BC
← All projectsBitcoin Core

Bitcoin Core

The Bitcoin network's reference node and wallet implementation.

BitcoinSupply chainNormal
Repository coverage

2876 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

252security candidates603second-pass queue199AI analyses
210commits · 30 days
492commits · 60 days
1521commits · 180 days
2876commits · 365 days
Backfill bands
Aug 5 → Feb 61351 seen45 candidatesComplete
Feb 6 → Jun 61033 seen63 candidatesComplete
Jun 6 → Jul 6281 seen11 candidatesComplete
Jul 6 → Aug 5207 seen5 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

70/100 average clarity
915Strong · 80–100
1187Adequate · 60–79
686Thin · 40–59
88Opaque · 0–39
6security candidates with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Antoine Poinsot2244170
Ava Chow1564946064
MarcoFalke4062113074
Lőrinc1772116081
fanquake227199057
Hennadii Stepanov208147063
rkrux5798074
Sjors Provoost8988074
Sebastian Falbesoner3376073
David Gumberg5563072
Pieter Wuille9555066
Hodlinator6654076
Analysis record

Published AI watches

Last scanned 21 minutes ago

Informational 15 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

refactor: Make all `const static` class members `constexpr`

This commit is a code cleanup that changes many internal class constants from 'static const' to 'static constexpr'. In modern C++, constexpr constants are automatically inlined and avoid certain linker errors when used in specific ways. Th…

05c35c40by rustaceanrob+38−4024 files
No security note in commit
Informational 15 AI analysisMessage 83 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

scripted-diff: Use long form of shell options in Guix scripts

This commit is a purely cosmetic change in Bitcoin Core's Guix build scripts. It replaces the short shell command 'set -e' with its long-form equivalent 'set -o errexit'. Both forms do exactly the same thing: they make the script exit imme…

2cb3bfa8by Hennadii Stepanov+6−66 files
No security note in commit
Informational 15 AI analysisMessage 45 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

guix: Add copyright headers to Guix scripts

This commit only adds or updates copyright and license header comments at the top of several helper scripts used for Bitcoin Core's Guix build process. It does not change any executable code, logic, or behavior. There is no security risk.

711eb10fby Hennadii Stepanov+20−27 files
No security note in commit
Low 28 AI analysisMessage 96 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Squashed 'src/secp256k1/' changes from bd0287d650..d2d04864ef

This commit updates the secp256k1 cryptographic library inside Bitcoin Core to a newer version. The main change is adding support for a new optional feature called 'Silent Payments' (BIP352), which is a privacy-enhancing way to receive Bit…

New cryptographic module added (Silent Payments / BIP352)Field-element equality check magnitude bound corrected from 31 to 30X-only public key even-Y invariant enforced in extrakeys module
a33f2405by fanquake+13939−13434 files
No security note in commit
Informational 15 AI analysisMessage 90 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

scripted-diff: Use C.UTF-8 locale in Guix scripts

This commit is a routine cleanup that changes the locale setting in Bitcoin Core's Guix build scripts from the old ASCII-only 'C' locale to the modern 'C.UTF-8' locale. It is not a security fix and does not change any behavior that could b…

8916f796by Hennadii Stepanov+15−1515 files
No security note in commit
Informational 19 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

p2p: Assume v2transport for addresses from seeds

This change makes Bitcoin Core assume that hard-coded and DNS seed nodes support the newer BIP324 encrypted transport (v2) when first connecting. If the guess is wrong, the software falls back to the older v1 protocol automatically. It is …

Adds NODE_P2P_V2 to assumed service flags for seed-derived addressesFallback to v1 transport exists if the v2 assumption is wrongNo input validation, memory safety, or cryptographic changes
cf0f2aeaby Martin Zumsande+10−22 files
No security note in commit
Informational 15 AI analysisMessage 85 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

refactor: simplify adding SipHash-1-3-UJ

This is a code cleanup (refactor) that moves the internal SipHash mixing steps into shared helper methods. It does not change how Bitcoin hashes data, how many rounds are run, or any user-visible behavior. There is no security bug being fi…

25bfca06by Lőrinc+74−1222 files
No security note in commit
Informational 21 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

crypto: add generic SipHash-1-3-UJ

