BIP-128: Bitcoin's New Standard for Dead Man's Switches | Bitcoin Index

Bitcoin’s inheritance problem just got a practical solution. BIP-128, merged into the bitcoin/bips repository on February 27, standardizes a format for timelock-recovery plans that work with existing wallets. The timing is uncanny. A day after the merge, CryptoSlate published an article warning that “Bitcoin’s self custody culture created an inheritance time bomb, and 2026 may be when it starts detonating.”

Between 2.3 and 3.7 million BTC are estimated to be permanently lost, with inheritance failures driving a significant chunk of that. Early Bitcoin adopters are aging into years when accidents, illness, and cognitive decline become real risks. “Not your keys, not your coins” works brilliantly for individual sovereignty until the individual dies or becomes incapacitated. Legal documents can’t move Bitcoin. Death certificates can’t reset seed phrases. Families inherit visible but permanently inaccessible wealth.

BIP-128 addresses this without requiring covenant soft forks, complex script-based wallets, or surrendering custody. It’s a dead man’s switch that preserves sovereignty while creating continuity.

The problem: all current solutions have drawbacks

Single pre-signed transaction with nLocktime (BIP-65) is simple but requires periodic renewal. When the locktime deadline approaches, you must access your wallet and spend a UTXO to invalidate the old transaction. Annoying if your seed is split across multiple geographic locations.

Script-based wallets like Liana use OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY to build recovery paths directly into address scripts. They automatically cover new funds and support longer timelocks. But they’re harder to implement correctly on hardware wallets, require wallet migration from standard P2WPKH addresses, and introduce backup complexity (users forget wallet descriptors). Even in the happy path where no recovery is needed, you must periodically renew by spending the UTXO.

Proposed covenant opcodes (OP_VAULT/BIP-345, OP_CHECKCONTRACTVERIFY/BIP-443, OP_CTV/BIP-119) are still in discussion. No timeline for activation. Adoption will be slow even if implemented. They may scare less-technical Bitcoiners.

BIP-128 works with standard wallets today. No new opcodes, no complex scripts, no wallet migration required.

How BIP-128 works: two transactions, one safety window

A timelock-recovery plan consists of two pre-signed transactions:

1. Alert transaction

This is mostly a consolidation transaction. It keeps the majority of funds on your original wallet (in a new, previously unused “alert address”) and sends a small amount to “anchor addresses” for CPFP (Child Pays For Parent) fee acceleration. The transaction must be non-malleable (using Segregated Witness per BIP-140).

When this transaction is mined, it serves as a visible on-chain alarm. If you see it confirmed, your recovery plan has been triggered. You still have time to cancel.

2. Recovery transaction

This is the transaction that actually moves funds to your heir or backup wallet. It spends the alert-address UTXO created by the Alert Transaction and has an nSequence relative-locktime (BIP-68) that creates a cancellation window. The recovery transaction can only be mined X days AFTER the Alert Transaction is confirmed.

The cancellation window: Users specify 2 to 388 days. The nSequence field uses 512-second units, giving a maximum of (2^16 - 1) × 512 seconds = 388 days, 8 hours, 32 minutes.

Because the Alert Transaction consolidates funds back to your own wallet (minus fees and anchor amounts), you always have time to notice and cancel by moving the funds elsewhere with your seed phrase. That’s the critical safety feature.

The JSON standardization: why it matters

The core innovation of BIP-128 isn’t just the two-transaction structure. It’s standardizing the export format so different wallets can generate timelock-recovery plans and different services can monitor and execute them.

The JSON format includes:

Raw transactions (Alert + Recovery, in uppercase hex for QR code efficiency)
Human-readable metadata (name, description, recovery output labels)
Technical data (txids, fees, weights, anchor addresses, alert inputs)
Wallet identification (wallet name, version, plugin version)
Checksum for integrity verification

Why duplicate data that’s already in the raw transactions? So frontend UIs can display plan details (UTXOs covered, destination addresses, cancellation period) before uploading to a service, without needing complex transaction parsing in JavaScript.

