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
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7EB41B88
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 03:51:20 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0F2E9F4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 03:51:18 +0000 (UTC)
Date: Fri, 24 May 2019 03:51:13 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1558669876;
bh=YnDKj+mLjRct+CzsepcHGwBUA0cdxpISp2XcdIyhm/M=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=D9G/RGXDDpVFoxkF2uKg7XKRpJc/o7Jf53PPUBaWhxCEtFvr1F33YBaxWXfx9UG4v
W68SZlG72f7Ipu6y7g2LDJP+rBuA2XVmwer3IICPLy2pVAjqh0cgyK5YgCkbwAg/vG
uDJgBwLEyFhaZ7BnvL9rNP67cb1NYvJ4N4Q2JbvM=
To: Jimmy Song <jaejoon@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <t6W0uozSuBP3lw7_leWuRW28TY9d31o5G8GxHQc4VoDFG3xBX0AKvUvCJMZpfLtlt5S1UGJhJMN6_Nr5MZoWRbxvNRx_-DqBa51EffCjXjI=@protonmail.com>
In-Reply-To: <CAJR7vkqogCzy8_SpCxcAhnEdkS6DRKaDtvJa8Wc-TNGsCcjM5g@mail.gmail.com>
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
<CAJR7vkqogCzy8_SpCxcAhnEdkS6DRKaDtvJa8Wc-TNGsCcjM5g@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 24 May 2019 14:39:19 +0000
Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 24 May 2019 03:51:20 -0000
Good morning Jimmy,
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Friday, May 24, 2019 1:36 AM, Jimmy Song via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
> Hi Russell,
>
> This is probably a dumb question, but I'd like to get some clarity on you=
r proposal.
>
> OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message and pubkey.=
Presumably, the message would then have to get constructed as part of the =
Script execution. What would such a message look like? What, in other words=
, would you be signing and would that be similar to what signatures sign no=
w? Would it be a single blob that incorporates all the input/output informa=
tion in some hashed manner (like BIP143)? Or would you need separate signat=
ures for different parts of the transaction? Or is it something more compli=
cated like aggregating multiple signatures over different parts of the tran=
saction?
In order to use `OP_CHECKSIGFROMSTACK` work to allow transaction introspect=
ion, the message to be signed would be the equivalent of the sighash digest=
using `SIGHASH_ALL`.
As a general pattern, if you want a SCRIPT that imposes some rule on some f=
ield in the sighash digest of the transaction:
1. You would require that the transaction be split into three parts, with =
those parts provided in the witness stack.
One would be "data before the field", then "the field", then "data afte=
r the field".
2. In addition, you would require a signature for the transaction in addit=
ion to the transaction parts above.
3. You would ensure that "data before the field" is the correct size, so t=
hat you know "the field" is at the correct location in the transaction.
Alternately you might need to also introspect some other fields in orde=
r to ensure other details like number of inputs, number of outputs, value o=
f inputs etc. etc. are what you expect.
4. You would check that the given signature is `SIGHASH_ALL` (most easily =
by checking its size --- proposed Schnorr signatures have a fixed size, and=
the lack of an extra sighash flags byte means `SIGHASH_ALL` by default, so=
if the signature is exactly the fixed Schnorr signature size, it is `SIGHA=
SH_ALL`).
5. You would use normal `OP_CHECKSIGVERIFY` to ensure that the signature s=
igns the actual transaction.
6. You would concatenate the supposed parts of the transaction together an=
d use `OP_CHECKSIGFROMSTACKVERIFY` to ensure that the signature *also* is v=
alid for that.
Since you know the signature is valid for the transaction itself, if it=
*also* is valid for this, then the concatenation of the input "data before=
the field", "the field", and "data after the field" is exactly the same si=
ghash digest as the actual transaction, and thus is accurate to the transac=
tion.
7. Finally, you would actually validate the field you want to impose some =
rule on.
`SIGHASH_ALL` is suggested since it allows you to introspect all fields, bu=
t also because ensuring that the signature is indeed a `SIGHASH_ALL` signat=
ure is easier (just do the size check).
Alternately you can use some other flag, but you would require the signatur=
e on the stack to be flagless and concat the flag yourself before using `OP=
_CHECKSIGVERIFY`.
This mechanism is very general and allows SCRIPT to introspect *any* field =
of the transactions.
Indeed, one can argue that `OP_CHECKLOCKTIMEVERIFY` and `OP_CHECKSEQUENCEVE=
RIFY` are both superfluous in a system with `OP_CAT` and `OP_CHECKSIGFROMST=
ACK`.
OF course, these operations are significantly more optimized since they do =
not require that you quine the transaction.
Regards,
ZmnSCPxj
>
> Best,
>
> Jimmy
>
> On Thu, May 23, 2019 at 8:35 AM Russell O'Connor via bitcoin-dev <bitcoin=
-dev@lists.linuxfoundation.org> wrote:
>
> > Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT a=
nd OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for=
Bitcoin via new Script operations.=C2=A0 However, I think that these propo=
sals miss the mark when it comes to how they approach Bitcoin Script and la=
nguage features.
> >
> > Bitcoin Script appears designed to be a flexible programmable system th=
at provides generic features to be composed to achieve various purposes.=
=C2=A0 Thus, when we design new language features for Script, we should be =
striving, as much as possible, to similarly build general purpose tools whi=
ch can in turn be used for a variety of purposes.
> >
> > I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fa=
il to achieve these design goals.=C2=A0 They are both are designed with ver=
y narrow applications in mind, while also going out of their way to extend =
the semantic domain of the interpretation of Bitcoin operations in new ways=
that complicate their specification.=C2=A0 In the case of SIGHASH_ANYPREVO=
UT, the semantic domain is extended by adding new counters to track the use=
of various v0 and v2 signature types.=C2=A0 In the case of OP_CHECKOUTPUTH=
ASHVERIFY, it employs a new context-sensitive operation that peeks at the v=
alue of surrounding opcodes.
> >
> > Instead, I propose that, for the time being, we simply implement OP_CAT=
and OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 OP_CAT pops two byte arrays off the =
stack and pushes their concatenation back onto the stack.=C2=A0 OP_CHECKSIG=
FROMSTACKVERIFY pops a signature, message, and pubkey off the stack and per=
forms a bip-schnorr verification on the SHA256 hash of the message.
> >
> > In concert, these two operations enable:
> >
> > * Oracle signature verification, including discrete log contracts.
> > * Amortized secure multiparty computations (see "Amortizing Secure Comp=
utation with Penalties" by Kumaresan and Bentov).
> > * Transaction introspection including:
> > +=C2=A0Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned s=
imply by the nature of the construction.
> > + Decide if a transaction has exactly one input or not. (etc.)
> > + Weak covenants, which can verify output scripts to see if they are am=
ong a set of predefined values or verify the output hash.
> >
> > and presumably more applications as well.
> >
> > For better or for worse, without an OP_PUBKEYTWEEK operation available,=
the more interesting recursive-covenants remain largely out of reach, with=
the exception of a recursive covenant that is only able to send back to it=
s own address, possibly abusing its own TXO value as a state variable.
> >
> > All this is accomplished by two straightforward opcodes whose semantics=
are pure computational operations on stack values.=C2=A0 The only semantic=
side-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the exi=
sting 'sigops_passed' count.=C2=A0 Moreover, I feel that adding these opera=
tions does not preclude adding more specialized opcodes in the future as an=
optimization for whatever popular constructions come up, once we know what=
those are.
> >
> > I feel that this style of generic building blocks truly embodies what i=
s meant by "programmable money".
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
