{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-04-21\n📝 Original message:On Wed, Apr 20, 2022 at 05:13:19PM +0000, Buck O Perley via bitcoin-dev wrote:\n\u003e All merits (or lack thereof depending on your view) of CTV aside, I find this topic around decision making both interesting and important. While I think I sympathize with the high level concern about making sure there are use cases, interest, and sufficient testing of a particular proposal before soft forking it into consensus code, it does feel like the attempt to attribute hard numbers in this way is somewhat arbitrary.\n\nSure. I included the numbers for falsifiability mostly -- so people\ncould easily check if my analysis was way off the mark.\n\n\u003e For example, I think it could be reasonable to paint the list of examples you provided where CTV has been used on signet in a positive light. 317 CTV spends “out in the wild” before there’s a known activation date is quite a lot\n\nNot really? Once you can make one transaction, it's trivial to make\nhundreds. It's more interesting to see if there's multiple wallets or\nsimilar that support it; or if one wallet has a particularly compelling\nuse case.\n\n\u003e (more than taproot had afaik).\n\nYes; as I've said a few times now, I think we should have had more\nreal life demos before locking taproot's activation in. I think that\nwould have helped avoid bugs like Neutrino's [0] and made it easier for\nhardware wallets etc to have support for taproot as soon as it was active,\nwithout having to rush around adding library support at the last minute.\n\n[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019589.html \n\nLightning's \"two independent implementations\" rule might be worth aspiring\ntoo, eg.\n\n\u003e If we don’t think it is enough, then what number of unique spends and use cases should we expect to see of a new proposal before it’s been sufficiently tested?\n\nI don't really think that's the metric. I'd go for something more like:\n\n 1a) can you make transactions using the new feature with bitcoin-cli,\n     eg createrawtransaction etc?\n 1b) can you make transactions using the new feature with some other\n     library?\n 1c) can you make transactions using the new feature with most common\n     libraries?\n\n 2) has anyone done a usable prototype of the major use cases of the new\n    feature?\n\nI think the answers for CTV are:\n\n 1a) no\n 1b) yes, core's python test suite, sapio\n 1c) no\n 2) no\n \nThough presumably jamesob's simple ctv vault is close to being an answer\nfor (2)?\n\nFor taproot, we had,\n\n 1a) yes, with difficulty [1]\n 1b) yes, core's python test suite; kalle's btcdeb sometimes worked too\n 1c) no\n 2) optech's python notebook [2] from it's taproot workshops had demos for\n    musig and degrading multisig via multiple merkle paths, though I\n    think they were out of date with the taproot spec for a while\n\n[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019543.html\n[2] https://github.com/bitcoinops/taproot-workshop/\n\nTo some extent those things are really proxies for:\n\n 3) how well do people actually understand the feature?\n\n 4) are we sure the tradeoffs being made in this implementation of the\n    feature, vs other implementations or other features actually make\n    sense?\n\n 5) how useful is the feature?\n\nI think we were pretty confident in the answers for those questions\nfor taproot. At least personally, I'm still not super confident in\nthe answers for CTV. In particular:\n\n - is there really any benefit to doing it as a NOP vs a taproot-only\n   opcode like TXHASH? Theoretically, sure, that saves some bytes; but as\n   was pointed out on #bitcoin-wizards the other day, you can't express\n   those outputs as an address, which makes them not very interoperable,\n   and if they're not interoperable between, say, an exchange and its\n   users trying to do a withdraw, how useful is that really ever going\n   to be?\n\n - the scriptSig commitments seems very kludgy; combining multiple\n   inputs likewise seems kludgy\n\nThe continual push to rush activation of it certainly doesn't increase my\nconfidence either. Personally, I suspect it's counterproductive; better\nto spend the time answering questions and improving the proposal, rather\nthan spending time going around in circles about activating something\npeople aren't (essentially) unanimously confident about.\n\n\u003e In absence of the above, the risk of a constantly moving bar \n\nI'd argue the bar *should* be constantly moving, in the sense that we\nshould keep raising it.\n\n\u003e To use your meme, miners know precisely what they’re mining for and what a metric of success looks like which makes the risk/costs of attempting the PoW worth it \n\nThe difference between mining and R\u0026D is variance: if you're competing for\n50k blocks a year, you can get your actual returns to closely match your\nexpected return, especially if you pool with others so your probability\nof success isn't miniscule -- for consensus dev, you can reasonably only\nwork on a couple of projects a year, so your median return is likely $0,\nrather than a close match to your average/expected return.\n\n\u003e We also have new ideas that only started coming up after Taproot activation (TLUV and Taro for example), so there’s also the unknown of what we could have once it becomes clear that it’s worth devoting mental energy and financial resources towards research.\n\nTLUV was an offshoot of SCRIPTREPLACE which was public (though not\nreally published) since 2019.\n\n\u003e One last wrinkle with regards to using countable metrics to determine a feature’s “worth” is that not all features are the same. Many of the use cases that people are excited to use CTV for ([5], [6]) are very long term in nature and targeted for long term store of value in contrast to medium of exchange.\n\nI mean, if those use cases are so exciting, it really doesn't seem much\nto ask to see them demoed live on the CTV signet that already exists?\n\n\u003e You can build a CTV vault in signet, but you’ll only really see a lot of people using it when it’s to store real value on a time scale measured in decades not minutes or days \n\nOn the other hand, if the value is really \"very long term\" and there's no\nrush to implement these features and demo them ASAP, then it doesn't seem\nlike there should be a rush to adapt consensus to these use cases either.\nWhy not wait until someone does have time to finish sketching out the\nuse case so they can demo them in public?\n\n\u003e To put another way and leave CTV out of it completely, what should an outside, unbiased observer that doesn’t spend much time on Twitter expect to be able to see to evaluate the readiness or acceptability of ANYPREVOUT, TLUV, \n\nFor ANYPREVOUT, I would like to see a toy implementation of eltoo using\nit, that can handle fees and layered transactions (or has a good argument\nwhy layered transactions aren't necessary). It's going to take a while\neven to update LN to taproot and PTLCs though, so eltoo doesn't seem like\nit's on the immediate horizon. Besides eltoo, I don't think ANYPREVOUT\nis an optimal design for covenants, so if that was the motivation and\nnot eltoo, maybe some other approach would be better.\n\nTLUV's design parameters don't really seem optimal (the mess with x-only\npubkeys, alternatives like OP_EVICT), so I think it's still on the\nwhiteboard.\n\nCheers,\naj"}