1950 Commits

Author SHA1 Message Date
Ava Chow
a4e96cae7d
Merge bitcoin/bitcoin#33042: refactor: inline constant return values from dbwrapper write methods
743abbcbde9e5a2db489bca461c98df461eff7d0 refactor: inline constant return value of `BlockTreeDB::WriteBatchSync` and `BlockManager::WriteBlockIndexDB` and `BlockTreeDB::WriteFlag` (Lőrinc)
e030240e909493549e24aa8bcd5b382cab6e2c79 refactor: inline constant return value of `CDBWrapper::Erase` and `BlockTreeDB::WriteReindexing` (Lőrinc)
cdab9480e9e35656f490878f92dab5427b36f21d refactor: inline constant return value of `CDBWrapper::Write` (Lőrinc)
d1847cf5b5af232ad180f5d302361b72334952b2 refactor: inline constant return value of `TxIndex::DB::WriteTxs` (Lőrinc)
50b63a5698e533376ef7a20bc0c440d3d6bf7a9f refactor: inline constant return value of `CDBWrapper::WriteBatch` (Lőrinc)

Pull request description:

  Related to https://github.com/bitcoin/bitcoin/pull/31144#discussion_r2223587480

  ### Summary
  `WriteBatch` always returns `true` - the errors are handled by throwing `dbwrapper_error` instead.

  ### Context
  This boolean return value of the `Write` methods is confusing because it's inconsistent with `CDBWrapper::Read`, which catches exceptions and returns a boolean to indicate success/failure. It's bad that `Read` returns and `Write` throws - but it's a lot worse that `Write` advertises a return value when it actually communicates errors through exceptions.

  ### Solution
  This PR removes the constant return values from write methods and inlines `true` at their call sites. Many upstream methods had boolean return values only because they were propagating these constants - those have been cleaned up as well.

  Methods that returned a constant `true` value that now return `void`:
  - `CDBWrapper::WriteBatch`, `CDBWrapper::Write`, `CDBWrapper::Erase`
  - `TxIndex::DB::WriteTxs`
  - `BlockTreeDB::WriteReindexing`, `BlockTreeDB::WriteBatchSync`, `BlockTreeDB::WriteFlag`
  - `BlockManager::WriteBlockIndexDB`

  ### Note
  `CCoinsView::BatchWrite` (and transitively `CCoinsViewCache::Flush` & `CCoinsViewCache::Sync`) were intentionally not changed here. While all implementations return `true`, the base `CCoinsView::BatchWrite` returns `false`. Changing this would cause `coins_view` tests to fail with:
  > terminating due to uncaught exception of type std::logic_error: Not all unspent flagged entries were cleared

  We can fix that in a follow-up PR.

ACKs for top commit:
  achow101:
    ACK 743abbcbde9e5a2db489bca461c98df461eff7d0
  janb84:
    ACK 743abbcbde9e5a2db489bca461c98df461eff7d0
  TheCharlatan:
    ACK 743abbcbde9e5a2db489bca461c98df461eff7d0
  sipa:
    ACK 743abbcbde9e5a2db489bca461c98df461eff7d0

Tree-SHA512: b2a550bff066216f1958d2dd9a7ef6a9949de518cc636f8ab9c670e0b7a330c1eb8c838e458a8629acb8ac980cea6616955cd84436a7b8ab9096f6d648073b1e
2025-11-10 09:15:24 -08:00
merge-script
93e79181da
Merge bitcoin/bitcoin#33786: script: remove dead code in CountWitnessSigOps
24bcad3d4df59690f30c9df8ebb62f0bddd0f1c7 refactor: remove dead code in `CountWitnessSigOps` (Lőrinc)

Pull request description:

  Found while reviewing #32840

  The `nullptr` witness path was dead in normal code paths: replacing it with reference enables us deleting unreachable logic.

  Code coverage proof:
  https://maflcko.github.io/b-c-cov/total.coverage/src/script/interpreter.cpp.gcov.html#L2135

ACKs for top commit:
  kevkevinpal:
    ACK [24bcad3](24bcad3d4d)
  maflcko:
    review ACK 24bcad3d4df59690f30c9df8ebb62f0bddd0f1c7 🐏
  darosior:
    Neat. utACK 24bcad3d4df59690f30c9df8ebb62f0bddd0f1c7.
  stickies-v:
    ACK 24bcad3d4df59690f30c9df8ebb62f0bddd0f1c7

Tree-SHA512: 92c87e431f06a15d8eeb02e20e9154b272c4586ddacf77c8d83783091485fb82c24ecbd711db7043a92cf6169746db24ad46a5904d694aea9d3c3aa96da725f0
2025-11-07 12:46:46 +00:00
Lőrinc
24bcad3d4d refactor: remove dead code in CountWitnessSigOps
Found while reviewing #32840

The `nullptr` witness path was dead in normal code paths: removing it deletes unreachable logic.

Code coverage proof:
https://maflcko.github.io/b-c-cov/total.coverage/src/script/interpreter.cpp.gcov.html#L2135
2025-11-04 22:51:25 +01:00
MarcoFalke
fa4b52bd16
fuzz: refactor memcpy to std::ranges::copy to work around ubsan warn
Using std::ranges::copy from the C++ standard library has a few benefits
here:

* It has the additional benefit of being a bit more type safe and
  document the byte cast explicitly.
* The compiler will likely optimize it to the same asm, but performance
  doesn't really matter here anyway.
* It works around an UB-Sanitizer bug, when the source range is empty.

Fixes https://github.com/bitcoin/bitcoin/issues/33643
2025-10-30 11:08:27 +01:00
merge-script
72511fd02e
Merge bitcoin/bitcoin#33555: build: Bump clang minimum supported version to 17
fa0fa0f70087d08fe5a54832b96799bd14293279 refactor: Revert "disable self-assign warning for tests" (MarcoFalke)
faed118fb30fbc303e9d4c70569abfee397f1759 build: Bump clang minimum supported version to 17 (MarcoFalke)

Pull request description:

  Most supported operating systems ship with clang-17 (or later), so bump the minimum to that and allow new code to drop workarounds for previous clang bugs.

  (Apart from dropping the small workaround, this bump allows the `ci_native_nowallet_libbitcoinkernel` CI to run on riscv64 without running into an ICE with clang-16.)

  This patch will only be released in version 31.x, next year (2026).

  For reference:

  * https://packages.debian.org/bookworm/clang-19
  * https://packages.ubuntu.com/noble/clang (clang-18)
  * CentOS-like 8/9/10 ship clang-17 (and later) via Stream
  * FreeBSD 12/13 ship clang-17 (and later) via packages
  * OpenSuse Tumbleweed ships with https://software.opensuse.org/package/clang (clang21); No idea about OpenSuse Leap

  On operating systems where the clang version is not shipped by default, the user would have to use GCC, or install clang in a different way. For example:

  * https://packages.debian.org/bookworm/g++ (g++-12)
  * https://packages.ubuntu.com/jammy/g++ (g++-11)
  * https://apt.llvm.org/, or nix, or guix, or compile clang from source, ...

  *Ubuntu 22.04 LTS does not ship with clang-16 (the previous minimum required), nor with clang-17, so one of the above workarounds is needed there.*

  macOS 14 is unaffected, and the previous minimum requirement of Xcode15.0 remains, see also 919e6d01e9/depends/hosts/darwin.mk (L3-L4). (Modulo compiling the fuzz tests, which requires 919e6d01e9/.github/workflows/ci.yml (L149))

