From: Greg Maxwell <gmaxwell@gmail•com>
To: Jameson Lopp <jameson.lopp@gmail•com>
Cc: Antoine Poinsot <darosior@protonmail•com>,
Matt Corallo <lf-lists@mattcorallo•com>,
Andrew Poelstra <apoelstra@wpsoftware•net>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
Date: Sat, 14 Jun 2025 21:31:03 +0000 [thread overview]
Message-ID: <CAAS2fgSmmDmEhi3y39MgQj+pKCbksMoVmV_SgQmqMOqfWY_QLg@mail.gmail.com> (raw)
In-Reply-To: <CADL_X_dTK0AtaWQGLzcNBug1=4x7CYn8ypvWAtHVzyGht47wuw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3267 bytes --]
On Sat, Jun 14, 2025 at 8:17 PM Jameson Lopp <jameson.lopp@gmail•com> wrote:
> Sure. As I mentioned in my article years ago, one can technically
> implement covenant functionality today via presigned transactions and
> ephemeral key material. But there is a vast gap between what is technically
> possible and what is practical, which is why I believe you can't find any
> such software in existence. Using presigned transactions means you have to
> regularly update your vault scheme whenever your UTXOs change. This becomes
> incredibly problematic if we're talking about a multisignature setup with
> geographically distributed keys. And ephemeral keys relies upon user being
> able to securely delete key material, which comes with its own host of
> problems.
>
What's the problem for securely deleting? The operation is atomic-- e.g.
software can be written that performs it as a single step and never even
hands the users the private key. If you need to attest to a third party
the ephemeral key can have 1-N multisigners, which has none of the normal
challenges for multisigning since they don't need to retain information or
check anything (in fact, it could even be blinded).
From a durability perspective you also have the same issue of maintaining a
script, if you're avoiding that by always constructing it programmatically
and backing up the scheme, you can more or less do that with the presigned
approach: just stick the ephemeral signature in a taproot annex in the
transaction paying the coins to the 'vault' script and then immediately all
the participants have the required data to deterministically construct the
intermediate transaction.
The result is essentially identical properties to a 'vault' constructed
with CTV and needs no consensus change.
As I see it, a setup where you presign a transaction to sweep funds to an
> emergency address is only particularly useful for the situation in which
> key material becomes inaccessible. It doesn't really help you in the case
> where key material is compromised. Vaults specifically allow for a user to
> recover from a situation in which a signing threshold of keys have been
> compromised.
>
But that is the only kind of vault you can construct from CTV isn't it?
One where the stationary output can go to one of multiple preconstructed
outputs, typically one 'immediately' and the other after a delay that
starts when a particular transaction is released. AFAICT, the CTV approach
does not allow you to stage an output address and then either abort or
allow it to continue.
(though I remain dubious as to the utility of that improvement, since if
you can secure the rescue/abort key you could use the process for the
primary. ... and because of the lack of implementation of these tools in
systems where its already easy to do so...)
--
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/CAAS2fgSmmDmEhi3y39MgQj%2BpKCbksMoVmV_SgQmqMOqfWY_QLg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4218 bytes --]
next prev parent reply other threads:[~2025-06-14 21:40 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 11:40 James O'Beirne
2025-06-09 12:51 ` Michael Folkson
2025-06-09 14:41 ` James O'Beirne
2025-06-09 15:56 ` Michael Folkson
2025-06-09 13:51 ` Matt Corallo
2025-06-09 14:43 ` James O'Beirne
2025-06-09 17:51 ` Matt Corallo
2025-06-09 19:27 ` /dev /fd0
2025-06-09 21:12 ` Matt Corallo
2025-06-09 18:55 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-10 2:02 ` Paul Sztorc
2025-06-09 23:02 ` Andrew Poelstra
2025-06-10 2:08 ` David A. Harding
2025-06-10 13:23 ` Andrew Poelstra
2025-06-10 17:17 ` Matt Corallo
2025-06-10 23:42 ` Antoine Riard
2025-06-12 3:34 ` James O'Beirne
2025-06-13 1:18 ` Antoine Riard
2025-06-10 23:42 ` Antoine Riard
2025-06-11 13:52 ` Peter Todd
2025-06-13 6:19 ` Anthony Towns
2025-06-13 14:50 ` Harsha Goli
2025-06-10 14:03 ` James O'Beirne
2025-06-10 16:56 ` Sjors Provoost
2025-06-10 17:15 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-10 19:04 ` Paul Sztorc
2025-06-11 18:09 ` Brandon Black
2025-06-10 2:28 ` Melvin Carvalho
2025-06-10 13:19 ` Greg Sanders
2025-06-11 14:12 ` James O'Beirne
[not found] ` <CAB3F3Dsf8=rbOyPf1yTQDzyQQX6FAoJWTg16VC8PVs4_uBkeTw@mail.gmail.com>
2025-06-11 16:50 ` James O'Beirne
2025-06-11 18:34 ` James O'Beirne
2025-06-11 20:30 ` Matt Corallo
2025-06-12 0:59 ` Harsha Goli
2025-06-12 18:04 ` Matt Corallo
2025-06-12 18:38 ` James O'Beirne
2025-06-12 18:43 ` Matt Corallo
2025-06-12 19:51 ` Andrew Poelstra
2025-06-12 22:44 ` Matt Corallo
2025-06-13 11:08 ` Jameson Lopp
2025-06-13 12:36 ` Matt Corallo
2025-06-13 13:07 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-13 15:41 ` Jameson Lopp
2025-06-14 15:58 ` Sjors Provoost
2025-06-14 20:05 ` Jameson Lopp
2025-06-14 16:06 ` gmaxwell
2025-06-14 20:17 ` Jameson Lopp
2025-06-14 21:31 ` Greg Maxwell [this message]
2025-06-14 23:50 ` Sanket Kanjalkar
2025-06-15 0:01 ` Greg Maxwell
2025-06-15 0:20 ` Sanket Kanjalkar
2025-06-13 5:50 ` Anthony Towns
2025-06-12 2:06 ` Greg Maxwell
2025-06-12 3:23 ` James O'Beirne
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=CAAS2fgSmmDmEhi3y39MgQj+pKCbksMoVmV_SgQmqMOqfWY_QLg@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(echo .)com \
--cc=jameson.lopp@gmail$(echo .)com \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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