path: root/27/57aec63d2b7b3fea66da45e3cc8e7dfb1abd3f

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2BBF5C0020
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Oct 2021 15:47:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 0C28780EF4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Oct 2021 15:47:32 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VCbJhEd64Qe5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Oct 2021 15:47:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [IPv6:2a00:1450:4864:20::52a])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 6514F80F10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Oct 2021 15:47:30 +0000 (UTC)
Received: by mail-ed1-x52a.google.com with SMTP id r12so40333347edt.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Oct 2021 08:47:30 -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=+WjIBhMioMEZzlYDxWH/WNdWqlqAb8Y6NifMQkmg41s=;
 b=hn7zSqOhcb/0fK7ph8CQkUR5E7W52ABwA6zVBxdILmV1He7lBqWnOsH48u5t/MSPpY
 jr2JqZx/QvsVrObqSWP6o1JSeppu5OYdFzIQOdBbHspIA6kq0dBN0kkAKaRn0dlIh8NI
 GtegwmbXpRCwL+2q+1oBRj8luQb5GKBawpGPQqe2ERvhCQx0H3kCbKjRZHe8sDG8XsJv
 UpMBk5B7VrYEAgHhef+oiHDeUfqNV8tDW03KhE6R8sheUo1g4HpVy+oTBeRrxJk1iNa3
 e2eYllqruGT+TKbDCqtLz52TbSnmVqMEad+51p8Wh6kgrg5Ek8E2g3rsXKtbCMWyhPO+
 diVw==
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=+WjIBhMioMEZzlYDxWH/WNdWqlqAb8Y6NifMQkmg41s=;
 b=WO6ynVV+fTER7OyKYPaSjvwvFyjWF/PVd01P9kvlIgDIAAt5jrkyl4hiw8/oIw861B
 lbRcTTf9p45WuRpt+35FgipeobznPsMrNNrtHSLknn88y8K0VQ13dow0K0BZlEQNjbk/
 E6nPUzmiQGk2p97vLnJ+ybFzEU4RhFE3KSR9QGzI8ZkvayTK3UwofvKakDlQZuhrK7DJ
 An9vfPm8eNJ8zJgAyz4UJnx2c0AbjSiq+keXfCRRePxdWf9acnWNv3I1T2RbtARi86ti
 M0iQG9k9GmS2i0o+FcgBI8VClCKISGltR+nUsBSPa8b8GdUii8GaVNmoTWKRz3Ey5P6v
 tP8g==
X-Gm-Message-State: AOAM531t3fidd5xnojGX7hrjGeAkPY5wkDK3Gjd93hv93NXhoxpLs70G
 Iff57OShtLeyZ5BWyePBRoBYT/QiGeY8v5psIMbMVHEYiGc=
X-Google-Smtp-Source: ABdhPJx68XK/e4duuu/YOZ30gWSLyxrKFxMyLXA5i3MC45vDsai+OMJPpUJpWMnJILZBaU7eRpPS+1jYOvhIboiNke8=
X-Received: by 2002:a17:906:6a03:: with SMTP id
 qw3mr14876189ejc.43.1635522448259; 
 Fri, 29 Oct 2021 08:47:28 -0700 (PDT)
MIME-Version: 1.0
References: <20210909064138.GA22496@erisian.com.au>
 <CAO3Pvs-OviFkDJOsOWOt3Ea9t0g6xXb79hYdEe_L1=nB5ZjSQw@mail.gmail.com>
In-Reply-To: <CAO3Pvs-OviFkDJOsOWOt3Ea9t0g6xXb79hYdEe_L1=nB5ZjSQw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 29 Oct 2021 10:47:12 -0500
Message-ID: <CAGpPWDYWB+TXMjLSTFw_ti62++w43ojAhPKTXOPghvN-=Qa4Kg@mail.gmail.com>
To: Olaoluwa Osuntokun <laolu32@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008cfdf705cf7fbe0e"
X-Mailman-Approved-At: Fri, 29 Oct 2021 15:51:22 +0000
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode
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: Fri, 29 Oct 2021 15:47:33 -0000

--0000000000008cfdf705cf7fbe0e
Content-Type: text/plain; charset="UTF-8"

I very much like this idea. It seems pretty flexible and has a lot of
interesting properties and use cases without being very complex. I'll have
to read through this more deeply later. I'm curious to understand more how
it compares to OP_CTV. It seems that implementing OP_TLUV wouldn't make
OP_CTV obsolete/uncessary, is that right?

