From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 01 Jan 2026 06:34:14 -0800 Received: from mail-ot1-f62.google.com ([209.85.210.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vbJkj-0002Mg-Oh for bitcoindev@gnusha.org; Thu, 01 Jan 2026 06:34:14 -0800 Received: by mail-ot1-f62.google.com with SMTP id 46e09a7af769-7c75798bfacsf25514685a34.1 for ; Thu, 01 Jan 2026 06:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1767278048; x=1767882848; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=T4dI+IhiXNv7N5GNS6ZbtBMRnLMnuK7B4JdEDrJZYJw=; b=hP8A6NO67OnyOqr078gi/IsfmfvT6SW1yUPq+oB8yZwiLgois/k9KnF72Xz5XE64cL mj/87K8lDQFQYDAA4bLPTekunww4TMwcrwK85frDZEvTZebE9JMHKSOAn4rGaXwQ5Bdy uqupgM7f03/kjnqP5eDvHVEKJyDv1z974uArxan9lfT9XQohkwcEIQgEbBvX3E+p8306 OtCSe+EKRfFjGMbXTdFdGqOnIU2ELUcTQJnJ85IlY4RqYxV+U7VKIj0/XdkNJQYhLKG4 034LgSTC3aLW3aG/LrlFSYaDXHQQvzVHkDP+aUqG6//QjED67uGYGqUsTvKrgAeYtXiM wyVg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767278048; x=1767882848; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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=T4dI+IhiXNv7N5GNS6ZbtBMRnLMnuK7B4JdEDrJZYJw=; b=mgppV3Aeqg9e5NQIEonM3JV4Lsdh2Dd//SOhdYB7h1jR329aS0XGAKDputaz45FVJL oGJXS4jhJ2Jnx4fl0j+ImOASKsDoYOnptrOgC6+pFvq/gT46o0AtdFZbsHmi1WbKAZJJ JtnYIb8HOVTChEb/UgpgNOa29fnRVpbYv00cfFog8a4sGIGnRcikTrK+DGinyII5L5MU fSw0VOxNzOt2mOLEDR+Ms3Y4j0SWNDOegjgcTJ4uEt0TgSuMIVYeHAnFlfpgl1iu3IMR x2jrfgsvvdRM8WvHegwYB4jbRkrWVyvDV/FjwwJ0ICI0NIWWzv1oc8YI5SIzaMaWa/5K dH6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767278048; x=1767882848; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=T4dI+IhiXNv7N5GNS6ZbtBMRnLMnuK7B4JdEDrJZYJw=; b=EtyQU3rOCaN0RJRLmqfoA1rG2frd98XLGHijZL41lXqubeDD8W/GUxMtmx6xtbfzl+ Du2vBb+1WFuuhohZ35HoVqgw36orekoxvd1jS2mHxEaofAmeB4WkAPrF2p26JPTACZoA JZ+mdKrjsBnnXV5atwnNPZUprHgFiE78MPr8ILbFEPxRuXeT3jiO3MQ+hDt5XuWMpUO3 kY+5HM0apWq8YLnWmi6Sp2nxVhHBjD8OGdnfWxGMRD9QG/8JCwwTQIsQQSZBlDUgYZsY /C/P0hm1uJQDEvGMWAsmohxd3H3v7KTN+BsJpxdD/93d2cbCtvbmWhL9IdzJ7KqyYndu cZ7A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXhzMmxOcfuKQ0akjZRpai37K1R3ZYk2+VJ1llPlgPnZQQlto0cWBYNnqZ6WAkhjQA1TcvIFfEGRAFJ@gnusha.org X-Gm-Message-State: AOJu0YyYhaMM/G6SkEvas0Gcgu1xhRsPN56iOXlyYiQqtkEpX628s2qe mpIvnP4DcnLZsXhGzVVozJvn24vhOcippby7XN4tfnLQ4n7o8KCP9Qhe X-Google-Smtp-Source: AGHT+IEFThQ7QOJ1ylwR2JNCJS91fu6WXdPfJpn7gaIl9BBI6qjJ1lMuuxmmQPY6qmZMOGNEen+0Ug== X-Received: by 2002:a05:6830:34a7:b0:7ca:c842:fe2 with SMTP id 46e09a7af769-7cc668a4bc8mr26483862a34.8.1767278047726; Thu, 01 Jan 2026 06:34:07 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWbzWTRi5lnXrrv0XBUaZ6MTCrpluuN6uRhoVxE21ReOZQ==" Received: by 2002:a05:6870:548a:b0:3ec:401f:488b with SMTP id 586e51a60fabf-3fe95673051ls2571708fac.1.-pod-prod-03-us; Thu, 01 Jan 2026 06:34:03 -0800 (PST) X-Received: by 2002:a05:6808:6a8d:b0:450:3ff9:f4ef with SMTP id 5614622812f47-457b21cfbe5mr19426510b6e.56.1767278043638; Thu, 01 Jan 2026 06:34:03 -0800 (PST) Received: by 2002:a05:690c:4a92:b0:786:6c46:840 with SMTP id 00721157ae682-78fb39c9e68ms7b3; Thu, 1 Jan 2026 05:59:45 -0800 (PST) X-Received: by 2002:a05:690e:144c:b0:646:7c2c:be13 with SMTP id 956f58d0204a3-6467c2cbecemr27484771d50.29.1767275984836; Thu, 01 Jan 2026 05:59:44 -0800 (PST) Date: Thu, 1 Jan 2026 05:59:44 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <8fefdd9e-8c71-4e11-9d90-ebbd8e25dc56n@googlegroups.com> 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_913444_2115358565.1767275984392" X-Original-Sender: ekaggata@gmail.com 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.5 (/) ------=_Part_913444_2115358565.1767275984392 Content-Type: multipart/alternative; boundary="----=_Part_913445_1539069906.1767275984392" ------=_Part_913445_1539069906.1767275984392 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 that= =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 delta,= =20 here). Should the BIP actually be something with more flexibility in transaction= =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 the= =20 later transactions may depend on earlier transactions - however in our case= =20 the Recovery Transaction has an nSequence relative-locktime, and therefore= =20 calling testmempoolaccept 'alert-tx' 'recovery-tx' will fail, claiming that= =20 the Alert Transaction UTXO is not confirmed (and the required time window= =20 has not passed). " This sounds like a pretty chunky and important problem (which surprised me,= =20 as in, it never occurred to me). Speaking for myself, I would not rest easy= =20 with a recovery plan that I couldn't unambiguously check as follows: "I=20 really, really want to know that this recovery works, but much more than=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 -> "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 with= =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" where= =20 txid is a 64-character lowercase hexadecimal string and vout is a decimal= =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 already= =20 in alert_tx, no? One last thing, that 388 day limit is a little unfortunate, no? I certainly= =20 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=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-technical= =20 > Bitcoiners. > > Solution: > Pre-signing a pair of transactions: > =E2=80=A2 Alert/Initiate Transaction: A consolidation transaction that ke= eps most=20 > funds on the original wallet (except for a minimal amount that goes to=20 > anchor-addresses, for CPFP acceleration) > =E2=80=A2 Recovery Transaction: A transaction that moves the Bitcoin from= 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, an= d=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 the= =20 > wallet, and will be revoked even if a tiny amount is spent. This mechanis= m=20 > is intended for wallets that are going to remain untouched for a long tim= e. > > 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 the= m=20 > 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, descriptio= n,=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/= aa635296-0522-4ab3-8033-321185ece353n%40googlegroups.com. ------=_Part_913445_1539069906.1767275984392 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 u= seful, at least to the enthusiast that can hand-craft them. Avoiding the "n= eed to refresh every interval" is clearly desirable, though the extra compl= exity *may* end up being more trouble than it's worth (clearly, you don't t= hink so!).

Btw, do you think you should address directly the phi= losophy found in Liana, and what setups they have decided to expose? (i.e. = what's the delta, here).
Should the BIP actually be something wit= h 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 late= r transactions may depend on earlier transactions - however in our case the= Recovery Transaction has an nSequence relative-locktime, and therefore cal= ling testmempoolaccept 'alert-tx' 'recovery-tx' will fail, claiming that th= e Alert Transaction UTXO is not confirmed (and the required time window has= not passed). "

This sounds like a pretty chunky and important p= roblem (which surprised me, as in, it never occurred to me). Speaking for m= yself, I would not rest easy with a recovery plan that I couldn't unambiguo= usly check as follows: "I really, really want to know that this recovery wo= rks, but much more than that, I *must* know that it doesn't work (leak my f= unds) before the intended deadline".

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

Is there a c= ase for requesting a feature in Core that one could do a 'testmempoolaccept= ' with a conditional setting of the time/block height as argument? Would th= at solve this issue? I'm guessing not, as (clue is in the name!) the tool w= as mostly designed around "how does this tx interact with the currently see= n 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 sp= ent by the Alert Transaction. Each input is a string in the format "txid:vo= ut" 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 cha= racters."

I'm probably being an idiot, but: since you're definin= g alert_inputs as just txid:vout, what's the point of including it since th= at data is already in alert_tx, no?

One last thing, t= hat 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 a= t 11: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 s= tarting this thread to discuss whether my idea is BIP-worthy.

Motiva= tion for Timelock-Recovery plans:
Storing seeds for recovery & inher= itance 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 nLockti= me deadline is getting close, which could be annoying (i.e. if the s= eed is split over multiple geographic locations).
Covenants/Vaults are s= till being debated, and could scare less-technical Bitcoiners.

Solut= ion:
Pre-signing a pair of transactions:
=E2=80=A2 Alert/Initiate= Transaction: A consolidation transaction that keeps most funds on the orig= inal wallet (except for a minimal amount that goes to anchor-addresses, for= CPFP acceleration)
=E2=80=A2 Recovery Transaction: A transaction th= at 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 noti= ced that the Alert transaction was mined, and still have the seed or signed= an alternative transaction in advance).

Similar to a single pre-sig= ned transaction with a future nLocktime, = Timelock-Recovery plans will not include new funds that are added to the wa= llet, 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 plugi= n that I've implemented for Electrum (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 fi= le (with detailed manual instructions for less-technological Bitcoiners how= to broadcast them), or in a JSON format.

The BIP will be abo= ut the JSON format, which includes not only the raw transactions themselves= , but also user-information (i.e. name, description, destination-labels, wa= llet-name, wallet-version), and data about the transactions (i.e. txids, am= ounts, fees, input-utxos, anchor-addresses, relative-locktime).
A standa= rd JSON format will allow implementing a compatible feature on other wallet= s, as well as apps/servers for monitoring & initiating timelock-recover= y 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/aa635296-0522-4ab3-8033-321185ece353n%40googlegroups.com.
------=_Part_913445_1539069906.1767275984392-- ------=_Part_913444_2115358565.1767275984392--