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.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
This change makes three Bitcoin command-line tools (bitcoin-tx, bitcoin-util, and bitcoin-wallet) automatically pick the fastest SHA-256 hashing implementation available on the computer, such as hardware-accelerated versions on modern CPUs…
This is a one-line fix in Bitcoin Core's network code. It changes how the size of a list of block headers is converted to a signed integer inside a loop. Previously, if the list was empty, the conversion could trigger undefined-behavior wa…
UndefinedBehaviorSanitizer integer sanitizer warning addressedImplicit signed/unsigned conversion in loop counterUnsigned integer wraparound on empty vector size
This change fixes a Bitcoin Core wallet bug where the `importprunedfunds` RPC command could only re-import transactions that sent money to the wallet, not transactions that spent money from it. After this fix, both incoming and outgoing tr…
Logic bug in wallet transaction import scopeIncorrect balance possible after removing and re-importing spending transactionFix routes import through existing involvement check (IsMine + IsFromMe)
This commit adds a new Bitcoin Core wallet startup option called -maxfeerate. It lets users set a maximum fee rate (fee per unit of transaction size) that the wallet will allow when creating or broadcasting transactions. Previously, the wa…
New wallet startup option -maxfeerate to cap transaction fee rateNew transaction error type MAX_FEE_RATE_EXCEEDEDBroadcastTransaction now checks both max absolute fee and max fee rate
This Bitcoin Core update fixes a wallet-signing quirk. When a user chose the SIGHASH_SINGLE signature mode, an input that had no matching output index would sign essentially nothing meaningful. That signature could then stay valid even if …
Funds-redirection footgun from SIGHASH_SINGLE signatures with no committed outputInconsistent guard between SignTransaction and SignPSBTInput pathsFix centralizes the guard in the low-level signature creator to cover future signing paths
This change updates Bitcoin Core's I2P (Invisible Internet Project) privacy network settings to use newer, stronger encryption for the published 'leaseset' that describes how other peers can contact a node. The old setting included ElGamal…
Cryptographic algorithm update (ElGamal to MLKEM-768)Use of I2P 'legacy' encryption type removedConfiguration-only change in network privacy layer
This change fixes a labeling bug in Bitcoin Core's first-run disk-space warning. The estimate was stored in GiB (binary gigabytes, 1024-based) but displayed as GB (decimal gigabytes, 1000-based), and for pruned nodes it showed the full-cha…
This is a wallet bug, not a theft or remote-code bug. When a Bitcoin Core user turns on the optional 'avoidpartialspends' or 'avoid_reuse' setting, an output group rejected during coin selection could be counted twice as 'discarded.' That …
Logic error causing double-counting of discarded UTXO groupsCan trigger false 'insufficient funds' failure in coin selectionAffects avoidpartialspends / avoid_reuse wallets only
This is a documentation-only fix in a tutorial file. It changes two shell examples from using '>>' (append to file) to '>' (overwrite file). If a user followed the old instructions and ran the same command twice, the file would contain two…
No security signal: change is limited to documentationNo code changes to Bitcoin Core binaries, RPC, wallet, or consensus logicNo cryptographic, network, or privilege-boundary implications
This is a large internal code reorganization (refactor) in Bitcoin Core. It creates a new BlockTemplateManager class that takes over block-template creation, block submission, and tip-waiting helpers that were previously spread across seve…
Large refactor touching mining, RPC, interfaces, and test shutdown pathsNew object lifetime dependency: BlockTemplateManager holds references to mempool, chainman, and notifications; explicit reset ordering added in Shutdown/InitAndLoadChainstate/test setupsRemoval of early-init node.mining interface; BlockTemplateManager is now created after chainstate load, with a comment that it must exist before setChainstateLoaded(true) unblocks IPC waiters
This commit adds the first implementation of BIP352 (Silent Payments) to Bitcoin Core. Silent Payments are a new type of privacy-preserving Bitcoin address that lets someone receive payments without publicly revealing a fixed address. The …
New cryptographic feature implementation (BIP352 Silent Payments)Extensive use of secp256k1 silentpayments moduleInput public key extraction from P2PKH, P2WPKH, P2SH-P2WPKH, and P2TR inputs
This update fixes a wallet database loading bug where a damaged or tampered Bitcoin wallet file could cause the program to read past the end of a stored extended public key (xpub). The patch makes the loader check the stored xpub length be…
Out-of-bounds read in wallet descriptor cache deserializationASan container-overflow triggered by malformed on-disk recordMissing length validation between record size prefix and fixed-size decoder
This commit adds a new wallet RPC called listrawtransactions to Bitcoin Core. It is a feature addition that lets users list every transaction their wallet knows about, including internal transfers and consolidations that the existing listt…
No security-relevant bug fix or vulnerability patch is present in the diff.New RPC exposes additional wallet transaction metadata, but only to callers already authorized for wallet RPCs.Code is a refactor of existing gettransaction logic into shared helpers; no new cryptographic, network, or consensus code.
This Bitcoin Core update fixes several wallet bugs where a failed database write could leave a wallet in an inconsistent state. For example, encrypting a wallet or changing its passphrase could appear to succeed in memory while the change …
Atomicity fix for encryption state and descriptor key persistenceFailure to persist master key during encryption previously reported success in memoryPassphrase change could activate new passphrase only in memory
This commit only changes Bitcoin Core's internal functional test code. It replaces hard-coded test keys and addresses with ones generated from a new test helper class, and unifies how tests tell nodes not to create a default wallet. There …
This commit only adds a new automated test to Bitcoin Core. It checks that when two partially-signed Bitcoin transactions (PSBTs) are combined, any custom 'unknown' data fields attached to them are preserved correctly. There is no change t…
This is a Bitcoin Core wallet maintenance patch. It speeds up a wallet function that checks whether a descriptor already exists by caching a hash of the descriptor's canonical text, instead of rebuilding that text every time. It also tidie…
No security-relevant signal in commit message or diffChange is described as performance improvement and code cleanupBackwards-compatibility test notes a known miniscript wallet loading incompatibility between v31.0/v31.1 and other versions, but this is a documented compatibility quirk, not a vulnerability
This is a documentation-only fix for Bitcoin Core's machine-readable RPC help data. It changes several default values from literal strings to 'hint' labels (because the real default depends on context) and corrects one boolean default from…
OpenRPC schema/default mismatch correctionRPC help metadata type correction (string 'false' to boolean false)No executable code path changes
This commit fixes documentation metadata for six Bitcoin Core RPC arguments. It changes how default values are described so that automatically generated API docs and schemas are accurate. The actual behavior of the software when running is…
No runtime code changesOnly RPC help/schema metadata modifiedVendor explicitly states runtime behavior is unchanged
This commit fixes a bug in Bitcoin Core's MuHash3072 cryptographic code where dividing a MuHash object by itself (x /= x) produced the wrong mathematical result. The fix is straightforward: the code now saves the divisor's numerator before…
Cryptographic correctness bug in MuHash3072 division operatorSelf-aliasing in operator/= produces incorrect 1/D result instead of empty setNo production code path identified that triggers self-division
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
Security candidatepsbt: add tx input and output fields in PSBTInput and PSBTOutputby Ava Chow · 9671aa08 · Apr 29, 2026 · 4 filesMessage 73 · AdequateInformational 19Details
Commit message · Ava Chow
psbt: add tx input and output fields in PSBTInput and PSBTOutput
PSBTInput should be aware of the previous txid, output index, and sequence numbers for inputs, extracting them from the global unsigned tx.
PSBTOutput should be aware of the output amount and script, extracting them from the global unsigned tx.
This prepares for PSBTv2 where these fields are serialized.
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 small internal refactor of how Bitcoin Core builds Partially Signed Bitcoin Transactions (PSBTs). It makes each PSBT input and output remember its corresponding transaction details (previous transaction ID, output index, sequence number, amount, and script) directly, instead of only storing them inside the global unsigned transaction. The change prepares the code for a future PSBT version (PSBTv2) where these fields are stored separately. There is no obvious security bug in the diff itself, but it touches serialization and RPC code paths that handle user-provided transaction data.
When decomposing a transaction into a PSBTv2, the tx version and locktime need to be stored in their respective global fields. Add those fields and fill them when constructing.
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 19/100
This commit adds two missing data fields to Bitcoin's PSBTv2 format support: the transaction version and the locktime. These values are now stored in the correct global fields when a transaction is converted into a PSBTv2. It appears to be a correctness/completeness fix for the newer PSBT standard rather than a fix for an active security vulnerability.
✓ Descriptive subject✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 18/100
This commit is a small code cleanup: it adds a helper function called GetOutPoint to PSBTInput and replaces several direct accesses to transaction input data with calls to that helper. There is no change in behavior or security fix visible in the diff. It appears to be a refactoring to make the code easier to maintain.
Security candidategui: Store PSBT in std::optional in PSBTOperationsDialogby Ava Chow · f926c326 · Apr 29, 2026 · 2 filesMessage 77 · AdequateInformational 16Details
Commit message · Ava Chow
gui: Store PSBT in std::optional in PSBTOperationsDialog
Use std::optional to store the PSBT to avoid having a default constructed PSBT
77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Explains rationale or failure mode
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 16/100
This is a small code-quality change in Bitcoin Core's graphical wallet interface. It switches the internal storage of a partially-signed Bitcoin transaction (PSBT) from a plain object to an optional wrapper, so the code no longer keeps a default/empty PSBT sitting around before one is actually loaded. The change itself does not fix a known crash or vulnerability, but it removes a class of potential bugs where an uninitialized PSBT could accidentally be used.
Security candidatepsbt: Fill hash preimages and taproot builder from SignatureDataby Ava Chow · 0cb884e6 · Apr 29, 2026 · 1 fileMessage 50 · ThinLow 32Details
Commit message · Ava Chow
psbt: Fill hash preimages and taproot builder from SignatureData
Filling these fields was missing.
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 32/100
This commit fixes a gap in Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) handling. When converting signature data into a PSBT input or output, several pieces of information—hash preimages for certain script operations and the taproot script tree builder—were not being copied over. Missing preimages could prevent a PSBT from being finalized correctly, and missing the taproot builder could prevent proper analysis or signing of taproot outputs. It is a correctness fix in wallet/transaction code rather than a remote-exploitable vulnerability.
Security candidatetest: PSBTs should roundtrip through RPCs that do nothingby Ava Chow · 88384180 · Apr 29, 2026 · 1 fileMessage 72 · AdequateInformational 15Details
Commit message · Ava Chow
test: PSBTs should roundtrip through RPCs that do nothing
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 only adds a new automated test to Bitcoin Core. It checks that certain PSBT (Partially Signed Bitcoin Transaction) RPC commands, when called in a way that should make no meaningful change, return the exact same PSBT they were given. There is no change to production code, no bug fix, and no security patch.
psbt: Refactor duplicate key lookup and size checks
Every key has a duplicate key lookup check, and many keys have fixed size checks. These can be refactored to reduce code duplication.
Co-Authored-By: David Gumberg <davidzgumberg@gmail.com>
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 20/100
This commit is a code cleanup in Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) handling. It moves duplicate-key detection and fixed-size checks into shared helpers so the same logic is not repeated dozens of times. The behavior is intended to stay the same; only error messages change in a few test cases. There is no indication this fixes a security bug.
Security candidatetest: construct psbt with unknown field programmaticallyby David Gumberg · 00187750 · Apr 29, 2026 · 2 filesMessage 72 · AdequateInformational 15Details
Commit message · David Gumberg
test: construct psbt with unknown field programmatically
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 only changes test code for Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) handling. It removes one hard-coded test vector from a JSON file and adds a helper function so tests can build PSBTs with made-up unknown fields on the fly. There is no change to production wallet or node code, so it cannot directly affect live funds, network behavior, or introduce a runtime vulnerability.
AI review queuedbench: Utilize setup() for WalletLoading and use a real databaseby Ava Chow · 57820c47 · Apr 29, 2026 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Ava Chow
bench: Utilize setup() for WalletLoading and use a real database
Instead of making a mock database and duplicating it for the benchmark, use a real database. Also use setup() to avoid measuring the overhead in the benchmark.
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 or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This change only modifies a benchmark test file. It swaps a fake/mock database for a real SQLite database when measuring how fast wallet loading runs, and moves wallet setup work outside the timed portion so the benchmark is more accurate. There is no change to production wallet code, network behavior, or user-facing functionality, and no security issue is evident.
AI review queuedbench: Use setup() in WalletMigration to prepare the legacy walletby Ava Chow · 9a7604fd · Apr 29, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Ava Chow
bench: Use setup() in WalletMigration to prepare the legacy wallet
WalletMigration needs a new wallet with legacy records for each run of the benchmark. This can be done in setup() rather than duplicating the records of an initial wallet.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This is a small internal cleanup of a Bitcoin Core benchmark test. It moves the creation of a fake legacy wallet from the main benchmark body into a setup() routine so the benchmark can be repeated cleanly. It does not change any production wallet code, network rules, or user-facing behavior, and it introduces no security issue.
AI review queuedbench: Utilize setup() in WalletEncrypt to create the encryption walletby Ava Chow · 426a94e7 · Apr 29, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Ava Chow
bench: Utilize setup() in WalletEncrypt to create the encryption wallet
WalletEncrypt needs an unencrypted wallet in order for the benchmark to encrypt a wallet. This was previously achieved by duplicating the contents of an initial wallet for each run of the benchmark. We can instead use setup() to unload the previously loaded wallet and then create a new wallet with unencrypted keys.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This is a benchmark-only code cleanup. It changes how a performance test creates a fresh wallet before each encryption run, replacing a database-copy approach with a setup() function that creates a new wallet each time. There is no change to production wallet encryption behavior and no security issue.
AI review queuedbench: Utilitze setup() in WalletBalance for marking caches dirtyby Ava Chow · d672455d · Apr 29, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Ava Chow
bench: Utilitze setup() in WalletBalance for marking caches dirty
WalletBalance benchmarks the balance computation function and should exclude the setup step of (optionally) marking caches as dirty. Instead, that is moved into setup().
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This is a benchmark-only change. It moves a 'mark cache dirty' step out of the timed portion of a wallet balance performance test so the benchmark measures only the balance calculation itself. There is no change to production wallet code, consensus logic, networking, or any user-facing behavior.
AI review queuedbench: Utilize setup() in WalletCreate to cleanup previous walletsby Ava Chow · 61412ef8 · Apr 29, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Ava Chow
bench: Utilize setup() in WalletCreate to cleanup previous wallets
The WalletCreate benchmark should only be for creating a wallet and exclude the unloading of the newly created wallet. Instead, unloading can be done in setup() and after the benchmark completes.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This is a small code-quality change to a benchmark test that measures how long it takes to create a Bitcoin wallet. It moves wallet cleanup from inside the timed loop to a setup/teardown phase so the benchmark only measures wallet creation. There is no user-facing behavior change and no security relevance.
AI review queuedwallet: Load everything into DescSPKM on constructionby Ava Chow · 80b0c259 · Apr 29, 2026 · 7 filesMessage 73 · AdequateLow 26Details
Commit message · Ava Chow
wallet: Load everything into DescSPKM on construction
Instead of creating a DescSPKM that is then progressively loaded, we should instead create it all at once in a factory function when loading.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 26/100
This Bitcoin Core commit refactors how descriptor wallets are loaded from disk. Instead of creating an empty wallet key manager and then gradually adding keys and cache data to it, the code now gathers all the data first and creates the key manager in one go. The change also adds a safety check that rejects wallets containing both unencrypted and encrypted keys, which previously could have coexisted during incremental loading. There is no direct evidence in the commit that this fixes an active exploit, but the stricter loading model removes a class of potential consistency bugs.
AI review queuedfuzz: Skip adding descriptor to wallet if it cannot be expandedby Ava Chow · 6538f691 · Apr 29, 2026 · 1 fileMessage 60 · AdequateInformational 19Details
Commit message · Ava Chow
fuzz: Skip adding descriptor to wallet if it cannot be expanded
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
fuzzing or regression evidencesigning or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 19/100
This is a small hardening change to a fuzz test (automated randomized testing) for Bitcoin Core's wallet descriptor handling. It adds a check that a parsed wallet descriptor can be 'expanded' (converted into actual output scripts) before the test proceeds to add it to a wallet. This prevents the fuzzer from creating wallet state with descriptors that parse but cannot actually be used, which could cause later test steps to hit unexpected failures or assertions. It is a test-only fix and does not change production wallet behavior.
AI review queuedtest: wallet: Check that loading wallet with both unencrypted and encrypted keys fails.by David Gumberg · 8be5ee55 · Apr 29, 2026 · 1 fileMessage 72 · AdequateInformational 18Details
Commit message · David Gumberg
test: wallet: Check that loading wallet with both unencrypted and encrypted keys fails.
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 or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 18/100
This commit adds a new automated test to Bitcoin Core. The test checks that the software correctly refuses to open a wallet that has been corrupted so that it contains both encrypted and unencrypted copies of the same key. It does not change any production wallet code; it only adds a regression test for an already-existing safety check.
AI review queuedwallet: Consolidate generation setup callers into one functionby Ava Chow · cd912c4e · Apr 29, 2026 · 2 filesMessage 50 · ThinInformational 12Details
Commit message · Ava Chow
wallet: Consolidate generation setup callers into one function
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 12/100
This is a routine internal code cleanup in Bitcoin Core's wallet module. It merges several places that set up a wallet's address-generation seed/descriptors into a single helper function called SetupWalletGeneration(). There is no indication this fixes a security bug; it appears intended to make the code easier to maintain and to avoid duplicating logic when creating or encrypting wallets.
AI review queuedrefactor: wallet: Don't reuse WALLET_BLANK flag for born-encrypted wallets.by David Gumberg · f713fd17 · Apr 29, 2026 · 3 filesMessage 97 · StrongInformational 13Details
Commit message · David Gumberg
refactor: wallet: Don't reuse WALLET_BLANK flag for born-encrypted wallets.
With the split between LoadWallet and CreateNew, it's no longer necessary to utilize the blank flag to prevent the wallet from having descriptors automatically being generated. Instead, CreateNew can take a separate parameter to indicate whether the wallet is to be born encrypted and therefore should not have any keys generated.
97/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 13/100
This is a code cleanup (refactor) in Bitcoin Core's wallet creation logic. Previously, the software temporarily marked encrypted wallets as 'blank' to prevent keys from being generated before encryption, then removed that flag afterward. The change makes the code more explicit by passing a separate 'born_encrypted' parameter instead of reusing the blank-wallet flag. There is no security vulnerability visible in the diff.
AI review queuedtest: wallet: Constructing a DSPKM that can't TopUp() throws.by David Gumberg · 451fdd26 · Apr 29, 2026 · 2 filesMessage 72 · AdequateInformational 17Details
Commit message · David Gumberg
test: wallet: Constructing a DSPKM that can't TopUp() throws.
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 or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 17/100
This commit is a test-only change for Bitcoin Core's wallet code. It moves two internal type definitions to a more private scope and adds a unit test verifying that creating a certain kind of watch-only descriptor wallet (one using hardened derivation without private keys) throws an error because it cannot generate new addresses. There is no runtime bug fix or exploit here; it improves test coverage and code encapsulation.
AI review queuedwallet: Setup new autogenerated descriptors on constructionby Ava Chow · 32946e02 · Apr 29, 2026 · 3 filesMessage 73 · AdequateInformational 21Details
Commit message · Ava Chow
wallet: Setup new autogenerated descriptors on construction
Instead of having a caller use SetupDescriptorGeneration, just have a constructor that takes those arguments and sets up the descriptor with the autogenerated key.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 21/100
This is a small internal code cleanup in Bitcoin Core's wallet. It moves the setup of newly generated single-signature descriptors into a dedicated factory-style constructor and tightens some safety checks. There is no obvious user-facing bug or direct exploit here, but the change removes a redundant encryption step and changes when a 'decryption checked' flag is set, which could have subtle wallet-initialization implications.
AI review queuedwallet migration, fuzz: Migrate hd seed onceby Ava Chow · 0301c758 · Apr 29, 2026 · 3 filesMessage 78 · AdequateLow 32Details
Commit message · Ava Chow
wallet migration, fuzz: Migrate hd seed once
If a wallet has multiple HD chains that have the same seed, we should only migrate that seed a single time.
This fixes a fuzz crash that occurs once the return value of AddDescriptorKeyWithDB is checked during descriptor construction.
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidencesigning or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Low 32/100
This commit fixes a bug in Bitcoin Core's wallet migration logic where the same HD (hierarchical deterministic) wallet seed could be processed more than once if it appeared in both the active and inactive HD chain lists. The duplicate processing could cause a crash during migration, which was discovered through automated fuzz testing. The fix uses a set data structure to ensure each unique seed is only migrated once. There is no direct evidence in the commit that this is exploitable by an attacker to steal funds or compromise the network; it appears to be a reliability/correctness fix for a fuzz-discovered crash.
AI review queuedwallet: Construct ExternalSignerSPKM with the new descriptorby Ava Chow · e20aaff7 · Apr 29, 2026 · 3 filesMessage 73 · AdequateInformational 15Details
Commit message · Ava Chow
wallet: Construct ExternalSignerSPKM with the new descriptor
Instead of constructing then setting the descriptor with SetupDescriptor, just pass in that descriptor to the constructor.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This is a small internal code cleanup in Bitcoin Core's wallet module. It changes how an external-signer wallet manager object is created so that its descriptor is passed directly through the constructor rather than being set afterward via a separate SetupDescriptor method. There is no user-facing behavior change and no security fix.
AI review queuedwallet: include keys when constructing DescriptorSPKM during importby Ava Chow · aa4f7823 · Apr 29, 2026 · 3 filesMessage 65 · AdequateLow 29Details
Commit message · Ava Chow
wallet: include keys when constructing DescriptorSPKM during import
When importing a descriptor, all of the descriptor data should be provided at the same time in the constructor.
65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 29/100
This Bitcoin Core wallet patch changes how private keys are added when a user imports or migrates to a descriptor-based wallet. Previously, keys were added to the descriptor manager in a separate step after creation. The patch bundles the keys into the manager's constructor or update call so all descriptor data is provided at once. The commit message frames this as a code-quality fix, not a security fix. There is no direct evidence in the diff or commit message that this closes an exploitable vulnerability, but it does reduce a window where the wallet state could be inconsistent.
Installing tools in the dockerfile using `COPY --from` is better , but not all tools we use publish an OCI image to a non-docker.io registry.
As we are frequently rate-limited from docker.io, only install tools which publish to another registry, e.g. ghcr.io.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This commit only updates a README file in the test/lint directory. It adds a sentence pointing readers to another file for dependency installation instructions. There is no code change and no security relevance.
.python-version always matches the minimum supported Python version. It's main purpose is to catch accidental use of too modern syntax in scripts and functional tests.
We (currently) don't specify a minimum patch version, so it's not necessary to do so here. The minor verion is enough.
This also avoids requiring users to keep a potentially unsafe old patch version installed.
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
access control
AI analysis · Informational 15/100
This commit changes a single configuration file used by developers so it only specifies the broad Python version (3.10) instead of an exact patch release (3.10.14). The stated goal is to avoid forcing developers to keep an old, potentially insecure Python patch release installed. It is a tooling/development hygiene change, not a fix for an exploitable vulnerability in Bitcoin Core itself.