From: Sanket Kanjalkar <sanket1729@gmail•com>
To: Greg Maxwell <gmaxwell@gmail•com>
Cc: Jameson Lopp <jameson.lopp@gmail•com>,
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: Sat, 14 Jun 2025 17:20:06 -0700 [thread overview]
Message-ID: <CAExE9c8Gs0toXmv-T3QrBBz9oDPT77VyvByiTL5fE37GOSo2xw@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgTj3o=BSUQhCJT4pk_YpSkfT6+w=Ymss3CntHst3y_DpQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3026 bytes --]
On Sat, Jun 14, 2025 at 5:01 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
> 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.
>
I presume in this case any rational attacker will not attempt something
like this until they know they can succeed. A weaker argument here might be
that this setup by itself would discourage attackers to attempt to continue
:). I can try to look up examples for defeated hacks, but they might be
hard to find.
>
> 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'.
>
Any amount of money that you move in hot wallet can be stolen. The point
here would be limit the theft exposure, for example, you never have more
than X BTC in hot wallets. I agree that this might be awkward to do in
practice with CTV vaults because you have to move the entire UTXO into "hot
area" in order to send change back. Having a powerful vault primitive helps
avoid this issue with change amounts. But in case of CTV, this can be
somewhat mitigated with careful UTXO management.
When moving larger amounts across wallets, you would move them in
increments of X BTC one by one limiting exposure.
--
Sanket Kanjalkar
--
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/CAExE9c8Gs0toXmv-T3QrBBz9oDPT77VyvByiTL5fE37GOSo2xw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4586 bytes --]
next prev parent reply other threads:[~2025-06-15 1:36 UTC|newest]
Thread overview: 54+ 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 [this message]
2025-06-13 5:50 ` Anthony Towns
2025-06-12 2:06 ` Greg Maxwell
2025-06-12 3:23 ` James O'Beirne
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=CAExE9c8Gs0toXmv-T3QrBBz9oDPT77VyvByiTL5fE37GOSo2xw@mail.gmail.com \
--to=sanket1729@gmail$(echo .)com \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(echo .)com \
--cc=gmaxwell@gmail$(echo .)com \
--cc=jameson.lopp@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