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