update bitcoin to 0.18.1 #1
Open
Conversation
This file contains 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
The m_deps_to_add vector is sorted by child Cluster*, which matches the order of an_clusters. This means we can walk through m_deps_to_add while doing the representative lookups for an_clusters, and reuse them.
…tion) Since m_deps_to_add has been sorted by child Cluster* already, all dependencies with the same child will be processed consecutively. Take advantage of this by remember the last partition merged with, and reusing that if applicable.
Chunk-based information (primarily, chunk feerates) are never accessed without first bringing the relevant Clusters to an "acceptable" quality level. Thus, while operations are ongoing and Clusters are not acceptable, we can omit computing the chunkings and chunk feerates for Clusters.
When transactions are removed from the tail of a cluster, we know the existing linearization remains acceptable (if it already was), but may just need splitting and postlinearization, so special case these into separate quality levels.
This is a preparation for a next commit where a TxGraph will start representing potentially two distinct graphs (a main one, and a staging one with proposed changes).
Move a number of related modifications to TxGraphImpl into a separate function for removal of transactions. This is preparation for a later commit where this will be useful in more than one place.
In order to make it easy to evaluate proposed changes to a TxGraph, introduce a "staging" mode, where mutators (AddTransaction, AddDependency, RemoveTransaction) do not modify the actual graph, but just a staging version of it. That staging graph can then be commited (replacing the main one with it), or aborted (discarding the staging).
Before this commit, if a TxGraph::Ref object is destroyed, it becomes impossible to refer to, but the actual corresponding transaction node in the TxGraph remains, and remains indefinitely as there is no way to remove it. Fix this by making the destruction of TxGraph::Ref trigger immediate removal of the corresponding transaction in TxGraph, both in main and staging if it exists.
In order to make it possible for higher layers to compare transaction quality (ordering within the implicit total ordering on the mempool), expose a comparison function and test it.
This can be called when the caller has time to spend now, and wants future operations to be fast.
This is a preparation for the next commit, which adds a feature to request the Refs to multiple ancestors/descendants at once.
Like GetAncestors and GetDescendants, but for the union of multiple inputs.
Since support for 32-bit Windows has been dropped, the suffix is no longer necessary.
2f2ab47 Release notes (Pol Espinasa) bf194c9 wallet, rpc: deprecate settxfee and paytxfee (Pol Espinasa) Pull request description: **Summary** This PR deprecates the settxfee RPC and paytxfee setting, marking it for removal in Bitcoin Core 31.0. **Motivation** The PR was initially motivated by #31088. The intention was to create a new function `settxfeerate` to allow users to set a static fee rate in `sat/vB` instead of `btc/kvB`. The `settxfee` RPC allows users to set a static fee rate for all transactions created by the wallet. However, in a dynamic fee environment, this can lead to poor fee choices, either overpaying when the mempool is empty or underpaying when congestion is high. The preferred approach is to rely on fee estimation, which is designed to adapt to network conditions, and is the one by default. Same argument apply for `paytxfee` setting. During discussion the consensus was that static fee settings are a footgun and that users should instead specify the fee rate per transaction if they don't want to rely on the fee estimation. Given this, rather than introducing a `settxfeerate` alternative, this PR goes towards removing `settxfee` and `paytxfee` entirely. **Key Changes** `settxfee` and `paytxfee` is now deprecated and will be removed in Bitcoin Core 31.0. Users should rely on fee estimation or explicitly specify a fee rate when constructing transactions. **Impact on Users** If users currently use settxfee or paytxfee, they should transition to specifying fees per transaction. No immediate breakage in 30.0 (must use `-deprecatedrpc=settxfee`), but `settxfee` and `paytxfee` will be removed in 31.0. **Alternative Approaches Considered** A settxfeerate alternative (using sat/vB) was initially proposed but ultimately rejected in favor of deprecating static fee setting entirely. **Notes for removal** - When removing paytxfee we should also update txconfirmtarget startup option help text. - Get back the comment from `rpc_deprecated.py` test. [+info](#31278 (comment)) ACKs for top commit: fjahr: re-ACK 2f2ab47 ismaelsadeeq: re-ACK 2f2ab47 rkrux: Concept and utACK 2f2ab47 Tree-SHA512: 0272812cbe5a519737c5d0683acc2072e67559792b4a6472bca8b23426e5ce9e88a3a1eba987feda70a082b8b474b3126893848628d7bf11e1520357b18c8d3e
a015b7e test: Add expected result assertions (yancy) Pull request description: ~This is a trivial addition to the test suit, however it shouldn't be required to add debug statements and manually run the tests if someone needs to know the results of this test.~ Add an assertion for the values returned. The goal of the test is to show that a minimal weight selection of UTXOs is returned by coin-grinder. Since there are multiple possible solutions, the added assertion shows that coin-grinder finds the solution with the lowest weight. Without this assertion, it's ambiguous whether or not coin-grinder is returning the solution with the lowest weight. Remove the check that a result is returned since the expected result assertion implies a result. ACKs for top commit: janb84: re ACK [a015b7e](a015b7e) murchandamus: ACK a015b7e Tree-SHA512: ee3c2688b4a4a07ab209f7655c3956e62a1084419df5e87c27d751a38ff64d4c3457df2317f8077149a6947cdb05b249975de2b8f0e18ca8b17b41f4735fb1c6
6869fb4 net: Block v2->v1 transport downgrade if !CConnman::fNetworkActive (Hodlinator) Pull request description: We might have just set `CNode::fDisconnect` in the first loop because of `!CConnman::fNetworkActive`. Attempting to reconnect using v1 transport just because `fNetworkActive` was set to `false` at the "right" stage in the v2 handshake does not make sense. Issue [discovered](#31633 (comment)) by davidgumberg. ACKs for top commit: davidgumberg: Tested and Reviewed ACK 6869fb4 mabu44: ACK 6869fb4 stratospher: ACK 6869fb4. I've reviewed the code but don't have strong preference for this branch vs master since only functional change is just a single log not being printed in a low probability scenario (we happen to be attempting v2 connection when P2P network activity is being turned off). vasild: ACK 6869fb4 Tree-SHA512: 54f596e54c5a6546f2c3fec2609aa8d10dec3adcf1001ca16666d8b374b8d79d64397f46c90d9b3915b4e91a5041b6ced3044fd2a5b4fb4aa7282eb51f61296a
288481a doc: clarify that testnet min-difficulty is not optional (Sjors Provoost) Pull request description: When 20 minutes have gone by on testnet3 or testnet4, the next block `MUST` have difficulty 1. I've seen people be confused about this several times now in recent months. It doesn't help that the code comment is wrong. So fixing that. The reason is that `nBits` must match exactly: https://github.com/bitcoin/bitcoin/blob/e568c1dd134e0318c46113cb7dfc23b40e2829e8/src/validation.cpp#L4212-L4215 ACKs for top commit: fjahr: ACK 288481a kevkevinpal: ACK [288481a](288481a) Tree-SHA512: 17d426301f386fa5810cceedfdb20a3523ab3ac2f17257ca7a525edd869fa409b150eff4cc258b27adecd0ded1c18ff48a9998fc9caed2faa461e410d4c5a884
Update get_permissions function to remove unnecessary replace() and improve password for strangedude6. Change all string concatenation to f-strings.
Checking for IsArgSet before calling GetArg while providing the args default value as fallback is both confusing and fragile. It is confusing, because the provided fallback is dead code. So it would be better to just call GetArg without a fallback. However, ignoring the fallback value is fragile, because it would not be sanitized. Fix all issues by sanitizing the fallback value.
Checking for IsArgSet before calling GetArg while providing an arbitrary default value as fallback is both confusing and fragile. It is confusing, because the provided fallback is dead code. So it would be better to just call GetArg without a fallback. Even better would be to provide the true fallback value and sanitize it as if it were user-input, but this can be done in a follow-up. Removing the redundant call to IsArgSet will have to be done either way, so do it now.
If anything is left to be done, a new discussion issue or pull request can be created.
Replace test_rpcwhitelistdefault_0_no_permissions and test_rpcwhitelistdefault_1_no_permissions with a single test_rpcwhitelistdefault_permissions function.
226d81f mining: drop unused -nFees and sigops from CBlockTemplate (Sjors Provoost) 53ad845 test: check fees and sigops in getblocktemplate (Sjors Provoost) Pull request description: For the coinbase `vTxFees` used a dummy value of -nFees. Similarly the first `vTxSigOpsCost` entry was calculated from the dummy coinbase transaction. This was introduced in #2115, but the values were never returned by the RPC or used in a test. Drop 'm and add code comments to prevent confusion. This PR also adds test coverage for the `fees` and `sigops` fields in `getblocktemplate`, so it closes #32053. ACKs for top commit: ismaelsadeeq: re-ACK 226d81f ryanofsky: Code review ACK 226d81f. New test was added since last review, which seems very cleanly written and fixes some missing coverage. glozow: ACK 226d81f Tree-SHA512: 79c534e6bc4810d29114b04dd6db798877732cb473e773bf3cc28f83d14ee3982392587bd0baa39857bd53a79eae3b730d7a7029b08a9b6c3b5c51f86657ca5d
…tdown during long poll and wait methods 05117e6 rpc: clarify longpoll behavior (Sjors Provoost) 5315278 Have createNewBlock() wait for a tip (Sjors Provoost) 64a2795 rpc: handle shutdown during long poll and wait methods (Sjors Provoost) a3bf433 rpc: drop unneeded IsRPCRunning() guards (Sjors Provoost) f9cf8bd Handle negative timeout for waitTipChanged() (Sjors Provoost) Pull request description: This PR prevents Mining interface methods from sometimes crashing when called during startup before a tip is connected. It also makes other improvements like making more RPC methods usable from the GUI. Specifically this PR: - Adds an `Assume` check to disallow passing negative timeout values to `Mining::waitTipChanged` - Makes `waitfornewblock`, `waitforblock` and `waitforblockheight` RPC methods usable from the GUI when `-server=1` is not set. - Changes `Mining::waitTipChanged` to return `optional<BlockRef>` instead of `BlockRef` and return `nullopt` instead of crashing if there is a timeout or if the node is shut down before a tip is connected. - Changes `Mining::waitTipChanged` to not time out before a tip is connected, so it is convenient and safe to call during startup, and only returns `nullopt` on early shutdowns. - Changes `Mining::createNewBlock` to block and wait for a tip to be connected if it is called on startup instead of crashing. Also documents that it will return null on early shutdowns. This allows `waitNext()` (added in #31283) to safely assume `TipBlock()` isn't `null`, not even during a scenario of early shutdown. Finally this PR clarifies long poll behaviour, mostly by adding code comments, but also through an early `break`. ACKs for top commit: achow101: ACK 05117e6 ryanofsky: Code review ACK 05117e6, just updated a commit message since last review TheCharlatan: ACK 05117e6 vasild: ACK 05117e6 Tree-SHA512: 277c285a6e73dfff88fd379298190b264254996f98b93c91c062986ab35c2aa5e1fbfec4cd71d7b29dc2d68e33f252b5cfc501345f54939d6bd78599b71fec04
Also, remove the minor version from the comment, because it does not matter and may even change at any time.
Signed-off-by: Eval EXEC <[email protected]>
The keys and scripts created for the Legacy Wallet needed to be persisted in order for the migration to work properly.
7749d92 Remove support for RNDR/RNDRRS for aarch64 on Linux (laanwj) Pull request description: This hardware feature is - Rarely supported on SoCs (and broken on like half of the chips that support it in the first place) (#31817). It is not clear if, or how, the brokenness will be worked around in the kernel, but working around it in user space seems the wrong thing to do, this is not the place to maintain special workarounds for specific hardware (which despite that, was attempted in #31826, but had to be reverted in #31908 due to other problems). - Apparently not compiled into the release binary anymore (#31817 (comment)). Did check this at the time, but a build system change must have caused this, and went undetected. - Hard to test in CI (as well as manually), due to unavailability of hardware. Better to remove it. This reverts commit aee5404 from #26839. Closes #31817. ACKs for top commit: sipa: utACK 7749d92 davidgumberg: utACK 7749d92 achow101: ACK 7749d92 w0xlt: utACK 7749d92 Tree-SHA512: d243ad7f745fb46f711f24b6983d9ea1d94e5d8ee60959229bafdba5caa210a60801a1c2cb5b558a0e72f365371b32285aee9a8d0cd24a60589adc7b03dd6a44
32dcec2 rpc: update RPC help of `createpsbt` (rkrux) 931117a rpc: update the doc for `data` field in `outputs` argument (rkrux) 8134a6b rpc: add cli example for `walletcreatefundedpsbt` RPC (rkrux) Pull request description: ### add cli example for `walletcreatefundedpsbt` and `createpsbt` RPCs The only example present earlier was one that creates an OP_RETURN output. This lack of examples has discouraged me earlier to use this RPC. Adding an example that creates PSBT sending bitcoin to address, a scenario that is much more common. ### rpc: update the doc for `data` field in `outputs` argument It was not evident to me that this field creates an `OP_RETURN` output until I read the code and tried it out. Thus, making the doc explicitly mention it. This affects docs of the following RPCs: `bumpfee`, `psbtbumpfee`, `send`, `walletcreatefundedpsbt`, `createpsbt`, and `createrawtransaction` ACKs for top commit: sipa: utACK 32dcec2 1440000bytes: utACK 32dcec2 achow101: ACK 32dcec2 ryanofsky: Concept ACK 32dcec2. These seem like helpful clarifications, but I did not look into the details Tree-SHA512: f994488ba7d52d00960fc52064bb419cf548e29822fe23d6ee0452fdf514dd93f089145eddb32b8086a7918cf8cf33a4c3f16bfcb7948f3c9d5afd95e8d3a1cb
…ization 8d801e3 optimization: bulk serialization writes in `WriteBlockUndo` and `WriteBlock` (Lőrinc) 520965e optimization: bulk serialization reads in `UndoRead`, `ReadBlock` (Lőrinc) 056cb3c refactor: clear up blockstorage/streams in preparation for optimization (Lőrinc) 67fcc64 log: unify error messages for (read/write)[undo]block (Lőrinc) a4de160 scripted-diff: shorten BLOCK_SERIALIZATION_HEADER_SIZE constant (Lőrinc) 6640dd5 Narrow scope of undofile write to avoid possible resource management issue (Lőrinc) 3197155 refactor: collect block read operations into try block (Lőrinc) c77e310 refactor: rename leftover WriteBlockBench (Lőrinc) Pull request description: This change is part of [[IBD] - Tracking PR for speeding up Initial Block Download](#32043) ### Summary We can serialize the blocks and undos to any `Stream` which implements the appropriate read/write methods. `AutoFile` is one of these, writing the results "directly" to disk (through the OS file cache). Batching these in memory first and reading/writing these to disk is measurably faster (likely because of fewer native fread calls or less locking, as [observed](#28226 (comment)) by Martinus in a similar change). ### Unlocking new optimization opportunities Buffered writes will also enable batched obfuscation calculations (implemented in #31144) - especially since currently we need to copy the write input's std::span to do the obfuscation on it, and batching enables doing the operations on the internal buffer directly. ### Measurements (micro benchmarks, full IBDs and reindexes) Microbenchmarks for `[Read|Write]BlockBench` show a ~**30%**/**168%** speedup with `macOS/Clang`, and ~**19%**/**24%** with `Linux/GCC` (the follow-up XOR batching improves these further): <details> <summary>macOS Sequoia - Clang 19.1.7</summary> > Before: | ns/op | op/s | err% | total | benchmark |--------------------:|--------------------:|--------:|----------:|:---------- | 2,271,441.67 | 440.25 | 0.1% | 11.00 | `ReadBlockBench` | 5,149,564.31 | 194.19 | 0.8% | 10.95 | `WriteBlockBench` > After: | ns/op | op/s | err% | total | benchmark |--------------------:|--------------------:|--------:|----------:|:---------- | 1,738,683.04 | 575.15 | 0.2% | 11.04 | `ReadBlockBench` | 3,052,658.88 | 327.58 | 1.0% | 10.91 | `WriteBlockBench` </details> <details> <summary>Ubuntu 24 - GNU 13.3.0</summary> > Before: | ns/op | op/s | err% | ins/op | cyc/op | IPC | bra/op | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 6,895,987.11 | 145.01 | 0.0% | 71,055,269.86 | 23,977,374.37 | 2.963 | 5,074,828.78 | 0.4% | 22.00 | `ReadBlockBench` | 5,152,973.58 | 194.06 | 2.2% | 19,350,886.41 | 8,784,539.75 | 2.203 | 3,079,335.21 | 0.4% | 23.18 | `WriteBlockBench` > After: | ns/op | op/s | err% | ins/op | cyc/op | IPC | bra/op | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 5,771,882.71 | 173.25 | 0.0% | 65,741,889.82 | 20,453,232.33 | 3.214 | 3,971,321.75 | 0.3% | 22.01 | `ReadBlockBench` | 4,145,681.13 | 241.21 | 4.0% | 15,337,596.85 | 5,732,186.47 | 2.676 | 2,239,662.64 | 0.1% | 23.94 | `WriteBlockBench` </details> 2 full IBD runs against master (compiled with GCC where the gains seem more modest) for **888888** blocks (seeded from real nodes) indicates a ~**7%** total speedup. <details> <summary>Details</summary> ```bash COMMITS="d2b72b13699cf460ffbcb1028bcf5f3b07d3b73a 652b4e3"; \ STOP_HEIGHT=888888; DBCACHE=1000; \ C_COMPILER=gcc; CXX_COMPILER=g++; \ BASE_DIR="/mnt/my_storage"; DATA_DIR="$BASE_DIR/BitcoinData"; LOG_DIR="$BASE_DIR/logs"; \ (for c in $COMMITS; do git fetch origin $c -q && git log -1 --pretty=format:'%h %s' $c || exit 1; done) && \ hyperfine \ --sort 'command' \ --runs 2 \ --export-json "$BASE_DIR/ibd-${COMMITS// /-}-$STOP_HEIGHT-$DBCACHE-$C_COMPILER.json" \ --parameter-list COMMIT ${COMMITS// /,} \ --prepare "killall bitcoind; rm -rf $DATA_DIR/*; git checkout {COMMIT}; git clean -fxd; git reset --hard; \ cmake -B build -DCMAKE_BUILD_TYPE=Release -DENABLE_WALLET=OFF -DCMAKE_C_COMPILER=$C_COMPILER -DCMAKE_CXX_COMPILER=$CXX_COMPILER && \ cmake --build build -j$(nproc) --target bitcoind && \ ./build/bin/bitcoind -datadir=$DATA_DIR -stopatheight=1 -printtoconsole=0; sleep 100" \ --cleanup "cp $DATA_DIR/debug.log $LOG_DIR/debug-{COMMIT}-$(date +%s).log" \ "COMPILER=$C_COMPILER COMMIT=${COMMIT:0:10} ./build/bin/bitcoind -datadir=$DATA_DIR -stopatheight=$STOP_HEIGHT -dbcache=$DBCACHE -blocksonly -printtoconsole=0" d2b72b1 refactor: rename leftover WriteBlockBench 652b4e3 optimization: Bulk serialization writes in `WriteBlockUndo` and `WriteBlock` Benchmark 1: COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=888888 -dbcache=1000 -blocksonly -printtoconsole=0 (COMMIT = d2b72b1) Time (mean ± σ): 41528.104 s ± 354.003 s [User: 44324.407 s, System: 3074.829 s] Range (min … max): 41277.786 s … 41778.421 s 2 runs Benchmark 2: COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=888888 -dbcache=1000 -blocksonly -printtoconsole=0 (COMMIT = 652b4e3) Time (mean ± σ): 38771.457 s ± 441.941 s [User: 41930.651 s, System: 3222.664 s] Range (min … max): 38458.957 s … 39083.957 s 2 runs Relative speed comparison 1.07 ± 0.02 COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=888888 -dbcache=1000 -blocksonly -printtoconsole=0 (COMMIT = d2b72b1) 1.00 COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=888888 -dbcache=1000 -blocksonly -printtoconsole=0 (COMMIT = 652b4e3) ``` </details> ACKs for top commit: maflcko: re-ACK 8d801e3 🐦 achow101: ACK 8d801e3 ryanofsky: Code review ACK 8d801e3. Most notable change is switching from BufferedReader to ReadRawBlock for block reads, which makes sense, and there are also various cleanups in blockstorage and test code. hodlinator: re-ACK 8d801e3 Tree-SHA512: 24e1dee653b927b760c0ba3c69d1aba15fa5d9c4536ad11cfc2d70196ae16b9228ecc3056eef70923364257d72dc929882e73e69c6c426e28139d31299d08adc
…C tests a4041c7 test: Handle empty string returned by CLI as None in RPC tests (Brandon Odiwuor) Pull request description: Partially Fixes #32264 Some tests are failing when `bitcoin-cli` returns an empty string. This change treats an empty response as `None`. See #32264 (comment) This fixes the error for: - feature_bip68_sequence.py - feature_nulldummy.py - feature_signet.py - mining_mainnet.py - rpc_scanblocks.py - rpc_scantxoutset.py - wallet_descriptor.py --descriptors ACKs for top commit: maflcko: lgtm ACK a4041c7 achow101: ACK a4041c7 pablomartin4btc: ACK a4041c7 mzumsande: ACK a4041c7 Tree-SHA512: 2f1a416a18e0b3eebdb014c2e2e8dadf1d46b15c231cb61f577d47f5e551994ab0e2aeb7c179c01be7c1f07ebc03476236d29cf2d04c358ffb1fae985aa385c9
2929da1 test: Add coverage for rpcwhitelistdefault when unset (naiyoma) 535b874 test: Combine rpcwhitelistdefault functions (naiyoma) 2b6ce92 test: Update permissions and string formatting (naiyoma) Pull request description: This is a follow-up PR to address review feedback from [https://github.com/bitcoin/bitcoin/pull/29858](https://github.com/bitcoin/bitcoin/pull/29858) - [x] add case where rpcwhitelistdefault setting is [unset](#29858 (review)) - [x] Code [cleanup](#29858 (comment)) , change password and f-string formatting - [x] [Combine](#29858 (comment)) rpcwhitelistdefault tests into `test_rpcwhitelistdefault_permissions` I am not sure if my approach of adding` test_rpcwhitelistdefault_unset` is better or if I should just include the assertions in the existing `test_rpcwhitelistdefault_permissions` ACKs for top commit: w0xlt: Code review ACK 2929da1 achow101: ACK 2929da1 ryanofsky: Code review ACK 2929da1. Only change since last review was simplifying the last commit as suggested Tree-SHA512: 6750dd3e6abaca3a09ad1fd5d07c64767bc59188ff953cbc26aa7796071774cb92745ac82cf91e479632d682fd450bc00d53032454b65b22654a3e770ec68e89
7a93544 doc: Fix and clarify description of ZMQ message format (Jiri Jakes) Pull request description: This change stresses that all ZMQ messages share the same structure and that they differ only in the format of the bodies. Previously this was not clear. Further it removes the notion of endianness of 32-byte hashes, as it was misleading, and replaces it with the term 'reversed byte order' (as opposed to natural or normal byte order produced by hashing functions). Additionally, it states that ZMQ 32-byte hashes are in the same format as in RPC. Previously it incorrectly stated that the two were in different formats. [Rendered](https://github.com/jirijakes/bitcoin/blob/zmq-doc/doc/zmq.md). Fixes #31856. ACKs for top commit: w0xlt: Code review ACK 7a93544 achow101: ACK 7a93544 ryanofsky: Code review ACK 7a93544. Nice changes. Documentation seems less repetitive and easier to understand now Tree-SHA512: 8c5ab047c5fd9b5b6910d691b725886d7743dfd01510735b46e43d01c2d0d25ec52d79d71ec75dbeb142e96a88ad503d69ee14b971e3cdaeb8fd85e5292a8c21
7912cd4 bench: Fix WalletMigration benchmark (pablomartin4btc) Pull request description: The keys and scripts created for the Legacy Wallet needed to be persisted in order for the migration to work properly. Fixes #32277. ACKs for top commit: achow101: ACK 7912cd4 davidgumberg: Tested ACK 7912cd4 furszy: utACK 7912cd4 Tree-SHA512: fe7b8e0a80d4d030ad3fd6446717ee09a260ab2bd6140bc817bdca52d233e3af8a8fed2d754743ca2ba022f7d2c8615a36b5070991d12942c13835e8f72e359f
So there's at least one CI sanity checking all benchmarks. Related to #32277.
faeb1ba ci: refactor: Use version id over version codename consistently (MarcoFalke) fae322a ci: Slim down lint image (MarcoFalke) 3333273 ci: Bump lint imagefile FROM base (MarcoFalke) Pull request description: Currently, the lint_test_runner is built and installed into the lint CI image. This is problematic, because it triggers a full image build on every change to its source code. Doing a build of the lint test_runner on every run is easier and faster. ACKs for top commit: l0rinc: ACK faeb1ba janb84: Re- ACK [faeb1ba](faeb1ba) Tree-SHA512: 39103e61ec2587096213bc1ce55b80087f6f03775592827d8c96a366453b798570d912690bf96fde4685798e5fc8ee2695ce851f473b4c8782d1a4c50c65a594
27f1121 ci: drop -priority-level from bench in win cross CI (fanquake) Pull request description: So there's at least one CI sanity checking all benchmarks. Related to #32277. ACKs for top commit: l0rinc: utACK 27f1121 hebasto: ACK 27f1121. mabu44: utACK 27f1121 Tree-SHA512: 4853584bf9db418f6e31aa0f558d08bc45479d672b193e1d25a25907f82fb225bc4388321f8f23286cd9fd9168c7546c713829607eb0cf5e3c62b98e88f8e68b
…n better 9ccee9c doc: Document WITH_EXTERNAL_LIBMULTIPROCESS build option better (Ryan Ofsky) Pull request description: This includes a cmake documentation change suggested #31741 (comment) and another change to mention the option in markdown documentation ACKs for top commit: hebasto: ACK 9ccee9c, changes look good. TheCharlatan: ACK 9ccee9c Tree-SHA512: c9103b001b970ac57afedc6dc384091f5661975d569573e93003cbd7df1891c54cefb06d7296eac5b9a5c57251803dcab2bd3b26c9d81aa476c62f211dcb3d6e
…tor target fa6a007 fuzz: Avoid integer sanitizer warnings in policy_estimator target (MarcoFalke) Pull request description: It seems odd to write a fuzz target to trigger integer sanitizer warnings in `CBlockPolicyEstimator::processBlockTx` and then suppress them. If the scenario can happen in reality, the code should be properly fixed to handle the cases. If not, it seems better to fix the fuzz target to not trigger meaningless traces. Do that here by keeping track of the current height and limiting mempool entries to at most this entry height. ACKs for top commit: brunoerg: ACK fa6a007 dergoegge: utACK fa6a007 Tree-SHA512: 2092017dc309fb095fe5d43cfb76efb691795f303d567ee919be2b5cac19a944293636229903dc4d1e8b9fe5daf9dc3058544321eff1735f91f804c3baa36cd0
2835216 txgraph: make GroupClusters use partition numbers directly (optimization) (Pieter Wuille) c72c8d5 txgraph: compare sequence numbers instead of Cluster* (bugfix) (Pieter Wuille) Pull request description: Part of cluster mempool: #30289 The implicit transaction ordering for transactions in a TxGraphImpl is defined by: 1. higher chunk feerate first 2. lower Cluster* object pointer first 3. lower position within cluster linearization first. Number (2) is not deterministic, as it intricately depends on the heap allocation algorithm. Fix this by giving each Cluster a unique `uint64_t m_sequence` value, and sorting by those instead. The second commit then uses this new approach to optimize GroupClusters a bit more, avoiding some repeated checks and dereferences, by making a local copy of the involved sequence numbers. Thanks to @dergoegge for pointing this out. ACKs for top commit: instagibbs: reACK 2835216 marcofleon: ACK 2835216 glozow: utACK 2835216 Tree-SHA512: d772a55b9ed620159b934a42a39fca7f900d4aa89c099a280a0c61ea0bd7c4fc39b388281ffc775064ea77b0b17263871b4c9763aa71c710a79287d5eb2cd4b4
e261eb8 tests: Add BIP 373 test vectors (Ava Chow) 26370c6 rpc: Include MuSig2 fields in decodepsbt (Ava Chow) ff3d460 psbt: Implement un/ser of musig2 fields (Ava Chow) Pull request description: Implements un/serialization of MuSig2 PSBT fields and prepares PSBT to be able to sign for MuSig2 inputs. Split from #29675 ACKs for top commit: fjahr: re-ACK e261eb8 theStack: re-ACK e261eb8 rkrux: tACK e261eb8 Tree-SHA512: bb852ad074978847ac4dc656332025e2d4d1025d4283537b89618c7cadd61a8ecd2eff24779b8a014bc8d7b431125060449768192fa05ad0577f29e3c64b2374
bcaa23a torcontrol: Fix addrOnion outdate comment (Eval EXEC) Pull request description: `m_randomize_credentials` is outdated name, remove it. Ref: #32176 (comment) ACKs for top commit: achow101: ACK bcaa23a laanwj: ACK bcaa23a w0xlt: ACK bcaa23a jonatack: ACK bcaa23a Tree-SHA512: 38ba9b37e560598605077da7a84c455aa1a7e49365c417ceceff85a18de2af393b164cc8c93cdd6da9eac4d41f046f0ed12bc0f6833fe606c412ce7f1fce5189
5cb1241 feefrac: avoid integer overflow in temporary (Pieter Wuille) Pull request description: In `FeeFrac::Div(__int128 n, int32_t d, bool round_down)` in src/util/feefrac.h, the following line computes the result: ```c++ return quot + (mod > 0) - (mod && round_down); ``` The function can only be called under conditions where the result is in range, and thus doesn't involve any integer overflow. However, the intermediary result computed by just `quot + (mod > 0)` may still overflow if it's going to be corrected by the `- (mod && round_down)` that follows. Fix this by balancing the two correction steps with each other first: ```c++ return quot + ((mod > 0) - (mod && round_down)); ``` Fixes #32294. ACKs for top commit: l0rinc: Tested ACK 5cb1241 maflcko: lgtm ACK 5cb1241 achow101: ACK 5cb1241 Tree-SHA512: 9daaccdf9acd7652d53b52cad2dc12872558265e863acdde2d6015f885cb87c0505f9bd5be5499fc0a0eded29bec719643f6af1fbc3604518143985094226c95
d85895e build, msvc: Build only required `qtbase` features (Hennadii Stepanov) fe5a6dc build, msvc: Update vcpkg manifest baseline (Hennadii Stepanov) Pull request description: This PR: 1. Updates the vcpkg manifest baseline from the [2024.09.30 Release](https://github.com/microsoft/vcpkg/releases/tag/2024.09.30) to the [2025.03.19 Release](https://github.com/microsoft/vcpkg/releases/tag/2025.03.19), with the following package changes: - boost: 1.85.0#1,2 --> 1.87.0 - qtbase: 6.7.2#3 -> 6.8.2#1 - qttools: 6.7.2#1 -> 6.8.2 - sqlite3: 3.46.1 --> 3.49.1 The previous update was made in #31186. 3. Explicitly specifies required features for the `qtbase` package, which makes vcpkg skip unused features such as `dnslookup`, `openssl`, etc. ACKs for top commit: hodlinator: ACK d85895e Tree-SHA512: e05fb50825c6ba2e0caf8ded1dfb55fa42f28f06dcd28597f748c1843a1c4cc888e62ad87b6481c66481a576fa224dd4943fe76e286ff579c6d4dc2ec6a78a71
18a0351 ci: Temporarily disable `WalletMigration` benchmark (Hennadii Stepanov) Pull request description: The `WalletMigration` benchmark is currently failing on CI. This PR temporarily disables it until the issue is resolved. An alternative to #32302. ACKs for top commit: maflcko: lgtm ACK 18a0351 TheCharlatan: ACK 18a0351 Tree-SHA512: bb1451fd0743a2955216a6d06916e411420a76bfed8b69ffcfadf99d0996d8f3b89ed72f855f25269f943ca4c3b4422065fde2374a1bf76c8bb64f14ab883092
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.