diff options
| author | Billy Tetrud <billy.tetrud@gmail.com> | 2021-10-29 10:47:12 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-10-29 15:47:33 +0000 |
| commit | 53a2d49c1470555f08fdb581b4dc258ea617d617 (patch) | |
| tree | d94fe758ebd16f4bcb852376f358f674da71099e | |
| parent | 0887ef12313a0adb893c99e89190c7fede6ea37a (diff) | |
| download | pi-bitcoindev-53a2d49c1470555f08fdb581b4dc258ea617d617.tar.gz pi-bitcoindev-53a2d49c1470555f08fdb581b4dc258ea617d617.zip | |
Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode
| -rw-r--r-- | 27/57aec63d2b7b3fea66da45e3cc8e7dfb1abd3f | 348 |
1 files changed, 348 insertions, 0 deletions
diff --git a/27/57aec63d2b7b3fea66da45e3cc8e7dfb1abd3f b/27/57aec63d2b7b3fea66da45e3cc8e7dfb1abd3f new file mode 100644 index 000000000..6511b1efd --- /dev/null +++ b/27/57aec63d2b7b3fea66da45e3cc8e7dfb1abd3f @@ -0,0 +1,348 @@ +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'll have to read through this more deeply later. I'm curious=C2= +=A0to understand more how it compares to OP_CTV. It seems that implementing= + OP_TLUV wouldn't make OP_CTV obsolete/uncessary, is that right?<div><b= +r></div><div>>=C2=A0<span style=3D"color:rgb(80,0,80)">And second, it do= +esn't provide a way for utxos to "interact",</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'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 <<a href=3D"mailto:bitcoin-dev@lists.l= +inuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> 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'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>> So the idea is to do just that via a new opcode &quo= +t;TAPLEAF_UPDATE_VERIFY"<br>> (TLUV) that takes three inputs: one t= +hat specifies how to update the<br>> internal public key (X), one that s= +pecifies a new step for the merkle path<br>> (F), and one that specifies= + whether to remove the current script and/or<br>> 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 "upgrade" mechanism<br>for any tapscript outpu= +t (covenant or not). Functionally, this is similar to<br>the existence of &= +quot;admin keys" 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 "owner" 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 "update" 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'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 "operator" 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>> And second, it doesn't provide a way for utxos to &q= +uot;interact",<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'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'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 "contracts" 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 "regular"<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'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-- + |