Short version. A common Bitcoin inheritance design lets the owner spend any time, while the heir key can spend only after the coin has sat still for N blocks
(older(N)). To keep the heir locked out while you are alive, you must periodically move the coin to your own address: a new UTXO restarts the countdown. I call this a heartbeat.
What I measured (Bitcoin Core 31.1, regtest)
Policy: tr(owner_key, and_v(v:pk(heir_key), older(10))). The owner spends through the key path at any time. The heir can spend through the script path only after 10 confirmations.
- A UTXO reached 9 confirmations, one block short of the heir being able to spend it.
- The owner then re-sent the coin to the same address. That created a new UTXO and made the old one unspendable for the heir.
- For the new UTXO the heir was rejected (
non-BIP68-final) at confirmations 1 to 9 and accepted at 10. The counter had restarted.
Rules of thumb
- Refresh before the lock expires. Doing it at 9 of 10 worked, doing it at 10 would have been too late. In real life leave a wide margin (the tool suggests at most half the lock).
- A refresh is an ordinary transaction: it costs a fee and reuses the address, which has a privacy cost.
- Set a reminder. A heartbeat you forget is an inheritance that opens early.
- The relative lock counts from the UTXO's current confirmation depth. After a chain reorganisation that un-confirms the coin, the counter restarts from the new confirmation (small regtest experiment, not a proof).
Several heirs
The same pattern works with a threshold of heirs inside the script leaf: and_v(v:multi_a(2,h1,h2,h3),older(10)). On regtest, a single heir signature could not complete the transaction; any two of the three could, and only after the lock had passed.
Limits
Regtest with fake coins, one node, Bitcoin Core 31.1. Software wallets, not hardware devices. Not investment, legal or tax advice.