path: root/16/5bc881286ee9c1dbc6834f49e265862435aeee

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CDF75C002C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 06:16:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id B33D5610E6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 06:16:25 +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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id GuTJcoSxG6aR
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 06:16:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [IPv6:2a00:1450:4864:20::12d])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 624ED60806
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 06:16:23 +0000 (UTC)
Received: by mail-lf1-x12d.google.com with SMTP id x33so6886556lfu.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Apr 2022 23:16:23 -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=q+z2KYTFOMBIYE/NRncZ3HLM4xhz1bFbWR3tOtTiu2Q=;
 b=BGRvRclYjfZbZjtSHj8hw5ygVrlKkqXVUOLxkxvIF8H6yQYTFryg8G4l0RsIQ+j3cz
 UuG+yuY+qlw+V+0i8nPHUa8aIhToQqDoIxDoT6Nc9cFMowAL8YKjTYMPts4kIC8EHh1Q
 CIDtCoI52LOV2rt0MKwiU7Y7x/og+FKPUEW/2bHPxm/zwBRj1CDlc/Pf338HV8jnLDTS
 5/iegR2GYYx1wM8C309Rf6SpOvuq/NDxdm/9YPRq4PRENyoxdhUkoHrSQ7GPBtk/SZHy
 ti8BGQbeGrrS3wjwWcPOaXDK2sQUMCnidu4IDCEmFKM73ggm/rZRkcqRK2DUPuQPUYqn
 oPHg==
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=q+z2KYTFOMBIYE/NRncZ3HLM4xhz1bFbWR3tOtTiu2Q=;
 b=Xa3U6Ha42yUyn/TFmgH83kj8FbwOlXTVdIFyVlziGXNuHUYJ8rq1UJpoPs8oIECXUy
 1D/O121Nv52aMijKPOjp37HhbUuk6n6u/5J9Yr+ZrCHOsqSu9k7vICax0/1d+ddfdKoC
 5nkpW1R/yKGkPjVItaxTKY/tCc5mQ00qmZv7CAX/4gCPRCf6kKPx+7FX1wWa+8o51q1H
 cmFOJLtipb1sel43tiMs/NKyZx+a+2tza5esuBD3pCIy+PDWSZOVaFxYgGNeEt9a5aAr
 LnID9NepUWdkLxFZ2/uSGLj2KkkpRFqSNIY8bWF3Y6w12OzknJiNzRiWPU6cBgHBybZQ
 mYIw==
X-Gm-Message-State: AOAM533YTfSv+UbHsu0NWDfJJMA9/yd0bO4iQF/E0s2CWOpcZiMpesDU
 n7x9eSYQiebDRp7gkNG9lm5Akr8DRbOzJzrpyuo=
X-Google-Smtp-Source: ABdhPJxgMNtr2WWgUiRBxAI2RgKPRHZZhFQslV3qXjq6FWMMj/bsvkCq+zek3X/MXj3RYrnADLK8dpS0KgBDktVmSz0=
X-Received: by 2002:a05:6512:3d88:b0:471:b3e2:5b7b with SMTP id
 k8-20020a0565123d8800b00471b3e25b7bmr6496871lfv.160.1650521781155; Wed, 20
 Apr 2022 23:16:21 -0700 (PDT)
MIME-Version: 1.0
References: <cROVGM8-pKj4YzUX0QMipX3pYW6M5ps8HMrpHD9MJDey8cWBUBJSKc9tNeAJ6XOL2WVPWVwfNYI_LIAmJ4A0lLtolVIF-F1Zn2m27boTO-U=@protonmail.com>
 <20220421050351.GA5616@erisian.com.au>
In-Reply-To: <20220421050351.GA5616@erisian.com.au>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Thu, 21 Apr 2022 01:16:09 -0500
Message-ID: <CAD5xwhhxvotKwG1dweLP4JovdFQO7AjzSHyepmei0EtsxtcYkw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000075ba5c05dd240c0c"
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:16:25 -0000

--00000000000075ba5c05dd240c0c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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-worksh=
op

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@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 fin=
d
> 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
> 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 active=
,
> without having to rush around adding library support at the last minute.
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019=
589.html
>
> Lightning's "two independent implementations" rule might be worth aspirin=
g
> too, eg.
>
> > If we don=E2=80=99t think it is enough, then what number of unique spen=
ds and
> use cases should we expect to see of a new proposal before it=E2=80=99s b=
een
> 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 fo=
r
>     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/0195=
43.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=E2=80=99re mining for=
 and what
