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

btc: support timestamp locktimes

Public commit record

What the developer wrote

Authored by benma's agent

70/100 · Adequate
btc: support timestamp locktimes

Accept timestamp-based nLockTime values and display the exact signed value in UTC.

Keep confirmation for effective locktimes because they control when a transaction becomes final.

Remove RBF status because replacement is mempool policy, not signed consensus state.

Bitcoin Core's full-RBF policy also makes sequence-derived opt-in status misleading.

Litecoin did not show replacement status, so the per-coin RBF flag is no longer needed.

Document client support and add a BIP388 after(timestamp) vector that finalizes and validates.
✓ Descriptive subject✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit adds support for timestamp-based Bitcoin transaction locktimes in the BitBox02 hardware wallet. Previously, locktimes at or above 500,000,000 were rejected; now they are accepted and shown to the user as a UTC date and time. The commit also removes the on-screen 'RBF' (Replace-By-Fee) indicator because RBF is a network policy, not a guaranteed property of the signed transaction. This is a normal feature addition with no obvious security bug, though it changes what transaction details users see before signing.

Recommended action

Review as a normal feature change. Verify that `format_locktime()` correctly handles all uint32 values and that the UTC conversion cannot panic or produce misleading dates. Confirm that removing the RBF display does not conflict with any vendor security or compliance requirements. No immediate security patch appears necessary from the diff alone.

Security signals we found

01

Feature expansion: previously rejected timestamp locktimes are now accepted

02

UI change: locktime confirmation now omits RBF status

03

Consensus semantics preserved: nLockTime still only applies when at least one input sequence is non-final

04

No new input validation bypass observed; locktime is still a uint32 and version is still restricted to 1 or 2

05

Test coverage added for timestamp locktime path

Risk score

Why this scored 32/100

Our methodology →
Potential impact 5/30
Exploitability 5/25
Stealth signal 5/15
Affected reach 5/15
Confidence 8/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.