From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Trey Del Bonis <trey.delbonis@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: John Light <bitcoin-dev@lightco•in>
Subject: Re: [bitcoin-dev] Validity Rollups on Bitcoin
Date: Fri, 04 Nov 2022 23:07:56 +0000 [thread overview]
Message-ID: <ifQPuaXwfXmFtiJrak3aOvpXG8fzm3-eNDCJVS_Us6WI-gcrd4vGeV6ZGk5sKDoy4SEz2K1PSMcVpflRXUmvud1gpVWWDgQr26e-1U5XJ5k=@protonmail.com> (raw)
In-Reply-To: <629da3d8-ee34-9acb-511b-4af1913eceff@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
prev parent reply other threads:[~2022-11-04 23:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-11 15:40 John Light
2022-10-12 13:28 ` Greg Sanders
2022-10-12 15:40 ` John Light
2022-11-02 17:19 ` AdamISZ
2022-11-04 19:53 ` Trey Del Bonis
2022-11-04 20:29 ` Russell O'Connor
2022-11-04 23:07 ` ZmnSCPxj [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ifQPuaXwfXmFtiJrak3aOvpXG8fzm3-eNDCJVS_Us6WI-gcrd4vGeV6ZGk5sKDoy4SEz2K1PSMcVpflRXUmvud1gpVWWDgQr26e-1U5XJ5k=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lightco$(echo .)in \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=trey.delbonis@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox