Date: Fri, 04 Nov 2022 23:07:56 +0000
To: Trey Del Bonis <trey.delbonis@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <ifQPuaXwfXmFtiJrak3aOvpXG8fzm3-eNDCJVS_Us6WI-gcrd4vGeV6ZGk5sKDoy4SEz2K1PSMcVpflRXUmvud1gpVWWDgQr26e-1U5XJ5k=@protonmail.com>
In-Reply-To: <629da3d8-ee34-9acb-511b-4af1913eceff@protonmail.com>
References: <689ed481-e7eb-4fea-8ca7-578503f3f285@app.fastmail.com>
 <CAB3F3Dt5oy93duGvYb7SZ7wn7DCvn9FjVwRU9ENNa79yjzmdCQ@mail.gmail.com>
 <224cf2f4-2577-4331-9977-ea71e9723ffe@app.fastmail.com>
 <WJ0jiInq_I_IiiT8EiAZZN6axo2pSIRCxQWfyvgU-4rjRmeHnCXFNGWFSXoeOv7nVmqoAPr6EHeXRgc-1DfiPX3C8xHwdYzs2qn4Lck06fs=@protonmail.com>
 <629da3d8-ee34-9acb-511b-4af1913eceff@protonmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: John Light <bitcoin-dev@lightco.in>
Subject: Re: [bitcoin-dev] Validity Rollups on Bitcoin
Precedence: list

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 commitm=
ent 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 in=
ternal 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 fir=
st output commits to that.

Basically it retains the same MASTed set of Tapscripts and the same interna=
l-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 sh=
ould be a NUMS point if you trust the tapscripts are bug-free), only modify=
ing 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 sta=
te.

In addition, you can split up the control script among multiple Tapscript b=
ranches and only publish onchain (=3D=3D spend onchain bytes) the one you n=
eed for a particular state transition.

Regards,
ZmnSCPxj