rich1.0npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwhttps://nostr.ae/npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwnjumphttps://nostr.ae📅 Original date posted:2022-04-21 📝 Original message:On Thu, Apr 21, 2022 at 1:04 AM Anthony Towns via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > > - is there really any benefit to doing it as a NOP vs a taproot-only > opcode like TXHASH? Theoretically, sure, that saves some bytes; but as > was pointed out on #bitcoin-wizards the other day, you can't express > those outputs as an address, which makes them not very interoperable, > and if they're not interoperable between, say, an exchange and its > users trying to do a withdraw, how useful is that really ever going > to be? > FWIW, this is also approximately where my sticking point lies with BIP-119. Overall I've come around to the idea of something like CTV. The ability to construct "smart contracts" that commit to *multiple* possible payout schemes based on some conditions seems like a very useful construct, and there have been several examples of schemes proposed that use this feature. However, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told that bare-CTV hasn't even appeared on the CTV signet). Unlike the general smart-contracting case, bare-CTV does not have any branches. All it can do is commit to a subsequent transaction's outputs. At first glance this appears to be a waste because, for less bandwidth, that transaction could just realize those outputs immediately, so why would anyone want to delay the inevitable? One reason might be that you want to commit to the output early during a high-fee time, and then complete the transaction later during a low-fee time. While there are fee-rate situations where this could result in lower fees than committing to the outputs all at once, it would be even cheaper still to just wait to do the payout at the low-fee time. I'm struggling to understand the advantages of the advanced commitment, along with all the overhead that entails. Doesn't it just cause more blockspace to be used overall? There are some other proposed use cases for bare-CTV. A bare-CTV can be used to delay a "trigger"-transaction. Some contracts, such as vaults, use a relative-locktime as part of their construction and it could make sense to make an output commitment but not realize those outputs yet until you are ready to start your relative-time lock clock. But bare-CTV doesn't support any co-signing ability here, so you are relying entirely on keeping the transaction data secret to prevent a third-party from triggering your relative-lock clock. More specifically for a vault scheme, since bare-CTV's are currently unaddressable, and AFAIK, there is no address format proposal yet, it is impossible to receive funds directly into a vault. You must shuffle received funds into your vault yourself, which seems very likely to negate the cost savings of using bare-CTV in the first place (please correct me if I'm wrong). Better to receive funds directly into a taproot-CTV vault, which has an address, and while you are at it, you could place the cold-key as the taproot key to save even more when using the cold-key to move vault funds. There might be even more exotic use cases of bare-CTV. For example you could commit to a transaction that has a second input that doesn't yet exist in the UTXO set in an attempt to coax it into existence. I don't know if there have been any proposals to take advantage of this. With that said, everything that bare-CTV can do, can also be done by tapscript-CTV; so it is just a matter of cost. I'm struggling to understand where this cost savings is and how much those savings are going to be given that bare-CTV is unaddressable and seems to ultimately occupy more-blockspace than if the outputs were directly committed to. I also believe the bare-CTV question is material, because if bare-CTV were not part of the spec, then I'd be advocating for using an OP_SUCCESS code from tapscript instead, and either use push-style semantics for CTV, which would be composed with EQUAL_VERIFY to mimic the currently proposed verification style-semantics, or a hybrid push-or-verify semantics that would either push or verify depending on the size of the input. (And I still think a more general TXHASH would be even better, though if I cannot convince aj then perhaps I'm wrong.) I'm not saying bare-CTV is necessarily a bad idea. I'm just struggling with its justification. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220421/7dabd75a/attachment-0001.html>