Re: [bitcoindev] CTV + CSFS: a letter

[Greg Maxwell <gmaxwell@gmail.com>]

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

On Sat, Jun 14, 2025 at 11:50 PM Sanket Kanjalkar <sanket1729@gmail.com>
wrote:

> 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.
>

Moving funds back to the initial key that the attacker already has
demonstrated the ability to release from doesn't seem useful to me.  --
though that is a thing the presigned example I gave doesn't do.


> 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.
>

Is there an example of a hack that has been defeated by one?  It would be
interesting to see the exact workflow.

If the scheme is just released into a 'hot area' and the hot area keys have
the power to send the coins anywhere, presumably the attacker will attack
the hot area keys and wait for funds to be moved there and instantly sweep
once they're there.  If the hot area keys are presumed secure, then they
can be multisig on the release from 'cold'.

-- 
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/CAAS2fgTj3o%3DBSUQhCJT4pk_YpSkfT6%2Bw%3DYmss3CntHst3y_DpQ%40mail.gmail.com.

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