This commit adds a new, weaker variant of the SipHash algorithm inside Bitcoin Core's cryptography module. It is explicitly designed for low-security uses such as internal hash tables, not for protecting funds or network messages. The code…

New weaker cryptographic primitive added (SipHash-1-3 vs. standard SipHash-2-4)Explicit unpadded input design removes length-commitment paddingJumbo 256-bit blocks increase attacker control within a single round
c2d7931bby Pieter Wuille+103−02 files
No security note in commit
Informational 15 AI analysisMessage 78 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

bench: add fixed-width SipHash benchmarks

This commit only adds new performance benchmark tests for a hash function called SipHash. It does not change any production code that handles Bitcoin transactions, networking, or wallet data. There is no security issue here.

7ff55cc6by Lőrinc+49−31 file
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

crypto: add fixed-width SipHash-1-3-UJ

This commit adds two new shortcut methods for computing a specific SipHash variant on fixed-size inputs. It is a pure performance/ergonomics addition: the new methods copy the hasher's internal state before operating, so they do not alter …

a0ccd4adby Pieter Wuille+21−01 file
No security note in commit
Informational 15 AI analysisMessage 90 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: add shared SipHash vectors

This commit only adds new test data and test code for the SipHash hashing function used in Bitcoin Core. It does not change any production code that handles transactions, networking, or wallets. The goal is to make sure the existing SipHas…

af50ba85by Lőrinc+797−237 files
No security note in commit
Informational 15 AI analysisMessage 72 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: compat, ensure downgrade preserves tx witness variants

This commit adds a new regression test to Bitcoin Core. It checks that when a wallet created on a newer version is loaded on an older version and then brought back to the newer version, the wallet still remembers alternative 'witness varia…

99bdcb06by furszy+74−01 file
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

fuzz: clang-format LIMITED_WHILE

This commit is purely a code-style cleanup. It adds a space between the macro name LIMITED_WHILE and its opening parenthesis across many fuzz test files, plus a few tiny formatting fixes like removing a redundant semicolon and fixing inden…

fab8eeedby MarcoFalke+91−14265 files
No security note in commit
Moderate 63 AI analysisMessage 90 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

net_processing: add a global delay queue for sending txs

This commit adds a global rate limiter to how many transaction announcements (INV messages) a Bitcoin node sends out. Before, each peer had its own queue, so a node could receive one transaction and announce it to over 100 peers, acting li…

Global rate limiting replaces per-peer queues to prevent transaction-announcement amplificationDual token buckets bound both INV count and relay bandwidthCommit message explicitly describes the change as limiting transaction-spam amplification and excessive memory/CPU usage
df31ee57by Anthony Towns+176−252 files
Vendor flagged security relevance
Informational 19 AI analysisMessage 45 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

chainparams: delete my DNS seed

A Bitcoin Core developer removed their own DNS seed (seed.bitcoin.sipa.be, run by Pieter Wuille) from the list of hardcoded network seeds that help new Bitcoin nodes find peers when they first start up. This is a routine operational/mainte…

Removal of a trusted bootstrap DNS seed from default chain parametersReduction in peer-discovery redundancy for new mainnet nodesNo vulnerability patch, cryptographic fix, or memory-safety change present
d9080639by Pieter Wuille+1−32 files
No security note in commit
Informational 15 AI analysisMessage 95 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: Redeclare variable as signed in `util_tests`

This is a minor fix to a unit test file. A test variable was being assigned a negative value in an unsigned container, which caused a silent underflow and made the test assertion technically incorrect. The patch changes the test to check t…

cd2a4bc5by rustaceanrob+1−21 file
No security note in commit
Informational 24 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: add regression test for in-memory SQLiteDatabase reopen

This commit only adds a new automated test. It checks that Bitcoin Core's in-memory SQLite wallet database correctly refuses to reopen after being closed, because reopening would silently create a fresh empty database and discard any previ…

Regression test for data-loss prevention behavior in wallet database layerIn-memory SQLite database reopen could silently discard wallet dataOpen() now throws std::runtime_error instead of returning a fresh connection
777d23f2by Pablo Martin+9−01 file
No security note in commit
Low 43 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

refactor: Use u64 over size_t for all cache sizes to fix a 32-bit overflow

This commit fixes a bug in Bitcoin Core that only affects 32-bit computers. When the program calculated how much database cache to allocate, it multiplied a large default cache value by 10. On 32-bit systems that multiplication overflowed,…

