Return-Path: <jeremy.l.rubin@gmail.com> Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id A9F74C002C for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 21 Apr 2022 06:25:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A5980402B1 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 21 Apr 2022 06:25:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uufvr-BwqmPk for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 21 Apr 2022 06:25:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by smtp2.osuosl.org (Postfix) with ESMTPS id 5787840241 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 21 Apr 2022 06:25:19 +0000 (UTC) Received: by mail-lj1-x22a.google.com with SMTP id q14so4504313ljc.12 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 20 Apr 2022 23:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dud4KMy7tm5f8P6sqBrS7qsWJ/MgFZblZypoH8vBYa8=; b=AXq86tO9pCNb9R5qfbCAHa9Vf2vN8MfwOC2jZJu4PRThVeV5A0C+sXWzw45hit8p+T Cc9Ma5orEmVfjwYkqY+jDUxCpuZWkR+TpZoh88D0jYivpGIPJDoosMXEhRLFr6N5xDGJ BXHJP0QzoEzTn/rfK/eBTKsW+k3CJeASmyOiXmtFcUcLB9Nsm+pzbDDc2UPZ63458y8m ul5x8V3PwfgAEUiRQfNOkRX86squqMKMyMxQJqlARYIIjuiwxoMVkG/9AepZyE4iSqrE rEEDMLxStNh6DcYNcnbDW6T5KXjSq1DLihAHTbbAj4T114b+IgqTVCDER7FfrNmLmisi 3vYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dud4KMy7tm5f8P6sqBrS7qsWJ/MgFZblZypoH8vBYa8=; b=f4ToeEZJgmmSwuu/8lX/b6wiXBh4aRrAZw54gku2xDvG2MHlcxl9ftob06TSTSt8yH 3sJpFSafIizATTC7NuG9ruACzXzU7JPSSTAYbNoaQEt4VTyXlMBR05mXuAZc8Me9+bS0 YCPBEPGf12z/pKNqiqX50e3Toh9TELeit1pbVqJcFzTpffllNOtvKbYRBw/qfCcALQ+F aNCjp6IQeYPAHv5lWaLq+T/EiYo6lis5fy1RHN5wmvAzcq+l4qIczD6oicu3CmRHnKvJ ooqw0FyFviGchQgcpMCpGwVDfurvXfc1bACE0nT8+GhUY+Vv1zxpwKAm5nNny8KfkLfb 6gJw== X-Gm-Message-State: AOAM5324BuXIatssQl2kwb4XkJCmZZxjxoHle8w2LTGmlFftPU3KNTFo s01WQYxum7VsUyJe5IumEl56TYTxY+vXYNhViG+jeivwiJc= X-Google-Smtp-Source: ABdhPJxD+PWkKFEYd1B9Qge56Cqryjv/prlZIVT/aiHQoNni58Fsa2d01NqxeUCLtHEkEuDN1kmm6JP4vrdq7KTCbeE= X-Received: by 2002:a05:651c:12c1:b0:249:7e8c:d5fc with SMTP id 1-20020a05651c12c100b002497e8cd5fcmr15197686lje.33.1650522316652; Wed, 20 Apr 2022 23:25:16 -0700 (PDT) MIME-Version: 1.0 References: <cROVGM8-pKj4YzUX0QMipX3pYW6M5ps8HMrpHD9MJDey8cWBUBJSKc9tNeAJ6XOL2WVPWVwfNYI_LIAmJ4A0lLtolVIF-F1Zn2m27boTO-U=@protonmail.com> <20220421050351.GA5616@erisian.com.au> <CAD5xwhhxvotKwG1dweLP4JovdFQO7AjzSHyepmei0EtsxtcYkw@mail.gmail.com> In-Reply-To: <CAD5xwhhxvotKwG1dweLP4JovdFQO7AjzSHyepmei0EtsxtcYkw@mail.gmail.com> From: Jeremy Rubin <jeremy.l.rubin@gmail.com> Date: Thu, 21 Apr 2022 01:25:05 -0500 Message-ID: <CAD5xwhh=0g5F_t=0gZXskrPZWL3FHV2JauhpWpq1KORZf=sv5g@mail.gmail.com> To: Anthony Towns <aj@erisian.com.au>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> Content-Type: multipart/alternative; boundary="00000000000060c1ab05dd242cd8" Subject: Re: [bitcoin-dev] CTV Signet Parameters X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Thu, 21 Apr 2022 06:25:21 -0000 --00000000000060c1ab05dd242cd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-wSW6CaLSgo7y4kvgrEwVgfY14= IW2XV_MA/edit#slide=3Did.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@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-work= shop > > 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 covenan= t > 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/contrac= ts > 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 ca= se. > > The suite of Sapio apps are less "production ready" than they could be fo= r > 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 i= t > 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/contrac= ts/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 alway= s > happen later, and I don't think it takes as much imagination. But the mai= n > 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 take= n > 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@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 t= he >> 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 =E2=80=9Cout in the wild=E2=80=9D before there=E2= =80=99s 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 activ= e, >> without having to rush around adding library support at the last minute. >> >> [0] >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/01= 9589.html >> >> Lightning's "two independent implementations" rule might be worth aspiri= ng >> too, eg. >> >> > If we don=E2=80=99t think it is enough, then what number of unique spe= nds and >> use cases should we expect to see of a new proposal before it=E2=80=99s = 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 f= or >> 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/019= 543.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 a= s >> 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 m= y >> 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=E2=80=99re mining fo= r 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 f= or >> 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=E2=80=99s also the unkn= own of what >> we could have once it becomes clear that it=E2=80=99s worth devoting men= tal 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=E2=80=99s =E2=80=9Cworth=E2=80=9D is that not all features are t= he same. Many of the use >> cases that people are excited to use CTV for ([5], [6]) are very long te= rm >> in nature and targeted for long term store of value in contrast to mediu= m >> 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=E2=80=99ll only really se= e a lot >> of people using it when it=E2=80=99s 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 n= o >> rush to implement these features and demo them ASAP, then it doesn't see= m >> 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=E2=80=99t spend much time on Twitt= er expect >> to be able to see to evaluate the readiness or acceptability of ANYPREVO= UT, >> 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 argumen= t >> 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 lik= e >> 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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --00000000000060c1ab05dd242cd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= lvetica,sans-serif;font-size:small;color:#000000">Missed one for part 2:</d= iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s= erif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" = style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000= 00">Shesek's social recovery=C2=A0wallet using CTV to enforce timelocks= without expiry, using his Minsc toolchain:</div><div class=3D"gmail_defaul= t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0= 00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he= lvetica,sans-serif;font-size:small;color:#000000"><a href=3D"https://twitte= r.com/shesek/status/1511619296367153153">https://twitter.com/shesek/status/= 1511619296367153153</a><br></div><div class=3D"gmail_default" style=3D"font= -family:arial,helvetica,sans-serif;font-size:small;color:#000000"><a href= =3D"https://docs.google.com/presentation/d/1B59CdMIXW-wSW6CaLSgo7y4kvgrEwVg= fY14IW2XV_MA/edit#slide=3Did.g1235f9ffb79_0_81">https://docs.google.com/pre= sentation/d/1B59CdMIXW-wSW6CaLSgo7y4kvgrEwVgfY14IW2XV_MA/edit#slide=3Did.g1= 235f9ffb79_0_81</a><br></div><div class=3D"gmail_default" style=3D"font-fam= ily:arial,helvetica,sans-serif;font-size:small;color:#000000"><a href=3D"ht= tps://github.com/shesek/plebfi2022-social-recovery">https://github.com/shes= ek/plebfi2022-social-recovery</a><br></div><div><div dir=3D"ltr" class=3D"g= mail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><= a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</= a><br></div></div></div><br></div><br><div class=3D"gmail_quote"><div dir= =3D"ltr" class=3D"gmail_attr">On Thu, Apr 21, 2022 at 1:16 AM Jeremy Rubin = <<a href=3D"mailto:jeremy.l.rubin@gmail.com">jeremy.l.rubin@gmail.com</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-co= lor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail= _default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c= olor:rgb(0,0,0)">Probably merits a more thorough response, but, I wanted to= respond on the framework above:</div><div class=3D"gmail_default" style=3D= "font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><= br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,= sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_= default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co= lor:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvet= ica,sans-serif">=C2=A01a) can you make transactions using the new feature w= ith bitcoin-cli,</span><br style=3D"color:rgb(34,34,34);font-family:Arial,H= elvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,H= elvetica,sans-serif">=C2=A0 =C2=A0 =C2=A0eg createrawtransaction etc? (<b>Y= ES)</b></span></div><div class=3D"gmail_default" style=3D"font-family:arial= ,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div clas= s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si= ze:small;color:rgb(0,0,0)">since ~Feb 2020, this has existed: <a href=3D"ht= tps://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-feb1-workshop= " target=3D"_blank">https://github.com/JeremyRubin/bitcoin/tree/checktempla= teverify-feb1-workshop</a></div><div class=3D"gmail_default" style=3D"font-= family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d= iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s= erif;font-size:small;color:rgb(0,0,0)">CTV hasn't changed so this code = should work un-rebased. The transaction outputs may need to be manually sub= mitted to the network, but the covenant is enforced. This covers congestion= control and vaults.</div><div class=3D"gmail_default" style=3D"font-family= :arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di= v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f= ont-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" sty= le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,= 0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-ser= if">=C2=A01b) can you make transactions using the new feature with some oth= er</span><br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-= serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-= serif">=C2=A0 =C2=A0 =C2=A0library? <b>(YES)</b></span></div><div class=3D"= gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm= all;color:rgb(0,0,0)">Sapio, Test Framework, also=C2=A0<a href=3D"https://m= in.sc/nextc/" target=3D"_blank">https://min.sc/nextc/</a> produced independ= ently by Shesek</div><div class=3D"gmail_default" style=3D"font-family:aria= l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div cla= ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s= ize:small;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:= Arial,Helvetica,sans-serif">=C2=A01c) can you make transactions using the n= ew feature with most common</span><br style=3D"color:rgb(34,34,34);font-fam= ily:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-fam= ily:Arial,Helvetica,sans-serif">=C2=A0 =C2=A0 =C2=A0libraries? <b>(YES, kin= da)</b></span></div><div class=3D"gmail_default" style=3D"font-family:arial= ,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br style=3D"color:= rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">Yes,=C2=A0<a href=3D"= https://crates.io/crates/sapio-miniscript" target=3D"_blank">https://crates= .io/crates/sapio-miniscript</a> and=C2=A0<a href=3D"https://crates.io/crate= s/sapio-bitcoin" target=3D"_blank">https://crates.io/crates/sapio-bitcoin</= a> have been maintained for about 1 year, and are now taproot compatible.</= div><div class=3D"gmail_default" style=3D"font-size:small"><br></div><div c= lass=3D"gmail_default" style=3D"font-size:small">Sapio's use of these l= ibraries=C2=A0has even helped find bugs in the release process of Taproot f= or rust-bitcoin.</div><div class=3D"gmail_default" style=3D"font-size:small= "><br></div><div class=3D"gmail_default" style=3D"font-size:small">kinda: I= t'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 b= e.</div><div class=3D"gmail_default" style=3D"font-size:small"><br></div><d= iv class=3D"gmail_default" style=3D"font-size:small"><span style=3D"color:r= gb(34,34,34);font-family:Arial,Helvetica,sans-serif">=C2=A02) has anyone do= ne a usable prototype of the major use cases of the new</span><br style=3D"= color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"= color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">=C2=A0 =C2=A0 f= eature?<b> (YES)</b></span><br></div><div class=3D"gmail_default" style=3D"= font-size:small"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helve= tica,sans-serif"><br></span></div><div class=3D"gmail_default" style=3D"fon= t-size:small"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetic= a,sans-serif">In addition to=C2=A0</span><a href=3D"https://github.com/jame= sob/simple-ctv-vault" target=3D"_blank">https://github.com/jamesob/simple-c= tv-vault</a>, there is also=C2=A0<a href=3D"https://github.com/kanzure/pyth= on-vaults" target=3D"_blank">https://github.com/kanzure/python-vaults</a>, = although it has an interesting bug.</div><div class=3D"gmail_default" style= =3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-s= ize:small">There's also a myriad of uses shown in=C2=A0<a href=3D"https= ://github.com/sapio-lang/sapio/tree/master/sapio-contrib/src/contracts" tar= get=3D"_blank">https://github.com/sapio-lang/sapio/tree/master/sapio-contri= b/src/contracts</a> and in=C2=A0<a href=3D"https://github.com/sapio-lang/sa= pio/tree/master/plugin-example" target=3D"_blank">https://github.com/sapio-= lang/sapio/tree/master/plugin-example</a>. While these aren't quite &qu= ot;usable" as an end-to-end application, e.g., something you'd wan= t to put real money on, they are a part of a *massive* infrastructure inves= tment in general purpose smart contract tooling for covenant design with CT= V. That CTV can be targeted with a compiler to generate a wide variety of c= omposable use cases *is* one of the use cases for CTV, since it enables peo= ple to design many different types of thing relatively easily. That is a fe= ature of CTV! It's not just for one use case.</div><div class=3D"gmail_= default" style=3D"font-size:small"><br></div><div class=3D"gmail_default" s= tyle=3D"font-size:small">The suite of Sapio apps are less "production = ready" than they could be for a few reasons:</div><div class=3D"gmail_= default" style=3D"font-size:small"><br></div><div class=3D"gmail_default" s= tyle=3D"font-size:small">1) I've been working hard at pushing the limit= s of what is possible & the theory of it v.s. making it production read= y</div><div class=3D"gmail_default" style=3D"font-size:small">2) I prioriti= zed supporting Taproot v.s. legacy script, and much of the taproot tooling = isn't production ready</div><div class=3D"gmail_default" style=3D"font-= size:small">3) Sapio is really ambitious undertaking, and it will take time= to make it production</div><div class=3D"gmail_default" style=3D"font-size= :small"><br></div><div class=3D"gmail_default" style=3D"font-size:small">Th= at said,=C2=A0<a href=3D"https://rubin.io/bitcoin/2022/03/22/sapio-studio-b= tc-dev-mtg-6/" target=3D"_blank">https://rubin.io/bitcoin/2022/03/22/sapio-= studio-btc-dev-mtg-6/</a> tutorial was completed by people who weren't = me, and at the <a href=3D"http://pleb.fi/miami2022" target=3D"_blank">pleb.= fi/miami2022</a> one of the projects was able to use sapio congestion contr= ol transactions as well, so it does "work". As it matures, we'= ;ll get a number of implemented use cases people have been excited about li= ke DLCs, which are implemented here <a href=3D"https://github.com/sapio-lan= g/sapio/blob/master/sapio-contrib/src/contracts/derivatives/dlc.rs" target= =3D"_blank">https://github.com/sapio-lang/sapio/blob/master/sapio-contrib/s= rc/contracts/derivatives/dlc.rs</a>. You can see the test case shows how to= construct one.</div><div class=3D"gmail_default" style=3D"font-size:small"= ><br></div><div class=3D"gmail_default" style=3D"font-size:small">Why did I= not focus on production grade? Well, production grade can always happen la= ter,=C2=A0and I don't think it takes=C2=A0as 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 h= ow CTV could be used for an incredibly wide and diverse set of applications= , as opposed to the polish on them.</div><div class=3D"gmail_default" style= =3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-s= ize:small">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 applicat= ions working end-to-end. But because the main feedback I got was that CTV w= asn't powerful enough, I opted to build a very general framework for co= venants and demonstrate how CTV fits that.</div><div class=3D"gmail_default= " style=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D= "font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size= :small"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans= -serif"><br></span></div><div class=3D"gmail_default" style=3D"font-family:= arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><br = clear=3D"all"><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https= ://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><br></div></d= iv></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma= il_attr">On Thu, Apr 21, 2022 at 12:05 AM Anthony Towns via bitcoin-dev <= ;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"= >bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote = class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1= px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:= 1ex">On Wed, Apr 20, 2022 at 05:13:19PM +0000, Buck O Perley via bitcoin-de= v wrote:<br> > All merits (or lack thereof depending on your view) of CTV aside, I fi= nd this topic around decision making both interesting and important. While = I think I sympathize with the high level concern about making sure there ar= e use cases, interest, and sufficient testing of a particular proposal befo= re soft forking it into consensus code, it does feel like the attempt to at= tribute hard numbers in this way is somewhat arbitrary.<br> <br> Sure. I included the numbers for falsifiability mostly -- so people<br> could easily check if my analysis was way off the mark.<br> <br> > For example, I think it could be reasonable to paint the list of examp= les you provided where CTV has been used on signet in a positive light. 317= CTV spends =E2=80=9Cout in the wild=E2=80=9D before there=E2=80=99s a know= n activation date is quite a lot<br> <br> Not really? Once you can make one transaction, it's trivial to make<br> hundreds. It's more interesting to see if there's multiple wallets = or<br> similar that support it; or if one wallet has a particularly compelling<br> use case.<br> <br> > (more than taproot had afaik).<br> <br> Yes; as I've said a few times now, I think we should have had more<br> real life demos before locking taproot's activation in. I think that<br= > would have helped avoid bugs like Neutrino's [0] and made it easier for= <br> hardware wallets etc to have support for taproot as soon as it was active,<= br> without having to rush around adding library support at the last minute.<br= > <br> [0] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021= -November/019589.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l= inuxfoundation.org/pipermail/bitcoin-dev/2021-November/019589.html</a> <br> <br> Lightning's "two independent implementations" rule might be w= orth aspiring<br> too, eg.<br> <br> > If we don=E2=80=99t think it is enough, then what number of unique spe= nds and use cases should we expect to see of a new proposal before it=E2=80= =99s been sufficiently tested?<br> <br> I don't really think that's the metric. I'd go for something mo= re like:<br> <br> =C2=A01a) can you make transactions using the new feature with bitcoin-cli,= <br> =C2=A0 =C2=A0 =C2=A0eg createrawtransaction etc?<br> =C2=A01b) can you make transactions using the new feature with some other<b= r> =C2=A0 =C2=A0 =C2=A0library?<br> =C2=A01c) can you make transactions using the new feature with most common<= br> =C2=A0 =C2=A0 =C2=A0libraries?<br> <br> =C2=A02) has anyone done a usable prototype of the major use cases of the n= ew<br> =C2=A0 =C2=A0 feature?<br> <br> I think the answers for CTV are:<br> <br> =C2=A01a) no<br> =C2=A01b) yes, core's python test suite, sapio<br> =C2=A01c) no<br> =C2=A02) no<br> <br> Though presumably jamesob's simple ctv vault is close to being an answe= r<br> for (2)?<br> <br> For taproot, we had,<br> <br> =C2=A01a) yes, with difficulty [1]<br> =C2=A01b) yes, core's python test suite; kalle's btcdeb sometimes w= orked too<br> =C2=A01c) no<br> =C2=A02) optech's python notebook [2] from it's taproot workshops h= ad demos for<br> =C2=A0 =C2=A0 musig and degrading multisig via multiple merkle paths, thoug= h I<br> =C2=A0 =C2=A0 think they were out of date with the taproot spec for a while= <br> <br> [1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021= -October/019543.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2021-October/019543.html</a><br> [2] <a href=3D"https://github.com/bitcoinops/taproot-workshop/" rel=3D"nore= ferrer" target=3D"_blank">https://github.com/bitcoinops/taproot-workshop/</= a><br> <br> To some extent those things are really proxies for:<br> <br> =C2=A03) how well do people actually understand the feature?<br> <br> =C2=A04) are we sure the tradeoffs being made in this implementation of the= <br> =C2=A0 =C2=A0 feature, vs other implementations or other features actually = make<br> =C2=A0 =C2=A0 sense?<br> <br> =C2=A05) how useful is the feature?<br> <br> I think we were pretty confident in the answers for those questions<br> for taproot. At least personally, I'm still not super confident in<br> the answers for CTV. In particular:<br> <br> =C2=A0- is there really any benefit to doing it as a NOP vs a taproot-only<= br> =C2=A0 =C2=A0opcode like TXHASH? Theoretically, sure, that saves some bytes= ; but as<br> =C2=A0 =C2=A0was pointed out on #bitcoin-wizards the other day, you can'= ;t express<br> =C2=A0 =C2=A0those outputs as an address, which makes them not very interop= erable,<br> =C2=A0 =C2=A0and if they're not interoperable between, say, an exchange= and its<br> =C2=A0 =C2=A0users trying to do a withdraw, how useful is that really ever = going<br> =C2=A0 =C2=A0to be?<br> <br> =C2=A0- the scriptSig commitments seems very kludgy; combining multiple<br> =C2=A0 =C2=A0inputs likewise seems kludgy<br> <br> The continual push to rush activation of it certainly doesn't increase = my<br> confidence either. Personally, I suspect it's counterproductive; better= <br> to spend the time answering questions and improving the proposal, rather<br= > than spending time going around in circles about activating something<br> people aren't (essentially) unanimously confident about.<br> <br> > In absence of the above, the risk of a constantly moving bar <br> <br> I'd argue the bar *should* be constantly moving, in the sense that we<b= r> should keep raising it.<br> <br> > To use your meme, miners know precisely what they=E2=80=99re mining fo= r and what a metric of success looks like which makes the risk/costs of att= empting the PoW worth it <br> <br> The difference between mining and R&D is variance: if you're compet= ing for<br> 50k blocks a year, you can get your actual returns to closely match your<br= > expected return, especially if you pool with others so your probability<br> of success isn't miniscule -- for consensus dev, you can reasonably onl= y<br> work on a couple of projects a year, so your median return is likely $0,<br= > rather than a close match to your average/expected return.<br> <br> > We also have new ideas that only started coming up after Taproot activ= ation (TLUV and Taro for example), so there=E2=80=99s also the unknown of w= hat we could have once it becomes clear that it=E2=80=99s worth devoting me= ntal energy and financial resources towards research.<br> <br> TLUV was an offshoot of SCRIPTREPLACE which was public (though not<br> really published) since 2019.<br> <br> > One last wrinkle with regards to using countable metrics to determine = a feature=E2=80=99s =E2=80=9Cworth=E2=80=9D is that not all features are th= e 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.<br> <br> I mean, if those use cases are so exciting, it really doesn't seem much= <br> to ask to see them demoed live on the CTV signet that already exists?<br> <br> > You can build a CTV vault in signet, but you=E2=80=99ll only really se= e a lot of people using it when it=E2=80=99s to store real value on a time = scale measured in decades not minutes or days <br> <br> On the other hand, if the value is really "very long term" and th= ere's no<br> rush to implement these features and demo them ASAP, then it doesn't se= em<br> like there should be a rush to adapt consensus to these use cases either.<b= r> Why not wait until someone does have time to finish sketching out the<br> use case so they can demo them in public?<br> <br> > To put another way and leave CTV out of it completely, what should an = outside, unbiased observer that doesn=E2=80=99t spend much time on Twitter = expect to be able to see to evaluate the readiness or acceptability of ANYP= REVOUT, TLUV, <br> <br> For ANYPREVOUT, I would like to see a toy implementation of eltoo using<br> it, that can handle fees and layered transactions (or has a good argument<b= r> why layered transactions aren't necessary). It's going to take a wh= ile<br> even to update LN to taproot and PTLCs though, so eltoo doesn't seem li= ke<br> it's on the immediate horizon. Besides eltoo, I don't think ANYPREV= OUT<br> is an optimal design for covenants, so if that was the motivation and<br> not eltoo, maybe some other approach would be better.<br> <br> TLUV's design parameters don't really seem optimal (the mess with x= -only<br> pubkeys, alternatives like OP_EVICT), so I think it's still on the<br> whiteboard.<br> <br> Cheers,<br> aj<br> <br> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </blockquote></div> </blockquote></div> --00000000000060c1ab05dd242cd8--