> And second, it doesn't provide a way for utxos to "interact",

This is talking about sending data to the output from an input or getting
data from a parent input, other than any added output tapscripts, right? I
think this can/should be done with a separate opcode, so I'm not sure I
would really call this a limitation here. I wrote a proposal for something
that does allow interaction like that (specifically sending data to an
output: OP_PUSHOUTPUTSTACK
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bip-pushoutputstack.md>
).

On Wed, Sep 22, 2021 at 7:29 PM Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi AJ,
>
> Happy to see that this proposal has finally seen the light of day! I've
> been
> hearing about it in hinted background convos over the past few months, so
> happy I can finally dig into the specifics of its operation.
>
> > So the idea is to do just that via a new opcode "TAPLEAF_UPDATE_VERIFY"
> > (TLUV) that takes three inputs: one that specifies how to update the
> > internal public key (X), one that specifies a new step for the merkle
> path
> > (F), and one that specifies whether to remove the current script and/or
> > how many merkle path steps to remove
>
> What if instead, it obtained the script from the _annex_? I think this
> small
> modification would make the op code even _more_ powerful. Consider that
> this
> allows a new script to be passed _dynamically_ after the output has been
> created, possibly by a threshold of parties that control the output, or
> them
> all (mu sig, etc, etc). This serves to create a generic "upgrade" mechanism
> for any tapscript output (covenant or not). Functionally, this is similar
> to
> the existence of "admin keys" or voted DAO upgrades that exists in chains
> that utilize an account based systems. This is really useful as it allows a
> script any given output to optional add in graftroot like behavior (leaf in
> tree that accepts script updates), and also allows contract developers to
> progressively upgrade or fix issues in prior versions of their deployed
> contracts.
>
> This little trick is secure since unlike the witness itself, the annex is
> actually _signed_ within the sighash like everything else. Incorporating
> this proposal would require the addition of an OP_PUSH_ANNEX op code, which
> by itself seems expertly useful. If one views the annex as a sort of
> authenticated associated data that can be passed into the script execution
> context, then this actually serves to absorb _some_ uses cases of a
> hypothetical OP_CHECKSIG_FROM_STACK opcode. A push annex op code also makes
> doing things like output delegation to a given key passed into the witness
> secure since the prior "owner" of the output commits to the key within the
> sighash.
>
> Even assuming a more powerful type of covenant that allows partial
> application of binding logic, something like this is still super useful
> since the action of re-creating a new tapscript tree based in dynamic input
> data would generate a rather large witness if only something like OP_CAT
> was
> available. The unique "update" nature of this appears to augment any other
> type of covenant, which is pretty cool. Consider that it would allow you
> (with the annex addition above), take something like a CTV congestion tree,
> and add in _new_ users at the tree is already being unrolled (just a toy
> example).
>
> It would also allow an individual to _join_ the payment pool construct
> described earlier which makes it 1000x more useful (vs just supporting
> unrolling). I haven't written it all down yet, but I think this along with
> something like CTV or CSFS makes it possible to implement a Plasma Cash [4]
> like Commit Chain [5], which is super exciting (assume a counter is
> embedded
> in the main script that tracks the next free leaf slot(s). With this model
> an "operator" is able to include a single transaction in the chain that
> stamps a batch of updates in the payment tree.  Users then get a
> contestation period where they can refute a modification to the tree in
> order to withdraw their funds.
>
> > And second, it doesn't provide a way for utxos to "interact",
>
> This is due to the fact that the op code doesn't allow any sort of late
> binding or pattern matching then constraining _where_ (or whence?) the
> coins
> can Be sent to. There's a group of developers that are attempting to make
> an
> AMM-like system on Liquid [1] using more generic stack based covenants [2]
> (see the `OP_INSPECTINPUT` op code, which seems very much inspired by
> jl2012's old proposal). However one challenge that still need to be tackled
> in the UTXO model is allowing multiple participants to easily interact w/
> the
> contract in a single block w/o a coordination layer to synchronize the
> access.
>
> One solution to this concurrency issue, that I believe is already employed
> by Chia is to allow "contracts" to be identified via a fixed ID (as long as
> their active in the chain) [3]. This lets transactions spend/interact with
> a
> contract, without always needing to know the set of active UTXOs where that
> contract lives. Transactions then specify their contract and "regular"
> inputs, with the requirement that every transaction spends at least a
> single
> regular input.
>
> The trade-off here is that nodes need to maintain this extra index into the
> UTXO set. However, this can be alleviated by applying a utreexo like
> solution: nodes maintain some merklized data structure over the index and
> require that spending transactions provide an _inclusion_ proof of the
> active contract. Nodes then only need to maintain root hashes of the UTXO
> and contract set.
>
> I'm super happy w.r.t how the covenant space has been processing over the
> past few years. IMO its the single most important (along with the utreexo
> type stateless stuff mentioned above) missing component to allow the
> creation of more decentralized self-custodial applications built on top of
> Bitcoin.
>
> -- Laolu
>
> [1]: https://medium.com/bit-matrix
> [2]:
> https://github.com/sanket1729/elements/blob/84339ba5e5dc65328d98afe2b1b33dcb69ba4311/doc/tapscript_opcodes.md
> [3]:
> https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37
> [4]: https://www.learnplasma.org/en/learn/cash.html
> [5]: https://eprint.iacr.org/2018/642
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000008cfdf705cf7fbe0e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I very much like this idea. It seems pretty flexible and h=
as a lot of interesting properties and use cases without being very complex=
. I&#39;ll have to read through this more deeply later. I&#39;m curious=C2=
=A0to understand more how it compares to OP_CTV. It seems that implementing=
 OP_TLUV wouldn&#39;t make OP_CTV obsolete/uncessary, is that right?<div><b=
r></div><div>&gt;=C2=A0<span style=3D"color:rgb(80,0,80)">And second, it do=
esn&#39;t provide a way for utxos to &quot;interact&quot;,</span></div><div=
><span style=3D"color:rgb(80,0,80)"><br></span></div>This is talking about =
sending data to the output from an input or getting data from a parent inpu=
t, other than any added output tapscripts, right? I think this can/should b=
e done with a separate opcode, so I&#39;m not sure I would really call this=
 a limitation here. I wrote a proposal for something that does allow intera=
ction like that (specifically sending data to an output: <a href=3D"https:/=
/github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bip-pushoutp=
utstack.md">OP_PUSHOUTPUTSTACK</a>).=C2=A0</div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 22, 2021 at 7:29 PM O=
laoluwa Osuntokun via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org">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:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">H=
i AJ, <br><br>Happy to see that this proposal has finally seen the light of=
 day! I&#39;ve been<br>hearing about it in hinted background convos over th=
e past few months, so<br>happy I can finally dig into the specifics of its =
operation.<br><br>&gt; So the idea is to do just that via a new opcode &quo=
t;TAPLEAF_UPDATE_VERIFY&quot;<br>&gt; (TLUV) that takes three inputs: one t=
hat specifies how to update the<br>&gt; internal public key (X), one that s=
pecifies a new step for the merkle path<br>&gt; (F), and one that specifies=
 whether to remove the current script and/or<br>&gt; how many merkle path s=
teps to remove<br><br>What if instead, it obtained the script from the _ann=
ex_? I think this small<br>modification would make the op code even _more_ =
powerful. Consider that this<br>allows a new script to be passed _dynamical=
ly_ after the output has been<br>created, possibly by a threshold of partie=
s that control the output, or them<br>all (mu sig, etc, etc). This serves t=
o create a generic &quot;upgrade&quot; mechanism<br>for any tapscript outpu=
t (covenant or not). Functionally, this is similar to<br>the existence of &=
quot;admin keys&quot; or voted DAO upgrades that exists in chains<br>that u=
tilize an account based systems. This is really useful as it allows a<br>sc=
ript any given output to optional add in graftroot like behavior (leaf in<b=
r>tree that accepts script updates), and also allows contract developers to=
<br>progressively upgrade or fix issues in prior versions of their deployed=
<br>contracts.<br><br>This little trick is secure since unlike the witness =
itself, the annex is<br>actually _signed_ within the sighash like everythin=
g else. Incorporating<br>this proposal would require the addition of an OP_=
PUSH_ANNEX op code, which<br>by itself seems expertly useful. If one views =
the annex as a sort of<br>authenticated associated data that can be passed =
into the script execution<br>context, then this actually serves to absorb _=
some_ uses cases of a<br>hypothetical OP_CHECKSIG_FROM_STACK opcode. A push=
 annex op code also makes<br>doing things like output delegation to a given=
 key passed into the witness<br>secure since the prior &quot;owner&quot; of=
 the output commits to the key within the<br>sighash.<br><br>Even assuming =
a more powerful type of covenant that allows partial<br>application of bind=
ing logic, something like this is still super useful<br>since the action of=
 re-creating a new tapscript tree based in dynamic input<br>data would gene=
rate a rather large witness if only something like OP_CAT was<br>available.=
 The unique &quot;update&quot; nature of this appears to augment any other<=
br>type of covenant, which is pretty cool. Consider that it would allow you=
<br>(with the annex addition above), take something like a CTV congestion t=
ree,<br>and add in _new_ users at the tree is already being unrolled (just =
a toy<br>example).<br><br>It would also allow an individual to _join_ the p=
ayment pool construct<br>described earlier which makes it 1000x more useful=
 (vs just supporting<br>unrolling). I haven&#39;t written it all down yet, =
but I think this along with<br>something like CTV or CSFS makes it possible=
 to implement a Plasma Cash [4]<br>like Commit Chain [5], which is super ex=
citing (assume a counter is embedded<br>in the main script that tracks the =
next free leaf slot(s). With this model<br>an &quot;operator&quot; is able =
to include a single transaction in the chain that<br>stamps a batch of upda=
tes in the payment tree.=C2=A0 Users then get a<br>contestation period wher=
e they can refute a modification to the tree in<br>order to withdraw their =
funds.<br><br>&gt; And second, it doesn&#39;t provide a way for utxos to &q=
uot;interact&quot;,<br><br>This is due to the fact that the op code doesn&#=
39;t allow any sort of late<br>binding or pattern matching then constrainin=
g _where_ (or whence?) the coins<br>can Be sent to. There&#39;s a group of =
developers that are attempting to make an<br>AMM-like system on Liquid [1] =
using more generic stack based covenants [2]<br>(see the `OP_INSPECTINPUT` =
op code, which seems very much inspired by<br>jl2012&#39;s old proposal). H=
owever one challenge that still need to be tackled<br>in the UTXO model is =
allowing multiple participants to easily interact w/ the<br>contract in a s=
ingle block w/o a coordination layer to synchronize the<br>access.<br><br>O=
ne solution to this concurrency issue, that I believe is already employed<b=
r>by Chia is to allow &quot;contracts&quot; to be identified via a fixed ID=
 (as long as<br>their active in the chain) [3]. This lets transactions spen=
d/interact with a<br>contract, without always needing to know the set of ac=
tive UTXOs where that<br>contract lives. Transactions then specify their co=
ntract and &quot;regular&quot;<br>inputs, with the requirement that every t=
ransaction spends at least a single<br>regular input. <br><br>The trade-off=
 here is that nodes need to maintain this extra index into the<br>UTXO set.=
 However, this can be alleviated by applying a utreexo like<br>solution: no=
des maintain some merklized data structure over the index and<br>require th=
at spending transactions provide an _inclusion_ proof of the<br>active cont=
ract. Nodes then only need to maintain root hashes of the UTXO<br>and contr=
act set.<br><br>I&#39;m super happy w.r.t how the covenant space has been p=
rocessing over the<br>past few years. IMO its the single most important (al=
ong with the utreexo<br>type stateless stuff mentioned above) missing compo=
nent to allow the<br>creation of more decentralized self-custodial applicat=
ions built on top of<br>Bitcoin.<br><br>-- Laolu<br><br>[1]: <a href=3D"htt=
ps://medium.com/bit-matrix" target=3D"_blank">https://medium.com/bit-matrix=
</a> <br>[2]: <a href=3D"https://github.com/sanket1729/elements/blob/84339b=
a5e5dc65328d98afe2b1b33dcb69ba4311/doc/tapscript_opcodes.md" target=3D"_bla=
nk">https://github.com/sanket1729/elements/blob/84339ba5e5dc65328d98afe2b1b=
33dcb69ba4311/doc/tapscript_opcodes.md</a><br>[3]: <a href=3D"https://forum=
.celestia.org/t/accounts-strict-access-lists-and-utxos/37" target=3D"_blank=
">https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37</a=
><br>[4]: <a href=3D"https://www.learnplasma.org/en/learn/cash.html" target=
=3D"_blank">https://www.learnplasma.org/en/learn/cash.html</a> <br>[5]: <a =
href=3D"https://eprint.iacr.org/2018/642" target=3D"_blank">https://eprint.=
iacr.org/2018/642</a><br></div>
_______________________________________________<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>

--0000000000008cfdf705cf7fbe0e--