From: Jameson Lopp <jameson.lopp@gmail•com>
To: Greg Maxwell <gmaxwell@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: Sun, 15 Jun 2025 10:40:38 -0400 [thread overview]
Message-ID: <CADL_X_cc2UdbFkFjL7ma9q=3mdgWs-s7+31UH62bdacmOLXK3A@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgSmmDmEhi3y39MgQj+pKCbksMoVmV_SgQmqMOqfWY_QLg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3967 bytes --]
On Sat, Jun 14, 2025 at 5:31 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
> 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).
>
>
It's the same problem as securely generating and storing keys. In order for
presigned transaction vaults to actually be trustworthy then ephemeral key
usage needs to occur on a hardened offline device that is highly unlikely
to be compromised. I'm not aware of any of the hardware manufacturers
offering functionality for generating and signing with ephemeral keys.
> 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.
>
I was referring to presigned transactions for which the original signing
keys still exist, so we're probably talking past each other a bit.
>
> (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/CADL_X_cc2UdbFkFjL7ma9q%3D3mdgWs-s7%2B31UH62bdacmOLXK3A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5586 bytes --]
next prev parent reply other threads:[~2025-06-15 16:11 UTC|newest]
Thread overview: 61+ 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
2025-06-14 23:50 ` Sanket Kanjalkar
2025-06-15 0:01 ` Greg Maxwell
2025-06-15 0:20 ` Sanket Kanjalkar
2025-06-15 14:40 ` Jameson Lopp [this message]
2025-06-15 17:43 ` Greg Maxwell
2025-06-15 19:43 ` Owen Kemeys
2025-06-13 5:50 ` Anthony Towns
2025-06-12 2:06 ` Greg Maxwell
2025-06-12 3:23 ` James O'Beirne
2025-06-17 11:22 ` Steven Roose
2025-06-17 14:34 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-17 16:40 ` Harsha Goli
2025-06-17 18:19 ` /dev /fd0
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='CADL_X_cc2UdbFkFjL7ma9q=3mdgWs-s7+31UH62bdacmOLXK3A@mail.gmail.com' \
--to=jameson.lopp@gmail$(echo .)com \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(echo .)com \
--cc=gmaxwell@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