> a metric of success looks like which makes the risk/costs of attempting t=
he
> PoW worth it
>
> The difference between mining and R&D is variance: if you're competing fo=
r
> 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 unkno=
wn of what
> we could have once it becomes clear that it=E2=80=99s worth devoting ment=
al 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 th=
e same. Many of the use
> cases that people are excited to use CTV for ([5], [6]) are very long ter=
m
> 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=E2=80=99ll only really see=
 a lot of
> people using it when it=E2=80=99s to store real value on a time scale mea=
sured 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=E2=80=99t spend much time on Twitte=
r expect
> to be able to see to evaluate the readiness or acceptability of ANYPREVOU=
T,
> 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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000075ba5c05dd240c0c
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">Probably merits a more th=
orough response, but, I wanted to respond on the framework above:</div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"><span style=3D"color:rgb(34,34,34=
);font-family:Arial,Helvetica,sans-serif">=C2=A01a) can you make transactio=
ns using the new feature with bitcoin-cli,</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=A0eg creat=
erawtransaction etc? (<b>YES)</b></span></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">since ~Feb 2020, this has ex=
isted: <a href=3D"https://github.com/JeremyRubin/bitcoin/tree/checktemplate=
verify-feb1-workshop" target=3D"_blank">https://github.com/JeremyRubin/bitc=
oin/tree/checktemplateverify-feb1-workshop</a></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:#000000">CTV hasn&#39;t changed=
 so this code should work un-rebased. The transaction outputs may need to b=
e manually submitted to the network, but the covenant is enforced. This cov=
ers congestion control and vaults.</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sa=
ns-serif">=C2=A01b) can you make transactions using the new feature with so=
me other</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 cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">Sapio, Test Framework, also=C2=A0<a href=3D"https:=
//min.sc/nextc/" target=3D"_blank">https://min.sc/nextc/</a> produced indep=
endently by Shesek</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000"><span style=3D"color:rgb(34,34,34);font-family:Ari=
al,Helvetica,sans-serif">=C2=A01c) can you make transactions using the new =
feature with most common</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=A0libraries? <b>(YES, kinda)=
</b></span></div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><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/cr=
ates/sapio-miniscript</a> and=C2=A0<a href=3D"https://crates.io/crates/sapi=
o-bitcoin" target=3D"_blank">https://crates.io/crates/sapio-bitcoin</a> hav=
e been maintained for about 1 year, and are now taproot compatible.</div><d=
iv class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=
=3D"gmail_default" style=3D"font-size:small">Sapio&#39;s use of these libra=
ries=C2=A0has even helped find bugs in the release process of Taproot for r=
ust-bitcoin.</div><div class=3D"gmail_default" style=3D"font-size:small"><b=
r></div><div class=3D"gmail_default" style=3D"font-size:small">kinda: It&#3=
9;s not _most_ common libraries, it&#39;s _a_ common library. it&#39;s also=
 not upstreamed, because the patches would not be accepted were it to be.</=
div><div class=3D"gmail_default" style=3D"font-size:small"><br></div><div c=
lass=3D"gmail_default" style=3D"font-size:small"><span style=3D"color:rgb(3=
4,34,34);font-family:Arial,Helvetica,sans-serif">=C2=A02) has anyone done a=
 usable prototype of the major use cases of the new</span><br style=3D"colo=
r:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"colo=
r:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">=C2=A0 =C2=A0 featu=
re?<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,Helvetica=
,sans-serif"><br></span></div><div class=3D"gmail_default" style=3D"font-si=
ze:small"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sa=
ns-serif">In addition to=C2=A0</span><a href=3D"https://github.com/jamesob/=
simple-ctv-vault" target=3D"_blank">https://github.com/jamesob/simple-ctv-v=
ault</a>, there is also=C2=A0<a href=3D"https://github.com/kanzure/python-v=
aults" target=3D"_blank">https://github.com/kanzure/python-vaults</a>, alth=
ough 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-size:=
small">There&#39;s also a myriad of uses shown in=C2=A0<a href=3D"https://g=
ithub.com/sapio-lang/sapio/tree/master/sapio-contrib/src/contracts" target=
=3D"_blank">https://github.com/sapio-lang/sapio/tree/master/sapio-contrib/s=
rc/contracts</a> and in=C2=A0<a href=3D"https://github.com/sapio-lang/sapio=
/tree/master/plugin-example" target=3D"_blank">https://github.com/sapio-lan=
g/sapio/tree/master/plugin-example</a>. While these aren&#39;t quite &quot;=
usable&quot; as an end-to-end application, e.g., something you&#39;d want t=
o put real money on, they are a part of a *massive* infrastructure investme=
nt 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 comp=
osable 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 featu=
re of CTV! It&#39;s not just for one use case.</div><div class=3D"gmail_def=
ault" style=3D"font-size:small"><br></div><div class=3D"gmail_default" styl=
e=3D"font-size:small">The suite of Sapio apps are less &quot;production rea=
dy&quot; than they could be for a few reasons:</div><div class=3D"gmail_def=
ault" style=3D"font-size:small"><br></div><div class=3D"gmail_default" styl=
e=3D"font-size:small">1) I&#39;ve been working hard at pushing the limits o=
f what is possible &amp; the theory of it v.s. making it production ready</=
div><div class=3D"gmail_default" style=3D"font-size:small">2) I prioritized=
 supporting Taproot v.s. legacy script, and much of the taproot tooling isn=
