From: Jameson Lopp <jameson.lopp@gmail•com>
To: Sjors Provoost <sjors@sprovoost•nl>
Cc: 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 16:05:57 -0400 [thread overview]
Message-ID: <CADL_X_fUCR=2O0MUHXBA98oV4+wcJ-qYYrrRjB7h7YER-JKsGA@mail.gmail.com> (raw)
In-Reply-To: <3781512A-0912-4493-AED5-9520A0488949@sprovoost.nl>
[-- Attachment #1: Type: text/plain, Size: 3305 bytes --]
On Sat, Jun 14, 2025 at 11:58 AM Sjors Provoost <sjors@sprovoost•nl> wrote:
> Hi Jameson,
>
> CTV does enable vaults, but the user has to (carefully) move coins into
> the vault themselves. Because CTV commits to the amount, among other
> things, you can't simply publish a vault address and receive arbitrary
> amounts there. They'd be stuck, committing to an impossible to satisfy CTV
> hash.
>
Understood. OP_CCV enables more flexible / user friendly vaults. Sounds
good to me!
I'll just reiterate my previous point that custody software services would
rather have a "good" tool in the hand than a better solution waiting on the
distant horizon.
> There's also the question of what, if anything, the user needs to backup
> after each deposit [0]. It's probably just the deposit transaction id,
> which is arguably something that can be recovered with some (?) work.
>
> OP_CCV enables a more flexible design where the user can receive arbitrary
> amounts directly into their vault address, and with nothing to backup after
> initial setup (seeds + descriptor-like-thing).
>
> Here's a demo functional test for an OP_CCV vault (without CTV):
> https://github.com/bitcoin/bitcoin/pull/32080
>
> The problem with both demos is that they use boutique software. There's
> not yet a potentially interoperable standard to describe these things.
>
> Hopefully some simple vault schemes can be shoehorned into the existing
> output descriptor paradigm [1], because inventing a whole new way of making
> vault-aware wallets interoperable would take many years.
>
> To illustrate such schemes, I'd love to see a working demo using just a
> (patched) Bitcoin Core wallet. Though perhaps a library like BDK[2] is an
> easier platform for such ideation.
>
> - Sjors
>
> [0] https://github.com/jamesob/simple-ctv-vault/issues/9
> [1] https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/8
> [2] https://github.com/bitcoindevkit
>
> > Op 13 jun 2025, om 17:41 heeft Jameson Lopp <jameson.lopp@gmail•com>
> het volgende geschreven:
> >
> [...]
> >
> > 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:
>
>
> [...]
>
> > 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 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.
> >
>
>
--
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_fUCR%3D2O0MUHXBA98oV4%2BwcJ-qYYrrRjB7h7YER-JKsGA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4810 bytes --]
next prev parent reply other threads:[~2025-06-14 20:43 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 [this message]
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_fUCR=2O0MUHXBA98oV4+wcJ-qYYrrRjB7h7YER-JKsGA@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 \
--cc=sjors@sprovoost$(echo .)nl \
/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