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
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 71802EEB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 22:06:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f175.google.com (mail-it1-f175.google.com
[209.85.166.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B279E6C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 22:06:56 +0000 (UTC)
Received: by mail-it1-f175.google.com with SMTP id m140so10852055itg.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 15:06:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=0BUClu3rjVKiK/QHRyinnIymHZYmBkq3ooawzBBo4V4=;
b=Y/971n5mQMSqcm20VYw/M/DDMLKDngSuCNCy7vOg7I1YN55HxsV66+ea3qw2D6OBxc
4/8D3NvUJbtZZ23i/1mXmt5H03LgbncE/p40JDNrSPlsjGCM5fV1oHdrLX7+74740CDg
UstfwnDFMSlJWdf4CsoNvBD1uVHcyBsYT1OgA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=0BUClu3rjVKiK/QHRyinnIymHZYmBkq3ooawzBBo4V4=;
b=Y+TClkk5zoWPzJNmYSki6Io6C/RbbRsZU9GK4PNXX/b0m4aEbIVX1sEWr+Yq48EVLY
Ndd0VPkeAiQ9ezL+47nhSncnT5X51qm/hncl38vC6FLWms8bKctLg3oPOjlLQ5LBsE00
Uq7dlW602z5yNixjK/GpZ0YDhbOqwEc/H9O4bp/n9D+5p3Raky+Ldee3ymohfJ2Idnfa
TJc5dYWBrqVHZYB92okjWK+JaN5FKrHbHl/VY/hAoGif/8gSF5BwAkWQqs9exMJkZQvY
pxb+caYO/9nCtLf2hdbk/vKZvVYkGyGzcmxQy3XjgRUrPk+W0cgDQrd+pJKPsWpxh32o
tkGg==
X-Gm-Message-State: APjAAAUYmjqz7y7DR5mAG1Ws02GTDxWc4Y9klllrrYj/kPfAZupmrLnZ
UNbs8eVwQ278maSL0qZpgP6Ar+67pCVzBZQXHy73ZQ==
X-Google-Smtp-Source: APXvYqwcmlUcHwwyjY45oqZrSB2UaRmfCLcdDHNdhXeFnDa2V74WOMHPQFUEwfc5Msu0zT1+YknPeJ75EyI8diyBbR8=
X-Received: by 2002:a05:660c:50:: with SMTP id
p16mr14602460itk.146.1558649215978;
Thu, 23 May 2019 15:06:55 -0700 (PDT)
MIME-Version: 1.0
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
<-doGGpQeidaYIWCJLexeiJPyi1leWSjZ4nMdO6K2CmhnaTLLtJCz4kOTY5stLEuly0qe7TUSYjzqoksbiXPp7IrA-qk0c8Abr_2Nad7ZJks=@protonmail.com>
In-Reply-To: <-doGGpQeidaYIWCJLexeiJPyi1leWSjZ4nMdO6K2CmhnaTLLtJCz4kOTY5stLEuly0qe7TUSYjzqoksbiXPp7IrA-qk0c8Abr_2Nad7ZJks=@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Thu, 23 May 2019 18:06:45 -0400
Message-ID: <CAMZUoKnD5_L7H8tGp2nbEV8-RQ8kJPxvpMp2Hi2Hu1=-DWsPZA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000d921d40589954ceb"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Thu, 23 May 2019 22:06:57 -0000
--000000000000d921d40589954ceb
Content-Type: text/plain; charset="UTF-8"
Hello ZmnSCPxj,
I agree that adding OP_CHECKSIGFROMSTACK doesn't preclude adding shortcuts
such as `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`, and I agree
we ought to support such operations directly, especially if we see
widespread use of these constructions in practice.
I think it is desirable to add OP_CHECKSIGFROMSTACK for its direct purposes
of enabling oracle verification and discreet log contracts. Moreover, it
would be better decide if we do or do not want to do this first, because
whether or not we chose to implement a general OP_CHECKSIGFROMSTACK will
influence the design of these other proposals.
For example, if we choose to deploy OP_CHECKSIGFROMSTACK, then the design
of OP_CHECKOUTPUTSHASHVERIFY ought to be simplified to OP_PUSHOUTPUTHASH
and OP_PUSHNUMINPUTS (etc.) because the proposal would no longer be
extending the expressiveness of Bitcoin Script. And while
OP_CHECKSIGFROMSTACK doesn't directly address whether SIGHASH_ANYPREVOUT
should be with or without a chaperone (as the simulated version with
OP_CHECKSIGFROMSTACK is necessarily chaperoned), we might get an
opportunity to learn if users are willing to take advantage of the
chaperone, or whether they rather bypass it by using a short well-known
pubkey: (e.g.
0x0200000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63)
and/or similar short signatures if we deploy OP_CHECKSIGFROMSTACK first.
Since most of the "scary" recursive convents are not available with
OP_CHECKSIGFROMSTACK within taproot (without further extensions), the
OP_CHECKSIGFROMSTACK proposal now has quite different consequences than
before.
On Thu, May 23, 2019 at 12:59 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning Russell,
>
> While I am sympathetic to this argument from first principles, as I
> understand it, it requires that provided witness inputs will become larger,
> compared to "shortcuts" like `SIGHASH_ANYPREVOUT` and
> `OP_CHECKOUTPUTSHASHVERIFY`.
>
> For instance, to simulate `SIGHASH_ANYPREVOUT` with `OP_CAT` and
> `OP_CHECKSIGFROMSTACK`, I would effectively split the unsigned transaction
> into its "inputs" and "outputs" part, concat them and use
> `OP_CHECKSIGFROMSTACK` on the chaperone signature, and also use a normal
> `OP_CHECKSIGVERIFY` on that same chaperone signature, then dup the
> "outputs" part and use `OP_CHECKSIGFROMSTACK` on the "any
> prevout"/"noinput" signature.
> I would effectively give the transaction to itself as part of the witness,
> and further, I would also have to very carefully write the script
> (admittedly the writing of the template could be done once, but it would
> require far more review than simple usages of the "limited" operations like
> `SIGHASH_ANYPREVOUT`).
> So my witness stack would contain two signatures, and a duplicate of the
> transaction itself, plus a very much complicated script, whereas use of
> `SIGHASH_ANYPREVOUT` just requires two signatures and a script not much
> longer than pre-Schnorr multisig scripts.
>
>
> It seems to me desirable, to try to reduce bandwidth consumption on the
> Bitcoin blockchain, including witness data.
> Indeed, I had thought the whole exercise of putting `OP_CHECKSIGFROMSTACK`
> in a federated sidechain (Elements/Liquid) was to try to identify common
> patterns of usage for that opcode, and *then* to propose those common
> patterns as specific "optimized" opcodes as a sort of "jet" for Bitcoin
> itself (but not `OP_CHECKSIGFROMSTACK` itself).
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
--000000000000d921d40589954ceb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hello ZmnSCPxj,</div><div><br></div><div>I agree that=
adding OP_CHECKSIGFROMSTACK doesn't preclude adding shortcuts such as =
`SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`, and I agree we ought =
to support such operations directly, especially if we see widespread use of=
these constructions in practice.</div><div><br></div><div>I think it is de=
sirable to add OP_CHECKSIGFROMSTACK for its direct purposes of enabling ora=
cle verification and discreet log contracts.=C2=A0 Moreover, it would be be=
tter decide if we do or do not want to do this first, because whether or no=
t we chose to implement a general OP_CHECKSIGFROMSTACK will influence the d=
esign of these other proposals.</div><div><br></div><div>For example, if we=
choose to deploy OP_CHECKSIGFROMSTACK, then the design of OP_CHECKOUTPUTSH=
ASHVERIFY ought to be simplified to OP_PUSHOUTPUTHASH and OP_PUSHNUMINPUTS =
(etc.) because the proposal would no longer be extending the expressiveness=
of Bitcoin Script.=C2=A0 And while OP_CHECKSIGFROMSTACK doesn't direct=
ly address whether SIGHASH_ANYPREVOUT should be with or without a chaperone=
(as the simulated version with OP_CHECKSIGFROMSTACK is necessarily chapero=
ned), we might get an opportunity to learn if users are willing to take adv=
antage of the chaperone, or whether they rather bypass it by using a short =
well-known pubkey: (e.g. 0x0200000000000000000000003b78ce563f89a0ed9414f5aa=
28ad0d96d6795f9c63) and/or similar short signatures if we deploy OP_CHECKSI=
GFROMSTACK first.</div><div><br></div><div>Since most of the "scary&qu=
ot; recursive convents are not available with OP_CHECKSIGFROMSTACK within t=
aproot (without further extensions), the OP_CHECKSIGFROMSTACK proposal now =
has quite different consequences than before.</div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 23, 2019 at 12:59 =
PM ZmnSCPxj <<a href=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank=
">ZmnSCPxj@protonmail.com</a>> wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">Good morning Russell,<br>
<br>
While I am sympathetic to this argument from first principles, as I underst=
and it, it requires that provided witness inputs will become larger, compar=
ed to "shortcuts" like `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSH=
ASHVERIFY`.<br>
<br>
For instance, to simulate `SIGHASH_ANYPREVOUT` with `OP_CAT` and `OP_CHECKS=
IGFROMSTACK`, I would effectively split the unsigned transaction into its &=
quot;inputs" and "outputs" part, concat them and use `OP_CHE=
CKSIGFROMSTACK` on the chaperone signature, and also use a normal `OP_CHECK=
SIGVERIFY` on that same chaperone signature, then dup the "outputs&quo=
t; part and use `OP_CHECKSIGFROMSTACK` on the "any prevout"/"=
;noinput" signature.<br>
I would effectively give the transaction to itself as part of the witness, =
and further, I would also have to very carefully write the script (admitted=
ly the writing of the template could be done once, but it would require far=
more review than simple usages of the "limited" operations like =
`SIGHASH_ANYPREVOUT`).<br>
So my witness stack would contain two signatures, and a duplicate of the tr=
ansaction itself, plus a very much complicated script, whereas use of `SIGH=
ASH_ANYPREVOUT` just requires two signatures and a script not much longer t=
han pre-Schnorr multisig scripts.<br>
<br>
<br>
It seems to me desirable, to try to reduce bandwidth consumption on the Bit=
coin blockchain, including witness data.<br>
Indeed, I had thought the whole exercise of putting `OP_CHECKSIGFROMSTACK` =
in a federated sidechain (Elements/Liquid) was to try to identify common pa=
tterns of usage for that opcode, and *then* to propose those common pattern=
s as specific "optimized" opcodes as a sort of "jet" fo=
r Bitcoin itself (but not `OP_CHECKSIGFROMSTACK` itself).<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
<br>
Sent with ProtonMail Secure Email.<br>
</blockquote></div></div>
--000000000000d921d40589954ceb--
|
