aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2024-08-06Merge bitcoin/bitcoin#30573: Update libsecp256k1 subtree to latest mastermerge-script
9ec776adff90f1d4cbb3c4decaf281bb391e5e1e Revert "build: pass --with-ecmult-gen-kb=86 to secp256k1" (fanquake) 41797f8ab9932279689b6731f8826f08db68ba16 Squashed 'src/secp256k1/' changes from 4af241b320..642c885b61 (fanquake) Pull request description: Updates the libsecp256k1 subtree to https://github.com/bitcoin-core/secp256k1/commit/642c885b6102725e25623738529895a95addc4f4 (which is the tag for the [`v0.5.1` release](https://github.com/bitcoin-core/secp256k1/releases/tag/v0.5.1)). Includes a handful of changes: * https://github.com/bitcoin-core/secp256k1/pull/1551 * https://github.com/bitcoin-core/secp256k1/pull/1555 * https://github.com/bitcoin-core/secp256k1/pull/1563 * https://github.com/bitcoin-core/secp256k1/pull/1564 * https://github.com/bitcoin-core/secp256k1/pull/1565 * https://github.com/bitcoin-core/secp256k1/pull/1574 Reverts a057869aa3c42457570765966cb66accb2375b13 given secps default has changed (https://github.com/bitcoin-core/secp256k1/pull/1563): > As a rule of thumb, the default values for configuration options should target standard desktop machines and align with Bitcoin Core's defaults, and the tests should mostly exercise the default configuration (see [#1549](https://github.com/bitcoin-core/secp256k1/issues/1549#issuecomment-2200559257)). ACKs for top commit: hebasto: ACK 9ec776adff90f1d4cbb3c4decaf281bb391e5e1e, I've reproduced the subtree update locally with the zero diff with this PR branch. Tree-SHA512: 903ca0ff12dcc32b6cd86aee84e19de09803d35a1ee006ce890f3761dd27f1e96fe70c7bb4c279416a96ee57c406c9627614900f0ca6f76674c0088a3d270cd2
2024-08-06fuzz: replace hardcoded numbers for bech32 limitsjosibake
Use bech32::CharLimit::BECH32 and bech32::CHECKSUM_SIZE instead of hardcoded values. This is a follow-up fix for #34007 (where this file was missed)
2024-08-05validation: don't erase coins cache on prune flushesAndrew Toth
2024-08-05Add linked-list test to CCoinsViewCache::SanityCheckPieter Wuille
2024-08-05coins: move Sync logic to CoinsViewCacheCursorAndrew Toth
Erase spent cache entries and clear flags of unspent entries inside the BatchWrite loop, instead of an additional loop after BatchWrite. Co-Authored-By: Pieter Wuille <pieter@wuille.net>
2024-08-05coins: pass linked list of flagged entries to BatchWriteAndrew Toth
BatchWrite now iterates through the linked list of flagged entries instead of the entire coinsCache map. Co-Authored-By: l0rinc <pap.lorinc@gmail.com>
2024-08-05test: add cache entry linked list testsAndrew Toth
Co-Authored-By: l0rinc <pap.lorinc@gmail.com>
2024-08-05coins: track flagged cache entries in linked listAndrew Toth
No visible behavior change. This commit tracks the flagged entries internally but the list is not iterated by anything. Co-Authored-By: Pieter Wuille <pieter@wuille.net> Co-Authored-By: l0rinc <pap.lorinc@gmail.com>
2024-08-06testnet: Add timewarp attack prevention for Testnet4Fabian Jahr
2024-08-06testnet: Add Testnet4 difficulty adjustment rules fixFabian Jahr
2024-08-06testnet: Introduce Testnet4Fabian Jahr
2024-08-06refactor: use c++20 std::views::reverse instead of reverse_iterator.hstickies-v
Use std::ranges::views::reverse instead of the implementation in reverse_iterator.h, and remove it as it is no longer used.
2024-08-05Merge bitcoin/bitcoin#28052: blockstorage: XOR blocksdir *.dat filesAva Chow
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
2024-08-05Merge bitcoin/bitcoin#30064: net: log connections failures via SOCKS5 with ↵Ava Chow
less severity 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
2024-08-05Merge bitcoin/bitcoin#30082: test: expand LimitOrphan and EraseForPeer coverageAva Chow
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](https://github.com/bitcoin/bitcoin/pull/30082/commits/172c1ad026cc38c6f52679e74c14579ecc77c48e) glozow: reACK 172c1ad026cc38c6f52679e74c14579ecc77c48e Tree-SHA512: e8fa9b1de6a8617612bbe9b132c9c0c9b5a651ec94fd8c91042a34a8c91c5f9fa7ec4175b47e2b97d1320d452c23775be671a9970613533e68e81937539a7d70
2024-08-05Merge bitcoin/bitcoin#30493: policy: enable full-rbf by defaultAva Chow
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 https://github.com/bitcoin/bitcoin/pull/30493/commits/590456e3f1043ba0680e0afec9fd7653db1098bb glozow: reACK 590456e3f1043ba0680e0afec9fd7653db1098bb achow101: ACK 590456e3f1043ba0680e0afec9fd7653db1098bb ariard: tested ACK 590456e3 murchandamus: reACK 590456e3f1043ba0680e0afec9fd7653db1098bb Tree-SHA512: 83fceef9961021687e6ff979041f89be0c616f7a49cc28a5d7edf7d8ad064fcb9c0e2af0c31f4f89867a9f6dff4e40ef8ad4dbd624e7d6a4e00ac1f1c1f66c7a
2024-08-05Merge bitcoin/bitcoin#30497: rpc: Return errors in loadtxoutset that ↵Ryan Ofsky
currently go to logs 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
2024-08-05Merge bitcoin/bitcoin#30560: refactor: Add consteval uint256 constructorRyan Ofsky
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
2024-08-05rpc: clarify ALREADY_IN_CHAIN rpc errorswillcl-ark
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.
2024-08-05Merge bitcoin/bitcoin#30512: net: Log accepted connection after ↵merge-script
m_nodes.push_back; Fix intermittent test issue 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
2024-08-05Merge bitcoin/bitcoin#30575: fuzz: fix timeout in crypter targetmerge-script
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
2024-08-05scripted-diff: Replace uint256S("str") -> uint256{"str"}Hodlinator
-BEGIN VERIFY SCRIPT- sed -i --regexp-extended -e 's/\buint256S\("(0x)?([^"]{64})"\)/uint256{"\2"}/g' $(git grep -l uint256S) -END VERIFY SCRIPT-
2024-08-05refactor: Hand-replace some uint256S -> uint256Hodlinator
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).
2024-08-05refactor: Add consteval uint256(hex_str)Hodlinator
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.
2024-08-05miniscript: Use `ToIntegral` instead of `ParseInt64`brunoerg
2024-08-05Merge bitcoin/bitcoin#29656: chainparams: Change nChainTx type to uint64_tglozow
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
2024-08-05Merge bitcoin/bitcoin#30285: cluster mempool: merging & postprocessing of ↵glozow
linearizations 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 https://github.com/bitcoin/bitcoin/pull/30285/commits/bbcee5a0d67db46526ba29a1a4a7c590d303de03 Tree-SHA512: d2b5a3f132d1ef22ddf9c56421ab8b397efe45b3c4c705548dda56f5b39fe4b8f57a0d2a4c65b338462d80bb5b9b84a9a39efa1b4f390420a8005ce31817774e
2024-08-04Merge bitcoin/bitcoin#30526: doc: Correct uint256 hex string endiannessRyan Ofsky
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
2024-08-04Merge bitcoin/bitcoin#29798: Logging cleanupRyan Ofsky
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
2024-08-04Merge bitcoin-core/gui#826: OptionsDialog: Allow Maximize of windowHennadii Stepanov
3dbd94b6610a58460b52a6cc02892d881c091ccd GUI/OptionsDialog: Allow Maximize of window (Luke Dashjr) Pull request description: ACKs for top commit: hebasto: ACK 3dbd94b6610a58460b52a6cc02892d881c091ccd. Tree-SHA512: 24a94840d97510ce5760c3099a765fb2f5d107d99a8f72757f509eefdaf35cb2d4d7f3243866bf6dc635fe83bb73b422e3cae2bd161d9b4b6f2e3d77bfd27353
2024-08-04scripted-diff: Modernize naming of nChainTx and nTxCountFabian Jahr
-BEGIN VERIFY SCRIPT- sed -i 's/nChainTx/m_chain_tx_count/g' $(git grep -l 'nChainTx' ./src) sed -i 's/nTxCount/tx_count/g' $(git grep -l 'nTxCount' ./src) -END VERIFY SCRIPT-
2024-08-04test: Add basic check for nChainTx typeFabian Jahr
2024-08-04chainparams: Change nChainTx to uint64_tFabian Jahr
Also update types of assumeutxo chainparams and some related local variables for consistency. Co-authored-by: russeree <reese.russell@ymail.com>
2024-08-04refactor: remove un-tested early returnsjosibake
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.
2024-08-04tests: add tests for KeyPairjosibake
Reuse existing BIP340 tests, as there should be no behavior change between the two
2024-08-04refactor: move SignSchnorr to KeyPairjosibake
Move `SignSchnorr` to `KeyPair`. This makes `CKey::SignSchnorr` now compute a `KeyPair` object and then call `KeyPair::SignSchorr`. The notable changes are: * Move the merkle_root tweaking out of the sign function and into the KeyPair constructor * Remove the temporary secp256k1_keypair object and have the functions access m_keypair->data() directly
2024-08-04logging: clarify -debug and -debugexclude descriptionsAnthony Towns
2024-08-04rpc: make logging method reject "0" category and correct the help textVasil Dimov
Current logging RPC method documentation claims to accept "0" and "none" categories, but the "none" argument is actually rejected and the "0" argument is ignored. Update the implementation to refuse both categories, and remove the help text claiming to support them.
2024-08-04logging, refactor: minor encapsulation improvement and use BCLog::NONE ↵Vasil Dimov
instead of 0 * Make the standalone function `LogCategoryToStr()` private inside `logging.cpp` (aka `static`) - it is only used in that file. * Make the method `Logger::GetLogPrefix()` `private` - it is only used within the class. * Use `BCLog::NONE` to initialize `m_categories` instead of `0`. We later check whether it is `BCLog::NONE` (in `Logger::DefaultShrinkDebugFile()`).
2024-08-04logging, refactor: make category special cases explicitRyan Ofsky
Make special cases explicit in GetLogCategory() and LogCategoryToStr() functions. Simplify the LOG_CATEGORIES_BY_STR and LOG_CATEGORIES_BY_FLAG mappings and LogCategoriesList() function. This makes the maps `LOG_CATEGORIES_BY_STR` and `LOG_CATEGORIES_BY_FLAG` consistent (one is exactly the opposite of the other).
2024-08-03doc + test: Correct uint256 hex string endiannessHodlinator
Follow-up to #30436. uint256 string representation was wrongfully documented as little-endian due to them being reversed by GetHex() etc, and base_blob::Compare() giving most significance to the beginning of the internal array. They are closer to "big-endian", but this commit tries to be even more precise than that. uint256_tests.cpp - Avoid using variable from the left side of the condition in the right side. setup_common.cpp - Skip needless ArithToUint256-conversion.
2024-08-03crypto: add KeyPair wrapper classjosibake
Add a `KeyPair` class which wraps the `secp256k1_keypair`. This keeps the secret data in secure memory and enables passing the `KeyPair` object directly to libsecp256k1 functions expecting a `secp256k1_keypair`. Motivation: when passing `CKeys` for taproot outputs to libsecp256k1 functions, the first step is to create a `secp256k1_keypair` data type and use that instead. This is so the libsecp256k1 function can determine if the key needs to be negated, e.g., when signing. This is a bit clunky in that it creates an extra step when using a `CKey` for a taproot output and also involves copying the secret data into a temporary object, which the caller must then take care to cleanse. In addition, the logic for applying the merkle_root tweak currently only exists in the `SignSchnorr` function. In a later commit, we will add the merkle_root tweaking logic to this function, which will make the merkle_root logic reusable outside of signing by using the `KeyPair` class directly. Co-authored-by: Cory Fields <cory-nospam-@coryfields.com>
2024-08-03tests: add key tweak smoke testjosibake
Sanity check that using CKey/CPubKey directly vs using secp256k1_keypair objects returns the same results for BIP341 key tweaking. Co-authored-by: l0rinc <pap.lorinc@gmail.com>
2024-08-03bench: add benchmark for signing with a taptweakjosibake
Add benchmarks for signing with null and non-null merkle_root arguments. Null and non-null merkle_root arguments will apply the taptweaks H_TapTweak(P) and H_TapTweak(P | merkle_root), respectively, to the private key during signing. This benchmark is added to verify there are no significant performance changes after moving the taptweak signing logic in a later commit. Co-authored-by: l0rinc <pap.lorinc@gmail.com>
2024-08-02policy: enable full-rbf by defaultPeter Todd
Enable full rbf (mempool policy) by default and update tests accordingly.
2024-08-02gui, qt: brintToFront workaround for Waylandpablomartin4btc
2024-08-02Merge bitcoin/bitcoin#30352: policy: Add PayToAnchor(P2A), `OP_1 <0x4e73>` ↵glozow
as a standard output script for spending 75648cea5a9032b3d388cbebacb94d908e08924e test: add P2A ProduceSignature coverage (Greg Sanders) 7998ce6b20fba62c022228355907b612ba6692e1 Add release note for P2A output feature (Greg Sanders) 71c9b02a04742eeecab14aae4697b1a3eb51ff7f test: add P2A coverage for decodescript (Greg Sanders) 1349e9ec1558484f2912a2444c410170fcec8745 test: Add anchor mempool acceptance test (Greg Sanders) 9d892099378b2ad5f52220403bdeae43c61d6955 policy: stop 3rd party wtxid malleability of anchor spend (Greg Sanders) b60aaf8b239978947d2b0e3f56e7d8a4092d7570 policy: make anchor spend standard (Greg Sanders) 455fca86cfada1823aa28615b5683f9dc73dbb9a policy: Add OP_1 <0x4e73> as a standard output type (Greg Sanders) Pull request description: This is a sub-feature taken out of the original proposal for ephemeral anchors #30239 This PR makes *spending* of `OP_1 <0x4e73>` (i.e. `bc1pfeessrawgf`) standard. Creation of this output type is already standard. Any future witness output types are considered relay-standard to create, but not to spend. This preserves upgrade hooks, such as a completely new output type for a softfork such as BIP341. It also gives us a bit of room to use a new output type for policy uses. This particular sized witness program has no other known use-cases (https://bitcoin.stackexchange.com/a/110664/17078), s it affords insufficient cryptographic security for a secure commitment to data, such as a script or a public key. This makes this type of output "keyless", or unauthenticated. As a witness program, the `scriptSig` of the input MUST be blank, by BIP141. This helps ensure txid-stability of the spending transaction, which may be required for smart contracting wallets. If we do not use segwit, a miner can simply insert an `OP_NOP` in the `scriptSig` without effecting the result of program execution. An additional relay restriction is to disallow non-empty witness data, which an adversary may use to penalize the "honest" transactor when RBF'ing the transaction due to the incremental fee requirement of RBF rules. The intended use-case for this output type is to "anchor" the transaction with a spending child to bring exogenous CPFP fees into the transaction package, encouraging the inclusion of the package in a block. The minimal size of creation and spending of this output makes it an attractive contrast to outputs like `p2sh(OP_TRUE)` and `p2wsh(OP_TRUE)` which are significantly larger in vbyte terms. Combined with TRUC transactions which limits the size of child transactions significantly, this is an attractive option for presigned transactions that need to be fee-bumped after the fact. ACKs for top commit: sdaftuar: utACK 75648cea5a9032b3d388cbebacb94d908e08924e theStack: re-ACK 75648cea5a9032b3d388cbebacb94d908e08924e ismaelsadeeq: re-ACK 75648cea5a9032b3d388cbebacb94d908e08924e via [diff](https://github.com/bitcoin/bitcoin/compare/e7ce6dc070c0319cbb868d41cadd836b2e6ca9db..75648cea5a9032b3d388cbebacb94d908e08924e) glozow: ACK 75648cea5a9032b3d388cbebacb94d908e08924e tdb3: ACK 75648cea5a9032b3d388cbebacb94d908e08924e Tree-SHA512: d529de23d20857e6cdb40fa611d0446b49989eaafed06c28280e8fd1897f1ed8d89a4eabbec1bbf8df3d319910066c3dbbba5a70a87ff0b2967d5205db32ad1e
2024-08-02[rpc, fees]: add more detail on the fee estimation modesismaelsadeeq
- Add description that indicates the fee estimation modes behaviour. - This description will be returned in the RPC's help texts.
2024-08-02Merge bitcoin-core/gui#626: Showing Local Addresses in Node WindowHennadii Stepanov
189c987386a0da132d7ef076cdf539f9eb75fc3c Showing local addresses on the Node Window (Jadi) a5d7aff867a3df9ac77664deed03e930e2636db0 net: Providing an interface for mapLocalHost (Jadi) Pull request description: This change adds a new row to the Node Window (debugwindow.ui) under the Network section which shows the LocalAddresses. fixes #564 <!-- *** 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: pablomartin4btc: re-ACK 189c987386a0da132d7ef076cdf539f9eb75fc3c furszy: utACK 189c987 Tree-SHA512: 93f201bc6d21d81b27b87be050a447b841f01e3efb69b9eca2cc7af103023d7cd69eb5e16e2875855573ef51a5bf74a6ee6028636c1b6798cb4bb11567cb4996
2024-08-02fuzz: fix timeout in crypter targetbrunoerg
Move `SetKeyFromPassphrase` to out of LIMITED_WHILE, remove `SetKey` calls since it is already called internally by other functions and reduce the number of iterations.
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 02:44:17 +0000