Integer overflow in cache-size calculation on 32-bit systemsUnsigned multiplication overflow explicitly mentioned in commit message with runtime sanitizer outputType promotion from size_t to uint64_t to prevent platform-dependent width issues
fabafd91by MarcoFalke+37−285 files
Vendor flagged security relevance
Informational 23 AI analysisMessage 85 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

wallet: Use Descriptor::CanSelfExpand() in CanGetAddresses()

This is a small Bitcoin Core wallet change that lets the wallet generate addresses from certain descriptors even when it does not have private keys and has already used up its pre-derived address range. It only affects descriptors that can…

Changes address-derivation gating logic in wallet codeExpands conditions under which addresses can be produced without private keysNo explicit security framing, CVE, or advisory language in commit
1e996640by Ava Chow+1−11 file
No security note in commit
Informational 19 AI analysisMessage 58 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

descriptor: Add CanSelfExpand()

This commit adds a new helper method called CanSelfExpand() to Bitcoin Core's descriptor system. It lets the code ask whether a wallet descriptor can produce its Bitcoin address(es) on its own, without needing a saved cache or private keys…

New API surface added to descriptor subsystem (CanSelfExpand)No change to existing expansion, signing, or key-derivation logicNo bounds, memory, or cryptographic operations modified
d2ee9227by Ava Chow+57−184 files
No security note in commit
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Security candidatepsbt, test: remove address type restrictions in testby rkrux · 81348576 · May 13, 2026 · 1 fileMessage 87 · StrongInformational 15Details
Commit message · rkrux

psbt, test: remove address type restrictions in test

Because the corresponding Taproot fields were added in PSBT in PR 22558, so
these restrictions are no longer necessary.

87/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This is a minor test-only cleanup. It removes a TODO comment and two command-line flags that forced a specific address type in one of Bitcoin Core's automated functional tests. The change has no effect on production code, user wallets, or network behavior.

Security candidatekey: cleanse ChainCode on destructionby Thomas · 21a1380c · May 12, 2026 · 4 filesMessage 78 · AdequateLow 49Details
Commit message · Thomas

key: cleanse ChainCode on destruction

HMAC primitives cleanse their internal stack buffers, but a caller's
ChainCode remains populated in memory after use. Promote ChainCode
from `typedef uint256` to a `base_blob<256>` subclass with a
memory_cleanse() destructor, so chain codes in CExtKey, CExtPubKey,
and local variables are cleansed on scope exit.

Retype MUSIG_CHAINCODE from `constexpr uint256` to `const ChainCode`
to match its BIP328 semantic role. Dropping `constexpr` (ChainCode is
no longer a literal type) also removes the GCC-14 consteval lambda
workaround.

Remove the duplicate typedef in pubkey.h (which includes hash.h
transitively). Two fuzz-test call sites in test/fuzz/key.cpp now
construct the chain-code argument explicitly rather than relying on
the typedef.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
secret or key materialfuzzing or regression evidence
AI analysis · Low 49/100

This commit is a defensive hardening change for Bitcoin Core's handling of BIP32 'chain codes'—secret-derived values used when creating child keys from a master key. Previously these values were stored as ordinary 256-bit numbers that could remain in memory after use. The change makes ChainCode a dedicated type that securely wipes its own memory when it goes out of scope, similar to how private keys are already handled. It is a preventive security improvement rather than a fix for an active exploit.

Security candidatemusig: Include pubnonce in session idby Ava Chow · bb05986c · May 12, 2026 · 4 filesMessage 80 · StrongLow 31Details
Commit message · Ava Chow

musig: Include pubnonce in session id

Multiple signing sessions over the same message are allowed. Including
the pubnonce in the session id allows distinguishing the signing
sessions.

This should be safe as a new secret nonce is used for each signing
session, and after the nonce is used, it is still deleted from memory in
order to avoid reuse.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing boundarynonce handlingsigning or wallet path
AI analysis · Low 31/100

This change tweaks how Bitcoin Core's MuSig2 multi-signature code keeps track of active signing sessions. Previously, the session identifier was based only on the public keys and the transaction hash. Now it also includes each participant's public nonce. This matters because the same keys and transaction can legitimately be signed more than once, and without the nonce in the identifier the code could confuse two different signing sessions and risk reusing or misplacing secret nonce data. The commit itself is framed as a safety improvement, not a fix for a known active bug or exploit.

