Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

From: Billy Tetrud <billy.tetrud@gmail•com>
To: Olaoluwa Osuntokun <laolu32@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode
Date: Fri, 29 Oct 2021 10:47:12 -0500	[thread overview]
Message-ID: <CAGpPWDYWB+TXMjLSTFw_ti62++w43ojAhPKTXOPghvN-=Qa4Kg@mail.gmail.com> (raw)
In-Reply-To: <CAO3Pvs-OviFkDJOsOWOt3Ea9t0g6xXb79hYdEe_L1=nB5ZjSQw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6908 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 8249 bytes --]