6bfa26048dbafb91e9ca63ea8d3960271e798098 testnet: Add timewarp attack prevention for Testnet4 (Fabian Jahr)
0100907ca168c53e8fe044bdda396f308825162c testnet: Add Testnet4 difficulty adjustment rules fix (Fabian Jahr)
74a04f9e7ad6a16988149cc3438b9ce13c91cdb9 testnet: Introduce Testnet4 (Fabian Jahr)
Pull request description:
To supplement the [ongoing conceptual discussion about a testnet reset](https://groups.google.com/g/bitcoindev/c/9bL00vRj7OU/m/9yCPo3uUBwAJ) I have drafted a move to v4 including a fix to the difficulty adjustment mechanism, which was part of the motivation that started the discussion.
Conceptual considerations:
- The conceptual discussion about doing a testnet4 or softforking the fix into testnet3 is outside of the scope of this PR and I would ask reviewers to contribute their opinions on this on the ML instead. However, I am happy to adapt this PR to a softfork change on testnet3 if there is consensus for that instead.
- The difficulty adjustment fix suggested here touches the `CalculateNextWorkRequired` function and uses the same logic used in `GetNextWorkRequired` to find the last previous block that was not mined with difficulty 1 under the exceptionf. An alternative fix briefly mentioned on the mailing list by Jameson Lopp would be to "restrict the special testnet minimum difficulty rule so that it can't be triggered on the block right before a difficulty retarget". That would also fix the issue but I find my suggestion here a bit more elegant.
ACKs for top commit:
jsarenik:
tACK 6bfa26048dba
achow101:
ACK 6bfa26048dbafb91e9ca63ea8d3960271e798098
murchandamus:
tACK 6bfa26048dbafb91e9ca63ea8d3960271e798098
Tree-SHA512: 0b8b69a621406a944da5be551b863d065358ba94d85dd3b80d83c412660e230ee93b27316081fbee9b4851cc4ff8585db64c7dfa26cb5148ac835663f2712c3d
1f93e3c360f3da38a02fe6c01551f424a2d63dc9 add deprecation warning for mempoolfullrbf (glozow)
4400c979a309ed03c7ed55644122622eb7def089 [doc] update documentation for new mempoolfullrbf default (glozow)
Pull request description:
Followup to #30493. Update bips.md and policy/*.md to reflect new default rules around signaling requirements in RBF.
Also, log a warning when `-mempoolfullrbf=0` that this config option is deprecated and will be removed in a future release.
ACKs for top commit:
petertodd:
ACK 1f93e3c360f3da38a02fe6c01551f424a2d63dc9
instagibbs:
ACK 1f93e3c360
tdb3:
ACK 1f93e3c360f3da38a02fe6c01551f424a2d63dc9
Tree-SHA512: f60a9524f15cfaa4c10c40b6f62b787d3f9865aac48ca883def30efac4f8a118f1359532f1b209ea34e201f0b1c92398abc8bc1e439e6b60910cc7f75c51e9ae
ec973dd19719541dbcd6f3a6facf6f5dd7cf439c refactor: remove un-tested early returns (josibake)
72a5822d43d47431b2838ebfcb1f2e21210f5ccb tests: add tests for KeyPair (josibake)
cebb08b121ce8c4c5e68bd043b8668c106e31169 refactor: move SignSchnorr to KeyPair (josibake)
c39fd39ba868253b5118db2e1ac1461d29f0b4ce crypto: add KeyPair wrapper class (josibake)
5d507a0091da1b6c013b00b6c76e19dd4d3b93a7 tests: add key tweak smoke test (josibake)
f14900b6e4eac26ae5f1c0badfa176d895851c97 bench: add benchmark for signing with a taptweak (josibake)
Pull request description:
Broken out from #28201
---
The wallet returns an untweaked internal key for taproot outputs. If the output commits to a tree of scripts, this key needs to be tweaked with the merkle root. Even if the output does not commit to a tree of scripts, BIP341/342 recommend commiting to a hash of the public key.
Previously, this logic for applying the taptweak was implemented in the `CKey::SignSchnorr` method.
This PR moves introduces a KeyPair class which wraps a `secp256k1_keypair` type and refactors SignSchnorr to use this new KeyPair. The KeyPair class is created with an optional merkle_root argument and the logic from BIP341 is applied depending on the state of the merkle_root argument.
The motivation for this refactor is to be able to use the tap tweak logic outside of signing, e.g. in silent payments when retrieving the private key (see #28201).
Outside of silent payments, since we almost always convert a `CKey` to a `secp256k1_keypair` when doing anything with taproot keys, it seems generally useful to have a way to model this type in our code base.
ACKs for top commit:
paplorinc:
ACK ec973dd19719541dbcd6f3a6facf6f5dd7cf439c - will happily reack if you decide to apply @ismaelsadeeq's suggestions
ismaelsadeeq:
Code review ACK ec973dd19719541dbcd6f3a6facf6f5dd7cf439c
itornaza:
trACK ec973dd19719541dbcd6f3a6facf6f5dd7cf439c
theStack:
Code-review ACK ec973dd19719541dbcd6f3a6facf6f5dd7cf439c
Tree-SHA512: 34947e3eac39bd959807fa21b6045191fc80113bd650f6f08606e4bcd89aa17d6afd48dd034f6741ac4ff304b104fa8c1c1898e297467edcf262d5f97425da7b
6714276d72244c2e2dbe9617f1341ba7fc06c0cc miniscript: Use `ToIntegral` instead of `ParseInt64` (brunoerg)
Pull request description:
Currently, miniscript code uses `ParseInt64` function for `after`, `older`, `multi` and `thresh` fragments. It means that a leading `+` or whitespace, among other things, are accepted into the fragments. However, these cases are not useful and cause Bitcoin Core to behave differently compared to other miniscript implementations (see https://github.com/brunoerg/bitcoinfuzz/issues/34). This PR fixes it.
ACKs for top commit:
achow101:
ACK 6714276d72244c2e2dbe9617f1341ba7fc06c0cc
tdb3:
cr ACK 6714276d72244c2e2dbe9617f1341ba7fc06c0cc
danielabrozzoni:
tACK 6714276d72244c2e2dbe9617f1341ba7fc06c0cc
darosior:
utACK 6714276d72244c2e2dbe9617f1341ba7fc06c0cc
Tree-SHA512: d9eeb93f380f346d636513eeaf26865285e7b0907b8ed258fe1e02153a9eb69d484c82180eb1c78b0ed77ad5f0e5b244be6672c2f890b1d9fddc9e844bee6dde
fa18fc705084f3620be566d8c6639b29117ccf68 log: Remove NOLINT(bitcoin-unterminated-logprintf) (MarcoFalke)
Pull request description:
`NOLINT(bitcoin-unterminated-logprintf)` is used to document a missing trailing `\n` char in the format string. This has many issues:
* It is just documentation, assuming that a trailing `\n` ends up in the formatted string. It is not enforced at compile-time, so it is brittle.
* If the newline was truly missing and `NOLINT(bitcoin-unterminated-logprintf)` were used to document a "continued" line, the log stream would be racy/corrupt, because any other thread may inject a log message in the meantime.
* If the newline was accidentally missing, nothing is there to correct the mistake.
* The intention of all code is to always end a log line with a new line. However, historic code exists to deal with the case where the new line was missing (`m_started_new_line`). This is problematic, because the presumed dead code has to be maintained (https://github.com/bitcoin/bitcoin/pull/30386#discussion_r1682963306).
Fix almost all issues by removing the `NOLINT(bitcoin-unterminated-logprintf)`, ensuring that a new line is always present.
A follow-up will remove the dead logging code.
ACKs for top commit:
TheCharlatan:
ACK fa18fc705084f3620be566d8c6639b29117ccf68
ryanofsky:
Code review ACK fa18fc705084f3620be566d8c6639b29117ccf68
Tree-SHA512: bf8a83723cca84e21187658edc19612da79c34f7ef2e1f6e9353e7ba70e4ecc0a878a2ae32290045fb90cba9a44451e35341a36ef2ec1169d13592393aa4a8ca
bbcba09cd5ca5fdd9055aaf64781125c5e505576 build: remove check for __declspec(dllexport) (fanquake)
37c9abdc4375ce1a1b9186a63e8c133fbb7feebd build: remove check for __attribute__((visibility.. (fanquake)
Pull request description:
These are unused (since libbitcoinconsensus / #29648), and the current CMake port doesn't quite match behaviour, such that there's no real point in doing the check. So rather than port anything, just remove it. If these are needed again in future (i.e for kernel or similar), they can be revisted, and it might be the case that build-system level checks will not be wanted.
ACKs for top commit:
hebasto:
ACK bbcba09cd5ca5fdd9055aaf64781125c5e505576. I've verified that neither `HAVE_DEFAULT_VISIBILITY_ATTRIBUTE` nor `HAVE_DLLEXPORT_ATTRIBUTE` are used or evaluated in the current codebase.
TheCharlatan:
ACK bbcba09cd5ca5fdd9055aaf64781125c5e505576
willcl-ark:
ACK bbcba09cd5ca5fdd9055aaf64781125c5e505576
Tree-SHA512: 332f018c50a159d2cbfd2f9ce018538fa11cf06a94e27ed42146945b86645af5881095df39cadd2f775a8ae348ebfc949d54f7eb4b62264bf48119c9f9952c20
e9de0a76b99fd4708295e1178f6c079db92e7f36 doc: release note for 30212 (willcl-ark)
87b188052528e97729a85d9701864eaff1ea5ec6 rpc: clarify ALREADY_IN_CHAIN rpc errors (willcl-ark)
Pull request description:
Closes: #19363
Renaming this error improves clarity around the returned error both internally and externally when a transactions' outputs are already found in the utxo set (`TransactionError::ALREADY_IN_CHAIN -> TransactionError::ALREADY_IN_UTXO_SET`)
ACKs for top commit:
tdb3:
ACK e9de0a76b99fd4708295e1178f6c079db92e7f36
ismaelsadeeq:
ACK e9de0a76b99fd4708295e1178f6c079db92e7f36
ryanofsky:
Code review ACK e9de0a76b99fd4708295e1178f6c079db92e7f36.
Tree-SHA512: 7d2617200909790340951fe56a241448f9ce511900777cb2a712e8b9c0778a27d1f912b460f82335844224f1abb4322bc898ca076440959edade55c082a09237
59c0ece0a785ce9e22fbfefce9ca228d85e5d43d fuzz: replace hardcoded numbers for bech32 limits (josibake)
Pull request description:
Follow-up to #30047 to replace a hardcoded value that was missed in the original PR
ACKs for top commit:
paplorinc:
ACK 59c0ece0a785ce9e22fbfefce9ca228d85e5d43d
dergoegge:
utACK 59c0ece0a785ce9e22fbfefce9ca228d85e5d43d
marcofleon:
ACK 59c0ece0a785ce9e22fbfefce9ca228d85e5d43d. Ran the test a bit to be sure, lgtm.
brunoerg:
utACK 59c0ece0a785ce9e22fbfefce9ca228d85e5d43d
Tree-SHA512: 89799928feb6752a533259117340b087ff7299f9bf204b165dd87708e15b99a338521f2ac9f9e1fd91dc48b93be839059768d9e68b172e36328232174d1dfa3f
a0a9a11642752578fb1f5142c3fb26cb39d1548a depends: fix ZMQ CMake getcachesize check (fanquake)
Pull request description:
Fixes#30587.
ACKs for top commit:
maflcko:
ACK a0a9a11642752578fb1f5142c3fb26cb39d1548a
hebasto:
ACK a0a9a11642752578fb1f5142c3fb26cb39d1548a. On Ubuntu (s390x), I was able to reproduce https://github.com/bitcoin/bitcoin/issues/30587. With this PR building `zeromq` succeeds.
TheCharlatan:
ACK a0a9a11642752578fb1f5142c3fb26cb39d1548a
Tree-SHA512: 70ca50ebe8e36d5a10a2354a1fbed49f5f802ae5115e09686bccca7e5d1da35168e84a6cab40dd2c83f8918889cdfdcbd5d1cbe25273b844c8ddd21865ea6c51
fa895c72832f9555b52d5bb1dba1093f73de3136 mingw: Document mode wbx workaround (MarcoFalke)
fa359255fe6b4de5f26784bfc147dbfb58bef116 Add -blocksxor boolean option (MarcoFalke)
fa7f7ac040a9467c307b20e77dc47c87d7377ded Return XOR AutoFile from BlockManager::Open*File() (MarcoFalke)
Pull request description:
Currently the *.dat files in the blocksdir store the data received from remote peers as-is. This may be problematic when a program other than Bitcoin Core tries to interpret them by accident. For example, an anti-virus program or other program may scan them and move them into quarantine, or delete them, or corrupt them. This may cause Bitcoin Core to fail a reorg, or fail to reply to block requests (via P2P, RPC, REST, ...).
Fix this, similar to https://github.com/bitcoin/bitcoin/pull/6650, by rolling a random XOR pattern over the dat files when writing or reading them.
Obviously this can only protect against programs that accidentally and unintentionally are trying to mess with the dat files. Any program that intentionally wants to mess with the dat files can still trivially do so.
The XOR pattern is only applied when the blocksdir is freshly created, and there is an option to disable it (on creation), so that people can disable it, if needed.
ACKs for top commit:
achow101:
ACK fa895c72832f9555b52d5bb1dba1093f73de3136
TheCharlatan:
Re-ACK fa895c72832f9555b52d5bb1dba1093f73de3136
hodlinator:
ACK fa895c72832f9555b52d5bb1dba1093f73de3136
Tree-SHA512: c92a6a717da83bc33a9b8671a779eeefde2c63b192362ba1d71e6535ee31d08e2802b74acc908345197de9daac6930e4771595ee25b09acd5a67f7ea34854720
f3cfbd65f54b5b6423d786fb8850cece05af603e net: log connections failures via SOCKS5 with less severity (Vasil Dimov)
Pull request description:
It is expected to have some Bitcoin nodes unreachable some of the time. A failure to connect to an IPv4 or IPv6 node is already properly logged under category=net/severity=debug. Do the same when a connection fails when using a SOCKS5 proxy. This could be either to an .onion address or to an IPv4 or IPv6 address (via a Tor exit node).
Related: https://github.com/bitcoin/bitcoin/issues/29759
ACKs for top commit:
achow101:
ACK f3cfbd65f54b5b6423d786fb8850cece05af603e
mzumsande:
Code Review ACK f3cfbd65f54b5b6423d786fb8850cece05af603e
tdb3:
Code Review ACK f3cfbd65f54b5b6423d786fb8850cece05af603e
Tree-SHA512: c6e83568783cb5233edac7840a00f708d27be9af87480fc73093ad99fe4bd8670d3f2c97fd6b6e2c54b8d9337746eacb9a5db6eefecc1486951996bfbb0a37f7
172c1ad026cc38c6f52679e74c14579ecc77c48e test: expand LimitOrphan and EraseForPeer coverage (Greg Sanders)
28dbe218feef51cbc28051273334dd73ba4500c0 refactor: move orphanage constants to header file (Greg Sanders)
Pull request description:
Inspired by refactorings in #30000 as the coverage appeared a bit sparse.
Added some minimal border value testing, timeouts, and tightened existing assertions.
ACKs for top commit:
achow101:
ACK 172c1ad026cc38c6f52679e74c14579ecc77c48e
rkrux:
reACK [172c1ad](172c1ad026)
glozow:
reACK 172c1ad026cc38c6f52679e74c14579ecc77c48e
Tree-SHA512: e8fa9b1de6a8617612bbe9b132c9c0c9b5a651ec94fd8c91042a34a8c91c5f9fa7ec4175b47e2b97d1320d452c23775be671a9970613533e68e81937539a7d70
590456e3f1043ba0680e0afec9fd7653db1098bb policy: enable full-rbf by default (Peter Todd)
195e98ea8e7746a84bbf980d547f88ee5242f35a doc: add release notes for full-rbf (Peter Todd)
Pull request description:
This pull request enables full rbf (mempool policy) by default. #28132 was closed recently with this [comment](https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-2225369634).
---
Rationale:
- Full RBF config option was added in July 2022: https://github.com/bitcoin/bitcoin/pull/25353
- It is used regularly: https://mempool.space/rbf#fullrbf
- Most mining pools are using it: https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-2059120917
ACKs for top commit:
petertodd:
ACK 590456e3f1043ba0680e0afec9fd7653db1098bb
instagibbs:
reACK 590456e3f1
glozow:
reACK 590456e3f1043ba0680e0afec9fd7653db1098bb
achow101:
ACK 590456e3f1043ba0680e0afec9fd7653db1098bb
ariard:
tested ACK 590456e3
murchandamus:
reACK 590456e3f1043ba0680e0afec9fd7653db1098bb
Tree-SHA512: 83fceef9961021687e6ff979041f89be0c616f7a49cc28a5d7edf7d8ad064fcb9c0e2af0c31f4f89867a9f6dff4e40ef8ad4dbd624e7d6a4e00ac1f1c1f66c7a
fa530ec54386a3fd56b51e50699b424cc8647821 rpc: Return precise loadtxoutset error messages (MarcoFalke)
faa5c86dbfec1ed7bdcd6a07316315147a7e87a2 refactor: Use untranslated error message in ActivateSnapshot (MarcoFalke)
Pull request description:
The error messages should never happen in normal operation. However, if
they do, they are helpful to return to the user to debug the issue. For
example, to notice a truncated file.
This fixes https://github.com/bitcoin/bitcoin/issues/28621
Also includes a minor refactor commit.
ACKs for top commit:
fjahr:
Code review ACK fa530ec54386a3fd56b51e50699b424cc8647821
ryanofsky:
Code review ACK fa530ec54386a3fd56b51e50699b424cc8647821, just adjusting error messages a little since last review. (Thanks!)
Tree-SHA512: 224968c9b13d082ca2ed1f6a8fcc5f51ff16d6c96bd38c3679699505b54337b99cccaf7a8474391f6b11f9ccb101977b4e626898c1217eae95802e290cf105f1
2d9d752e4fc30aabf2ddd36ca7a63432d26d4fea scripted-diff: Replace uint256S("str") -> uint256{"str"} (Hodlinator)
c06f2368e2346b087b72064a4f1e9817a680ef5f refactor: Hand-replace some uint256S -> uint256 (Hodlinator)
b74d8d58fa4e620e24c30a1786e968604423a028 refactor: Add consteval uint256(hex_str) (Hodlinator)
Pull request description:
Motivation:
* Validates and converts the hex string at compile time instead of at runtime into the resulting bytes.
* Makes it possible to derive other compile time constants from `uint256`.
* Potentially eliminates runtime dependencies (`SetHexDeprecated()` is called in less places).
* Has stricter requirements than the deprecated `uint256S()` (requiring 64 chars exactly, disallows garbage at the end) and replaces it in a bunch of places.
* Makes the binary smaller (tested Guix-built x86_64-linux-gnu bitcoind binary).
* Minor: should shave off a few cycles of start-up time.
Extracted from #30377 which diverged into exploring `consteval` `ParseHex()` solutions.
ACKs for top commit:
maflcko:
rebase re-cr-ACK 2d9d752e4fc30aabf2ddd36ca7a63432d26d4fea 🎐
stickies-v:
re-ACK 2d9d752e4fc30aabf2ddd36ca7a63432d26d4fea
paplorinc:
ACK 2d9d752e4fc30aabf2ddd36ca7a63432d26d4fea
Tree-SHA512: 39bd9320db0ed81950b5d71495eaa1d06508cc008466f2308874d70ac9ff32bc69798d2e3ef6a784868c1633fb519f60cc2111a9d0718c2663b28e78b67f7cde
When using `sendrawtransaction` the ALREADY_IN_CHAIN error help string
may be confusing.
Rename TransactionError::ALREADY_IN_CHAIN to
TransactionError::ALREADY_IN_UTXO_SET and update the rpc help string.
Remove backwards compatibility alias as no longer required.
fa3ea3b83c6a4c9726a17f2a48bbdb77f944bf6c test: Fix intermittent issue in p2p_v2_misbehaving.py (MarcoFalke)
55555574d105f6c529c5c966c3c971c9db5ab786 net: Log accepted connection after m_nodes.push_back (MarcoFalke)
Pull request description:
Fix the two issues reported in https://github.com/bitcoin/bitcoin/pull/30468/files#r1688444784:
* Delay a debug log line for consistency.
* Fix an intermittent test issue.
They are completely separate fixes, but both `net` related.
ACKs for top commit:
0xB10C:
Code Review ACK fa3ea3b83c6a4c9726a17f2a48bbdb77f944bf6c
stratospher:
tested ACK fa3ea3b.
Tree-SHA512: cd6b6e164b317058a305a5c3e38c56c9a814a7469039e1143f1d7addfbc91b0a28506873356b373d97448b46cb6fbe94a1309df82e34c855540b241a09489e8b
bfd3c29e4f7942b49986ce0efa08481bae190b7e fuzz: fix timeout in crypter target (brunoerg)
Pull request description:
Fixes#30503
- Move SetKeyFromPassphrase to out of LIMITED_WHILE
- Remove `SetKey` calls since it is already called internally by other functions.
- Reduce number of iterations (100 is enough, no need for 10,000).
ACKs for top commit:
maflcko:
review ACK bfd3c29e4f7942b49986ce0efa08481bae190b7e 📆
dergoegge:
utACK bfd3c29e4f7942b49986ce0efa08481bae190b7e
Tree-SHA512: 275ab7d07a20bfd07279a23613678993c10c166f40cdc900213b9f4d5afb107462d5f88518a0f4ce2a52f3b7950ff2c01cf74292042f16996909fcb96f827d3e
chainparams.cpp - workaround for MSVC bug triggering C7595 - Calling consteval constructors in initializer lists fails, but works on GCC (13.2.0) & Clang (17.0.6).
Complements uint256::FromHex() nicely in that it naturally does all error checking at compile time and so doesn't need to return an std::optional.
Will be used in the following 2 commits to replace many calls to uint256S(). uint256S() calls taking C-string literals are littered throughout the codebase and executed at runtime to perform parsing unless a given optimizer was surprisingly efficient. While this may not be a hot spot, it's better hygiene in C++20 to store the parsed data blob directly in the binary, without any parsing at runtime.
2a3a24296ec21b4a27a73291fabae3a68974cd1a test: check that P2A with witness data is still consensus-legal (Greg Sanders)
68bd86cd7c686e66d3eae12e17349a0e5ff88504 test: P2A is a destination type with an address (Greg Sanders)
Pull request description:
Followups for https://github.com/bitcoin/bitcoin/pull/30352
Suggestions taken:
https://github.com/bitcoin/bitcoin/pull/30352#discussion_r1698542647https://github.com/bitcoin/bitcoin/pull/30352#discussion_r1698563426
ACKs for top commit:
tdb3:
ACK 2a3a24296ec21b4a27a73291fabae3a68974cd1a
glozow:
ACK 2a3a24296ec21b4a27a73291fabae3a68974cd1a
theStack:
ACK 2a3a24296ec21b4a27a73291fabae3a68974cd1a
Tree-SHA512: 5de865b2c300fa504dbdbd5879649a6fc328da052ad8bf9479e3fea0c49c516d824908a87523ec1fb30cc536bffe2e116dd523a9b66a07f81f93429e42879f14
6d33e13bd493ca6cee7b52b990e4822a28e35d0a doc: tor.md: use -bind=127.0.0.1:8334=onion for the Tor bind (David Gumberg)
a7f5d188cc7a23b1946d48693ada22fe90d9ffe0 doc: add release notes for #22729 (Vasil Dimov)
Pull request description:
Add release notes for #22729.
ACKs for top commit:
davidgumberg:
reACK 6d33e13bd4
willcl-ark:
ACK 6d33e13bd493ca6cee7b52b990e4822a28e35d0a
Tree-SHA512: 9d7e66ee1d0bb1d75b8273707d30f20915d5040a768c2c5cd47c84997df2645c8bec35db6c09dc77ab917836622411b924373816cbc83c4be38e2e9156a139d8
bf0efb4fc72d3c49a2c498c944e55466dfa046dc scripted-diff: Modernize naming of nChainTx and nTxCount (Fabian Jahr)
72e5d1be1f4491565249d43e836ee42cfd858866 test: Add basic check for nChainTx type (Fabian Jahr)
dc2938e9799d79696d1db2438ef33d90542d984b chainparams: Change nChainTx to uint64_t (Fabian Jahr)
Pull request description:
This picks up the work from #29331 and closes#29258.
This simply changes the type and addresses the comments from #29331 by changing the type in all relevant places and removing unnecessary casts. This also adds an extremely simple unit test.
Additionally this modernizes the name of `nChainTx` which helps reviewers check all use of the symbol and can make silent merge conflicts.
ACKs for top commit:
maflcko:
only rebase in scripted-diff, re-ACK bf0efb4fc72d3c49a2c498c944e55466dfa046dc 🔈
glozow:
reACK bf0efb4fc72 via range-diff
Tree-SHA512: ee4020926d0800236fe655d0c7b127215ab36b553b04d5f91494f4b7fac6e1cfe7ee298b07c0983db5a3f4786932acaa54f5fd2ccd45f2fcdcfa13427358dc3b
5e87f30f7c9f6b276ccace88a55b7f0abced591b test: check that keyless P2A 'signing' via `signrawtransactionwithkey` succeeds (Sebastian Falbesoner)
Pull request description:
This small PR adds a sanity check to verify that transactions with P2A inputs can be 'signed' successfully, using the non-wallet RPC `signrawtransactionwithkey`. Note that in the this flow, `SignStep` (which was also extended for the new `ANCHOR` output type in #30352) is never called, as signing is only tried if the locking script verification isn't successful already. See the review discussion https://github.com/bitcoin/bitcoin/pull/30352#discussion_r1690530356 ff.
ACKs for top commit:
instagibbs:
ACK 5e87f30f7c9f6b276ccace88a55b7f0abced591b
tdb3:
ACK 5e87f30f7c9f6b276ccace88a55b7f0abced591b
glozow:
code review ACK 5e87f30f7c9f6b276ccace88a55b7f0abced591b
Tree-SHA512: dfea75b4bf8fa0b9c265ddd63dab36374c2430c31220f0c8eb1b53dd847c183f9e1c493a0173e2da317553a1d4cb1b35aa9ffde1268c430cc610368d23b9c942
bbcee5a0d67db46526ba29a1a4a7c590d303de03 clusterlin: improve rechunking in LinearizationChunking (optimization) (Pieter Wuille)
04d7a04ea426dd0a69b61e3b887867b0277d84d1 clusterlin: add MergeLinearizations function + fuzz test + benchmark (Pieter Wuille)
4f8958d7563ae2d0d359ec1e6885f8cb5e40a5e0 clusterlin: add PostLinearize + benchmarks + fuzz tests (Pieter Wuille)
0e2812d2938b933debffba5b873637fa1d348b81 clusterlin: add algorithms for connectedness/connected components (Pieter Wuille)
0e52728a2d6ccafcfecfefbb5a0432a9881d8e0d clusterlin: rename Intersect -> IntersectPrefixes (Pieter Wuille)
Pull request description:
Part of cluster mempool: #30289
Depends on #30126, and was split off from it. #28676 depends on this.
This adds the algorithms for merging & postprocessing linearizations.
The `PostLinearize(depgraph, linearization)` function performs an in-place improvement of `linearization`, using two iterations of the [Linearization post-processing](https://delvingbitcoin.org/t/linearization-post-processing-o-n-2-fancy-chunking/201/8) algorithm. The first running from back to front, the second from front to back.
The `MergeLinearizations(depgraph, linearization1, linearization2)` function computes a new linearization for the provided cluster, given two existing linearizations for that cluster, which is at least as good as both inputs. The algorithm is described at a high level in [merging incomparable linearizations](https://delvingbitcoin.org/t/merging-incomparable-linearizations/209).
For background and references, see [Introduction to cluster linearization](https://delvingbitcoin.org/t/introduction-to-cluster-linearization/1032).
ACKs for top commit:
sdaftuar:
ACK bbcee5a0d67db46526ba29a1a4a7c590d303de03
glozow:
code review ACK bbcee5a0d67
instagibbs:
ACK bbcee5a0d6
Tree-SHA512: d2b5a3f132d1ef22ddf9c56421ab8b397efe45b3c4c705548dda56f5b39fe4b8f57a0d2a4c65b338462d80bb5b9b84a9a39efa1b4f390420a8005ce31817774e
73e3fa10b4dd63b7767d6b6f270df66971067341 doc + test: Correct uint256 hex string endianness (Hodlinator)
Pull request description:
This PR is a follow-up to #30436.
Only changes test-code and modifies/adds comments.
Byte order of hex string representation was wrongfully documented as little-endian, but are in fact closer to "big-endian" (endianness is a memory-order concept rather than a numeric concept). `[arith_]uint256` both store their data in arrays with little-endian byte order (`arith_uint256` has host byte order within each `uint32_t` element).
**uint256_tests.cpp** - Avoid using variable from the left side of the condition in the right side. Credits to @maflcko: https://github.com/bitcoin/bitcoin/pull/30436#discussion_r1688273553
**setup_common.cpp** - Skip needless ArithToUint256-conversion. Credits to @stickies-v: https://github.com/bitcoin/bitcoin/pull/30436#discussion_r1688621638
---
<details>
<summary>
## Logical reasoning for endianness
</summary>
1. Comparing an `arith_uint256` (`base_uint<256>`) to a `uint64_t` compares the beginning of the array, and verifies the remaining elements are zero.
```C++
template <unsigned int BITS>
bool base_uint<BITS>::EqualTo(uint64_t b) const
{
for (int i = WIDTH - 1; i >= 2; i--) {
if (pn[i])
return false;
}
if (pn[1] != (b >> 32))
return false;
if (pn[0] != (b & 0xfffffffful))
return false;
return true;
}
```
...that is consistent with little endian ordering of the array.
2. They have the same endianness (but `arith_*` has host-ordering of each `uint32_t` element):
```C++
arith_uint256 UintToArith256(const uint256 &a)
{
arith_uint256 b;
for(int x=0; x<b.WIDTH; ++x)
b.pn[x] = ReadLE32(a.begin() + x*4);
return b;
}
```
### String conversions
The reversal of order which happens when converting hex-strings <=> uint256 means strings are actually closer to big-endian, see the end of `base_blob<BITS>::SetHexDeprecated`:
```C++
unsigned char* p1 = m_data.data();
unsigned char* pend = p1 + WIDTH;
while (digits > 0 && p1 < pend) {
*p1 = ::HexDigit(trimmed[--digits]);
if (digits > 0) {
*p1 |= ((unsigned char)::HexDigit(trimmed[--digits]) << 4);
p1++;
}
}
```
Same reversal here:
```C++
template <unsigned int BITS>
std::string base_blob<BITS>::GetHex() const
{
uint8_t m_data_rev[WIDTH];
for (int i = 0; i < WIDTH; ++i) {
m_data_rev[i] = m_data[WIDTH - 1 - i];
}
return HexStr(m_data_rev);
}
```
It now makes sense to me that `SetHexDeprecated`, upon receiving a shorter hex string that requires zero-padding, would pad as if the missing hex chars where towards the end of the little-endian byte array, as they are the most significant bytes. "Big-endian" string representation is also consistent with the case where `SetHexDeprecated` receives too many hex digits and discards the leftmost ones, as a form of integer narrowing takes place.
### How I got it wrong in #30436
Previously I used the less than (`<`) comparison to prove endianness, but for `uint256` it uses `memcmp` and thereby gives priority to the *lower* bytes at the beginning of the array.
```C++
constexpr int Compare(const base_blob& other) const { return std::memcmp(m_data.data(), other.m_data.data(), WIDTH); }
```
`arith_uint256` is different in that it begins by comparing the bytes from the end, as it is using little endian representation, where the bytes toward the end are more significant.
```C++
template <unsigned int BITS>
int base_uint<BITS>::CompareTo(const base_uint<BITS>& b) const
{
for (int i = WIDTH - 1; i >= 0; i--) {
if (pn[i] < b.pn[i])
return -1;
if (pn[i] > b.pn[i])
return 1;
}
return 0;
}
```
(The commit documents that `base_blob::Compare()` is doing lexicographic ordering unlike the `arith_*`-variant which is doing numeric ordering).
</details>
ACKs for top commit:
paplorinc:
ACK 73e3fa10b4dd63b7767d6b6f270df66971067341
ryanofsky:
Code review ACK 73e3fa10b4dd63b7767d6b6f270df66971067341
Tree-SHA512: 121630c37ab01aa7f7097f10322ab37da3cbc0696a6bbdbf2bbd6db180dc5938c7ed91003aaa2df7cf4a4106f973f5118ba541b5e077cf3588aa641bbd528f4e
a7432dd6ed3e13a272d62ecde535e6d562cc932c logging: clarify -debug and -debugexclude descriptions (Anthony Towns)
74dd33cb0a967086df32e5140d58843ca1359d81 rpc: make logging method reject "0" category and correct the help text (Vasil Dimov)
8c6f3bf1634533a0dd268dcf5929e49429640a09 logging, refactor: minor encapsulation improvement and use BCLog::NONE instead of 0 (Vasil Dimov)
160706aa387245ed96b1f13e5362fe1837e8fc4b logging, refactor: make category special cases explicit (Ryan Ofsky)
Pull request description:
* Move special cases from `LOG_CATEGORIES_BY_STR` to `GetLogCategory()` (suggested [here](https://github.com/bitcoin/bitcoin/pull/29419#discussion_r1547990373)).
* Remove `"none"` and `"0"` from RPC `logging` help because that help text was wrong. `"none"` resulted in an error and `"0"` was ignored itself (contrary to what the help text suggested).
* Remove unused `LOG_CATEGORIES_BY_STR[""]` (suggested [here](https://github.com/bitcoin/bitcoin/pull/29419#discussion_r1548018694)).
This is a followup to https://github.com/bitcoin/bitcoin/pull/29419, addressing leftover suggestions + more.
ACKs for top commit:
LarryRuane:
ACK a7432dd6ed3e13a272d62ecde535e6d562cc932c
ryanofsky:
Code review ACK a7432dd6ed3e13a272d62ecde535e6d562cc932c. Only changes since last review are removing dead if statement and adding AJ's suggested -debug and -debugexclude help improvements, which look accurate and much more clear.
Tree-SHA512: 41b997b06fccdb4c1d31f57d4752c83caa744cb3280276a337ef4a9b7012a04eb945071db6b8fad24c6a6cf8761f2f800fe6d8f3d8836f5b39c25e4f11c85bf0
Replace early returns in KeyPair::KeyPair() with asserts.
The if statements imply there is an error we are handling, but keypair_xonly_pub
and xonly_pubkey_serialize can only fail if the keypair object is malformed, i.e.,
it was created with a bad secret key. Since we check that the keypair was created
successfully before attempting to extract the public key, using asserts more
accurately documents what we expect here and removes untested branches from the code.