Reference implementation: Electrum Wallet has shipped the Timelock Recovery plugin since version 4.6.0b1. Specter Desktop has an implementation under development (PR #2489). RITREK is an Android app for uploading, monitoring, and initiating timelock recovery plans, developed by Oren Z (the BIP author) and team.

Monitoring options: You can manually check transaction IDs on mempool.space or blockstream.info. WoofBot (an Umbrel app) monitors the blockchain for txids and sends Telegram alerts. Cryptocurrency Alerting sends email, push, or phone-call alerts when addresses are active. RITREK offers automated monitoring and initiation.

BIP-128 vs. Liana: two paths to the same goal

Liana wallet is a script-based alternative with built-in timelock recovery. It uses covenant-style opcodes to build recovery paths into address scripts. Recovery paths automatically cover new funds. Timelocks go up to roughly 15 months. But it requires using Liana wallet specifically and migrating funds from standard wallets.

BIP-128 advantage: Simpler, works with any standard wallet, easier hardware wallet support, easier to back up. You don’t need to move existing funds.

Liana advantage: New funds are automatically covered. No need to manually renew when receiving funds.

The BIP-128 specification discusses this comparison explicitly in the “Comparison with Script-Based Wallets” section. The author acknowledges that script-based approaches have benefits but notes they’re harder to implement on hardware wallets and require wallet migration.

I think BIP-128 made the right tradeoff. The 388-day renewal constraint is real, but trying to support all custom logic would turn it into a general-purpose code compiler rather than something useful for standard users.

Technical caveats

Verification is tricky

The testmempoolaccept RPC in Bitcoin Core cannot verify the Recovery Transaction is valid because it has an nSequence relative-locktime. When you try to test both transactions together, testmempoolaccept fails on “non-final” before checking signatures.

Workaround: Services that want to verify recovery plans must parse the Recovery Transaction and manually check signatures, rejecting complicated spending scripts. Discovering the Recovery Transaction is invalid only at execution time could mean funds locked forever.

Bitcoin Core issue #32142 requests a testmempoolaccept mode that ignores nSequence/nLocktime to verify signatures. Until that’s implemented, verification stays manual.

Hardware wallets don’t show nSequence

None of the hardware wallets tested show custom nSequence fields to the user. They blindly sign whatever nSequence/nLocktime is in the PSBT.

Security implication: A malicious virus could manipulate the nSequence field before sending it to the hardware wallet. The user would sign transactions that appear invalid now but become valid in the future. Users may want to verify the exact relative-locktime value independently. This isn’t unique to BIP-128 (it affects all timelock transactions), but it’s a real concern.

Limitations by design

New funds not covered: Only UTXOs that existed when the plan was created are included.
Spending breaks the plan: Any spend from the wallet invalidates the Alert Transaction (all inputs must remain unspent).
Best for cold storage: Not suitable for wallets with regular activity.

Recommended setup: Use a separate daily-use wallet (seed stored where heirs can find it). Move accumulated savings to a highly secure cold wallet (protected by a passphrase only you memorize), then create a timelock-recovery plan for the cold wallet.

Why this matters now

The timing is striking. BIP-128 was proposed in December 2025 after discussion at BTC++ Taiwan, assigned a BIP number on February 5, 2026, and merged on February 27. The next day, CryptoSlate published an inheritance crisis article warning that early Bitcoin adopters are aging into the problem right now.

QuadrigaCX (2019) remains the cautionary tale. Customers were locked out after CEO Gerry Cotten died with exclusive access to cold storage keys. Auditors later found the wallets were empty months before his death, adding fraud to the operational failure. One human, one set of keys equals total lockout when that person cannot act.

Bitcoin has grown large enough to “change a family’s financial future,” as the CryptoSlate article puts it. Most families don’t want to become security engineers. They need clear, executable processes.

BIP-128 fills the space between “no plan” and “full custodian.” It preserves sovereignty while creating continuity. The JSON standardization enables a service ecosystem (monitoring, execution, multi-wallet support) without locking users into a single vendor. The reference implementation already ships in Electrum.

This is a good BIP. Practical, addresses a real problem, works with existing infrastructure. The 388-day constraint will frustrate some ultra-long-term holders who check their wallets less than once a year, but the author is right that the alternative is a Turing-complete mess.

The inheritance time bomb is real. BIP-128 won’t defuse all of it, but it’s a meaningful step toward making Bitcoin inheritable without surrendering what makes it worth inheriting.

Sources

Last updated: March 2, 2026