From: Nadav Ivgi <nadav@shesek•info>
To: Anthony Towns <aj@erisian•com.au>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
Date: Wed, 12 Mar 2025 18:15:31 +0200 [thread overview]
Message-ID: <CAGXD5f3XScYjj-eFu76vNWyRZG1T_wzeTNfgWCAC3qWKL6_n5w@mail.gmail.com> (raw)
In-Reply-To: <CAGXD5f3zHuwGq+M1jwBJjpEc3Wd8biwjwnrXu6VhrysQeyivLQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4421 bytes --]
> One important difference is that for a BMM-like bidding system [..]. But
for other cases, the difference would be negligible.
Actually, thinking about this some more, this could be an issue even
without multiple bidders - the tx preparing the fee utxo might pay
sufficient fees to get itself confirmed, yet not provide enough fees for
the main transaction to confirm too. In this case you'll basically also
have 'losing bids' that waste fees/space and will have to make another tx
to prepare a larger fee utxo.
So yes, pretty annoying. :< More than I initially thought.
shesek
On Wed, Mar 12, 2025 at 12:02 PM Nadav Ivgi <nadav@shesek•info> wrote:
> On Wed, Mar 12, 2025 at 5:48 AM Anthony Towns <aj@erisian•com.au> wrote:
>
>> I think the original COSHV implementation had the hash appear a push
>> *after*
>> the CTV opcode.
>>
>> https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki
>
>
> Yes you are of course correct. My memory failed me, should've looked up
> the BIP :)
>
> With either APO or CTV alone you can do an arbitrarily long chain of
>> commitments,
>
> 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:
>
> 1. Trustless, Finite - using a chain of pre-computed transactions where
> the signature for the next transaction is committed to in the scriptPubKey.
> This has similar properties to what you can get with CTV alone.
>
> 2. Trusted, Infinite - using a simple non-committed signature spending
> back to the same address. This has similar properties to your CTV+CSFS
> construct.
>
> 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?
>
> With Elements it's pretty straightforward, something like
> `OP_PUSHCURRENTINPUTINDEX OP_INSPECTINPUTSCRIPTPUBKEY <0>
> OP_INSPECTOUTPUTSCRIPTPUBKEY OP_ROT OP_EQUALVERIFY OP_EQUAL`
>
> 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.
>
> One important difference is that for a BMM-like bidding system, losing
> bids would still pay tx fees (and take up chain space) for creating the fee
> utxo, unlike with CPFP where only the winning bid pays fees. But for other
> cases, the difference would be negligible.
>
> Of course, the most WU-optimal construct is APO|SINGLE (implying ACP) that
> you mentioned, where no extra transaction is needed at all.
>
> [0] Assuming you need to use N coins for fees and that change is needed,
> with an exact-sized fee utxo you have a N-in, 2-out tx to prepare the fee
> utxo, then a 2-in, 1-out for the main tx - for a total of N+2 inputs and 3
> outputs. With CPFP, its 1-in, 2-out for the main tx, then a N+1-in, 1-out
> tx for the CPFP fee bump - also for a total of N+2 inputs and 3 outputs.
> However, with CPFP you could use Pay-to-Anchor (while the fee utxo has to
> be key-encumbered), saving 65WU for one input plus 30vB/120WU for one
> output, making it more efficient by a total of 185WU/46vB (assuming the fee
> utxo uses key-path P2TR).
>
> [1] If you happen to have an existing utxo to pay fees with, the 2-input
> CTV template would be as efficient as it gets, on par with APO|SINGLE. This
> can be extended to combos of multiple utxos, by adding more CTV tapleaves
> for different numbers of inputs (at a slight cost of larger control
> blocks). With large wallets it could be plausible to find such combos.
>
> Cheers,
> shesek
>
--
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/CAGXD5f3XScYjj-eFu76vNWyRZG1T_wzeTNfgWCAC3qWKL6_n5w%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6133 bytes --]
next prev parent reply other threads:[~2025-03-12 21:51 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 [this message]
2025-03-14 3:20 ` Anthony Towns
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=CAGXD5f3XScYjj-eFu76vNWyRZG1T_wzeTNfgWCAC3qWKL6_n5w@mail.gmail.com \
--to=nadav@shesek$(echo .)info \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoindev@googlegroups.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