Re: [bitcoindev] CTV + CSFS: a letter

[Sanket Kanjalkar <sanket1729@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5410 bytes --]

On Sat, Jun 14, 2025 at 2:40 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).
>

> 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.
>
Do you mean arbitrary output address that is unknown at commitment time?
Otherwise, I think the current CTV vault does allow abort/allowing from
"stage area" to "hot area" or abort to "rescue area". While general purpose
recursive vaults will allow funds back into same "cold area", I think it is
possible to also move funds back into same back under the same cold keys
with a bounded recursion CTV provides.


> (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.)
>
Primary key is used often for regular withdrawals from the vault. The
rescue/abort key will only be used in case there is something wrong. If
there is something that you don't intent you use at all, you can go 10
extra steps to secure it. Maybe store in secure guarded physical locations,
or require offchain security authorization protocols to secure them. You
might not do these for regular primary keys if you intend to use them often.

 And even if you secure rescue key as the primary key, there is still value
because the attacker has to get both of them. We can see that in practice,
people use multisig instead of single-sig even though both keys are
probably secured to the same degree of security.


Finally, on the usefulness of vaults; based on my own observation of all
the hacks (bitcoin and wider crypto), in most cases it is not the key that
is stolen but rather the authorization process or UI/UX hacks or something
else up the signing stack is compromised. Having reactive security to
"undo" feels valuable in this scenario.

>
>
>
>
> --
> 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
> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSmmDmEhi3y39MgQj%2BpKCbksMoVmV_SgQmqMOqfWY_QLg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Sanket1729

-- 
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/CAExE9c8oWiy6GUaSMVf2Nxa%2B9a60e2Mw8fg_s8GT4TmfiPMKMQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 7494 bytes --]