From: Anthony Towns <aj@erisian•com.au>
To: Nadav Ivgi <nadav@shesek•info>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
Date: Fri, 14 Mar 2025 13:20:12 +1000 [thread overview]
Message-ID: <Z9OgbC3Zvg1vfrlc@erisian.com.au> (raw)
In-Reply-To: <CAGXD5f3XScYjj-eFu76vNWyRZG1T_wzeTNfgWCAC3qWKL6_n5w@mail.gmail.com> <CAGXD5f3zHuwGq+M1jwBJjpEc3Wd8biwjwnrXu6VhrysQeyivLQ@mail.gmail.com>
On Wed, Mar 12, 2025 at 12:02:27PM +0200, Nadav Ivgi wrote:
> > adding CSFS and discarding the CSFS private key allows
> > you to have a single commitment that can be reused indefinitely.
> With APO alone, you can use one of two constructs:
> 2. Trusted, Infinite - using a simple non-committed signature spending back
> to the same address. This has similar properties to your CTV+CSFS construct.
Right, that's
<01 P> OP_CHECKSIG
as the scriptPubKey, "<sig ANYPREVOUT|ALL>" as the witness, committing to
that scriptPubKey (and an anchor output probably), and after generating
that signature, the private key is discarded.
> Does adding CSFS enable any additional designs?
> I think it's impossible to get Trustless, Infinite short of having full
> introspection abilities (CAT/TXHASH/Elements-like), right?
Direct introspection certainly seems like the easiest approach.
TLUV/OP_VAULT should also get you there I think, despite not providing
full introspection.
> > You could have CTV commit to two inputs, with the second input's entire
> > value being burnt to fees, but that's fairly annoying
> Yes, preparing an exact-sized utxo for fees is indeed annoying. However
> it's not much different from CPFP - an extra tx with the same overall
> number of inputs/outputs, only around 46vB less efficient[0] (assuming you
> need change[1]). So at least for some use-cases it's not terrible either.
CPFP is easier to RBF, so still superior, I think.
> Of course, the most WU-optimal construct is APO|SINGLE (implying ACP) that
> you mentioned, where no extra transaction is needed at all.
A big problem with that is that a griefer can potentially attach large
inputs or outputs to your tx and get their package relayed before yours,
making RBF attempts expensive in high-feerate scenarios, potentially
resulting in nothing being confirmed for an extended period. Could
potentially be solved by TRUC or similar rules (or pure replace-by-feerate
rules), though.
Also, for better or worse, an even more WU-optimal construction is simply
paying miners directly, out of band.
Cheers,
aj
--
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/Z9OgbC3Zvg1vfrlc%40erisian.com.au.
prev parent reply other threads:[~2025-03-14 3:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 0:01 Anthony Towns
2025-03-05 6:14 ` Olaoluwa Osuntokun
2025-03-05 16:14 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-06 17:17 ` Greg Sanders
2025-03-06 18:36 ` 'moonsettler' via Bitcoin Development Mailing List
2025-03-06 21:26 ` Antoine Riard
2025-03-07 21:36 ` Anthony Towns
2025-03-07 21:01 ` Anthony Towns
2025-03-08 15:55 ` James O'Beirne
2025-03-05 17:53 ` 'moonsettler' via Bitcoin Development Mailing List
2025-03-05 22:46 ` Antoine Riard
2025-03-07 21:16 ` Anthony Towns
2025-03-10 22:36 ` Antoine Riard
2025-03-10 5:14 ` Nadav Ivgi
2025-03-12 3:48 ` Anthony Towns
2025-03-12 10:02 ` Nadav Ivgi
2025-03-12 16:15 ` Nadav Ivgi
2025-03-14 3:20 ` Anthony Towns [this message]
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=Z9OgbC3Zvg1vfrlc@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoindev@googlegroups.com \
--cc=nadav@shesek$(echo .)info \
/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