Security candidaterpc: Fix descriptorprocesspsbt internal bug on invalid signaturesby b-l-u-e · 7e19ce20 · May 12, 2026 · 3 filesMessage 73 · AdequateModerate 62Details
Commit message · b-l-u-e

rpc: Fix descriptorprocesspsbt internal bug on invalid signatures

Use PSBTInputSignedAndVerified instead of PSBTInputSigned to properly
validate signatures before marking PSBT as complete

Signed-off-by: b-l-u-e <8102260+blue@users.noreply.github.com>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarydefensive validationsigning or wallet path
AI analysis · Moderate 62/100

This commit fixes a bug in Bitcoin Core's descriptorprocesspsbt RPC command. Previously, the command could mark a partially-signed Bitcoin transaction (PSBT) as 'complete' and return a finalized transaction hex even when one of the signatures was actually invalid. The fix makes the command verify signatures cryptographically, not just check that signature data is present. The new test deliberately corrupts a signature and confirms the command now correctly reports the PSBT as incomplete.

Security candidatecrypto: cleanse HMAC stack buffers after useby Thomas · b3a3f883 · May 10, 2026 · 2 filesMessage 68 · AdequateModerate 51Details
Commit message · Thomas

crypto: cleanse HMAC stack buffers after use

CHMAC_SHA256 and CHMAC_SHA512 leave two stack buffers populated on
return: rkey[] holds K' XOR ipad after the constructor, and temp[]
holds the inner-hash output after Finalize().

When the HMAC is keyed with sensitive material (chain code in
BIP32Hash() in hash.cpp for BIP32 child key derivation; PRK in
HKDF-Expand in hkdf_sha256_32.cpp, used for BIP324 transport keying),
rkey is one constant XOR from that key, and temp is a one-way digest
covering it.

Cleanse both buffers with memory_cleanse(), matching the convention
in chacha20.cpp and chacha20poly1305.cpp. No observable change for
callers.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Moderate 51/100

This commit is a defensive hardening patch for Bitcoin Core's HMAC code. It wipes two temporary memory buffers that previously held sensitive key-derived data after the HMAC operation finishes. The change reduces the risk that leftover key material could leak through memory dumps, core dumps, or side-channel attacks, but it does not fix an active bug or known exploit.

Security candidatevalidation: correct lifetime of precomputed tx databy Antoine Poinsot · 1ed799fb · May 5, 2026 · 1 fileMessage 98 · StrongCritical 87Details
Commit message · Antoine Poinsot

validation: correct lifetime of precomputed tx data

This makes sure `txsdata` always outlives the Script check queue (since local
objects are destructed in reverse order of construction).

This is the root cause for a security vulnerability reported by Cory Fields in
2024 that could be exploited by crafting an invalid block to cause nodes to
read freed memory. The vulnerability was covertly fixed in commit
`492e1f09943fcb6145c21d470299305a19e17d8b`.

See security advisory for CVE-2024-52911 for more details.

98/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
explicit security language
AI analysis · Critical 87/100

This commit fixes a memory safety bug in Bitcoin Core's block validation. When checking a new block, the program creates a queue of script checks that may run on multiple threads in the background. It also precomputes some transaction data used by those checks. Previously, the precomputed data was destroyed before the background check queue finished, so the workers could read memory that had already been freed. An attacker could craft a malicious block to trigger this, potentially causing crashes, memory corruption, or worse. The fix simply moves the precomputed data variable so it is created before the queue and destroyed after it, guaranteeing the data stays alive as long as the checks need it.

Security candidatepsbt: Return std::optional from PrecomputePSBTDataby Ava Chow · c568624f · Apr 29, 2026 · 8 filesMessage 50 · ThinLow 34Details
Commit message · Ava Chow

psbt: Return std::optional from PrecomputePSBTData

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 34/100

This commit changes a Bitcoin Core internal helper function so that it can now report failure when a PSBT (Partially Signed Bitcoin Transaction) is internally inconsistent. Previously, the helper would build transaction precomputation data without checking whether the underlying unsigned transaction could actually be constructed. Now it returns an optional value that callers must check, and they reject or abort the operation if the transaction cannot be valid. This is a defensive hardening change that prevents the code from continuing with malformed PSBTs.

