Age | Commit message (Collapse) | Author |
|
This adds an implementation of the ChaCha20Poly1305 AEAD exactly matching
the version specified in RFC8439 section 2.8, including tests and official
test vectors.
|
|
Remove the variant of ChaCha20Poly1305 AEAD that was previously added in
anticipation of BIP324 using it. BIP324 was updated to instead use rekeying
wrappers around otherwise unmodified versions of the ChaCha20 stream cipher
and the ChaCha20Poly1305 AEAD as specified in RFC8439.
|
|
In `wallet_fundrawtransaction`, `totalOut` is used in
some functions to check if the change is correct. In
other ones, it has been created but never used.
|
|
In `wallet_fundrawtransaction`, there are some unecessary
variables/calls to `decoderawtransaction`. They have not
been used.
|
|
Use reinterpret_cast
fa9108f85afdc926fd6a8b96cc2acff7ca25d7a8 refactor: Use reinterpret_cast where appropriate (MarcoFalke)
3333f950d49f13662842650ae76599a0dff052eb refactor: Avoid casting away constness (MarcoFalke)
fa6394dd10ae71755e46fd523dd43c2a1f2b832d refactor: Remove unused C-style casts (MarcoFalke)
Pull request description:
Using a C-style cast to convert pointer types to a byte-like pointer type has many issues:
* It may accidentally and silently throw away `const`.
* It forces reviewers to check that it doesn't accidentally throw away `const`.
For example, on current master a `const char*` is cast to `unsigned char*` (without `const`), see https://github.com/bitcoin/bitcoin/blob/d23fda05842ba4539b225bbab01b94df0060f697/src/span.h#L273 . This can lead to UB, and the only reason why it didn't lead to UB is because the return type added back the `const`. (Obviously this would break if the return type was deduced via `auto`)
Fix all issues by adding back the `const` and using `reinterpret_cast` where appropriate.
ACKs for top commit:
darosior:
re-utACK fa9108f85afdc926fd6a8b96cc2acff7ca25d7a8
hebasto:
re-ACK fa9108f85afdc926fd6a8b96cc2acff7ca25d7a8.
john-moffett:
ACK fa9108f85afdc926fd6a8b96cc2acff7ca25d7a8
Tree-SHA512: 87f6e4b574f9bd96d4e0f2a0631fd0a9dc6096e5d4f1b95042fe9f197afc2fe9a24e333aeb34fed11feefcdb184a238fe1ea5aff10d580bb18d76bfe48b76a10
|
|
test_locked_wallet case
c648bdbda21c7ae90c6b40e506ca4ed62b1dbb6c test: create wallet specific for test_locked_wallet case (furszy)
Pull request description:
Coming from https://github.com/bitcoin/bitcoin/pull/28089#discussion_r1265478128.
Several test cases are relying on the node1 default wallet, which thanks to 'test_locked_wallet' is encrypted.
And can be only accessed within a specific timeframe (100ms), a duration internally set by the same test.
This situation introduces a potential race condition, where other tests must complete their operations within
the specified 100ms window to pass (otherwise the wallet gets re-locked and they fail).
This can be seen running the test in valgrind (https://github.com/bitcoin/bitcoin/pull/28089), where other test cases fail due the wallet re-locking
itself after the 100ms.
ACKs for top commit:
MarcoFalke:
lgtm ACK c648bdbda21c7ae90c6b40e506ca4ed62b1dbb6c
ishaanam:
utACK c648bdbda21c7ae90c6b40e506ca4ed62b1dbb6c
Tree-SHA512: 01cde5a4a0cb3405adb9ea3c1f73841f3fa237d1162268ed06f0d49ca38541006b423a029e0b5e5955e1aa7e018c4600d894e555a68cf17ff60a4b8be58f4aa9
|
|
events in validationinterface_tests
faca9a3d5a6887517d02b994a43d0e1101b718bc test: Avoid intermittent issues due to async events in validationinterface_tests (MarcoFalke)
Pull request description:
Currently the tests have many issues:
* They setup the genesis block, even though it is not needed
* They queue an async `UpdatedBlockTip` even, which causes intermittent issues: https://github.com/bitcoin/bitcoin/issues/28146#issuecomment-1650064645
Fix all issues by trimming down the setup to just `ChainTestingSetup`.
ACKs for top commit:
Crypt-iQ:
tACK faca9a3d5a6887517d02b994a43d0e1101b718bc
Tree-SHA512: 4449040330f89bbaf5ce5b2052417c160b451c373987fdf1069596c07834ed81f0aea1506d53c7d2cd21062b27332d30679285dae194b272fd0cb9ce5ded32cf
|
|
`type:ClassName::MethodName` should be used
d0c6cc4abe42163aaf081a969d2c449785563ba2 suppressions: note that 'type:ClassName::MethodName' should be used (fanquake)
Pull request description:
Now that the symbolizer is back in play, suppressions can once-again be targeted to functions, rather than file-wide.
ACKs for top commit:
MarcoFalke:
lgtm ACK d0c6cc4abe42163aaf081a969d2c449785563ba2
hebasto:
ACK d0c6cc4abe42163aaf081a969d2c449785563ba2
Tree-SHA512: fb65398eae18a6ebc5f8414275c568cf2664ab5357c2b3160f3bf285b67bc3af788225c5dba3c824c0e098627789450bec775375f52529d71c6ef700a9632d65
|
|
systems
53c990ad3406ee945305af84af98d2f020e5f316 test: fix `feature_addrman.py` on big-endian systems (Sebastian Falbesoner)
Pull request description:
The test `feature_addrman.py` currently serializes the addrdb without specifying endianness for `int`s, so the machine's native byte order is used (see https://docs.python.org/3/library/struct.html#byte-order-size-and-alignment) and the generated `peers.dat` would be invalid on big-endian systems (our internal (de)serializers always use little-endian, see `ser_{read,write}data32`). Fix this by explicitly specifying little-endian serialization via the `<` character in `struct.pack(...)`.
This is not detected by CI as we unfortunately don't run functional tests on big-endian systems there (I think we definitely should!).
ACKs for top commit:
MarcoFalke:
lgtm ACK 53c990ad3406ee945305af84af98d2f020e5f316 🔚
Tree-SHA512: 513af6f1f785a713e7a8ef3a57fcd3fe2520a7d537f63a9c8e1f4bdea4c2f605fd4c35001623d6b13458883dbc256f24943684ab8f224055c22bf8d8eeee5fe2
|
|
50f7214e0915a88dd81c1ac1d292e049a398cda2 valgrind: add suppression for bug 472219 (fanquake)
Pull request description:
Now that https://bugs.kde.org/show_bug.cgi?id=472219 has been fixed upstream in:
https://sourceware.org/git/?p=valgrind.git;a=commit;h=6ce0979884a8f246c80a098333ceef1a7b7f694d
Add a supression to ignore the bug until we are using a fixed version of Valgrind.
Related to #28072.
ACKs for top commit:
MarcoFalke:
lgtm ACK 50f7214e0915a88dd81c1ac1d292e049a398cda2
Tree-SHA512: 1030f3709195250350fd9c558420a9b1773fb54fdb323e0452a46eeb69ec6d60b5df50bde617c12d917e16dde07db64dee1b0101ddd4eda6161261fc7f6d4474
|
|
fa3d72960bc86319aa8b838e3df4e833f845c71f lint: Ignore check_fileopens failure on **kwargs (MarcoFalke)
fa6bb85cd264adf2e1f0c71fa97b650f9a62745f test: Ignore UTF-8 errors in assert_debug_log (MarcoFalke)
fa63326fbc1634ef2816f79c54db9266e56f4b3b test: Fix debug_log_size helper (MarcoFalke)
Pull request description:
Fix two bugs, see commit messages.
ACKs for top commit:
theStack:
utACK fa3d72960bc86319aa8b838e3df4e833f845c71f
Tree-SHA512: 4a29bdf954bf62bb7676c2a41b03ad017bc86d535b2bd912c96bd41d1621beb06d840b53c211480ad51974e8b293bbae620060d2528d269159f32c0b44e47712
|
|
std::allocator
07c59eda00841aafaafd8fd648217b56b1e907c9 Don't derive secure_allocator from std::allocator (Casey Carter)
Pull request description:
Giving the C++ Standard Committee control of the public interface of your type means they will break it. C++23 adds a new `allocate_at_least` member to `std::allocator`. Very bad things happen when, say, `std::vector` uses `allocate_at_least` from `secure_allocator`'s base to allocate memory which it then tries to free with `secure_allocator::deallocate`.
(Discovered by microsoft/STL#3712, which will be reverted by microsoft/STL#3819 before it ships.)
ACKs for top commit:
jonatack:
re-ACK 07c59eda00841aafaafd8fd648217b56b1e907c9 no change since my previous ACK apart from squashing the commits
achow101:
ACK 07c59eda00841aafaafd8fd648217b56b1e907c9
john-moffett:
ACK 07c59eda00841aafaafd8fd648217b56b1e907c9 Reviewed and tested. Performance appears unaffected in my environment.
Tree-SHA512: 23606c40414d325f5605a9244d4dd50907fdf5f2fbf70f336accb3a2cb98baa8acd2972f46eab1b7fdec1d28a843a96b06083cd2d09791cda7c90ee218e5bbd5
|
|
6960c81cbfa6208d4098353e53b313e13a21cb49 kernel: Remove Univalue from kernel library (TheCharlatan)
10eb3a9faa977371facacee937b2e6dc26f008e0 kernel: Split ParseSighashString (TheCharlatan)
Pull request description:
Besides the build system changes, this is a mostly move-only change for moving the few UniValue-related functions out of kernel files.
UniValue is not required by any of the kernel components and a JSON library should not need to be part of a consensus library.
ACKs for top commit:
achow101:
ACK 6960c81cbfa6208d4098353e53b313e13a21cb49
theuni:
Re-ACK 6960c81cbfa6208d4098353e53b313e13a21cb49
stickies-v:
re-ACK https://github.com/bitcoin/bitcoin/commit/6960c81cbfa6208d4098353e53b313e13a21cb49
Tree-SHA512: d92e4cb4e12134c94b517751bd746d39f9b8da528ec3a1c94aaedcce93274a3bae9277832e8a7c0243c13df0397ca70ae7bbb24ede200018c569f8d81103c1da
|
|
Also changes max_extra_txs into a uint32_t to avoid platform-specific
behaviour
|
|
|
|
|
|
Follow-up for #28025.
|
|
It is not required by any of the kernel components.
A JSON library should not need to be part of a consensus library.
|
|
This split is done in preparation for the next commit where the
dependency on UniValue in the kernel library is removed.
|
|
|
|
python p2p instances will automatically send a getaddr msg after
connecting, the explicit message was a duplicate that was being ignored.
|
|
Only the combined addr:port of source and destination
must be unique. If the destination is different, the same addr:port
for the source may be used by the OS.
|
|
-BEGIN VERIFY SCRIPT-
sed -i 's|].chain_path / "blocks"|].blocks_path|g' $(git grep -l chain_path)
-END VERIFY SCRIPT-
|
|
|
|
* The node was only used to migrate the legacy txindex. But now that it
is known to be working and that 22.x is EOL, it can be dropped.
* Also, fix a typo to properly check the txindex of node [1], not [2].
|
|
Initialize PeerManager::Options early to avoid reading -blocksonly twice.
|
|
Refactor to consistently use ApplyArgsManOptions to set all PeerManager::Options,
including ignore_incoming_txs.
|
|
The test creates enough blocks itself, so there is no need to have more.
Also, remove os import.
|
|
Nobody is pushing direct to guix.sigs, nor should they, as that
bypasses CI.
Use a newer example for the testing issue.
Don't duplicate the bitcoincore.org doc instructions.
|
|
Now that the symbolizer is back in play, suppressions can once-again be
targeted to functions, rather than file-wide.
|
|
|
|
We haven't done this since 22.0. It's not clear why dumping out a
version of git log into the release-notes is that useful.
|
|
It has been removed from the file.
|
|
faa8c1be265d2344a3bc0932455b0182ec7d64c7 fuzz: Re-enable symbolize=1 in ASAN_OPTIONS (MarcoFalke)
Pull request description:
Looks like this fixed itself somehow and is no longer reproducible?
ACKs for top commit:
fanquake:
ACK faa8c1be265d2344a3bc0932455b0182ec7d64c7
Tree-SHA512: 67d2d6349cc7485f32bebabc18869ab101ae66a778a40ff9ddb037980997e600d7c6d1e0a17a011fa2a4ba07c73594b087dd781248cb8351f2688bc4cf6e587d
|
|
from gArgs
23c7b51ddd2888cf7fb260c439f004bd28768473 [net processing] Move -capturemessages to PeerManager::Options (dergoegge)
bd59bda26b67b53293a5cef7433e992203da325a [net processing] Move -blockreconstructionextratxn to PeerManager::Options (dergoegge)
567c4e0b6a3fadd2fd1be732076026bf491519b2 [net processing] Move -maxorphantx to PeerManager::Options (dergoegge)
fa9e6d80d1c55f8b1bb2691bfd67e8c2b7189b38 [net processing] Move -txreconciliation to PeerManager::Options (dergoegge)
4cfb7b925f8fea818f03433882138a7d3d7e179a [net processing] Use ignore_incoming_txs from m_opts (dergoegge)
8b877259217c6da316153afb136a55c2dbd401c2 [net processing] Introduce PeerManager options (dergoegge)
Pull request description:
This PR decouples `PeerManager` from our global args manager by introducing `PeerManager::Options`.
ACKs for top commit:
stickies-v:
re-ACK 23c7b51ddd2888cf7fb260c439f004bd28768473
TheCharlatan:
ACK 23c7b51ddd2888cf7fb260c439f004bd28768473
Tree-SHA512: cd807b36ec018010e11935d3539fa7ed5015fdfb531d13a042a65b54ee8533a35a919a6a6c5fa293b5cba76000e9403c64dfd790fb9c649b7838544929b1fee8
|
|
Now that https://bugs.kde.org/show_bug.cgi?id=472219 has been fixed
upstream in:
https://sourceware.org/git/?p=valgrind.git;a=commit;h=6ce0979884a8f246c80a098333ceef1a7b7f694d
Add a supression to ignore the bug until we are using a fixed version of
Valgrind.
Related to #28072.
|
|
Affects both secure_allocator and zero_after_free_allocator.
Giving the C++ Standard Committee control of the public interface of your type means they will break it. C++23 adds a new `allocate_at_least` member to `std::allocator`. Very bad things happen when, say, `std::vector` uses `allocate_at_least` from `secure_allocator`'s base to allocate memory which it then tries to free with `secure_allocator::deallocate`.
Drive-by: Aggressively remove facilities unnecessary since C++11 from both allocators to keep things simple.
|
|
|
|
This is to (a) avoid repeated lookups into the block index for an entry that
should never change and (b) emphasize that the snapshot base should always
exist when set and not change during the runtime of the program.
Thanks to Russ Yanofsky for suggesting this approach.
|
|
Also rewrite CheckBlockIndex() to perform tests on all chainstates.
This increases sanity-check coverage, as any place in our code where we were
invoke CheckBlockIndex() on a single chainstate will now invoke the sanity
checks on all chainstates.
This change also tightens up the checks on setBlockIndexCandidates and
mapBlocksUnlinked, to more precisely match what we aim for even in the presence
of assumed-valid blocks.
|
|
|
|
chainstates
When using assumeutxo and multiple chainstates are active, the background
chainstate should consider all HAVE_DATA blocks that are ancestors of the
snapshotted block and that have more work than the tip as potential candidates.
|
|
When using assumeutxo, we only need the background chainstate to consider
blocks that are on the chain leading to the snapshotted block.
Note that this introduces the new invariant that we can only have an assumeutxo
snapshot where the snapshotted blockhash is in our block index. Unknown block
hashes that are somehow passed in will cause assertion failures when processing
new blocks.
Includes test fixes and improvements by Andrew Chow and Fabian Jahr.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|