The small mistake that can silently remove your Bitcoin inheritance lock

The older() time-lock: the duration you write and the one Bitcoin enforces may differ.

Türkçe

Short version. To say "the heir key may spend if the coin hasn't moved for 90 days" you write older(12960) in Miniscript. But if you write older(65536) the lock does not exist: the heir can spend immediately. If you write older(2592000) intending "30 days", the real wait is ~250.7 days. Miniscript does not reject these values and Bitcoin Core does not warn.

Why does this happen?

older(n) is a relative time-lock (BIP-68/112). For n, Miniscript only requires 1 ≤ n < 2³¹ (BIP-379). But when spending, consensus uses only bit 22 (type: blocks/time) and the low 16 bits of the value and ignores the rest. A value that overflows 16 bits is silently truncated.

What I measured (Bitcoin Core 31.1, regtest)

I tested the heir path at every block with testmempoolaccept. "First accept" = the first confirmation count at which the heir could spend.

WrittenActual lockMeasured first acceptMeaning
older(10)10 blocks10th confirmationAs expected
older(65535)65,535 blocks—Maximum ≈ 455 days
older(65536)01st confirmationNo lock
older(65541)5 blocks5th confirmationUnexpectedly short
older(131075)3 blocks3rd confirmationUnexpectedly short
older(8388615)7 blocks7th confirmationUnexpectedly short
older(2592000)36,096 blocks ≈ 250.7 days36,096th (rejected at 36,095)Mistaken for "30 days"
older(4194306)2 × 512 s = 1024 s (time-based)Median-time difference ≥ 1024 sTime-based lock

What to do

Audit your own policy → (runs in your browser; your data never leaves your device)

Limits

Results were measured on a single-node Bitcoin Core 31.1 regtest with no real money. This is not investment, legal or tax advice. Sources: BIP-68, BIP-112, BIP-379.