Subject: Re: [bitcoindev] CTV + CSFS: a letter

From: Jameson Lopp <[email-masked]>
Date: Sun, 15 Jun 2025 10:40:38 -0400

On Sat, Jun 14, 2025 at 5:31 PM Greg Maxwell <[email-masked]> wrote:

> On Sat, Jun 14, 2025 at 8:17 PM Jameson Lopp <[email-masked]>
> 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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_cc2UdbFkFjL7ma9q%3D3mdgWs-s7%2B31UH62bdacmOLXK3A%40mail.gmail.com.