&#39;t production ready</div><div class=3D"gmail_default" style=3D"font-siz=
e: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:sm=
all"><br></div><div class=3D"gmail_default" style=3D"font-size:small">That =
said,=C2=A0<a href=3D"https://rubin.io/bitcoin/2022/03/22/sapio-studio-btc-=
dev-mtg-6/" target=3D"_blank">https://rubin.io/bitcoin/2022/03/22/sapio-stu=
dio-btc-dev-mtg-6/</a> tutorial was completed by people who weren&#39;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 control =
transactions as well, so it does &quot;work&quot;. As it matures, we&#39;ll=
 get a number of implemented use cases people have been excited about like =
DLCs, which are implemented here <a href=3D"https://github.com/sapio-lang/s=
apio/blob/master/sapio-contrib/src/contracts/derivatives/dlc.rs" target=3D"=
_blank">https://github.com/sapio-lang/sapio/blob/master/sapio-contrib/src/c=
ontracts/derivatives/dlc.rs</a>. You can see the test case shows how to con=
struct 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 later,=
=C2=A0and I don&#39;t think it takes=C2=A0as much imagination. But the main=
 critique I&#39;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 C=
TV 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-size:=
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 applications=
 working end-to-end. But because the main feedback I got was that CTV wasn&=
#39;t powerful enough, I opted to build a very general framework for covena=
nts and demonstrate how CTV fits that.</div><div class=3D"gmail_default" st=
yle=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"fon=
t-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:sma=
ll"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-ser=
if"><br></span></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><br clear=
=3D"all"><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"=
gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/Jere=
myRubin" target=3D"_blank">@JeremyRubin</a><br></div></div></div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Ap=
r 21, 2022 at 12:05 AM Anthony Towns via bitcoin-dev &lt;<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl=
e: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-dev wrote:<br>
&gt; 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>
&gt; 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&#39;s trivial to make<br>
hundreds. It&#39;s more interesting to see if there&#39;s multiple wallets =
or<br>
similar that support it; or if one wallet has a particularly compelling<br>
use case.<br>
<br>
&gt; (more than taproot had afaik).<br>
<br>
Yes; as I&#39;ve said a few times now, I think we should have had more<br>
real life demos before locking taproot&#39;s activation in. I think that<br=
>
would have helped avoid bugs like Neutrino&#39;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&#39;s &quot;two independent implementations&quot; rule might be w=
orth aspiring<br>
too, eg.<br>
<br>
&gt; 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&#39;t really think that&#39;s the metric. I&#39;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&#39;s python test suite, sapio<br>
=C2=A01c) no<br>
=C2=A02) no<br>
<br>
Though presumably jamesob&#39;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&#39;s python test suite; kalle&#39;s btcdeb sometimes w=
orked too<br>
=C2=A01c) no<br>
=C2=A02) optech&#39;s python notebook [2] from it&#39;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&#39;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&#39=
;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&#39;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&#39;t increase =
my<br>
confidence either. Personally, I suspect it&#39;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&#39;t (essentially) unanimously confident about.<br>
<br>
&gt; In absence of the above, the risk of a constantly moving bar <br>
<br>
I&#39;d argue the bar *should* be constantly moving, in the sense that we<b=
r>
should keep raising it.<br>
<br>
&gt; 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&amp;D is variance: if you&#39;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&#39;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>
&gt; 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>
&gt; 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&#39;t seem much=
<br>
to ask to see them demoed live on the CTV signet that already exists?<br>
<br>
&gt; 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 &quot;very long term&quot; and th=
ere&#39;s no<br>
rush to implement these features and demo them ASAP, then it doesn&#39;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>
&gt; 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&#39;t necessary). It&#39;s going to take a wh=
ile<br>
even to update LN to taproot and PTLCs though, so eltoo doesn&#39;t seem li=
ke<br>
it&#39;s on the immediate horizon. Besides eltoo, I don&#39;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&#39;s design parameters don&#39;t really seem optimal (the mess with x=
-only<br>
pubkeys, alternatives like OP_EVICT), so I think it&#39;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>

--00000000000075ba5c05dd240c0c--