Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2BBF5C0020 for ; 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 ; 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 ; 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 ; Fri, 29 Oct 2021 15:47:30 +0000 (UTC) Received: by mail-ed1-x52a.google.com with SMTP id r12so40333347edt.6 for ; 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> In-Reply-To: From: Billy Tetrud Date: Fri, 29 Oct 2021 10:47:12 -0500 Message-ID: To: Olaoluwa Osuntokun , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000008cfdf705cf7fbe0e" X-Mailman-Approved-At: Fri, 29 Oct 2021 15:51:22 +0000 Cc: Anthony Towns 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ). 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
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?
>=C2=A0And second, it do= esn'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 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: OP_PUSHOUTPUTSTACK).=C2=A0
On Wed, Sep 22, 2021 at 7:29 PM O= laoluwa Osuntokun via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
H= i 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 th= e 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 &quo= t;TAPLEAF_UPDATE_VERIFY"
> (TLUV) that takes three inputs: one t= hat specifies how to update the
> internal public key (X), one that s= pecifies a new step for the merkle path
> (F), and one that specifies= whether to remove the current script and/or
> how many merkle path s= teps to remove

What if instead, it obtained the script from the _ann= ex_? I think this small
modification would make the op code even _more_ = powerful. Consider that this
allows a new script to be passed _dynamical= ly_ after the output has been
created, possibly by a threshold of partie= s that control the output, or them
all (mu sig, etc, etc). This serves t= o create a generic "upgrade" mechanism
for any tapscript outpu= t (covenant or not). Functionally, this is similar to
the existence of &= quot;admin keys" or voted DAO upgrades that exists in chains
that u= tilize an account based systems. This is really useful as it allows a
sc= ript any given output to optional add in graftroot like behavior (leaf intree 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 everythin= g 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 bind= ing logic, something like this is still super useful
since the action of= re-creating a new tapscript tree based in dynamic input
data would gene= rate a rather large witness if only something like OP_CAT was
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=
(with the annex addition above), take something like a CTV congestion t= ree,
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 p= ayment 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 ex= citing (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 upda= tes in the payment tree.=C2=A0 Users then get a
contestation period wher= e 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 &q= uot;interact",

This is due to the fact that the op code doesn&#= 39;t allow any sort of late
binding or pattern matching then constrainin= g _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). H= owever one challenge that still need to be tackled
in the UTXO model is = allowing multiple participants to easily interact w/ the
contract in a s= ingle block w/o a coordination layer to synchronize the
access.

O= ne solution to this concurrency issue, that I believe is already employedby Chia is to allow "contracts" to be identified via a fixed ID= (as long as
their active in the chain) [3]. This lets transactions spen= d/interact with a
contract, without always needing to know the set of ac= tive UTXOs where that
contract lives. Transactions then specify their co= ntract and "regular"
inputs, with the requirement that every t= ransaction 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: no= des maintain some merklized data structure over the index and
require th= at spending transactions provide an _inclusion_ proof of the
active cont= ract. Nodes then only need to maintain root hashes of the UTXO
and contr= act set.

I'm super happy w.r.t how the covenant space has been p= rocessing over the
past few years. IMO its the single most important (al= ong with the utreexo
type stateless stuff mentioned above) missing compo= nent to allow the
creation of more decentralized self-custodial applicat= ions built on top of
Bitcoin.

-- Laolu

[1]: https://medium.com/bit-matrix=
[2]: https://github.com/sanket1729/elements/blob/84339ba5e5dc65328d98afe2b1b= 33dcb69ba4311/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/mail= man/listinfo/bitcoin-dev
--0000000000008cfdf705cf7fbe0e--