ACKs for top commit:
  janb84:
    Concept ACK fa0fa0f70087d08fe5a54832b96799bd14293279
  l0rinc:
    Code review ACK fa0fa0f70087d08fe5a54832b96799bd14293279
  hebasto:
    ACK fa0fa0f70087d08fe5a54832b96799bd14293279.

Tree-SHA512: 5973cec39982f80b8b43e493cde012d9d1ab75a0362300b007d155db9f871c6341e7e209e5e63f0c3ca490136b684683de270136d62cb56f6b00b0ac0331dc36
2025-10-29 16:53:42 +00:00
Hennadii Stepanov
3bb30658e6
Merge bitcoin/bitcoin#32380: Modernize use of UTF-8 in Windows code
53e4951a5b5b9d166d278db4240513d09b447f58 Switch to ANSI Windows API in `fsbridge::fopen()` function (Hennadii Stepanov)
dbe770d9210666a366f055d52b9f34fa8a3d7305 Switch to ANSI Windows API in `Win32ErrorString()` function (Hennadii Stepanov)
06d0be4e22cef08fd7517f42ee82a44475c6363b Remove no longer necessary `WinCmdLineArgs` class (Hennadii Stepanov)
f366408492f6205ee20fe23e5104813de45dd4b1 cmake: Set process code page to UTF-8 on Windows (Hennadii Stepanov)
dccbb178065f05810a0fad57a86bca2f10995ecf Set minimum supported Windows version to 1903 (May 2019 Update) (Hennadii Stepanov)

