path: root/19/ffcca171aa8df48dfb0bfa0408e2c3a010ab40

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&#39;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 =
&lt;<a href=3D"mailto:jeremy.l.rubin@gmail.com">jeremy.l.rubin@gmail.com</a=
>&gt; 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&#39;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&#39;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&#39;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 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&#39;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&#39;t quite &qu=
ot;usable&quot; as an end-to-end application, e.g., something you&#39;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&#39;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 &quot;production =
ready&quot; 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&#39;ve been working hard at pushing the limit=
s of what is possible &amp; 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&#39;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&#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 contr=
ol 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 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&#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 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&#39;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 &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_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>
&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>
</blockquote></div>

--00000000000060c1ab05dd242cd8--