AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 19 Bitcoin

lnwallet: use BIP-340 nonce derivation for HTLC sigs in test vectors

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

88/100 · Strong
lnwallet: use BIP-340 nonce derivation for HTLC sigs in test vectors

btcd's schnorr.Sign defaults to RFC6979 nonce derivation, while
libsecp256k1 (used by eclair, CLN, etc) uses BIP-340's standard
nonce derivation with zero auxrand. Both are deterministic but produce
different signatures for the same key and message, causing HTLC
signature mismatches in interop test vectors.

This commit introduces a bip340Signer wrapper that overrides
SignOutputRaw for taproot script path spends to use
schnorr.CustomNonce([32]byte{}) — matching BIP-340 deterministic
signing behavior. The wrapper is only used in the test vector
generator; production signing paths are unchanged.

Note that MuSig2 commitment signatures were already using BIP-340
nonces internally (via the musig2.Sign path), so only the HTLC
second-level transaction signatures were affected.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit changes only a test file in LND. It makes the test-vector generator produce HTLC signatures using the same nonce math as other Lightning implementations (Eclair, Core Lightning), so cross-implementation test vectors match. Production signing code is not touched, so real user funds or network behavior are unaffected. There is no security vulnerability being fixed here; it is a test-infrastructure consistency change.

Recommended action

No security action required. Review and merge as a normal test-maintenance change. If desired, verify that regenerated test vectors still pass against reference implementations (Eclair/CLN).

Security signals we found

01

No production code changed; only test vector generator affected

02

Change is explicitly described as test-only in commit message and comments

03

No memory safety, cryptographic weakness, or privilege boundary change

04

Deterministic signing in tests improves reproducibility, not vulnerability remediation

Risk score

Why this scored 19/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 1/15
Affected reach 2/15
Confidence 9/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.