*** Please remove the following help text before submitting: *** #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
They are exactly the same, but the descriptor utils should not prescribe to use the FuzzBufferType. Using a dedicated type for them clarifies that the utils are not tied to FuzzBufferType. Also, while touching the lines, use `const` only where it is meaningful.
… target The same are rejected in the descriptor_parse target, so it makes sense to reject them here as well.
Negative fees are possible with prioritisetransaction.
…eer Detail 301d9ee qt: Remove "Starting Block" from Peer Detail. Following Deprecation in `#34197` (WakeTrainDev) Pull request description: the `startingheight` rpc field got deprecated in #34197 this pr removes it from peer detail ACKs for top commit: maflcko: review lgtm ACK 301d9ee theStack: ACK 301d9ee hebasto: ACK 301d9ee, I verified `forms/debugwindow.ui` using Qt Designer. Tree-SHA512: b870b4cff8ead073a17d171c01c46fc7e750c0343b4578ffb63abc8f40b33abdf08beb6733fead5307ef5d48b078b60d29ac0e0e41190a98f50f92154f0878cf
An interrupt does not create a failure exit code during normal operation. This should also be the case when interrupt is triggered during initialization. However a failure exit code is currently returned if an interrupt occurs during init. Fix this by making `AppInitMain` return true instead of false, which further up the call stack sets the `EXIT_FAILURE` code. Also add a check for the interrupt condition during GUI startup.
Refactor a common way to perform the failed migration test that exists for default wallets, and add relative-path wallets and absolute-path wallets.
eeaf28d wallet: test: Failed migration cleanup (David Gumberg) Pull request description: Prior to #34156, an issue existed where if migration of a wallet with a relative pathname failed, the relatively specified path where the legacy wallet is would be deleted. This issue predates #32273, because the relative pathnames get stacked together, e.g. "../../", the copy conflict bug that caused migration to abort early instead of getting far enough to attempt clean-up that was fixed in #32273 is avoided. This is a functional test demonstrating that we handle failed migration clean-up correctly for relatively-named wallets. To see the issue, you can backport this test onto 29.x: https://github.com/davidgumberg/bitcoin/tree/2026-01-07-rel-migration-test-backport I've also added an absolute path failed migration cleanup test. WRT this and #34156, absolute paths exhibit similar behavior to unnamed wallets. Because of the name-conflict bug prior to #32273 an absolute-path migration would fail no matter what because migration would attempt to copy a file to a destination that already exists. But after #32273, absolute-path migration gets past there, and if it fails for some other reason, the same behavior that's fixed in #34156 occurs where the directory containing the wallet file is deleted. ACKs for top commit: achow101: ACK eeaf28d furszy: ACK eeaf28d rkrux: lgtm ACK eeaf28d Tree-SHA512: ee366fe526d0328654a86c2e9e6f228ca81554c8f8a78c259fa7aab90f024f9e5694ecf3f1d188938355f4e6d351c5a6a8ad236701bdd0ce63005e5d42c15e15
194114d guix: Fix `osslsigncode` tests (Hennadii Stepanov) Pull request description: This PR aims to improve the experience for Guix builders when creating new Guix profiles after 2025. In particular, it should be helpful for those who are new to building with Guix. Fixes #34220. Other possible alternatives to consider include: 1. Applying a workaround as suggested [here](#34220 (comment)). 2. Updating the package as suggested [here](#34220 (comment)). 3. Disabling tests as suggested [here](#34220 (comment)). ACKs for top commit: fanquake: ACK 194114d as a short-term, backportable workaround. janb84: ACK 194114d Tree-SHA512: b263604297adfc54fccab8fe3c3126939b729aebda5b7e15f6f453a17260fd4ea754523a694bbc4268693513d071c4362325b0511696af2e81f00f1a461bcfa9
2cade5d [miniminer] stop assuming ancestor fees >= self fees (glozow) Pull request description: These assertions exist to detect double-deducting values when we update descendants. However, negative fees are possible with `prioritisetransaction` so it doesn't make sense to check this. Leave the check for sizes because those are never negative. Fixes #34234 ACKs for top commit: instagibbs: ACK 2cade5d dergoegge: utACK 2cade5d Tree-SHA512: 935bbc8bd9a0d508eea43bb49aa43c22735e3f2c1012598f6843e229c13b76e44f9fd3eb8b61c437fa0b32353b4e7b15afa3e31002bdfa382d3d711d16419fde
d1b227f Add sedited to trusted-keys (sedited) Pull request description: As discussed on irc: https://www.erisian.com.au/bitcoin-core-dev/log-2026-01-08.html#l-286 ACKs for top commit: l0rinc: ACK d1b227f, well deserved. achow101: ACK d1b227f fjahr: ACK d1b227f darosior: ACK d1b227f theStack: ACK d1b227f 🍾 willcl-ark: ACK d1b227f glozow: ACK d1b227f mzumsande: ACK d1b227f Tree-SHA512: 865507213459013d88c3bd74797efd5bf2ad81cafb184520fc62a471b3c01786194ef842a046a34085c8ef65a8e02e634cd9b6c2c75ca40298cfb5d0ea38d1dd
- No need to jump into the next subroutine when there is no conflict. - This makes it clear why it is necessary to have two calls of CheckMempoolPolicyLimts in both PackageMempoolChecks and after in AcceptMultipleTransactionsInternal, there is a possibilty that we we want to accept multiple transaction but they are not conflicting with any in-mempool transaction, in that case also we want to check that they do not bust the cluster limits.
ca4a844 depends: Boost 1.90.0 (fanquake) Pull request description: Update [Boost to 1.90.0](https://www.boost.org/releases/1.90.0.beta1/) in depends. ACKs for top commit: hebasto: ACK ca4a844. sedited: ACK ca4a844 Tree-SHA512: d9fbef9f8f8b14b12281a252b17c79abb8bf5bcd5cbbccac0e509c010adca909f66d3f4739f6663741c5ff2829ec58e88185e67ed5815d2588b0980bba9b1b63
Allow some commits to not require the sha1 check.
Use port=0 for dynamic port allocation in test framework components to avoid "address already in use" errors from concurrent tests or ports stuck in TIME_WAIT state from previous test runs. Changes: - socks5.py: Update conf.addr after bind() to reflect actual port - p2p.py: Retrieve actual port after create_server() when port=0 - feature_proxy.py: Use port=0 for all SOCKS5 proxy servers - feature_anchors.py: Use port=0 for onion proxy server
`CCoinsViewCache::FetchCoin()` had special handling for a spent `Coin` returned by the parent view. Production parents (`CCoinsViewCache` and `CCoinsViewDB`) do not return spent coins, so this path is unreachable. Replace it with an `Assume(!coin.IsSpent())`, drop outdated documentation about spent+FRESH cache entries, and simplify `SanityCheck()` to assert the remaining possible state invariants. This is safe because it does not change behavior for valid backends and will fail fast if the `GetCoin()` contract is violated. Co-authored-by: Lőrinc <pap.lorinc@gmail.com>
44b12cd doc: add 433 (Pay to Anchor) to bips.md (Sebastian Falbesoner) Pull request description: See PR bitcoin/bips#1982 (merged recently) and #30352 (first released in v28.0). ACKs for top commit: instagibbs: ACK 44b12cd glozow: ACK 44b12cd Tree-SHA512: 0389bfd9b57a354ef15eff726783c83969586a73de52d27b6d3b042dba14c1361af29303b6ce42330a841310811a81c5e45b5c7d25e307787f1cfbfd75ab3e62
Add a unit test that exercises the `IsInitialBlockDownload()` decision matrix by varying the cached latch, `BlockManager::LoadingBlocks()`, and tip work/recency inputs. This documents the current latching behavior and provides a baseline for later refactors.
Rename and invert the internal IBD latch so the cached value directly matches `IsInitialBlockDownload()` (true while in IBD, then latched to false). This is a behavior-preserving refactor to avoid double negatives.
Factor the chain tip work/recency check out of `ChainstateManager::IsInitialBlockDownload()` into a reusable `CChain::IsTipRecent()` helper, and annotate it as requiring `cs_main` since it's reading mutable state. Also introduce a local `chainman_ref` in the kernel import-blocks wrapper to reduce repetition and keep follow-up diffs small. `IsInitialBlockDownload` returns were also unified to make the followup move clean. Co-authored-by: Patrick Strateman <patrick.strateman@gmail.com> Co-authored-by: Martin Zumsande <mzumsande@gmail.com>
`ChainstateManager::IsInitialBlockDownload()` is queried on hot paths and previously acquired `cs_main` internally, contributing to lock contention. Cache the IBD status in `m_cached_is_ibd`, and introduce `ChainstateManager::UpdateIBDStatus()` to latch it once block loading has finished and the current chain tip has enough work and is recent. Call the updater after tip updates and after `ImportBlocks()` completes. Since `IsInitialBlockDownload()` no longer updates the cache, drop `mutable` from `m_cached_is_ibd` and only update it from `UpdateIBDStatus()` under `cs_main`. Update the new unit test to showcase the new `UpdateIBDStatus()`. Co-authored-by: Patrick Strateman <patrick.strateman@gmail.com> Co-authored-by: Martin Zumsande <mzumsande@gmail.com>
…I2P connections 8937221 doc: add release notes for 29415 (Vasil Dimov) 582016f test: add unit test for the private broadcast storage (Vasil Dimov) e74d54e test: add functional test for private broadcast (Vasil Dimov) 818b780 rpc: use private broadcast from sendrawtransaction RPC if -privatebroadcast is ON (Vasil Dimov) eab595f net_processing: retry private broadcast (Vasil Dimov) 37b79f9 net_processing: stop private broadcast of a transaction after round-trip (Vasil Dimov) 2de53ee net_processing: handle ConnectionType::PRIVATE_BROADCAST connections (Vasil Dimov) 30a9853 net_processing: move a debug check in VERACK processing earlier (Vasil Dimov) d1092e5 net_processing: modernize PushNodeVersion() (Vasil Dimov) 9937a12 net_processing: move the debug log about receiving VERSION earlier (Vasil Dimov) a098f37 net_processing: reorder the code that handles the VERSION message (Vasil Dimov) 679ce3a net_processing: store transactions for private broadcast in PeerManager (Vasil Dimov) a3faa6f node: extend node::TxBroadcast with a 3rd option (Vasil Dimov) 95c051e net_processing: rename RelayTransaction() to better describe what it does (Vasil Dimov) bb49d26 net: implement opening PRIVATE_BROADCAST connections (Vasil Dimov) 01dad4e net: introduce a new connection type for private broadcast (Vasil Dimov) 94aaa5d init: introduce a new option to enable/disable private broadcast (Vasil Dimov) d6ee490 log: introduce a new category for private broadcast (Vasil Dimov) Pull request description: _Parts of this PR are isolated in independent smaller PRs to ease review:_ * [x] _https://github.com/bitcoin/bitcoin/pull/29420_ * [x] _https://github.com/bitcoin/bitcoin/pull/33454_ * [x] _https://github.com/bitcoin/bitcoin/pull/33567_ * [x] _https://github.com/bitcoin/bitcoin/pull/33793_ --- To improve privacy, broadcast locally submitted transactions (from the `sendrawtransaction` RPC) to the P2P network only via Tor or I2P short-lived connections, or to IPv4/IPv6 peers but through the Tor network. * Introduce a new connection type for private broadcast of transactions with the following properties: * started whenever there are local transactions to be sent * opened to Tor or I2P peers or IPv4/IPv6 via the Tor proxy * opened regardless of max connections limits * after handshake is completed one local transaction is pushed to the peer, `PING` is sent and after receiving `PONG` the connection is closed * ignore all incoming messages after handshake is completed (except `PONG`) * Broadcast transactions submitted via `sendrawtransaction` using this new mechanism, to a few peers. Keep doing this until we receive back this transaction from one of our ordinary peers (this takes about 1 second on mainnet). * The transaction is stored in peerman and does not enter the mempool. * Once we get an `INV` from one of our ordinary peers, then the normal flow executes: we request the transaction with `GETDATA`, receive it with a `TX` message, put it in our mempool and broadcast it to all our existent connections (as if we see it for the first time). * After we receive the full transaction as a `TX` message, in reply to our `GETDATA` request, only then consider the transaction has propagated through the network and remove it from the storage in peerman, ending the private broadcast attempts. The messages exchange should look like this: ``` tx-sender >--- connect -------> tx-recipient tx-sender >--- VERSION -------> tx-recipient (dummy VERSION with no revealing data) tx-sender <--- VERSION -------< tx-recipient tx-sender <--- WTXIDRELAY ----< tx-recipient (maybe) tx-sender <--- SENDADDRV2 ----< tx-recipient (maybe) tx-sender <--- SENDTXRCNCL ---< tx-recipient (maybe) tx-sender <--- VERACK --------< tx-recipient tx-sender >--- VERACK --------> tx-recipient tx-sender >--- INV/TX --------> tx-recipient tx-sender <--- GETDATA/TX ----< tx-recipient tx-sender >--- TX ------------> tx-recipient tx-sender >--- PING ----------> tx-recipient tx-sender <--- PONG ----------< tx-recipient tx-sender disconnects ``` Whenever a new transaction is received from `sendrawtransaction` RPC, the node will send it to a few (`NUM_PRIVATE_BROADCAST_PER_TX`) recipients right away. If after some time we still have not heard anything about the transaction from the network, then it will be sent to 1 more peer (see `PeerManagerImpl::ReattemptPrivateBroadcast()`). A few considerations: * The short-lived private broadcast connections are very cheap and fast wrt network traffic. It is expected that some of those peers could blackhole the transaction. Just one honest/proper peer is enough for successful propagation. * The peers that receive the transaction could deduce that this is initial transaction broadcast from the transaction originator. This is ok, they can't identify the sender. --- <details> <summary>How to test this?</summary> Thank you, @stratospher and @andrewtoth! Start `bitcoind` with `-privatebroadcast=1 -debug=privatebroadcast`. Create a wallet and get a new address, go to the Signet faucet and request some coins to that address: ```bash build/bin/bitcoin-cli -chain="signet" createwallet test build/bin/bitcoin-cli -chain="signet" getnewaddress ``` Get a new address for the test transaction recipient: ```bash build/bin/bitcoin-cli -chain="signet" loadwallet test new_address=$(build/bin/bitcoin-cli -chain="signet" getnewaddress) ``` Create the transaction: ```bash # Option 1: `createrawtransaction` and `signrawtransactionwithwallet`: txid=$(build/bin/bitcoin-cli -chain="signet" listunspent | jq -r '.[0] | .txid') vout=$(build/bin/bitcoin-cli -chain="signet" listunspent | jq -r '.[0] | .vout') echo "txid: $txid" echo "vout: $vout" tx=$(build/bin/bitcoin-cli -chain="signet" createrawtransaction "[{\"txid\": \"$txid\", \"vout\": $vout}]" "[{\"$new_address\": 0.00001000}]" 0 false) echo "tx: $tx" signed_tx=$(build/bin/bitcoin-cli -chain="signet" signrawtransactionwithwallet "$tx" | jq -r '.hex') echo "signed_tx: $signed_tx" # OR Option 2: `walletcreatefundedpsbt` and `walletprocesspsbt`: # This makes it not have to worry about inputs and also automatically sends back change to the wallet. # Start `bitcoind` with `-fallbackfee=0.00003000` for instance for 3 sat/vbyte fee. psbt=$(build/bin/bitcoin-cli -chain="signet" walletcreatefundedpsbt "[]" "[{\"$new_address\": 0.00001000}]" | jq -r '.psbt') echo "psbt: $psbt" signed_tx=$(build/bin/bitcoin-cli -chain="signet" walletprocesspsbt "$psbt" | jq -r '.hex') echo "signed_tx: $signed_tx" ``` Finally, send the transaction: ```bash raw_tx=$(build/bin/bitcoin-cli -chain="signet" sendrawtransaction "$signed_tx") echo "raw_tx: $raw_tx" ``` </details> --- <details> <summary>High-level explanation of the commits</summary> * New logging category and config option to enable private broadcast * `log: introduce a new category for private broadcast` * `init: introduce a new option to enable/disable private broadcast` * Implement the private broadcast connection handling on the `CConnman` side: * `net: introduce a new connection type for private broadcast` * `net: implement opening PRIVATE_BROADCAST connections` * Prepare `BroadcastTransaction()` for private broadcast requests: * `net_processing: rename RelayTransaction to better describe what it does` * `node: extend node::TxBroadcast with a 3rd option` * `net_processing: store transactions for private broadcast in PeerManager` * Implement the private broadcast connection handling on the `PeerManager` side: * `net_processing: reorder the code that handles the VERSION message` * `net_processing: move the debug log about receiving VERSION earlier` * `net_processing: modernize PushNodeVersion()` * `net_processing: move a debug check in VERACK processing earlier` * `net_processing: handle ConnectionType::PRIVATE_BROADCAST connections` * `net_processing: stop private broadcast of a transaction after round-trip` * `net_processing: retry private broadcast` * Engage the new functionality from `sendrawtransaction`: * `rpc: use private broadcast from sendrawtransaction RPC if -privatebroadcast is ON` * New tests: * `test: add functional test for private broadcast` * `test: add unit test for the private broadcast storage` </details> --- **This PR would resolve the following issues:** #3828 Clients leak IPs if they are recipients of a transaction #14692 Can't configure bitocoind to only send tx via Tor but receive clearnet transactions #19042 Tor-only transaction broadcast onlynet=onion alternative #24557 Option for receive events with all networks, but send transactions and/or blocks only with anonymous network[s]? #25450 Ability to broadcast wallet transactions only via dedicated oneshot Tor connections #32235 Tor: TX circuit isolation **Issues that are related, but (maybe?) not to be resolved by this PR:** #21876 Broadcast a transaction to specific nodes #28636 new RPC: sendrawtransactiontopeer --- Further extensions: * Have the wallet do the private broadcast as well, #11887 would have to be resolved. * Have the `submitpackage` RPC do the private broadcast as well, [draft diff in the comment below](#29415 (review)), thanks ismaelsadeeq! * Add some stats via RPC, so that the user can better monitor what is going on during and after the broadcast. Currently this can be done via the debug log, but that is not convenient. * Make the private broadcast storage, currently in peerman, persistent over node restarts. * Add (optional) random delay before starting to broadcast the transaction in order to avoid correlating unrelated transactions based on the time when they were broadcast. Suggested independently of this PR [here](#30471). * Consider periodically sending transactions that did not originate from the node as decoy, discussed [here](#29415 (comment)). * Consider waiting for peer's FEEFILTER message and if the transaction that was sent to the peer is below that threshold, then assume the peer is going to drop it. Then use this knowledge to retry more aggressively with another peer, instead of the current 10 min. See [comment below](#29415 (comment)). * It may make sense to be able to override the default policy -- eg so submitrawtransaction can go straight to the mempool and relay, even if txs are normally privately relayed. See [comment below](#29415 (comment)). * As a side effect we have a new metric available - the time it takes for a transaction to reach a random node in the network (from the point of view of the private broadcast recipient the tx originator is a random node somewhere in the network). This can be useful for monitoring, unrelated to privacy characteristics of this feature. --- _A previous incarnation of this can be found at #27509. It puts the transaction in the mempool and (tries to) hide it from the outside observers. This turned out to be too error prone or maybe even impossible._ ACKs for top commit: l0rinc: code review diff ACK 8937221 andrewtoth: ACK 8937221 pinheadmz: ACK 8937221 w0xlt: ACK 8937221 with nit #29415 (comment) mzumsande: re-ACK 8937221 Tree-SHA512: d51dadc865c2eb080c903cbe2f669e69a967e5f9fc64e9a20a68f39a67bf0db6ac2ad682af7fa24ef9f0942a41c89959341a16ba7b616475e1c5ab8e563b9b96
3400db8 doc: add missing param description to SRD (yancy) Pull request description: The params documentation is missing `change_fee` and the description is lacking recent changes. ACKs for top commit: murchandamus: ACK 3400db8 brunoerg: code review ACK 3400db8 Tree-SHA512: 8f6fac0d92873c5c9f77b19fbc0c6ecfb425b2a6b3d5f5ad69c82ed706b21cf4627e68c71acbc43661000e6063e8f8dbcd3b8ff60e3c727bdcba497d13ee1383
On merges to master we set LINT_CI_SANITY_CHECK_COMMIT_SIG (when "GITHUB_REPOSITORY == bitcoin/bitcoin") which runs verify-commits.py. This requires write access to the .git directory. Make the mounted .git directory writable. This is currently not run on PR branches or locally which caused a miss during review.
c8abac9 ci: mount .git dir rw (ci) Pull request description: On merges to master we set LINT_CI_SANITY_CHECK_COMMIT_SIG (when "GITHUB_REPOSITORY == bitcoin/bitcoin") which runs verify-commits.py. This requires write access to the .git directory. Make the mounted .git directory writable. This is currently not run on PR branches or locally which caused a miss during review. Ideally we can have the same checks running in PRs as on merges to master to avoid future discrepancies like this. ACKs for top commit: maflcko: lgtm ACK c8abac9 l0rinc: untested code review ACK c8abac9 Tree-SHA512: 7ae4f63227ecffe1dc9003454a7473d6d592550af2e1c899457f34a947e5604b04c13319fb8979f36789ae7787bed62066be60697d163ad5ebedde3fbe8ce45f
…em as errors fdc9fe2 ci, iwyu: Fix warnings in `src/primitives` and treat them as errors (Hennadii Stepanov) Pull request description: This PR [continues](#33725 (comment)) the ongoing effort to enforce IWYU warnings. See [Developer Notes](https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#using-iwyu). ACKs for top commit: maflcko: review ACK fdc9fe2 📀 janb84: ACK fdc9fe2 sedited: ACK fdc9fe2 Tree-SHA512: d290545c7aab477b4a5bf121b694899a78e0526be72efa31fa4205b0fd840e6e8240d32f9134a18c9dc58c5f91e7847d7f20ca34f8d2edc4d541ac858ec0dccc
fa578d9 lint: [move-only] Move python related lints to lint_py.rs (MarcoFalke) fa392c3 lint: [move-only] Move repo related lints to lint_repo_hygiene.rs (MarcoFalke) fab0cfa lint: [move-only] Move cpp related lints to lint_cpp.rs (MarcoFalke) fa3e48e lint: [move-only] Move docs related lints to lint_docs.rs (MarcoFalke) fad09e7 lint: [move-only] Move text related lints to text_format.rs (MarcoFalke) faf40c2 lint: [move-only] Move util functions to util.rs (MarcoFalke) Pull request description: The single, large `main.rs` file is fine, but at some point it becomes harder to read. So reduce the size by pulling functions out into modules. This can be reviewed with the git option: `--color-moved=dimmed-zebra` ACKs for top commit: l0rinc: Lightly tested code review ACK fa578d9 sedited: ACK fa578d9 Tree-SHA512: f1e29fd3cf695fb6634d0b9f9e55508992b4b9885afee9dbe4d5d9e99cad3061e7141f39acbfe69d698422888169128cd7658a6dc991fd904b8520328b51586d
ab649ce guix: documented shasum gathering command (janb84) Pull request description: When a PR requires proof of Guix builds (sha256sums), the PR author or reviewer uses a not well documented command to collect the sha256sums of build outputs or manually gathers them from files. This pull request introduces a new section in the documentation, providing some documentation on the command's functionality and usage. ACKs for top commit: willcl-ark: ACK ab649ce sedited: ACK ab649ce Tree-SHA512: 0188663ad117b636c7d32a1b655db97610f558cfcffe4abd6f0fb097b3990db0dc6d23ab972926fefd2531b21f429742dcbea6b0fa579d22d5da7a7d6a4c753e
…onditionally fa9c92d log: Print warning about privacy-sensitive log info unconditionally (MarcoFalke) Pull request description: There is a warning about logs containing privacy-sensitive information. However, it is only printed when at least one debug log category is enabled. This is confusing, because: * Setting (let's say) `-debug=reindex` enables this warning, but it is hard to see what sensitive logs could be contained in reindex debug logs. * Dropping `-debug=reindex` again disabled this warning, but the wallet continues to log txids (and other sensitive stuff) at info level. So instead of implying the wrong thing, it would be better to remove this log line (because it should be common sense), or log it unconditionally. ACKs for top commit: l0rinc: ACK fa9c92d sedited: ACK fa9c92d Tree-SHA512: 42f71b030e7722203f225f04e979143e829dae3556f64e322a791361a3b9c16150d53bb7bb9a99839c975d9052115770b9473138acc58baeee457253526fd892
905dfde test: use ModuleNotFoundError in interface_ipc.py (fanquake) Pull request description: Change this so we catch the case where the capnp shared libs have been updated, and can no-longer be loaded by the Python module, resulting in a skipped test, even though pycapnp is installed. i.e: ```bash stderr: Traceback (most recent call last): File "/root/ci_scratch/build/test/functional/interface_ipc.py", line 20, in <module> import capnp # type: ignore[import] # noqa: F401 ^^^^^^^^^^^^ File "/usr/local/lib64/python3.14/site-packages/capnp/__init__.py", line 36, in <module> from .version import version as __version__ File "/usr/local/lib64/python3.14/site-packages/capnp/version.py", line 1, in <module> from .lib.capnp import _CAPNP_VERSION_MAJOR as LIBCAPNP_VERSION_MAJOR # noqa: F401 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ImportError: libcapnpc.so.1.0.1: cannot open shared object file: No such file or directory ``` Failing in this way should make it clear that `pycapnp` needs to be reinstalled/rebuilt. If `pycapnp` is not installed, the test still skips as expected: ```bash Remaining jobs: [interface_ipc.py] 1/1 - interface_ipc.py skipped (capnp module not available.) TEST | STATUS | DURATION interface_ipc.py | ○ Skipped | 0 s ``` Fixes: #34016. ACKs for top commit: maflcko: lgtm ACK 905dfde hebasto: ACK 905dfde, I have reviewed the code and it looks OK. However, I'm [not able](#34016 (comment)) to reproduce #34016. sedited: ACK 905dfde Tree-SHA512: 3cedbe8fc51cc18f1c993f7747d20905f3bf94c736db99a9c4090f5823bf8c09dfbc19ef03c573d504dcdfba6ea0f7d088a7f4563b220742c9a441167c04cfd6
…sactions 1f60ca3 wallet: fix removeprunedfunds bug with conflicting transactions (Martin Zumsande) Pull request description: `removeprunedfunds` removes all entries from `mapTxSpends` for the inputs of the pruned tx. However, this is incorrect, because there could be multiple entries from conflicting transactions (that shouldn't be removed as well). This could lead to the wallet creating invalid transactions, trying to double spend utxos. The bug persists when the conflicting tx was mined, because the wallet trusts its internal accounting instead of calling `AddToSpends` again. The added test should fail on master. ACKs for top commit: achow101: ACK 1f60ca3 fjahr: tACK 1f60ca3 furszy: utACK 1f60ca3 vasild: ACK 1f60ca3 Tree-SHA512: 3cc9ed547530fd53e25721177b76ab2e1eae16ce2c0e63fc01b20fdbf8bd02655dae51167ad56f9dec748d34c61ce65d38f993370820601f8257c73b876a3347
and_v() must never be 'd'. This is not a bug fix since this was unreachable in valid Miniscripts: the first sub of an and_v() must be of type V, which conflicts with (i.e. never has) property 'd'.
…t coins 2ee7f9b coins: assume `GetCoin` only returns unspent coins (Andrew Toth) eec551a fuzz: keep `coinscache_sim` backend free of spent coins (Andrew Toth) 3e4155f test: do not return spent coins from `CCoinsViewTest::GetCoin` (Andrew Toth) ee1e40f txdb: assert `CCoinsViewDB::GetCoin` only returns unspent coins (Lőrinc) Pull request description: This PR is split out from #33018 to keep that PR focused on removing the `FRESH-but-not-DIRTY` cache state. ### Problem `::GetCoin()` is an interface for querying the UTXO set, so production implementations should only ever return unspent coins. Tests should mimic this to provide useful feedback. ### Fix: * Add a fail-fast assertion that `CCoinsViewDB::GetCoin()` never returns a spent coin. * Align unit tests and fuzz simulations with the production `GetCoin()` contract by never returning spent coins. * Replace the unreachable “spent coin returned by parent” handling in `CCoinsViewCache::FetchCoin()` with `Assert(!coin.IsSpent())`, drop outdated `spent+FRESH` docs, and tighten `SanityCheck()` invariants. Behavior is unchanged, it just aligns our tests to exercise valid states. ACKs for top commit: andrewtoth: re-ACK 2ee7f9b optout21: crACK 2ee7f9b achow101: ACK 2ee7f9b w0xlt: reACK 2ee7f9b Tree-SHA512: be21cc09690410fc04ca25e1ba47aae6186bc037e413b3bb1e6e9a04e6364cbfac5a2fcdc49b638fec848cd29243fab0cc0581b9923f34fafe8366828f690ed4
…ling e770392 test: addrman: test self-announcement time penalty handling (Bruno Garcia) Pull request description: This PR adds a test case for addrman that verifies that addresses announcing themselves (addr == source) are exempt from time penalties, while addresses announced by others receive the expected penalty. It fixes the following mutant (https://corecheck.dev/mutation/src/addrman.cpp#L561): ```diff diff --git a/src/addrman.cpp b/src/addrman.cpp index 206b541..c6a045fd8d 100644 --- a/src/addrman.cpp +++ b/src/addrman.cpp @@ -558,7 +558,7 @@ bool AddrManImpl::AddSingle(const CAddress& addr, const CNetAddr& source, std::c AddrInfo* pinfo = Find(addr, &nId); // Do not set a penalty for a source's self-announcement - if (addr == source) { + if (addr != source) { time_penalty = 0s; } ``` ACKs for top commit: maflcko: review ACK e770392 🐤 achow101: ACK e770392 fjahr: Code review ACK e770392 naiyoma: tACK e770392 Tree-SHA512: ec029d1e1e979f91840af944984cad530a1ce9a0eceb123230817f0ef3b9ad47253eebc4c953d350de2d904b59496fcd4757123c8bd63cf0e09c3581da48fff8
fad0422 refactor: Remove remaining std::bind, check via clang-tidy (MarcoFalke) Pull request description: `std::bind` has many issues: * It is verbose in a meaningless way * Overriden args are silently accepted and dropped at runtime without a compile error. Same for accidental duplicates. One could use `std::bind_front` similar to commit fa26755. Though, I think the remaining cases are better off with lambdas. So do that here, and enable the `modernize-avoid-bind` clang-tidy rule to avoid `std::bind` bugs in the future. ACKs for top commit: fjahr: Code review ACK fad0422 purpleKarrot: Code review ACK fad0422 Tree-SHA512: 38b17e26eda3ae47d84a8c34298309dc1eeb4ed434fda58b5803ef031c4c2edfb17222f5208f37af727bf340e32b37c7f81784f461d2b65fbc6227f3cd53eea4
…lockDownload()` 557b41a validation: make `IsInitialBlockDownload()` lock-free (Lőrinc) b9c0ab3 chain: add `CChain::IsTipRecent` helper (Lőrinc) 8d531c6 validation: invert `m_cached_finished_ibd` to `m_cached_is_ibd` (Lőrinc) 8be54e3 test: cover IBD exit conditions (Lőrinc) Pull request description: This PR is a follow-up to the stale #32885. ### Problem `ChainstateManager::IsInitialBlockDownload()` currently acquires `cs_main` internally, even though most existing call sites already hold the lock. This becomes relevant for proposals like #34054, which would call `IsInitialBlockDownload()` from the scheduler thread without holding `cs_main`, potentially introducing lock contention. ### Fix Make `ChainstateManager::IsInitialBlockDownload()` lock-free by caching its result in a single atomic `m_cached_is_ibd` (true while in IBD, latched to false on exit). Move the IBD exit checks out of `IsInitialBlockDownload()` (reader-side) into a new `ChainstateManager::UpdateIBDStatus()` (writer-side, called under cs_main). Call UpdateIBDStatus() at strategic points where IBD exit conditions may change, after active chain tip updates in `ConnectTip()`, `DisconnectTip()`, and `LoadChainTip()`, and after `ImportBlocks()` returns. With this, `IsInitialBlockDownload()` becomes a lock-free atomic read, avoiding internal `cs_main` acquisition on hot paths. ### Testing and Benchmarks This isn't strictly an optimization (though some usecases might benefit from it), so rather as a sanity check I ran a reindex-chainstate and an `AssumeUTXO` load (without background validation). <details> <summary>assumeutxo load | 910000 blocks | dbcache 4500 | i9-ssd | x86_64 | Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz | 16 cores | 62Gi RAM | xfs | SSD</summary> ``` COMMITS="595504a43209bead162da54a204df7d140a25f0e 63e822b"; \ CC=gcc; CXX=g++; \ BASE_DIR="/mnt/my_storage"; DATA_DIR="$BASE_DIR/ShallowBitcoinData"; LOG_DIR="$BASE_DIR/logs"; UTXO_SNAPSHOT_PATH="$BASE_DIR/utxo-910000.dat"; \ (echo ""; for c in $COMMITS; do git fetch -q origin $c && git log -1 --pretty='%h %s' $c || exit 1; done; echo "") && \ for DBCACHE in 4500; do \ (echo "assumeutxo load | 910000 blocks | dbcache ${DBCACHE} | $(hostname) | $(uname -m) | $(lscpu | grep 'Model name' | head -1 | cut -d: -f2 | xargs) | $(nproc) cores | $(free -h | awk '/^Mem:/{print $2}') RAM | $(df -T $BASE_DIR | awk 'NR==2{print $2}') | $(lsblk -no ROTA $(df --output=source $BASE_DIR | tail -1) | grep -q 0 && echo SSD || echo HDD)";) &&\ hyperfine \ --sort command \ --runs 3 \ --export-json "$BASE_DIR/assumeutxo-$(sed -E 's/(\w{8})\w+ ?/\1-/g;s/-$//'<<<"$COMMITS")-$DBCACHE-$CC-$(date +%s).json" \ --parameter-list COMMIT ${COMMITS// /,} \ --prepare "killall -9 bitcoind 2>/dev/null; rm -rf $DATA_DIR/blocks $DATA_DIR/chainstate $DATA_DIR/chainstate_snapshot $DATA_DIR/debug.log; git clean -fxd; git reset --hard {COMMIT} && \ cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo && ninja -C build bitcoind bitcoin-cli -j2 && \ ./build/bin/bitcoind -datadir=$DATA_DIR -stopatheight=1 -printtoconsole=0; sleep 20 && \ ./build/bin/bitcoind -datadir=$DATA_DIR -daemon -blocksonly -connect=0 -dbcache=$DBCACHE -printtoconsole=0; sleep 20" \ --conclude "build/bin/bitcoin-cli -datadir=$DATA_DIR stop || true; killall bitcoind || true; sleep 10; \ echo '{COMMIT} | dbcache=$DBCACHE | chainstate: $(find $DATA_DIR/chainstate_snapshot -type f 2>/dev/null | wc -l) files, $(du -sb $DATA_DIR/chainstate_snapshot 2>/dev/null | cut -f1) bytes' >> $DATA_DIR/debug.log; \ cp $DATA_DIR/debug.log $LOG_DIR/debug-assumeutxo-{COMMIT}-dbcache-$DBCACHE-$(date +%s).log" \ "COMPILER=$CC DBCACHE=$DBCACHE ./build/bin/bitcoin-cli -datadir=$DATA_DIR -rpcclienttimeout=0 loadtxoutset $UTXO_SNAPSHOT_PATH"; \ done 595504a Merge #34236: Add sedited to trusted-keys 63e822b validation: make `IsInitialBlockDownload()` lock-free assumeutxo load | 910000 blocks | dbcache 4500 | i9-ssd | x86_64 | Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz | 16 cores | 62Gi RAM | xfs | SSD Benchmark 1: COMPILER=gcc DBCACHE=4500 ./build/bin/bitcoin-cli -datadir=/mnt/my_storage/ShallowBitcoinData -rpcclienttimeout=0 loadtxoutset /mnt/my_storage/utxo-910000.dat (COMMIT = 595504a) Time (mean ± σ): 418.452 s ± 0.461 s [User: 0.001 s, System: 0.001 s] Range (min … max): 418.070 s … 418.964 s 3 runs Benchmark 2: COMPILER=gcc DBCACHE=4500 ./build/bin/bitcoin-cli -datadir=/mnt/my_storage/ShallowBitcoinData -rpcclienttimeout=0 loadtxoutset /mnt/my_storage/utxo-910000.dat (COMMIT = 63e822b) Time (mean ± σ): 415.994 s ± 0.294 s [User: 0.001 s, System: 0.001 s] Range (min … max): 415.788 s … 416.330 s 3 runs Relative speed comparison 1.01 ± 0.00 COMPILER=gcc DBCACHE=4500 ./build/bin/bitcoin-cli -datadir=/mnt/my_storage/ShallowBitcoinData -rpcclienttimeout=0 loadtxoutset /mnt/my_storage/utxo-910000.dat (COMMIT = 595504a) 1.00 COMPILER=gcc DBCACHE=4500 ./build/bin/bitcoin-cli -datadir=/mnt/my_storage/ShallowBitcoinData -rpcclienttimeout=0 loadtxoutset /mnt/my_storage/utxo-910000.dat (COMMIT = 63e822b) ``` </details> <details> <summary>2026-01-12 | reindex-chainstate | 931139 blocks | dbcache 4500 | i9-ssd | x86_64 | Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz | 16 cores | 62Gi RAM | SSD</summary> ``` for DBCACHE in 4500; do \ COMMITS="595504a43209bead162da54a204df7d140a25f0e 63e822b"; \ STOP=931139; CC=gcc; CXX=g++; \ BASE_DIR="/mnt/my_storage"; DATA_DIR="$BASE_DIR/BitcoinData"; LOG_DIR="$BASE_DIR/logs"; \ (echo ""; for c in $COMMITS; do git fetch -q origin $c && git log -1 --pretty='%h %s' $c || exit 1; done) && \ (echo "" && echo "$(date -I) | reindex-chainstate | ${STOP} blocks | dbcache ${DBCACHE} | $(hostname) | $(uname -m) | $(lscpu | grep 'Model name' | head -1 | cut -d: -f2 | xargs) | $(nproc) cores | $(free -h | awk '/^Mem:/{print $2}') RAM | SSD"; echo "") &&\ hyperfine \ --sort command \ --runs 1 \ --export-json "$BASE_DIR/rdx-$(sed -E 's/(\w{8})\w+ ?/\1-/g;s/-$//'<<<"$COMMITS")-$STOP-$DBCACHE-$CC.json" \ --parameter-list COMMIT ${COMMITS// /,} \ --prepare "killall -9 bitcoind 2>/dev/null; rm -f $DATA_DIR/debug.log; git clean -fxd; git reset --hard {COMMIT} && \ cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DENABLE_IPC=OFF && ninja -C build bitcoind -j1 && \ ./build/bin/bitcoind -datadir=$DATA_DIR -stopatheight=$STOP -dbcache=1000 -printtoconsole=0; sleep 20; rm -f $DATA_DIR/debug.log" \ --conclude "killall bitcoind || true; sleep 5; grep -q 'height=0' $DATA_DIR/debug.log && grep -q 'Disabling script verification at block #1' $DATA_DIR/debug.log && grep -q 'height=$STOP' $DATA_DIR/debug.log; \ cp $DATA_DIR/debug.log $LOG_DIR/debug-{COMMIT}-$(date +%s).log" \ "COMPILER=$CC ./build/bin/bitcoind -datadir=$DATA_DIR -stopatheight=$STOP -dbcache=$DBCACHE -reindex-chainstate -blocksonly -connect=0 -printtoconsole=0"; done 595504a Merge #34236: Add sedited to trusted-keys 63e822b validation: make `IsInitialBlockDownload()` lock-free 2026-01-12 | reindex-chainstate | 931139 blocks | dbcache 4500 | i9-ssd | x86_64 | Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz | 16 cores | 62Gi RAM | SSD Benchmark 1: COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=931139 -dbcache=4500 -reindex-chainstate -blocksonly -connect=0 -printtoconsole=0 (COMMIT = 595504a) Time (abs ≡): 17187.310 s [User: 33104.415 s, System: 937.548 s] Benchmark 2: COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=931139 -dbcache=4500 -reindex-chainstate -blocksonly -connect=0 -printtoconsole=0 (COMMIT = 63e822b) Time (abs ≡): 17240.300 s [User: 33164.803 s, System: 976.485 s] Relative speed comparison 1.00 COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=931139 -dbcache=4500 -reindex-chainstate -blocksonly -connect=0 -printtoconsole=0 (COMMIT = 595504a) 1.00 COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=931139 -dbcache=4500 -reindex-chainstate -blocksonly -connect=0 -printtoconsole=0 (COMMIT = 63e822b) ``` </details> ACKs for top commit: sedited: ACK 557b41a sipa: utACK 557b41a mzumsande: Code Review ACK 557b41a Tree-SHA512: 174015b9785846fc3375bd9d6e4ef91de47ffb659a94d645c49d333a33a32986d5c3cb2eb5a0a7245f96580ed6fea4ba5b7f93cac7e42e3b225f0a01538a2e5c
… allocation 2845f10 test: extend FreeBSD ephemeral port range fix to P2P listeners (node) 34bed0e test: use IP_PORTRANGE_HIGH on FreeBSD for dynamic port allocation (woltx) Pull request description: Reopening #34336. I’ve now tested it on FreeBSD and confirmed it works. On FreeBSD, the default ephemeral port range (10000-65535) overlaps with the test framework's static port range (11000-26000), possibly causing intermittent "address already in use" failures when tests use dynamic port allocation (`port=0`). This PR adds a helper that sets `IP_PORTRANGE_HIGH` via `setsockopt()` before binding, requesting ports from 49152-65535 instead, which avoids the overlap, as suggested in #34331 (comment) by @maflcko . From FreeBSD's [sys/netinet/in.h](https://cgit.freebsd.org/src/tree/sys/netinet/in.h): ```c #define IP_PORTRANGE 19 #define IP_PORTRANGE_HIGH 1 #define IPPORT_EPHEMERALFIRST 10000 /* default range start */ #define IPPORT_HIFIRSTAUTO 49152 /* high range start */ ``` See also: FreeBSD https://man.freebsd.org/cgi/man.cgi?query=ip&sektion=4 man page. Fixes #34331 ACKs for top commit: vasild: ACK 2845f10 hebasto: ACK 2845f10, I have reviewed the code and it looks OK. Tree-SHA512: ce501ce3e8a4023e07bad572df2b85d6829becf133813e4529aebba83e4eba59fa8b48e9d2197ebbb226adaf3054fad720775a787244d6b38c0078ee086102f4
Use the AFL++ shared memory ID environment variable to create a deterministic datadir path. This prevents accumulation of stale directories after a fuzz iteration crashes or times out. During long fuzz campaigns, this accumulation has occasionally resulted in running out of disk space.
Add a Reset() method to CCoinsViewCache that clears cacheCoins, cachedCoinsUsage, and hashBlock without flushing to the base view. Co-authored-by: l0rinc <pap.lorinc@gmail.com> Co-authored-by: sedited <seb.kung@gmail.com>
Co-authored-by: l0rinc <pap.lorinc@gmail.com>
CCoinsViewCache::CreateResetGuard returns a guard that calls Reset on the cache when the guard goes out of scope. This RAII pattern ensures the cache is always properly reset when it leaves current scope. Co-authored-by: l0rinc <pap.lorinc@gmail.com> Co-authored-by: sedited <seb.kung@gmail.com>
Add m_connect_block_view to ChainState's CoinsViews. Call CreateResetGuard inside ConnectTip to ensure the view is Reset after each block, avoiding repeated memory allocations. Co-authored-by: l0rinc <pap.lorinc@gmail.com>
More accurately reflects the purpose of the parameter, since we will keep reusing the cache but don't want to reallocate it.
…shots c6ca2b8 validation: do not wipe utxo cache for stats/scans/snapshots (Pieter Wuille) 7099e93 refactor: rename `FlushStateMode::ALWAYS` to `FORCE_FLUSH` (Lőrinc) Pull request description: Revival of #30610 (comment) with the remaining comments applied on top > Since #28280, the cost of a non-wiping sync of the UTXO cache is only proportional to the number of dirty entries, rather than proportional to the size of the entire cache. Because of that, there is no reason to perform a wiping flush in case the contents of the cache is still useful. > > Split the `FlushStateMode::ALWAYS` mode into a FORCE_SYNC (non-wiping) and a FORCE_FLUSH (wiping), and then use the former in `scantxoutset`, `gettxoutsetinfo`, snapshot creation. (slightly updated after #30214) ACKs for top commit: optout21: reACK c6ca2b8 cedwies: reACK c6ca2b8 (trivial) achow101: ACK c6ca2b8 sedited: ACK c6ca2b8 Tree-SHA512: f3525a85dc512db4a0a9c749ad47c0d3fa44085a121aa54cd77646260a719c71f754ec6570ae77779c0ed68a24799116f79c686e7a17ce57a26f6a598f7bf926
3e0fd0e refactor: rename will_reuse_cache to reallocate_cache (Andrew Toth) 44b4ee1 validation: reuse same CCoinsViewCache for every ConnectBlock call (Andrew Toth) 8fb6043 coins: introduce CCoinsViewCache::ResetGuard (Andrew Toth) 041758f coins: use hashBlock setter internally for CCoinsViewCache methods (Andrew Toth) 8dd9200 coins: add Reset on CCoinsViewCache (Andrew Toth) Pull request description: This is the first commit of #31132, which can be merged as an independent change. It has a small benefit on its own, but will help in moving the parent PR forward. Add a `Reset()` method to `CCoinsViewCache` that clears `cacheCoins`, `cachedCoinsUsage`, and `hashBlock` without flushing to the `base` view. This allows efficiently reusing a cache instance across multiple blocks. Add `CCoinsViewCache::CreateResetGuard` method to return a `CCoinsViewCache::ResetGuard`. The `ResetGuard` automatically calls `Reset()` on destruction. This RAII pattern ensures the cache is always properly reset between blocks. Add `m_connect_block_view` as a persistent `CCoinsViewCache` for `ConnectBlock`, avoiding repeated memory allocations. ACKs for top commit: l0rinc: ACK 3e0fd0e achow101: ACK 3e0fd0e sedited: ACK 3e0fd0e Tree-SHA512: a95feaa062a9eb7cf7514425a7e7adffd347cd1f7b32b4c1fefcde30002141757c184174702b3104a029dcd33194f8bd734159deebb2e668716089305b42cb00
…block after assumeutxo validation 7d9e1a8 test: Verify peer usage after assumeutxo validation completes (stringintech) 0067abe p2p: Allow block downloads from peers without snapshot block after assumeutxo validation (stringintech) Pull request description: Currently, after assumeutxo background validation finishes, the node continues to skip peers that don't have the snapshot block in their best chain until restart. This unnecessarily excludes peers from block downloads even though the background sync has completed and undo data is available. The restriction persists because `m_chainman.CurrentChainstate().SnapshotBase()` continues to return the snapshot base block until restart, even after validation completes. Added `m_chainman.CurrentChainstate().m_assumeutxo == Assumeutxo::UNVALIDATED` check to only apply the peer restriction while background validation is ongoing. Also added test coverage in `feature_assumeutxo.py` that verifies peers without the snapshot block can be used for block downloads after background validation completes. The test fails without this fix. ACKs for top commit: fjahr: Re-ACK 7d9e1a8 achow101: ACK 7d9e1a8 sedited: Re-ACK 7d9e1a8 Tree-SHA512: 5515971da7bf7efc55eecdf03686f44c20c9e52dd168e7cfa119032d6a8ebccee69df7143075e4e9d0a01426cd9ae7202dce5c00919a82478ebf49a15dc0fe19
fad2876 ci: Always print low ccache hit rate notice (MarcoFalke) Pull request description: Looks like the hit rate is low, even on test changes such as https://github.com/bitcoin/bitcoin/actions/runs/21476546461/job/61867393974#step:10:3349 to make it easier to debug, unconditionally print the low hit rate notice ACKs for top commit: l0rinc: ACK fad2876 sedited: ACK fad2876 Tree-SHA512: 0cd85e3572e8465ec424766b1fdb6181d7e607cae991889b46cc66e5f08354772b6040a9f14c0864d36e1f38894628819a3a7458d3ec9ea32e063257177740a0
fafdae4 test: Check that redundant verack message is ignored (MarcoFalke) Pull request description: The code exists and is uncovered (ref https://maflcko.github.io/b-c-cov/total.coverage/src/net_processing.cpp.gcov.html#L3795), so add a trivial test to cover it. ACKs for top commit: brunoerg: ACK fafdae4 sedited: ACK fafdae4 Tree-SHA512: 157f434c2faa16243890b2344c4ee36bc359e56c80ba8a04f0bba71e9760cf9106c38ed755ff57eff8d1957f35516d20b3d010e0ecb8633b845f5314cc0d050a
d3e681b fuzz: Use `__AFL_SHM_ID` for naming test directories (marcofleon) Pull request description: During long multicore fuzzing campaigns with AFL++, stale datadirs can eventually accumulate from time outs, resulting in disk running out of space (see #28811). The easiest way to reproduce this is by running our `utxo_total_supply` target using multiple cores with AFL++ and observing the crashes that occur because of all the directories in `/tmp/test_common\ bitcoin/utxo_total_supply/`. Fix this by using the AFL++ shared memory ID to name the test dirs and cleaning it up before each setup. This ID is unique per AFL++ instance, so multiple cores can run in parallel without conflicts. Fixes #28811 ACKs for top commit: maflcko: lgtm ACK d3e681b dergoegge: utACK d3e681b Tree-SHA512: 420373e5f8a63c84797303ba2ef6657dfe9dacf9c2f3d818524421c24681a0e984c212ecb706217d93f67c2ec16b146a2d37fddcbd6918b2e5e9f634f5e13c10
4fab35c miniscript: correct and_v() properties (Antoine Poinsot) Pull request description: `and_v()` must never be 'd'. This is not a bug fix since this was unreachable in valid Miniscripts: the first sub of an `and_v()` must be of type V, which conflicts with (i.e. never has) property 'd'. ACKs for top commit: sipa: ACK 4fab35c. Fuzzed for 2 months worth of CPU time. achow101: ACK 4fab35c Tree-SHA512: 8932ad2c9188747299cb9147ff097dca8d078ce7bdd0caefa71ee2724ff81d9bef836664211c2081519a45afd50c539974d67c2a3a1a42a65a3b10b1daef8cbe
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.