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
