rich1.0npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0https://nostr.ae/npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0njumphttps://nostr.ae📅 Original date posted:2022-04-21 📝 Original message:Missed one for part 2: Shesek's social recovery wallet using CTV to enforce timelocks without expiry, using his Minsc toolchain: https://twitter.com/shesek/status/1511619296367153153 https://docs.google.com/presentation/d/1B59CdMIXW-wSW6CaLSgo7y4kvgrEwVgfY14IW2XV_MA/edit#slide=id.g1235f9ffb79_0_81 https://github.com/shesek/plebfi2022-social-recovery -- @JeremyRubin <https://twitter.com/JeremyRubin> On Thu, Apr 21, 2022 at 1:16 AM Jeremy Rubin <jeremy.l.rubin at gmail.com> wrote: > Probably merits a more thorough response, but, I wanted to respond on the > framework above: > > > 1a) can you make transactions using the new feature with bitcoin-cli, > eg createrawtransaction etc? (*YES)* > > since ~Feb 2020, this has existed: > https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-feb1-workshop > > CTV hasn't changed so this code should work un-rebased. The transaction > outputs may need to be manually submitted to the network, but the covenant > is enforced. This covers congestion control and vaults. > > > 1b) can you make transactions using the new feature with some other > library? *(YES)* > Sapio, Test Framework, also https://min.sc/nextc/ produced independently > by Shesek > > 1c) can you make transactions using the new feature with most common > libraries? *(YES, kinda)* > > Yes, https://crates.io/crates/sapio-miniscript and > https://crates.io/crates/sapio-bitcoin have been maintained for about 1 > year, and are now taproot compatible. > > Sapio's use of these libraries has even helped find bugs in the release > process of Taproot for rust-bitcoin. > > kinda: It's not _most_ common libraries, it's _a_ common library. it's > also not upstreamed, because the patches would not be accepted were it to > be. > > 2) has anyone done a usable prototype of the major use cases of the new > feature?* (YES)* > > In addition to https://github.com/jamesob/simple-ctv-vault, there is also > https://github.com/kanzure/python-vaults, although it has an interesting > bug. > > There's also a myriad of uses shown in > https://github.com/sapio-lang/sapio/tree/master/sapio-contrib/src/contracts > and in https://github.com/sapio-lang/sapio/tree/master/plugin-example. > While these aren't quite "usable" as an end-to-end application, e.g., > something you'd want to put real money on, they are a part of a *massive* > infrastructure investment in general purpose smart contract tooling for > covenant design with CTV. That CTV can be targeted with a compiler to > generate a wide variety of composable use cases *is* one of the use cases > for CTV, since it enables people to design many different types of thing > relatively easily. That is a feature of CTV! It's not just for one use case. > > The suite of Sapio apps are less "production ready" than they could be for > a few reasons: > > 1) I've been working hard at pushing the limits of what is possible & the > theory of it v.s. making it production ready > 2) I prioritized supporting Taproot v.s. legacy script, and much of the > taproot tooling isn't production ready > 3) Sapio is really ambitious undertaking, and it will take time to make it > production > > That said, https://rubin.io/bitcoin/2022/03/22/sapio-studio-btc-dev-mtg-6/ > tutorial was completed by people who weren't me, and at the > pleb.fi/miami2022 one of the projects was able to use sapio congestion > control transactions as well, so it does "work". As it matures, we'll get a > number of implemented use cases people have been excited about like DLCs, > which are implemented here > https://github.com/sapio-lang/sapio/blob/master/sapio-contrib/src/contracts/derivatives/dlc.rs. > You can see the test case shows how to construct one. > > Why did I not focus on production grade? Well, production grade can always > happen later, and I don't think it takes as much imagination. But the main > critique I'd heard of CTV was that no one could see it being used for > anything but one or two use cases. So I built Sapio, in part, to show how > CTV could be used for an incredibly wide and diverse set of applications, > as opposed to the polish on them. > > If I knew the bar to surpass was to be polish, I probably could have taken > a less ambitious approach with Sapio and shown like 1-2 applications > working end-to-end. But because the main feedback I got was that CTV wasn't > powerful enough, I opted to build a very general framework for covenants > and demonstrate how CTV fits that. > > > > > > -- > @JeremyRubin <https://twitter.com/JeremyRubin> > > On Thu, Apr 21, 2022 at 12:05 AM Anthony Towns via bitcoin-dev < > bitcoin-dev at lists.linuxfoundation.org> wrote: > >> On Wed, Apr 20, 2022 at 05:13:19PM +0000, Buck O Perley via bitcoin-dev >> wrote: >> > 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. >> >> Sure. I included the numbers for falsifiability mostly -- so people >> could easily check if my analysis was way off the mark. >> >> > 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 >> >> Not really? Once you can make one transaction, it's trivial to make >> hundreds. It's more interesting to see if there's multiple wallets or >> similar that support it; or if one wallet has a particularly compelling >> use case. >> >> > (more than taproot had afaik). >> >> Yes; as I've said a few times now, I think we should have had more >> real life demos before locking taproot's activation in. I think that >> would have helped avoid bugs like Neutrino's [0] and made it easier for >> hardware wallets etc to have support for taproot as soon as it was active, >> without having to rush around adding library support at the last minute. >> >> [0] >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019589.html >> >> Lightning's "two independent implementations" rule might be worth aspiring >> too, eg. >> >> > 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? >> >> I don't really think that's the metric. I'd go for something more like: >> >> 1a) can you make transactions using the new feature with bitcoin-cli, >> eg createrawtransaction etc? >> 1b) can you make transactions using the new feature with some other >> library? >> 1c) can you make transactions using the new feature with most common >> libraries? >> >> 2) has anyone done a usable prototype of the major use cases of the new >> feature? >> >> I think the answers for CTV are: >> >> 1a) no >> 1b) yes, core's python test suite, sapio >> 1c) no >> 2) no >> >> Though presumably jamesob's simple ctv vault is close to being an answer >> for (2)? >> >> For taproot, we had, >> >> 1a) yes, with difficulty [1] >> 1b) yes, core's python test suite; kalle's btcdeb sometimes worked too >> 1c) no >> 2) optech's python notebook [2] from it's taproot workshops had demos for >> musig and degrading multisig via multiple merkle paths, though I >> think they were out of date with the taproot spec for a while >> >> [1] >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019543.html >> [2] https://github.com/bitcoinops/taproot-workshop/ >> >> To some extent those things are really proxies for: >> >> 3) how well do people actually understand the feature? >> >> 4) are we sure the tradeoffs being made in this implementation of the >> feature, vs other implementations or other features actually make >> sense? >> >> 5) how useful is the feature? >> >> I think we were pretty confident in the answers for those questions >> for taproot. At least personally, I'm still not super confident in >> the answers for CTV. In particular: >> >> - is there really any benefit to doing it as a NOP vs a taproot-only >> opcode like TXHASH? Theoretically, sure, that saves some bytes; but as >> was pointed out on #bitcoin-wizards the other day, you can't express >> those outputs as an address, which makes them not very interoperable, >> and if they're not interoperable between, say, an exchange and its >> users trying to do a withdraw, how useful is that really ever going >> to be? >> >> - the scriptSig commitments seems very kludgy; combining multiple >> inputs likewise seems kludgy >> >> The continual push to rush activation of it certainly doesn't increase my >> confidence either. Personally, I suspect it's counterproductive; better >> to spend the time answering questions and improving the proposal, rather >> than spending time going around in circles about activating something >> people aren't (essentially) unanimously confident about. >> >> > In absence of the above, the risk of a constantly moving bar >> >> I'd argue the bar *should* be constantly moving, in the sense that we >> should keep raising it. >> >> > 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 >> >> The difference between mining and R&D is variance: if you're competing for >> 50k blocks a year, you can get your actual returns to closely match your >> expected return, especially if you pool with others so your probability >> of success isn't miniscule -- for consensus dev, you can reasonably only >> work on a couple of projects a year, so your median return is likely $0, >> rather than a close match to your average/expected return. >> >> > 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. >> >> TLUV was an offshoot of SCRIPTREPLACE which was public (though not >> really published) since 2019. >> >> > 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. >> >> I mean, if those use cases are so exciting, it really doesn't seem much >> to ask to see them demoed live on the CTV signet that already exists? >> >> > 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 >> >> On the other hand, if the value is really "very long term" and there's no >> rush to implement these features and demo them ASAP, then it doesn't seem >> like there should be a rush to adapt consensus to these use cases either. >> Why not wait until someone does have time to finish sketching out the >> use case so they can demo them in public? >> >> > 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, >> >> For ANYPREVOUT, I would like to see a toy implementation of eltoo using >> it, that can handle fees and layered transactions (or has a good argument >> why layered transactions aren't necessary). It's going to take a while >> even to update LN to taproot and PTLCs though, so eltoo doesn't seem like >> it's on the immediate horizon. Besides eltoo, I don't think ANYPREVOUT >> is an optimal design for covenants, so if that was the motivation and >> not eltoo, maybe some other approach would be better. >> >> TLUV's design parameters don't really seem optimal (the mess with x-only >> pubkeys, alternatives like OP_EVICT), so I think it's still on the >> whiteboard. >> >> 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/20220421/a4e08892/attachment-0001.html>