From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: BIP idea: Timelock-Recovery storage format
Date: Thu, 1 Jan 2026 05:59:44 -0800 (PST) [thread overview]
Message-ID: <aa635296-0522-4ab3-8033-321185ece353n@googlegroups.com> (raw)
In-Reply-To: <8fefdd9e-8c71-4e11-9d90-ebbd8e25dc56n@googlegroups.com>
[-- 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 --]
next prev parent reply other threads:[~2026-01-01 14:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-28 14:21 [bitcoindev] " 'Oren' via Bitcoin Development Mailing List
2026-01-01 13:59 ` waxwing/ AdamISZ [this message]
2026-01-01 16:18 ` [bitcoindev] " 'Oren' via Bitcoin Development Mailing List
2026-01-01 16:49 ` 'Oren' via Bitcoin Development Mailing List
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aa635296-0522-4ab3-8033-321185ece353n@googlegroups.com \
--to=ekaggata@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox