From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 01 Jan 2026 08:53:21 -0800 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vbLvM-0005PX-2F for bitcoindev@gnusha.org; Thu, 01 Jan 2026 08:53:21 -0800 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-3fecd1c4e09sf2966096fac.1 for ; Thu, 01 Jan 2026 08:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1767286393; x=1767891193; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=EJOdCJky0RXjT2P92KMUUs1vQUpbGHecFy+4Wd8oulg=; b=QJpdfS5Yiydo0M2iIjhbYJ6uXT3SzndPzVQ6OU8b603SH59gZ3V8C9NQpBWpjZtHxH bHAYsn2BxDocQrRQhQGHmITY/S04gc/NyT5lIDvaJM4EMTJ2UfJzQb/xxvo60ppLDA/S BM2Sy874i3qOeweadv8kocqII61HgLLMLjhmT6WGSc/T7Yh+CMFynt0u4AwZrTe6/Yfh m24gaPPpdymqJySIIdKwBzC/fPIjKymL09hz9noZ1Ris9p65s6z2xXkqjXr4kP/VBBwg f+ONTjH+3OP3FyZliGxuGyJhE07mMg+zb5tyFC5pPqPqpXydAiz4wn0ZMeUAyF2CD0Fv 2NMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767286393; x=1767891193; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EJOdCJky0RXjT2P92KMUUs1vQUpbGHecFy+4Wd8oulg=; b=QJmitPo86w5d9O+zRY9d1bwMLxdW5yC+ZpygSYoyw/CAENP4Yhq8D5blSeeb33DGHp 46/DHkeM1nfozZ1Oc4tSBfIODdebORpYu9tTK0Q2bap6NQl/hWl6DJ4spbcHy73vDjBt bnGIppF9YyS3/3lJ4ItGLMETFdDQkE++8Jhq/YenGR782+2pa7QNv+tAE3DlP5NL1xB6 E4zsSH2MYotXEqxSaxgzsKFCMZlHcf/KVA2DmNDVT20HdZWZDsMbLLtDCKqWC9obIPXI Vgtcm6k655MUbfZ3JkwTtiN+MKqD3/C/0o82qtL36kUiFQ7M2w8wEkYLsN2cgClSE3Lh VnXw== X-Forwarded-Encrypted: i=1; AJvYcCWjAXMeWbdxrqgXVW2UZodBG28EuzfPIyoUPRturM/qXDC+XAeFUEhyc7XLRLvNsk7gBym6B1AG9sfA@gnusha.org X-Gm-Message-State: AOJu0YyKedKSpoxX5mc0QjnTNPB3ZFtiJDJdXm5zHi2fa9qbmLwq5K5Z iPVIYJnKO/bX8TkIn/IxMUT7Ak6KDWLJjz6ULXzz84LeSj/15NMROMKW X-Google-Smtp-Source: AGHT+IHjv3MbhRGVP56Z5LOEWXUXSUOFECPGSas8hZFHlxwo6zfpWFhQ417I2Sg3UPfqV3rX6yEBVQ== X-Received: by 2002:a05:6870:832a:b0:3ec:4435:7c2c with SMTP id 586e51a60fabf-3fda58151famr19087868fac.27.1767286392965; Thu, 01 Jan 2026 08:53:12 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWb86vRLhmHCVlnFdH07acroL/kyIvr+m+9zXLHXqOl3pQ==" Received: by 2002:a05:6870:266:b0:3fa:9f2:b79b with SMTP id 586e51a60fabf-3fa09f2de01ls5753177fac.0.-pod-prod-00-us; Thu, 01 Jan 2026 08:53:08 -0800 (PST) X-Received: by 2002:a05:6808:1987:b0:455:986c:3644 with SMTP id 5614622812f47-457b213ee8dmr17670766b6e.9.1767286388454; Thu, 01 Jan 2026 08:53:08 -0800 (PST) Received: by 2002:a05:690c:688c:b0:786:8d90:70d8 with SMTP id 00721157ae682-78fb3c672f8ms7b3; Thu, 1 Jan 2026 08:49:07 -0800 (PST) X-Received: by 2002:a05:690c:6906:b0:78f:bfa6:75cd with SMTP id 00721157ae682-78fbfa68511mr301393677b3.22.1767286146415; Thu, 01 Jan 2026 08:49:06 -0800 (PST) Date: Thu, 1 Jan 2026 08:49:05 -0800 (PST) From: "'Oren' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <8fefdd9e-8c71-4e11-9d90-ebbd8e25dc56n@googlegroups.com> Subject: [bitcoindev] Re: BIP idea: Timelock-Recovery storage format MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1747586_690834959.1767286145995" X-Original-Sender: orenz0@protonmail.com X-Original-From: Oren Reply-To: Oren Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_1747586_690834959.1767286145995 Content-Type: multipart/alternative; boundary="----=_Part_1747587_218015412.1767286145995" ------=_Part_1747587_218015412.1767286145995 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One more thing to mention - none of the hardware wallets that I've tested= =20 show the custom nSequence fields to the user, and only some show a custom= =20 nLocktime. They just agree to sign whatever nSequence/nLocktime was in the PSBT, even= =20 if they it's not one of the common values (i.e. nSequence of 0xFFFFFFFD -= =20 0xFFFFFFFF). This is an issue regardless of my BIP idea, because a malicious virus could= =20 manipulate the nSequence field before sending it to the hardware wallet,=20 making the user sign transactions that would seem corrupt when they try to= =20 broadcast them, but will become valid in the future. Just as users may wish to verify that all pre-signed transactions are valid= =20 using some custom testmempoolaccept, they may also want to verify the exact= =20 relative-locktime (nSequence) value on their hardware wallet. I wrote a PR for Specter-DIY to show this information, and wish for other= =20 wallets to follow: https://github.com/cryptoadvance/specter-diy/pull/321 Regards, Oren On Thursday, January 1, 2026 at 6:22:40=E2=80=AFPM 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= =20 > Liana, and what setups they have decided to expose? (i.e. what's the delt= a,=20 > here). > Yes, I think it's a good idea to talk about the advantages and=20 > disadvantages of pre-signed transactions vs script-based wallets. I'll ad= d=20 > it to the Motivation section. > > > Should the BIP actually be something with more flexibility in=20 > transaction structure, so as to cover more use-cases? > I think it's good to limit the structure of the transactions, so that=20 > different services could easily integrate this feature. > One guy that I talked to suggested building a more sophisticated sequence= =20 > of transactions with multiple wallets, for example that after 90 days the= =20 > Bitcoin will move to his wife's wallet, from which there will be another= =20 > pre-signed transaction that moves the Bitcoin to his brother's wallet aft= er=20 > 180 days, etc. > But after all, trying to support all custom logics and use-cases will end= =20 > up in a service that compiles general-purpose "code" instead of something= =20 > useful for standard users. > > > Is there a case for requesting a feature in Core that one could do a=20 > 'testmempoolaccept' with a conditional setting of the time/block height a= s=20 > argument? > I've asked for a testmempoolaccept RPC that ignores nSequence/nLocktime= =20 > here: https://github.com/bitcoin/bitcoin/issues/32142=20 > It's a problem even in transactions with a single nLocktime.=20 > testmempoolaccept breaks on the first problem that it finds. Suppose you= =20 > are signing a transaction with a future nLocktime, and testmempoolaccept= =20 > breaks on "non-final" - how do you know that there are no other problems = in=20 > the transaction? How can you tell that the cryptographic signatures are= =20 > good, and what if it's a script-based wallet? > Some worry that complicate the testmempoolaccept RPC diverge from how=20 > transactions are checked in sendrawtransaction, and I somewhat agree with= =20 > that. > Checking the signatures of P2WPKH wallets is straight-forward, but in=20 > order to build a service that verifies the Recovery transaction of a=20 > complicated wallet (i.e. multisig, taproot, etc.), without initiating the= =20 > plan - I guess you would need to run a node with patched code for=20 > testmempoolaccept. > > > I'm probably being an idiot, but: since you're defining alert_inputs as= =20 > just txid:vout, what's the point of including it since that data is alrea= dy=20 > in alert_tx, no? > I did mention that the JSON has some information duplicated. Even the=20 > alert_txid can be calculated from the raw transaction. > This is useful for displaying the information to the user for review. For= =20 > example, a webpage to which you drag-n-drop the JSON file, shows you its= =20 > information and has a button saying "Upload for Monitoring". > This will allow the frontend to show the user the list of UTXOs covered b= y=20 > the recovery-plan, without complicated frontend-code to parse the raw=20 > transaction. > Of course, if the user clicks "Upload for Monitoring" and the backend=20 > finds out that the alert_inputs mismatch the raw transaction, the whole= =20 > process should be rejected with a warning that the file was corrupt=20 > (possibly maliciously). > > > One last thing, that 388 day limit is a little unfortunate, no? I=20 > certainly think a year is a good, reasonable "long time", but still, all= =20 > 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= =20 > from the lowest 16 bits, in units of 512 seconds. > This gives a maximal value of (2^16 - 1) * 512 seconds =3D 33,553,920=20 > seconds =3D 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=E2=80=AFPM UTC+2 waxwing/ AdamISZ= wrote: > >> Hi Oren, list, >> >> I do think this is a really good general idea - and certainly fits into= =20 >> "this could be a BIP". Current covenant-less "deadman's switch" style=20 >> systems are of course limited, but useful, at least to the enthusiast th= at=20 >> can hand-craft them. Avoiding the "need to refresh every interval" is=20 >> clearly desirable, though the extra complexity *may* end up being more= =20 >> trouble than it's worth (clearly, you don't think so!). >> >> Btw, do you think you should address directly the philosophy found in=20 >> Liana, and what setups they have decided to expose? (i.e. what's the del= ta,=20 >> here). >> Should the BIP actually be something with more flexibility in transactio= n=20 >> 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= =20 >> the later transactions may depend on earlier transactions - however in o= ur=20 >> case the Recovery Transaction has an nSequence relative-locktime, and=20 >> therefore calling testmempoolaccept 'alert-tx' 'recovery-tx' will fail,= =20 >> claiming that the Alert Transaction UTXO is not confirmed (and the requi= red=20 >> time window has not passed). " >> >> This sounds like a pretty chunky and important problem (which surprised= =20 >> me, as in, it never occurred to me). Speaking for myself, I would not re= st=20 >> easy with a recovery plan that I couldn't unambiguously check as follows= :=20 >> "I really, really want to know that this recovery works, but much more t= han=20 >> that, I *must* know that it doesn't work (leak my funds) before the=20 >> intended deadline". >> >> With a single nlocktime you can do that (testmempoolaccept ->=20 >> "non-final"). >> >> Is there a case for requesting a feature in Core that one could do a=20 >> 'testmempoolaccept' with a conditional setting of the time/block height = as=20 >> argument? Would that solve this issue? I'm guessing not, as (clue is in = the=20 >> name!) the tool was mostly designed around "how does this tx interact wi= th=20 >> the currently seen mempool" more than "forget conflicts, is this even=20 >> valid/could it ever be valid in and of itself?" (yeah perhaps it's just = an=20 >> incoherent question..?). >> >> "alert_inputs (mandatory): An array of up to 10,000 inputs spent by the= =20 >> Alert Transaction. Each input is a string in the format "txid:vout" wher= e=20 >> txid is a 64-character lowercase hexadecimal string and vout is a decima= l=20 >> number of up to 6 digits. >> alert_tx (mandatory): The raw Alert Transaction in uppercase hexadecimal= =20 >> format. A string of up to 800,000 characters." >> >> I'm probably being an idiot, but: since you're defining alert_inputs as= =20 >> just txid:vout, what's the point of including it since that data is alre= ady=20 >> in alert_tx, no? >> >> One last thing, that 388 day limit is a little unfortunate, no? I=20 >> certainly think a year is a good, reasonable "long time", but still, all= =20 >> the same. >> >> Cheers, >> AdamISZ/waxwing >> >> On Sunday, December 28, 2025 at 11:59:43=E2=80=AFAM UTC-3 Oren wrote: >> >>> Reposting here from BitcoinTalk=20 >>> : >>> >>> After a short talk with Ava Chow during BTC++ Taiwan, I'm starting this= =20 >>> 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= =20 >>> handle and backup due to their immutability. >>> A single pre-signed transaction with a future nLocktime requires=20 >>> "renewal" when the nLocktime deadline is getting close, which could be= =20 >>> annoying (i.e. if the seed is split over multiple geographic locations)= . >>> Covenants/Vaults are still being debated, and could scare less-technica= l=20 >>> Bitcoiners. >>> >>> Solution: >>> Pre-signing a pair of transactions: >>> =E2=80=A2 Alert/Initiate Transaction: A consolidation transaction that = keeps=20 >>> most funds on the original wallet (except for a minimal amount that goe= s to=20 >>> anchor-addresses, for CPFP acceleration) >>> =E2=80=A2 Recovery Transaction: A transaction that moves the Bitcoin fr= om the=20 >>> consolidated UTXO to the secondary-wallet(s), with an nSequence=20 >>> relative-locktime that gives the user enough time to move the funds=20 >>> elsewhere (assuming they noticed that the Alert transaction was mined, = and=20 >>> still have the seed or signed an alternative transaction in advance). >>> >>> Similar to a single pre-signed transaction with a future nLocktime,=20 >>> Timelock-Recovery plans will not include new funds that are added to th= e=20 >>> wallet, and will be revoked even if a tiny amount is spent. This mechan= ism=20 >>> is intended for wallets that are going to remain untouched for a long t= ime. >>> >>> An example implementation can be found in the Timelock Recovery plugin= =20 >>> that I've implemented for Electrum (merged since= =20 >>> Electrum v4.6.0b1). Details and demo videos can be found at:=20 >>> https://timelockrecovery.com. >>> The plugin creates a UI for signing the two transactions, then saving= =20 >>> them either in a PDF file (with detailed manual instructions for=20 >>> less-technological Bitcoiners how to broadcast them), or in a *JSON=20 >>> format*. >>> >>> The BIP will be about the JSON format, which includes not only the raw= =20 >>> transactions themselves, but also user-information (i.e. name, descript= ion,=20 >>> destination-labels, wallet-name, wallet-version), and data about the=20 >>> transactions (i.e. txids, amounts, fees, input-utxos, anchor-addresses,= =20 >>> relative-locktime). >>> A standard JSON format will allow implementing a compatible feature on= =20 >>> other wallets, as well as apps/servers for monitoring & initiating=20 >>> timelock-recovery plans - such as the one being developed by RITREK.com= =20 >>> (disclosure: I'm one of RITREK's founders). >>> >>> Let me know what you think! >>> >>> Oren >>> >>> --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= e76b2eda-aa34-4e47-816f-0ca5d5835ea8n%40googlegroups.com. ------=_Part_1747587_218015412.1767286145995 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One more thing to mention - none of the hardware wallets that I've tested s= how the custom nSequence fields to the user, and only some show a custom nL= ocktime.
They just agree to sign whatever nSequence/nLocktime was in th= e PSBT, even if they it's not one of the common values (i.e. nSequence of 0= xFFFFFFFD - 0xFFFFFFFF).
This is an issue regardless of my BIP id= ea, because a malicious virus could manipulate the nSequence field before s= ending it to the hardware wallet, making the user sign transactions that wo= uld 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=C2=A0te= stmempoolaccept, they may also want to verify the exact relative-loc= ktime (nSequence) value on their hardware wallet.

I wrote a PR for Specter-DIY to show this information, and wish for other= wallets to follow:=C2=A0https://github.com/cryptoadvance/specter-diy/pull/321

Regards,
Oren


On Thursday, January 1, 2026 at 6:22:40=E2=80=AFPM UTC+2 Oren wrote:<= br/>
Hi AdamSZ, li= st,
Thanks for showing interest in the BIP and happy new year.

&g= t; Btw, do you think you should address directly the philosophy found in Li= ana, and what setups they have decided to expose? (i.e. what's the delt= a, 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= 9;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 tra= nsactions, so that different services could easily integrate this feature.<= br>One guy that I talked to suggested building a more sophisticated sequenc= e 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 anoth= er pre-signed transaction that moves the Bitcoin to his brother's walle= t after 180 days, etc.
But after all, trying to support all custom logic= s and use-cases will end up in a service that compiles general-purpose &quo= t;code" instead of something useful for standard users.

> Is= there a case for requesting a feature in Core that one could do a 'tes= tmempoolaccept' with a conditional setting of the time/block height as = argument?
I've asked for a testmempoolacc= ept RPC that ignores nSequence/nLocktime here: https://github.com/bit= coin/bitcoin/issues/32142
It's a problem even in transactions w= ith a single nLocktime. testmempoolaccept= breaks on the first problem that it finds. Suppose you are signing a trans= action with a future nLocktime, and testmempoola= ccept breaks on "non-final" - how do you know that there a= re no other problems in the transaction? How can you tell that the cryptogr= aphic signatures are good, and what if it's a script-based wallet?
S= ome worry that complicate the testmempoolaccept RPC diverge from how transa= ctions are checked in sendrawtransaction,= and I somewhat agree with that.
Checking the signatures of P2WPKH walle= ts is straight-forward, but in order to build a service that verifies the R= ecovery transaction of a complicated wallet (i.e. multisig, taproot, etc.),= without initiating the plan - I guess you would need to run a node with pa= tched 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 d= ata is already in alert_tx, no?
I did mention that the JSON has some inf= ormation duplicated. Even the alert_txid can be calculated from the raw tra= nsaction.
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, show= s you its information and has a button saying "Upload for Monitoring&q= uot;.
This will allow the frontend to show the user the list of UTXOs co= vered by the recovery-plan, without complicated frontend-code to parse the = raw transaction.
Of course, if the user clicks "Upload for Monitori= ng" and the backend finds out that the alert_inputs mismatch the raw t= ransaction, the whole process should be rejected with a warning that the fi= le 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 corre= ct 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 =3D 33,553,920 seconds =3D 388 days, 8 hours and 32 minutes.
Use= rs can obviously choose a shorter cancellation-window.

R= egards,
Oren

On Thursday, January 1, 2026 at 4:34:07=E2=80=AF= 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 sys= tems are of course limited, but useful, at least to the enthusiast that can= hand-craft them. Avoiding the "need to refresh every interval" i= s clearly desirable, though the extra complexity *may* end up being more tr= ouble than it's worth (clearly, you don't think so!).

Btw, d= o 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 tr= ansaction structure, so as to cover more use-cases?

Other comments s= timulated by the BIP text:

"The testmempoolaccept RPC ca= n 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 &#= 39;alert-tx' 'recovery-tx' will fail, claiming that the Alert T= ransaction UTXO is not confirmed (and the required time window has not pass= ed). "

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 w= orks, but much more than that, I *must* know that it doesn't work (leak= my funds) before the intended deadline".

With a single nlockti= me you can do that (testmempoolaccept -> "non-final").

= Is there a case for requesting a feature in Core that one could do a 't= estmempoolaccept' with a conditional setting of the time/block height a= s 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 in= teract with the currently seen mempool" more than "forget conflic= ts, is this even valid/could it ever be valid in and of itself?" (yeah= perhaps it's just an incoherent question..?).

"alert_input= s (mandatory): An array of up to 10,000 inputs spent by the Alert Transacti= on. Each input is a string in the format "txid:vout" where txid i= s 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 up= percase hexadecimal format. A string of up to 800,000 characters."
=
I'm probably being an idiot, but: since you're defining alert_i= nputs as just txid:vout, what's the point of including it since that da= ta is already in alert_tx, no?

One last thing, that 388 d= ay limit is a little unfortunate, no? I certainly think a year is a good, r= easonable "long time", but still, all the same.

Cheers,
AdamISZ/waxwing

On Sunday, December 28, 2025 at 1= 1:59:43=E2=80=AFAM UTC-3 Oren wrote:
Reposting here from BitcoinTalk:

After a short talk with Ava Chow during BTC++ Taiwan, I'm starting t= his 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 saf= er to handle and backup due to their immutability.
A single pre-signed t= ransaction with a future nLocktime requir= es "renewal" when the nLocktime= deadline is getting close, which could be annoying (i.e. if the seed is sp= lit over multiple geographic locations).
Covenants/Vaults are still bein= g debated, and could scare less-technical Bitcoiners.

Solution:
P= re-signing a pair of transactions:
=E2=80=A2 Alert/Initiate Transact= ion: A consolidation transaction that keeps most funds on the original wall= et (except for a minimal amount that goes to anchor-addresses, for CPFP acc= eleration)
=E2=80=A2 Recovery Transaction: A transaction that moves= the Bitcoin from the consolidated UTXO to the secondary-wallet(s), with an= nSequence relative-locktime that gives t= he 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 alte= rnative transaction in advance).

Similar to a single pre-signed tran= saction with a future nLocktime, Timelock= -Recovery plans will not include new funds that are added to the wallet, an= d will be revoked even if a tiny amount is spent. This mechanism is intende= d 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 (merged since Elec= trum 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 t= o 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, wall= et-name, wallet-version), and data about the transactions (i.e. txids, amou= nts, 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 = (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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/e76b2eda-aa34-4e47-816f-0ca5d5835ea8n%40googlegroups.com.
------=_Part_1747587_218015412.1767286145995-- ------=_Part_1747586_690834959.1767286145995--