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
|
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 B037D710
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Nov 2018 17:07:44 +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 9AAC880F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Nov 2018 17:07:43 +0000 (UTC)
Received: by mail-it1-f175.google.com with SMTP id o19so9900397itg.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Nov 2018 09:07:43 -0800 (PST)
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;
bh=Uz7z/vEi+6wsgVytaogdSHyWPMOvsT7hQakAIwGD8lg=;
b=p6JcfvyyBsPqY8C/0zKTqyGLHnj7XOtiD4AbmyU0hhewyh4wJRc8MeX6o0PAuw9uaB
xTnEhiJPrlDtDwkjMuglH66Kp7XZIm8Khd9ijZ1n3mDYf42uT4vPfCamBlg7xMffZJz+
GYe/0pcuLD8y//x/iKHGm4SwqvgUU/Fqezg/4=
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;
bh=Uz7z/vEi+6wsgVytaogdSHyWPMOvsT7hQakAIwGD8lg=;
b=Tul4rHWArisYvQ9hOP1khgZrsxafQNZhWaAAGO0eRPot6eA+OvB8OOcJn+0y7iZNDL
kpUk0uHBIH1Cp/pmuhb0/CfP8FxdBefUkOK4Ra7k533LsWQ00PiQ++djxPdE3tqP0ndk
V0oUP5GdX9Q0R42wVJOeNBhD5myB5fBL82//uF+rwsqx10xNMf3EPLmLfQng7es93QYP
evToyZoqaFPInHI4yj+Ns/YGNv7A5FzQ8L7sYH4LRPm2pR7J2MYue46/pY9CQlu9JGun
vuaGTdRoBB++8J4Rkr/Z2idJVeaOKyNiwR2xnwA76wou5UZjtB6qWUMFN3wQxtuHN2dx
KwFA==
X-Gm-Message-State: AGRZ1gKvieAaIO+9oAzQI9t1s6fe1ibCDgj9nqAiWsZpFAl3nt6V+fh6
/F0HIZlHyxrjuIW1IR4u6NqBWh0j089OHzq3ipGd4w==
X-Google-Smtp-Source: AJdET5eabbfvK4+SeAdpjH6OdNU+vdJkxIB4iKzCuyQsGMiRYxRe/PPuON6mGnYobndIW35m1yu50odVloWmkbI3p30=
X-Received: by 2002:a24:aa04:: with SMTP id
b4-v6mr6369799itf.127.1542820062637;
Wed, 21 Nov 2018 09:07:42 -0800 (PST)
MIME-Version: 1.0
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
In-Reply-To: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Wed, 21 Nov 2018 12:07:30 -0500
Message-ID: <CAMZUoK==Bdn73Lc=swgf2F5_mqE84TR1GRBFhrFkn7kab4jBaw@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c96a34057b2fc954"
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: Thu, 22 Nov 2018 14:08:02 +0000
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
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: Wed, 21 Nov 2018 17:07:44 -0000
--000000000000c96a34057b2fc954
Content-Type: text/plain; charset="UTF-8"
On Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> So my question is whether anyone can see ways in which this introduces
> redundant flexibility, or misses obvious use cases?
>
Hopefully my comment is on-topic for this thread:
Given that we want to move away from OP_CODESEPARATOR, because each call to
this operation effectively takes O(script-size) time, we need a replacement
for the functionality it currently provides. While perhaps the original
motivation for OP_CODESEPARTOR is surrounded in mystery, it currently can
be used (or perhaps abused) for the task of creating signature that covers,
not only which input is being signed, but which specific branch within that
input Script code is being signed for.
For example, one can place an OP_CODESEPARATOR within each branch of an IF
block, or by placing an OP_CODESEPARATOR before each OP_CHECKSIG
operation. By doing so, signatures created for one clause cannot be used
as signatures for another clause. Since different clauses in Bitcoin
Script may be enforcing different conditions (such as different time-locks,
hash-locks, etc), it is useful to be able to sign in such a way that your
signature is only valid when the conditions for a particular branch are
satisfied. In complex Scripts, it may not be practical or possible to use
different public keys for every different clause. (In practice, you will be
able to get away with fewer OP_CODESEPARATORS than one in every IF block).
One suggestion I heard (I think I heard it from Pieter) to achieve the
above is to add an internal counter that increments on every control flow
operator, OP_IF, OP_NOTIF, OP_ELSE, OP_ENDIF, and have the signature cover
the value of this counter. Equivalently we divide every Bitcoin Script
program into blocks deliminated by these control flow operator and have the
signature cover the index of the block that the OP_CHECKSIG occurs within.
More specifically, we will want a SigHash flag to enables/disable the
signature covering this counter.
There are many different ways one might go about replacing the remaining
useful behaviour of OP_CODESEPARATOR than the one I gave above. I would be
happy with any solution.
--000000000000c96a34057b2fc954
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Nov 19=
, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev <<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a=
>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So my question is whet=
her anyone can see ways in which this introduces<br>
redundant flexibility, or misses obvious use cases?<br></blockquote><div><b=
r></div><div>Hopefully my comment is on-topic for this thread:</div><div><b=
r></div><div>Given that we want to move away from OP_CODESEPARATOR, because=
each call to this operation effectively takes O(script-size) time, we need=
a replacement for the functionality it currently provides.=C2=A0 While per=
haps the original motivation for OP_CODESEPARTOR is surrounded in mystery, =
it currently can be used (or perhaps abused) for the task of creating signa=
ture that covers, not only which input is being signed, but which specific =
branch within that input Script code is being signed for.</div><div><br></d=
iv><div>For example, one can place an OP_CODESEPARATOR within each branch o=
f an IF block, or by placing an OP_CODESEPARATOR before each OP_CHECKSIG op=
eration.=C2=A0 By doing so, signatures created for one clause cannot be use=
d as signatures for another clause.=C2=A0 Since different clauses in Bitcoi=
n Script may be enforcing different conditions (such as different time-lock=
s, hash-locks, etc), it is useful to be able to sign in such a way that you=
r signature is only valid when the conditions for a particular branch are s=
atisfied.=C2=A0 In complex Scripts, it may not be practical or possible to =
use different public keys for every different clause. (In practice, you wil=
l be able to get away with fewer OP_CODESEPARATORS than one in every IF blo=
ck).<br></div><div><br></div><div>One suggestion I heard (I think I heard i=
t from Pieter) to achieve the above is to add an internal counter that incr=
ements on every control flow operator, OP_IF, OP_NOTIF, OP_ELSE, OP_ENDIF, =
and have the signature cover the value of this counter.=C2=A0 Equivalently =
we divide every Bitcoin Script program into blocks deliminated by these con=
trol flow operator and have the signature cover the index of the block that=
the OP_CHECKSIG occurs within.=C2=A0 More specifically, we will want a Sig=
Hash flag to enables/disable the signature covering this counter.<br></div>=
<div><br></div><div>There are many different ways one might go about replac=
ing the remaining useful behaviour of OP_CODESEPARATOR than the one I gave =
above. I would be happy with any solution.<br></div></div></div>
--000000000000c96a34057b2fc954--
|