Security candidateReplace PSBT::GetInputUTXO with PSBTInput::GetUTXOby Ava Chow · 092de4f1 · Apr 29, 2026 · 4 filesMessage 65 · AdequateInformational 15Details
Commit message · Ava Chow

Replace PSBT::GetInputUTXO with PSBTInput::GetUTXO

Now that PSBTInput's track their own prevouts, there's no need for a
PSBT global function to fetch input specific data.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit is a straightforward internal code cleanup in Bitcoin Core. It moves a helper function that looks up the previous transaction output (UTXO) for a PSBT input from the whole-transaction object (PartiallySignedTransaction) into the input object itself (PSBTInput). The behavior is unchanged; only the code organization is simplified.

Security candidateImplement PSBTv2 in decodepsbtby Ava Chow · dcc9a3c8 · Apr 29, 2026 · 1 fileMessage 35 · OpaqueInformational 18Details
Commit message · Ava Chow

Implement PSBTv2 in decodepsbt

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 18/100

This commit updates the Bitcoin Core 'decodepsbt' RPC command so it can display the newer PSBT version 2 format. It only changes what information is shown to the user; it does not change how transactions are validated, signed, or broadcast. There is no indication this is a security fix.

Security candidateImplement PSBTv2 AddInput and AddOutputby Ava Chow · 93e339e2 · Apr 29, 2026 · 2 filesMessage 45 · ThinInformational 20Details
Commit message · Ava Chow

Implement PSBTv2 AddInput and AddOutput

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 20/100

This commit finishes implementing the 'AddInput' and 'AddOutput' methods for PSBT version 2 in Bitcoin Core. PSBTs are files used to collaboratively build or sign Bitcoin transactions offline. Previously, adding inputs/outputs to a PSBTv2 would silently fail (return false). The change now properly checks version compatibility, respects the 'modifiable' flags that say whether inputs/outputs may be added, and handles time-lock consistency when new inputs are appended. It is a feature-completion patch with defensive checks, not a fix for an active vulnerability.

Security candidateImplement PSBTv2 fields de/serby Ava Chow · 925161ea · Apr 29, 2026 · 2 filesMessage 45 · ThinLow 28Details
Commit message · Ava Chow

Implement PSBTv2 fields de/ser

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 28/100

This commit adds support for a new version of Partially Signed Bitcoin Transactions (PSBTv2) in Bitcoin Core. It introduces serialization and deserialization code for new PSBTv2 fields, including transaction version, input/output counts, modifiable flags, per-input previous outpoints and locktimes, and per-output amounts and scripts. The commit also adds validation rules to reject malformed or version-inconsistent PSBT data. There is no indication in the commit message or diff that this is a security fix; it appears to be a feature implementation.

Security candidateImplement PSBTv2 field mergingby Ava Chow · ab38c301 · Apr 29, 2026 · 2 filesMessage 35 · OpaqueLow 28Details
Commit message · Ava Chow

Implement PSBTv2 field merging

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 28/100

This commit updates how Bitcoin Core combines two Partially Signed Bitcoin Transactions (PSBTs). It adds checks to prevent merging PSBTs of different versions, propagates failure if any input or output cannot be merged, and copies new PSBTv2-only fields such as sequence numbers, locktimes, and modifiable flags. The change is a correctness and robustness improvement rather than a clear security fix.

Security candidateAdd psbt_version to PSBT RPCs and default to v2by Ava Chow · bcc1dca7 · Apr 29, 2026 · 12 filesMessage 68 · AdequateInformational 24Details
Commit message · Ava Chow

Add psbt_version to PSBT RPCs and default to v2

walletcreatefundedpsbt, createpsbt, converttopsbt, and psbtbumpfee take
a psbt_version argument to set the version of the PSBT that they
produce. The default psbt_version is 2.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 24/100

This commit updates Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) RPC commands so they can produce the newer PSBT version 2 format, and makes version 2 the default. It is a feature and compatibility change, not a fix for an active security vulnerability. The code validates that only versions 0 or 2 can be requested, and updates tests to match the new output structure. There is no indication in the commit that this resolves a disclosed security issue.

