descriptor: speed-up Parse (xpub/xpriv) in ~30% - #23
Open
brunoerg wants to merge 627 commits into
Open
Conversation
brunoerg
force-pushed
the
2026-04-descriptor
branch
2 times, most recently
from
April 8, 2026 23:03
fb7c5b9 to
6b4e303
Compare
brunoerg
changed the title
Parse in ~30%Parse (xpub/xpriv) in ~30%
brunoerg
force-pushed
the
2026-04-descriptor
branch
from
April 9, 2026 17:50
6b4e303 to
2d86114
Compare
brunoerg
force-pushed
the
2026-04-descriptor
branch
2 times, most recently
from
June 10, 2026 17:51
0d8110a to
6dd023a
Compare
Found by Sjors in bitcoin#35896 (comment) This should also fix GCC warnings such as bitcoin#35896 (comment)
This is unused since cluster-mempool. See the commit that forgot to remove it: ```sh $ git show 216e693 -U99999 | grep newFeeRate CFeeRate newFeeRate(ws.m_modified_fees, ws.m_vsize); - if (const auto err_string{PaysMoreThanConflicts(ws.m_iters_conflicting, newFeeRate, hash)}) { ```
…ementChecks fa9a9a8 refactor: Remove unused newFeeRate var in ReplacementChecks (MarcoFalke) Pull request description: This is unused since cluster-mempool, so it seems confusing to keep around. See the commit that forgot to remove it: ```sh $ git show 216e693 -U99999 | grep newFeeRate CFeeRate newFeeRate(ws.m_modified_fees, ws.m_vsize); - if (const auto err_string{PaysMoreThanConflicts(ws.m_iters_conflicting, newFeeRate, hash)}) { ``` ACKs for top commit: sedited: ACK fa9a9a8 Tree-SHA512: f8804109c59dfe37da754cb1924cc16abbc792fbb3619249a1edbc005f66fd88357c4810926625a375415c5be4ff056d68af3029f8075590252289c1d753a2fd
This has been unused since a52b539.
This has been unused since 3333282.
…n.cpp` This has been unused since 0de48fe.
Like authproxy.py, so that tests can work without having to think whether the cli was used or not.
Also, modify send_cli, so that the test can be run under --usecli
sourceware is blocking/rate-limiting http(s) git requests to combat AI scrapers. Switch to a live mirror hosted at fish.foo Use exported GIT_CONFIG_* to avoid setting `git config --global` which could clobber a user running on bare host, but still propagate to child git processes spawned by `make`.
This reverts commit fa06ea4.
Steps to reproduce the diff on Ubuntu 26.04: ``` cmake --preset dev-mode cmake --build build_dev_mode --target translate ```
Contributed by Sjors in bitcoin#35896 (comment) This benchmark can be run on top of any earlier commit by applying the diff of this commit before building.
81fcecf Revert "ci: Temporarily remove riscv32 config from GHA matrix" (will) b283e17 ci: use mirror for riscv submodules (will) Pull request description: The https transport is rate-limited to block AI scrapers. Switch to a live mirror on fish.foo to re-enable the riscv job. ACKs for top commit: maflcko: lgtm ACK 81fcecf sedited: ACK 81fcecf Tree-SHA512: 1891046d9847b904a3e4be25b7f313fc2413ad1cc0b2c09b2300f81a2f1f691dad816fa5fcfeeae263f8d5f868d229aca5a7ab3f227ce650d359068488bc1e21
…r load fa7bc26 test: Check that RPCs do not time out, even under load (MarcoFalke) fa2bd96 test: Map cli CalledProcessError on server error to JSONRPCException (MarcoFalke) Pull request description: It turns out there is no test currently to check that the RPC server does not time out under load. With "load" I mean a flood of trivial payloads. That is, the only work needed is JSON encoding and decoding of (let's say) a block of data of 2 MB or so. This may take a few milliseconds, but should never take more than a few seconds. So add a test for this. ACKs for top commit: enirox001: ACK bitcoin@fa7bc26 sedited: ACK fa7bc26 Tree-SHA512: c60646981b7449c757e9fad499e1cd71030376ffb2ae687c8136c6f70accd0a2d76a4cbfc7dd1bc6626ea3a5310a33616a36cd682cc5c4371ec86aa2c8641aeb
e98ffd4 doc: fix stale bitcoin_en.xlf reference (cyb3ralbert) Pull request description: `doc/release-process.md` still instructs users to create the Transifex resource from `src/qt/locale/bitcoin_en.xlf`, even though that file no longer exists. It was removed in bitcoin#34808, which switched the Transifex source to the native Qt `.ts` file. That PR updated the other references to `.xlf` in this document, but this one was missed. The last step in the same list already refers to `bitcoin_en.ts`, as does `.tx/config`. This patch updates the remaining outdated reference. Docs-only change. No tests run. ACKs for top commit: hebasto: ACK e98ffd4. This was overlooked in bitcoin#34808. Tree-SHA512: fc6a295aae8a58e72e3324f52849255fe5c49bc53af71733de44489dd8a5dea86e3dfeaaf01cb47c506e717019a390de97a71505babcb1c98626f5c2fd98274f
This has been unused since it was introduced in 938e86f.
This has been unused since d610951.
This has been unused since 3b98bf9.
1278a59 net_processing: process unique tx INVs only (Gregory Sanders) Pull request description: There is no reason we should process conflicting advertisements for transactions, as they cannot be both accepted into our mempool. Avoid processing these and doing spurious work. Should be no change in observable behavior. ACKs for top commit: ajtowns: ACK 1278a59 fjahr: ACK 1278a59 l0rinc: ACK 1278a59 Tree-SHA512: c62ceed2cc634c8c99509a8495e5f9bb6d4d8d050942f709a6539ae4dfe1ec628ce7ab0ec1392656809e0d827d1fecf2e8fb9bb4600d13a5bf9a34c9e9e3ad6e
7502b9d fuzz: check http_request body matches framing (ameen-alam) Pull request description: The http_request target asserted that ReadBody() returns an empty string. That held for the libevent-based http_libevent::HTTPRequest, where the harness only parsed the request line and headers and never populated a body. Commit 9c20859 (PR bitcoin#35182) replaced libevent with http_bitcoin::HTTPRequest, and the target was switched over in e427c22; its LoadBody() now decodes Content-Length and chunked bodies per RFC 9112, so any fully-parsed request carrying a body trips the stale assertion (e.g. "POST / HTTP/1.1\r\nContent-Length: 3\r\n\r\nabc"). Replace the emptiness check with a framing-consistency check that mirrors LoadBody()'s own branch logic: a chunked body is bounded by MAX_BODY_SIZE, a Content-Length body is exactly that many bytes, and a request with neither framing header has no body. This strengthens the target instead of dropping the assertion. **Steps to reproduce (old assertion):** Build the fuzz binary and pass this input as a file to the `http_request` target: `POST / HTTP/1.1\r\nContent-Length: 3\r\n\r\nabc` → `test/fuzz/http_request.cpp:49: Assertion 'body.empty()' failed` **Testing the fix:** Ran the updated target ~16 min under libFuzzer with ASAN/UBSAN (14.2M execs, no crashes), plus targeted inputs for each branch: Content-Length body, chunked, `Transfer-Encoding: identity` + Content-Length, no framing headers, and `Content-Length: 0`. Happy to contribute the repro input to qa-assets as a follow-up. ACKs for top commit: pinheadmz: ACK 7502b9d marcofleon: tACK 7502b9d Tree-SHA512: 4f2eb6bdb3a4556866a84fe0f1d0d8cf506e2efd1b1c7493a99f67ca452b31a140034d418c4064142b1a66c3a6c34b97df0e2b12c21ea86cd4019ffc7cff3b27
…-only fac4b06 refactor: Use CLIENT_NAME in buildOpenRPCDoc (MarcoFalke) fa3aadb refactor: Use self.Arg<bool> in getopenrpcinfo (MarcoFalke) fa1871a refactor: Remove stale NOLINTNEXTLINE above GetAddressInfoBaseFields (MarcoFalke) fa22647 rpc: Properly make RPCResult::Type::ANY non-test-only (MarcoFalke) fa1242d refactor: Use std::visit in ApplyArgFallback (MarcoFalke) Pull request description: Commit 6a1a66c attempted to properly render RPC results of the type `ANY`. However, the commit is incomplete. Fix it, by properly rendering all `ANY` types. Moreover, a few trivial refactors after bitcoin#34683 are included here. ACKs for top commit: sedited: ACK fac4b06 willcl-ark: ACK fac4b06 Tree-SHA512: b77f1956e4feb9afb93d38245491eec190c4538aec7ac57c327fb2efd86c7da6ee8a1406f81fc18fac06bae77a7d38845a537ca0b8f4ae2d94c38eefd8e88dc1
fa8762d build: ci/doc win64-cross build via nix (MarcoFalke) fafe720 doc: Clarify that cygwin/msys2 are not tested/supported (MarcoFalke) Pull request description: Release cross-builds to win64 are done in guix. There are also docs to use Debian/Ubuntu for those cross-builds and this approach is used in CI. However, there are many problems: * The CI is intended to mirror the guix build, but often it is not possible to find the major versions used for mingw and GCC in the guix build in the `apt` packages for an LTS distro. * Users on older distro releases may lack released bugfixes, such as mingw-w64/mingw-w64@8e06daa in mingw 13 (e.g. Debian Trixie with mingw 12, https://packages.debian.org/trixie/mingw-w64-x86-64-dev). * When using the UCRT variant of the build, this uncovers bugs such as https://bugs.launchpad.net/ubuntu/+source/mingw-w64/+bug/2106420 or https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121403. So add a way to use nix to do the cross build. This allows to closer mimic the guix build. Also, clarify that cygwin/msys2 are not tested/supported. ACKs for top commit: willcl-ark: reACK fa8762d hebasto: re-ACK fa8762d. Tree-SHA512: de94f8bc4bb6ed9a75352cd909aa227c5954e336bf9b14969d7412b5cedfbe6cd6b2d8b476d5b1b0bcfc93bdb32fc229015855082350c8c507189e34b9b3ef3f
Integrate MemPoolFeeRateEstimator into FeeRateEstimatorManager. When both estimators succeed, select the lower of the block policy and mempool estimates. When either estimator fails, return its error instead of falling back to the block policy estimate: if the mempool estimator cannot produce an estimate, the combined estimate fails. Callers that want a block-policy-only estimate can request it explicitly via fee_rate_estimator option. estimatesmartfee now emits the estimator field only for successful manager-selected estimates. Add a test that ensures estimatesmartfee returns the mempool fee rate estimate when it is lower than the block policy estimate, and can request the mempool policy estimator explicitly Two wallet functional tests also need adjusting. When the mempool is too sparse to fill its percentile buckets, MemPoolFeeRateEstimator returns a relayable floor of max(min relay fee, mempool min fee), so in regtest getFeeRateEstimate now returns the min relay fee where the wallet previously had no estimate and fell back to a higher rate: - wallet_taproot.py: the cleanup sendall used automatic fee estimation. GetMinimumFeeRate previously fell back to the wallet fallback fee (fallbackfee, 20 sat/vB in the test framework); it now uses the min relay fee floor. At that lower feerate the wallet's underestimate of the taproot script-path witness size drops the effective feerate below min relay, so the transaction is rejected. Pin fee_rate=20 to match the framework fallbackfee. - wallet_bumpfee.py: GetDiscardRate() previously fell back to the wallet discard rate (-discardfee); it now takes the minimum of that and the estimate, so the min relay fee floor collapses the discard rate down to the dust relay feerate. The lower discard rate reduces the cost of change, so the ~614 sat leftover change in test_dust_to_fee is now retained instead of being dropped to fee. Rework the test to leave a sub-dust (20/270 sat) change that is dropped regardless of the discard rate. Co-authored-by: willcl-ark <will@256k1.dev>
Return the removed mempool transaction info from CTxMemPool::removeForBlock instead of dispatching the MempoolTransactionsRemovedForBlock notification from the mempool. Emit it from ConnectTip after mempool removal and before BlockConnected, passing the connected block, the removed mempool transactions, and the block height to the callback. Because the signal now originates from ConnectTip, where the IBD state is known, gate it on !IsInitialBlockDownload(): the notification is no longer fired for blocks connected during initial block download or reindex, while the mempool removal in removeForBlock still runs unconditionally. This keeps fee rate estimators from recording blocks connected before the node is synced.
Gate the mempool fee rate estimator on a coverage check: recent connected blocks must be well represented by transactions removed from our mempool. Track per-block weight for the last MEMPOOL_HEALTH_WINDOW_BLOCKS blocks. AddMinedBlockStats drops stats at or above a connected block's height before appending it, and resets the window on a forward height gap so tracked heights stay consecutive. Only apply the coverage ratio once the window holds at least one block of transactions; below that activity is too low for the ratio to be meaningful, so treat the mempool as healthy. Replace a boolean health check with a MempoolHealth enum so EstimateFeeRate() can report whether estimation is unavailable because too few recent blocks have been tracked (INSUFFICIENT_DATA) or because recent blocks poorly represent the mempool (LOW_COVERAGE).
Add a verbosity option to the existing estimatesmartfee options object. The default verbosity remains 1. When verbosity is at least 2 include mempool_health_statistics in the response. The array reports the mined blocks tracked by the mempool fee rate estimator in most-recent-first order, with each entry containing: - block_height - block_weight: total non-coinbase transaction weight in the block - mempool_txs_weight: weight of transactions removed from our mempool for that block Expose these stats through the fee rate estimator manager so RPC users can inspect the block coverage data used by the mempool health check.
Move block policy fee estimates from fee_estimates.dat to
fees/block_policy_estimates.dat.
On startup, migrate the legacy file to the new path when only the legacy
file exists. If both files exist, keep the new file and remove the
legacy file.
Rename the block policy estimator args source files to the generic
estimator_args.{cpp,h} names and rename FeeestPath to
BlockPolicyFeeEstPath while the path helper is moved into the shared fee
estimator argument code.
Persist MemPoolFeeRateEstimator's recent mined-block statistics to fees/mempool_policy_estimator.dat and reload them at startup. Without this, the mempool estimator starts cold after each restart and treats the mempool as unhealthy until MEMPOOL_HEALTH_WINDOW_BLOCKS blocks have been observed, causing the default combined estimatesmartfee request to return a mempool fee rate estimator error. Files with more stats than MEMPOOL_HEALTH_WINDOW_BLOCKS, non-consecutive block heights, or a final block that does not match the active chain tip are rejected on read, preserving the invariant that loaded stats describe the current chain. Add MempoolPolicyEstimatorPath(), pass the path through FeeRateEstimatorManager, and flush both block-policy and mempool-policy estimator files on interval and shutdown.
Boost.Test registers a `SIGSTKSZ` alternate signal stack as each test binary starts, before any tests run. On musl, this can be smaller than Linux's hardware-dependent minimum, causing `sigaltstack()` to fail with `ENOMEM` during setup. Disable Boost.Test's alternate stack in both test entry points. Signal handlers continue to use the regular process stack. Boost.Test can no longer report stack overflows. Fixes bitcoin#36026 Co-authored-by: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
ef501a6 consensus: document merkle mutation root invariant (Lőrinc) Pull request description: **Problem:** `ComputeMerkleRoot`'s optional mutation flag and the reasoning behind its per-level check are undocumented, and the behavior is only exercised indirectly by merkle_test through random duplications and old-vs-new comparisons, so a refactor could silently change it, as the discussions in bitcoin#22046 and bitcoin#28430 illustrate. **Fix:** Document the flag on the function declaration, explain inside the inner loop why the mutation check runs at every tree level even after a duplicate is found, and add direct API coverage for the CVE-2012-2459 construction. **Coverage check:** Both `merkle_test` and the new `merkle_test_mutated_return_value` would fail under a refactor that stops the outer reduction once mutation is detected, e.g.: <details><summary>Hypothetical regression</summary> ```patch diff --git a/src/consensus/merkle.cpp b/src/consensus/merkle.cpp index dfa23cf..40bc3f8efa 100644 --- a/src/consensus/merkle.cpp +++ b/src/consensus/merkle.cpp @@ -59,6 +59,7 @@ uint256 ComputeMerkleRoot(std::vector<uint256> hashes, bool* mutated) { if (hashes[pos] == hashes[pos + 1]) mutation = true; } } + if (mutation) break; if (hashes.size() & 1) { hashes.push_back(hashes.back()); } ``` </details> Fixes bitcoin#28457 ACKs for top commit: optout21: reACK ef501a6 achow101: ACK ef501a6 w0xlt: reACK ef501a6 hodlinator: ACK ef501a6 Tree-SHA512: 5a54eed071079a0a37333d5ba7c2d8eb81ae318ee4c84e15e3c050198daea6282453d4f7727b75f7dab90696b3d9bc946b8b33e6456a7f190b2297c15aca390c
…util::Expected<void, PSBTError> and remove PSBTError:Ok 6cca38e refactor: remove unused PSBTError::Ok (kevkevinpal) 3660678 refactor: SignPSBTInput now uses util:Expected (kevkevinpal) Pull request description: ### Description This is a follow-up to bitcoin#31622 (comment) and bitcoin#31622 (comment) ### What this changes - Updates `SignPSBTInput` to return `util::Expected<void, PSBTError>` - Removes `PSBTError:Ok` from the `PSBTError` Enum ACKs for top commit: achow101: ACK 6cca38e rkrux: lgtm ACK 6cca38e jeanpablojp: tACK 6cca38e Tree-SHA512: c83b2e7e440aff01becc788e36a732756085f507d447eaa16dd1276d0d0b54070d0d8a51727d553d214043935072586111a175f34338a8d1886a6d5b251de7e4
Replace separate member assignments with construction, using brace initialization so the size_t to CAmount conversions have to be explicit. Use uint32_t for the loop index feeding COutPoint::n, which avoids conversion entirely.
…e expression 950bdb7 bench: Construct CTxOut and COutPoint in a single expression (Alexander Wiederin) Pull request description: Replaces field-by-field mutation of `CTxOut` and `COutPoint` in two bench files with brace initialisation, which requires the `size_t` conversions to be made explicit. Noticed while looking at bitcoin#35994, where switching the proposed fix-it to `{}` surfaces implicit narrowing conversions like these. The constructed values are unchanged. *Note: Only the sites where a conversion is involved are included in this PR; the remaining field-by-field construction in `bench/` would be covered by bitcoin#35994's follow-ups.* ACKs for top commit: l0rinc: code review ACK 950bdb7 maflcko: review ACK 950bdb7 🐯 Tree-SHA512: c664d41eeeb9241d381e5fa27689f18d9445a942055734463978498f60d0f2c495a0d7a58131493bb63267371bb6fe2d45ac124d910c919c8905322948d17a23
…reduce overestimation 7f9c4e2 doc: add release notes (ismaelsadeeq) e18d392 test: add mempool estimator i/o fuzz test (ismaelsadeeq) 970f020 fees: persist mempool policy estimator data (ismaelsadeeq) 7dcb379 fees: move fee_estimates.dat into fees directory (ismaelsadeeq) 0db2b69 rpc: add verbosity option to estimatesmartfee options (ismaelsadeeq) 06bb657 fees: gate mempool estimates on recent block coverage (ismaelsadeeq) cfe585d validation: emit block mempool removal signal from ConnectTip (ismaelsadeeq) 0d88558 fees: return mempool estimates when it's lower than block policy (ismaelsadeeq) 693b135 fees: add caching to MemPoolFeeRateEstimator (ismaelsadeeq) c9bb3df fees: add MemPoolFeeRateEstimator class (ismaelsadeeq) 9cacf67 rpc: add fee_rate_estimator option to estimatesmartfee (ismaelsadeeq) ba6c61b fees: add FeeRateEstimatorManager class (ismaelsadeeq) 2cb6b83 fees: add EstimateFeeRate and MaximumTarget to CBlockPolicyEstimator (ismaelsadeeq) 5adb2ab refactor: test block policy estimator directly (ismaelsadeeq) 9c8309a test: rename policy estimator tests to block policy estimator tests (ismaelsadeeq) e3d5ef1 fees: move StringForBlockPolicyEstimateReason to block policy estimator (ismaelsadeeq) 74245c2 fees: split wallet and estimator fee reasons (ismaelsadeeq) Pull request description: This PR is another attempt to fix bitcoin#27995 using a better approach. For background and motivation, see bitcoin#27995 and the discussion in the Delving Bitcoin post [Mempool Based Fee Estimation on Bitcoin Core](https://delvingbitcoin.org/t/mempool-based-fee-estimation-on-bitcoin-core/703). This PR is currently limited to using the mempool only to lower what is recommended by the Block Policy Estimator. Accurate and safe fee estimation using the mempool is challenging. There are open questions about how to prevent mempool games that are theoretically possible for miners [(a variant of the Finney attack)](https://delvingbitcoin.org/t/mempool-based-fee-estimation-on-bitcoin-core/703/6). This is one reason this PR uses the mempool only to lower the Block Policy Estimator result. The Block Policy Estimator itself is not gameable in this way, so the combined estimate is not susceptible to this attack increasing the returned feerate. The underlying assumption is that, with the current tools and work done to make RBF and CPFP feasible and reliable (TRUC transaction relay, ephemeral anchors, cluster size 2 package RBF), underestimation is safer than overestimation. We now assume it is relatively easy to fee-bump later if a transaction does not confirm, whereas once a fee is overestimated there is no way to recover from that. Another open question when using the mempool for fee estimation is how to account for incoming transaction inflow. [Bitcoin Augur](https://github.com/block/bitcoin-augur) does this by using past inflow plus a constant expected inflow to predict future inflow. I find this unconvincing for fee estimation and potentially prone to more overestimation, as past conditions are not always representative of the future. See my [review of the Augur fee rate estimator and open questions](block/bitcoin-augur#3). This PR uses a much simpler approach based on current user behavior, similar to the widely used method employed by mempool.space: looking at the top block of the mempool and selecting a percentile feerate depending on whether the user is economical or conservative. Empirical data from both myself and Clara Shikhelman shows that the 75th percentile feerate for economical users and the 50th percentile feerate for conservative users provide positive confirmation guarantees, hence this is what is used in this PR. Parallel research by Rene Pickhardt and his student suggests that using the [average fee per byte of the block template performs well](https://delvingbitcoin.org/t/mempool-based-fee-estimation-on-bitcoin-core/703/12). All of these are constants that can be adjusted. There is parallel work exploring these constants and running benchmarks across fee estimators to find a sweet spot. See also work in LND, the [LND Budget Sweeper](https://delvingbitcoin.org/t/lnds-deadline-aware-budget-sweeper/1512), which applies this idea successfully. Their approach is to estimate fees initially with bitcoind, then increment gradually as the confirmation deadline approaches, using a fixed fee budget. Historical data indicates that this PR's approach can [reduce overestimation quite significantly (~29%)](https://delvingbitcoin.org/t/mempool-based-fee-estimation-on-bitcoin-core/703/8). This is particularly useful in scenarios where the Block Policy Estimator recommends a high feerate while the mempool is empty. <img width="1800" height="1090" alt="56f3ba26c0184521c42bb82ec9d8c9f2224d4f8e" src="https://github.com/user-attachments/assets/c035c40c-8ece-42a7-b290-d29f1ac9bf4d" /> As seen in the image above, there is only one remaining unfixed case: when there is a sudden inflow of transactions and the feerate rises, the Block Policy Estimator takes time to reflect this. In that case, users will continue to see a low feerate estimate until it slowly updates. From the historical data linked above, [this occurs about ~26% of the time](https://delvingbitcoin.org/t/mempool-based-fee-estimation-on-bitcoin-core/703/8). Overall, we observe a **73% success rate with 0% overestimation, and 26% underestimation** with this approach. See https://bitcoincorefeerate.com/stats for recent running stats that have almost identical data. This PR also includes refactors that enable this work. Rather than splitting the PR and implementing changes incrementally, I opted for an end-to-end implementation: ### 1. Refactors * Split the mixed fee reason enum into separate wallet and block policy concepts. The wallet now has a `FeeReason` enum for why the wallet selected a fee rate (`FEE_RATE_ESTIMATOR`, `MEMPOOL_MIN`, `USER_SPECIFIED`, `FALLBACK`, `REQUIRED`), while the Block Policy Estimator uses `BlockPolicyEstimateReason` for its internal threshold details. * Move `StringForBlockPolicyEstimateReason` to the Block Policy Estimator code, keeping the estimator-specific strings with the estimator. * Move detailed Block Policy Estimator logging out of wallet transaction creation and into the estimator path. Wallet transaction creation now logs the selected fee and wallet fee reason instead of leaking estimator internals. * Keep the wallet RPC `fee_reason` field name for compatibility, but update its meaning to report the wallet fee reason instead of the Block Policy Estimator's internal threshold reason. * Rename policy estimator tests and files to block-policy-specific names where appropriate. * Update Block Policy Estimator unit tests to be independent of the mempool and validation interface. ### 2. Introduce Mempool-Based Fee Estimator and Fee Estimator Manager * Introduce `FeeRateEstimation` and `FeeRateEstimationError` as common estimator result types, avoiding new out-parameters for fee estimation results. * Add `FeeRateEstimatorType` to identify the estimator that produced a result. * Add `FeeRateEstimatorManager`, responsible for owning the Block Policy Estimator and Mempool Fee Rate Estimator. * Update the node context to store a `std::unique_ptr` to `FeeRateEstimatorManager` instead of `CBlockPolicyEstimator`. * Update `CBlockPolicyEstimator` to no longer subscribe directly to the validation interface; instead, `FeeRateEstimatorManager` subscribes and forwards relevant notifications. * Add a mempool fee estimator that generates a block template when called, calculates a percentile feerate, and returns the 75th percentile for economical mode or the 50th percentile for conservative mode. * When the selected estimate is below the node's fee floor, `estimatesmartfee` still returns at least the max of `mempoolminfee` and `minrelaytxfee`. * Add caching to the mempool estimator so new estimates are generated at most every 7 seconds while the chain tip is unchanged, assuming enough [transactions have propagated](https://bitcoin.stackexchange.com/questions/125776/how-long-does-it-take-for-a-transaction-to-propagate-through-the-network/125777#125777) to make a meaningful difference. This heuristic will likely be replaced by requesting block templates via the general-purpose block template cache proposed here: bitcoin#33389 * Update `MempoolTransactionsRemovedForBlock` to receive the connected block as well as the transactions removed from the mempool. * Track the weight of block transactions and mempool transactions removed due to block connection after each block connection. This data is tracked for the last 6 mined blocks. A mempool feerate estimate is returned only when the ratio of mempool transaction weight removed due to block connection to block transaction weight is greater than 75% across the tracked window. This heuristic provides rough confidence that the node's mempool matches that of the majority of the hashrate. The 75% threshold is arbitrary and can be adjusted. There is a caveat when transactions in the local mempool are consistently not mined by the network, as described in bitcoin#27995 (e.g. due to filtering). Accounting for these transactions during fee estimation is not necessary, as they should be evicted from the mempool itself (see bitcoin#33510). Handling this again within fee estimation would be redundant. * Persist statistics for the 6 most recent mined blocks to `fees/mempool_policy_estimator.dat` during periodic flushes and shutdown, so this data is available after restarts. * Move Block Policy Estimator data from `fee_estimates.dat` to `fees/block_policy_estimates.dat`, migrating the legacy file during startup when needed. * Add `fee_rate_estimator` to the `estimatesmartfee` options object. Supported values are `"none"` (default combined behavior), `"block_policy"` (use only the Block Policy Estimator), and `"mempool_policy"` (use only the Mempool Fee Rate Estimator). Unknown values are treated as `"none"`. * Add `verbosity` to the `estimatesmartfee` options object. With `verbosity >= 2`, the RPC returns recent mempool health statistics. * Expose the selected fee rate estimator in `estimatesmartfee` results when `fee_rate_estimator` is `"none"` and the estimate succeeds. * Add unit, functional, and fuzz test coverage for the new estimator behavior, persistence, RPC options, and estimator I/O. <details> <summary>see example output</summary> ```bash bitcoin-cli estimatesmartfee 1 economical '{"verbosity": 2, "fee_rate_estimator": "none"}' ``` ```json { "feerate": 0.00002133, "estimator": "mempool_policy", "blocks": 2, "mempool_health_statistics": [ { "block_height": 927953, "block_weight": 3991729, "mempool_txs_weight": 3942409 } ] } ``` </details> ACKs for top commit: willcl-ark: reACK 7f9c4e2 jsarenik: Approach ACK 7f9c4e2 Tree-SHA512: c35b423eea0eb34524cf5ad07822c0ab8d53e2ab78965b58c8738044c61c77352184822360ed077a51bfbf83d0226d221e988f7156b1948023707c7e1fb31495
9eba3aa test: avoid undersized Boost.Test signal stacks (Lőrinc) Pull request description: **Problem:** Boost.Test can fail while an Alpine CI test binary is starting, before any tests run. The required signal stack size depends on the runner's CPU features, while musl provides a fixed size. **Fix:** Use the [regular process stack](https://www.boost.org/doc/libs/latest/libs/test/doc/html/boost_test/utf_reference/link_references/config_disable_alt_stack.html) for Boost.Test signal handling in both unit-test binaries. Fixes bitcoin#36026 ACKs for top commit: maflcko: lgtm ACK 9eba3aa Tree-SHA512: 177a31ab325f4ebce0ad7e4679b171cd5a28787595bf0e117fc66731b8bf9157c4f5bef74cc6bb7651021bafb616fe5e9a25709abf30b7689d10ddd0fbd484cb
dd669f4 util: set os-level thread names on Windows (ViniciusCestarii) Pull request description: Update SetThreadName to set os-level thread names on Windows too. This is useful for debugging-ergonomics on Windows. Threads currently show up unnamed in debuggers, crash dumps on Windows and mismatch what's documented under https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#threads. Tested with the mingw cross build running on Windows 11, print from WinDbg: <img width="713" height="631" alt="image" src="https://github.com/user-attachments/assets/05e03383-c9b1-4e6b-91f3-9088b2fc7e90" /> ACKs for top commit: l0rinc: code review ACK dd669f4 hebasto: ACK dd669f4, tested Guix-built `bitcoind.exe` on Windows 11 Pro using WinDbg: winterrdog: utACK dd669f4 Tree-SHA512: 3632584f5f0612414a53ad6d868b9f832e8e7f1fad19f212f292172a4a6516f6e0055ec6ac8fbb71b22acdd003d09c9a5f97c0c15a137e1ad242580f997aca6f
9d0c38d ci: use mypy 2.3.1 (fanquake) 7a53bec ci: use pyzmq 27.2.0 (fanquake) f29f076 ci: use ruff 16 (fanquake) Pull request description: Also use mypy `2.3.1` and pyzmq `27.2.0`. ACKs for top commit: willcl-ark: ACK 9d0c38d janb84: ACK 9d0c38d maflcko: lgtm ACK 9d0c38d Tree-SHA512: 819fa465d34dd1c3de1753f4b7227a2f7217b108b5a4e4d3ff0527d2273140c9c0bf973b9fc8c60791bfe89dc1e7ed0fa17da8797cebe74fafb3a0b810c603bf
73a94b4 psbt: avoid aborting on invalid MuSig2 derivations (Lőrinc) e3d1e75 test: characterize MuSig2 derivation aborts (Lőrinc) Pull request description: **Problem:** A PSBT may contain MuSig2 derivation metadata with a hardened child index or a path that derives to a different key. The hardened index aborts during public derivation, while the mismatched key aborts at the result assertion. `analyzepsbt`, `finalizepsbt`, and `descriptorprocesspsbt` all reach this code without a wallet. Even the read-only `analyzepsbt` can force a co-signer service to restart its node after unexpected input. **Fix:** Return failure when a MuSig2 derivation path contains a hardened child index, and skip only the current aggregate when the path derives to a different key so another matching aggregate can still be tried. This follows [bitcoin#35154](bitcoin#35154), with the related contributions credited in the commits. ACKs for top commit: jeanpablojp: ACK 73a94b4 achow101: ACK 73a94b4 andrewtoth: ACK 73a94b4 Tree-SHA512: d8e28c5a4184154a4427c644ce62423cbcccdc3d82a6293f36fe99055fa04714598bc92c43b526fbcc7c99b231140669c2d0f1b853999d7dc33f949564c90504
…t block weight limit 5be2483 bugfix: compare real chunk weight against block weight limit (ismaelsadeeq) fc98790 test: `TestChunkBlockLimits` uses incorrect weight for comparison (ismaelsadeeq) Pull request description: Partially fixes bitcoin#35596 When assembling a block template, `BlockAssembler::addChunks()` adds chunks of transactions until the block is close to being full. For each chunk, `TestChunkBlockLimits()` checks both the weight and the sigop-cost limits before the chunk is included. The weight check compared the chunk's **sigops-adjusted** weight against `block_max_weight`: ```cpp if (nBlockWeight + chunk_feerate.size >= m_options.block_max_weight) { return false; } ``` Whereas `nBlockWeight` accumulates the actual chunk weight. A chunk whose sigop-adjusted weight exceeds the actual weight can be wrongly skipped even though the block sigop limit is enforced independently on the next line, and that could pass. Those chunks pay higher fees, so this could potentially cause miners to needlessly forfeit some fees revenue. This PR fixes this by passing the chunk's real weight (sum of `GetTxWeight()`, accumulated in the same loop that already sums sigop cost) to `TestChunkBlockLimits()`. The separate sigop-cost check is unchanged. - The first commit adds `TestSigOpsAdjustedWeightChunkLimit`: it builds one sigop-dense transaction sized to fit by real weight but not by adjusted weight, and asserts that the tx is skipped and only the coinbase is mined. - The second commit applies the fix and flips the assertion to show the transaction is now included. ACKs for top commit: pablomartin4btc: Code Review ACK 5be2483 sedited: ACK 5be2483 Tree-SHA512: b3fe9bfaa6d83d713d0243c0fc0d0fb8e68e1060bf6d606e43d9a52bd1ec07e42c561a1ba3426f180903726826c4a664bb131ddc5160354a96e3454d538fbf6c
bd4b152 init: do not count file descriptors for HTTPServer if -server=0 (Matthew Zipkin) b086620 init: account for maximum file descriptors needed by HTTP (Matthew Zipkin) cc2aceb http: configure simultaneous connection limit with -rpcmaxconnections (Matthew Zipkin) b3d6d2d http: limit connected clients to 16 (Matthew Zipkin) 86651d8 scripted-diff: Rename nUserBind, nBind, nMaxConnections to snake_case (Matthew Zipkin) Pull request description: Introduces a new configuration option `-rpcmaxconnections` with default value `16`. This is used to limit the number of simultaneous `HTTPClient` connected to the `HTTPServer`. When the limit is reached, new pending connections remain queued in the kernel's socket buffer. Those connections have complete TCP handshakes with the kernel but do not occupy any application memory. The previous libevent-based HTTP server had no limit on connections but it did have a limit on the kernel socket queue: https://github.com/libevent/libevent/blob/e7ff4ef2b4fc950a765008c18e74281cdb5e7668/http.c#L3510 ```c if (listen(fd, 128) == -1) { ``` The current HTTP server, like the p2p server, uses a platform constant here: https://github.com/bitcoin/bitcoin/blob/b6becf3534c7b7f1b4d356a8f6113d62b6dd05bf/src/httpserver.cpp#L743 (on my macOS `SOMAXCONN` is `128` but on my Debian machine it's `4096`) The default of 16 was chosen as a reasonable upper bound for single-user RPC use cases. Systems designed to handle more simultaneous HTTP connections than this (previously relying on the absence of a limit) can adjust the setting. ## File descriptors Because of the connection limit, we can now account for the maximum number of file descriptors needed by the HTTP server. This addresses several issues (bitcoin#11368 bitcoin#11322 maybe bitcoin#27732) that could have been fixed by a PR waiting in vain for a libevent release (bitcoin#27731). ## Bonus performance improvement The new limit is managed in a loop that drains the kernel's socket queue with `accept()`. All pending connections from the queue (up to the limit) are processed in one single call to `SocketHandlerListening()`. The previous code would only accept one connection from the queue on each I/O loop tick, with a `SELECT_TIMEOUT` (50ms) sleep between each. ACKs for top commit: fjahr: tACK bd4b152 janb84: ACK bd4b152 winterrdog: tested ACK bd4b152 hodlinator: Concept ACK bd4b152 willcl-ark: ACK bd4b152 Tree-SHA512: 2ef7a96da4d7037c7343ec0ea03fda5bb55d10c2a071fce4929141297515923b203d3d338dbcb6599849768f52aa3c9da509fb5d1d6f7c574a1d2034ea2a9e74
… doubled PSBT origin paths b42f7fa descriptor: don't prepend key origins twice (Shuvam Pandey) 7b15e2c descriptor: fix duplicate check for hardened keys (Shuvam Pandey) Pull request description: Fixes bitcoin#34273. Importing a descriptor that uses the same `musig()` participants twice in one tapleaf, with different musig subderivations, fails with `is not sane: contains duplicate public keys`. It only fails when one of the participants is a private key on a hardened path. The all-xpub version of the same descriptor imports fine. That's what gave it away. The duplicate check (`KeyCompare`) resolves each key expression to a pubkey and compares the results. It does this at index 0, and the old code used an empty signing provider. With that empty provider, a `musig()` expression can't resolve when one of its participants is on a hardened path, because deriving that participant needs its private key, so the whole aggregate key comes back empty. Two different musig expressions both came back empty, so the check treated them as duplicates. The fix derives against the signing provider populated during parsing, which holds the private keys, and only compares the expression strings when neither side resolves. 151henry151 had suggested looking at the empty signing provider on the issue. scgbckbone found a second, separate bug in the same descriptors. When another expression that reuses those participants is handled in the same expansion, its participant origin in the PSBT is added twice, so `m/86h/1h/0h` becomes `m/86h/1h/0h/86h/1h/0h` in both the input and output Taproot BIP32 derivation maps. `OriginPubkeyProvider::GetPubKey()` now derives into a temporary provider, merges it, and writes the corrected origin once, so a later expression can't prepend the same origin again. Tested: ``` ./build/bin/test_bitcoin --run_test=descriptor_tests ./build/bin/test_bitcoin --run_test=miniscript_tests ./build/bin/test_bitcoin --run_test=bip328_tests ./build/bin/test_bitcoin --run_test=psbt_wallet_tests ./build/test/functional/test_runner.py wallet_musig.py --jobs=1 ``` ACKs for top commit: achow101: ACK b42f7fa scgbckbone: ACK b42f7fa Tree-SHA512: ab36caa6bc484fa1fc3289c79e9a3d713278d82f80de478e53e1bdbe645037e07776ac798eba085733abc139c11a9dbf0d3f49d3c0eee9632e4ddf33d2242f92
…ss_messages fae6665 fuzz: Use ImmediateBackgroundTaskRunner in process_messages (MarcoFalke) Pull request description: The `process_messages` target may complain about false-positive debug lock-order issues: ``` echo 'Gv8uXPBdXV0QEP//dHVhxyoVKP////8A/0BrLmNrAEEAIP+MXHR0OQAAAAD+///txgIUADBgAAEC fgAAAK0ArQEAAAD/AFwAQf9cdHf5XGhlYWRlcltbyzHIw8RcX2Jsb2NrAAAAAGNtcAAAADAftOvd D0sFqXEx6US5VIknlsOJqZ5goMwtmwZBPdCxQZbatBsWPOR3FcUvSLLsKwcgKT8XdmjvDgskH5pK iAUI/uVJTf//fyAAAAAAAQIAAAAAAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// //8DAskA/v///wIA+QKVAAAAAAFRAAAAAAAAAAAmaiSqIant4vYcP3HR3v0/qZnfo2lTdVxcaQaJ eZlitIvr2DaXToz5ASAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMgAAAD/XPB0eAD/ AgAAAAD9ABZqCwAAAAAEAAAAXPBhYVtbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tb W1tb//9bW1tbW1tbW1sAAAAxNgAAADc5MzU5NDk2ODEwNzg3NAAAAAICAgL9a4jAhyQCAgICAQAA AAAABSpvdGhlcir/8wICAgICAAAAeAL0AAAAAAAAaW52O///BAAAAAAAtbW1tWFbW2FhtbVhYWFh YSkpW1tbW2QAJwAAAAAAAAAAMTYAAAA3OTM1OTQ5NjgxMDc4NzQAAAACAgIC/WuIwIckAgICAgEA AAAAAAUAAAAAAv7///MAeAL0AAAAAAAAaW52Ow==' | base64 --decode > /tmp/fuzz.input FUZZ=process_messages ./bld-cmake/bin/fuzz /tmp/fuzz.input --printtoconsole=1 | grep -A99 'POTENTIAL DEADLOCK DETECTED' ``` ``` [test] [sync.cpp:108] [potential_deadlock_detected] [error] POTENTIAL DEADLOCK DETECTED [test] [sync.cpp:109] [potential_deadlock_detected] [error] Previous lock order was: [test] [sync.cpp:118] [potential_deadlock_detected] [error] 'NetEventsInterface::g_msgproc_mutex' in test/fuzz/process_messages.cpp:89 (in thread 'test') [test] [sync.cpp:118] [potential_deadlock_detected] [error] 'm_chainstate_mutex' in validation.cpp:3351 (in thread 'test') [test] [sync.cpp:118] [potential_deadlock_detected] [error] 'cs_main' in validation.cpp:3373 (in thread 'test') [test] [sync.cpp:118] [potential_deadlock_detected] [error] (2) 'MempoolMutex()' in validation.cpp:3376 (in thread 'test') [test] [sync.cpp:118] [potential_deadlock_detected] [error] (1) 'm_tx_download_mutex' in net_processing.cpp:2216 (in thread 'test') [test] [sync.cpp:122] [potential_deadlock_detected] [error] Current lock order is: [test] [sync.cpp:133] [potential_deadlock_detected] [error] 'NetEventsInterface::g_msgproc_mutex' in test/fuzz/process_messages.cpp:89 (in thread 'test') [test] [sync.cpp:133] [potential_deadlock_detected] [error] 'cs_main' in net_processing.cpp:4725 (in thread 'test') [test] [sync.cpp:133] [potential_deadlock_detected] [error] (1) 'm_tx_download_mutex' in net_processing.cpp:4725 (in thread 'test') [test] [sync.cpp:133] [potential_deadlock_detected] [error] (2) 'cs' in txmempool.h:521 (in thread 'test') ``` Fix this by using the `ImmediateBackgroundTaskRunner` from `src/test/fuzz/cmpctblock.cpp`. ACKs for top commit: Crypt-iQ: ACK fae6665 sedited: ACK fae6665 marcofleon: tACK fae6665 frankomosh: Tested ACK fae6665 Tree-SHA512: 9cee43aa72495abfd69211004b27ee6857d3a1a6bbab9fdc5a8b5349159a54e270236f198a516a7d9087917af8c95ee626e8307155ded8d08314a6b606dd0c33
In ParsePubkeyInner, every extended key required two full base58 decodes: once via DecodeExtKey and again via DecodeExtPubKey, even though at most one can succeed. Replace both calls with a new DecodeExtKeyOrPubKey helper that performs a single DecodeBase58Check and dispatches on the 4-byte version prefix to populate either the xprv or xpub result. Also eliminate the per-key std::string allocation in ParsePubkeyInner by switching the local 'str' variable to std::string_view over the existing span, and update DecodeSecret / DecodeExtKey / DecodeExtPubKey to accept std::string_view directly (std::string and const char* callers are unaffected via implicit conversion). To allow the string_view path all the way down, the internal base58 decoder is refactored from null-terminated const char* to a (psz, end) pointer pair, replacing strlen() and *psz null checks with pointer comparisons. The public DecodeBase58 / DecodeBase58Check APIs now take std::string_view as well.
… table Replace the O(n) linear INPUT_CHARSET.find() in DescriptorChecksum with a precomputed 256-entry lookup table, reducing the checksum pass from O(95 * len) to O(len).
brunoerg
force-pushed
the
2026-04-descriptor
branch
from
August 24, 2026 14:27
6dd023a to
0339b33
Compare
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.
This PR speeds up descriptor parsing, for basically descriptors that use xpub/xpriv, through some targeted improvements:
Avoid redundant base58 decoding when parsing extended keys (this is the major improvement)
ParsePubkeyInner unconditionally called both DecodeExtKey() and DecodeExtPubKey(), each running a full DecodeBase58Check (two SHA256 passes over ~111 bytes). A new DecodeExtKeyOrPubKey() function performs a single base58 decode and then checks the prefix, halving the cryptographic work per key. The interfaces of DecodeSecret, DecodeExtKey, and DecodeExtPubKey are also updated to accept string_view instead of const std::string&, eliminating unnecessary string copies in the descriptor parser and allowing DecodeBase58/DecodeBase58Check to use pointer-range iteration instead of strlen.
Replace O(n) charset lookup with precomputed table
DescriptorChecksum previously called std::string::find() for every character in the descriptor string, doing up to 96 comparisons per character. This replaces it with a 256-entry precomputed lookup table for O(1) lookups. The benefit scales with descriptor length.
Parse()with the following descriptor:tr(xpub6CGCzpvrZVssNNXuP1Awcz8GoakYyJHra2WHASXfCzsD9szbQFoT1pLMdQopyqaSqXUprH7fkk8NG2pUbQa5HpNzpWmEsdNZDHxXvSLPTrn/*,{{multi_a(20,xpub6CGCzpvrZVssNNXuP1Awcz8GoakYyJHra2WHASXfCzsD9szbQFoT1pLMdQopyqaSqXUprH7fkk8NG2pUbQa5HpNzpWmEsdNZDHxXvSLPTrn/*,xpub6C5MW95EE8hAmxm96LdAFYkweaAktQoojCf2MwJmNL9Fi6oUPeBnpFdEzhs9zHwr4HQEeF1r1yAUR8MqDJqk4YPteh75rNoCKCtud7shDDk/*,xpub6DNEUJP1zLAZ1P6gYRba9FyxuppmkrPmSKz3FLM7msRwn2LEr4LnKfAnNoSoAbnbW2orTfsitdfWTxLbJCZ6LizqV7cFUavSAjWzNjqdfCP/*,xpub6Cm5sAgCZQvYtnatYPdFuLhsD9VtgY3Rtt48TrdgqXm4DttXfM6nFmFTko8KcyGhPswTvPcTzfpMUvqV3F9tgLPvzfzoKwjmU668vBmGXEX/*,xpub6DN66R61Luv95HLvznR2ZWsbYuGBoK9LDR6XiNm1pvp5zRJ2vFhLQ4PBe2pDn59sKmRnEFbdLtBVZFN3QAujcGZ5PomGCvrnisxkP2fcgHg/*,xpub6D2GtAtYodmjwEoAzorKUta44NDvAB4JjafYXxsQ5hTWvCAK55nnkyNHfdjrsx3umfgGe1nnHut13mLuFqqi2fs7VVyv6rht76ddrDGhrTY/*,xpub6Bfi8jsDMuu2XHQ1TGRB6ehjdHKKmTwRFQYU6QcgHoZswqbzKsXs9Qd87nAxevjZwuQ37jaVnQoPF6wY34BJoeLxXkEYMpKz2CBHLcEmJVF/*,xpub6CYiNdQesStiBwZkWjPBxwxxf6oPMH9meBMujCwBX74X8nCpMF9zRZUbDrU9raQah1LQcnzLQrHC6Kr6LNCmsBpaMkYD3U6FyhHZfTHQGUB/*,xpub6CddszJHLa3VisZ6ufU4hiFcGsuuPHo7hYa24o3kPuPfAbMED4ajuDa6svuqxxBxYgUQhN8LK7MtTMetquNo7YsWhiV8hX2gBfjszJVXgkG/*,xpub6DAM262AxC4Um3rxBiP5FoA7SJJG3a7MjaJkEyXWyMA6iNuyqWueKZHSSNjKEWnn8Wi3PUQNTV1Z3a59C2Qaidha88GTWtAMhJBAWBBvuTN/*,xpub6ByZcsLsr8xTCJmYxvLpLrsFzuHNXRLR4xMyB9ZFLek1hDVh7zba2xAVTU8M6eonFFAAPYpTA76bDuopF5zyBkZqFc3rtJ3ziH1BUXkjC6j/*,xpub6Bx2LErujvR1noXrk7RHQB9htiDcPM5qYuV7Jg1nZh5jWeK8pYB4DnYQ73EX9sB9M6rnNsF8LDPUejHiXrBx2JJQSdVQ9i9FfEzJLuAnzEd/*,xpub6DSBog1uLngjBWVDUpLTQ19jGGKovgc3iTd1ijL4fjk9sgNqrnG5kGLjUWncay2jbqdgt6yrbYSHhfwsTMp7i8pUD1FMCQuFyqdsZpgUNH8/*,xpub6C53ov8LpuGp5MM4ghqUFJcdTnXJCRHyXaz1RVCys2uQErpdzUWHtm8Bsg8NJyaqfhGWvm9WPSE7jMneCRw1xs1CTajpToXyRqSCc41JiuY/*,xpub6CscWPNXdEybbJVvx7fJTrfHyTkKZtb97qcpQ9fH4k4xtm4nkckSpvy86heQsdyoF28CugwLHg5kLDwpGoPQAYXQ3RG9cJB2Na1FdeN1wt5/*,xpub6Cmrivt6w3kVAxw7NmcKSY19gSLmC2tVwx46cdigr9d1UEnttJCGZJ7NQu1MkugpZgF9rQ3j3NKUiZ2MoaC2QoZUfi4nwxbpH39SQZaBHut/*,xpub6D1Ey5JAYnBxFE8i2V2SUsEpJt7r3ykJKcShcpT2xN9CXtVQy5dKeYiZ9D1bdnkPrmgEajrSuA5nWqf94s6u7FwvXy3cU4BXUMgAt9C8wGT/*,xpub6CwJ2vicnoSJNFDzhonucHNVHDwyb1vyiu2VF6zmjQrzGb4qoAma1i2QJ7qRNe1qmpvvWwzSuQDgMnCECFQhZaPKuPFjcMo33r2xenBauxf/*,xpub6CiLNz8mFB4fB51x6gMNu44Up9PyVhq7fSxQb8UzYQermvMShwWyqzQe99Uiyxpfy1ow42xUGpPGBHf8ErxDbQojBf7Uy7hKFgYk8KpgMm2/*,xpub6DQ2qVMZ2o2QGGpYDsw5hpAcygNVEycAkkCib2Lexwm8gYWMCSecZ256AbAV93Rgze6h8yEoTcqUnvnz7L69WUqp7cXd85X8HoeKWjPHRRZ/*),multi_a(20,xpub6CGCzpvrZVssNNXuP1Awcz8GoakYyJHra2WHASXfCzsD9szbQFoT1pLMdQopyqaSqXUprH7fkk8NG2pUbQa5HpNzpWmEsdNZDHxXvSLPTrn/*,xpub6C5MW95EE8hAmxm96LdAFYkweaAktQoojCf2MwJmNL9Fi6oUPeBnpFdEzhs9zHwr4HQEeF1r1yAUR8MqDJqk4YPteh75rNoCKCtud7shDDk/*,xpub6DNEUJP1zLAZ1P6gYRba9FyxuppmkrPmSKz3FLM7msRwn2LEr4LnKfAnNoSoAbnbW2orTfsitdfWTxLbJCZ6LizqV7cFUavSAjWzNjqdfCP/*,xpub6Cm5sAgCZQvYtnatYPdFuLhsD9VtgY3Rtt48TrdgqXm4DttXfM6nFmFTko8KcyGhPswTvPcTzfpMUvqV3F9tgLPvzfzoKwjmU668vBmGXEX/*,xpub6DN66R61Luv95HLvznR2ZWsbYuGBoK9LDR6XiNm1pvp5zRJ2vFhLQ4PBe2pDn59sKmRnEFbdLtBVZFN3QAujcGZ5PomGCvrnisxkP2fcgHg/*,xpub6D2GtAtYodmjwEoAzorKUta44NDvAB4JjafYXxsQ5hTWvCAK55nnkyNHfdjrsx3umfgGe1nnHut13mLuFqqi2fs7VVyv6rht76ddrDGhrTY/*,xpub6Bfi8jsDMuu2XHQ1TGRB6ehjdHKKmTwRFQYU6QcgHoZswqbzKsXs9Qd87nAxevjZwuQ37jaVnQoPF6wY34BJoeLxXkEYMpKz2CBHLcEmJVF/*,xpub6CYiNdQesStiBwZkWjPBxwxxf6oPMH9meBMujCwBX74X8nCpMF9zRZUbDrU9raQah1LQcnzLQrHC6Kr6LNCmsBpaMkYD3U6FyhHZfTHQGUB/*,xpub6CddszJHLa3VisZ6ufU4hiFcGsuuPHo7hYa24o3kPuPfAbMED4ajuDa6svuqxxBxYgUQhN8LK7MtTMetquNo7YsWhiV8hX2gBfjszJVXgkG/*,xpub6DAM262AxC4Um3rxBiP5FoA7SJJG3a7MjaJkEyXWyMA6iNuyqWueKZHSSNjKEWnn8Wi3PUQNTV1Z3a59C2Qaidha88GTWtAMhJBAWBBvuTN/*,xpub6ByZcsLsr8xTCJmYxvLpLrsFzuHNXRLR4xMyB9ZFLek1hDVh7zba2xAVTU8M6eonFFAAPYpTA76bDuopF5zyBkZqFc3rtJ3ziH1BUXkjC6j/*,xpub6Bx2LErujvR1noXrk7RHQB9htiDcPM5qYuV7Jg1nZh5jWeK8pYB4DnYQ73EX9sB9M6rnNsF8LDPUejHiXrBx2JJQSdVQ9i9FfEzJLuAnzEd/*,xpub6DSBog1uLngjBWVDUpLTQ19jGGKovgc3iTd1ijL4fjk9sgNqrnG5kGLjUWncay2jbqdgt6yrbYSHhfwsTMp7i8pUD1FMCQuFyqdsZpgUNH8/*,xpub6C53ov8LpuGp5MM4ghqUFJcdTnXJCRHyXaz1RVCys2uQErpdzUWHtm8Bsg8NJyaqfhGWvm9WPSE7jMneCRw1xs1CTajpToXyRqSCc41JiuY/*,xpub6CscWPNXdEybbJVvx7fJTrfHyTkKZtb97qcpQ9fH4k4xtm4nkckSpvy86heQsdyoF28CugwLHg5kLDwpGoPQAYXQ3RG9cJB2Na1FdeN1wt5/*,xpub6Cmrivt6w3kVAxw7NmcKSY19gSLmC2tVwx46cdigr9d1UEnttJCGZJ7NQu1MkugpZgF9rQ3j3NKUiZ2MoaC2QoZUfi4nwxbpH39SQZaBHut/*,xpub6D1Ey5JAYnBxFE8i2V2SUsEpJt7r3ykJKcShcpT2xN9CXtVQy5dKeYiZ9D1bdnkPrmgEajrSuA5nWqf94s6u7FwvXy3cU4BXUMgAt9C8wGT/*,xpub6CwJ2vicnoSJNFDzhonucHNVHDwyb1vyiu2VF6zmjQrzGb4qoAma1i2QJ7qRNe1qmpvvWwzSuQDgMnCECFQhZaPKuPFjcMo33r2xenBauxf/*,xpub6CiLNz8mFB4fB51x6gMNu44Up9PyVhq7fSxQb8UzYQermvMShwWyqzQe99Uiyxpfy1ow42xUGpPGBHf8ErxDbQojBf7Uy7hKFgYk8KpgMm2/*,xpub6DQ2qVMZ2o2QGGpYDsw5hpAcygNVEycAkkCib2Lexwm8gYWMCSecZ256AbAV93Rgze6h8yEoTcqUnvnz7L69WUqp7cXd85X8HoeKWjPHRRZ/*)},{multi_a(20,xpub6CGCzpvrZVssNNXuP1Awcz8GoakYyJHra2WHASXfCzsD9szbQFoT1pLMdQopyqaSqXUprH7fkk8NG2pUbQa5HpNzpWmEsdNZDHxXvSLPTrn/*,xpub6C5MW95EE8hAmxm96LdAFYkweaAktQoojCf2MwJmNL9Fi6oUPeBnpFdEzhs9zHwr4HQEeF1r1yAUR8MqDJqk4YPteh75rNoCKCtud7shDDk/*,xpub6DNEUJP1zLAZ1P6gYRba9FyxuppmkrPmSKz3FLM7msRwn2LEr4LnKfAnNoSoAbnbW2orTfsitdfWTxLbJCZ6LizqV7cFUavSAjWzNjqdfCP/*,xpub6Cm5sAgCZQvYtnatYPdFuLhsD9VtgY3Rtt48TrdgqXm4DttXfM6nFmFTko8KcyGhPswTvPcTzfpMUvqV3F9tgLPvzfzoKwjmU668vBmGXEX/*,xpub6DN66R61Luv95HLvznR2ZWsbYuGBoK9LDR6XiNm1pvp5zRJ2vFhLQ4PBe2pDn59sKmRnEFbdLtBVZFN3QAujcGZ5PomGCvrnisxkP2fcgHg/*,xpub6D2GtAtYodmjwEoAzorKUta44NDvAB4JjafYXxsQ5hTWvCAK55nnkyNHfdjrsx3umfgGe1nnHut13mLuFqqi2fs7VVyv6rht76ddrDGhrTY/*,xpub6Bfi8jsDMuu2XHQ1TGRB6ehjdHKKmTwRFQYU6QcgHoZswqbzKsXs9Qd87nAxevjZwuQ37jaVnQoPF6wY34BJoeLxXkEYMpKz2CBHLcEmJVF/*,xpub6CYiNdQesStiBwZkWjPBxwxxf6oPMH9meBMujCwBX74X8nCpMF9zRZUbDrU9raQah1LQcnzLQrHC6Kr6LNCmsBpaMkYD3U6FyhHZfTHQGUB/*,xpub6CddszJHLa3VisZ6ufU4hiFcGsuuPHo7hYa24o3kPuPfAbMED4ajuDa6svuqxxBxYgUQhN8LK7MtTMetquNo7YsWhiV8hX2gBfjszJVXgkG/*,xpub6DAM262AxC4Um3rxBiP5FoA7SJJG3a7MjaJkEyXWyMA6iNuyqWueKZHSSNjKEWnn8Wi3PUQNTV1Z3a59C2Qaidha88GTWtAMhJBAWBBvuTN/*,xpub6ByZcsLsr8xTCJmYxvLpLrsFzuHNXRLR4xMyB9ZFLek1hDVh7zba2xAVTU8M6eonFFAAPYpTA76bDuopF5zyBkZqFc3rtJ3ziH1BUXkjC6j/*,xpub6Bx2LErujvR1noXrk7RHQB9htiDcPM5qYuV7Jg1nZh5jWeK8pYB4DnYQ73EX9sB9M6rnNsF8LDPUejHiXrBx2JJQSdVQ9i9FfEzJLuAnzEd/*,xpub6DSBog1uLngjBWVDUpLTQ19jGGKovgc3iTd1ijL4fjk9sgNqrnG5kGLjUWncay2jbqdgt6yrbYSHhfwsTMp7i8pUD1FMCQuFyqdsZpgUNH8/*,xpub6C53ov8LpuGp5MM4ghqUFJcdTnXJCRHyXaz1RVCys2uQErpdzUWHtm8Bsg8NJyaqfhGWvm9WPSE7jMneCRw1xs1CTajpToXyRqSCc41JiuY/*,xpub6CscWPNXdEybbJVvx7fJTrfHyTkKZtb97qcpQ9fH4k4xtm4nkckSpvy86heQsdyoF28CugwLHg5kLDwpGoPQAYXQ3RG9cJB2Na1FdeN1wt5/*,xpub6Cmrivt6w3kVAxw7NmcKSY19gSLmC2tVwx46cdigr9d1UEnttJCGZJ7NQu1MkugpZgF9rQ3j3NKUiZ2MoaC2QoZUfi4nwxbpH39SQZaBHut/*,xpub6D1Ey5JAYnBxFE8i2V2SUsEpJt7r3ykJKcShcpT2xN9CXtVQy5dKeYiZ9D1bdnkPrmgEajrSuA5nWqf94s6u7FwvXy3cU4BXUMgAt9C8wGT/*,xpub6CwJ2vicnoSJNFDzhonucHNVHDwyb1vyiu2VF6zmjQrzGb4qoAma1i2QJ7qRNe1qmpvvWwzSuQDgMnCECFQhZaPKuPFjcMo33r2xenBauxf/*,xpub6CiLNz8mFB4fB51x6gMNu44Up9PyVhq7fSxQb8UzYQermvMShwWyqzQe99Uiyxpfy1ow42xUGpPGBHf8ErxDbQojBf7Uy7hKFgYk8KpgMm2/*,xpub6DQ2qVMZ2o2QGGpYDsw5hpAcygNVEycAkkCib2Lexwm8gYWMCSecZ256AbAV93Rgze6h8yEoTcqUnvnz7L69WUqp7cXd85X8HoeKWjPHRRZ/*),multi_a(20,xpub6CGCzpvrZVssNNXuP1Awcz8GoakYyJHra2WHASXfCzsD9szbQFoT1pLMdQopyqaSqXUprH7fkk8NG2pUbQa5HpNzpWmEsdNZDHxXvSLPTrn/*,xpub6C5MW95EE8hAmxm96LdAFYkweaAktQoojCf2MwJmNL9Fi6oUPeBnpFdEzhs9zHwr4HQEeF1r1yAUR8MqDJqk4YPteh75rNoCKCtud7shDDk/*,xpub6DNEUJP1zLAZ1P6gYRba9FyxuppmkrPmSKz3FLM7msRwn2LEr4LnKfAnNoSoAbnbW2orTfsitdfWTxLbJCZ6LizqV7cFUavSAjWzNjqdfCP/*,xpub6Cm5sAgCZQvYtnatYPdFuLhsD9VtgY3Rtt48TrdgqXm4DttXfM6nFmFTko8KcyGhPswTvPcTzfpMUvqV3F9tgLPvzfzoKwjmU668vBmGXEX/*,xpub6DN66R61Luv95HLvznR2ZWsbYuGBoK9LDR6XiNm1pvp5zRJ2vFhLQ4PBe2pDn59sKmRnEFbdLtBVZFN3QAujcGZ5PomGCvrnisxkP2fcgHg/*,xpub6D2GtAtYodmjwEoAzorKUta44NDvAB4JjafYXxsQ5hTWvCAK55nnkyNHfdjrsx3umfgGe1nnHut13mLuFqqi2fs7VVyv6rht76ddrDGhrTY/*,xpub6Bfi8jsDMuu2XHQ1TGRB6ehjdHKKmTwRFQYU6QcgHoZswqbzKsXs9Qd87nAxevjZwuQ37jaVnQoPF6wY34BJoeLxXkEYMpKz2CBHLcEmJVF/*,xpub6CYiNdQesStiBwZkWjPBxwxxf6oPMH9meBMujCwBX74X8nCpMF9zRZUbDrU9raQah1LQcnzLQrHC6Kr6LNCmsBpaMkYD3U6FyhHZfTHQGUB/*,xpub6CddszJHLa3VisZ6ufU4hiFcGsuuPHo7hYa24o3kPuPfAbMED4ajuDa6svuqxxBxYgUQhN8LK7MtTMetquNo7YsWhiV8hX2gBfjszJVXgkG/*,xpub6DAM262AxC4Um3rxBiP5FoA7SJJG3a7MjaJkEyXWyMA6iNuyqWueKZHSSNjKEWnn8Wi3PUQNTV1Z3a59C2Qaidha88GTWtAMhJBAWBBvuTN/*,xpub6ByZcsLsr8xTCJmYxvLpLrsFzuHNXRLR4xMyB9ZFLek1hDVh7zba2xAVTU8M6eonFFAAPYpTA76bDuopF5zyBkZqFc3rtJ3ziH1BUXkjC6j/*,xpub6Bx2LErujvR1noXrk7RHQB9htiDcPM5qYuV7Jg1nZh5jWeK8pYB4DnYQ73EX9sB9M6rnNsF8LDPUejHiXrBx2JJQSdVQ9i9FfEzJLuAnzEd/*,xpub6DSBog1uLngjBWVDUpLTQ19jGGKovgc3iTd1ijL4fjk9sgNqrnG5kGLjUWncay2jbqdgt6yrbYSHhfwsTMp7i8pUD1FMCQuFyqdsZpgUNH8/*,xpub6C53ov8LpuGp5MM4ghqUFJcdTnXJCRHyXaz1RVCys2uQErpdzUWHtm8Bsg8NJyaqfhGWvm9WPSE7jMneCRw1xs1CTajpToXyRqSCc41JiuY/*,xpub6CscWPNXdEybbJVvx7fJTrfHyTkKZtb97qcpQ9fH4k4xtm4nkckSpvy86heQsdyoF28CugwLHg5kLDwpGoPQAYXQ3RG9cJB2Na1FdeN1wt5/*,xpub6Cmrivt6w3kVAxw7NmcKSY19gSLmC2tVwx46cdigr9d1UEnttJCGZJ7NQu1MkugpZgF9rQ3j3NKUiZ2MoaC2QoZUfi4nwxbpH39SQZaBHut/*,xpub6D1Ey5JAYnBxFE8i2V2SUsEpJt7r3ykJKcShcpT2xN9CXtVQy5dKeYiZ9D1bdnkPrmgEajrSuA5nWqf94s6u7FwvXy3cU4BXUMgAt9C8wGT/*,xpub6CwJ2vicnoSJNFDzhonucHNVHDwyb1vyiu2VF6zmjQrzGb4qoAma1i2QJ7qRNe1qmpvvWwzSuQDgMnCECFQhZaPKuPFjcMo33r2xenBauxf/*,xpub6CiLNz8mFB4fB51x6gMNu44Up9PyVhq7fSxQb8UzYQermvMShwWyqzQe99Uiyxpfy1ow42xUGpPGBHf8ErxDbQojBf7Uy7hKFgYk8KpgMm2/*,xpub6DQ2qVMZ2o2QGGpYDsw5hpAcygNVEycAkkCib2Lexwm8gYWMCSecZ256AbAV93Rgze6h8yEoTcqUnvnz7L69WUqp7cXd85X8HoeKWjPHRRZ/*)}})This PR:
Master:
Joint work with claude 😅