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