{"type":"rich","version":"1.0","author_name":"npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0","author_url":"https://nostr.ae/npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-04-21\n📝 Original message:Probably merits a more thorough response, but, I wanted to respond on the\nframework above:\n\n\n 1a) can you make transactions using the new feature with bitcoin-cli,\n     eg createrawtransaction etc? (*YES)*\n\nsince ~Feb 2020, this has existed:\nhttps://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-feb1-workshop\n\nCTV hasn't changed so this code should work un-rebased. The transaction\noutputs may need to be manually submitted to the network, but the covenant\nis enforced. This covers congestion control and vaults.\n\n\n 1b) can you make transactions using the new feature with some other\n     library? *(YES)*\nSapio, Test Framework, also https://min.sc/nextc/ produced independently by\nShesek\n\n 1c) can you make transactions using the new feature with most common\n     libraries? *(YES, kinda)*\n\nYes, https://crates.io/crates/sapio-miniscript and\nhttps://crates.io/crates/sapio-bitcoin have been maintained for about 1\nyear, and are now taproot compatible.\n\nSapio's use of these libraries has even helped find bugs in the release\nprocess of Taproot for rust-bitcoin.\n\nkinda: It's not _most_ common libraries, it's _a_ common library. it's also\nnot upstreamed, because the patches would not be accepted were it to be.\n\n 2) has anyone done a usable prototype of the major use cases of the new\n    feature?* (YES)*\n\nIn addition to https://github.com/jamesob/simple-ctv-vault, there is also\nhttps://github.com/kanzure/python-vaults, although it has an interesting\nbug.\n\nThere's also a myriad of uses shown in\nhttps://github.com/sapio-lang/sapio/tree/master/sapio-contrib/src/contracts\nand in https://github.com/sapio-lang/sapio/tree/master/plugin-example.\nWhile these aren't quite \"usable\" as an end-to-end application, e.g.,\nsomething you'd want to put real money on, they are a part of a *massive*\ninfrastructure investment in general purpose smart contract tooling for\ncovenant design with CTV. That CTV can be targeted with a compiler to\ngenerate a wide variety of composable use cases *is* one of the use cases\nfor CTV, since it enables people to design many different types of thing\nrelatively easily. That is a feature of CTV! It's not just for one use case.\n\nThe suite of Sapio apps are less \"production ready\" than they could be for\na few reasons:\n\n1) I've been working hard at pushing the limits of what is possible \u0026 the\ntheory of it v.s. making it production ready\n2) I prioritized supporting Taproot v.s. legacy script, and much of the\ntaproot tooling isn't production ready\n3) Sapio is really ambitious undertaking, and it will take time to make it\nproduction\n\nThat said, https://rubin.io/bitcoin/2022/03/22/sapio-studio-btc-dev-mtg-6/\ntutorial was completed by people who weren't me, and at the\npleb.fi/miami2022 one of the projects was able to use sapio congestion\ncontrol transactions as well, so it does \"work\". As it matures, we'll get a\nnumber of implemented use cases people have been excited about like DLCs,\nwhich are implemented here\nhttps://github.com/sapio-lang/sapio/blob/master/sapio-contrib/src/contracts/derivatives/dlc.rs.\nYou can see the test case shows how to construct one.\n\nWhy did I not focus on production grade? Well, production grade can always\nhappen later, and I don't think it takes as much imagination. But the main\ncritique I'd heard of CTV was that no one could see it being used for\nanything but one or two use cases. So I built Sapio, in part, to show how\nCTV could be used for an incredibly wide and diverse set of applications,\nas opposed to the polish on them.\n\nIf I knew the bar to surpass was to be polish, I probably could have taken\na less ambitious approach with Sapio and shown like 1-2 applications\nworking end-to-end. But because the main feedback I got was that CTV wasn't\npowerful enough, I opted to build a very general framework for covenants\nand demonstrate how CTV fits that.\n\n\n\n\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\nOn Thu, Apr 21, 2022 at 12:05 AM Anthony Towns via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wed, Apr 20, 2022 at 05:13:19PM +0000, Buck O Perley via bitcoin-dev\n\u003e wrote:\n\u003e \u003e All merits (or lack thereof depending on your view) of CTV aside, I find\n\u003e this topic around decision making both interesting and important. While I\n\u003e think I sympathize with the high level concern about making sure there are\n\u003e use cases, interest, and sufficient testing of a particular proposal before\n\u003e soft forking it into consensus code, it does feel like the attempt to\n\u003e attribute hard numbers in this way is somewhat arbitrary.\n\u003e\n\u003e Sure. I included the numbers for falsifiability mostly -- so people\n\u003e could easily check if my analysis was way off the mark.\n\u003e\n\u003e \u003e For example, I think it could be reasonable to paint the list of\n\u003e examples you provided where CTV has been used on signet in a positive\n\u003e light. 317 CTV spends “out in the wild” before there’s a known activation\n\u003e date is quite a lot\n\u003e\n\u003e Not really? Once you can make one transaction, it's trivial to make\n\u003e hundreds. It's more interesting to see if there's multiple wallets or\n\u003e similar that support it; or if one wallet has a particularly compelling\n\u003e use case.\n\u003e\n\u003e \u003e (more than taproot had afaik).\n\u003e\n\u003e Yes; as I've said a few times now, I think we should have had more\n\u003e real life demos before locking taproot's activation in. I think that\n\u003e would have helped avoid bugs like Neutrino's [0] and made it easier for\n\u003e hardware wallets etc to have support for taproot as soon as it was active,\n\u003e without having to rush around adding library support at the last minute.\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019589.html\n\u003e\n\u003e Lightning's \"two independent implementations\" rule might be worth aspiring\n\u003e too, eg.\n\u003e\n\u003e \u003e If we don’t think it is enough, then what number of unique spends and\n\u003e use cases should we expect to see of a new proposal before it’s been\n\u003e sufficiently tested?\n\u003e\n\u003e I don't really think that's the metric. I'd go for something more like:\n\u003e\n\u003e  1a) can you make transactions using the new feature with bitcoin-cli,\n\u003e      eg createrawtransaction etc?\n\u003e  1b) can you make transactions using the new feature with some other\n\u003e      library?\n\u003e  1c) can you make transactions using the new feature with most common\n\u003e      libraries?\n\u003e\n\u003e  2) has anyone done a usable prototype of the major use cases of the new\n\u003e     feature?\n\u003e\n\u003e I think the answers for CTV are:\n\u003e\n\u003e  1a) no\n\u003e  1b) yes, core's python test suite, sapio\n\u003e  1c) no\n\u003e  2) no\n\u003e\n\u003e Though presumably jamesob's simple ctv vault is close to being an answer\n\u003e for (2)?\n\u003e\n\u003e For taproot, we had,\n\u003e\n\u003e  1a) yes, with difficulty [1]\n\u003e  1b) yes, core's python test suite; kalle's btcdeb sometimes worked too\n\u003e  1c) no\n\u003e  2) optech's python notebook [2] from it's taproot workshops had demos for\n\u003e     musig and degrading multisig via multiple merkle paths, though I\n\u003e     think they were out of date with the taproot spec for a while\n\u003e\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019543.html\n\u003e [2] https://github.com/bitcoinops/taproot-workshop/\n\u003e\n\u003e To some extent those things are really proxies for:\n\u003e\n\u003e  3) how well do people actually understand the feature?\n\u003e\n\u003e  4) are we sure the tradeoffs being made in this implementation of the\n\u003e     feature, vs other implementations or other features actually make\n\u003e     sense?\n\u003e\n\u003e  5) how useful is the feature?\n\u003e\n\u003e I think we were pretty confident in the answers for those questions\n\u003e for taproot. At least personally, I'm still not super confident in\n\u003e the answers for CTV. In particular:\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\u003e  - the scriptSig commitments seems very kludgy; combining multiple\n\u003e    inputs likewise seems kludgy\n\u003e\n\u003e The continual push to rush activation of it certainly doesn't increase my\n\u003e confidence either. Personally, I suspect it's counterproductive; better\n\u003e to spend the time answering questions and improving the proposal, rather\n\u003e than spending time going around in circles about activating something\n\u003e people aren't (essentially) unanimously confident about.\n\u003e\n\u003e \u003e In absence of the above, the risk of a constantly moving bar\n\u003e\n\u003e I'd argue the bar *should* be constantly moving, in the sense that we\n\u003e should keep raising it.\n\u003e\n\u003e \u003e To use your meme, miners know precisely what they’re mining for and what\n\u003e a metric of success looks like which makes the risk/costs of attempting the\n\u003e PoW worth it\n\u003e\n\u003e The difference between mining and R\u0026D is variance: if you're competing for\n\u003e 50k blocks a year, you can get your actual returns to closely match your\n\u003e expected return, especially if you pool with others so your probability\n\u003e of success isn't miniscule -- for consensus dev, you can reasonably only\n\u003e work on a couple of projects a year, so your median return is likely $0,\n\u003e rather than a close match to your average/expected return.\n\u003e\n\u003e \u003e We also have new ideas that only started coming up after Taproot\n\u003e activation (TLUV and Taro for example), so there’s also the unknown of what\n\u003e we could have once it becomes clear that it’s worth devoting mental energy\n\u003e and financial resources towards research.\n\u003e\n\u003e TLUV was an offshoot of SCRIPTREPLACE which was public (though not\n\u003e really published) since 2019.\n\u003e\n\u003e \u003e One last wrinkle with regards to using countable metrics to determine a\n\u003e feature’s “worth” is that not all features are the same. Many of the use\n\u003e cases that people are excited to use CTV for ([5], [6]) are very long term\n\u003e in nature and targeted for long term store of value in contrast to medium\n\u003e of exchange.\n\u003e\n\u003e I mean, if those use cases are so exciting, it really doesn't seem much\n\u003e to ask to see them demoed live on the CTV signet that already exists?\n\u003e\n\u003e \u003e You can build a CTV vault in signet, but you’ll only really see a lot of\n\u003e people using it when it’s to store real value on a time scale measured in\n\u003e decades not minutes or days\n\u003e\n\u003e On the other hand, if the value is really \"very long term\" and there's no\n\u003e rush to implement these features and demo them ASAP, then it doesn't seem\n\u003e like there should be a rush to adapt consensus to these use cases either.\n\u003e Why not wait until someone does have time to finish sketching out the\n\u003e use case so they can demo them in public?\n\u003e\n\u003e \u003e To put another way and leave CTV out of it completely, what should an\n\u003e outside, unbiased observer that doesn’t spend much time on Twitter expect\n\u003e to be able to see to evaluate the readiness or acceptability of ANYPREVOUT,\n\u003e TLUV,\n\u003e\n\u003e For ANYPREVOUT, I would like to see a toy implementation of eltoo using\n\u003e it, that can handle fees and layered transactions (or has a good argument\n\u003e why layered transactions aren't necessary). It's going to take a while\n\u003e even to update LN to taproot and PTLCs though, so eltoo doesn't seem like\n\u003e it's on the immediate horizon. Besides eltoo, I don't think ANYPREVOUT\n\u003e is an optimal design for covenants, so if that was the motivation and\n\u003e not eltoo, maybe some other approach would be better.\n\u003e\n\u003e TLUV's design parameters don't really seem optimal (the mess with x-only\n\u003e pubkeys, alternatives like OP_EVICT), so I think it's still on the\n\u003e whiteboard.\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/20220421/4dc687ea/attachment-0001.html\u003e"}