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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z9OgbC3Zvg1vfrlc%40erisian.com.au.
