d742be3d3f5d5063d7160f72422bce2fec953f38 ci: Switch native macOS CI job to Xcode 15.0 (Hennadii Stepanov)
8decc5c726caca2381cffbd1b3585862421f5b8e build: Fix `-Xclang -internal-isystem` option (Hennadii Stepanov)
Pull request description:
This PR:
- addresses https://github.com/bitcoin/bitcoin/pull/29165#discussion_r1439433156
- fixes https://github.com/bitcoin/bitcoin/issues/29174
ACKs for top commit:
fanquake:
ACK d742be3d3f5d5063d7160f72422bce2fec953f38. The same as what was done in #27328.
Tree-SHA512: 4788a0511e9fac638edab8e4f7ec62c5e08aeb07e518ab62fd53074ab3dd4eca1f62dc17c2af2b535bad12e77a7437e5c1c714cd03ce711e5d5e5c87d4620358
e5b9ee0221ec8aa238fb5720fcd6faa01b09fe46 fuzz: set `nMaxOutboundLimit` in connman target (brunoerg)
Pull request description:
Setting `nMaxOutboundLimit` (`-maxuploadtarget`) will make fuzz to reach more coverage in connman target. This value is used in `GetMaxOutboundTimeLeftInCycle`, `OutboundTargetReached` and `GetOutboundTargetBytesLeft`.
ACKs for top commit:
dergoegge:
utACK e5b9ee0221ec8aa238fb5720fcd6faa01b09fe46
jonatack:
ACK e5b9ee0221ec8aa238fb5720fcd6faa01b09fe46
Tree-SHA512: d19c83602b0a487e6da0e3be539aa2abc95b8bbf36cf9a3e391a4af53b959f68ca38548a96d27d56742e3b772f648da04e2bf8973dfc0ab1cdabf4f2e8d44de6
The `ALLOW_HOST_PACKAGES` variable was introduced in bitcoin#10508 "to
speed up build and avoid timeout".
It is no longer the case for our CI infrastructure, which uses self-
hosted persistent workers and depends caching.
In the current circumstances, it does not seem worth porting this
feature to the upcoming CMake-based build system.
406b71abcb72f234ddf9245a3f57e748343c774f wallet: Migrate entire address book entries (Andrew Chow)
Pull request description:
Not all of the data in an address book entry was being copied to the watchonly and solvables wallets. This includes information such as whether the address was previously spent, and any receive requests that may exist. A test has been added to check that the previously spent information is copied, although it passes without the changes in this PR since this information is also regenerated when a transaction is loaded/added into a wallet.
ACKs for top commit:
ryanofsky:
Code review ACK 406b71abcb72f234ddf9245a3f57e748343c774f. Just suggested change since last review
furszy:
Code review ACK 406b71ab
Tree-SHA512: 13de42b16a1d8524fe0555764744139566b2e7d29741ceffc1158a905dd537136b762330568b3b5cac28cbee1bfd363a20de97d0a6c5296738cb3aa99133945b
5779010ed7be1cbe9b98a91c7487d3d14b7cf24d RPC/Blockchain: scanblocks: Accept named param for filter_false_positives (Luke Dashjr)
Pull request description:
Possibly due to a silent cross-merge, `scanblocks` was left out of 96233146dd31c1d99fd1619be4449944623ef750
ACKs for top commit:
stickies-v:
ACK 5779010ed7be1cbe9b98a91c7487d3d14b7cf24d
theStack:
ACK 5779010ed7be1cbe9b98a91c7487d3d14b7cf24d
Tree-SHA512: bade107c7cb5fdd1265224c263a1e1edfc8bc0698b3abfac8d65c49a270181f0311713f7243813de17932a7a7ca65a36850e527ab0b433cf64c32191d3adde70
A Bitcoin Core node may only connect to a peer destination via I2P if both sides
have sessions with the same encryption type. The encryption type is a property
of the session, not the destination. Sessions may support multiple encryption
types.
As Bitcoin Core is not currently setting the I2P encryption type when creating
sessions, it is using the older default, ElGamal (type 0).
This pull updates Bitcoin Core to use both ECIES-X25519 and ElGamal (types 4 and
0, respectively). This allows to connect to I2P peers with either type, and the
newer, faster ECIES-X25519 will be preferred.
See also the recently updated section "Signature and Encryption Types" in
https://geti2p.net/en/docs/api/samv3
Thanks and credit to zzzi2p (https://github.com/zzzi2p) for reporting.
Closes https://github.com/bitcoin/bitcoin/issues/29197.
d83bea42d1f0ffb0899a6de3556c489543468995 wallettool: Don't create CWallet when dumping DB (Andrew Chow)
40c80e36b1a204ed133acc403016a6cb1a92051e wallettool: Don't unilaterally reset wallet_instance if loading error (Ava Chow)
Pull request description:
https://github.com/bitcoin/bitcoin/issues/29109#issuecomment-1863449058 reports that a wallet with noncritical errors cannot be dumped with `bitcoin-wallet dump`. This was caused by an erroneous reset of the wallet pointer when the loading the wallet returns something other than `LOAD_OK`. Not all errors are errors that require aborting, so unilaterally resetting the pointer at that time is incorrect. The first commit resolves this issue.
Furthermore, if a wallet has loading errors, that should not prevent the wallet tool from dumping the wallet. The wallet application logic should not get in the way of performing such a low level database operation, especially when it's primary usage is for debugging potentially corrupted wallets. The 2nd commit is taken from #28710 and changes the `dump` to stop at making a `WalletDatabase` rather than making a `CWallet` only to retrieve the underlying `WalletDatabase`.
ACKs for top commit:
furszy:
Code review ACK d83bea42d1
BrandonOdiwuor:
Code Review ACK d83bea42d1f0ffb0899a6de3556c489543468995
Tree-SHA512: 425d712dfff1002bd81272aca0bae1016f9126a3c89506f8cb7cf0a0ec9f33d0c03b8d03896394f3a45c2998e59047e19218dfd08dc8a5f40e8625134e886b0f
fa87f8feb76da42eeb5c4d32ee7be070b2bd559f doc: Clarify C++20 comments (MarcoFalke)
Pull request description:
Turns out "class template argument deduction for aggregates" is one of the few things implemented only in recent compilers, see https://en.cppreference.com/w/cpp/compiler_support/20
So clarify the comments.
ACKs for top commit:
hebasto:
ACK fa87f8feb76da42eeb5c4d32ee7be070b2bd559f, I verified the code with clang-{16,17}.
Tree-SHA512: f6d20f946cb6f8e34db224e074ed8f9dfa598377c066d1b58a8feb9e64d007444f1e2c0399e91a3e282fd5d59f90e0d7df90aa3956824d96bc78070ee12f603c
f8ca1357c8205ceff732dcfb0d2bad79b40b611b build: Fix check whether `-latomic` needed (Hennadii Stepanov)
Pull request description:
Clang >=15 still might need linking against `libatomic`.
We use `std::atomic<std::chrono::seconds>::compare_exchange_strong` in `net_processing.cpp`.
Addresses the https://github.com/bitcoin/bitcoin/pull/29165#discussion_r1440293694.
ACKs for top commit:
maflcko:
lgtm ACK f8ca1357c8205ceff732dcfb0d2bad79b40b611b
fanquake:
ACK f8ca1357c8205ceff732dcfb0d2bad79b40b611b
Tree-SHA512: ba8b6a88fd3471a206d068e8a000a053c99cb46d26bd04624418ddb066b3b9664a569ec8a1569af67c96b3e27f13dccbd5e24f985290ac072b6d74c92524e35d
fa46cc22bc696e6845915ae91d6b68e36bf4c242 Remove deprecated -rpcserialversion (MarcoFalke)
Pull request description:
The flag is problematic for many reasons:
* It is deprecated
* It is a global flag, requiring a restart to change, as opposed to a flag that can be set on each RPC invocation
* It may be hidden in config files by accident, hard to debug, causing LND crashes and bugs, see https://github.com/bitcoin/bitcoin/issues/28730#issuecomment-1780940868
* It makes performance improvements harder to implement: https://github.com/bitcoin/bitcoin/pull/17529#issuecomment-556082818
Fix all issues by removing it.
If there is a use-case, likely a per-RPC flag can be added, if needed.
ACKs for top commit:
ajtowns:
crACK fa46cc22bc696e6845915ae91d6b68e36bf4c242
TheCharlatan:
lgtm ACK fa46cc22bc696e6845915ae91d6b68e36bf4c242
Tree-SHA512: 96ba1c60356ce93954fe5c2a59045771c6d1516ad0d9dc436ef1800a1f1b0153f0d5fb78ca99d53ad54ba25fbce36962bdf1d4325aceedfc8154a61347a6a915
a44808fb437864878c2d9696b8a96193091446ee fuzz: rule-out too deep derivation paths in descriptor parsing targets (Antoine Poinsot)
Pull request description:
This fixes the `mocked_descriptor_parse` timeout reported in #28812 and direct the targets more toward what they are intended to fuzz: the descriptor syntax.
ACKs for top commit:
sipa:
utACK a44808fb437864878c2d9696b8a96193091446ee
achow101:
ACK a44808fb437864878c2d9696b8a96193091446ee
dergoegge:
ACK a44808fb437864878c2d9696b8a96193091446ee - Not running into timeouts anymore
TheCharlatan:
ACK a44808fb437864878c2d9696b8a96193091446ee
Tree-SHA512: a5dd1dbe9adf8f088bdc435addab88b56f435e6d7d2065bd6d5c6d80a32e3f1f97d3d2323131ab233618cd6dcc477c458abe3c4c865ab569449b8bc176231e93
29fde0223abc706925188014209eba75390a9df8 Squashed 'src/secp256k1/' changes from 199d27cea3..efe85c70a2 (fanquake)
Pull request description:
This includes changes from the 0.4.1 release: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.4.1.
> The point multiplication algorithm used for ECDH operations (module ecdh) was replaced with a slightly faster one.
> Optional handwritten x86_64 assembly for field operations was removed because modern C compilers are able to output more efficient assembly. This change results in a significant speedup of some library functions when handwritten x86_64 assembly is enabled (--with-asm=x86_64 in GNU Autotools, -DSECP256K1_ASM=x86_64 in CMake), which is the default on x86_64. Benchmarks with GCC 10.5.0 show a 10% speedup for secp256k1_ecdsa_verify and secp256k1_schnorrsig_verify.
ACKs for top commit:
hebasto:
re-ACK e2cdeb592596432039d21f4c819d45f1e46d65ef
jonasnick:
reACK e2cdeb592596432039d21f4c819d45f1e46d65ef
Tree-SHA512: eaa82721b63e84b9d8dae82956d5e75dbcee50c58c9049b7901055d79aef938bd268e18ce4ff85feb73aae7ee1cf58018b93067692f8f69f80216d336bd6f10a
faebf1df2afe207f5d2d4f73f50ac66824fe34bb wallet: Fix use-after-free in WalletBatch::EraseRecords (MarcoFalke)
Pull request description:
Creating a copy of the pointer to the underlying data of the stream is not enough to copy the data.
Currently this happens to work sometimes, because the stream may not immediately free unused memory. However, there is no guarantee by the stream interface to always behave this way. Also, if `vector::clear` is called on the underlying memory, any pointers to it are invalid.
Fix this, by creating a full copy of all bytes.
ACKs for top commit:
achow101:
ACK faebf1df2afe207f5d2d4f73f50ac66824fe34bb
Tree-SHA512: 79ede9bc16cf257609545597bc6d9623ceead4531780ea6037cc5684aa3a7c7d80601354d315358defe47193f978a8ce40c5dc4637e32936c76157679b549ac5
b1318dcc56a0181783ee7ddbd388ae878a0efc52 test: change `m_submitted_in_package` input to fuzz data provider boolean (ismaelsadeeq)
5615e16b705d74bf6ebb7c39523844f97a41cb6f tx fees: update `m_from_disconnected_block` to `m_mempool_limit_bypassed` (ismaelsadeeq)
fcd429664818f14cace580513e7e6159335b5416 doc: fix typo and update incorrect comment (ismaelsadeeq)
562664d26374331d291b97e2e2f7fca1f0fd467b test: wait for fee estimator to catch up before estimating fees (ismaelsadeeq)
Pull request description:
This is a simple PR that does two things
1. Fixes#29000 by waiting for the fee estimator to catch up after `removeForBlock` calls before calling `estimateFee` in the `BlockPolicyEstimates` unit test.
2. Addressed some outstanding review comments from #28368
- Updated `NewMempoolTransactionInfo::m_from_disconnected_block` to `NewMempoolTransactionInfo::m_mempool_limit_bypassed` which now correctly indicates what the boolean does.
- Changed input of `processTransaction`'s tx_info `m_submitted_in_package` input from false to fuzz data provider boolean.
- Fixed some typos, and update incorrect comment
ACKs for top commit:
martinus:
re-ACK b1318dcc56a0181783ee7ddbd388ae878a0efc52
glozow:
utACK b1318dcc56a0181783ee7ddbd388ae878a0efc52
Tree-SHA512: 45268729bc044da4748fe004524e0df696d2ec92c5bd053db9aad6e15675f3838429b2a7b9061a6b694be4dc319d1782a876b44df506ddd439d62ad07252d0e1
e03d6f7ed534f423f58236866f8e83beee1871e1 fuzz: set `m_fallback_fee`/`m_fee_mode` in `wallet_fees` target (brunoerg)
Pull request description:
`m_fallback_fee` and `m_fee_mode` are used in `GetMinimumFeeRate` but we're not setting any value for them in `wallet_fees` target. That's the reason fuzzing is never reaching the following code:
This PR fixes it.
ACKs for top commit:
maflcko:
review ACK e03d6f7ed534f423f58236866f8e83beee1871e1
achow101:
ACK e03d6f7ed534f423f58236866f8e83beee1871e1
murchandamus:
ACK e03d6f7ed534f423f58236866f8e83beee1871e1
Tree-SHA512: 5d364f5351d65762a3ddf88e3abb7bda401b7e4955285e083031d216fb50082b1ea98e2c065aff75a5a8a3d1bc4c2e5e3ca9f9478d902ee8f8d4347b6cbe53af
fa1d49542e4b69a5d8b1177ffe4207f051a468bb refactor: share and use `GenerateRandomKey` helper (Sebastian Falbesoner)
Pull request description:
Making the `GeneratingRandomKey` helper (recently introduced in PR #28433, commit b6934fd03f080d437acb1fd2b665503c3d6de785) available to other modules via key.{h.cpp} allows us to create random private keys directly at CKey instantiation, in contrast to the currently needed two-step process of creating an (invalid) CKey instance first and then having to call `MakeNewKey(...)`.
This is mostly used in unit tests and a few instances in the wallet.
ACKs for top commit:
Sjors:
re-ACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb
achow101:
ACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb
sipa:
utACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb
kristapsk:
cr utACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb
stratospher:
ACK fa1d495.
Tree-SHA512: 6fec73f33efe5bd77ca7d3c2fc06725d96f789f229294c39377e682ff222cfc7990b77c92e0bfd4cb6cf891d007ab1f86d395907511f06e87044bae37652a2fd
91dc48c14825a9075a57c1eefda202b83b6346ba doc: Add multiprocess design doc (Ryan Ofsky)
Pull request description:
Add multiprocess design doc and existing multiprocess documentation into design and usage sections.
Links to rendered markdown:
https://github.com/ryanofsky/bitcoin/blob/pr/ipcdoc/doc/design/multiprocess.mdhttps://github.com/ryanofsky/bitcoin/blob/pr/ipcdoc/doc/multiprocess.md
---
This PR is part of the [process separation project](https://github.com/bitcoin/bitcoin/issues/28722).
ACKs for top commit:
fjahr:
ACK 91dc48c14825a9075a57c1eefda202b83b6346ba
achow101:
ACK 91dc48c14825a9075a57c1eefda202b83b6346ba
TheCharlatan:
ACK 91dc48c14825a9075a57c1eefda202b83b6346ba
stickies-v:
ACK 91dc48c14825a9075a57c1eefda202b83b6346ba - left a couple of improvements but agreed that iterating in future PRs is better.
Tree-SHA512: 8890abd85555eb3a64e75e3393f867839771a83aaba7667c19eccac2e959fb37b13c3bc1906ff06ff3d66609e2c72835b4b9a22d31e997af4489092418eeb001
In reality some mempool transaction might be submitted in a package,
so change m_submitted_in_package to fuzz data provider boolean just like
m_has_no_mempool_parents.
The boolean indicates whether the transaction was added without enforcing mempool
fee limits. m_mempool_limit_bypassed is the correct variable name.
Also changes NewMempoolTransactionInfo booleans descriptions to the format that
is consistent with the codebase.
This affects manual connections made either with -connect, or with
-addnode provided as a bitcoind config arg (the addnode RPC has an
extra option for v2).
We don't necessarily know if our peer supports v2, but will reconnect
with v1 if they don't. In order to do that, improve the reconnection
behavior such that we will reconnect after a sleep of 500ms
(which usually should be enough for our peer to send us their
version message).
Making the `GenerateRandomKey` helper available to other modules via
key.{h.cpp} allows us to create random private keys directly at
instantiation of CKey, in contrast to the two-step process of creating
the instance and then having to call `MakeNewKey(...)`.
b335710782c2545e6eeed67b5e1763c07eab26b0 depends: patch around non-determinism in qt (fanquake)
e8ecec45756d7121edfaa1321c597d88ce7ec6db build: rename native_clang to native_llvm (fanquake)
b0c290340c1e1398dc9eb51b3e48a040de3f47d6 Revert "build: Patch Qt to handle minimum macOS version properly" (fanquake)
558250dec15e43b66c7b5a96543dd184925b6209 guix: use clang-toolchain-17 for macOS build (fanquake)
5ddd7c65b415629d4b57fb238d5fd39b049ccf79 build: Bump `native_clang` up to 17.0.6 (Hennadii Stepanov)
Pull request description:
This is the last step before #21778. We need LLVM 17.x so that lld has `-fixup_chains`.
ACKs for top commit:
theuni:
ACK b335710782c2545e6eeed67b5e1763c07eab26b0.
TheCharlatan:
ACK b335710782c2545e6eeed67b5e1763c07eab26b0
Tree-SHA512: 8142956196a481178f360258c2e4d924178d552966b713323f29f2deba7e5ec73a3da1c9d79d97c9e7f6aa18ed7429cd6660826aa633e6dde1ac56000b9ad57f
fae526345de539ab8f9b80100f6dfbe8e1d3284b Allow std::byte C-style array serialization (MarcoFalke)
fa898e6836a8fc2c7b6c8c15ad21818b16a89863 refactor: Print verbose serialize compiler error messages (MarcoFalke)
Pull request description:
Currently, trying to serialize an object that can't be serialized will fail with a short error message. For example, the diff and the error message:
```diff
diff --git a/src/test/serialize_tests.cpp b/src/test/serialize_tests.cpp
index d75eb499b4..773f49845b 100644
--- a/src/test/serialize_tests.cpp
+++ b/src/test/serialize_tests.cpp
@@ -62,6 +62,8 @@ public:
BOOST_AUTO_TEST_CASE(sizes)
{
+ int b[4];
+ DataStream{} << b << Span{b};
BOOST_CHECK_EQUAL(sizeof(unsigned char), GetSerializeSize((unsigned char)0));
BOOST_CHECK_EQUAL(sizeof(int8_t), GetSerializeSize(int8_t(0)));
BOOST_CHECK_EQUAL(sizeof(uint8_t), GetSerializeSize(uint8_t(0)));
```
```
./serialize.h:765:6: error: member reference base type 'const int[4]' is not a structure or union
765 | a.Serialize(os);
| ~^~~~~~~~~~
```
```
./serialize.h:277:109: error: no matching function for call to 'UCharCast'
277 | template <typename Stream, typename B> void Serialize(Stream& s, Span<B> span) { (void)/* force byte-type */UCharCast(span.data()); s.write(AsBytes(span)); }
| ^~~~~~~~~
```
This is fine. However, it would be more helpful for developers and more accurate by the compiler to explain why each function is not selected.
Fix this by using C++20 concepts where appropriate.
ACKs for top commit:
ajtowns:
reACK fae526345de539ab8f9b80100f6dfbe8e1d3284b
achow101:
ACK fae526345de539ab8f9b80100f6dfbe8e1d3284b
TheCharlatan:
Re-ACK fae526345de539ab8f9b80100f6dfbe8e1d3284b
Tree-SHA512: e03a684ccfcc5fbcad7f8a4899945a05989b555175fdcaebdb113aff46b52b4ee7b467192748edf99c5c348a620f8e52ab98bed3f3fca88280a64dbca458fe8a
e1281f1bbd884f15d40053c9bc24794d0ce9a58a wallet: fix key parsing check for miniscript expressions in `ParseScript` (brunoerg)
Pull request description:
In `ParseScript`, when processing miniscript expressions, the way we check for key parsing error is wrong, the actual code is unreachable because we're checking it into `if (node)` (successful parsing) statement.
ACKs for top commit:
sipa:
utACK e1281f1bbd884f15d40053c9bc24794d0ce9a58a
RandyMcMillan:
utACK e1281f1bbd
achow101:
ACK e1281f1bbd884f15d40053c9bc24794d0ce9a58a
Tree-SHA512: c4b3765d32673928a1f6d84ecbaa311870da9a9625753ed15ea57c802a9f16ddafa48c1dc66c0e4be284c5862e7821ed94135498ed9b9f3d7342a080035da289
