{"type":"rich","version":"1.0","author_name":"npub1f2w9pm06c4k9ay8rst7757thahg2tfrtd0n645zxrtsqwhvaysrswydpll","author_url":"https://nostr.ae/npub1f2w9pm06c4k9ay8rst7757thahg2tfrtd0n645zxrtsqwhvaysrswydpll","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-04-20\n📝 Original message:\u003e I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte hash\non the stack evaluate as true?\n\nNot with Taproot's CLEANSTACK rule. It can make sense to always use `DROP\nOP_1` even outside of Taproot, just to keep things consistent and to avoid\npotential errors when switching from non-Taproot to Taproot. FWIW that's\nwhat I found myself doing when playing with CTV in P2WSH\n\nOn Wed, Apr 20, 2022 at 5:31 AM Anthony Towns via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Thu, Feb 17, 2022 at 01:58:38PM -0800, Jeremy Rubin via bitcoin-dev\n\u003e wrote:\n\u003e \u003e AJ Wrote (in another thread):\n\u003e \u003e \u003e   I'd much rather see some real\n\u003e \u003e \u003e   third-party experimentation *somewhere* public first, and Jeremy's\n\u003e CTV\n\u003e \u003e \u003e   signet being completely empty seems like a bad sign to me.\n\u003e\n\u003e There's now been some 2,200 txs on CTV signet, of which (if I haven't\n\u003e missed anything) 317 have been CTV spends:\n\u003e\n\u003e  - none have been bare CTV (ie, CTV in scriptPubKey directly, not via\n\u003e    p2sh/p2wsh/taproot)\n\u003e\n\u003e  - none have been via p2sh\n\u003e\n\u003e  - 3 have been via taproot:\n\u003e\n\u003e https://explorer.ctvsignet.com/tx/f73f4671c6ee2bdc8da597f843b2291ca539722a168e8f6b68143b8c157bee20\n\u003e\n\u003e https://explorer.ctvsignet.com/tx/7e4ade977db94117f2d7a71541d87724ccdad91fa710264206bb87ae1314c796\n\u003e\n\u003e https://explorer.ctvsignet.com/tx/e05d828bf716effc65b00ae8b826213706c216b930aff194f1fb2fca045f7f11\n\u003e\n\u003e    The first two of these had alternative merkle paths, the last didn't.\n\u003e\n\u003e  - 314 have been via p2wsh\n\u003e\n\u003e https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36c7212362b648cf3f054315853a081f5808e\n\u003e    (don't think there's any meaningfully different examples?)\n\u003e\n\u003e As far as I can see, all the scripts take the form:\n\u003e\n\u003e   [PUSH 32 bytes] [OP_NOP4] [OP_DROP] [OP_1]\n\u003e\n\u003e (I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte\n\u003e hash on the stack evaluate as true? I guess that means everyone's using\n\u003e sapio to construct the txs?)\n\u003e\n\u003e I don't think there's any demos of jamesob's simple-ctv-vault [0], which\n\u003e I think uses a p2wsh of \"IF n CSV DROP hotkey CHECKSIG ELSE lockcoldtx CTV\n\u003e ENDIF\", rather than taproot branches.\n\u003e\n\u003e [0] https://github.com/jamesob/simple-ctv-vault\n\u003e\n\u003e Likewise I don't think there's any examples of \"this CTV immediately;\n\u003e or if fees are too high, this other CTV that pays more fees after X\n\u003e days\", though potentially they could be hidden in the untaken taproot\n\u003e merkle branches.\n\u003e\n\u003e I don't think there's any examples of two CTV outputs being combined\n\u003e and spent in a single transaction.\n\u003e\n\u003e I don't see any txs with nSequence set meaningfully; though most (all?)\n\u003e of the CTV spends seem to set nSequence to 0x00400000 which I think\n\u003e doesn't have a different effect from 0xfffffffe?\n\u003e\n\u003e That looks to me like there's still not much practical (vs theoretical)\n\u003e exploration of CTV going on; but perhaps it's an indication that CTV\n\u003e could be substantially simplified and still get all the benefits that\n\u003e people are particularly eager for.\n\u003e\n\u003e \u003e I am unsure that \"learning in public\" is required --\n\u003e\n\u003e For a consensus system, part of the learning is \"this doesn't seem that\n\u003e interesting to me; is it actually valuable enough to others that the\n\u003e change is worth the risk it imposes on me?\" and that's not something\n\u003e you can do purely in private.\n\u003e\n\u003e One challenge with building a soft fork is that people don't want to\n\u003e commit to spending time building something that relies on consensus\n\u003e features and run the risk that they might never get deployed. But the\n\u003e reverse of that is also a concern: you don't want to deploy consensus\n\u003e changes and run the risk that they won't actually turn out to be useful.\n\u003e\n\u003e Or, perhaps, to \"meme-ify\" it -- part of the \"proof of work\" for deploying\n\u003e a consensus change is actually proving that it's going to be useful.\n\u003e Like sha256 hashing, that does require real work, and it might turn out\n\u003e to be wasteful.\n\u003e\n\u003e Cheers,\n\u003e aj\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220420/5f867336/attachment-0001.html\u003e"}