Security candidatetest: Tests for PSBT AddInput and AddOutputby Ava Chow · 5bd0579c · Apr 29, 2026 · 1 fileMessage 67 · AdequateInformational 15Details
Commit message · Ava Chow

test: Tests for PSBT AddInput and AddOutput

67/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit only adds new automated tests for existing PSBT (Partially Signed Bitcoin Transaction) helper functions called AddInput and AddOutput. It does not change any production wallet, consensus, or networking code. The tests verify that the functions correctly reject mismatched PSBT versions, duplicate inputs, inputs that violate timelock rules, and additions when the transaction is marked as non-modifiable. There is no indication this commit fixes a security bug or introduces a vulnerability.

Security candidatefuzz: Enforce additional version invariants in PSBT fuzzerby Antoine Poinsot · 470e52a5 · Apr 29, 2026 · 3 filesMessage 60 · AdequateInformational 17Details
Commit message · Antoine Poinsot

fuzz: Enforce additional version invariants in PSBT fuzzer

60/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing boundaryfuzzing or regression evidencesigning or wallet path
AI analysis · Informational 17/100

This commit only changes test/fuzzing code and adds equality operators to internal data structures so the fuzzer can check round-trip behavior of PSBT (Partially Signed Bitcoin Transaction) data. It does not change production transaction handling, consensus rules, or network code. There is no indication it fixes an exploitable vulnerability.

Security candidateUpdate test_framework/psbt.py for PSBTv2by Ava Chow · 863cf47b · Apr 29, 2026 · 2 filesMessage 45 · ThinInformational 15Details
Commit message · Ava Chow

Update test_framework/psbt.py for PSBTv2

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit updates Bitcoin Core's internal test-framework Python helper for Partially Signed Bitcoin Transactions (PSBT) to support the newer PSBT version 2 format. It is a test/development tooling change, not a change to the live Bitcoin network code that validates transactions or consensus rules. There is no indication this fixes a security bug or introduces a vulnerability.

Security candidatetests: Add PSBT unit test for ComputeTimeLockby Ava Chow · b8b6e7f0 · Apr 29, 2026 · 2 filesMessage 55 · ThinInformational 15Details
Commit message · Ava Chow

tests: Add PSBT unit test for ComputeTimeLock

55/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit only adds a new unit test file for an existing PSBT (Partially Signed Bitcoin Transaction) function called ComputeTimeLock. It does not change any production code, wallet logic, or network behavior. There is no security fix or vulnerability being patched here.

Security candidateRestrict joinpsbts to PSBTv0 onlyby Ava Chow · d9cf658e · Apr 29, 2026 · 1 fileMessage 45 · ThinLow 32Details
Commit message · Ava Chow

Restrict joinpsbts to PSBTv0 only

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 32/100

This change updates the Bitcoin Core 'joinpsbts' RPC command so it only accepts PSBT version 0 files. Previously, it could accept newer PSBT versions, which might have led to incorrect or unexpected behavior when combining partially signed transactions. The change adds an explicit version check and rejects non-v0 PSBTs with a clear error message.

Security candidateAdd PSBT::ComputeLockTime()by Ava Chow · 5770dbd3 · Apr 29, 2026 · 2 filesMessage 50 · ThinLow 27Details
Commit message · Ava Chow

Add PSBT::ComputeLockTime()

Function to compute the lock time for the transaction

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 27/100

This commit adds a helper function that calculates when a Bitcoin transaction becomes valid based on time or block height locks inside a Partially Signed Bitcoin Transaction (PSBT). It also makes the existing unsigned-transaction builder use this new calculation instead of always using a simple fallback value. The change appears to be a correctness improvement for PSBT version 2 locktime handling, not an obvious security fix, but it prevents a PSBT from being turned into a transaction when its inputs disagree about whether the lock is based on time or block height.

Security candidateReplace PSBT.tx with PSBT::GetUnsignedTx and PSBT::GetUniqueIDby Ava Chow · 3da0e160 · Apr 29, 2026 · 6 filesMessage 85 · StrongLow 33Details
Commit message · Ava Chow

Replace PSBT.tx with PSBT::GetUnsignedTx and PSBT::GetUniqueID

The global unsigned tx is decomposed into separate fields inside of
PSBT, which mirrors what PSBTv2 will do. However, we still need to get
the global unsigned tx so PSBT::GetUnsignedTx is introduced to do that.
In order to also have a stable unique ID, we also introduce
PSBT::GetUniqueID to replace uses of PSBT.tx.GetHash().

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 33/100

