BIP128: Timelock-Recovery Storage Format

[oren-z0]

This simple BIP explains what Timelock-Recovery plans are, and how they to store them In a standard JSON format, that services could parse and then monitor/execute.

[murchandamus]

Hi Oren, thanks for your submission. I did a first quick pass. From the formatting, this seems already a good start. I left a few comments and questions.

[murchandamus]

Since the Recovery Transaction appears to spend an output from the Alert Transaction, the Alert transaction is required to be non-malleable. Transactions with non-segwit inputs are always third-party malleable. It therefore seems clear that the Alert Transaction must only have segwit inputs. It’s not clear to me why non-malleability would be necessary for the Recovery Transaction.

Please note that BIP 62 was withdrawn in 2015 and therefore might not be the best choice to express the requirements for the transactions. Either way, it seems to me that it would be useful to be more specific here what exactly the requirements of the transactions are.

[oren-z0]

Fixed, with a reference to BIP 140 instead of BIP 62.

[murchandamus]

Not speaking as an editor, but just as a reviewer, I am a bit on the fence regarding the idea of using an on-chain transaction to notify the user that their recovery transaction will reach maturity soon. Something has to broadcast that alert transaction upon maturity for it to be mined. For the user to see that notification, the user would need to actively monitor the wallet that is paid by the alert transaction. Under those two assumptions, why wouldn’t the daemon/service that broadcasts the alert transaction or the receiving app notify the user by a notification on their phone or send an email?

Perhaps you could expand your Rationale on why a transaction was chosen over other ways to notify the user.

[oren-z0]

Monitoring the blockchain and looking for the alert-transaction is intended for unintentional broadcast, either by accident or by a malicious hacker.
I've added a new line to explain that using a reliable tool to monitor the blockchain and search for the alert transaction - users can keep one or more online backups of the presigned transactions (unlike seed phrases which should never go online).
Someone hacked the online backup and broadcast the Alert Transaction? Not a big deal, you have many days (depending on the Recovery Transaction nSeqeunce) to prevent the majority of funds from moving to the secondary wallet. An nSequence of ~90 days means that you can even monitor the blockchain manually, by setting a monthly reminder to check https://mempool.space/tx/<alert_txid>

Check our https://timelockrecovery.com for a list of services that can do the monitoring (plus I'm working on a new Android app + service that will let you create the presigned transactions and monitor them).

[murchandamus]

I just looked this over again. From an editorial perspective this looks like it’s getting close to publication. Please consider whether your document introduces any potential incompabilities, and if so, add a Backwards Compatibility section.

Other than that, what are the next steps from your perspective? Are you working with any Bitcoin projects that are working on implementing this scheme? Are you expecting any other reviewers to take a look?

[oren-z0]

I just looked this over again. From an editorial perspective this looks like it’s getting close to publication. Please consider whether your document introduces any potential incompabilities, and if so, add a Backwards Compatibility section.

Other than that, what are the next steps from your perspective? Are you working with any Bitcoin projects that are working on implementing this scheme? Are you expecting any other reviewers to take a look?

Thanks again for the thorough review. The current implementation in Electrum matches the BIP description. I also developed a similar plugin for Specter Desktop here, which I don't think matches exactly the BIP - but AFAIK Specter Desktop is not being maintained anymore (except for bug fixes).

A friend and I founded https://ritrek.com based exactly on the BIP idea, and soon we'll release our Android app where users could create/upload recovery-plans and later initiate them, monitor them (get push-notifications on their status, or if the wallet "double-spent" them), and set a dead-man-switch to initiate them automatically after X months if the app hasn't been opened.
I think we have a small market of less-technical Bitcoiners who don't want to switch to a multisig wallet and use one of the "collaborative custody" solutions. It's also more secure in my opinion (no 3rd party key that could leak), but with the downside of not being able to touch that wallet (without re-signing new transactions).

I think the BIP is fine as is and doesn't need more reviewers. I have a small doubt whether we should add the Alert Transaction's inputs' amounts - and allow validating the segwit transaction without querying those UTXOs. On the other hand, any service that accepts such JSON should call testmempoolaccept anyways.

In any case, if there will be major changes in the future to the json format, we can always add a "version" field, or change the "kind" from "timelock-recovery-plan" to "timelock-recovery-plan-v2".

[murchandamus]

Assigned BIP 128. Please update the BIP and Assigned headers, the file name of the document, and add a table entry to the README for your BIP.

[oren-z0]

@murchandamus Pushed the changes. BIP 2^7 🤓

[murchandamus]

Thanks for the quick turnaround. I propose leaving this open for a few more days as often a number assignment will spur some additional review. Please feel free to remind me to take another look on 2026-02-12 or later, if this hasn’t gotten more review or been merged.