From: Jameson Lopp <jameson.lopp@gmail•com>
To: Antoine Poinsot <darosior@protonmail•com>
Cc: 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: Fri, 13 Jun 2025 11:41:40 -0400 [thread overview]
Message-ID: <CADL_X_faQhCGS78y0Nggm_h=x_cEtshhbrZDDhQ=FEgbDXkc-Q@mail.gmail.com> (raw)
In-Reply-To: <psUO5AHTglJ3KiGM5tTd0sqrFDUexydKzfkOpjOHcWM97OdluX_hIplsXxl_9vzS1pPOqMek3rVBhlzWiPyuvFvz7VmG9FNXapkMG97a7xc=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 6602 bytes --]
Casa (and many other companies focused on custody products) would love to
see vaulting functionality. I don't think any of us are too hung up on the
details of the particular implementation - we would rather have a "good"
tool than not have any tool because consensus has not been achieved for a
"perfect" solution.
What is the problem that makes vaults desirable? It's frankly because
there's no such thing as perfect security. Even if one designs an
architecture that is nearly perfectly secure against external threats, the
issue of internal threats (such as oneself, via social engineering) will
remain. The ability to require high value funds to sit in a "quarantine /
cooldown" address for some period of time before they can be sent to an
arbitrary address enables additional security measures a la watchtowers to
be designed. Being your own bank is still an incredibly scary proposition
because it's quite difficult to design custody solutions that tolerate
failures without leading to catastrophic loss. The more tools that custody
application engineers have available to them, the more guardrails we can
build into wallet software, and thus hopefully the more comfortable we can
make the general public with the idea of taking on the responsibility of
self custody.
To be clear, I'm not aware of CSFS improving the vaulting functionality
already available via CTV. As far as I can tell, CSFS is one of the least
controversial opcodes proposed in a long time and just seems to be an
all-around win with no risks / trade-offs, so why not bundle it in?
I'm not sure how to parse Antoine's claim that CTV+CSFS doesn't enable
vaults given that there has already been a CTV vault client proof of
concept for 3 years: https://github.com/jamesob/simple-ctv-vault
On Fri, Jun 13, 2025 at 9:07 AM Antoine Poinsot <darosior@protonmail•com>
wrote:
> Jameson,
>
> Thanks for sharing. Although i grew more skeptical of the reactive
> security model of vaults as i implemented them in practice for real users,
> i can appreciate people's mileage may vary.
>
> That said, consensus-enforced vaults require a mechanism to forward any
> amount received on a script A to a pre-committed script B. CTV+CSFS does
> not enable this, and a primitive that actually does (like CCV) is more
> controversial because of its potency. I see the CTV+CSFS bundle as
> maximizing "bang for your buck" in terms of capabilities enabled compared
> to the accompanying risk. If we do want vaults, then we need to get past
> the MEVil concerns and much more interesting primitives are actually on the
> table.
>
> I also appreciate that CTV is nice to have for CCV vaults, but a potential
> future use case that is not enabled by one proposal cannot be used to
> motivate said proposal.
>
> Best,
> Antoine Poinsot
> On Friday, June 13th, 2025 at 7:15 AM, Jameson Lopp <
> jameson.lopp@gmail•com> wrote:
>
> > Unlike a generic "We Want Things" sign-on letter, individual messages
> indicating desire to utilize features is way more compelling.
>
> Then I submit my essay from 2 years ago (
> https://blog.casa.io/why-bitcoin-needs-covenants/) and will quote myself:
>
> "There are clearly a LOT of use cases that could potentially be unlocked
> with the right kind of covenant implementation. Personally, having spent 8
> years working on high security multi-signature wallets, I'm most interested
> in vaults. I believe the value they offer is quite straightforward and is
> applicable to every single self-custody bitcoin user, regardless of what
> type of wallet they are running."
>
> - Jameson
>
> On Thu, Jun 12, 2025 at 6:54 PM Matt Corallo <lf-lists@mattcorallo•com>
> wrote:
>
>> To be fair to James, in my (luckily rather brief) experience with
>> Bitcoin-consensus-letter-writing,
>> its nearly impossible to forge a statement that everyone agrees to that
>> is consistently interpreted.
>>
>> Matt
>>
>> On 6/12/25 3:51 PM, Andrew Poelstra wrote:
>> > Le Thu, Jun 12, 2025 at 02:38:13PM -0400, James O'Beirne a écrit :
>> >>
>> >> As the person who coordinated the letter, I can say that this is not an
>> >> accurate characterization of the signers' intent. Everyone who signed
>> >> explicitly wants to see the imminent review, integration, and
>> activation
>> >> planning for CTV+CSFS specifically. The letter is intentionally
>> concise to
>> >> make sure there are no misunderstandings about that.
>> >>
>> >> I spoke to each person on the original list of signatories who either
>> did
>> >> (or didn't) sign and this was made very clear. Some people didn't sign
>> as a
>> >> result of what the letter says.
>> >>
>> >
>> > The letter asks Core to "prioritize the review and integration" on an
>> > accelerated timeline, and that this will "allow" for "activation
>> planning".
>> >
>> > Early drafts of the letter did ask for actual integration and even
>> > activation, but I did not sign any of those early drafts. It was not
>> > until the language was weakened to be about priorities and planning (and
>> > to be a "respectful ask" rather some sort of demand) that I signed on.
>> >
>> >
>> > The letter is concise but unfortunately I think Matt is correct that it
>> > offers a broad range of interpretations, even among the signers.
>> >
>> >
>>
>> --
>> 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/f8b37a59-0897-40df-a08e-7812c806a716%40mattcorallo.com
>> .
>>
> --
> 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/CADL_X_fxwKLdst9tYQqabUsJgu47xhCbwpmyq97ZB-SLWQC9Xw%40mail.gmail.com
> .
>
>
>
--
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/CADL_X_faQhCGS78y0Nggm_h%3Dx_cEtshhbrZDDhQ%3DFEgbDXkc-Q%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9295 bytes --]
next prev parent reply other threads:[~2025-06-14 14:08 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 [this message]
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
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='CADL_X_faQhCGS78y0Nggm_h=x_cEtshhbrZDDhQ=FEgbDXkc-Q@mail.gmail.com' \
--to=jameson.lopp@gmail$(echo .)com \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(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