1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 970B6C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Nov 2022 23:08:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 6530B4014D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Nov 2022 23:08:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6530B4014D
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=wvjPfg7I
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id xac99qJBye56
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Nov 2022 23:08:04 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 95873400FD
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
by smtp2.osuosl.org (Postfix) with ESMTPS id 95873400FD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Nov 2022 23:08:04 +0000 (UTC)
Date: Fri, 04 Nov 2022 23:07:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1667603281; x=1667862481;
bh=aL/OvFUm9diqO7WNvw7A2Y7PdovXFm5OlSJ0fH+W48s=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=wvjPfg7IU8+aSHTXdFqM9/FR2bDrF+MZQif6Yn+02h/Kf4UV+NPV+Ecl5X/vOta5g
cCqwMUUw4cEzI9fqKtTDiXlsSEnSg6ALPc4wcW2+53xhU+q3NaDTI/L+uG1sSsh4ta
gkV2KuiiD8Ef3znwACFlv0SmvsM67pc0hznvcZckc/CbqwAj22+meslsSiA2qnktCb
T/N9lJQ2PPy8gY2ah4/8yKHM//vvdjzhvU08eoiVruF/ZVo/2kkMIb+5dXwq2mKJjC
LRPFxfhR+qPggBY5ZLp3UvR2OA+xdD3Q3HrEWeDiXHajDxoQ0OX+R9kNmosr64XFgg
dAkgEnhr3qzTQ==
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2022 23:08:05 -0000
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
|
