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.