Re: [bitcoin-dev] Validity Rollups on Bitcoin

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Trey,

> * something like OP_PUSHSCRIPT which would remove the need for the
> introspection the the prevout's script and avoids duplicating data in
> the witness
> * some kind of OP_MERKLEUPDATEVERIFY which checks a merkle proof for a
> leaf against a root and checks if replacing the leaf with some hash
> using the proof yields a specified updated root (or instead, a version
> that just pushes the updated root)
> * if we really wanted to golf the size of the script, then possibly a
> limited form of OP_EVAL if we can't figure out another way to split up
> the different spend paths into different tapleafs while still being able
> to do the recursive covenant, but still the script and the vk would
> still be significant so it's not actually that much benefit per-batch

A thing I had been musing on is to reuse pay-to-contract to store a commitment to the state.

As we all know, in Taproot, the Taproot outpoint script is just the public key corresponding to the pay-to-contract of the Taproot MAST root and an internal public key.

The internal public key can itself be a pay-to-contract, where the contract being committed to would be the state of some covenant.

One could then make an opcode which is given an "internal internal" pubkey (i.e. the pubkey that is behind the pay-to-contract to the covenant state, which when combined serves as the internal pubkey for the Taproot construct), a current state, and an optional expected new state.
It determines if the Taproot internal pubkey is actually a pay-to-contract of the current state on the internal-internal pubkey.
If the optional expected new state exists, then it also recomputes a pay-to-contract of the new state to the same internal-internal pubkey, which is a new Taproot internal pubkey, and then recomputes a pay-to-contract of the same Taproot MAST root on the new Taproot internal pubkey, and that the first output commits to that.

Basically it retains the same MASTed set of Tapscripts and the same internal-internal pubkey (which can be used to escape the covenant, in case a bug is found, if it is an n-of-n of all the interested parties, or otherwise should be a NUMS point if you trust the tapscripts are bug-free), only modifying the covenant state.
The covenant state is committed to on the Taproot output, indirectly by two nested pay-to-contracts.

With this, there is no need for quining and `OP_PUSHSCRIPT`.
The mechanism only needs some way to compute the new state from the old state.

In addition, you can split up the control script among multiple Tapscript branches and only publish onchain (== spend onchain bytes) the one you need for a particular state transition.

Regards,
ZmnSCPxj