Pull request description:

  The main goal is to remove [deprecated](https://github.com/bitcoin/bitcoin/issues/32361) code (removed in C++26).

  This PR employs Microsoft's modern [approach](https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page) to handling UTF-8:
  > Until recently, Windows has emphasized "Unicode" -W variants over -A APIs. However, recent releases have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured for UTF-8, then -A APIs typically operate in UTF-8. This model has the benefit of supporting existing code built with -A APIs without any code changes.

  TODO:
  - [x] Handle application manifests properly when building with MSVC.
  - [x] Bump the minimum supported Windows version to 1903 (May 2019 Update).
  - [x] Remove all remaining use cases of the deprecated `std:wstring_convert`.
      - The instance in `subprocess.h` will be addressed in a follow-up PR, as additional tests are likely needed.
      - The usage in `common/system.cpp` is handled in https://github.com/bitcoin/bitcoin/pull/32566.

  Resolves partially https://github.com/bitcoin/bitcoin/issues/32361.

ACKs for top commit:
  laanwj:
    re-ACK 53e4951a5b5b9d166d278db4240513d09b447f58
  hodlinator:
    re-ACK 53e4951a5b5b9d166d278db4240513d09b447f58
  davidgumberg:
    untested crACK 53e4951a5b

Tree-SHA512: 0dbe9badca8b979ac2b4814fea6e4a7e53c423a1c96cb76ce894253137d3640a87631a5b22b9645e8f0c2a36a107122eb19ed8e92978c17384ffa8b9ab9993b5
2025-10-28 22:41:07 +00:00
ismaelsadeeq
ab49480d9b fees: rename fees_args to block_policy_estimator_args
- Also move them to policy/fees/ and update includes
- Note: the block_policy_estimator_args.h include in block_policy_estimator_args.cpp was done manually.
2025-10-27 10:44:18 +01:00
ismaelsadeeq
06db08a435
fees: refactor: rename fees to block_policy_estimator
- Also move it to policy/fees and update the includes
2025-10-27 10:41:02 +01:00
Ava Chow
00ad998d95
Merge bitcoin/bitcoin#33252: p2p: add DifferenceFormatter fuzz target and invariant check
65a10fc3c52ea09a4794345bcf607dff908c783a p2p: add assertion for BlockTransactionsRequest indexes (frankomosh)
58be359f6b240528e4df23296dec65202f28a773 fuzz: add a target for DifferenceFormatter Class (frankomosh)

Pull request description:

  Adds a fuzz test for the [`DifferenceFormatter`](e3f416dbf7/src/blockencodings.h (L22-L42)) (used in [`BlockTransactionsRequest`](https://github.com/bitcoin/bitcoin/blob/master/src/blockencodings.h#L44-L54), [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)). The DifferenceFormatter class implements differential encoding for compact block transactions (BIP 152). This PR ensures that its strictly-monotonic property is maintained. It complements the tests in [`blocktransactionsrequest_deserialize`](9703b7e6d5/src/test/fuzz/deserialize.cpp (L314)).

  Additionally, there's an added invariant check after GETBLOCKTXN deserialization in `net_processing.cpp`.

ACKs for top commit:
  Crypt-iQ:
    tACK 65a10fc3c52ea09a4794345bcf607dff908c783a
  achow101:
    ACK 65a10fc3c52ea09a4794345bcf607dff908c783a
  dergoegge:
    Code review ACK 65a10fc3c52ea09a4794345bcf607dff908c783a

Tree-SHA512: 70659cf045e99bb5f753763c7ddac094cb2883c202c899276cbe616889afa053b2d5e831f99d6386d4d1e4118cd35fa0b14b54667853fe067f6efe2eb77b4097
2025-10-24 10:12:11 -07:00
merge-script
af78d36512
Merge bitcoin/bitcoin#32588: util: Abort on failing CHECK_NONFATAL in debug builds
fa37153288ca420420636046ef6b8c4ba7e5a478 util: Abort on failing CHECK_NONFATAL in debug builds (MarcoFalke)
fa0dc4bdffb06b6f0c192fe1aa02b4dfdcdc6e15 test: Allow testing of check failures (MarcoFalke)
faeb58fe668662d8262c4cc7c54ad2af756dbe3b refactor: Set G_ABORT_ON_FAILED_ASSUME when G_FUZZING_BUILD (MarcoFalke)

Pull request description:

  A failing `CHECK_NONFATAL` will throw an exception. This is fine and even desired in production builds, because the program may catch the exception and give the user a way to easily report the bug upstream.

  However, in debug development builds, exceptions for internal bugs are problematic:

  * The exception could accidentally be caught and silently ignored
  * The exception does not include a full stacktrace, possibly making debugging harder

  Fix all issues by turning the exception into an abort in debug builds.

  This can be tested by reverting the hunks to `src/rpc/node.cpp` and `test/functional/rpc_misc.py` and then running the functional or fuzz tests.

ACKs for top commit:
  achow101:
    ACK fa37153288ca420420636046ef6b8c4ba7e5a478
  ryanofsky:
    Code review ACK fa37153288ca420420636046ef6b8c4ba7e5a478, just catching subprocess.CalledProcessError in test fixing up a comment since last review
  stickies-v:
    ACK fa37153288ca420420636046ef6b8c4ba7e5a478

Tree-SHA512: 2d892b838ccef6f9b25a066e7c2f6cd6f5acc94aad1d91fce62308983bd3f5c5d724897a76de4e3cc5c3678ddadc87e2ee8c87362965373526038e598dfb0101
2025-10-24 04:41:24 +02:00
merge-script
161864a038
Merge bitcoin/bitcoin#32579: p2p: Correct unrealistic headerssync unit test behavior
cc5dda1de333cf7aa10e2237ee2c9221f705dbd9 headerssync: Make HeadersSyncState more flexible and move constants (Hodlinator)
8fd1c2893e6768223069d8b2fdec033b026cb2eb test(headerssync): Test returning of pow_validated_headers behavior (Hodlinator)
7b00643ef5f932116ee303af9984312b27c040f1 test(headerssync): headers_sync_chainwork test improvements (Hodlinator)
04eeb9578c60ce5661f285f6bde996569fafdcc3 doc(test): Improve comments (Hodlinator)
fe896f8faa7883f33169fe3e6dddb91feaca23e1 refactor(test): Store HeadersSyncState on the stack (Hodlinator)
f03686892a9c07e87e6dd12027d988fe188b1f9e refactor(test): Break up headers_sync_state (Hodlinator)
e984618d0b9946dc11f1087adf22a4cfbf9c1a77 refactor(headerssync): Process spans of headers (Hodlinator)
a4ac9915a95eb865779cf4627dd518d94c01032b refactor(headerssync): Extract test constants ahead of breakup into functions (Hodlinator)

Pull request description:

  ### Background

  As part of the release process we often run *contrib/devtools/headerssync-params.py* and increase the values of the constants `HEADER_COMMITMENT_PERIOD` and `REDOWNLOAD_BUFFER_SIZE` in *src/headerssync.cpp* as per *doc/release-process.md* (example: 11a2d3a63e90cdc1920ede3c67d52a9c72860e6b). This helps fine tune the memory consumption per `HeadersSyncState`-instance in the face of malicious peers.

  (The `REDOWNLOAD_BUFFER_SIZE`/`HEADER_COMMITMENT_PERIOD` ratio determines how many Headers Sync commitment bits must match between PRESYNC & REDOWNLOAD phases before we start permanently storing headers from a peer. For more details see comments in *src/headerssync.h* and *contrib/devtools/headerssync-params.py*).

  ### Problem: Not feeding back headers until completing sync

  During v30 release process #33274 made `REDOWNLOAD_BUFFER_SIZE` exceed the `target_blocks` constant used to control the length of chains generated for testing Headers Sync (`15000`, *headers_sync_chainwork_tests.cpp*).

  The `HeadersSyncState::m_redownloaded_headers`-buffer now does not reach the `REDOWNLOAD_BUFFER_SIZE`-threshold during those unit tests. As a consequence `HeadersSyncState::PopHeadersReadyForAcceptance()` will not start feeding back headers until the PoW threshold has been met. While this will not cause the unit test to start failing on master, it means we have gone from testing behavior that resembles mainnet (way more than `REDOWNLOAD_BUFFER_SIZE` headers to reach the PoW limit), to behavior that is not possible/expected there.

  ### Solution

  Avoid testing this unrealistic condition of completing Headers Sync before reaching `REDOWNLOAD_BUFFER_SIZE` by making tests able to define their own values through the new `HeadersSyncParams` instead of having them hard-coded for all chains & tests.

  ### Commits

  * First 6 commits refactor and improve the unit tests in order to clarify latter changes.
  * We then add checks for the behavior around the `REDOWNLOAD_BUFFER_SIZE` threshold.
  * The main change: we extract the section from *headerssync.cpp* containing the constants to *kernel/chainparams.cpp*, making `HeadersSyncState` no longer hard-coded to mainnet.

  ### Notes

  This PR used to be called "headerssync: Preempt unrealistic unit test behavior".

ACKs for top commit:
  l0rinc:
    reACK cc5dda1de333cf7aa10e2237ee2c9221f705dbd9
  marcofleon:
    code review ACK cc5dda1de333cf7aa10e2237ee2c9221f705dbd9
  danielabrozzoni:
    reACK cc5dda1de333cf7aa10e2237ee2c9221f705dbd9

Tree-SHA512: ccc824dcbbb8ad5ae98c3bf5808b38467aac0230739898a758c9b939eecd74f982df088fa0ba81cc1c1732f19a607b135a6e9577bb9fcf7f8570567ce92f66e6
2025-10-23 06:19:50 -04:00
merge-script
f76e1ae389
Merge bitcoin/bitcoin#32313: coins: fix cachedCoinsUsage accounting in CCoinsViewCache
24d861da7894add47747eff69dd3fc71fbcdd7d0 coins: only adjust `cachedCoinsUsage` on `EmplaceCoinInternalDANGER` insert (Lőrinc)
d7c9d6c2914aadd711544908d0fad8857a809c72 coins: fix `cachedCoinsUsage` accounting to prevent underflow (Lőrinc)
39cf8bb3d0d9ee84544d161bf66d90d5e2a1a140 refactor: remove redundant usage tracking from `CoinsViewCacheCursor` (Lőrinc)
67cff8bec9094e968f36d351fb2e38c9bf563757 refactor: assert newly-created parent cache entry has zero memory usage (Lőrinc)

Pull request description:

  ### Summary

  This PR fixes `cachedCoinsUsage` accounting bugs in `CCoinsViewCache` that caused UBSan `unsigned-integer-overflow` violations during testing. The issues stemmed from incorrect decrement timing in `AddCoin()`, unconditional reset in `Flush()` on failure, and incorrect increment in `EmplaceCoinInternalDANGER()` when insertion fails.

  ### Problems Fixed

  **1. `AddCoin()` underflow on exception**
  - Previously decremented `cachedCoinsUsage` *before* the `possible_overwrite` validation
  - If validation threw, the map entry remained unchanged but counter was decremented
  - This corrupted accounting and later caused underflow
  - **Impact**: Test-only in current codebase, but unsound accounting that could affect future changes

  **2. `Flush()` accounting drift on failure**
  - Unconditionally reset `cachedCoinsUsage` to 0, even when `BatchWrite()` failed
  - Left the map populated while the counter read zero
  - **Impact**: Test-only (production `BatchWrite()` returns `true`), but broke accounting consistency

  **3. Cursor redundant usage tracking**
  - `CoinsViewCacheCursor::NextAndMaybeErase()` subtracted usage when erasing spent entries
  - However, `SpendCoin()` already decremented and cleared the `scriptPubKey`, leaving `DynamicMemoryUsage()` at 0
  - **Impact**: Redundant code that obscured actual accounting behavior

  **4. `EmplaceCoinInternalDANGER()` double-counting**
  - Incremented `cachedCoinsUsage` even when `try_emplace` did not insert (duplicate key)
  - Inflated the counter on duplicate attempts
  - **Impact**: Mostly test-reachable (AssumeUTXO doesn't overwrite in production), but incorrect accounting

  ### Testing

  To reproduce the historical UBSan failures on the referenced baseline and to verify the fix, run:
  ```
  MAKEJOBS="-j$(nproc)" FILE_ENV="./ci/test/00_setup_env_native_fuzz.sh" ./ci/test_run_all.sh
  ```

  The change was tested with the related unit and fuzz test, and asserted before/after each `cachedCoinsUsage` change (in production code and fuzz) that the calculations are still correct by recalculating them from scratch.

  <details>
  <summary>Details</summary>

  ```C++
  bool CCoinsViewCache::CacheUsageValid() const
  {
      size_t actual{0};
      for (auto& entry : cacheCoins | std::views::values) actual += entry.coin.DynamicMemoryUsage();
      return actual == cachedCoinsUsage;
  }
  ```
  or
  ```patch
  diff --git a/src/coins.cpp b/src/coins.cpp
  --- a/src/coins.cpp(revision fd3b1a7f4bb2ac527f23d4eb4cfa40a3215906e5)
  +++ b/src/coins.cpp(revision 872a05633bfdbd06ad82190d7fe34b42d13ebfe9)
  @@ -96,6 +96,7 @@
           fresh = !it->second.IsDirty();
       }
       if (!inserted) {
  +        Assert(cachedCoinsUsage >= it->second.coin.DynamicMemoryUsage());
           cachedCoinsUsage -= it->second.coin.DynamicMemoryUsage();
       }
       it->second.coin = std::move(coin);
  @@ -133,6 +134,7 @@
   bool CCoinsViewCache::SpendCoin(const COutPoint &outpoint, Coin* moveout) {
       CCoinsMap::iterator it = FetchCoin(outpoint);
       if (it == cacheCoins.end()) return false;
  +    Assert(cachedCoinsUsage >= it->second.coin.DynamicMemoryUsage());
       cachedCoinsUsage -= it->second.coin.DynamicMemoryUsage();
       TRACEPOINT(utxocache, spent,
              outpoint.hash.data(),
  @@ -226,10 +228,12 @@
               if (itUs->second.IsFresh() && it->second.coin.IsSpent()) {
                   // The grandparent cache does not have an entry, and the coin
                   // has been spent. We can just delete it from the parent cache.
  +                Assert(cachedCoinsUsage >= itUs->second.coin.DynamicMemoryUsage());
                   cachedCoinsUsage -= itUs->second.coin.DynamicMemoryUsage();
                   cacheCoins.erase(itUs);
               } else {
                   // A normal modification.
  +                Assert(cachedCoinsUsage >= itUs->second.coin.DynamicMemoryUsage());
                   cachedCoinsUsage -= itUs->second.coin.DynamicMemoryUsage();
                   if (cursor.WillErase(*it)) {
                       // Since this entry will be erased,
  @@ -279,6 +283,7 @@
   {
       CCoinsMap::iterator it = cacheCoins.find(hash);
       if (it != cacheCoins.end() && !it->second.IsDirty() && !it->second.IsFresh()) {
  +        Assert(cachedCoinsUsage >= it->second.coin.DynamicMemoryUsage());
           cachedCoinsUsage -= it->second.coin.DynamicMemoryUsage();
           TRACEPOINT(utxocache, uncache,
                  hash.hash.data(),
  ```

  </details>

ACKs for top commit:
  optout21:
    reACK 24d861da7894add47747eff69dd3fc71fbcdd7d0
  andrewtoth:
    ACK 24d861da7894add47747eff69dd3fc71fbcdd7d0
  sipa:
    ACK 24d861da7894add47747eff69dd3fc71fbcdd7d0
  w0xlt:
    ACK 24d861da78

Tree-SHA512: ff1b756b46220f278ab6c850626a0f376bed64389ef7f66a95c994e1c7cceec1d1843d2b24e8deabe10e2bdade2a274d9654ac60eb2b9bf471a71db8a2ff496c
2025-10-15 09:48:04 -04:00
Lőrinc
24d861da78 coins: only adjust cachedCoinsUsage on EmplaceCoinInternalDANGER insert
`EmplaceCoinInternalDANGER()` incremented `cachedCoinsUsage` even when `try_emplace` did not insert (duplicate key), inflating the counter.
This is mostly reachable in tests today since `AssumeUTXO` does not overwrite.

Increment only on successful insert, and capture `coin.DynamicMemoryUsage()` before the move so accounting uses the correct value.

Fuzz: add an `EmplaceCoinInternalDANGER` path to exercise insert-only accounting.
Unit test: emplace two different coins at the same outpoint (with different `DynamicMemoryUsage()`), verify `SelfTest()` passes and `AccessCoin(outpoint)` returns the first coin.

Co-authored-by: Andrew Toth <andrewstoth@gmail.com>
Co-authored-by: w0xlt <woltx@protonmail.com>
2025-10-12 12:37:45 -04:00
Lőrinc
d7c9d6c291 coins: fix cachedCoinsUsage accounting to prevent underflow
Move the `cachedCoinsUsage` subtract in `AddCoin()` to after the `possible_overwrite` check.
Previously a throw before assignment decremented the counter without changing the entry, which corrupted accounting and later underflowed.

In `Flush()`, reset `cachedCoinsUsage` to `0` only when `BatchWrite()` succeeds and `cacheCoins` is actually cleared. In production `BatchWrite()` returns `true`, so this mostly affects tests. On failure, leave the counter unchanged to keep it in sync with the cache.

The existing `Flush()` workaround in fuzzing was also removed now that the source of the problem was fixed, so the fuzzer no longer needs `coins_view_cache.Flush()` to realign `cachedCoinsUsage` after an exception.
Replace the prior `expected_code_path` tracking with direct assertions. The role of the variable was to verify that code execution follows only expected paths, either successful addition, or if it's an exception, the message is verified and checked that overwrite was disallowed.

With these changes the counter stays consistent across success and exception paths, so we can finally remove the `UBSan` suppressions for `CCoinsViewCache` that were masking the issue.

Included a unit test as well, attempting to add a different coin to the same outpoint without allowing overwrites and make sure it throws.
We use `SelfTest()` to validates accounting, and check that the cache remains usable.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
Co-authored-by: w0xlt <woltx@protonmail.com>
2025-10-11 22:05:22 -04:00
Lőrinc
39cf8bb3d0 refactor: remove redundant usage tracking from CoinsViewCacheCursor
When a coin is spent via `SpendCoin()`, `cachedCoinsUsage` is already decremented and the coin's `scriptPubKey` is cleared, so `DynamicMemoryUsage()` is `0`.

`CoinsViewCacheCursor::NextAndMaybeErase()` was subtracting usage again when erasing spent entries.
Replace it with an assert that documents spent coins have zero dynamic memory usage by the time the cursor encounters them.

Remove the now-unnecessary `usage` reference from the cursor's constructor and member variables.
2025-10-11 21:48:04 -04:00
Pieter Wuille
04c808ac4c txgraph: expose memory usage estimate function (feature) 2025-10-11 17:25:09 -04:00
Pieter Wuille
bb5cb222ae depgraph: add memory usage control (feature)
Co-Authored-By: Lőrinc <pap.lorinc@gmail.com>
2025-10-11 17:25:09 -04:00
MarcoFalke
fa0fa0f700
refactor: Revert "disable self-assign warning for tests"
This reverts commit 53372f21767be449bb452fc3f5fe7f16286ae371.
2025-10-09 20:47:25 +02:00
Ava Chow
d735e2e9b3
Merge bitcoin/bitcoin#32998: Bump SCRIPT_VERIFY flags to 64 bit
652424ad162b63d73ecb6bd65bd26946e90c617f test: additional test coverage for script_verify_flags (Anthony Towns)
417437eb01ac014c57aca47f44d7f8d3da351987 script/verify_flags: extend script_verify_flags to 64 bits (Anthony Towns)
3cbbcb66efc39c6566ab31836e4eb582b77581d2 script/interpreter: make script_verify_flag_name an ordinary enum (Anthony Towns)
bddcadee82daf3ed1441820a0ffc4c5ef78f64f1 script/verify_flags: make script_verify_flags type safe (Anthony Towns)
a5ead122fe060e7e582914dcb7acfaeee7a8ac48 script/interpreter: introduce script_verify_flags typename (Anthony Towns)
4577fb2b1e098c3f560b1ff50a37ebfef2af5f32 rpc: have getdeploymentinfo report script verify flags (Anthony Towns)
a3986935f073be799a35dfa92ab5004e12b35467 validation: export GetBlockScriptFlags() (Anthony Towns)
5db8cd2d37eba3ca6abc66386a3b9dc2185fa3ce Move mapFlagNames and FormatScriptFlags logic to script/interpreter.h (Anthony Towns)

Pull request description:

  We currently use 21 of 32 possible bits for `SCRIPT_VERIFY_*` flags, with open PRs that may use 8 more (#29247, #31989, #32247, #32453). The mutinynet fork that has included many experimental soft fork features is [already reusing bits here](d4a86277ed/src/script/interpreter.h (L175-L195)). Therefore, bump this to 64 bits.

  In order to make it easier to update this logic in future, this PR also introduces a dedicated type for the script flags, and disables implicit conversion between that type and the underlying integer type. To make verifying that this change doesn't cause flags to disappear, this PR also resurrects the changes from #28806 so that the script flags that are consensus enforced on each block can be queried via getdeploymentinfo.

ACKs for top commit:
  instagibbs:
    reACK 652424ad16
  achow101:
    ACK 652424ad162b63d73ecb6bd65bd26946e90c617f
  darosior:
    ACK 652424ad162b63d73ecb6bd65bd26946e90c617f
  theStack:
    Code-review ACK 652424ad162b63d73ecb6bd65bd26946e90c617f 🎏

Tree-SHA512: 7b30152196cdfdef8b9700b571b7d7d4e94d28fbc5c26ea7532788037efc02e4b1d8de392b0b20507badfdc26f5c125f8356a479604a9149b8aae23a7cf5549f
2025-10-07 14:51:22 -07:00
Hennadii Stepanov
f366408492
cmake: Set process code page to UTF-8 on Windows
Additionally, this change adds app manifests to targets that were
previously missing them.
2025-10-06 19:41:35 +01:00
merge-script
919e6d01e9
Merge bitcoin/bitcoin#33489: build: Drop support for EOL macOS 13
1aaaaa078bb2efed126e3f41ecf7c81ccf005818 fuzz: Drop unused workaround after Apple-Clang bump (MarcoFalke)
fadad7a49477cd61fbbfe20a0a61023c2d4d70a1 Drop support for EOL macOS 13 (MarcoFalke)

Pull request description:

  Now that macOS 13 is EOL (https://en.wikipedia.org/wiki/MacOS_Ventura), it seems odd to still support it.

  (macOS Ventura 13.7.8 received its final security update on 20 Aug 2025: https://support.apple.com/en-us/100100)

  This patch will only be released in version 31.x, another 6 months out from now.

  So:

  * Update the depends build and release note template to drop EOL macOS 13.
  * As a result, update the earliest Xcode to version 16 in CI.
  * Also, bump the macOS CI runner to version 15, to avoid issues when version 14 will be at its EOL in about 1 year.

  This also allows to drop a small workaround in the fuzz tests and unlocks libcpp hardening (https://github.com/bitcoin/bitcoin/pull/33462)

ACKs for top commit:
  stickies-v:
    re-ACK 1aaaaa078bb2efed126e3f41ecf7c81ccf005818
  l0rinc:
    code review ACK 1aaaaa078bb2efed126e3f41ecf7c81ccf005818
  hodlinator:
    re-ACK 1aaaaa078bb2efed126e3f41ecf7c81ccf005818
  hebasto:
    ACK 1aaaaa078bb2efed126e3f41ecf7c81ccf005818.

Tree-SHA512: 6d247a8432ef8ea8c6ff2a221472b278f8344346b172980299507f9898bb9e8e16480c128b1f4ca692bcbcc393da2b2fd6895ac5f118bc09e0f30f910529d20c
2025-10-06 12:48:00 -04:00
merge-script
452ea59281
Merge bitcoin/bitcoin#33454: net: support overriding the proxy selection in ConnectNode()
c76de2eea18076f91dd80b52f66ba790f071a2b1 net: support overriding the proxy selection in ConnectNode() (Vasil Dimov)

Pull request description:

  Normally `ConnectNode()` would choose whether to use a proxy and which one. Make it possible to override this from the callers and same for `OpenNetworkConnection()` - pass down the proxy to `ConnectNode()`.

  Document both functions.

  This is useful if we want to open connections to IPv4 or IPv6 peers through the Tor SOCKS5 proxy.

  Also have `OpenNetworkConnection()` return whether the connection succeeded or not. This can be used when the caller needs to keep track of how many (successful) connections were opened.

  ---

  This is part of [#29415 Broadcast own transactions only via short-lived Tor or I2P connections](https://github.com/bitcoin/bitcoin/pull/29415). Putting it in its own PR to reduce the size of #29415 and because it does not depend on the other commits from there.

ACKs for top commit:
  stratospher:
    ACK c76de2e.
  optout21:
    ACK c76de2eea18076f91dd80b52f66ba790f071a2b1
  mzumsande:
    Code Review ACK c76de2eea18076f91dd80b52f66ba790f071a2b1
  andrewtoth:
    ACK c76de2eea18076f91dd80b52f66ba790f071a2b1

Tree-SHA512: 1d266e4280cdb1d0599971fa8b5da58b1b7451635be46abb15c0b823a1e18cf6e7bcba4a365ad198e6fd1afee4097d81a54253fa680c8b386ca6b9d68d795ff0
2025-10-06 12:43:14 -04:00
merge-script
a33bd767a3
Merge bitcoin/bitcoin#33464: p2p: Use network-dependent timers for inbound inv scheduling
0f7d4ee4e8281ed141a6ebb7e0edee7b864e4dcf p2p: Use different inbound inv timer per network (Martin Zumsande)
94db966a3bb52a3677eb5f762447202ed3889f0f net: use generic network key for addrcache (Martin Zumsande)

Pull request description:

  Currently, `NextInvToInbounds` schedules  each round of `inv` at the same time for all inbound peers. It's being done this way because with a separate timer per peer (like it's done for outbounds), an attacker could do multiple connections to learn about the time a transaction arrived. (#13298).

  However, having a single timer for inbounds of all networks is also an obvious fingerprinting vector: Connecting to a suspected pair of privacy-network and clearnet addresses and observing the `inv` pattern makes it trivial to confirm or refute that they are the same node.

  This PR changes it such that a separate timer is used for each network.
  It uses the existing method  from `getaddr` caching and generalizes it to be saved in a new field `m_network_key` in `CNode` which will be used for both `getaddr` caching and `inv` scheduling, and can also be used for any future anti-fingerprinting measures.

ACKs for top commit:
  sipa:
    utACK 0f7d4ee4e8281ed141a6ebb7e0edee7b864e4dcf
  stratospher:
    reACK 0f7d4ee.
  naiyoma:
    Tested ACK 0f7d4ee4e8281ed141a6ebb7e0edee7b864e4dcf
  danielabrozzoni:
    reACK 0f7d4ee4e8

Tree-SHA512: e197c3005b2522051db432948874320b74c23e01e66988ee1ee11917dac0923f58c1252fa47da24e68b08d7a355d8e5e0a3ccdfa6e4324cb901f21dfa880cd9c
2025-10-03 23:45:17 +01:00
merge-script
1ed00a0d39
Merge bitcoin/bitcoin#33504: Mempool: Do not enforce TRUC checks on reorg
06df14ba75be5f48cf9c417424900ace17d1cf4d test: add more TRUC reorg coverge (Greg Sanders)
26e71c237d9d2197824b547f55ee3a0a60149f92 Mempool: Do not enforce TRUC checks on reorg (Greg Sanders)
bbe8e9063c15dc230553e0cbf16d603f5ad0e4cf fuzz: don't bypass_limits for most mempool harnesses (Greg Sanders)

Pull request description:

  This was the intended behavior but our tests didn't cover the scenario where in-block transactions themselves violate TRUC topological constraints.

  The behavior in master will potentially lead to many erroneous evictions during a reorg, where evicted TRUC packages may be very high feerate and make sense to mine all together in the next block and are well within the normal anti-DoS chain limits.

  This issue exists since the merge of https://github.com/bitcoin/bitcoin/pull/28948/files#diff-97c3a52bc5fad452d82670a7fd291800bae20c7bc35bb82686c2c0a4ea7b5b98R956

ACKs for top commit:
  sdaftuar:
    ACK 06df14ba75be5f48cf9c417424900ace17d1cf4d
  glozow:
    ACK 06df14ba75b
  ismaelsadeeq:
    Code review ACK 06df14ba75be5f48cf9c417424900ace17d1cf4d

Tree-SHA512: bdb6e4dd622ed8b0b11866263fff559fcca6e0ca1c56a884cca9ac4572f0026528a63a9f4c8a0660df2f5efe0766310a30e5df1d6c560f31e4324ea5d4b3c1a8
2025-10-02 13:22:22 +01:00
Vasil Dimov
c76de2eea1
net: support overriding the proxy selection in ConnectNode()
Normally `ConnectNode()` would choose whether to use a proxy and which
one. Make it possible to override this from the callers and same for
`OpenNetworkConnection()` - pass down the proxy to `ConnectNode()`.

Document both functions.

This is useful if we want to open connections to IPv4 or IPv6 peers
through the Tor SOCKS5 proxy.

Also have `OpenNetworkConnection()` return whether the connection
succeeded or not. This can be used when the caller needs to keep track
of how many (successful) connections were opened.
2025-10-02 08:39:26 +02:00
MarcoFalke
1aaaaa078b
fuzz: Drop unused workaround after Apple-Clang bump 2025-10-01 08:09:34 +02:00
Ava Chow
f41f97240c
Merge bitcoin/bitcoin#28584: Fuzz: extend CConnman tests
0802398e749c5e16fa7085cd87c91a31bbe043bd fuzz: make it possible to mock (fuzz) CThreadInterrupt (Vasil Dimov)
6d9e5d130d2e1d052044e9a72d44cfffb5d3c771 fuzz: add CConnman::SocketHandler() to the tests (Vasil Dimov)
3265df63a48db187e0d240ce801ee573787fed80 fuzz: add CConnman::InitBinds() to the tests (Vasil Dimov)
91cbf4dbd864b65ba6b107957f087d1d305914b2 fuzz: add CConnman::CreateNodeFromAcceptedSocket() to the tests (Vasil Dimov)
50da7432ec1e5431b243aa30f8a9339f8e8ed97d fuzz: add CConnman::OpenNetworkConnection() to the tests (Vasil Dimov)
e6a917c8f8e0f1a0fa71dc9bbb6e1074f81edea3 fuzz: add Fuzzed NetEventsInterface and use it in connman tests (Vasil Dimov)
e883b37768812d96feec207a37202c7d1b603c1f fuzz: set the output argument of FuzzedSock::Accept() (Vasil Dimov)

Pull request description:

  Extend `CConnman` fuzz tests to also exercise the methods `OpenNetworkConnection()`, `CreateNodeFromAcceptedSocket()`, `InitBinds()` and `SocketHandler()`.

  Previously fuzzing those methods would have resulted in real socket functions being called in the operating system which is undesirable during fuzzing. Now that https://github.com/bitcoin/bitcoin/pull/21878 is complete all those are mocked to a fuzzed socket and a fuzzed DNS resolver (see how `CreateSock` and `g_dns_lookup` are replaced in the first commit).

ACKs for top commit:
  achow101:
    ACK 0802398e749c5e16fa7085cd87c91a31bbe043bd
  jonatack:
    Review re-ACK 0802398e749c5e16fa7085cd87c91a31bbe043bd
  dergoegge:
    Code review ACK 0802398e749c5e16fa7085cd87c91a31bbe043bd

Tree-SHA512: a717d4e79f42bacf2b029c821fdc265e10e4e5c41af77cd4cb452cc5720ec83c62789d5b3dfafd39a22cc8c0500b18169aa7864d497dded729a32ab863dd6c4d
2025-09-30 15:59:09 -07:00
Greg Sanders
bbe8e9063c fuzz: don't bypass_limits for most mempool harnesses
Using bypass_limits=true is essentially fuzzing part of a
reorg only, and results in TRUC invariants unable to be
checked. Remove most instances of bypassing limits, leaving
one harness able to do so.
2025-09-29 16:25:54 -04:00
merge-script
7e08445449
Merge bitcoin/bitcoin#33399: key: use static context for libsecp256k1 calls where applicable
1ff9e929489e625a603e8755b8efe849feda1f16 key: use static context for libsecp256k1 calls where applicable (Sebastian Falbesoner)

Pull request description:

  The dynamically created [signing context](2d6a0c4649/src/key.cpp (L19)) for libsecp256k1 calls is only needed for functions that involve generator point multiplication with a secret key, i.e. different variants of public key creation and signing. The API docs hint to those by stating "[(not secp256k1_context_static)](b475654302/include/secp256k1.h (L645))" for the context parameter. In our case that applies to the following calls:
  - `secp256k1_ec_pubkey_create`
  - `secp256k1_keypair_create`
  - `secp256k1_ellswift_create`
  - `secp256k1_ecdsa_sign`
  - `secp256k1_ecdsa_sign_recoverable`
  - `secp256k1_schnorrsig_sign32`
  - `ec_seckey_export_der` (not a direct secp256k1 function, but calls `secp256k1_ec_pubkey_create` inside)

  For all the other secp256k1 calls we can simply use the static context. This is done for consistency to other calls that already use `secp256k1_context_static`, and also to reduce dependencies on the global signing context variable. Looked closer at this in the course of reviewing #29675, where some functions used the signing context that didn't need to, avoiding a move to another module (see https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2333831377).

ACKs for top commit:
  Eunovo:
    ACK 1ff9e92948
  furszy:
    ACK 1ff9e929489e625a603e8755b8efe849feda1f16
  rkrux:
    crACK 1ff9e929489e625a603e8755b8efe849feda1f16

Tree-SHA512: f091efa56c358057828f3455d4ca9ce40ec0d35f3e38ab147fe3928bb5dbf7ffbc27dbf97b71937828ab95ea4e9be5f96d89a2d29e2aa18df4542aae1b33e258
2025-09-26 11:44:29 -04:00
Martin Zumsande
94db966a3b net: use generic network key for addrcache
The generic key can also be used in other places
where behavior between different network identities should
be uncorrelated to avoid fingerprinting.
This also changes RANDOMIZER_ID - since it is not
being persisted to disk, there are no compatibility issues.
2025-09-23 10:56:44 -04:00
marcofleon
6a33970fef fuzz: Reduce iterations in slow targets 2025-09-19 15:13:15 +01:00
Sebastian Falbesoner
1ff9e92948 key: use static context for libsecp256k1 calls where applicable
The dynamically created signing context for libsecp256k1 calls is only
needed for functions that involve generator point multiplication with a
secret key, i.e. different variants of public key creation and signing.
The API docs hint to this by stating "not secp256k1_context_static" for
the context parameter. In our case that applies to the following calls:
- `secp256k1_ec_pubkey_create`
- `secp256k1_keypair_create`
- `secp256k1_ellswift_create`
- `secp256k1_ecdsa_sign`
- `secp256k1_ecdsa_sign_recoverable`
- `secp256k1_schnorrsig_sign32`
- `ec_seckey_export_der` (not a direct secp256k1 function, but calls
  `secp256k1_ec_pubkey_create` inside)

For all the other secp256k1 calls we can simply use the static context.
2025-09-16 21:46:18 +02:00
Hodlinator
cc5dda1de3
headerssync: Make HeadersSyncState more flexible and move constants
Move calculated constants from the top of src/headerssync.cpp into src/kernel/chainparams.cpp.

Instead of being hardcoded to mainnet parameters, HeadersSyncState can now vary depending on chain or test. (This means we can reset TARGET_BLOCKS back to the nice round number of 15'000).

Signet and testnets got new HeadersSyncParams constants through temporarily altering headerssync-params.py with corresponding GENESIS_TIME and MINCHAINWORK_HEADERS (based off defaultAssumeValid block height comments, corresponding to nMinimumChainWork). Regtest doesn't have a default assume valid block height, so the values are copied from Testnet 4. Since the constants only affect memory usage, and have very low impact unless dealing with a largely malicious chain, it's not that critical to keep updating them for non-mainnet chains.

GENESIS_TIMEs (UTC):
Testnet3: 1296688602 = datetime(2011, 2, 2)
Testnet4: 1714777860 = datetime(2024, 5, 3)
Signet: 1598918400 = datetime(2020, 9, 1)
2025-09-12 22:28:41 +02:00
Anthony Towns
652424ad16 test: additional test coverage for script_verify_flags 2025-09-11 11:24:09 +10:00
Pieter Wuille
d45f3717d2 txgraph: use enum Level instead of bool main_only 2025-09-10 08:03:17 -04:00
Ava Chow
1861030bea
Merge bitcoin/bitcoin#30469: index: Fix coinstats overflow
c76797481155754329ec6a6f58e8402569043944 clang-tidy: Fix critical warnings (Fabian Jahr)
54dc34ec2279378c78fa2d9155668e39e20decda index: Remove unused coinstatsindex recovery code (Fabian Jahr)
37c4fba1f4c18632bceb16f41f5a8f1a61fb9096 index: Check BIP30 blocks when rewinding Coinstatsindex (Fabian Jahr)
51df9de8e5b9c8ecd8339d95b630f312fcb9414e doc: Add release note for 30469 (Fabian Jahr)
bb8d673183294a43c716ff8738da2492f3d7a94b test: Add coinstatsindex compatibility test (Fabian Jahr)
b2e8b64ddc351124ac1390ee906a8fcd2781ca50 index, refactor: Append blocks to coinstatsindex without db read (Fabian Jahr)
431a076ae6e3cc32a8725d4a01483d27c5081a34 index: Fix coinstatsindex overflow issue (Fabian Jahr)
84e813a02bb7b3c735ae413f06c0fc156bfeb7ac index, refactor: DRY coinbase check (Fabian Jahr)
fab842b3248744fb0030486f64d3febe815f8377 index, refactor: Rename ReverseBlock to RevertBlock (Fabian Jahr)

Pull request description:

  Closes https://github.com/bitcoin/bitcoin/issues/26362

  This continues the work that was started with #26426. It fixes the overflow issue by switching the tracked values that are in danger of overflowing from `CAmount` to `arith_uint256`.

  The current approach opts for a simple solution to ensure compatibility with datadirs including the previous version of the index: The new version of the index goes into a separate location in the datadir (`index/coinstatsindex/` rather than `index/coinstats/` before, the new naming is more consistent with the naming of the other indexes). There is no explicit concept of versioning of the index which earlier versions of this PR had. Having the two different versions of the index in separate places allows for downgrading of the node without having to rebuild the index. However, there will be a warning printed in the logs if the new code (v30) detects the old index still being present. A future version could delete a left-over legacy index automatically.

  The PR also includes several minor improvements but most notably it lets new entries be calculated and stored without needing to read any DB records.

ACKs for top commit:
  achow101:
    ACK c76797481155754329ec6a6f58e8402569043944
  TheCharlatan:
    ACK c76797481155754329ec6a6f58e8402569043944
  mzumsande:
    Tested / Code Review ACK c76797481155754329ec6a6f58e8402569043944

Tree-SHA512: 3fa4a19dd1a01c1b01390247bc9daa6871eece7c1899eac976e0cc21ede09c79c65f758d14daafc46a43c4ddd7055c85fb28ff03029132d48936b248639c6ab9
2025-09-08 17:06:30 -07:00
TheCharlatan
188de70c86
net: Add interrupt to pcp retry loop
Without this interrupt bitcoind takes a long time to exit if requested
to do so after a failed pcp lookup on startup.
2025-09-08 11:18:51 +02:00
Fabian Jahr
c767974811
clang-tidy: Fix critical warnings
The std::move in coinstatsindex was not necessary since it was passed as a const reference argument.

The other change in the utxo supply fuzz test changes a line that seems to have triggered a false alarm.
2025-09-07 17:28:31 +02:00
frankomosh
58be359f6b fuzz: add a target for DifferenceFormatter Class
Add fuzz test to verify that arbitrary input successfully deserialized
by DifferenceFormatter will maintain the sorted-without-duplicates invariant.
2025-09-02 07:50:07 +03:00
Anthony Towns
b9300d8d0a Revert "refactor: Simplify extra_txn to be a vec of CTransactionRef instead of a vec of pair<Wtxid, CTransactionRef>"
This reverts commit a8203e94123b6ea6e4f4a6320e3ad20457f44a28.
2025-08-27 03:33:32 +10:00
Anthony Towns
bddcadee82 script/verify_flags: make script_verify_flags type safe
`using script_verify_flags = uint32_t` allows implicit conversion to
and from int, so replace it with a class to have the compiler ensure we
use the correct type. Provide from_int and as_int to allow for explicit
conversions when desired.

Introduces the type `script_verify_flag_name` for the individual flag
name enumeration.
2025-08-14 10:17:32 +10:00
Anthony Towns
a5ead122fe script/interpreter: introduce script_verify_flags typename
Previously the SCRIPT_VERIFY_* flags were specified as either uint32_t,
unsigned int, or unsigned. This converts them to a common type alias in
preparation for changing the underlying type.
2025-08-14 10:17:32 +10:00
Lőrinc
743abbcbde refactor: inline constant return value of BlockTreeDB::WriteBatchSync and BlockManager::WriteBlockIndexDB and BlockTreeDB::WriteFlag 2025-08-13 15:47:48 -07:00
merge-script
9b1a7c3e8d
Merge bitcoin/bitcoin#33116: refactor: Convert uint256 to Txid
de0675f9de5feae1f070840ad7218b1378fb880b refactor: Move `transaction_identifier.h` to primitives (marcofleon)
6f068f65de17951dc459bc8637e5de15b84ca445 Remove implicit uint256 conversion and comparison (marcofleon)
9c24cda72edb2085edfa75296d6b42fab34433d9 refactor: Convert remaining instances from uint256 to Txid (marcofleon)
d2ecd6815d89c9b089b55bc96fdf93b023be8dda policy, refactor: Convert uint256 to Txid (marcofleon)
f6c0d1d23128f742dfdda253752cba7db9bb0679 mempool, refactor: Convert uint256 to Txid (marcofleon)
aeb0f783305c923ee7667c46ca0ff7e1b96ed45c refactor: Convert `mini_miner` from uint256 to Txid (marcofleon)
326f24472487dc7f447839136db2ccf60833e9a2 refactor: Convert RPCs and `merkleblock` from uint256 to Txid (marcofleon)
49b3d3a92a7250e80c56ff8c351cf1670e32c1a2 Clean up `FindTxForGetData` (marcofleon)

Pull request description:

  This is the final leg of the [type safety refactor](https://github.com/bitcoin/bitcoin/pull/32189).

  All of these changes are straightforward `uint256` --> `Txid` along with any necessary explicit conversions. Also, `transaction_identifier.h` is moved to primitives in the last commit, as `Txid` and `Wtxid` become fundamental types after this PR.

ACKs for top commit:
  stickies-v:
    re-ACK de0675f9de5feae1f070840ad7218b1378fb880b, no changes since a20724d926d5844168c6a13fa8293df8c8927efe except address review nits.
  janb84:
    re ACK de0675f9de5feae1f070840ad7218b1378fb880b
  dergoegge:
    re-ACK de0675f9de5feae1f070840ad7218b1378fb880b
  theStack:
    Code-review ACK de0675f9de5feae1f070840ad7218b1378fb880b

Tree-SHA512: 2413160fca7ab146a8d79d18ce3afcf7384cacc73c513d41928904aa453b4dd7a350064cee71e9c5d015da5904c7c81ac17603e50a47441ebc5b0c653235dd08
2025-08-13 14:50:51 -04:00
marcofleon
de0675f9de refactor: Move transaction_identifier.h to primitives
Moves the file from `src/util` to `src/primitives`. Now that the
refactor is complete, Txid and Wtxid are fundamental types, so it
makes sense for them to reside in `src/primitives`.
2025-08-11 16:47:51 +01:00
marcofleon
9c24cda72e refactor: Convert remaining instances from uint256 to Txid
These remaining miscellaneous changes were identified by commenting out
the `operator const uint256&` conversion and the `Compare(const uint256&)`
method from `transaction_identifier.h`.
2025-08-11 16:47:43 +01:00
marcofleon
d2ecd6815d policy, refactor: Convert uint256 to Txid 2025-08-11 16:28:59 +01:00
marcofleon
f6c0d1d231 mempool, refactor: Convert uint256 to Txid 2025-08-11 16:26:35 +01:00
marcofleon
326f244724 refactor: Convert RPCs and merkleblock from uint256 to Txid 2025-08-11 15:53:34 +01:00
merge-script
a27430e259
Merge bitcoin/bitcoin#32473: Introduce per-txin sighash midstate cache for legacy/p2sh/segwitv0 scripts
83950275eddacac56c58a7a3648ed435a5593328 qa: unit test sighash caching (Antoine Poinsot)
b221aa80a081579b8d3b460e3403f7ac0daa7139 qa: simple differential fuzzing for sighash with/without caching (Antoine Poinsot)
92af9f74d74e76681f7d98f293eab226972137b4 script: (optimization) introduce sighash midstate caching (Pieter Wuille)
8f3ddb0bccebc930836b4a6745a7cf29b41eb302 script: (refactor) prepare for introducing sighash midstate cache (Pieter Wuille)
9014d4016ad9351cb59b587541895e55f5d589cc tests: add sighash caching tests to feature_taproot (Pieter Wuille)

Pull request description:

  This introduces a per-txin cache for sighash midstate computation to the script interpreter for legacy (bare), P2SH, P2WSH, and (as collateral effect, but not actually useful) P2WPKH. This reduces the impact of certain types of quadratic hashing attacks that use standard transactions. It is not known to improve the situation for attacks involving non-standard transaction attacks.

  The cache works by remembering for each of the 6 sighash modes a `(scriptCode, midstate)` tuple, which gives a midstate `CSHA256` object right before the appending of the sighash type itself (to permit all 256, rather than just the 6 ones that match the modes). The midstate is only reused if the `scriptCode` matches. This works because - within a single input - only the sighash type and the `scriptCode` affect the actual sighash used.

  The PR implements two different approaches:
  * The initial commits introduce the caching effect always, for both consensus and relay relation validation. Despite being primarily intended for improving the situation for standard transactions only, I chose this approach as the code paths are already largely common between the two, and this approach I believe involves fewer code changes than a more targetted approach, and furthermore, it should not hurt (it may even help common multisig cases slightly).
  * The final commit changes the behavior to only using the cache for non-consensus script validation. I'm open to feedback about whether adding this commit is worth it.

  Functional tests are included that construct contrived cases with many sighash types (standard and non-standard ones) and `OP_CODESEPARATOR`s in all script types (including P2TR, which isn't modified by this PR).

ACKs for top commit:
  achow101:
    ACK 83950275eddacac56c58a7a3648ed435a5593328
  dergoegge:
    Code review ACK 83950275eddacac56c58a7a3648ed435a5593328
  darosior:
    re-ACK 83950275eddacac56c58a7a3648ed435a5593328

Tree-SHA512: 65ae8635429a4d563b19969bac8128038ac2cbe01d9c9946abd4cac3c0780974d1e8b9aae9bb83f414e5d247a59f4a18fef5b37d93ad59ed41b6f11c3fe05af4
2025-08-11 10:26:19 +01:00