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 commit only changes tests and clarifies a public comment. It does not alter the actual authentication behavior of the btcd RPC client. The code already only suppresses the internally generated Basic auth header when DisableAuth is tru…
No functional code change; only tests and commentsComment clarification that DisableAuth only suppresses generated Basic auth, not caller-provided Authorization headersTests now cover WebSocket handshake, cookie bypass, and caller-provided headers
This commit only adds new unit tests for an existing feature. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The tests verify that an existing option called DisableAuth correctl…
This commit fixes a deadlock risk in btcd's new Bitcoin v2 transport handshake. Previously, the responder waited until it had received the initiator's full 64-byte key before doing any work, which could cause both sides to sit waiting for …
BIP324 handshake deadlock avoidanceCPU admission lease split to prevent resource exhaustion / lock holding across network I/OResponder now sends key material before full initiator key is received
This commit changes how btcd reads base64-encoded PSBT (Partially Signed Bitcoin Transaction) data. Previously, the code read the entire base64 input into memory before decoding, and it wrongly applied the Bitcoin P2P wire message size lim…
Removes an incorrect size bound that caused base64 PSBT parsing to reject valid large packets (denial-of-service / interoperability issue)Switches from full in-memory base64 decode to incremental streaming, reducing peak memory for large base64 PSBTsRetains strict base64 alphabet checks and rejects trailing data after the PSBT packet
This commit fixes a class of crash bugs in btcd's PSBT (Partially Signed Bitcoin Transaction) handling for Taproot transactions. Previously, if certain Taproot-related lists contained a nil (empty) entry, the code would panic when trying t…
nil-pointer dereference / panic prevention in Taproot PSBT finalizernil-pointer dereference / panic prevention in PSBT serializationinput validation added before sort.Slice and pointer dereference
This commit fixes two problems in the way btcd reads Partially Signed Bitcoin Transactions (PSBTs). First, the parser could hang forever when reading from a network connection or pipe because it tried to read one extra byte to check for le…
Denial-of-service via blocking read on open stream (potential infinite hang)Denial-of-service via unbounded memory allocation on base64 input before validationStrict parsing hardening for PSBT base64 decoding
This change tightens how a Bitcoin PSBT library extracts final witness data when turning a partially-signed transaction into a finished transaction. Previously, extra bytes after the declared witness stack were silently ignored. Now the li…
strict parsing of serialized witness datarejection of trailing bytes in PSBT final script witnesspotential malleability / ambiguity reduction in PSBT extraction
This commit adds a new test to the btcd PSBT (Partially Signed Bitcoin Transaction) library. The test checks that when extracting a final Bitcoin transaction from a PSBT, the library rejects a final witness value that has extra trailing by…
Strict parsing of final witness data to reject malformed/trailing bytesPrevents creation of transactions with non-standard witness encodingTest-only commit implies behavior enforcement elsewhere in the codebase
This commit fixes a bug in how btcd parses Schnorr (BIP-340) digital signatures. The code was supposed to reject signatures whose 's' number was larger than the allowed group order, but instead it silently wrapped the value around (modulo …
BIP-340 signature parsing non-compliancesilent modulo reduction of s componentsignature malleability risk from non-canonical encodings
This commit fixes a memory-usage issue, not a security vulnerability. When reading PSBT data, the code was keeping a pointer to a large 4 MiB internal memory block even for tiny scripts. The patch copies the small script into its own compa…
This commit only adds a new test case. It does not change any production code. The test checks that the PSBT parser rejects files that have extra bytes after a valid PSBT packet. Because no code behavior is changed, this commit by itself d…
Test-only commitNo production code changesTests input-validation behavior (trailing data rejection)
This change tightens how base64-encoded PSBT (Partially Signed Bitcoin Transaction) data is decoded. Previously, the decoder could silently ignore extra whitespace or unexpected characters in the base64 stream. Now it rejects anything that…
Strict input validation added for base64 decodingRejection of whitespace/newlines inside base64 payloadUse of strict base64 decoder to enforce RFC4648 padding rules
This commit only adds a new unit test that checks whether the MuSig2 partial signature decoder correctly rejects empty or too-short inputs. It does not change any production code, so by itself it cannot introduce or fix a security vulnerab…
This commit only adds new test code for the PSBT (Partially Signed Bitcoin Transaction) package. It does not change any production code. The tests verify that WitnessUtxo fields are parsed strictly and correctly, including rejecting extra …
Strict parsing tests for WitnessUtxo transaction outputsRejection of trailing data after serialized txOutCorrect handling of multi-byte CompactSize script lengths
This commit only adds a new test file. It does not change any production code. The test checks that the PSBT parser rejects transaction fields that have extra trailing bytes. Because no actual parser logic is modified, this commit by itsel…
Regression test added for strict parsing of transaction-valued PSBT fieldsNo production code changes
This commit only adds new test code to check that the PSBT (Partially Signed Bitcoin Transaction) parser rejects malformed base64 input such as whitespace, bad padding, or extra bytes. It does not change the actual parser logic. The tests …
strict base64 decoding validationPSBT packet format hardeningrejection of non-canonical base64 input
This change makes the PSBT (Partially Signed Bitcoin Transaction) parser reject files or data that have extra bytes after the end of a valid PSBT. Previously, extra trailing data was silently ignored, which could let an attacker hide malic…
Parser no longer ignores trailing bytesCould prevent smuggling of extra data inside PSBT containersCould prevent canonicalization attacks where different byte sequences parse to the same structure
This commit fixes a bug in the MuSig2 multi-signature code where reading a partial signature from an input stream could fail silently. Previously, if the stream ended early or had a read error, the function would return 'no error' as if th…
Silent failure in cryptographic decode pathPartial signature scalar left uninitialized on read errorMuSig2 signing correctness dependency
This commit tightens how a Bitcoin-related library reads transaction outputs stored inside PSBT (Partially Signed Bitcoin Transaction) data. Previously, the code read the output value and script in a loose, hand-rolled way that ignored ext…
Strict canonical parsing of serialized transaction outputsRemoval of hand-rolled length handling that ignored script length byteAddition of full-consumption check on parsed witness UTXO data
This commit adds a new helper function to the PSBT (Partially Signed Bitcoin Transaction) package that checks whether a data reader still has leftover bytes after parsing. Leftover bytes could mean a malformed or malicious PSBT file was no…
New validation helper for trailing/leftover data in a binary parserLocated in PSBT parsing utilities, an area where malformed input handling mattersNo caller added in this commit, so defensive effect is not yet active
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
Security candidatebtcutil: zero range-check scalar before returning from DecodeWIFby Lrifton92 · f10224dd · Jun 24, 2026 · 1 fileMessage 86 · StrongLow 30Details
Commit message · Lrifton92
btcutil: zero range-check scalar before returning from DecodeWIF
Wipe the secp256k1 scalar used for the [1, N-1] range validation as soon as DecodeWIF returns, so the decoded private key value does not linger in this local after use. Addresses review feedback on #2545.
86/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
secret or key material
AI analysis · Low 30/100
This commit adds a cleanup step in the function that decodes Bitcoin private keys from Wallet Import Format (WIF). It ensures a temporary mathematical value used to check the key is valid gets wiped from memory right after use, so the private key value does not linger in that temporary variable. This is a defensive memory-hygiene improvement rather than a fix for an active remote attack.
btcutil: reject out-of-range private keys in DecodeWIF
DecodeWIF did not validate that the decoded private key falls within the valid range [1, N-1] for a secp256k1 private key. The raw 32-byte key material was passed straight to btcec.PrivKeyFromBytes, which reduces the scalar modulo the group order N and clamps to zero, returning no error.
As a result, a WIF encoding a private key of zero, the group order N, or any value >= N was silently accepted. For keys >= N this is particularly dangerous: DecodeWIF returned a private key that differs from the one actually encoded in the WIF (e.g. a WIF for N+5 decoded to the key 5), so an application importing such a WIF would obtain a valid-looking but wrong key pair, with no indication that anything was off. This is also inconsistent with hdkeychain.NewKeyFromString in the same package, which already rejects private keys outside [1, N-1].
Validate the range using a ModNScalar (constant time): SetByteSlice reports an overflow when the value is >= N, and IsZero covers the zero key. Out-of-range keys now return ErrMalformedPrivateKey.
Add regression test cases (zero, N, and N+5) to TestEncodeDecodeWIF.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
secret or key materialmemory safetydefensive validationfuzzing or regression evidenceconstant-time or timing behavior
AI analysis · High 72/100
This commit fixes a bug in how btcd decodes Bitcoin private keys stored in the common Wallet Import Format (WIF). Previously, the software silently accepted invalid private keys, including the all-zero key and keys larger than the allowed secp256k1 group order. For keys larger than the allowed maximum, the library would quietly reduce the value modulo the group order, returning a different, valid-looking private key than the one actually encoded in the WIF. This could cause a wallet or application to import the wrong key without any warning, potentially leading to loss of funds or unexpected addresses. The fix now rejects these out-of-range keys and returns an error instead.
Security candidatepsbt: reject nil taproot leaf scriptsby Julio Cesar · 1a4dea6a · Jun 3, 2026 · 2 filesMessage 45 · ThinLow 36Details
Commit message · Julio Cesar
psbt: reject nil taproot leaf scripts
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 36/100
This commit adds a safety check in btcd's PSBT (Partially Signed Bitcoin Transaction) handling code. Previously, if a taproot leaf script entry was accidentally set to nil (empty/missing), the code could crash with a panic when trying to sort or encode the PSBT. The fix now rejects nil entries with a clear error message instead of crashing. This is a defensive hardening change rather than a remote exploit, but it prevents a denial-of-service-style crash for applications that process untrusted PSBTs.
Security candidatemulti: pin new v2 submodule tags and bump to v0.26.0-beta.rc1by Olaoluwa Osuntokun · fdad1fab · May 15, 2026 · 18 filesMessage 81 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun
multi: pin new v2 submodule tags and bump to v0.26.0-beta.rc1
In this commit, we strip all of the local `replace ... => ../...` directives that were introduced as part of #1825 (the v2 module restructuring), now that proper tags exist for every freshly carved-out submodule. Every in-tree go.mod is pinned to the newly published tags: chainhash/v2.0.0, wire/v2.0.0, chaincfg/v2.0.0, address/v2.0.0, txscript/v2.0.0, btcutil/v2.0.0, psbt/v2.0.0, and btcec is bumped to v2.5.0 since it now depends on chainhash/v2 (previously chaincfg/chainhash).
While here, we also unify the Go toolchain to 1.25 across every submodule so the workspace resolves a consistent set of language features.
Finally, we bump the main btcd version to v0.26.0-beta.rc1 in preparation for the upcoming release candidate.
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundaryaccess controlsigning or wallet path
AI analysis · Informational 15/100
This is a routine release-preparation commit. It removes temporary local path overrides in Go module files, pins submodules to newly published version tags, bumps one dependency version (btcec to v2.5.0), unifies the Go toolchain version to 1.25, and updates the project's own version number. There are no code logic changes and nothing in the commit suggests a security fix or vulnerability.
Security candidatemulti: use new v2 modules everywhereby Oliver Gugger · dccea8fe · May 15, 2026 · 169 filesMessage 45 · ThinInformational 15Details
Commit message · Oliver Gugger
multi: use new v2 modules everywhere
45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
seed or entropy pathsigning or wallet pathboot or update path
AI analysis · Informational 15/100
This is a large, routine refactoring commit. It updates the btcd project to use new 'v2' versions of its own Go modules (such as btcutil/v2, chaincfg/v2, wire/v2, txscript/v2, and a newly split-out address/v2 package) across the entire codebase. It also updates some third-party dependencies and Go version requirements. There is no indication of a security fix or vulnerability being addressed.
Security candidatepsbt: move to top-level module, use v2, remove btcutil depby Oliver Gugger · c0db6dfa · May 15, 2026 · 22 filesMessage 50 · ThinInformational 15Details
Commit message · Oliver Gugger
psbt: move to top-level module, use v2, remove btcutil dep
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarycryptography-sensitive pathsigning or wallet pathboot or update path
AI analysis · Informational 15/100
This commit is a routine code reorganization: it moves the PSBT (Partially Signed Bitcoin Transaction) package from a nested location under btcutil to a top-level module, updates internal import paths to use v2 module versions, and removes a dependency on btcutil. The diff shows files being deleted from btcutil/psbt and equivalent files being added under psbt/. There is no indication of a security bug fix, vulnerability patch, or behavior change intended to address an exploit.
Security candidatebtcutil: remove circular dependency, use v2by Oliver Gugger · e9ec6ec5 · May 15, 2026 · 52 filesMessage 45 · ThinInformational 18Details
Commit message · Oliver Gugger
btcutil: remove circular dependency, use v2
45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathboot or update path
AI analysis · Informational 18/100
This commit is a routine internal restructuring of the btcd project's Go module layout. It switches the btcutil package and its subpackages from the old module path to a new 'v2' path, and updates imports throughout the code to point at newly split-out submodules (address, chaincfg, chainhash, txscript, wire). It also copies one small helper function (HashMerkleBranches) into the bloom package to avoid depending on the blockchain package. There is no indication in the commit of any security bug being fixed.
Security candidatebtcec: use new chainhash/v2 moduleby Oliver Gugger · bf8006d8 · May 15, 2026 · 8 filesMessage 45 · ThinInformational 18Details
Commit message · Oliver Gugger
btcec: use new chainhash/v2 module
45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 18/100
This commit is a routine dependency update inside the btcd cryptocurrency project. It changes the btcec cryptographic package to use a newer version (v2) of the internal chainhash module instead of the older v1 path. No security bug is fixed or introduced in the visible code; it is purely an import-path and module-reference change.
multi: bump in-tree go.mod files to newly tagged submodule versions
In this commit, we pin every in-tree go.mod to the freshly cut submodule tags ahead of a btcd point release: btcec/v2.4.0, btcutil/v1.2.0, btcutil/psbt/v1.2.0, and chaincfg/chainhash/v1.2.0. The btcec bump also drags secp256k1 up to v4.4.0 (and blake256 to v1.1.0 transitively) for every module that imports btcec.
v2transport stays at v1.0.1 since no v2transport code changed since the last tag, but its go.mod is bumped here so the workspace resolves to a consistent set of internal deps.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundaryaccess controlsigning or wallet path
AI analysis · Informational 15/100
This commit only updates version numbers in Go package files (go.mod and go.sum) to prepare for a new release. It does not change any actual program code, fix a bug, or alter behavior. There is no direct security issue visible in this change.
Security candidaterpcclient: compute httpURL once at construction timeby Jacob Schuler · 807cbce3 · May 14, 2026 · 2 filesMessage 88 · StrongTriage 18Details
Commit message · Jacob Schuler
rpcclient: compute httpURL once at construction time
httpURL was being recomputed on every JSON-RPC POST. It went through ParseAddressString to discriminate Unix sockets from TCP, which called net.ResolveTCPAddr and triggered a DNS lookup whose result was thrown away.
Both inputs (config.Host and config.DisableTLS) are immutable after New, so the URL is constant for the life of the Client. Compute it once and store it on the Client, mirroring the parsedDialAddr cache already in newHTTPClient.
The httpURL method now uses HasPrefix and runs exactly once per Client. Drop its (string, error) signature — with the resolve gone nothing can fail. Add table coverage for the URL strings, plus a wiring test that catches refactors of New silently dropping the assignment to Client.httpURL.
88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
Security candidatetxscript: support trivial signing for P2Aby Olaoluwa Osuntokun · 241bf7ca · May 12, 2026 · 1 fileMessage 45 · ThinLow 34Details
Commit message · Olaoluwa Osuntokun
txscript: support trivial signing for P2A
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 34/100
This commit adds support in btcd's transaction-signing code for a new Bitcoin output type called P2A (Pay-to-Anchor). P2A outputs are intentionally designed to be 'anyone-can-spend,' meaning no signature is needed to spend them. The change simply tells btcd to return an empty script when asked to sign such an output, rather than failing because it doesn't recognize the type. This is a feature addition to keep btcd compatible with Bitcoin's evolving protocol, not a fix for a vulnerability in the cryptographic sense. However, because P2A outputs are anyone-can-spend by design, any wallet or node that mishandles them could in theory lose funds placed in such outputs, so the change has security-adjacent relevance.
Security candidatebtcjson: add tests for StringOrArray and Warnings fieldby Olaoluwa Osuntokun · 91cf7b24 · May 12, 2026 · 1 fileMessage 96 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun
btcjson: add tests for StringOrArray and Warnings field
Add a regression test for the StringOrArray.MarshalJSON infinite-recursion fix that exercises both the direct method call and the path through json.Marshal. Without the fix, the test triggers a goroutine stack overflow.
Also add a round-trip test and tests for the new Warnings field on GetBlockChainInfoResult, covering both the legacy single-string form and the post-bitcoin#29845 array form.
96/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
memory safetyfuzzing or regression evidence
AI analysis · Informational 15/100
This commit only adds new test code for a previously fixed bug. It does not change any production code, so it cannot introduce or fix a live security issue on its own. The tests verify that a type called StringOrArray can be safely converted to JSON without getting stuck in infinite recursion, and that a 'warnings' field can accept either a single string or a list of strings.
Security candidatebtcjson: fix infinite recursion in StringOrArray.MarshalJSONby Eric Grill · b528a353 · May 12, 2026 · 1 fileMessage 86 · StrongLow 39Details
Commit message · Eric Grill
btcjson: fix infinite recursion in StringOrArray.MarshalJSON
The MarshalJSON method was calling json.Marshal(h) where h is of type StringOrArray. Since StringOrArray implements json.Marshaler, this caused json.Marshal to call MarshalJSON again, resulting in infinite recursion and a stack overflow.
Fix by converting to the underlying []string type before marshaling, which breaks the interface lookup cycle.
Closes #2369
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
86/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Low 39/100
This commit fixes a bug where a piece of code responsible for turning a list of text strings into JSON format accidentally called itself forever, eventually crashing the program with a stack overflow. The fix changes the code to convert the custom type to a plain list of strings before handing it to the JSON encoder, breaking the endless loop.
ecdsa: update recovery error messages and fix test comparison
Update the expected error strings in recoveryTests to match the new error message format introduced by the secp256k1 v4.4.0 upgrade. Also replace reflect.DeepEqual with a string-based errorStringEqual helper to avoid type mismatches between fmt.Errorf and wrapped errors, and drop the now-unused "reflect" import.
95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 15/100
This commit only changes test code. It updates the expected error messages in a test file to match a newer version of a cryptographic library and swaps one test-comparison helper for another. There is no change to the actual signature-recovery logic that runs in production, so it does not create or fix a security vulnerability in live code.
Introduce a VerifyLowS helper to detect non-canonical high-S ECDSA signatures, along with unit tests.
70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing boundarycryptography-sensitive pathsigning or wallet path
AI analysis · Low 28/100
This commit adds a new helper function called VerifyLowS to the btcd Bitcoin library's ECDSA signature code. Its purpose is to detect signatures whose 'S' value is in the mathematically equivalent but non-standard 'high-S' form, which can make signatures malleable (one valid signature can be transformed into another valid one). The commit also adds unit tests. It does not by itself change any consensus or network validation rules; it only provides a reusable utility for callers to enforce low-S if they choose.
The new version exposes Signature.S(), giving direct access to the S scalar without re-parsing the DER bytes. This enables a cleaner implementation of the VerifyLowS helper added in this branch.
73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Add a bounds check against the remaining slab capacity so oversized witness items return a decode error. Add a regression test for witness items that overflow the decode slab.
83/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
memory safetyfuzzing or regression evidence
AI analysis · High 72/100
This commit fixes a bug in btcd's transaction decoding where a malformed Bitcoin transaction could claim witness data larger than the internal decode buffer. Before the fix, this could cause a panic (crash) when the code tried to copy data into a too-small buffer. The patch adds a size check so the transaction is rejected cleanly instead of crashing the node.
Security candidateDockerfile: update go base imageby Kim · 2577dd3e · Aug 20, 2025 · 3405 filesMessage 45 · ThinInformational 17Details
Commit message · Kim
Dockerfile: update go base image
45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive pathseed or entropy pathsigning or wallet pathboot or update pathauthentication pathparser or protocol path
AI analysis · Informational 17/100
This commit is a large repository import or rebase that adds the entire btcd codebase plus new GitHub templates, CI workflows, a Makefile, and Dockerfiles. The stated purpose is 'Dockerfile: update go base image'. The actual Dockerfile change moves the build base image from a pinned SHA256 digest of golang:1.23.12-alpine3.21 to a tag-based golang:1.22.11-alpine3.21 in the GitHub Actions Dockerfile. There is no direct code-level security fix visible in the diff; the security relevance is limited to supply-chain/dependency hygiene of the Go base image used in Docker builds.