* [bitcoindev] BIP idea: Timelock-Recovery storage format
@ 2025-12-28 14:21 'Oren' via Bitcoin Development Mailing List
2026-01-01 13:59 ` [bitcoindev] " waxwing/ AdamISZ
0 siblings, 1 reply; 4+ messages in thread
From: 'Oren' via Bitcoin Development Mailing List @ 2025-12-28 14:21 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3114 bytes --]
Reposting here from BitcoinTalk
<https://bitcointalk.org/index.php?topic=5569543.0>:
After a short talk with Ava Chow during BTC++ Taiwan, I'm starting this
thread to discuss whether my idea is BIP-worthy.
Motivation for Timelock-Recovery plans:
Storing seeds for recovery & inheritance is scary.
Pre-signed transactions to a secondary-wallet/custodian, are safer to
handle and backup due to their immutability.
A single pre-signed transaction with a future nLocktime requires "renewal"
when the nLocktime deadline is getting close, which could be annoying (i.e.
if the seed is split over multiple geographic locations).
Covenants/Vaults are still being debated, and could scare less-technical
Bitcoiners.
Solution:
Pre-signing a pair of transactions:
• Alert/Initiate Transaction: A consolidation transaction that keeps most
funds on the original wallet (except for a minimal amount that goes to
anchor-addresses, for CPFP acceleration)
• Recovery Transaction: A transaction that moves the Bitcoin from the
consolidated UTXO to the secondary-wallet(s), with an nSequence
relative-locktime that gives the user enough time to move the funds
elsewhere (assuming they noticed that the Alert transaction was mined, and
still have the seed or signed an alternative transaction in advance).
Similar to a single pre-signed transaction with a future nLocktime,
Timelock-Recovery plans will not include new funds that are added to the
wallet, and will be revoked even if a tiny amount is spent. This mechanism
is intended for wallets that are going to remain untouched for a long time.
An example implementation can be found in the Timelock Recovery plugin that
I've implemented for Electrum <https://electrum.org> (merged since Electrum
v4.6.0b1). Details and demo videos can be found at:
https://timelockrecovery.com.
The plugin creates a UI for signing the two transactions, then saving them
either in a PDF file (with detailed manual instructions for
less-technological Bitcoiners how to broadcast them), or in a *JSON format*.
The BIP will be about the JSON format, which includes not only the raw
transactions themselves, but also user-information (i.e. name, description,
destination-labels, wallet-name, wallet-version), and data about the
transactions (i.e. txids, amounts, fees, input-utxos, anchor-addresses,
relative-locktime).
A standard JSON format will allow implementing a compatible feature on
other wallets, as well as apps/servers for monitoring & initiating
timelock-recovery plans - such as the one being developed by RITREK.com
<https://ritrek.com> (disclosure: I'm one of RITREK's founders).
Let me know what you think!
Oren
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8fefdd9e-8c71-4e11-9d90-ebbd8e25dc56n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3823 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [bitcoindev] Re: BIP idea: Timelock-Recovery storage format
2025-12-28 14:21 [bitcoindev] BIP idea: Timelock-Recovery storage format 'Oren' via Bitcoin Development Mailing List
@ 2026-01-01 13:59 ` waxwing/ AdamISZ
2026-01-01 16:18 ` 'Oren' via Bitcoin Development Mailing List
0 siblings, 1 reply; 4+ messages in thread
From: waxwing/ AdamISZ @ 2026-01-01 13:59 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 6156 bytes --]
Hi Oren, list,
I do think this is a really good general idea - and certainly fits into
"this could be a BIP". Current covenant-less "deadman's switch" style
systems are of course limited, but useful, at least to the enthusiast that
can hand-craft them. Avoiding the "need to refresh every interval" is
clearly desirable, though the extra complexity *may* end up being more
trouble than it's worth (clearly, you don't think so!).
Btw, do you think you should address directly the philosophy found in
Liana, and what setups they have decided to expose? (i.e. what's the delta,
here).
Should the BIP actually be something with more flexibility in transaction
structure, so as to cover more use-cases?
Other comments stimulated by the BIP text:
"The testmempoolaccept RPC can receive a list of transactions in which the
later transactions may depend on earlier transactions - however in our case
the Recovery Transaction has an nSequence relative-locktime, and therefore
calling testmempoolaccept 'alert-tx' 'recovery-tx' will fail, claiming that
the Alert Transaction UTXO is not confirmed (and the required time window
has not passed). "
This sounds like a pretty chunky and important problem (which surprised me,
as in, it never occurred to me). Speaking for myself, I would not rest easy
with a recovery plan that I couldn't unambiguously check as follows: "I
really, really want to know that this recovery works, but much more than
that, I *must* know that it doesn't work (leak my funds) before the
intended deadline".
With a single nlocktime you can do that (testmempoolaccept -> "non-final").
Is there a case for requesting a feature in Core that one could do a
'testmempoolaccept' with a conditional setting of the time/block height as
argument? Would that solve this issue? I'm guessing not, as (clue is in the
name!) the tool was mostly designed around "how does this tx interact with
the currently seen mempool" more than "forget conflicts, is this even
valid/could it ever be valid in and of itself?" (yeah perhaps it's just an
incoherent question..?).
"alert_inputs (mandatory): An array of up to 10,000 inputs spent by the
Alert Transaction. Each input is a string in the format "txid:vout" where
txid is a 64-character lowercase hexadecimal string and vout is a decimal
number of up to 6 digits.
alert_tx (mandatory): The raw Alert Transaction in uppercase hexadecimal
format. A string of up to 800,000 characters."
I'm probably being an idiot, but: since you're defining alert_inputs as
just txid:vout, what's the point of including it since that data is already
in alert_tx, no?
One last thing, that 388 day limit is a little unfortunate, no? I certainly
think a year is a good, reasonable "long time", but still, all the same.
Cheers,
AdamISZ/waxwing
On Sunday, December 28, 2025 at 11:59:43 AM UTC-3 Oren wrote:
> Reposting here from BitcoinTalk
> <https://bitcointalk.org/index.php?topic=5569543.0>:
>
> After a short talk with Ava Chow during BTC++ Taiwan, I'm starting this
> thread to discuss whether my idea is BIP-worthy.
>
> Motivation for Timelock-Recovery plans:
> Storing seeds for recovery & inheritance is scary.
> Pre-signed transactions to a secondary-wallet/custodian, are safer to
> handle and backup due to their immutability.
> A single pre-signed transaction with a future nLocktime requires
> "renewal" when the nLocktime deadline is getting close, which could be
> annoying (i.e. if the seed is split over multiple geographic locations).
> Covenants/Vaults are still being debated, and could scare less-technical
> Bitcoiners.
>
> Solution:
> Pre-signing a pair of transactions:
> • Alert/Initiate Transaction: A consolidation transaction that keeps most
> funds on the original wallet (except for a minimal amount that goes to
> anchor-addresses, for CPFP acceleration)
> • Recovery Transaction: A transaction that moves the Bitcoin from the
> consolidated UTXO to the secondary-wallet(s), with an nSequence
> relative-locktime that gives the user enough time to move the funds
> elsewhere (assuming they noticed that the Alert transaction was mined, and
> still have the seed or signed an alternative transaction in advance).
>
> Similar to a single pre-signed transaction with a future nLocktime,
> Timelock-Recovery plans will not include new funds that are added to the
> wallet, and will be revoked even if a tiny amount is spent. This mechanism
> is intended for wallets that are going to remain untouched for a long time.
>
> An example implementation can be found in the Timelock Recovery plugin
> that I've implemented for Electrum <https://electrum.org> (merged since
> Electrum v4.6.0b1). Details and demo videos can be found at:
> https://timelockrecovery.com.
> The plugin creates a UI for signing the two transactions, then saving them
> either in a PDF file (with detailed manual instructions for
> less-technological Bitcoiners how to broadcast them), or in a *JSON
> format*.
>
> The BIP will be about the JSON format, which includes not only the raw
> transactions themselves, but also user-information (i.e. name, description,
> destination-labels, wallet-name, wallet-version), and data about the
> transactions (i.e. txids, amounts, fees, input-utxos, anchor-addresses,
> relative-locktime).
> A standard JSON format will allow implementing a compatible feature on
> other wallets, as well as apps/servers for monitoring & initiating
> timelock-recovery plans - such as the one being developed by RITREK.com
> <https://ritrek.com> (disclosure: I'm one of RITREK's founders).
>
> Let me know what you think!
>
> Oren
>
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aa635296-0522-4ab3-8033-321185ece353n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7853 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [bitcoindev] Re: BIP idea: Timelock-Recovery storage format
2026-01-01 13:59 ` [bitcoindev] " waxwing/ AdamISZ
@ 2026-01-01 16:18 ` 'Oren' via Bitcoin Development Mailing List
2026-01-01 16:49 ` 'Oren' via Bitcoin Development Mailing List
0 siblings, 1 reply; 4+ messages in thread
From: 'Oren' via Bitcoin Development Mailing List @ 2026-01-01 16:18 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 10191 bytes --]
Hi AdamSZ, list,
Thanks for showing interest in the BIP and happy new year.
> Btw, do you think you should address directly the philosophy found in
Liana, and what setups they have decided to expose? (i.e. what's the delta,
here).
Yes, I think it's a good idea to talk about the advantages and
disadvantages of pre-signed transactions vs script-based wallets. I'll add
it to the Motivation section.
> Should the BIP actually be something with more flexibility in transaction
structure, so as to cover more use-cases?
I think it's good to limit the structure of the transactions, so that
different services could easily integrate this feature.
One guy that I talked to suggested building a more sophisticated sequence
of transactions with multiple wallets, for example that after 90 days the
Bitcoin will move to his wife's wallet, from which there will be another
pre-signed transaction that moves the Bitcoin to his brother's wallet after
180 days, etc.
But after all, trying to support all custom logics and use-cases will end
up in a service that compiles general-purpose "code" instead of something
useful for standard users.
> Is there a case for requesting a feature in Core that one could do a
'testmempoolaccept' with a conditional setting of the time/block height as
argument?
I've asked for a testmempoolaccept RPC that ignores nSequence/nLocktime
here: https://github.com/bitcoin/bitcoin/issues/32142
It's a problem even in transactions with a single nLocktime.
testmempoolaccept breaks on the first problem that it finds. Suppose you
are signing a transaction with a future nLocktime, and testmempoolaccept
breaks on "non-final" - how do you know that there are no other problems in
the transaction? How can you tell that the cryptographic signatures are
good, and what if it's a script-based wallet?
Some worry that complicate the testmempoolaccept RPC diverge from how
transactions are checked in sendrawtransaction, and I somewhat agree with
that.
Checking the signatures of P2WPKH wallets is straight-forward, but in order
to build a service that verifies the Recovery transaction of a complicated
wallet (i.e. multisig, taproot, etc.), without initiating the plan - I
guess you would need to run a node with patched code for testmempoolaccept.
> I'm probably being an idiot, but: since you're defining alert_inputs as
just txid:vout, what's the point of including it since that data is already
in alert_tx, no?
I did mention that the JSON has some information duplicated. Even the
alert_txid can be calculated from the raw transaction.
This is useful for displaying the information to the user for review. For
example, a webpage to which you drag-n-drop the JSON file, shows you its
information and has a button saying "Upload for Monitoring".
This will allow the frontend to show the user the list of UTXOs covered by
the recovery-plan, without complicated frontend-code to parse the raw
transaction.
Of course, if the user clicks "Upload for Monitoring" and the backend finds
out that the alert_inputs mismatch the raw transaction, the whole process
should be rejected with a warning that the file was corrupt (possibly
maliciously).
> One last thing, that 388 day limit is a little unfortunate, no? I
certainly think a year is a good, reasonable "long time", but still, all
the same.
388 days is just the maximal value that you get from BIP-68:
After setting the correct bit flags, the relative-locktime is calculated
from the lowest 16 bits, in units of 512 seconds.
This gives a maximal value of (2^16 - 1) * 512 seconds = 33,553,920 seconds
= 388 days, 8 hours and 32 minutes.
Users can obviously choose a shorter cancellation-window.
Regards,
Oren
On Thursday, January 1, 2026 at 4:34:07 PM UTC+2 waxwing/ AdamISZ wrote:
> Hi Oren, list,
>
> I do think this is a really good general idea - and certainly fits into
> "this could be a BIP". Current covenant-less "deadman's switch" style
> systems are of course limited, but useful, at least to the enthusiast that
> can hand-craft them. Avoiding the "need to refresh every interval" is
> clearly desirable, though the extra complexity *may* end up being more
> trouble than it's worth (clearly, you don't think so!).
>
> Btw, do you think you should address directly the philosophy found in
> Liana, and what setups they have decided to expose? (i.e. what's the delta,
> here).
> Should the BIP actually be something with more flexibility in transaction
> structure, so as to cover more use-cases?
>
> Other comments stimulated by the BIP text:
>
> "The testmempoolaccept RPC can receive a list of transactions in which the
> later transactions may depend on earlier transactions - however in our case
> the Recovery Transaction has an nSequence relative-locktime, and therefore
> calling testmempoolaccept 'alert-tx' 'recovery-tx' will fail, claiming that
> the Alert Transaction UTXO is not confirmed (and the required time window
> has not passed). "
>
> This sounds like a pretty chunky and important problem (which surprised
> me, as in, it never occurred to me). Speaking for myself, I would not rest
> easy with a recovery plan that I couldn't unambiguously check as follows:
> "I really, really want to know that this recovery works, but much more than
> that, I *must* know that it doesn't work (leak my funds) before the
> intended deadline".
>
> With a single nlocktime you can do that (testmempoolaccept -> "non-final").
>
> Is there a case for requesting a feature in Core that one could do a
> 'testmempoolaccept' with a conditional setting of the time/block height as
> argument? Would that solve this issue? I'm guessing not, as (clue is in the
> name!) the tool was mostly designed around "how does this tx interact with
> the currently seen mempool" more than "forget conflicts, is this even
> valid/could it ever be valid in and of itself?" (yeah perhaps it's just an
> incoherent question..?).
>
> "alert_inputs (mandatory): An array of up to 10,000 inputs spent by the
> Alert Transaction. Each input is a string in the format "txid:vout" where
> txid is a 64-character lowercase hexadecimal string and vout is a decimal
> number of up to 6 digits.
> alert_tx (mandatory): The raw Alert Transaction in uppercase hexadecimal
> format. A string of up to 800,000 characters."
>
> I'm probably being an idiot, but: since you're defining alert_inputs as
> just txid:vout, what's the point of including it since that data is already
> in alert_tx, no?
>
> One last thing, that 388 day limit is a little unfortunate, no? I
> certainly think a year is a good, reasonable "long time", but still, all
> the same.
>
> Cheers,
> AdamISZ/waxwing
>
> On Sunday, December 28, 2025 at 11:59:43 AM UTC-3 Oren wrote:
>
>> Reposting here from BitcoinTalk
>> <https://bitcointalk.org/index.php?topic=5569543.0>:
>>
>> After a short talk with Ava Chow during BTC++ Taiwan, I'm starting this
>> thread to discuss whether my idea is BIP-worthy.
>>
>> Motivation for Timelock-Recovery plans:
>> Storing seeds for recovery & inheritance is scary.
>> Pre-signed transactions to a secondary-wallet/custodian, are safer to
>> handle and backup due to their immutability.
>> A single pre-signed transaction with a future nLocktime requires
>> "renewal" when the nLocktime deadline is getting close, which could be
>> annoying (i.e. if the seed is split over multiple geographic locations).
>> Covenants/Vaults are still being debated, and could scare less-technical
>> Bitcoiners.
>>
>> Solution:
>> Pre-signing a pair of transactions:
>> • Alert/Initiate Transaction: A consolidation transaction that keeps
>> most funds on the original wallet (except for a minimal amount that goes to
>> anchor-addresses, for CPFP acceleration)
>> • Recovery Transaction: A transaction that moves the Bitcoin from the
>> consolidated UTXO to the secondary-wallet(s), with an nSequence
>> relative-locktime that gives the user enough time to move the funds
>> elsewhere (assuming they noticed that the Alert transaction was mined, and
>> still have the seed or signed an alternative transaction in advance).
>>
>> Similar to a single pre-signed transaction with a future nLocktime,
>> Timelock-Recovery plans will not include new funds that are added to the
>> wallet, and will be revoked even if a tiny amount is spent. This mechanism
>> is intended for wallets that are going to remain untouched for a long time.
>>
>> An example implementation can be found in the Timelock Recovery plugin
>> that I've implemented for Electrum <https://electrum.org> (merged since
>> Electrum v4.6.0b1). Details and demo videos can be found at:
>> https://timelockrecovery.com.
>> The plugin creates a UI for signing the two transactions, then saving
>> them either in a PDF file (with detailed manual instructions for
>> less-technological Bitcoiners how to broadcast them), or in a *JSON
>> format*.
>>
>> The BIP will be about the JSON format, which includes not only the raw
>> transactions themselves, but also user-information (i.e. name, description,
>> destination-labels, wallet-name, wallet-version), and data about the
>> transactions (i.e. txids, amounts, fees, input-utxos, anchor-addresses,
>> relative-locktime).
>> A standard JSON format will allow implementing a compatible feature on
>> other wallets, as well as apps/servers for monitoring & initiating
>> timelock-recovery plans - such as the one being developed by RITREK.com
>> <https://ritrek.com> (disclosure: I'm one of RITREK's founders).
>>
>> Let me know what you think!
>>
>> Oren
>>
>>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a4295d52-8553-42d6-82d6-5605476d3c38n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 12315 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [bitcoindev] Re: BIP idea: Timelock-Recovery storage format
2026-01-01 16:18 ` 'Oren' via Bitcoin Development Mailing List
@ 2026-01-01 16:49 ` 'Oren' via Bitcoin Development Mailing List
0 siblings, 0 replies; 4+ messages in thread
From: 'Oren' via Bitcoin Development Mailing List @ 2026-01-01 16:49 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 11529 bytes --]
One more thing to mention - none of the hardware wallets that I've tested
show the custom nSequence fields to the user, and only some show a custom
nLocktime.
They just agree to sign whatever nSequence/nLocktime was in the PSBT, even
if they it's not one of the common values (i.e. nSequence of 0xFFFFFFFD -
0xFFFFFFFF).
This is an issue regardless of my BIP idea, because a malicious virus could
manipulate the nSequence field before sending it to the hardware wallet,
making the user sign transactions that would seem corrupt when they try to
broadcast them, but will become valid in the future.
Just as users may wish to verify that all pre-signed transactions are valid
using some custom testmempoolaccept, they may also want to verify the exact
relative-locktime (nSequence) value on their hardware wallet.
I wrote a PR for Specter-DIY to show this information, and wish for other
wallets to follow: https://github.com/cryptoadvance/specter-diy/pull/321
Regards,
Oren
On Thursday, January 1, 2026 at 6:22:40 PM UTC+2 Oren wrote:
> Hi AdamSZ, list,
> Thanks for showing interest in the BIP and happy new year.
>
> > Btw, do you think you should address directly the philosophy found in
> Liana, and what setups they have decided to expose? (i.e. what's the delta,
> here).
> Yes, I think it's a good idea to talk about the advantages and
> disadvantages of pre-signed transactions vs script-based wallets. I'll add
> it to the Motivation section.
>
> > Should the BIP actually be something with more flexibility in
> transaction structure, so as to cover more use-cases?
> I think it's good to limit the structure of the transactions, so that
> different services could easily integrate this feature.
> One guy that I talked to suggested building a more sophisticated sequence
> of transactions with multiple wallets, for example that after 90 days the
> Bitcoin will move to his wife's wallet, from which there will be another
> pre-signed transaction that moves the Bitcoin to his brother's wallet after
> 180 days, etc.
> But after all, trying to support all custom logics and use-cases will end
> up in a service that compiles general-purpose "code" instead of something
> useful for standard users.
>
> > Is there a case for requesting a feature in Core that one could do a
> 'testmempoolaccept' with a conditional setting of the time/block height as
> argument?
> I've asked for a testmempoolaccept RPC that ignores nSequence/nLocktime
> here: https://github.com/bitcoin/bitcoin/issues/32142
> It's a problem even in transactions with a single nLocktime.
> testmempoolaccept breaks on the first problem that it finds. Suppose you
> are signing a transaction with a future nLocktime, and testmempoolaccept
> breaks on "non-final" - how do you know that there are no other problems in
> the transaction? How can you tell that the cryptographic signatures are
> good, and what if it's a script-based wallet?
> Some worry that complicate the testmempoolaccept RPC diverge from how
> transactions are checked in sendrawtransaction, and I somewhat agree with
> that.
> Checking the signatures of P2WPKH wallets is straight-forward, but in
> order to build a service that verifies the Recovery transaction of a
> complicated wallet (i.e. multisig, taproot, etc.), without initiating the
> plan - I guess you would need to run a node with patched code for
> testmempoolaccept.
>
> > I'm probably being an idiot, but: since you're defining alert_inputs as
> just txid:vout, what's the point of including it since that data is already
> in alert_tx, no?
> I did mention that the JSON has some information duplicated. Even the
> alert_txid can be calculated from the raw transaction.
> This is useful for displaying the information to the user for review. For
> example, a webpage to which you drag-n-drop the JSON file, shows you its
> information and has a button saying "Upload for Monitoring".
> This will allow the frontend to show the user the list of UTXOs covered by
> the recovery-plan, without complicated frontend-code to parse the raw
> transaction.
> Of course, if the user clicks "Upload for Monitoring" and the backend
> finds out that the alert_inputs mismatch the raw transaction, the whole
> process should be rejected with a warning that the file was corrupt
> (possibly maliciously).
>
> > One last thing, that 388 day limit is a little unfortunate, no? I
> certainly think a year is a good, reasonable "long time", but still, all
> the same.
> 388 days is just the maximal value that you get from BIP-68:
> After setting the correct bit flags, the relative-locktime is calculated
> from the lowest 16 bits, in units of 512 seconds.
> This gives a maximal value of (2^16 - 1) * 512 seconds = 33,553,920
> seconds = 388 days, 8 hours and 32 minutes.
> Users can obviously choose a shorter cancellation-window.
>
> Regards,
> Oren
>
> On Thursday, January 1, 2026 at 4:34:07 PM UTC+2 waxwing/ AdamISZ wrote:
>
>> Hi Oren, list,
>>
>> I do think this is a really good general idea - and certainly fits into
>> "this could be a BIP". Current covenant-less "deadman's switch" style
>> systems are of course limited, but useful, at least to the enthusiast that
>> can hand-craft them. Avoiding the "need to refresh every interval" is
>> clearly desirable, though the extra complexity *may* end up being more
>> trouble than it's worth (clearly, you don't think so!).
>>
>> Btw, do you think you should address directly the philosophy found in
>> Liana, and what setups they have decided to expose? (i.e. what's the delta,
>> here).
>> Should the BIP actually be something with more flexibility in transaction
>> structure, so as to cover more use-cases?
>>
>> Other comments stimulated by the BIP text:
>>
>> "The testmempoolaccept RPC can receive a list of transactions in which
>> the later transactions may depend on earlier transactions - however in our
>> case the Recovery Transaction has an nSequence relative-locktime, and
>> therefore calling testmempoolaccept 'alert-tx' 'recovery-tx' will fail,
>> claiming that the Alert Transaction UTXO is not confirmed (and the required
>> time window has not passed). "
>>
>> This sounds like a pretty chunky and important problem (which surprised
>> me, as in, it never occurred to me). Speaking for myself, I would not rest
>> easy with a recovery plan that I couldn't unambiguously check as follows:
>> "I really, really want to know that this recovery works, but much more than
>> that, I *must* know that it doesn't work (leak my funds) before the
>> intended deadline".
>>
>> With a single nlocktime you can do that (testmempoolaccept ->
>> "non-final").
>>
>> Is there a case for requesting a feature in Core that one could do a
>> 'testmempoolaccept' with a conditional setting of the time/block height as
>> argument? Would that solve this issue? I'm guessing not, as (clue is in the
>> name!) the tool was mostly designed around "how does this tx interact with
>> the currently seen mempool" more than "forget conflicts, is this even
>> valid/could it ever be valid in and of itself?" (yeah perhaps it's just an
>> incoherent question..?).
>>
>> "alert_inputs (mandatory): An array of up to 10,000 inputs spent by the
>> Alert Transaction. Each input is a string in the format "txid:vout" where
>> txid is a 64-character lowercase hexadecimal string and vout is a decimal
>> number of up to 6 digits.
>> alert_tx (mandatory): The raw Alert Transaction in uppercase hexadecimal
>> format. A string of up to 800,000 characters."
>>
>> I'm probably being an idiot, but: since you're defining alert_inputs as
>> just txid:vout, what's the point of including it since that data is already
>> in alert_tx, no?
>>
>> One last thing, that 388 day limit is a little unfortunate, no? I
>> certainly think a year is a good, reasonable "long time", but still, all
>> the same.
>>
>> Cheers,
>> AdamISZ/waxwing
>>
>> On Sunday, December 28, 2025 at 11:59:43 AM UTC-3 Oren wrote:
>>
>>> Reposting here from BitcoinTalk
>>> <https://bitcointalk.org/index.php?topic=5569543.0>:
>>>
>>> After a short talk with Ava Chow during BTC++ Taiwan, I'm starting this
>>> thread to discuss whether my idea is BIP-worthy.
>>>
>>> Motivation for Timelock-Recovery plans:
>>> Storing seeds for recovery & inheritance is scary.
>>> Pre-signed transactions to a secondary-wallet/custodian, are safer to
>>> handle and backup due to their immutability.
>>> A single pre-signed transaction with a future nLocktime requires
>>> "renewal" when the nLocktime deadline is getting close, which could be
>>> annoying (i.e. if the seed is split over multiple geographic locations).
>>> Covenants/Vaults are still being debated, and could scare less-technical
>>> Bitcoiners.
>>>
>>> Solution:
>>> Pre-signing a pair of transactions:
>>> • Alert/Initiate Transaction: A consolidation transaction that keeps
>>> most funds on the original wallet (except for a minimal amount that goes to
>>> anchor-addresses, for CPFP acceleration)
>>> • Recovery Transaction: A transaction that moves the Bitcoin from the
>>> consolidated UTXO to the secondary-wallet(s), with an nSequence
>>> relative-locktime that gives the user enough time to move the funds
>>> elsewhere (assuming they noticed that the Alert transaction was mined, and
>>> still have the seed or signed an alternative transaction in advance).
>>>
>>> Similar to a single pre-signed transaction with a future nLocktime,
>>> Timelock-Recovery plans will not include new funds that are added to the
>>> wallet, and will be revoked even if a tiny amount is spent. This mechanism
>>> is intended for wallets that are going to remain untouched for a long time.
>>>
>>> An example implementation can be found in the Timelock Recovery plugin
>>> that I've implemented for Electrum <https://electrum.org> (merged since
>>> Electrum v4.6.0b1). Details and demo videos can be found at:
>>> https://timelockrecovery.com.
>>> The plugin creates a UI for signing the two transactions, then saving
>>> them either in a PDF file (with detailed manual instructions for
>>> less-technological Bitcoiners how to broadcast them), or in a *JSON
>>> format*.
>>>
>>> The BIP will be about the JSON format, which includes not only the raw
>>> transactions themselves, but also user-information (i.e. name, description,
>>> destination-labels, wallet-name, wallet-version), and data about the
>>> transactions (i.e. txids, amounts, fees, input-utxos, anchor-addresses,
>>> relative-locktime).
>>> A standard JSON format will allow implementing a compatible feature on
>>> other wallets, as well as apps/servers for monitoring & initiating
>>> timelock-recovery plans - such as the one being developed by RITREK.com
>>> <https://ritrek.com> (disclosure: I'm one of RITREK's founders).
>>>
>>> Let me know what you think!
>>>
>>> Oren
>>>
>>>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e76b2eda-aa34-4e47-816f-0ca5d5835ea8n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 14115 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-01-01 16:53 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-12-28 14:21 [bitcoindev] BIP idea: Timelock-Recovery storage format 'Oren' via Bitcoin Development Mailing List
2026-01-01 13:59 ` [bitcoindev] " waxwing/ AdamISZ
2026-01-01 16:18 ` 'Oren' via Bitcoin Development Mailing List
2026-01-01 16:49 ` 'Oren' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox