BT
← All projectsbtcsuite

btcd

Alternative full-node Bitcoin implementation written in Go.

BitcoinNode implementationsNormal
Repository coverage

209 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.

46security candidates22second-pass queue203AI analyses
10commits · 30 days
10commits · 60 days
147commits · 180 days
204commits · 365 days
Backfill bands
Aug 5 → Feb 621 seen1 candidatesComplete
Feb 6 → Jun 6112 seen7 candidatesComplete
Jun 6 → Jul 634 seen13 candidatesComplete
Jul 6 → Aug 530 seen7 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.

68/100 average clarity
64Strong · 80–100
80Adequate · 60–79
60Thin · 40–59
5Opaque · 0–39
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Boris Nagaev461546160
Olaoluwa Osuntokun651461173
Lrifton92434186
Erick Cestari818177
Or Aharonee404184
Oliver Gugger13413047
MPins333079
Drake Thomsen222091
Eric Grill313086
Jacob Schuler111088
Julio Cesar111045
Kim111045
Analysis record

Published AI watches

Last scanned 29 minutes ago

Informational 12 AI analysisMessage 86 · Strong
BT btcsuitebtcd BitcoinNode implementations

rpcserver: test null getblock verbosity

This commit only adds a new integration test that sends a null value for the optional verbosity parameter of the getblock RPC and checks that the server returns a normal verbose block response. It does not change any production code. The t…

