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

Merge pull request #568 from LedgerHQ/locktimes

Public commit record

What the developer wrote

Authored by Salvatore Ingala

53/100 · Thin
Merge pull request #568 from LedgerHQ/locktimes
✓ Descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
The short version

What changed, and why it matters

This commit fixes how the Ledger Bitcoin app decides the 'lock time' for a transaction when signing a PSBTv2. Previously, the app always used the global fallback lock time and ignored per-input required lock times. That meant a wallet or attacker could set hidden per-input lock-time requirements that the device would not actually enforce, while still producing a valid-looking signature. The change makes the app derive the lock time correctly per the BIP-370 standard, using each input's required height or time lock time when present, and rejecting the PSBT when inputs disagree. This is a correctness fix for a security-critical signing rule.

Recommended action

Treat this as a security-relevant fix. Users and integrators relying on PSBTv2 locktime enforcement should upgrade to the release containing this commit. Wallets that set PSBT_IN_REQUIRED_TIME_LOCKTIME or PSBT_IN_REQUIRED_HEIGHT_LOCKTIME should verify that signatures now commit to the derived lock time, not the fallback. Review any prior transactions signed with affected versions if per-input locktimes were used.

Security signals we found

01

Fixes incorrect handling of PSBTv2 per-input locktime fields

02

Changes what the signature commits to (nLockTime) for PSBTs using required locktimes

03

Adds validation and rejection for conflicting or out-of-range locktime values

04

Adds defensive assertion that locktime is determined before hashing

05

Includes BIP-370 test vectors and adversarial test cases

Risk score

Why this scored 76/100

Our methodology →
Potential impact 22/30
Exploitability 16/25
Stealth signal 12/15
Affected reach 12/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.