Open
Conversation
Introduce `TrySub(T&, U)` which subtracts an unsigned integral `U` from an unsigned integral `T`, returning `false` on underflow.
Use with `Assume(TrySub(...))` at coins cache accounting decrement sites so invariant violations fail immediately rather than silently wrapping.
Co-authored-by: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
Co-authored-by: Pieter Wuille <pieter@wuille.net>
In validation, `AddCoins(check_for_overwrite=false)` is only used after BIP30 has already ensured the transaction does not overwrite any unspent outputs in the UTXO view. The coins view fuzz target can call `AddCoins` with arbitrary txids, so using the `check_for_overwrite=false` fast path on non-coinbase transactions may violate the `AddCoin` caller contract and trigger logic errors. Only use `check_for_overwrite=false` when we have first confirmed that none of the outputs are currently unspent. Otherwise, fall back to `check_for_overwrite=true` so `AddCoins` determines overwrites via the view.
The coins view fuzzer can call `AddCoin` with `possible_overwrite=false` for an outpoint that already exists unspent in the view, which violates the `AddCoin` caller contract. Derive `possible_overwrite` from `PeekCoin` so `possible_overwrite=false` is only used when the outpoint is absent. This matches the approach used by the `coinscache_sim` fuzzer, which derives the overwrite flag from simulated state.
Modify fuzzer logic to avoid setting `FRESH` for an outpoint that already exists unspent in the parent view, and ensure `FRESH` implies `DIRTY`. This keeps cursor invariants realistic and lets `BatchWrite` failures expose real bugs without resetting state.
a9e59f7 rpc: add optimal result to getmempoolinfo (Greg Sanders) a3fb3dd mempool: log if we detect a non-optimal mempool (Greg Sanders) Pull request description: Post-SFL #34023 I don't think we expect the mempool to be unordered for long periods of time. If we consider it likely to be a serious regression in production, it would be useful to expose the fact that the mempool is not known to be optimal. 1. do a MEMPOOL log after any `DoWork()` returns false, meaning non-optimal 2. expose it via getmempoolinfo, by calling `DoWork(0)`, which does nothing but return known-optimality I'm not wedded to either approach, I just think something is better than nothing for the next release. ACKs for top commit: ajtowns: ACK a9e59f7 ismaelsadeeq: reACK a9e59f7 [c89b93b..a9e59f7](https://github.com/bitcoin/bitcoin/compare/c89b93b9584f09401f9740061fdb6e4036f6dbbf..a9e59f7d955f995078b3e0bf3b527c03c74fef8d) fixed typo, added more logging for block/reorg additions to mempool, and fixed brittle test case. sedited: ACK a9e59f7 sipa: ACK a9e59f7 Tree-SHA512: 1560ad21cc1606df7279c102f35f61d4555c0ac920f02208b2a6eb89b14d7e22befb6d7f510a00a9074c2f9931f32e9af86bcea3a8dd9a1d947b0398c84666dd
c462e54 test: don't always assert NUM_PRIVATE_BROADCAST_PER_TX broadcasts (Vasil Dimov) 3710566 test: move abortprivatebroadcast test at the end (Vasil Dimov) Pull request description: _test: move abortprivatebroadcast test at the end_ The piece of `p2p_private_broadcast.py` which tests the correctness of `abortprivatebroadcast` issues a new `sendrawtransaction` call. That call schedules up to 3 new connections: peer=13, peer=14 and possibly peer=15 before it gets aborted. These up to 3 in-the-process-of-opening private broadcast connections have `CNode::m_connected` set early - when the `CNode` object is created. Later in the test the mock time is advanced by 20 minutes and those "old" connections pick a transaction for rebroadcast but that triggers `PRIVATE_BROADCAST_MAX_CONNECTION_LIFETIME` immediately: ``` 2026-02-21T13:28:14.209766Z [privbcast] [net.cpp:4006] [CNode] [net] Added connection peer=20 2026-02-21T13:28:14.309792Z (mocktime: 2026-02-21T13:48:14Z) [msghand] [net.cpp:4074] [PushMessage] [net] sending inv (37 bytes) peer=20 2026-02-21T13:28:14.309801Z (mocktime: 2026-02-21T13:48:14Z) [msghand] [net_processing.cpp:5745] [SendMessages] [privatebroadcast] Disconnecting: did not complete the transaction send within 180 seconds, peer=20 ``` This prematurely stops the private broadcast connection and results in a failure like: ``` AssertionError: ... not({} == {'ping': 1, 'tx': 1}) ``` --- _test: don't always assert NUM_PRIVATE_BROADCAST_PER_TX broadcasts_ In `p2p_private_broadcast.py` in the function `check_broadcasts()` we should assert that the broadcast was done to `broadcasts_to_expect` peers, not to `NUM_PRIVATE_BROADCAST_PER_TX`. This is because in the "Basic" test we check the first broadcast manually because it is done to `nodes[1]` and then check the other two by `check_broadcasts(..., NUM_PRIVATE_BROADCAST_PER_TX - 1, ...)`. The first broadcast might not have fully concluded by the time we call `check_broadcasts()` to check the remaining 2. Demanding always `NUM_PRIVATE_BROADCAST_PER_TX` can lead to: ``` Traceback (most recent call last): File "/home/vd/gh/bitcoin/bitcoin/test/functional/test_framework/test_framework.py", line 142, in main self.run_test() ~~~~~~~~~~~~~^^ File "/tmp/build/clang22/test/functional/p2p_private_broadcast.py", line 347, in run_test self.check_broadcasts("Basic", txs[0], NUM_PRIVATE_BROADCAST_PER_TX - 1, NUM_INITIAL_CONNECTIONS + 1) ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/tmp/build/clang22/test/functional/p2p_private_broadcast.py", line 313, in check_broadcasts assert_greater_than_or_equal(sum(1 for p in peers if "received" in p), NUM_PRIVATE_BROADCAST_PER_TX) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/vd/gh/bitcoin/bitcoin/test/functional/test_framework/util.py", line 94, in assert_greater_than_or_equal raise AssertionError("%s < %s" % (str(thing1), str(thing2))) AssertionError: 2 < 3 ``` ACKs for top commit: l0rinc: ACK c462e54 achow101: ACK c462e54 andrewtoth: ACK c462e54 Tree-SHA512: 0de8d0eae079eeedc3bfad39df8129a8fa0d7734bdc03b4fb3e520a2f13a187d68118ffc210556af125d634f0ff51a1b081b34a023ac68a1c6a0caf541cecb91
…ter IBD fcaec25 doc: release note for IPC cooldown and interrupt (Sjors Provoost) 1e82fa4 mining: add interrupt() (Sjors Provoost) a11297a mining: add cooldown argument to createNewBlock() (Sjors Provoost) Pull request description: As reported in #33994, connected mining clients will receive a flood of new templates if the node is still going through IBD or catching up on the last 24 hours. This PR fixes that using an _optional_ cooldown mechanism, only applied to `createNewBlock()`. First, cooldown waits for IBD. Then, as the tip keeps moving forward, it waits a few seconds to see if the tip updated. If so, it restarts the timer and waits again. The trade-offs for this mechanism are explained below. Because this PR changes `createNewBlock()` from a method that returns quickly to one that can block for minutes, we rely on #34568 to fix a bug in our `.capnp` definition, adding the missing `context` to `createNewBlock` (and `checkBlock`). The second commit then adds an `interrupt()` method so that clients can cleanly disconnect. --- ## Rationale The cooldown argument is optional, and not used by internal non-IPC code, for two reasons: 1. The mechanism wreaks havoc on the functional test suite, which would require very careful mock time handling to work around. But that's pointless, because only IPC clients need it. 2. It needs to be optional for IPC clients too, because in some situations, like a signet with only one miner, waiting for IBD can mean being stuck forever. The reason it's only applied to `createNewBlock()` is that this is the first method called by clients; `waitNext()` is a method on the interface returned by `createNewBlock()`, at which point the cooldown is done. After IBD, we wait N seconds if the header is N blocks ahead of the tip, with a minimum of 3 and a maximum of 20 seconds. The minimum waiting time is short enough that it shouldn't be annoying or confusing for someone manually starting up a client. While the maximum should be harmless if it happens spuriously (which it shouldn't). If the minimum wait is too short, clients get a burst of templates, as observed in the original issue. We can't entirely rule this out without a lot of additional complexity (like scanning our own log file for heuristics). This PR should make it a lot less likely, and thanks to the IBD wait also limit it to one day worth of blocks (`-maxtipage`). Some test runs on an M4 MacBook Pro, where I had a node catch up on the last few days worth of blocks: <img width="872" height="972" alt="Schermafbeelding 2026-02-04 om 18 21 17" src="https://github.com/user-attachments/assets/7902a0f2-0e0b-4604-9688-cec2da073261" /> As the chart shows, sometimes it takes longer than 3 seconds. But it turns out that in all those cases there were quite a few headers ahead of the tip. It also demonstrates that it's important to first wait for IBD, because it's less likely a random tip update takes longer than 20 seconds. - modified sv2-apps: https://github.com/Sjors/sv2-apps/tree/2026/02/cooldown - test script: https://gist.github.com/Sjors/feb6122c97acc2b9e6d66b168614609c#file-run_mainnet_pool_loop-zsh - chart script: https://gist.github.com/Sjors/feb6122c97acc2b9e6d66b168614609c#file-tip_interval_charts-py ACKs for top commit: ryanofsky: Code review ACK fcaec25. Only changes since last review were removing two cooldown arguments from the mining IPC test to simplify it enirox001: ACK fcaec25 Tree-SHA512: 08b75470f7c5c80a583a2fdb918fad145e7d5377309e5c599f67fc0d0e3139d09881067ba50c74114f117e69da17ee50666838259491691c031b1feaf050853f
Prior to this commit, tool_bitcoin.py was failing:
```sh
$ ./bld-cmake/test/functional/tool_bitcoin.py --valgrind
TestFramework (ERROR): Unexpected exception
Traceback (most recent call last):
File "./test/functional/test_framework/test_framework.py", line 138, in main
self.setup()
~~~~~~~~~~^^
File "./test/functional/test_framework/test_framework.py", line 269, in setup
self.setup_network()
~~~~~~~~~~~~~~~~~~^^
File "./test/functional/tool_bitcoin.py", line 38, in setup_network
assert all(node.args[:len(node_argv)] == node_argv for node in self.nodes)
~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
```
This commit fixes this issue by running `bitcoin` under valgrind. Also,
it comes with other improvements:
* Drop the outdated valgrind 3.14 requirement, because there is no
distro that ships a version that old anymore.
* Drop the VALGRIND_SUPPRESSIONS_FILE env var handling, because it was
presumably never used since it was introduced. Also, the use-case
seems limited.
Review note:
The set_cmd_args was ignoring the --valgrind test option.
In theory, this could be fixed by refactoring Binaries::node_argv() to
be used here. However, for now, just re-implement the node_argv logic in
set_cmd_args to prepend the valgrind cmd.
The error was added in commit 1ea7e45, because there was an additional confusing `AssertionError: [node 0] Error: no RPC connection` instead of just a single `FileNotFoundError: [Errno 2] No such file or directory`. This is no longer needed on current master. Also, the test is incomplete, because it was just checking bitcoind and bitcoin-cli, not any other missing binaries. Also, after the previous commit, it would not work in combination with --valgrind. Instead of trying to make it complete, and work in all combinations, just remove it, because the already existing error will be clear in any case. This can be tested via: ```sh ./test/get_previous_releases.py mv releases releases_backup # Confirm the test is skipped due to missing releases ./bld-cmake/test/functional/wallet_migration.py # Confirm the test fails due to missing releases ./bld-cmake/test/functional/wallet_migration.py --previous-releases mv releases_backup releases mv ./releases/v28.2 ./releases/v28.2_backup # Confirm the test fails with a single FileNotFoundError ./bld-cmake/test/functional/wallet_migration.py mv ./releases/v28.2_backup ./releases/v28.2 # Confirm the test runs and passes ./bld-cmake/test/functional/wallet_migration.py rm ./bld-cmake/bin/bitcoind # Confirm the test fails with a single "No such file or directory", # testing with and without --valgrind ./bld-cmake/test/functional/wallet_migration.py ./bld-cmake/test/functional/wallet_migration.py --valgrind ```
a28eedb ci: use LLVM 22 in sanitizer tasks (fanquake) Pull request description: Clang/LLVM 22 is out, and upstream apt issues seem to be resolved. Use it in the sanitizer related tasks in CI. Not changing tidy here (needs more changes). ACKs for top commit: maflcko: lgtm ACK a28eedb hebasto: ACK a28eedb. Tree-SHA512: 311cca7d1ebc5769812e63c1946e8bad1bd2da728bfe3a4b91182eca8c9a9036f7506aff4ea99665982f57c14e4523b674a8689a2390e30936c16ae2548bc759
There's no change in behavior. This is just a refactoring to avoid a minor layer violation in init code. The node.init object is intended to return interface pointers for code outside the node (like wallet and gui code), not used by node itself to initialize its internal state. (Motivation for this change is to introduce a MakeMining wait_loaded option in an upcoming commit that can only be used internally and not set by external clients.)
The index is now initialized after the setup phase (chain generation and txs creation), since it doesn't participate on it at all. This improves readability and splits setup from what we actually want to check. This also adds a check after Sync() to verify the index best block hash matches the tip, so we know it fully synced before checking the processed data. This will help catching errors as Sync() could have aborted prematurely. As a happy side effect, the SyncWithValidationInterfaceQueue() call at the end of the test is no longer needed and has been removed.
This parametrizes the cost model for the SFL algorithm with another class. Right now, the behavior of that class matches the naive cost model so far, but it will be replaced with a more advanced on in a future commit. The reason for abstracting this out is that it makes benchmarking for creating such cost models easy, by instantiating the cost model class with one that tracks time.
Instead of having the InitAndLoadChainstate function delete and create the KernelNotifications object each time it is called (it can be called twice when reindexing) to clear cached state, create it just one time and add a setChainstateLoaded() method to manage state as it is loaded and unloaded. This refactoring should make sense by itself to be more explicit about how KernelNotifications state is cleared, but it's also needed to make outside code accessing KernelNotifications state (currently just mining code) safe during node startup and shutdown so the KernelNofications mutex can be used for synchronization and does not get recreated itself.
…early startup This fixes ``Assertion `m_node.chainman' failed`` errors first reported #33994 (comment) when IPC mining methods are called before ChainstateManager is loaded. The fix works by making the `Init.makeMining` method block until chainstate data is loaded.
See the comments for the SFLDefaultCostModel class for details on how the numbers were obtained.
e8f8b74 test: index, improve txospenderindex_initial_sync() test code (furszy) ac3bea0 test: improve rpc_gettxspendingprevout.py code (furszy) Pull request description: Fixes #34637. Was reviewing #34637 and, while reading the new txospender index test code for the first time, found it could use some cleanups. Finding stuff in there is harder than it should be due to the amount of dup code. The first commit cleans up `rpc_gettxspendingprevout.py` by introducing helper functions to avoid repeating the same dicts everywhere, using for-loops instead of duplicating the same checks for each node, and renaming variables to better reflect what they actually represent. The second commit reorganizes `txospenderindex_initial_sync()` moving index initialization after the test setup phase, since the index doesn't participate in it anyway. It adds a post-sync check to catch cases where `Sync()` aborted prematurely. Note: This is just a pre-work for deeper index changes I'm cooking. ACKs for top commit: achow101: ACK e8f8b74 sedited: Re-ACK e8f8b74 w0xlt: reACK e8f8b74 Tree-SHA512: 3f7026712ab20a43f376afa28c683dcd5daec8ed1bbf1c36d7ec6bbf231f468d4de74efae4aa8295ff3afb83986286ccaf31c03b34e45fc9971652f064791ed0
c86bce5 guix: use a temporary file over sponge (fanquake) Pull request description: Remove sponge (moreutils). ACKs for top commit: davidgumberg: crACK c86bce5 janb84: crACK c86bce5 sedited: Nice, ACK c86bce5 Tree-SHA512: 2a2041a70d3636452317126145332a7c24d3a6f3f5db107cdd2467a8afa7c35e0148fed6e02f0a5b78507e44db13ed1ed944501c2e4e04b9fd6a95ea04f12ea4
No-behavior change.
Stop() has two windows where Start() could cause troubles: 1) m_workers is temporarily empty while workers are being joined, this creates a window where Start() could slip through and reset m_interrupt to false, preventing the old workers from exiting and causing a deadlock. 2) Start() could be called after workers are joined but before the empty() sanity check on m_work_queue, causing a crash. Fix both races by keeping m_interrupt set for the entire duration of Stop(), so any concurrent Start() call is rejected until all workers have exited. Co-authored-by: Hodlinator <172445034+hodlinator@users.noreply.github.com>
…gument 50cf683 wallet: rpc: manpage: fix example missing `fee_rate` argument (SomberNight) Pull request description: The function signature for the `send` RPC is: ``` send [{"address":amount,...},{"data":"hex"},...] ( conf_target "estimate_mode" fee_rate options version ) ``` The last example in the manpage is missing the `fee_rate` arg, but is trying to specify the `options` arg, by index. The parser confuses the intended `options` arg as the missing `fee_rate` arg. See: ``` $ bitcoin-cli -rpcuser=doggman -rpcpassword=donkey -rpcport=18554 -regtest send '{"bcrt1qusm48zmlzwr32csxdw4ar7atw260h22c9ten9l": 0.1}' 1 economical '{"add_to_wallet": false, "inputs": [{"txid":"0b7e1a471dc948b7a6187936b16e6d7d9833629b2f9dd8a392eb89928f63aaad", "vout":0}]}' error code: -8 error message: Cannot specify both conf_target and fee_rate. Please provide either a confirmation target in blocks for automatic fee estimation, or an explicit fee rate. ``` vs ``` $ bitcoin-cli -rpcuser=doggman -rpcpassword=donkey -rpcport=18554 -regtest send '{"bcrt1qusm48zmlzwr32csxdw4ar7atw260h22c9ten9l": 0.1}' 1 economical null '{"add_to_wallet": false, "inputs": [{"txid":"0b7e1a471dc948b7a6187936b16e6d7d9833629b2f9dd8a392eb89928f63aaad", "vout":0}]}' { "psbt": "cHNidP8BAHECAAAAAa2qY4+SieuSo9idL5tiM5h9bW6xNnkYprdIyR1HGn4LAAAAAAD9////AkR2DwQAAAAAFgAUpLDwJu+wFRHLQAgKAb0psk7UVd2AlpgAAAAAABYAFOQ3U4t/E4cVYgZrq9H7q3K0+6lYAAAAAAABAIUCAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wQC4wMA/////wLIF6gEAAAAABYAFLMY1zihXrefAA0DA5nld4MCPjkrAAAAAAAAAAAmaiSqIant4vYcP3HR3v0/qZnfo2lTdVxpBol5mWK0i+vYNpdOjPkAAAAAAQEfyBeoBAAAAAAWABSzGNc4oV63nwANAwOZ5XeDAj45KwEIawJHMEQCIElTV4pbUrsPR9qHWcioowVv3QVWHizxwevfD0u/I8YyAiBCY3OzF81PSLM00h4ueQkehYuxDFZu7Jk51iejphKnnwEhA0VKdYVSyBpWoxBwTDOupB58Fi3mEBs+u+OOqEYVd2sZACICA98YLWyH7dBCfXVxe7woiLSTgV1mJN8Zc8KgZ77pVSg+GNBMeT5UAACAAQAAgAAAAIABAAAAbAAAAAAA", "txid": "625b71b314a6ac4f738634e29dc007cd5edc0427c1ae96ab706d06a62910cea2", "hex": "02000000000101adaa638f9289eb92a3d89d2f9b6233987d6d6eb1367918a6b748c91d471a7e0b0000000000fdffffff0244760f0400000000160014a4b0f026efb01511cb40080a01bd29b24ed455dd8096980000000000160014e437538b7f13871562066babd1fbab72b4fba9580247304402204953578a5b52bb0f47da8759c8a8a3056fdd05561e2cf1c1ebdf0f4bbf23c6320220426373b317cd4f48b334d21e2e79091e858bb10c566eec9939d627a3a612a79f012103454a758552c81a56a310704c33aea41e7c162de6101b3ebbe38ea84615776b1900000000", "complete": true } ``` ACKs for top commit: svanstaa: tACK 50cf683 kannapoix: Tested ACK 50cf683 achow101: ACK 50cf683 rkrux: tACK 50cf683 theStack: Tested ACK 50cf683 Tree-SHA512: 499701729038cd863b612698098a73ce995589fc5ab08a2962f8edf1ff3cb3de6f7090e04722ca13ba7707a566fa3750ae549b6ad55750a3d01127eb6b94a79f
5cd5794 test: verify node state after restart in assumeutxo (Yash Bhutwala) Pull request description: ## Summary This PR replaces the TODO comment in `wallet_assumeutxo.py` (line 242) with actual test assertions that verify node and wallet behavior after a restart during assumeutxo background sync. ## Changes The new tests verify: - Two chainstates exist (background validation not complete) - Background chainstate is still at `START_HEIGHT` - Snapshot chainstate has synced to at least `PAUSE_HEIGHT` - Wallets cannot be loaded after restart (expected behavior) - Wallet backup from before snapshot height cannot be restored ## Motivation During implementation, I discovered that **wallets cannot be loaded after a node restart during assumeutxo background sync**. This is expected behavior because: - The wallet loading code checks if required blocks are available for rescanning - During assumeutxo background sync, blocks before the snapshot are not available - This applies to all wallets, including watch-only wallets created at the snapshot height This is a valuable test addition because it documents this expected behavior and ensures it doesn't regress. Users should be aware that if they restart their node during assumeutxo background sync, they won't be able to load their wallets until the background sync completes. ## Related refs #28648 Addresses the TODO comment that was originally added as part of the assumeutxo wallet test implementation. ACKs for top commit: Bicaru20: Code review ACK 5cd5794 achow101: ACK 5cd5794 fjahr: ACK 5cd5794 sedited: ACK 5cd5794 polespinasa: code lgtm ACK 5cd5794 Tree-SHA512: 4a125c5247168da2bbf4d855b4150ca453bb5e4cce1a62e633ce5e43acdc2c58883a6a94dcc46b38f8b4c44206fe42cec4db151a76aded53d8ea433ea5eb2562
3281824 fuzz: prevent invalid `FRESH` entries and surface `BatchWrite` errors (Lőrinc) 780f460 fuzz: avoid invalid `AddCoin` overwrites (Lőrinc) d7e0d51 fuzz: make `AddCoins` query view for overwrites (Lőrinc) b8fa6f0 util: introduce `TrySub` to prevent unsigned underflow (Lőrinc) Pull request description: ### Problem This is an alternative approach to #34647, fixes #34645. ### Fix First, add `CheckedSub` and use it for decrements of `m_dirty_count` and `cachedCoinsUsage`, so unsigned underflows turn into immediate failures instead of silently wrapping and only failing later. <details><summary>Assertion `j <= i' failed.</summary> ```bash util/overflow.h:44 T CheckedSub(const T, const U) [T = unsigned long, U = bool]: Assertion `j <= i' failed. ==72817== ERROR: libFuzzer: deadly signal #0 0x556e9225eab5 in __sanitizer_print_stack_trace (/mnt/my_storage/bitcoin/build_fuzz/bin/fuzz+0x191dab5) (BuildId: d77c4d5f9dfd38ea06fab463f49341735205e109) #1 0x556e921acafc in fuzzer::PrintStackTrace() (/mnt/my_storage/bitcoin/build_fuzz/bin/fuzz+0x186bafc) (BuildId: d77c4d5f9dfd38ea06fab463f49341735205e109) #2 0x556e92191bb7 in fuzzer::Fuzzer::CrashCallback() (/mnt/my_storage/bitcoin/build_fuzz/bin/fuzz+0x1850bb7) (BuildId: d77c4d5f9dfd38ea06fab463f49341735205e109) #3 0x7164cfc458cf (/lib/x86_64-linux-gnu/libc.so.6+0x458cf) (BuildId: ae7440bbdce614e0e79280c3b2e45b1df44e639c) #4 0x7164cfca49bb in __pthread_kill_implementation nptl/pthread_kill.c:43:17 #5 0x7164cfca49bb in __pthread_kill_internal nptl/pthread_kill.c:89:10 #6 0x7164cfca49bb in pthread_kill nptl/pthread_kill.c:100:10 #7 0x7164cfc4579d in raise signal/../sysdeps/posix/raise.c:26:13 #8 0x7164cfc288cc in abort stdlib/abort.c:73:3 #9 0x556e92f9d591 in assertion_fail(std::source_location const&, std::basic_string_view<char, std::char_traits<char>>) /mnt/my_storage/bitcoin/src/util/check.cpp:41:5 #10 0x556e9250daf0 in bool&& inline_assertion_check<false, bool>(bool&&, std::source_location const&, std::basic_string_view<char, std::char_traits<char>>) /mnt/my_storage/bitcoin/src/util/check.h:90:13 #11 0x556e9250daf0 in unsigned long CheckedSub<unsigned long, bool>(unsigned long, bool) /mnt/my_storage/bitcoin/src/util/overflow.h:44:5 #12 0x556e9250daf0 in CoinsViewCacheCursor::NextAndMaybeErase(std::pair<COutPoint const, CCoinsCacheEntry>&) /mnt/my_storage/bitcoin/src/coins.h:282:25 #13 0x556e92507eb2 in (anonymous namespace)::MutationGuardCoinsViewCache::BatchWrite(CoinsViewCacheCursor&, uint256 const&) /mnt/my_storage/bitcoin/src/test/fuzz/coins_view.cpp:90:75 #14 0x556e92c17a2b in CCoinsViewCache::Flush(bool) /mnt/my_storage/bitcoin/src/coins.cpp:282:11 #15 0x556e924fb732 in TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_1::operator()() const /mnt/my_storage/bitcoin/src/test/fuzz/coins_view.cpp:135:34 #16 0x556e924fb732 in unsigned long CallOneOf<TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_0, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_1, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_2, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_3, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_4, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_5, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_6, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_7, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_8, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_9, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_10, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_11>(FuzzedDataProvider&, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_0, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_1, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_2, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_3, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_4, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_5, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_6, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_7, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_8, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_9, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_10, TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool)::$_11) /mnt/my_storage/bitcoin/src/test/fuzz/util.h:42:27 #17 0x556e924fb732 in TestCoinsView(FuzzedDataProvider&, CCoinsViewCache&, CCoinsView&, bool) /mnt/my_storage/bitcoin/src/test/fuzz/coins_view.cpp:114:9 #18 0x556e92503b0c in coins_view_overlay_fuzz_target(std::span<unsigned char const, 18446744073709551615ul>) /mnt/my_storage/bitcoin/src/test/fuzz/coins_view.cpp:404:5 #19 0x556e92bcb7a5 in std::function<void (std::span<unsigned char const, 18446744073709551615ul>)>::operator()(std::span<unsigned char const, 18446744073709551615ul>) const /usr/lib/gcc/x86_64-linux-gnu/15/../../../../include/c++/15/bits/std_function.h:593:9 #20 0x556e92bcb7a5 in test_one_input(std::span<unsigned char const, 18446744073709551615ul>) /mnt/my_storage/bitcoin/src/test/fuzz/fuzz.cpp:88:5 #21 0x556e92bcb7a5 in LLVMFuzzerTestOneInput /mnt/my_storage/bitcoin/src/test/fuzz/fuzz.cpp:216:5 #22 0x556e9219318f in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/mnt/my_storage/bitcoin/build_fuzz/bin/fuzz+0x185218f) (BuildId: d77c4d5f9dfd38ea06fab463f49341735205e109) #23 0x556e92192799 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) (/mnt/my_storage/bitcoin/build_fuzz/bin/fuzz+0x1851799) (BuildId: d77c4d5f9dfd38ea06fab463f49341735205e109) #24 0x556e92194139 in fuzzer::Fuzzer::MutateAndTestOne() (/mnt/my_storage/bitcoin/build_fuzz/bin/fuzz+0x1853139) (BuildId: d77c4d5f9dfd38ea06fab463f49341735205e109) #25 0x556e92194c95 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) (/mnt/my_storage/bitcoin/build_fuzz/bin/fuzz+0x1853c95) (BuildId: d77c4d5f9dfd38ea06fab463f49341735205e109) #26 0x556e92181255 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/mnt/my_storage/bitcoin/build_fuzz/bin/fuzz+0x1840255) (BuildId: d77c4d5f9dfd38ea06fab463f49341735205e109) #27 0x556e921ad696 in main (/mnt/my_storage/bitcoin/build_fuzz/bin/fuzz+0x186c696) (BuildId: d77c4d5f9dfd38ea06fab463f49341735205e109) #28 0x7164cfc2a577 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #29 0x7164cfc2a63a in __libc_start_main csu/../csu/libc-start.c:360:3 #30 0x556e921757e4 in _start (/mnt/my_storage/bitcoin/build_fuzz/bin/fuzz+0x18347e4) (BuildId: d77c4d5f9dfd38ea06fab463f49341735205e109) NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal MS: 2 PersAutoDict-CopyPart- DE: "\005\000"-; base unit: ecb626aff8724f0fdde38a0a6965718f2096d474 artifact_prefix='/tmp/fuzz_artifacts/'; Test unit written to /tmp/fuzz_artifacts/crash-1d19026c1a23f08bfe693fd684a56ce51187c6e5 ./build_fuzz/bin/fuzz /tmp/fuzz_corpus/coins_view_overlay -max_total_time=3600 -rss_limit_mb=2560 -artifact_prefix=/tmp/fuzz_artifacts/ >fuzz-16.log 2>&1 ``` </details> The coins view fuzz targets can call `AddCoin`/`AddCoins` and construct `BatchWrite` cursors in ways that violate `CCoinsViewCache` caller contracts. These invalid states can trigger `BatchWrite` `std::logic_error` and can desync dirty-entry accounting (caught by `Assume(m_dirty_count == 0)` currently). Make the fuzzer avoid generating invalid states instead of catching and resetting: * Derive `AddCoin`’s `possible_overwrite` from `PeekCoin`, so `possible_overwrite=false` is only used when the outpoint is absent - similarly to https://github.com/bitcoin/bitcoin/blob/67c0d1798e6147f48d4bafc2c9e5ff30f2a62340/src/test/fuzz/coinscache_sim.cpp#L312-L317 - Only use `AddCoins(check=false)` when we have confirmed the txid has no unspent outputs; otherwise fall back to `check=true` so `AddCoins` determines overwrites via the view. - When constructing a `CoinsViewCacheCursor`, avoid setting `FRESH` when the parent already has an unspent coin, and ensure `FRESH` implies `DIRTY`. ### Fuzzing The original error could be reproduced in ~10 minutes using `coins_view_overlay`. I ran the `coins_view`, `coins_view_db`, `coins_view_overlay`, and `coinscache_sim` fuzzers for this PR overnight and they didn't fail anymore. ACKs for top commit: achow101: ACK 3281824 sipa: ACK 3281824. Ran the 4 relevant fuzz tests for ~1 CPU day each. Will run more overnight. andrewtoth: ACK 3281824 Tree-SHA512: b8155e8d21740eb7800e373c27a8a1457eb84468c24af879bac5a1ed251ade2aec99c34a350a31f2ebb74e41bb7380bf20214d38d14fe23310a43282d2434fb7
fa5d478 test: valgrind --trace-children=yes for bitcoin wrapper (MarcoFalke) fa29fb7 test: Remove redundant warning about missing binaries (MarcoFalke) fa03fbf test: Fix broken --valgrind handling after bitcoin wrapper (MarcoFalke) Pull request description: Currently, tool_bitcoin.py is failing under `--valgrind`: ```sh $ ./bld-cmake/test/functional/tool_bitcoin.py --valgrind TestFramework (ERROR): Unexpected exception Traceback (most recent call last): File "./test/functional/test_framework/test_framework.py", line 138, in main self.setup() ~~~~~~~~~~^^ File "./test/functional/test_framework/test_framework.py", line 269, in setup self.setup_network() ~~~~~~~~~~~~~~~~~~^^ File "./test/functional/tool_bitcoin.py", line 38, in setup_network assert all(node.args[:len(node_argv)] == node_argv for node in self.nodes) ~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AssertionError ``` Fix this issue by running `bitcoin` under valgrind. ACKs for top commit: achow101: ACK fa5d478 ryanofsky: Code review ACK fa5d478 just squashing commits since last review (Thanks!) Tree-SHA512: 503685ac69e1ca3046958655bed4fe6d0aee1525c5ea58ebf098efd0332c0e16f138540baffaf9af1263a8c42ac6b150ed8bca5a5371a3c49802e21957ec6632
744d47f clusterlin: adopt trained cost model (feature) (Pieter Wuille) 4eefdfc clusterlin: rescale costs (preparation) (Pieter Wuille) ecc9a84 clusterlin: use 'cost' terminology instead of 'iters' (refactor) (Pieter Wuille) 9e7129d clusterlin: introduce CostModel class (preparation) (Pieter Wuille) Pull request description: Part of #30289, replaces earlier #34138. This introduces a more accurate cost model for SFL, to control how much CPU time is spent inside the algorithm for clusters that cannot be linearized perfectly within a reasonable amount of time. The goal is having a metric for the amount of work performed, so that txmempool can impose limits on that work: a lower bound that is always performed (unless optimality is reached before that point, of course), and an upper bound to limit the latency and total CPU time spent on this. There are conflicting design goals here: * On the one hand, it seems ideal if this metric is closely correlated to actual CPU time, because otherwise the limits become inaccurate. * On the other hand, it seems a nightmare to have the metric be platform/system dependent, as it makes network-wide reasoning nearly impossible. It's expected that slower systems take longer to do the same thing; this holds for everything, and we don't need to compensate for this. There are multiple solutions to this: * One extreme is just measuring the time. This is very accurate, but extremely platform dependent, and also non-deterministic due to random scheduling/cache effects. * The other extreme is using a very abstract metric like counting how many times certain loops/function inside the algorithm run. That is what is implemented in master right now, just counting the sum of the numbers of transactions updated across all `UpdateChunks()` calls. It however necessarily fails to account for significant portions of runtime spent elsewhere, resulting in a rather wide range of "ns per cost" values. * This PR takes a middle ground, counting many function calls / branches / loops, with weights that were determined through benchmarking on an average on a number of systems. Specifically, the cost model was obtained by: * For a variety of machines: * Running a fixed collection of ~385000 clusters found through random generation and fuzzing, optimizing for difficulty of linearization. * Linearize each 1000-5000 times, with different random seeds. Sometimes without input linearization, sometimes with a bad one. * Gather cycle counts for each of the operations included in this cost model, broken down by their parameters. * Correct the data by subtracting the runtime of obtaining the cycle count. * Drop the 5% top and bottom samples from each cycle count dataset, and compute the average of the remaining samples. * For each operation, fit a least-squares linear function approximation through the samples. * Rescale all machine expressions to make their total time match, as we only care about relative cost of each operation. * Take the per-operation average of operation expressions across all machines, to construct expressions for an average machine. * Approximate the result with integer coefficients. The benchmarks were performed by `l0rinc <pap.lorinc@gmail.com>` and myself, on AMD Ryzen 5950X, AMD Ryzen 7995WX, AMD Ryzen 9980X, Apple M4 Max, Intel Core i5-12500H, Intel Core Ultra 7 155H, Intel N150 (Umbrel), Intel Core i7-7700, Intel Core i9-9900K, Intel Haswell (VPS, virtualized), Intel Xeon E5-2637, ARM Cortex-A76 (Raspberry Pi 5), ARM Cortex-A72 (Raspberry Pi 4). Based on final benchmarking, the "acceptable" iteration count (which is the minimum spent on every cluster) is to 75000 units, which corresponds to roughly 50 μs on Ryzen 5950X and similar modern desktop hardware. ACKs for top commit: instagibbs: ACK 744d47f murchandamus: reACK 744d47f Tree-SHA512: 5cb37a6bdd930389937c435f910410c3581e53ce609b9b594a8dc89601e6fca6e6e26216e961acfe9540581f889c14bf289b6a08438a2d7adafd696fc81ff517
This allows external tooling (e.g. converters) to consume the output directly, rather than having to write the dump to disk first and then read it from there again. Co-authored-by: Luke Dashjr <luke-jr+git@utopios.org>
fadaa7d ci: Bump GHA actions versions (MarcoFalke) Pull request description: Looks like this was forgotten in the prior pull #34344 (comment) ACKs for top commit: fanquake: ACK fadaa7d Tree-SHA512: bc3bc5b7ba275d7c48bd34fa0eaaac05942212369fc87be338b31c024ca736550a5ff64766c78912f9705e9f95ffedeae1eddfe2f95828350c7672ab2069713c
This is the only non-void callback type, so it makes sense to document what implementers should return.
To work around #34810
… callback ec4ec91 kernel: doc: explain return value for `btck_WriteBytes` callback (Sebastian Falbesoner) Pull request description: Note that this is the only callback type with a non-void return type. Probably it would make sense to document the parameters of callbacks as well on the long-term (Doxygen style?), but this IMHO the most critical missing documentation, where likely other bitcoinkernel users working with the C API could trip over too. Background: I've been working on btck bindings for [Zig](https://ziglang.org/) for a while [1]. Overall I found the C API header `bitcoinkernel.h` very well-documented and to a large degree self-explanatory, but for implementing a `btck_WriteBytes` callback (needed for various `btck_..._to_bytes` serialization functions) I had to look into the [kernel implementation](https://github.com/bitcoin/bitcoin/blob/e98d36715eace5ee54a10f2931adcbbc5f6b0a15/src/kernel/bitcoinkernel.cpp#L86) to figure out what return value is expected. [1] still not public and put on hold for the last few months due to lib(std)c++ build system / linking issues (needing ugly workarounds, hopefully improved with Zig's upcoming 0.16 release); now continued, hopefully ready to be published in a first presentable version soon(tm) ACKs for top commit: sedited: ACK ec4ec91 alexanderwiederin: ACK ec4ec91 stickies-v: ACK ec4ec91 Tree-SHA512: aeea68474a04e0bc4d2421a0539a0bd717b0526f58c7379848a8bb8cb75a0fdf5c94bfcc226f28dd09b89c5fc368921d1d875893b86680e7c51d7b98f4ab749d
…` RPC and from node state 745ad94 p2p: remove m_starting_height field from node state (only show once in debug log) (Sebastian Falbesoner) b267efc rpc, net: completely remove `startingheight` field of `getpeerinfo` RPC (Sebastian Falbesoner) Pull request description: This PR completely removes the `startingheight` field in the `getpeerinfo` RPC, previously deprecated in v31.0 (see #34197). The second commit goes one step further: the only remaining usage for a `Peer`s `m_starting_height` field is for printing P2P debug messages. Considering that the information is untrusted and not deemed useful (see discussion #33990), remove the field and only print the starting height information once at reception of the `VERSION` message (suggested by ajtowns in #33990 (comment)), without saving it. ACKs for top commit: stickies-v: re-ACK 745ad94, no changes except for addressing minor merge conflict w0xlt: ACK 745ad94 sedited: Re-ACK 745ad94 Tree-SHA512: 09d30f34ea564e884e5d5c0e56cd66f99d6127ba8cc779f1e7ab29ea4fe8603835d306e343ee3a0038b1c07245f429012375034518135c915f543ba175d6dc45
b19caee doc: add release note for #31560 (named pipe support for `dumptxoutset` RPC) (Sebastian Falbesoner) 61a5460 test: add test for utxo-to-sqlite conversion using named pipe (Sebastian Falbesoner) 2e8072e rpc: support writing UTXO set dump (`dumptxoutset`) to a named pipe (Sebastian Falbesoner) Pull request description: This PR slightly modifies the `dumptxoutset` RPC to allow writing the UTXO set dump into a [named pipe](https://askubuntu.com/a/449192), so that the output data can be consumed by another process, see #31373. Taking use of this with the utxo-to-sqlite.py tool (introduced in #27432), creating an UTXO set in SQLite3 format is possible on the fly. E.g. for signet: ``` $ mkfifo /tmp/utxo_fifo && ./build/bin/bitcoin-cli -signet dumptxoutset /tmp/utxo_fifo latest & $ ./contrib/utxo-tools/utxo_to_sqlite.py /tmp/utxo_fifo ./utxo.sqlite UTXO Snapshot for Signet at block hash 000000012711f0a4e741be4a22792982..., contains 61848352 coins 1048576 coins converted [1.70%], 2.800s passed since start .... .... 60817408 coins converted [98.33%], 159.598s passed since start { "coins_written": 61848352, "base_hash": "000000012711f0a4e741be4a22792982370f51326db20fca955c7d45da97f768", "base_height": 294305, "path": "/tmp/utxo_fifo", "txoutset_hash": "34ae7fe7af33f58d4b83e00ecfc3b9605d927f154e7a94401226922f8e3f534e", "nchaintx": 28760852 } TOTAL: 61848352 coins written to ./utxo.sqlite, snapshot height is 294305. ``` Note that the `dumptxoutset` RPC calculates an UTXO set hash as a first step before any data is emitted, so especially on mainnet it takes quite a while until the conversion starts and something is happening visibly. ACKs for top commit: ajtowns: utACK b19caee sedited: Re-ACK b19caee Tree-SHA512: 7101563d0dba15439cdef8c8fb535f8593d5a779ff04208e2d72382a3f99072db8eac3651d1b3fe72c5e1f03e164efb281c3030d45d0723b943ebbbcf2a841d6
2f8f2e9 validation: remove ConnectTrace wrapper class (stickies-v) b83de7f validation: remove sentinel block from ConnectTrace (stickies-v) Pull request description: The sentinel pattern in `ConnectTrace` has been unnecessary since conflicted transaction tracking was removed in 5613f98. Without that tracking `ConnectTrace` is a trivial wrapper around `std::vector`, so it seems better to just replace it with the vector directly. Also modernize/update naming along the way, renaming `PerBlockConnectTrace` to `ConnectedBlock` Refactor, no behaviour change. ACKs for top commit: HowHsu: ACK 2f8f2e9 sedited: ACK 2f8f2e9 w0xlt: reACK 2f8f2e9 Tree-SHA512: 0045fcdc1178a160e31ef9d44dcd5fddd21c30c53ed06e84beacddb0b73e7b8120fee874256d1b9ceae45da65164a2e5531992bd374f8d57b6a8455a5354fe57
fa6497b build: Set AUTHOR_WARNING on warnings (MarcoFalke) Pull request description: Now that the cmake setting `-Werror=dev` is set since commit 6a13a61 for the CI, guix and the dev cmake preset, it could make sense to notify developers about any warnings. So do that with a single `AUTHOR_WARNING`. This can be tested by introducing a bug, like: ```diff diff --git a/CMakeLists.txt b/CMakeLists.txt index 6017775..5610e03c66 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -589,7 +589,7 @@ set(Python3_FIND_FRAMEWORK LAST CACHE STRING "") # improves compatibility with Python version managers that use shims. set(Python3_FIND_UNVERSIONED_NAMES FIRST CACHE STRING "") mark_as_advanced(Python3_FIND_FRAMEWORK Python3_FIND_UNVERSIONED_NAMES) -find_package(Python3 3.10 COMPONENTS Interpreter) +find_package(Python3 3.210 COMPONENTS Interpreter) if(NOT TARGET Python3::Interpreter) list(APPEND configure_warnings "Minimum required Python not found." ``` Fixes #31476. ACKs for top commit: l0rinc: ACK fa6497b purpleKarrot: ACK fa6497b stickies-v: ACK fa6497b hebasto: ACK fa6497b, this effectively allows us to use `-Werror=dev` to automatically catch any warning. sedited: ACK fa6497b Tree-SHA512: df3b7fa88451527d6a950bd6ebe46e96d1d2f6447c2b53cbe26c6ece0b63a41663a0accfc0ee20c03bc40328363d46f0e7ad88aab1be9b383ad7ff2621363a30
Co-authored-by: Matias Furszyfer <matiasfurszyfer@protonmail.com>
be6d24e guix: Make guix-clean less destructive (Hodlinator) Pull request description: * Show preview and ask for confirmation before git clean unless used with "--force" * Error out when user tries to pass args such as "guix-clean --help" ACKs for top commit: kevkevinpal: reACK [be6d24e](be6d24e) janb84: ACK be6d24e sedited: ACK be6d24e willcl-ark: ACK be6d24e Tree-SHA512: 19fc6e5dc68f2886f5fb970ff39d040a8088eedca56ad5b86622297614b0d164df9ddd5a8b24b972060e9dcde732de5e3346866b53963524a4277a0a56220570
9a968ad ci: bump cirruslabs actions versions (will) Pull request description: Fix CI deprecation warnings of form: `Node.js 20 actions are deprecated. The following actions are running on Node.js 20 and may not work as expected: cirruslabs/cache/restore@v4.` As these are hiding in `.github/actions/**/*.yml` they were forgotten by the (two) previous PR(s) 😢 #34802 #34344 ACKs for top commit: maflcko: lgtm ACK 9a968ad Tree-SHA512: 2de22cac1dbe7b3df3a69114b1cd84cb8ca5338c6b03c7181d535de247778202301457cfb8d537f6ce118c8d08e0bdcc6ce316ab3d946f606c17e2974a1f14c0
d236415 rpc: Refactor gettxspendingprevout to be easier to parse (Fabian Jahr) Pull request description: This refactoring commit was originally part of #34635 but the the change was some-what controversial: #34635 (comment) and the discussion was blocking the rest of the uncontroversial changes from moving forward. It looks like #34748 is trying to achieve something similar now, we'll have to see how the different approached converge but at least there seems to be some more conceptual interest than appeared on #34635 originally. ACKs for top commit: hodlinator: ACK d236415 sedited: Re-ACK d236415 furszy: utACK d236415 Tree-SHA512: 3df70bb8f143247f66d52430b3d8a4ecc5f0b80aa68ef3fc9082739b6f1be02fa9ef88ff134bb01034c9b6006400342e71fa8dc0a203d8e13b4bf6e21d1b05a8
…provements 57bfa86 test: use static methods and clarify comment in addr_relay (stratospher) 7ee8c0a test: protect outbound connection from eviction in getaddr_test (stratospher) ecb5ce6 test: fix addr relay test silent pass and wrong peerinfo index (stratospher) Pull request description: couple of improvements in the addr relay test: - fixes the silent test pass discovered in #34717 (comment) (will remove this if that PR gets merged - the test doesn't fail even though #34717 changes the behaviour) - correct wrong peerinfo index - prevent intermittent disconnection warnings like the one shown below by protecting outbound peer from `ConsiderEviction` ``` TestFramework (INFO): Check that we answer getaddr messages only once per connection TestFramework.p2p (WARNING): Connection lost to 127.0.0.1:58829 due to [Errno 54] Connection reset by peer ``` - remove a no longer applicable test comment since we don't need to send initial GETADDR for intial self announcement anymore ACKs for top commit: Bortlesboat: ACK 57bfa86. Ran both `p2p_addr_relay.py` and `p2p_addr_selfannouncement.py` locally, both pass. Good catch on the stale `peerinfo` reference in `inbound_blackhole_tests` — that would silently check the wrong peer. naiyoma: ACK 57bfa86 mzumsande: Code Review ACK 57bfa86 Tree-SHA512: 22e4f87f66569bfa629a68a8b440cd21b5285c6dad6eb7926514f2d74e16fe3711525b264f82765c83020be976a0438b8d2ab1e48e7c0b7d85437ee672d52324
c273214 doc: fix process name typo in multiprocess.md (ViniciusCestarii) Pull request description: In this [flow](https://github.com/bitcoin/bitcoin/blob/master/doc/design/multiprocess.md#example-use-cases-and-flows), the bitcoin-wallet process acts as the client initiating the RPC request, while the bitcoin-node process acts as the server receiving it. So at "The `getBlockHash` method of the generated `Chain` server subclass in `bitcoin-wallet` receives a Cap’n Proto request object with the `height` parameter, and calls the `getBlockHash` method on its local `Chain` object with the provided `height`." it should say bitcoin-node not bitcoin-wallet. This PR fix this typo. ACKs for top commit: ryanofsky: Code review ACK c273214. Nice catch! Tree-SHA512: 7227dc96e556ad36f1f39cc1033d80c92e8c6a47cf61ab68401122b1ef8075068224494e4ffb7094eca8dc325294cb96e561d3e997af7d434158031485f92677
9085dee qa: Add lock order annotation for TxMempool::cs (David Gumberg) Pull request description: I added this to see if static analysis would catch any lock order inversions while investigating #34731, it did not catch any but it is a worthwhile defense against statically-analyzable inversions of `cs_main->TxMempool::cs`. ACKs for top commit: sedited: tested ACK 9085dee hebasto: ACK 9085dee. w0xlt: ACK 9085dee Tree-SHA512: 498605362e7b197b7643a3f9ffd04589bc9b245aca1d245d289efa145906248c1a72f9fbf4835a9378aabe170b747dc0cc033105915a2bf7a9989de368710c02
… with `Mutex` 20fb761 args: make most ArgsManager members private (w0xlt) 22b40f3 args: replace cs_args RecursiveMutex with Mutex (w0xlt) 3a16ec8 test: scope cs_args locks to avoid recursive locking (w0xlt) 70b51fe args: eliminate all recursive locking of cs_args (w0xlt) 7d61e03 args: extract lock-requiring internal helpers (w0xlt) Pull request description: Part of #19303. Replace `ArgsManager::cs_args` from `RecursiveMutex` to `Mutex`. The conversion follows the pattern established in prior `RecursiveMutex` removals (e.g. `CAddrMan` in #19238, `CBlockPolicyEstimator` in #22014): extract private lock-held helpers with trailing underscore naming (`GetSetting_()`, `GetArgFlags_()`, `GetPathArg_()`), then replace recursive calls in methods that already hold `cs_args` with those helpers. ACKs for top commit: l0rinc: ACK 20fb761 rkrux: Concept ACK 20fb761 sedited: Re-ACK 20fb761 hebasto: ACK 20fb761, only rebased and suggested changes since my recent [review](#34745 (review)). Tree-SHA512: 7ab4278737f00deaa3f3da75e08469f91e95aa31e916820d02af737c754751ae4f73c1c8650f120eeff142a134f9209cf581499696a7b88ffc83d296515e40f2
d03e3be ci: check macos bundle structure and codesigning (fanquake) 66d80d5 macdeploy: use plugins dir to find plugins (fanquake) ab137cb macdeploy: subprocess out to zip rather than shutil.make_archive (fanquake) Pull request description: Fix bundle format. Add a CI check that codesigning works. Fixes #34744. ACKs for top commit: Sjors: tACK d03e3be hebasto: ACK d03e3be, tested on macOS Tahoe 26.3.1. sedited: ACK d03e3be Tree-SHA512: 5a7db896952edf338ff4fe8c934f1e1c992642850a99d5fafbb1212c6979601b3b72b6f3af880fb6f6ac8759cd4102e9f01792abb05410ceaf36cbffaec48e47
d62f46e doc: Add `INSTALL.md` to Linux release tarballs (Hennadii Stepanov) Pull request description: Closes #32097: > Better I think would be to add instructions for the most popular desktop distros. ACKs for top commit: willcl-ark: utACK d62f46e achow101: ACK d62f46e janb84: re ACK d62f46e w0xlt: ACK d62f46e sedited: ACK d62f46e Tree-SHA512: eab6904b6acc63eaf0e13112f52d856ee630ce4110fb368f4f5f170655def91706bb7c7f70c123186a51461ea3d48ef026a4e026d665675f1fd76f2d0bbca68c
af0da2f crypto: Use `secure_allocator` for `AES256CBC*::iv` (David Gumberg) d53852b crypto: Use `secure_allocator` for `AES256_ctx` (David Gumberg) 8c6feda build: `lockedpool.cpp` kernel -> crypto (David Gumberg) 51ac1ab bench: Add wallet encryption benchmark (David Gumberg) 9a15872 wallet: Make encryption derivation clock mockable (David Gumberg) ae5485f refactor: Generalize derivation target calculation (David Gumberg) Pull request description: Fixes #31744 Reuse `secure_allocator` for `AES256_ctx` in the aes 256 encrypters and decrypters and the `iv` of `AES256CBC` encrypters and decrypters. These classes are relevant to `CCrypter`, used for encrypting wallets, and my understanding is that if an attacker knows some or all of the contents of these data structures (`AES256_ctx` & `iv`) they might be able to decrypt a user's wallet. Presently the `secure_allocator` tries to protect sensitive data with `mlock()` on POSIX systems and `VirtualLock()` on Windows to prevent memory being paged to disk, and by zero'ing out memory contents on deallocation with `memory_cleanse()` which is similar to `OPENSSL_cleanse()` by scaring compilers away from optimizing `memset` calls on non-Windows systems, and using `SecureZeroMemory()` on Windows. ACKs for top commit: achow101: ACK af0da2f furszy: utACK af0da2f theStack: re-ACK af0da2f Tree-SHA512: 49067934fd2f2b285fc7b1a7c853fd2d4475431b3a811ae511f61074dc71a99a0826c3ab40ab4a5dfc84b2b9914a90c920d2484b38ac19502e3bd6170ad27622
…tible 111864a qa: Avoid duplicating output in case the diff is the same (Hodlinator) c2e28d4 ci: Enable `wallet_multiwallet.py` in "Windows, test cross-built" job (Hodlinator) 850a80c qa: Disable parts of the test when running under Windows or root (Hodlinator) fb803e3 qa: Test scanning errors individually (Hodlinator) ed43ce5 qa: Check for platform-independent part of error message (Hodlinator) 64a098a refactor(qa): Break apart ginormous run_test() (Hodlinator) bb1aff7 move-only(qa): Move wallet creation check down to others (Hodlinator) d1a4ddb refactor(qa): Lift out functions to outer scopes (Hodlinator) c811e47 scripted-diff: self.nodes[0] => node (Hodlinator) 73cf858 refactor(qa): Remove unused option (Hodlinator) Pull request description: Makes the functional test compatible with *Linux->Windows cross-built executables*. Main parts: * Commit "qa: Check for platform-independent part of error message" switches to match on platform-independent part of error message. * Commit "qa: Test scanning errors individually" disentangles code causing the same error message substring, based on #31410. * Commit "qa: Disable parts of the test when running under Windows or root" enables the test to be run on Windows, based in part on #31410 (comment). Also: * Removes unused option in wallet_multiwallet.py. * Breaks apart wallet_multiwallet.py's `run_test()` into smaller test functions. * Improves `assert_equal()` output for dicts. Fixes #31409. ACKs for top commit: achow101: ACK 111864a janb84: re ACK 111864a w0xlt: reACK 111864a Tree-SHA512: 4e3ff92588ac9f2611fc963ce62097b6c0dd4d4eb8da7952c72619c7b554ff3cae5163fe1886d4d9bbd7af1acca5b846411e7f5b46f9bddb08719b61108efbba
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
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.
Avance