22335474d768f99067856173ff2764b6db753f67 net: format peer+addr logs with `LogPeer` (Lőrinc)
e55ea534f74b2dd2a81e8f9972554303f7cf9c20 test: add pre-`LogPeer` net log assertion (Lőrinc)
736b17c0f0f23dca78e7266be6c98b24b0eda210 log: fix minor formatting in debug logs (Lőrinc)
9cf82bed3205d8405f56838d0e2ca0c72023a081 log: show placeholders for missing peer fields (Lőrinc)
Pull request description:
This is an alternative to #34293, but aims to address the remaining logging inconsistencies more broadly.
It extends the example fixed there to every instance, restores the original separator behavior, applies it consistently via a single helper, and adds tests for `logips` (covering both current and new behavior).
### Problem
After #28521 centralized peer address logging into `CNode::LogIP()`, the original comma separator before `peeraddr=` was lost, resulting in inconsistent formatting across net (and recent private broadcast) logs.
Some lines also had double spaces, empty fields, or mismatched format specifiers.
### Fix
Introduces `CNode::LogPeer(bool)` which always emits `peer=<id>` and, when `-logips=1`, appends `, peeraddr=<addr>`. This eliminates hand-rolled separators and makes peer identification predictable.
Minor issues (double spaces, empty placeholders, format specifiers) are fixed along the way in separate commits.
### Reproducer
Run with `-debug=net -logips=1` and observe peer log lines now show `peer=<id>, peeraddr=<addr>` (comma-separated). The new assertion in `feature_logging.py` automates this check.
ACKs for top commit:
naiyoma:
ACK 22335474d768f99067856173ff2764b6db753f67
vasild:
ACK 22335474d768f99067856173ff2764b6db753f67
sedited:
ACK 22335474d768f99067856173ff2764b6db753f67
Tree-SHA512: 562262a58c3042f139099ff4c41e3fc6a97505fe9603c2bf700a97fd0aa052954b47c14da0e50c1fc311db1ae6c04e6a92156c9b85e25c777a637b7766c1dafe
c6a6435cedac01a6800cac9285e2c599290e2e0d wallet: remove `DBErrors::NEED_REWRITE` enum value (rkrux)
61039d72a5da443a254b3229748fc64eee613757 wallet: remove unimplemented `RewriteDB` calls from SPKM (rkrux)
Pull request description:
ISTM that there is no implementation left of the `RewriteDB` method in any of the SPKMs, and thus, its call sites can be removed safely.
Also remove `DBErrors::NEED_REWRITE` enum value as its usage is outdated now.
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improve coverage are always welcome.
* All other changes should have accompanying unit tests (see `src/test/`) or
functional tests (see `test/`). Contributors should note which tests cover
modified code. If no tests exist for a region of modified code, new tests
should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or an
explanation of the potential issue as well as reasoning for the way the bug
was fixed.
* Features are welcome, but might be rejected due to design or scope issues.
If a feature is based on a lot of dependencies, contributors should first
consider building the system outside of Bitcoin Core, if possible.
* Refactoring changes are only accepted if they are required for a feature or
bug fix or otherwise improve developer experience significantly. For example,
most "code style" refactoring changes require a thorough explanation why they
are useful, what downsides they have and why they *significantly* improve
developer experience or avoid serious programming bugs. Note that code style
is often a subjective matter. Unless they are explicitly mentioned to be
preferred in the [developer notes](/doc/developer-notes.md), stylistic code
changes are usually rejected.
-->
<!--
Bitcoin Core has a thorough review process and even the most trivial change
needs to pass a lot of eyes and requires non-zero or even substantial time
effort to review. There is a huge lack of active reviewers on the project, so
patches often sit for a long time.
-->
ACKs for top commit:
achow101:
ACK c6a6435cedac01a6800cac9285e2c599290e2e0d
furszy:
ACK c6a6435cedac01a6800cac9285e2c599290e2e0d
sedited:
ACK c6a6435cedac01a6800cac9285e2c599290e2e0d
Tree-SHA512: 050d3115ad436eb7728716c897c8d23c6dd0c6cd7a018dc023896d301b126bae5ba89b684811226a0ca4045b393b612296aeab3b3b5dfb7ed0bf443fc1eaef41
79571b918130e66436b2d43489835c38bb3ae3e3 threadpool: add ranged Submit overload (Andrew Toth)
Pull request description:
The current `ThreadPool::Submit` is not very efficient when we have a use case where we need to submit multiple tasks immediately. The `Submit` method must take the lock for each task, and notifies only a single worker thread. This will cause lock contention with the awakened worker thread trying to take the lock and the caller trying to submit the next task.
Introduce a `Submit` overload, which takes the lock once and submits a range of tasks, then notifies all worker threads after the lock is released.
This is needed for #31132 to be able to use `ThreadPool`.
ACKs for top commit:
l0rinc:
ACK 79571b918130e66436b2d43489835c38bb3ae3e3
rkrux:
ACK 79571b9
sedited:
Re-ACK 79571b918130e66436b2d43489835c38bb3ae3e3
willcl-ark:
ACK 79571b918130e66436b2d43489835c38bb3ae3e3
Tree-SHA512: 1fbe0c150f01b9ea5be3459cd10b817045af52eaf6f14a1a298a68853890da4033c1b21bdc6f995bb55029fb4ab536e9dbf58d98e2e1e12b25298fa3470b4ba6
b50376881929ff23b1148028ac6ca42617af04d8 fuzz: register PeerManager in process_message(s) (Eugene Siegel)
Pull request description:
This lets CValidationInterface callbacks be hit (just `BlockChecked` using the corpus from qa-assets). Also remove no-op SyncWithValidationInterfaceQueue since there are no validation interfaces registered in ResetChainman.
ACKs for top commit:
marcofleon:
code review ACK b50376881929ff23b1148028ac6ca42617af04d8
dergoegge:
utACK b50376881929ff23b1148028ac6ca42617af04d8
Tree-SHA512: 51c0c9a3396ee898b1dce2c65c2fc7b61ea6d04342d181b1b60be1677bc0c2828b9d970673f67501e3579ae002392cd5f0e3268aae1b216ff332e2654fd1fe14
02d047fd5b93d96f159db2b8e95fc39450505159 refactor: add overflow-safe `CeilDiv` helper (Lőrinc)
Pull request description:
### Problem
The codebase has many open-coded ceiling-division expressions (for example `(x+y-1)/y`) scattered across files.
These are less readable, duplicate logic, and can be overflow-prone in edge cases.
### Fix
Introduce a small overflow-safe integer helper, `CeilDiv()`, and use it in existing **unsigned** callsites where the conversion is straightforward and noise-free.
### What this PR does
* Adds `CeilDiv()` to `src/util/overflow.h` for unsigned integral inputs.
* Keeps the precondition check `assert(divisor > 0)`.
* Replaces selected unsigned ceiling-division expressions with `CeilDiv(...)`.
* Adds focused unit tests in `src/test/util_tests.cpp` for the migrated patterns.
---
This is a pure refactor with no intended behavioral change.
Signed arithmetic callsites are intentionally left unchanged in this PR.
This PR changed a few more things originally but based on feedback reverted to the simplest cases only.
ACKs for top commit:
rustaceanrob:
ACK 02d047fd5b93d96f159db2b8e95fc39450505159
hodlinator:
ACK 02d047fd5b93d96f159db2b8e95fc39450505159
sedited:
ACK 02d047fd5b93d96f159db2b8e95fc39450505159
Tree-SHA512: b09336031f487e6ce289822e0ffeb8cfc8cfe8a2f4f3f49470748dfbd0a6cbab97498674cb8686dd2bd4ab6dd0b79cfdf2da00041fee12d109892e1bc5dde0ff
af041c405756d3b8bb04cb2ebd8c32cf237ac2a9 wallet: Always rewrite tx records during migration (Ava Chow)
Pull request description:
Since loading a wallet may change some parts of tx records (e.g. adding nOrderPos), we should rewrite the records instead of copying them so that the automatic upgrade does not need to be performed again when the wallet is loaded.
This is useful for future PRs I'm working on where we need to be sure about what data exists in a tx record in descriptor wallets.
ACKs for top commit:
rkrux:
lgtm ACK af041c405756d3b8bb04cb2ebd8c32cf237ac2a9
Eunovo:
ACK af041c4057
furszy:
ACK af041c405756d3b8bb04cb2ebd8c32cf237ac2a9
Tree-SHA512: 96984e46fe110a7749495965587b88a94d1297794e5d8b632b89dcdb2ebc1cd3070cd4458cf8e1b4ec0c76c4e56994f21867c44fa74f25739cbd9c0c911732a6
d339884f1dfac3749c6214ae896b4354cf9ee28e bench: add script verification benchmark for P2TR key path spends (Sebastian Falbesoner)
dd93362a1d874eb761ed7026956a490b5ed0472b bench: simplify script verification benchmark, generalize signing (Sebastian Falbesoner)
Pull request description:
We currently benchmark Schnorr signature verification only in the context of block validation ([`ConectBlock*`](8bb77f348e/src/bench/connectblock.cpp (L107)) benchmarks), but not individually for single inputs [1]. This PR adds a script verification benchmark for P2TR key path spends accordingly, by generalizing the already existing one for P2WPKH spends.
This should make it easier to quantify potential performance improvements like e.g. https://github.com/bitcoin-core/secp256k1/pull/1777, which allows to plug in our HW-optimized SHA256 functions to be used in libsecp256k1 (see the linked example commit f68bef06d9). IIRC from last CoreDev, the main speedup from this is expected for ECDSA signing though (as this involves quite a lot of hashing), but it still makes sense to have verification benchmarks available for both signature types as well.
(An alternative way could be to add benchmarks for the signing/verifying member functions `CKey::Sign{,Schnorr}`, `CPubKey::Verify` and `XOnlyPubKey::VerifySchnorr` directly, if we prefer that.)
[1] this claim can be practically verified by putting an `assert(false);` into `XOnlyPubKey::VerifySchnorr`: the three benchmarks crashing are `ConnectBlockAllSchnorr`, `ConnectBlockMixedEcdsaSchnorr` and `SignTransactionSchnorr` (as signing includes verification)
ACKs for top commit:
furszy:
ACK d339884f1dfac3749c6214ae896b4354cf9ee28e
sedited:
Re-ACK d339884f1dfac3749c6214ae896b4354cf9ee28e
w0xlt:
ACK d339884f1dfac3749c6214ae896b4354cf9ee28e
Tree-SHA512: efd20444984bdf1dab4d3d876fdbe2a3a838d7cebc0e31e26683009b81afe4dab8611e2c28c87e46fe8b7e305895c93e461b7934a5aaf293f72b19488b9cec60
b3046cca7182f3399a221757318d24e203092301 doc: add release notes for #26988 (stratospher)
675be930245e5c1ac2f7940bcf308430adeb18ee cli: modify -addrinfo to use getaddrmaninfo RPC endpoint (stratospher)
Pull request description:
Rework of `-addrinfo` CLI is done using `getaddrmaninfo` RPC proposed in https://github.com/bitcoin/bitcoin/pull/27511. This would be useful for users who want to know the total number of addresses the node knows about and can make connections to.
Currently, `-addrinfo` returns total number of addresses the node knows about after filtering them for quality + recency using [`isTerrible`](4b51290f71/src/addrman.cpp (L808)). However `isTerrible`addresses [don't matter](https://github.com/bitcoin/bitcoin/pull/26988#discussion_r1147725684) when selecting outbound peers to connect to. Total number of addresses the node knows about could be higher than what `-addrinfo` currently displays. See https://github.com/bitcoin/bitcoin/pull/24370.
ACKs for top commit:
ajtowns:
ACK b3046cca7182f3399a221757318d24e203092301
pablomartin4btc:
re-ACK b3046cca7182f3399a221757318d24e203092301
vasild:
ACK b3046cca7182f3399a221757318d24e203092301
sr-gi:
tACK b3046cca7182f3399a221757318d24e203092301
Tree-SHA512: 764b74f9e0e28a65f8644a31228ca70f6e2cd4c6a93d8f29093ed7a241cd20a81e24b4babace170d945fb28078793d52ec1f4bce898a6d478950fb29ce54af91
d67c8ed78894a8f5e3d6c5ab949c484e64241266 clusterlin: update SFL comments for deterministic order (Pieter Wuille)
Pull request description:
This was missed in #34257.
ACKs for top commit:
marcofleon:
ACK d67c8ed78894a8f5e3d6c5ab949c484e64241266
achow101:
ACK d67c8ed78894a8f5e3d6c5ab949c484e64241266
Tree-SHA512: e381da09eb686e69c0fb32cc16dff7ae108f13ecb07bc1466f504a7b4c773d4557599c659f6d2e9ba0037ed89179c2e187f383a917e0242c4c795cf6e1c9cec6
0690a5d0f27b52435782815b9d7520684486a9ad Update embedded asmap to 1772726400 (Fabian Jahr)
Pull request description:
This updates the currently embedded data ahead of the v31 release.
It currently uses the map from the 1772726400 run
- Pull request: https://github.com/bitcoin-core/asmap-data/pull/45
- Issue: https://github.com/bitcoin-core/asmap-data/issues/44
The attestation process to accompany these runs is still rather new but sigs are collected here: https://github.com/asmap/asmap.sigs/tree/main/1772726400
ACKs for top commit:
achow101:
ACK 0690a5d0f27b52435782815b9d7520684486a9ad
sedited:
ACK 0690a5d0f27b52435782815b9d7520684486a9ad
hodlinator:
ACK 0690a5d0f27b52435782815b9d7520684486a9ad FWIW
Tree-SHA512: 61c43ea1bd44425aa07056316220a0e9f3c4ec59cd9447277e114b2004fd7f9e525fb56ac0b3f590447d1a454fa3c636c7ac8c034a673a76126ce51e005cce49
This lets CValidationInterface callbacks be hit. Also remove
no-op SyncWithValidationInterfaceQueue since there are no validation
interfaces registered in ResetChainman.
501a3dd4ad4a545a05663a78cec61575966045c7 walletdb: hash pubkey/privkey in one shot to avoid leaking secret data (Sebastian Falbesoner)
Pull request description:
In several places in the wallet DB module, byte strings containing serialized public keys and secret keys are created in order to be hashed. To avoid sensitive data lingering in memory (and potentially leaking), don't store the preimage, but hash both public key and secret key in one shot, using the overloaded `Hash` function:
d198635fa2/src/hash.h (L82-L88)
See e.g. #31166 and #31774 for similarly themed PRs (Note that in #31166 we used the explicit `memory_cleanse` approach though, as changing the allocator was not possible.)
ACKs for top commit:
davidgumberg:
crACK 501a3dd4ad
furszy:
ACK 501a3dd4ad4a545a05663a78cec61575966045c7
rkrux:
ACK 501a3dd
theuni:
ACK 501a3dd4ad4a545a05663a78cec61575966045c7
Tree-SHA512: 8a71685b26bf89fca181aed6512a8db843b6d1dc740a468bb33fb2a629a23167a9676c228d1077ad8db2df9db80f47e32ec013737e93df8ee6f4ba505d3d50c9
fec58229fa671cb870ebf795b54b73b7e22a1eb6 contrib: Update fixed feeds (Ava Chow)
27fbdb009f2f007239c4845cad528487b30598bd makeseeds: Choose node info with most recent success when deduplicating (Ava Chow)
982883a1bc4d03efb78d296849a3b8fa04ded26d makeseeds: Update known user agents (Ava Chow)
Pull request description:
ACKs for top commit:
fjahr:
ACK fec58229fa671cb870ebf795b54b73b7e22a1eb6
Tree-SHA512: 2852a9a6a7c299ce04ee4dc438af9547d56a860858201ad2ccdea14640b17876e7e9841ce3a30030e2482cd04e9b386f7ede5c4e51582ebd09b9ce0a2a0bc43b
89386e700ebc232e2beab3a3f3ea0d1ae78ac203 kernel: Use fs:: namespace and unicode path in kernel tests (sedited)
Pull request description:
Add support for unicode characters in paths to the kernel tests by using our fs:: wrappers for std::filesystem calls and adding the windows application manifest to the binary. This exercises their handling through the kernel API.
ACKs for top commit:
hebasto:
ACK 89386e700ebc232e2beab3a3f3ea0d1ae78ac203.
w0xlt:
ACK 89386e700ebc232e2beab3a3f3ea0d1ae78ac203
Tree-SHA512: 7b541f482d84a66c89eec63aea0e7f7626bbbd62082ad7a7fb2c7a517296c291a6ff301c628e5e9e1d7b850ead89005141481a2bfd06d8a9081622e32f7340cc
faa016af542763492a63de8cc972f8f4b52a58cd refactor: Use aliasing shared_ptr in Sock::Wait (MarcoFalke)
Pull request description:
Currently, a no-op lambda is used as the deleter for the temporary shared pointer helper in `Sock::Wait`. This is perfectly fine, but has a few style issues:
* The lambda needs to be allocated on the heap
* It triggers a false-positive upstream GCC-16-trunk bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123912
Fix all issues by just using an aliasing shared pointer, which points to `this`, but is otherwise empty (sits on the stack without any heap allocations).
ACKs for top commit:
hodlinator:
ACK faa016af542763492a63de8cc972f8f4b52a58cd
sedited:
ACK faa016af542763492a63de8cc972f8f4b52a58cd
vasild:
ACK faa016af542763492a63de8cc972f8f4b52a58cd
Tree-SHA512: b7330862204e79fb61f30694accb16f9a24e5722bd0ceb098ca27c877cff921afa00c0cfd953d4cbb355e6433706961a25b628efefdbe0b48bdec2941eaaee7a
a067ca34106817565e02daca52b3175266714c25 [doc] coin selection filters by max cluster count, not descendant (glozow)
f7be5fb8fc7d2a5831810a0b91666fc774b64b8f [refactor] rename variable to clarify it is unused and cluster count (glozow)
Pull request description:
Followup to #33629.
Fix misleading docs and variable names. Namely, `getTransactionAncestry` returns the cluster count, not max descendant count of ancestor set (not worth reimplementing as it is merely a heuristic). No behavior changes - I don’t think much needs to be changed for the first release containing cluster mempool.
Current `CoinEligibilityFilter`s enforce a maximum ancestor count (summed across all outputs, potentially overestimating) and max descendant count across ancestors of the output.
Since #33629, these filters have started using cluster count instead of max desc count across ancestors. The change isn’t dangerous, as the cluster count bounds descendant count as well. Currently, the wallet is essentially enforcing a mixture of both limits - this is good while we are transitioning. Note that the cluster count enforced is 25, not 64, since it's grabbing the node's descendant count limit. While it is not an apples-to-apples comparison, a cluster count limit of 25 helps us avoid busting legacy descendant limits (which will be common on the network for a while).
Potential things for the future, out of scope for this PR:
- When we get rid of the ancestor/descendant config options, `getPackageLimits` can probably be replaced with hard-coded values.
- Change the `OutputGroup`s to track the actual cluster count that results from spending these outputs and merging their clusters.
- Loosen from 25 after that policy is no longer common.
- Clean up `getPackageLimits`.
ACKs for top commit:
achow101:
ACK a067ca34106817565e02daca52b3175266714c25
ismaelsadeeq:
reACK a067ca34106817565e02daca52b3175266714c25
rkrux:
crACK a067ca34106817565e02daca52b3175266714c25
Tree-SHA512: d7cacd5bf668d42e26e8b83e42a42c280929c3bfd554c3db1de605e5939f8b36c14ecfd2839abeb4eec352363df1891b3420a693c250916391ab10a5ce26396b
Avoid storing the privkey in a vector, which could linger in memory
and potentially leak sensitive data. An alternative approach is to
use `secure_allocator` for the `std::vector` instances, but this
commit has the advantage of also deduplicating code at the same shot.
Thanks to @theuni for suggesting this.
44538f8ada868cb73ffa7a4bfb5267046d3f6b85 kernel: Add recent assumeutxo snapshot info (Ava Chow)
58c2e23fca05d201dfcea092ab032c943c9d5665 kernel: Update headerssync params (Ava Chow)
cf261b071f68b1967077a6d3baac10ea024e653a kernel: update chainTxData (Ava Chow)
8eaf1d26d446ecdc5c69b61334ee51a6f41050d3 kernel: update defaultAssumeValid and minimumChainWork (Ava Chow)
5ca0c55517d4c8e41a1dd9904545d82ee09adedf kernel: update assumed blockchain and chainstate sizes (Ava Chow)
Pull request description:
Update chainparams and headerssync params per the release process.
Also added new assumeutxo snapshots for each network. I've uploaded snapshots to https://achow101.com/files/utxo-snapshots/
ACKs for top commit:
Sjors:
ACK 44538f8ada868cb73ffa7a4bfb5267046d3f6b85
fjahr:
ACK 44538f8ada868cb73ffa7a4bfb5267046d3f6b85
janb84:
ACK 44538f8ada868cb73ffa7a4bfb5267046d3f6b85
sipa:
ACK 44538f8ada868cb73ffa7a4bfb5267046d3f6b85. I re-did all the mainnet parameters, but did not look closely at the other networks.
jaonoctus:
ACK 44538f8ada868cb73ffa7a4bfb5267046d3f6b85
Tree-SHA512: f9b6ccc967c5ef58f734245df459c3136491e9b6a0f6e36f4272bc0787e7b59eabe47a8c8b19a90267eca4a0b5851dfbf45153f96eac599c417f148b3cf264cf
f580cc7e9f26331f7f03a8bbc5722521eb159bb2 doc: Fix `fee` field in `getblock` RPC result (nervana21)
Pull request description:
The `fee` field in the `getblock` RPC result (verbosity 2 and 3) may be omitted when block undo data is not available. Marking it optional in the `RPCResult` aligns the documented schema with the runtime behavior.
ACKs for top commit:
mercie-ux:
ACK f580cc7e9f
satsfy:
ACK f580cc7e9f
instagibbs:
ACK f580cc7e9f26331f7f03a8bbc5722521eb159bb2
w0xlt:
ACK f580cc7e9f26331f7f03a8bbc5722521eb159bb2
luke-jr:
ACK f580cc7e9f26331f7f03a8bbc5722521eb159bb2
Tree-SHA512: e3b44a48e17e21b906967aef124688a34aea2c6af3b6df3c47693fd3002d33e824f764c0060a7ab07751b98567c29eb16f3b3c07bf2999db080ff7adfd087dfd
44feab23a7c6060a3b432c04e3f952c5a7104325 script: Fix undefined behavior in Clone() -- std::transform writes past end of empty vector (Weixie Cui)
Pull request description:
# Motivation
This patch fixes undefined behavior in Clone() in src/script/descriptor.cpp.
When std::transform is used with providers.begin() or subdescs.begin() as the output iterator, the vectors have been reserve()d but have size 0. Writing through begin() in that case writes past the logical end of the vector, which is undefined behavior.
ACKs for top commit:
maflcko:
lgtm ACK 44feab23a7c6060a3b432c04e3f952c5a7104325
rkrux:
ACK 44feab23a7c6060a3b432c04e3f952c5a7104325 because it gets rid of the possible undefined behaviour.
frankomosh:
Code Review ACK 44feab23a7c6060a3b432c04e3f952c5a7104325. Fix seems minimal and correct.
Tree-SHA512: 8af3b6d97c139b32bd47d4c452b6b16befdaa7028a7bc1b6de0ab1f0a8cb35eb068710316a2c07fa60856e17e25307931aa3125b4f41d0fe7726b435483a52db
4ae9a10ada95ab8c1ab01472948d348d9538f3bb doc: add release notes for dbcache bump (Andrew Toth)
c510d126efb6ce9623e0e005829c13a110f65b0e doc: update dbcache default in reduce-memory.md (Andrew Toth)
027cac852796f643e2b6036fd3652dd3ca7785a5 qt: show GetDefaultDBCache() in settings (Andrew Toth)
5b34f251847a3c66b444959800b70e9863b10bbe dbcache: bump default from 450MB -> 1024MB if enough memory (Andrew Toth)
Pull request description:
Alternative to #34641
This increases the default `dbcache` value from `450MiB` to `1024MiB` if:
- `dbcache` is unset
- The system is 64 bit
- At least 4GiB of RAM is detected
Otherwise fallback to previous `450MiB` default.
This should be simple enough to get into v31. The bump to 1GiB shows significant performance increases in #34641. It also alleviates concerns of too high default for steady state, and of lowering the current dbcache for systems with less RAM.
This change only changes bitcoind behavior, while kernel still defaults to 450 MiB.
ACKs for top commit:
ajtowns:
ACK 4ae9a10ada95ab8c1ab01472948d348d9538f3bb
kevkevinpal:
reACK [4ae9a10](4ae9a10ada)
svanstaa:
ACK [4ae9a10](4ae9a10ada)
achow101:
ACK 4ae9a10ada95ab8c1ab01472948d348d9538f3bb
sipa:
ACK 4ae9a10ada95ab8c1ab01472948d348d9538f3bb
Tree-SHA512: ee3acf1fb08523ac80e37ec8f0caca226ffde6667f3a75ae6f4f4f54bc905a883ebcf1bf0e8a8a15c7cfabff96c23225825b3fff4506b9ab9936bf2c0a2c2513
20ae9b98eab20117344cf31f7cde39cadd70ca22 Extend functional test for setBlockIndexCandidates UB (marcofleon)
854a6d5a9a0e40329a2852efb2a8dfec4b54886e validation: fix UB in LoadChainTip (marcofleon)
9249e6089ec4e2eb63f0896961f04d9dbe14651a validation: remove LoadChainTip call from ActivateSnapshot (marcofleon)
Pull request description:
Addresses https://github.com/bitcoin/bitcoin/issues/34503. See this issue for more details as well.
Fixes a bug where, under certain conditions, `setBlockIndexCandidates` had blocks in it that were worse than the tip. The block index candidate set uses `nSequenceId` as a sort key, so modifying this field while blocks are in the set results in undefined behavior. This PR populates `setBlockIndexCandidates` after the `nSequenceId` modifications, avoiding the UB.
ACKs for top commit:
achow101:
ACK 20ae9b98eab20117344cf31f7cde39cadd70ca22
sedited:
Re-ACK 20ae9b98eab20117344cf31f7cde39cadd70ca22
sipa:
Code review ACK 20ae9b98eab20117344cf31f7cde39cadd70ca22
Tree-SHA512: 121c170bb70fb6365089d578db63c811e7926e129d7206e569947f7a1f6c5ddc8d5f4937b80f1ba1b7d7daa42789b143ca5b56f154b7ab968a1cd55f925f378d
97e7e79435c69e90cb7f056c704c275421bf0892 test: Enable `system_tests/run_command` "stdin" test on Windows (Hennadii Stepanov)
a4324ce09546d80ab847dbfce715f015139ed593 test: Remove `system_tests/run_command` runtime dependencies (Hennadii Stepanov)
Pull request description:
`system_tests` currently rely on `cat`, `echo`, `false` and `sh` being available in `PATH` at runtime.
This PR:
1. Removes these dependencies.
2. Reduces the number of platform-specific code paths.
The change is primarily motivated by my work on maintaining the [`bitcoin-core`](https://packages.guix.gnu.org/packages/bitcoin-core) package in Guix. It enables the removal of the existing `bash` and `coreutils` native inputs, which in turn makes it possible to drop the implicit dependency on `qtbase@5` (see https://codeberg.org/guix/guix/pulls/4386#issuecomment-8613333).
ACKs for top commit:
maflcko:
re-ACK 97e7e79435c69e90cb7f056c704c275421bf0892 👓
janb84:
ACK 97e7e79435c69e90cb7f056c704c275421bf0892
sedited:
ACK 97e7e79435c69e90cb7f056c704c275421bf0892
Tree-SHA512: 1375c676f85c75d571df1ddfc3a4405767dbf0ed7bfea2927c93ec01b29f9f7ae3383e546d2658f595e8ffafa9ab20bba6fcc628a9f5ebdb288bbef03b645fb6
15c4889497b96037e41019a8f43090af841b36ec index: document TxoSpenderIndex::FindSpender (furszy)
f8b9595aaa966c373b02e6227dc799fed6d038ba test: Add missing txospenderindex coverage in feature_init (Fabian Jahr)
a1074d852a7a46b746fb4ed90d94cb4cc346f9b3 index, rpc, test: Misc formatting fixes (Fabian Jahr)
Pull request description:
This addresses my own comments in the last review of #24539: https://github.com/bitcoin/bitcoin/pull/24539#pullrequestreview-3829110465
The first commit fixes three small formatting errors.
The second commit adds some missing coverage in `feature_init` and refactors the code a bit as well so these misses don't happen so easily in the future.
The third commit is by furzy:
> TxoSpenderIndex::FindSpender returns an Expected<optional<TxoSpender>> but
the two levels of the return type were undocumented, making it unclear what a returned
nullopt means. So added doc clarifying each return case.
ACKs for top commit:
furszy:
ACK 15c4889497b96037e41019a8f43090af841b36ec
sedited:
ACK 15c4889497b96037e41019a8f43090af841b36ec
rkrux:
crACK 15c4889497b96037e41019a8f43090af841b36ec
Tree-SHA512: 2e0f060a54b558d2967ebae0835cf81bd86c2d8d983d670a48d1bee7d347f186623e75db7ae311ca1566807f715c1b3fa67cf734c9467d35e13b84d082f28253
bff8a7a80d2a198e84443a696438925d4c303c7b subprocess: replace __USING_WINDOWS__ with WIN32 (kevkevinpal)
Pull request description:
## Summary
Motivated by https://github.com/bitcoin/bitcoin/pull/34385#pullrequestreview-3826616188
In `subprocess.h` we are now renaming `__USING_WINDOWS__` with `WIN32`
In the rest of the codebase, we are using `WIN32`, so it makes sense to update `subprocess.h` to match that.
---
Use the following `grep` to assert there is no `__USING_WINDOWS__` in the codebase
```
grep -nri --exclude-dir=build "WIN32" ./ -I
rep -nri --exclude-dir=build "__USING_WINDOWS__" ./ -I
```
ACKs for top commit:
sedited:
ACK bff8a7a80d2a198e84443a696438925d4c303c7b
hebasto:
ACK bff8a7a80d2a198e84443a696438925d4c303c7b, I have reviewed the code and it looks OK.
Tree-SHA512: 18c3c8b87cf880053bbf69f837a0a135c5da51cfb15ab1d9fd554d8f931b2ea8202cf0f4d5e6f317d6234480128c2f41a7a1a9d9bd0504697a3c4c6a21797762
The removal of the chain tip from setBlockIndexCandidates was
happening after nSequenceId was modified. Since the set uses
nSequenceId as a sort key, modifying it while the element is in the
set is undefined behavior, which can cause the erase to fail.
With assumeutxo, a second form of UB exists: two chainstates each
have their own candidate set, but share the same CBlockIndex
objects. Calling LoadChainTip on one chainstate mutates nSequenceIds
that are also in the other chainstate's set.
Fix by populating setBlockIndexCandidates after all changes to
nSequenceId.
This call is a no-op. PopulateAndValidateSnapshot already sets both
the chain tip and the coins cache best block to the snapshot block,
so LoadChainTip always hits the early return when it finds that the
two match (tip->GetBlockHash() == coins_cache.GetBestBlock()).
f51665bee72c26d3f3cc6813b6c02adad5f0af6a psbt: validate pubkeys in MuSig2 pubnonce/partial sig deserialization (tboy1337)
Pull request description:
The previous fix for invalid MuSig2 pubkeys (bitcoin/bitcoin#34010) only
addressed the PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS field. However, the
PSBT_IN_MUSIG2_PUB_NONCE and PSBT_IN_MUSIG2_PARTIAL_SIG fields also
deserialize pubkeys without validation, which could lead to crashes when
invalid pubkeys are processed.
This commit adds validation to the DeserializeMuSig2ParticipantDataIdentifier
function to ensure all pubkeys in MuSig2 pubnonce and partial signature
fields are fully valid elliptic curve points.
The fix:
- Validates both aggregate and participant pubkeys in MuSig2 pubnonce and
partial signature deserialization
- Throws std::ios_base::failure with descriptive error messages for invalid
pubkeys
- Prevents potential crashes from invalid elliptic curve points
- Maintains backward compatibility for valid PSBTs
This completes the fix for issues [#33999](https://github.com/bitcoin/bitcoin/issues/33999) and [#34201](https://github.com/bitcoin/bitcoin/issues/34201).
ACKs for top commit:
rkrux:
lgtm ACK f51665bee72c26d3f3cc6813b6c02adad5f0af6a
w0xlt:
ACK f51665bee7
darosior:
utACK f51665bee72c26d3f3cc6813b6c02adad5f0af6a
Tree-SHA512: 8454d77a05aa003a3121b0a5975e8a000125ee0d62343bfa625a75db113358ba7a210ae0376ca1666957b7de7005e06e5a54c95170430ee5e9e1416719b8af53
Add support for unicode characters in paths to the kernel tests by using
our fs:: wrappers for std::filesystem calls and adding the windows
application manifest to the binary. This exercises their handling
through the kernel API.
98e8af4bb991fd8edeb15c0fb8afa66bff6b5cac wallet: Drain validation interface queue after notifications disconnect (Ava Chow)
52992ebe1c55c8f7219b824f05d22fbc18acb794 interfaces: Add waitForNotifications() to call SyncWithValidationInterfaceQueue() (Ava Chow)
Pull request description:
When the wallet disconnects chain notifications, it is expecting no further notifications to execute, but this is not the case. This results in test failures such as in #34354. Instead of disconnecting the notifications and continuing shutdown, we should wait for the validation interface queue to be drained before the rest of wallet shutdown. This is achieved by adding an `interfaces::Chain::waitForNotifications()` function which calls `SyncWithValidationInterfaceQueue()`.
Fixes#34354
ACKs for top commit:
stickies-v:
utACK 98e8af4bb991fd8edeb15c0fb8afa66bff6b5cac
furszy:
ACK 98e8af4bb991fd8edeb15c0fb8afa66bff6b5cac
rkrux:
crACK 98e8af4bb991fd8edeb15c0fb8afa66bff6b5cac
sedited:
ACK 98e8af4bb991fd8edeb15c0fb8afa66bff6b5cac
Tree-SHA512: 263628556f740cb633d3970c22a0dfdb52a644bd1d0cd5a69c2970524edbb0e25d592cb39fc9bf1d0c281eebce09578526e2958dffee9026fc7473db35bd0dec
da7f70a5322843b70f29456a8bc2227209a0718b test: use port 0 for I2P addresses in p2p_private_broadcast.py (Vasil Dimov)
a8ebcfd34c63f142064b4f5ef7d52299739d4cd6 test: let connections happen in any order in p2p_private_broadcast.py (Vasil Dimov)
67696b207f370e902c8d5fb765e4ff10f6c9e1b4 net: extend log message to include attempted connection type (Vasil Dimov)
Pull request description:
If the following two events happen:
* (likely) the automatic 10 initial connections are not made to all
networks
* (unlikely) the network-specific logic kicks in almost immediately.
It is using exponential distribution with a mean of 5 minutes
(`rng.rand_exp_duration(EXTRA_NETWORK_PEER_INTERVAL)`).
So if both happen, then the 11th connection may not be the expected
private broadcast, but a network-specific connection.
Fix this by retrieving the connection type from
`destinations_factory()`. This is more flexible because it allows
connections to happen in any order and does not break if e.g. the 11th
connection is not the expected first private broadcast.
This also makes the test run faster:
before: 19-44 sec
now: 10-25 sec
because for example there is no need to wait for the initial 10
automatic outbound connections to be made in order to proceed.
Fixes: https://github.com/bitcoin/bitcoin/issues/34387
ACKs for top commit:
achow101:
ACK da7f70a5322843b70f29456a8bc2227209a0718b
andrewtoth:
ACK da7f70a5322843b70f29456a8bc2227209a0718b
mzumsande:
Code Review ACK da7f70a5322843b70f29456a8bc2227209a0718b
Tree-SHA512: 7c293e59c15c148a438e0119343b05eb278205640658c99336d4caf4848c5bae92b48e15f325fa616cbc9d5f394649abfa02406a76e802cffbd3d312a22a6885
The `fee` field in the `getblock` RPC result (verbosity 2 and 3) may be
omitted when block undo data is not available. Marking it optional in
the `RPCResult` aligns the documented schema with the runtime behavior.
