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

Compute nLocktime in compliance with BIP-370

Public commit record

What the developer wrote

Authored by Salvatore Ingala

68/100 · Adequate
Compute nLocktime in compliance with BIP-370

Before this, the app used to simplify the specs by taking the
PSBT's fallback locktime (or its absence) at face value.

It was documented as a deviation from the specs, but it might
lead to future unexpected behaviors from software wallets that
expect the BIP-370 computation.

This fixes the gap.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

Ledger's Bitcoin app changed how it calculates the 'nLockTime' value when signing a PSBT (Partially Signed Bitcoin Transaction). Previously, it simply used the PSBT's fallback locktime and ignored per-input locktime requirements. Now it follows the BIP-370 standard: it looks at each input's required locktime, picks the correct type (block height or timestamp), and uses the maximum required value. This prevents a wallet from preparing a PSBT where the Ledger would sign with a different locktime than the wallet intended, which could in some cases let funds be spent earlier or later than expected, or cause the signed transaction to be rejected by the network.

Recommended action

Treat this as a security-hardening correctness fix. Users and integrators should upgrade to ensure PSBTs with input-level locktime constraints are signed according to BIP-370. Wallet software that relied on the previous simplified behavior should verify compatibility, especially for PSBTs containing PSBT_IN_REQUIRED_TIME_LOCKTIME or PSBT_IN_REQUIRED_HEIGHT_LOCKTIME. No immediate emergency response is indicated by the commit alone, but the change is relevant to transaction validity and timelock enforcement.

Security signals we found

01

Fixes a documented deviation from BIP-370 nLockTime computation

02

Adds validation of per-input required locktime fields (0x11/0x12)

03

Adds range checks for height/time locktime values

04

Adds conflict detection when inputs require incompatible locktime types

05

Adds assertion that locktime is resolved before transaction hashing

06

Changes signing semantics for PSBTs that use input-level locktime constraints

Risk score

Why this scored 59/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 8/15
Affected reach 10/15
Confidence 7/10
Evidence quality 4/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.