This commit refactors how Bitcoin Core handles Partially Signed Bitcoin Transactions (PSBTs). Previously, a PSBT stored a complete copy of the unsigned transaction. Now, the transaction is broken into separate fields and reconstructed on demand. The change also introduces a stable unique ID for each PSBT. This is primarily a code-cleanup and preparation step for a future PSBT version 2, not a direct fix for an active security bug.

Security candidateAllow specifying PSBT version in constructorby Ava Chow · b39c86ae · Apr 29, 2026 · 3 filesMessage 60 · AdequateInformational 19Details
Commit message · Ava Chow

Allow specifying PSBT version in constructor

The constructor will create the PSBT of the specified version, as long
as it is 0 or 2.

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 19/100

This change lets the PSBT constructor choose between version 0 or version 2 when creating a new Partially Signed Bitcoin Transaction. It also fixes a small consistency bug in the joinpsbts RPC where newly created PSBTs during joining/shuffling were always version 0, even when the inputs being joined were version 2. There is no direct evidence this is a security fix, and the new version parameter is guarded by an assertion that only allows 0 or 2.

Security candidatepsbt: Change default psbt version to 2by Ava Chow · e0e4dbde · Apr 29, 2026 · 2 filesMessage 45 · ThinInformational 21Details
Commit message · Ava Chow

psbt: Change default psbt version to 2

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 21/100

This commit changes the default version number used when Bitcoin Core creates new Partially Signed Bitcoin Transactions (PSBTs) from version 0 to version 2. PSBT is a standard format for passing around unsigned or partially signed transactions between wallets and signers. The change itself is a one-line default-value update plus a test that confirms new PSBTs are created as version 2. It does not fix a memory corruption bug, crash, or remote-code-execution flaw, and there is no evidence in the commit or supplied references that it addresses a known security incident.

Security candidatetest: Test merging implicit PSBTv0 with explicit PSBTv0by w0xlt · 9fa4076b · Apr 29, 2026 · 1 fileMessage 72 · AdequateInformational 15Details
Commit message · w0xlt

test: Test merging implicit PSBTv0 with explicit PSBTv0

72/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit adds a new test case to Bitcoin Core's functional test suite. It verifies that two PSBT (Partially Signed Bitcoin Transaction) version 0 encodings—one with the version field explicitly set to 0 and one with it omitted—can be merged together correctly. There is no code change to the actual Bitcoin Core node software, only a new regression test.

Security candidateHave PSBTInput and PSBTOutput know the PSBT's versionby Ava Chow · 990b084f · Apr 29, 2026 · 4 filesMessage 50 · ThinInformational 18Details
Commit message · Ava Chow

Have PSBTInput and PSBTOutput know the PSBT's version

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 18/100

This commit is a small internal refactor in Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) handling. It makes each PSBT input and output aware of which PSBT version it belongs to, currently hard-coded to version 0. The change does not fix a known bug or vulnerability by itself; it appears to lay groundwork for future PSBT version support. There is no evidence in the commit or supplied references that this is a security patch.

Security candidatepsbt: Use PSBTInput and PSBTOutput fields instead of accessing global txby Ava Chow · 82c9fe31 · Apr 29, 2026 · 8 filesMessage 73 · AdequateInformational 19Details
Commit message · Ava Chow

psbt: Use PSBTInput and PSBTOutput fields instead of accessing global tx

PSBTInput now has the previous txid and output index, and PSBTOutput has
the amount and script. We no longer need to access the global unsigned
tx for these fields.

Additionally, we can change iterating tx.vin and tx.vout to psbtx.inputs
and psbtx.outputs.

This is in prepration for use with PSBTv2 where the global unsigned tx
will not exist.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 19/100

This commit is a code cleanup in Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) handling. It changes internal code to read input and output details from the PSBT data structures themselves rather than from the global unsigned transaction. The stated goal is to prepare for a future PSBT version (PSBTv2) where the global unsigned transaction may not exist. There is no direct security fix here, but any inconsistency between the PSBT fields and the global transaction could, in principle, lead to wrong analysis or signing behavior. The patch appears to keep behavior equivalent by using the same data through a different path.