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 >