{"type":"rich","version":"1.0","author_name":"npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw","author_url":"https://nostr.ae/npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-04-21\n📝 Original message:On Thu, Apr 21, 2022 at 1:04 AM Anthony Towns via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e  - is there really any benefit to doing it as a NOP vs a taproot-only\n\u003e    opcode like TXHASH? Theoretically, sure, that saves some bytes; but as\n\u003e    was pointed out on #bitcoin-wizards the other day, you can't express\n\u003e    those outputs as an address, which makes them not very interoperable,\n\u003e    and if they're not interoperable between, say, an exchange and its\n\u003e    users trying to do a withdraw, how useful is that really ever going\n\u003e    to be?\n\u003e\n\nFWIW, this is also approximately where my sticking point lies with BIP-119.\n\nOverall I've come around to the idea of something like CTV.  The ability to\nconstruct \"smart contracts\" that commit to *multiple* possible payout\nschemes based on some conditions seems like a very useful construct, and\nthere have been several examples of  schemes proposed that use this feature.\n\nHowever, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told\nthat bare-CTV hasn't even appeared on the CTV signet).  Unlike the general\nsmart-contracting case, bare-CTV does not have any branches.  All it can do\nis commit to a subsequent transaction's outputs.  At first glance this\nappears to be a waste because, for less bandwidth, that transaction could\njust realize those outputs immediately, so why would anyone want to delay\nthe inevitable?\n\nOne reason might be that you want to commit to the output early during a\nhigh-fee time, and then complete the transaction later during a low-fee\ntime.  While there are fee-rate situations where this could result in lower\nfees than committing to the outputs all at once, it would be even cheaper\nstill to just wait to do the payout at the low-fee time.  I'm struggling to\nunderstand the advantages of the advanced commitment, along with all the\noverhead that entails.  Doesn't it just cause more blockspace to be used\noverall?\n\nThere are some other proposed use cases for bare-CTV.  A bare-CTV can be\nused to delay a \"trigger\"-transaction.  Some contracts, such as vaults, use\na relative-locktime as part of their construction and it could make sense\nto make an output commitment but not realize those outputs yet until you\nare ready to start your relative-time lock clock.  But bare-CTV doesn't\nsupport any co-signing ability here, so you are relying entirely on keeping\nthe transaction data secret to prevent a third-party from triggering your\nrelative-lock clock.  More specifically for a vault scheme, since\nbare-CTV's are currently unaddressable, and AFAIK, there is no address\nformat proposal yet, it is impossible to receive funds directly into a\nvault.  You must shuffle received funds into your vault yourself, which\nseems very likely to negate the cost savings of using bare-CTV in the first\nplace (please correct me if I'm wrong).  Better to receive funds directly\ninto a taproot-CTV vault, which has an address, and while you are at it,\nyou could place the cold-key as the taproot key to save even more when\nusing the cold-key to move vault funds.\n\nThere might be even more exotic use cases of bare-CTV.  For example you\ncould commit to a transaction that has a second input that doesn't yet\nexist in the UTXO set in an attempt to coax it into existence. I don't know\nif there have been any proposals to take advantage of this.\n\nWith that said, everything that bare-CTV can do, can also be done by\ntapscript-CTV; so it is just a matter of cost.  I'm struggling to\nunderstand where this cost savings is and how much those savings are going\nto be given that bare-CTV is unaddressable and seems to ultimately occupy\nmore-blockspace than if the outputs were directly committed to.\n\nI also believe the bare-CTV question is material, because if bare-CTV were\nnot part of the spec, then I'd be advocating for using an OP_SUCCESS code\nfrom tapscript instead, and either use push-style semantics for CTV, which\nwould be composed with EQUAL_VERIFY to mimic the currently proposed\nverification style-semantics, or a hybrid push-or-verify semantics that\nwould either push or verify depending on the size of the input.  (And I\nstill think a more general TXHASH would be even better, though if I cannot\nconvince aj then perhaps I'm wrong.)\n\nI'm not saying bare-CTV is necessarily a bad idea.  I'm just struggling\nwith its justification.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220421/7dabd75a/attachment-0001.html\u003e"}