Regression test for a prior RPC server panic (#2600)No production code changes; defensive test coverage only
c130f0bfby Olaoluwa Osuntokun+36−01 file
No security note in commit
Moderate 65 AI analysisMessage 73 · Adequate
BT btcsuitebtcd BitcoinNode implementations

Merge pull request #2600 from allocz/fix_issue_2597

This patch fixes a server crash in btcd's JSON-RPC 'getblock' command. When a caller did not provide an optional 'verbosity' parameter, the code later dereferenced a nil pointer, causing the entire btcd process to panic. The fix supplies a…

nil-pointer dereference panic in RPC handlerdenial-of-service via crafted JSON-RPC requestserver process crash (availability impact)
a3f20384by Olaoluwa Osuntokun+5−11 file
No security note in commit
Moderate 59 AI analysisMessage 58 · Thin
BT btcsuitebtcd BitcoinNode implementations

Merge pull request #2601 from vbrekher/fix/psbt-multi-a-finalizer

This change fixes how btcd finalizes a specific type of Bitcoin Taproot smart contract called multi_a. Previously, the finalizer simply stacked signatures in the order they appeared in the PSBT file. For multi_a contracts, signatures must …

Incorrect witness ordering for multi_a tapscripts could produce invalid Bitcoin transactionsNew parser enforces standard multi_a template and rejects unsupported CHECKSIGADD constructionsDuplicate and non-matching signatures now return ErrInvalidPsbtFormat
ca0bb02cby Olaoluwa Osuntokun+366−93 files
No security note in commit
Informational 12 AI analysisMessage 95 · Strong
BT btcsuitebtcd BitcoinNode implementations

psbt: test multi_a excess signature handling

This commit only adds a new unit test for the PSBT finalizer. It checks that when a Bitcoin Taproot multi-signature (multi_a) input has more valid signatures than required, the finalizer picks exactly the required number and leaves the ext…

26ee1cc8by Olaoluwa Osuntokun+33−01 file
No security note in commit
Informational 12 AI analysisMessage 95 · Strong
BT btcsuitebtcd BitcoinNode implementations

psbt: test multi_a signature input ordering

This commit only adds a new test case to the project's test suite. It does not change any production code. The test verifies that a PSBT (Partially Signed Bitcoin Transaction) finalizer correctly orders signatures for a specific type of Ta…

Regression test for Taproot multi_a signature orderingNo production code changesDefensive guard against incorrect finalizer implementations
709069b9by Olaoluwa Osuntokun+36−131 file
No security note in commit
Informational 15 AI analysisMessage 58 · Thin
BT btcsuitebtcd BitcoinNode implementations

Merge pull request #2580 from Roasbeef/version-bump-v0.26.2

This commit only changes the software version number from v0.26.1-beta.rc1 to v0.26.2-beta. It does not modify any security-related code, network behavior, or user-facing functionality. There is no security issue here.

05585e03by Olaoluwa Osuntokun+2−21 file
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
BT btcsuitebtcd BitcoinNode implementations

build: bump version to v0.26.2-beta

This commit only changes the software version number from v0.26.1-beta.rc1 to v0.26.2-beta. It does not modify any program logic, network code, or security behavior. There is no security issue here.

d9948c49by Olaoluwa Osuntokun+2−21 file
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
BT btcsuitebtcd BitcoinNode implementations

build: bump version to v0.26.1-beta.rc1

This commit only changes the reported software version number from v0.26.0-beta to v0.26.1-beta.rc1. It does not alter any program logic, network behavior, or security-sensitive code. There is no security issue here.

3fa0a65cby Olaoluwa Osuntokun+2−21 file
No security note in commit
Informational 18 AI analysisMessage 78 · Adequate
BT btcsuitebtcd BitcoinNode implementations

version: preserve semantic version separators

This commit fixes a small bug in how the btcd Bitcoin node software cleans up version strings. Previously, dots in pre-release version labels like 'beta.rc1' were accidentally removed, turning them into 'betarc1'. The change adds dots to t…

No security-relevant signals in commit message or diffChange is a string-normalization correctness fixNo input from untrusted network sources is processed by this code path
65db4939by Olaoluwa Osuntokun+20−12 files
No security note in commit
Informational 15 AI analysisMessage 85 · Strong
BT btcsuitebtcd BitcoinNode implementations

build: pin tagged submodules and remove local replacements

This commit is a routine build housekeeping change. It updates two internal Go module dependencies to newly published tagged versions and removes local directory overrides so that everyone builds with the same published code. There is no i…

3d3b5e8aby Olaoluwa Osuntokun+8−82 files
No security note in commit
Informational 15 AI analysisMessage 88 · Strong
BT btcsuitebtcd BitcoinNode implementations

build: bump v2transport to v1.1.0

This commit only updates a dependency version number in the project's Go module file. It bumps the v2transport package from version 1.0.1 to 1.1.0 so that downstream projects building btcd as a module can access new handshake admission API…

8d902916by Olaoluwa Osuntokun+1−11 file
No security note in commit
Informational 12 AI analysisMessage 83 · Strong
BT btcsuitebtcd BitcoinNode implementations

rpcclient: harden DisableAuth transport tests

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
52d2fadeby Olaoluwa Osuntokun+186−1272 files
No security note in commit
Informational 15 AI analysisMessage 78 · Adequate
BT btcsuitebtcd BitcoinNode implementations

rpcclient: wrap DisableAuth tests to 80 columns

This commit only reformats an existing test file. It wraps long lines to 80 columns, splits nested code into separate variables, and adjusts whitespace. No production code was changed, and no security behavior is altered.

fe84a0e1by Olaoluwa Osuntokun+83−521 file
No security note in commit
Informational 15 AI analysisMessage 96 · Strong
BT btcsuitebtcd BitcoinNode implementations

rpcclient: add tests for DisableAuth header behavior

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…

9b849c17by Drake Thomsen+109−01 file
No security note in commit
Informational 21 AI analysisMessage 86 · Strong
BT btcsuitebtcd BitcoinNode implementations

rpcclient: make HTTP Basic Auth optional via DisableAuth

This change adds a new optional setting called DisableAuth to the btcd RPC client. When a user turns it on, the client will not send username/password credentials automatically. This is meant to let users connect to external Bitcoin API se…

New opt-in configuration flag that disables authentication headersDefault behavior unchanged; authentication still required unless user explicitly disables itNo validation added to ensure alternative authentication is present when DisableAuth is true
5d22b395by Drake Thomsen+25−131 file
No security note in commit
Informational 14 AI analysisMessage 83 · Strong
BT btcsuitebtcd BitcoinNode implementations

integration: stabilize pre-verack disconnect cycles

This change only modifies an integration test file. It makes a test more reliable by waiting for a version response and retrying connection attempts, rather than changing any production code that handles real Bitcoin peer connections. Ther…

76ba8842by Olaoluwa Osuntokun+58−191 file
No security note in commit
Low 27 AI analysisMessage 83 · Strong
BT btcsuitebtcd BitcoinNode implementations

server+connmgr: make outbound startup deterministic

This commit fixes a scheduling bug in how a Bitcoin node decides how many automatic outbound peers to connect to at startup. Previously, if a user had configured permanent peers, those permanent peers could grab internal connection IDs bef…

Non-deterministic outbound peer count at startupPermanent peers could consume connection request IDs before automatic counter sampledPotential for fewer automatic outbound peers than configured, reducing network diversity
58ee9ef6by Olaoluwa Osuntokun+157−224 files
No security note in commit
Low 26 AI analysisMessage 68 · Adequate
BT btcsuitebtcd BitcoinNode implementations

config: reject non-positive maxpeers

This commit fixes a configuration bug in btcd, a Bitcoin node implementation. Previously, setting maxpeers=0 caused the node to enter a tight loop: it would repeatedly try to connect to outbound peers and immediately reject them. The chang…

Denial-of-service-like resource exhaustion via tight reconnect loop triggered by a configuration valueInput validation added for a previously unbounded configuration parameterNo memory corruption, authentication bypass, or remote code execution signals present
7e9414faby Olaoluwa Osuntokun+42−23 files
No security note in commit
Informational 12 AI analysisMessage 83 · Strong
BT btcsuitebtcd BitcoinNode implementations

integration: synchronize p2p lifecycle stress batches

This commit changes only test code. It tightens up an integration test that simulates many fake Bitcoin peers connecting and disconnecting from a node, and makes a small cleanup in a unit test for closing network pipes. There is no change …

No production code changedTest-only synchronization improvementsNo authentication, cryptography, consensus, or network handling logic modified
5a2c5063by Olaoluwa Osuntokun+217−202 files
No security note in commit
Low 48 AI analysisMessage 78 · Adequate
BT btcsuitebtcd BitcoinNode implementations

v2transport: restore responder handshake progress

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
09717871by Olaoluwa Osuntokun+231−862 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.

AI review queuedrpcserver: test null getblock verbosityby Olaoluwa Osuntokun · c130f0bf · Sep 11, 2026 · 1 fileMessage 86 · StrongInformational 12Details
Commit message · Olaoluwa Osuntokun

rpcserver: test null getblock verbosity

In this commit, we add an RPC integration test for an explicit null
getblock verbosity parameter. The request must use the documented default
verbosity, return the verbose block result, and keep the WebSocket client
connected.

This covers the panic fixed in #2600 through the same raw JSON-RPC decoding
path that exposed it.

86/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 12/100

This commit only adds a new integration test that sends a null value for the optional verbosity parameter of the getblock RPC and checks that the server returns a normal verbose block response. It does not change any production code. The test is described as covering a previously fixed server panic, but the fix itself is not present in this commit.

AI review queuedMerge pull request #2600 from allocz/fix_issue_2597by Olaoluwa Osuntokun · a3f20384 · Sep 11, 2026 · 1 fileMessage 73 · AdequateModerate 65Details
Commit message · Olaoluwa Osuntokun

Merge pull request #2600 from allocz/fix_issue_2597

btcd: fix getblock panic triggered by rpc call

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discountsecond-pass: broader security terminology
AI analysis · Moderate 65/100

This patch fixes a server crash in btcd's JSON-RPC 'getblock' command. When a caller did not provide an optional 'verbosity' parameter, the code later dereferenced a nil pointer, causing the entire btcd process to panic. The fix supplies a default verbosity value of 1 when the parameter is missing, preventing the crash.

Security candidateMerge pull request #2601 from vbrekher/fix/psbt-multi-a-finalizerby Olaoluwa Osuntokun · ca0bb02c · Sep 9, 2026 · 3 filesMessage 58 · ThinModerate 59Details
Commit message · Olaoluwa Osuntokun

Merge pull request #2601 from vbrekher/fix/psbt-multi-a-finalizer

psbt: fix multi_a taproot finalization

58/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet pathmerge-commit duplicate discount
AI analysis · Moderate 59/100

This change fixes how btcd finalizes a specific type of Bitcoin Taproot smart contract called multi_a. Previously, the finalizer simply stacked signatures in the order they appeared in the PSBT file. For multi_a contracts, signatures must be placed in the exact reverse order of the public keys written into the script, and unused key slots need empty placeholders. If the order was wrong, the resulting transaction would be rejected by the Bitcoin network, effectively locking or breaking the spend. The patch adds parsing logic to recognize multi_a scripts and build the witness stack correctly.

Security candidatepsbt: test multi_a excess signature handlingby Olaoluwa Osuntokun · 26ee1cc8 · Sep 9, 2026 · 1 fileMessage 95 · StrongInformational 12Details
Commit message · Olaoluwa Osuntokun

psbt: test multi_a excess signature handling

In this commit, we cover a 2-of-3 multi_a input that contains valid signatures for all three keys. The finalizer must select exactly two script positions because NUMEQUAL rejects a witness with more successful checks than the threshold.

The expected witness also fixes the deterministic choice in script order and requires the excess key position to remain empty.

95/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 12/100

This commit only adds a new unit test for the PSBT finalizer. It checks that when a Bitcoin Taproot multi-signature (multi_a) input has more valid signatures than required, the finalizer picks exactly the required number and leaves the extra signature slot empty. There is no code change to the finalizer itself—only a test was added.

Security candidatepsbt: test multi_a signature input orderingby Olaoluwa Osuntokun · 709069b9 · Sep 9, 2026 · 1 fileMessage 95 · StrongInformational 12Details
Commit message · Olaoluwa Osuntokun

psbt: test multi_a signature input ordering

In this commit, we exercise taproot multi_a finalization with signature records in both script order and reverse script order. Both inputs must produce the same witness because PSBT record ordering does not define tapscript stack positions.

This guards against implementations that only reverse the input slice, which works for script-ordered records but assigns shuffled records to the wrong keys.

95/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 12/100

This commit only adds a new test case to the project's test suite. It does not change any production code. The test verifies that a PSBT (Partially Signed Bitcoin Transaction) finalizer correctly orders signatures for a specific type of Taproot script (multi_a) regardless of the order in which the signatures are recorded in the PSBT. It is a defensive regression test, not a fix for a known vulnerability.

Lower-priorityMerge pull request #2580 from Roasbeef/version-bump-v0.26.2by Olaoluwa Osuntokun · 05585e03 · Jul 24, 2026 · 1 fileMessage 58 · ThinInformational 15Details
Commit message · Olaoluwa Osuntokun

Merge pull request #2580 from Roasbeef/version-bump-v0.26.2

build: bump version to v0.26.2-beta

58/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
merge-commit duplicate discount
AI analysis · Informational 15/100

This commit only changes the software version number from v0.26.1-beta.rc1 to v0.26.2-beta. It does not modify any security-related code, network behavior, or user-facing functionality. There is no security issue here.

Lower-prioritybuild: bump version to v0.26.2-betaby Olaoluwa Osuntokun · d9948c49 · Jul 24, 2026 · 1 fileMessage 80 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun

build: bump version to v0.26.2-beta

In this commit, we move btcd past the v0.26.1 release candidate and set
the development version to v0.26.2-beta. This keeps the daemon and RPC
server version on the next patch series as work resumes on master.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit only changes the software version number from v0.26.1-beta.rc1 to v0.26.2-beta. It does not modify any program logic, network code, or security behavior. There is no security issue here.

Lower-prioritybuild: bump version to v0.26.1-beta.rc1by Olaoluwa Osuntokun · 3fa0a65c · Jul 22, 2026 · 1 fileMessage 80 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun

build: bump version to v0.26.1-beta.rc1

In this commit, we bump btcd from v0.26.0-beta to
v0.26.1-beta.rc1 for the next release candidate. This puts the version
reported by the daemon and RPC server in sync with the release series
prepared by this PR.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit only changes the reported software version number from v0.26.0-beta to v0.26.1-beta.rc1. It does not alter any program logic, network behavior, or security-sensitive code. There is no security issue here.

Lower-priorityversion: preserve semantic version separatorsby Olaoluwa Osuntokun · 65db4939 · Jul 22, 2026 · 2 filesMessage 78 · AdequateInformational 18Details
Commit message · Olaoluwa Osuntokun

version: preserve semantic version separators

In this commit, we include periods in the alphabet accepted by
normalizeVerString. SemVer uses periods to separate pre-release identifiers,
but the old filter silently collapsed beta.rc1 into betarc1.

We add a focused test for the dotted RC suffix before using it for the next
release candidate.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 18/100

This commit fixes a small bug in how the btcd Bitcoin node software cleans up version strings. Previously, dots in pre-release version labels like 'beta.rc1' were accidentally removed, turning them into 'betarc1'. The change adds dots to the allowed character set and adds a test to prevent regression. It is a correctness fix with no direct security impact visible in the code.

Security candidatebuild: pin tagged submodules and remove local replacementsby Olaoluwa Osuntokun · 3d3b5e8a · Jul 22, 2026 · 2 filesMessage 85 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun

build: pin tagged submodules and remove local replacements

In this commit, we pin btcutil and wire to their freshly tagged v2.0.1
releases. We also remove the root module's remaining local replace
directives now that all three in-tree modules have published versions.

This makes local builds and downstream module consumers resolve the same
btcutil, v2transport, and wire code. The regenerated checksums cover each
published module.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
access control
AI analysis · Informational 15/100

This commit is a routine build housekeeping change. It updates two internal Go module dependencies to newly published tagged versions and removes local directory overrides so that everyone builds with the same published code. There is no indication of a security fix or vulnerability in the commit itself.

Lower-prioritybuild: bump v2transport to v1.1.0by Olaoluwa Osuntokun · 8d902916 · Jul 22, 2026 · 1 fileMessage 88 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun

build: bump v2transport to v1.1.0

In this commit, we bump the root module requirement to the freshly tagged
v2transport v1.1.0 release. This exposes the responder handshake admission
APIs added in #2576 when btcd is built as a downstream module, where the
repository-local replace directive does not apply.

88/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
AI analysis · Informational 15/100

This commit only updates a dependency version number in the project's Go module file. It bumps the v2transport package from version 1.0.1 to 1.1.0 so that downstream projects building btcd as a module can access new handshake admission APIs. There is no code change, no bug fix, and no security patch in the diff itself.

Security candidaterpcclient: wrap DisableAuth tests to 80 columnsby Olaoluwa Osuntokun · fe84a0e1 · Jul 22, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Olaoluwa Osuntokun

rpcclient: wrap DisableAuth tests to 80 columns

In this commit, we wrap the new DisableAuth regression tests to the
btcd 80-column formatting convention. We also split the nested handler
setup and assertions into logical stanzas so the tests match the
surrounding style.

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 evidenceauthentication path
AI analysis · Informational 15/100

This commit only reformats an existing test file. It wraps long lines to 80 columns, splits nested code into separate variables, and adjusts whitespace. No production code was changed, and no security behavior is altered.

Security candidaterpcclient: make HTTP Basic Auth optional via DisableAuthby Drake Thomsen · 5d22b395 · Jul 22, 2026 · 1 fileMessage 86 · StrongInformational 21Details
Commit message · Drake Thomsen

rpcclient: make HTTP Basic Auth optional via DisableAuth

Add a DisableAuth field to ConnConfig that, when set to true, skips
setting the Authorization header on RPC requests.

This enables connecting to third-party RPC providers (e.g. Alchemy,
GetBlock) that authenticate via API key in the URL path and reject
requests containing an Authorization header with 401 errors.

Previously, getAuth() unconditionally set BasicAuth or attempted
cookie auth, leaving no way to disable authentication entirely.

Fixes #2505

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
access control
AI analysis · Informational 21/100

This change adds a new optional setting called DisableAuth to the btcd RPC client. When a user turns it on, the client will not send username/password credentials automatically. This is meant to let users connect to external Bitcoin API services that use a key in the web address instead of HTTP Basic Auth. It is a feature addition, not a fix for an active security flaw. The only risk is that someone who enables it may accidentally send unauthenticated requests if they forget to configure the other security mechanism provided by their RPC provider.

Security candidaterpcclient: add tests for DisableAuth header behaviorby Drake Thomsen · 9b849c17 · Jul 22, 2026 · 1 fileMessage 96 · StrongInformational 15Details
Commit message · Drake Thomsen

rpcclient: add tests for DisableAuth header behavior

Add table-driven tests that verify:
- Authorization header is omitted when DisableAuth is true
- Authorization header is present when DisableAuth is false
- Default (zero value) behavior includes Authorization header

Suggested by @TechLateef in #2514.

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
access controlauthentication path
AI analysis · Informational 15/100

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 correctly controls whether the RPC client sends an Authorization header.

Security candidaterpcclient: harden DisableAuth transport testsby Olaoluwa Osuntokun · 52d2fade · Jul 22, 2026 · 2 filesMessage 83 · StrongInformational 12Details
Commit message · Olaoluwa Osuntokun

rpcclient: harden DisableAuth transport tests

In this commit, we make the DisableAuth tests observe successful
requests instead of inferring them from an empty header. This closes a
false-positive path where credential lookup could fail before the
request reached the server.

We also cover the WebSocket handshake, cookie bypass, and
caller-provided headers across enabled and disabled auth. The public
comment now makes clear that DisableAuth only suppresses
rpcclient-generated Basic auth.

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
defensive validationcredential or privilege stateauthentication path
AI analysis · Informational 12/100

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 true; the commit makes the tests check that real requests succeed and confirms caller-provided Authorization headers are still sent. There is no security fix here.

Lower-priorityintegration: stabilize pre-verack disconnect cyclesby Olaoluwa Osuntokun · 76ba8842 · Jul 21, 2026 · 1 fileMessage 83 · StrongInformational 14Details
Commit message · Olaoluwa Osuntokun

integration: stabilize pre-verack disconnect cycles

In this commit, we make the pre-verack lifecycle test count only peers that
btcd has admitted and processed through version exchange.

The source handshake limit can close a rapid follow-up socket while the
previous disconnect is still unwinding. This made the client-side version
write fail with EPIPE before the intended lifecycle path ran. We now wait for
a version response from btcd, retry rejected attempts under a deadline, and
still disconnect without sending verack.

This preserves all 50 peerDone without peerAdd cycles while removing the
scheduler-dependent admission race from the test.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 14/100

This change only modifies an integration test file. It makes a test more reliable by waiting for a version response and retrying connection attempts, rather than changing any production code that handles real Bitcoin peer connections. There is no security fix or vulnerability here.

Lower-priorityconfig: reject non-positive maxpeersby Olaoluwa Osuntokun · 7e9414fa · Jul 21, 2026 · 3 filesMessage 68 · AdequateLow 26Details
Commit message · Olaoluwa Osuntokun

config: reject non-positive maxpeers

In this commit, we reject maxpeers values that cannot represent a usable
peer budget.

A zero value reached connmgr as TargetOutbound=0, where zero means to use
the default target of eight. The server then rejected every completed
peer and immediately created a replacement request. Rejecting the value
during configuration avoids that outbound reconnect loop.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 26/100

This commit fixes a configuration bug in btcd, a Bitcoin node implementation. Previously, setting maxpeers=0 caused the node to enter a tight loop: it would repeatedly try to connect to outbound peers and immediately reject them. The change now rejects zero or negative maxpeers values at startup with a clear error, preventing the node from starting in a broken state.

Lower-priorityserver+connmgr: make outbound startup deterministicby Olaoluwa Osuntokun · 58ee9ef6 · Jul 21, 2026 · 4 filesMessage 83 · StrongLow 27Details
Commit message · Olaoluwa Osuntokun

server+connmgr: make outbound startup deterministic

In this commit, we define TargetOutbound as the number of automatic
connections and treat explicit Connect requests as additional peers.

Permanent requests could previously consume connection IDs before Start
sampled the shared counter. The resulting automatic count depended on
goroutine scheduling, while the listener reserved the worst-case total.
We now start the configured automatic count directly and cap it by the
peer budget left after permanent peers.

The composition test covers permanent requests on both sides of Start and
pins the same automatic+permanent total for either ordering.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Low 27/100

This commit fixes a scheduling bug in how a Bitcoin node decides how many automatic outbound peers to connect to at startup. Previously, if a user had configured permanent peers, those permanent peers could grab internal connection IDs before the automatic counter started, causing the node to sometimes open fewer automatic connections than intended. The patch makes the count deterministic: automatic outbound peers are always started directly, and the total is capped only after accounting for permanent peers. This is primarily a reliability/consistency fix, but inconsistent peer counts could mildly affect a node's network connectivity and resistance to eclipse attacks.

Lower-priorityintegration: synchronize p2p lifecycle stress batchesby Olaoluwa Osuntokun · 5a2c5063 · Jul 21, 2026 · 2 filesMessage 83 · StrongInformational 12Details
Commit message · Olaoluwa Osuntokun

integration: synchronize p2p lifecycle stress batches

In this commit, we make each stress wave establish its full set of peers
before disconnecting them together. A ping/pong barrier proves the server
processed each verack, while RPC connection-count barriers prove
registration and removal completed before the next wave starts.

We bound concurrent handshakes from the shared source, drain every worker on
failure, and wait for server-side cleanup. This keeps the test compatible
with the admission limits it exercises and makes a passing run evidence of
the intended NewPeer/DonePeer ordering.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 12/100

This commit changes only test code. It tightens up an integration test that simulates many fake Bitcoin peers connecting and disconnecting from a node, and makes a small cleanup in a unit test for closing network pipes. There is no change to production code, so it does not introduce or fix a security vulnerability in the software users run.

Security candidatev2transport: restore responder handshake progressby Olaoluwa Osuntokun · 09717871 · Jul 21, 2026 · 2 filesMessage 78 · AdequateLow 48Details
Commit message · Olaoluwa Osuntokun

v2transport: restore responder handshake progress

In this commit, we send the responder key as soon as the initiator diverges
from the v1 prefix. This avoids the BIP324 deadlock where both sides can wait
for the other to write before the initiator has sent its complete 64-byte
key.

We split key generation and key agreement into separate admission leases,
and release each lease before the intervening network I/O. The regression
test stops after the first mismatch, requires the responder to make
progress, then completes key agreement and verifies the resulting packet
ciphers interoperate.

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 material
AI analysis · Low 48/100

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 each other. The change makes the responder send its own key earlier, after the first byte that differs from the old v1 protocol, and splits expensive cryptographic work into two separately rate-limited phases so the CPU lock is not held across network reads or writes. It is a protocol correctness/DoS-resilience fix rather than a direct theft-of-funds bug.

Lower-priorityserver+inbound: correct inbound admission accountingby Olaoluwa Osuntokun · 95c11c56 · Jul 21, 2026 · 6 filesMessage 73 · AdequateLow 48Details
Commit message · Olaoluwa Osuntokun

server+inbound: correct inbound admission accounting

In this commit, we keep loopback and whitelisted peers inside the ordinary
pending-handshake and V2 source budgets, while preserving their existing
no-ban behavior.

We also derive the listener reservation from the configured peer mode.
Connect-only and simnet nodes now reserve just their permanent peers, while
automatic mode accounts for both its target and addpeers without exceeding
MaxPeers.

Finally, a bound V2 handshake consumes its rate budgets once, but reacquires
the concurrency slot for each CPU-bound responder phase. This keeps rate
limiting scoped to the handshake while bounding both expensive phases.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 48/100

This commit fixes accounting bugs in how btcd counts and limits incoming peer connections. Previously, loopback/whitelisted peers and permanent outbound peers (such as manually added peers) were not correctly counted against connection budgets, which could let a node accept more inbound connections than intended or let special peers bypass per-source rate limits. The patch makes the counts consistent so the configured maximum peer limits are actually enforced for all peer types, while still preserving the existing rule that whitelisted/loopback peers cannot be banned.

Security candidatepsbt: decode base64 packets incrementallyby Olaoluwa Osuntokun · e333817d · Jul 21, 2026 · 2 filesMessage 78 · AdequateLow 41Details
Commit message · Olaoluwa Osuntokun

psbt: decode base64 packets incrementally

In this commit, we decode base64 PSBT packets as a stream instead of
reading the full encoded input into memory first.

The previous aggregate bound reused wire.MaxMessagePayload, even though
BIP-174 doesn't bind PSBT packet size to the P2P message limit. This made
the base64 path reject packets that the raw path accepted. We now feed
decoded bytes through the same per-field parser used for raw packets,
while retaining strict base64 and trailing-data checks.

We also add a regression test with nine individually valid 4,000,000-byte
unknown values to pin raw and base64 parsing to the same behavior.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundaryaccess controlfuzzing or regression evidencesigning or wallet path
AI analysis · Low 41/100

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 limit to PSBT packets. That caused the base64 parser to reject large but otherwise valid PSBTs that the raw binary parser would accept. The new code decodes base64 incrementally as a stream, removes the wire-size bound for base64 PSBTs, and still rejects whitespace, non-canonical characters, and trailing data. A regression test confirms that nine 4 MB unknown fields are accepted via both raw and base64 paths.

Lower-priorityaddress: reject v2-v16 segwit addresses encoded with bech32by Lrifton92 · 27bbee94 · Jul 21, 2026 · 2 filesMessage 83 · StrongModerate 52Details
Commit message · Lrifton92

address: reject v2-v16 segwit addresses encoded with bech32

BIP-350 requires that segregated witness outputs of version 1 through 16
use the bech32m checksum, while only version 0 uses bech32. decodeSegWitAddress
only special-cased versions 0 and 1, so a witness program with version 2-16
encoded using the legacy bech32 checksum decoded successfully, in violation of
the spec and contrary to the BIP-350 reference decoder (which rejects any
non-zero witness version that is not bech32m).

Generalize the version 1 check to cover all versions >= 1, matching the
reference decode() function. Add the relevant BIP-350 INVALID_ADDRESS vectors
(v2 and v16 encoded with bech32) as a regression test; they decoded
successfully before this change and are now rejected.

Signed-off-by: Lrifton92 <Lrifton92@users.noreply.github.com>

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Moderate 52/100

This commit fixes a bug in how btcd decodes certain Bitcoin SegWit addresses. Under the BIP-350 standard, newer witness versions (versions 2 through 16) must use a newer checksum called bech32m, but btcd was only enforcing that rule for version 1. As a result, it wrongly accepted v2-v16 addresses encoded with the older bech32 format. The patch now rejects those invalid addresses and adds test cases to prevent the bug from returning. This is a standards-compliance fix; it does not by itself steal funds, but accepting non-standard addresses could lead to wallet or payment-processing mistakes.

Lower-priorityblockchain/indexers: propagate index drop errorsby Olaoluwa Osuntokun · eb603e40 · Jul 20, 2026 · 2 filesMessage 78 · AdequateLow 34Details
Commit message · Olaoluwa Osuntokun

blockchain/indexers: propagate index drop errors

In this commit, we propagate errors returned while cataloging index
buckets, matching the bucket deletion path fixed by the preceding commit.

We also add fault-injected regression coverage for both paths so neither
error can silently report a successful index drop.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Low 34/100

This commit fixes a bug where an error while listing index buckets during an index drop operation was silently ignored, making the drop appear successful when it actually failed. The fix makes the function return the error to the caller instead of swallowing it, and adds tests to verify both error paths are properly reported.

Lower-priorityblockchain/indexers: fix dropped errorby Lars Lehtonen · ad3b10d1 · Jul 20, 2026 · 1 fileMessage 45 · ThinLow 31Details
Commit message · Lars Lehtonen

blockchain/indexers: fix dropped error

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Low 31/100

This commit fixes a programming mistake where an error from deleting a database bucket was accidentally ignored. The function that drops an index now properly returns the error instead of continuing as if nothing went wrong. A silently ignored failure could leave an index partially deleted or in an inconsistent state, which might cause incorrect behavior later.