👍 fanquake approved a pull request: "Use hardened runtime on macOS release builds."
(https://github.com/bitcoin/bitcoin/pull/29127#pullrequestreview-1815147663)
ACK 4fdd836db92e789c98b9e68398ca931a968cc9c3 - we can move ahead with this, and figure out notarisation / stapling as a followup.
(https://github.com/bitcoin/bitcoin/pull/29127#pullrequestreview-1815147663)
ACK 4fdd836db92e789c98b9e68398ca931a968cc9c3 - we can move ahead with this, and figure out notarisation / stapling as a followup.
✅ fanquake closed an issue: "macOS App Notarization"
(https://github.com/bitcoin/bitcoin/issues/15774)
(https://github.com/bitcoin/bitcoin/issues/15774)
🚀 fanquake merged a pull request: "Use hardened runtime on macOS release builds."
(https://github.com/bitcoin/bitcoin/pull/29127)
(https://github.com/bitcoin/bitcoin/pull/29127)
⚠️ fanquake reopened an issue: "macOS App Notarization"
(https://github.com/bitcoin/bitcoin/issues/15774)
> The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly. If there are no issues, the notary service generates a ticket for you to staple to your software; the notary service also publishes that ticket online where Gatekeeper can find it.
> Beginning in **macOS 10.14.5**, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must
...
(https://github.com/bitcoin/bitcoin/issues/15774)
> The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly. If there are no issues, the notary service generates a ticket for you to staple to your software; the notary service also publishes that ticket online where Gatekeeper can find it.
> Beginning in **macOS 10.14.5**, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must
...
🤔 glozow reviewed a pull request: "RPC: add new `listmempooltransactions`"
(https://github.com/bitcoin/bitcoin/pull/29016#pullrequestreview-1815145958)
> > Assuming you mean the sequence emitted from Transaction{AddedTo,RemovedFrom}Mempool, note that this is not actually the case (they're usually off by 1 or more due to when the sequence increments happen).
>
> Can you say more about this divergence or point me to a doc that contains more info?
It's more that they just happen to use the same counter, but that doesn't mean they match.
The mempool entry's sequence number is assigned here;
https://github.com/bitcoin/bitcoin/blob/fcacbab487
...
(https://github.com/bitcoin/bitcoin/pull/29016#pullrequestreview-1815145958)
> > Assuming you mean the sequence emitted from Transaction{AddedTo,RemovedFrom}Mempool, note that this is not actually the case (they're usually off by 1 or more due to when the sequence increments happen).
>
> Can you say more about this divergence or point me to a doc that contains more info?
It's more that they just happen to use the same counter, but that doesn't mean they match.
The mempool entry's sequence number is assigned here;
https://github.com/bitcoin/bitcoin/blob/fcacbab487
...
💬 glozow commented on pull request "RPC: add new `listmempooltransactions`":
(https://github.com/bitcoin/bitcoin/pull/29016#discussion_r1448596725)
Do note that a mempool tx from a recently disconnected block would be skipped here
(https://github.com/bitcoin/bitcoin/pull/29016#discussion_r1448596725)
Do note that a mempool tx from a recently disconnected block would be skipped here
💬 deyw-bit commented on issue "Failed loading mempool when restarting bitcoind":
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1886783736)
I can confirm a similar issue in a node running Bitcoin Core 25.1, as detailed below:
Config options:
- maxmempool=2000
- mempoolexpiry=720
- mempoolfullrbf=1
Prior to the node's restart, the mempool size was approximately 1.14 GB, which filled up over roughly 26 hours of uptime since the last node restart.
After initiating the shutdown, the node restarted immediately. According to the logs, the mempool was dumped ("Dumped mempool: 1.0479s to copy, 10.5051s to dump"). However, there
...
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1886783736)
I can confirm a similar issue in a node running Bitcoin Core 25.1, as detailed below:
Config options:
- maxmempool=2000
- mempoolexpiry=720
- mempoolfullrbf=1
Prior to the node's restart, the mempool size was approximately 1.14 GB, which filled up over roughly 26 hours of uptime since the last node restart.
After initiating the shutdown, the node restarted immediately. According to the logs, the mempool was dumped ("Dumped mempool: 1.0479s to copy, 10.5051s to dump"). However, there
...
💬 maflcko commented on pull request "test: add assumeutxo wallet test":
(https://github.com/bitcoin/bitcoin/pull/28838#issuecomment-1886787577)
lgtm ACK 997b9a73e5166b4244f7c5b4fe144d524f3005f4
(https://github.com/bitcoin/bitcoin/pull/28838#issuecomment-1886787577)
lgtm ACK 997b9a73e5166b4244f7c5b4fe144d524f3005f4
💬 maflcko commented on issue "Failed loading mempool when restarting bitcoind":
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1886796183)
> Ten minutes later, it increased to 18MB and continued to grow gradually
Loading the mempool takes time after a startup. You can monitor whether it is complete over the getmempoolinfo RPC (`loaded` field). Once it is loaded, the loading result will be printed to the debug log.
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1886796183)
> Ten minutes later, it increased to 18MB and continued to grow gradually
Loading the mempool takes time after a startup. You can monitor whether it is complete over the getmempoolinfo RPC (`loaded` field). Once it is loaded, the loading result will be printed to the debug log.
💬 deyw-bit commented on issue "Failed loading mempool when restarting bitcoind":
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1886805643)
Okay, will keep monitoring it, right now (90 minutes after restart), bitcoin-cli getmempoolinfo returns "loaded": false
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1886805643)
Okay, will keep monitoring it, right now (90 minutes after restart), bitcoin-cli getmempoolinfo returns "loaded": false
💬 maflcko commented on pull request "build: LLD based macOS toolchain":
(https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-1886821459)
> This is why this PR works fine, if you just invoke make -C depends HOST=arm64-apple-darwin, with clang installed, but if you make -C depends HOST=arm64-apple-darwin CC=clang-17 CXX=clang++-17, like we want to do in the CI
If picking the clang version via depends is not a use case to support outside the CI, what about aliasing `clang=clang-17` in the CI container? Obviously fixing depends would be cleaner, but if it is only used by CI, then it may not be needed.
The only requirement for
...
(https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-1886821459)
> This is why this PR works fine, if you just invoke make -C depends HOST=arm64-apple-darwin, with clang installed, but if you make -C depends HOST=arm64-apple-darwin CC=clang-17 CXX=clang++-17, like we want to do in the CI
If picking the clang version via depends is not a use case to support outside the CI, what about aliasing `clang=clang-17` in the CI container? Obviously fixing depends would be cleaner, but if it is only used by CI, then it may not be needed.
The only requirement for
...
💬 fanquake commented on pull request "build: LLD based macOS toolchain":
(https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-1886844363)
> Want to punt the libtool removal to a follow-up PR to avoid slowing this one down?
Looks like the cmake changes will require some additional CI changes at least. I think we can still open an additional PR, with upnpc and natpmp, and get that merged. Seems cleanest to just nuke libtool here, and avoid interim workarounds for Ubuntus binarys etc. I'll pull your new commits in here in any case.
> If picking the clang version via depends is not a use case to support outside the CI,
We do
...
(https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-1886844363)
> Want to punt the libtool removal to a follow-up PR to avoid slowing this one down?
Looks like the cmake changes will require some additional CI changes at least. I think we can still open an additional PR, with upnpc and natpmp, and get that merged. Seems cleanest to just nuke libtool here, and avoid interim workarounds for Ubuntus binarys etc. I'll pull your new commits in here in any case.
> If picking the clang version via depends is not a use case to support outside the CI,
We do
...
💬 moonsettler commented on pull request "Implement 64 bit arithmetic op codes in the Script interpreter":
(https://github.com/bitcoin/bitcoin/pull/29221#issuecomment-1886873235)
Concept ACK. i see no reason for this not to be bundled with any future amount introspection soft fork.
(https://github.com/bitcoin/bitcoin/pull/29221#issuecomment-1886873235)
Concept ACK. i see no reason for this not to be bundled with any future amount introspection soft fork.
📝 fanquake opened a pull request: "ci: move CMake into base packages"
(https://github.com/bitcoin/bitcoin/pull/29225)
This is already used in multiple CIs, and will soon become a requirement for most CIs, i.e when we migrate depends packages to use CMake, for example: https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-1885576324.
Some of the CIs in 21778 are failing because CMake isn't available, so just break this out and make CMake globally available.
(https://github.com/bitcoin/bitcoin/pull/29225)
This is already used in multiple CIs, and will soon become a requirement for most CIs, i.e when we migrate depends packages to use CMake, for example: https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-1885576324.
Some of the CIs in 21778 are failing because CMake isn't available, so just break this out and make CMake globally available.
💬 maflcko commented on pull request "ci: move CMake into base packages":
(https://github.com/bitcoin/bitcoin/pull/29225#issuecomment-1886940654)
Forgot centos?
(https://github.com/bitcoin/bitcoin/pull/29225#issuecomment-1886940654)
Forgot centos?
💬 fanquake commented on pull request "ci: move CMake into base packages":
(https://github.com/bitcoin/bitcoin/pull/29225#issuecomment-1886944344)
Forgot that has it's own `CI_BASE_PACKAGES`. Fixed up.
(https://github.com/bitcoin/bitcoin/pull/29225#issuecomment-1886944344)
Forgot that has it's own `CI_BASE_PACKAGES`. Fixed up.
📝 dergoegge opened a pull request: "Revert "build: Fix regression in "ARMv8 CRC32 intrinsics" test""
(https://github.com/bitcoin/bitcoin/pull/29226)
This reverts commit 228d6a2969e4fcee573c9df7aad31550eab9c8d4.
Fixes #29178
(https://github.com/bitcoin/bitcoin/pull/29226)
This reverts commit 228d6a2969e4fcee573c9df7aad31550eab9c8d4.
Fixes #29178
💬 dergoegge commented on pull request "Revert "build: Fix regression in "ARMv8 CRC32 intrinsics" test"":
(https://github.com/bitcoin/bitcoin/pull/29226#issuecomment-1886953885)
We could alternatively add a suppression but I prefer reverting unless someone can explain how this is not an actual bug.
(https://github.com/bitcoin/bitcoin/pull/29226#issuecomment-1886953885)
We could alternatively add a suppression but I prefer reverting unless someone can explain how this is not an actual bug.
💬 stickies-v commented on pull request "logging: Simplify API for level based logging":
(https://github.com/bitcoin/bitcoin/pull/28318#discussion_r1448721515)
I think ajtowns addressed that quite well at the bottom of [this comment](https://github.com/bitcoin/bitcoin/pull/28318#issuecomment-1702318968):
> I don't think that's a sensible concern: unconditional logging should be rare enough to not need disabling (eg, connecting to new outbounds, new headers, and new tips for about 400 entries a day), and at that point it's better not to disable them as that gives the user a pretty clear indication their node is still working right. Even for users th
...
(https://github.com/bitcoin/bitcoin/pull/28318#discussion_r1448721515)
I think ajtowns addressed that quite well at the bottom of [this comment](https://github.com/bitcoin/bitcoin/pull/28318#issuecomment-1702318968):
> I don't think that's a sensible concern: unconditional logging should be rare enough to not need disabling (eg, connecting to new outbounds, new headers, and new tips for about 400 entries a day), and at that point it's better not to disable them as that gives the user a pretty clear indication their node is still working right. Even for users th
...
📝 glozow opened a pull request: "log mempool loading progress"
(https://github.com/bitcoin/bitcoin/pull/29227)
Motivated by #29193. Currently, we only log something (non-debug) when we fail to load the file and at the end of importing all the transactions. That means it's hard to tell what's happening if it's taking a long time to load.
This PR adds a maximum of 10 new unconditional log lines:
- When we start to load transactions.
- Our progress percentage when it advances by at least 10% from the last time we logged. Percentage is based on the number of transactions.
If there are lots of transac
...
(https://github.com/bitcoin/bitcoin/pull/29227)
Motivated by #29193. Currently, we only log something (non-debug) when we fail to load the file and at the end of importing all the transactions. That means it's hard to tell what's happening if it's taking a long time to load.
This PR adds a maximum of 10 new unconditional log lines:
- When we start to load transactions.
- Our progress percentage when it advances by at least 10% from the last time we logged. Percentage is based on the number of transactions.
If there are lots of transac
...