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
|
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 BBC6C72A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Nov 2018 20:18:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f173.google.com (mail-it1-f173.google.com
[209.85.166.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 358DA771
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Nov 2018 20:18:26 +0000 (UTC)
Received: by mail-it1-f173.google.com with SMTP id h193so19426308ita.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Nov 2018 12:18:26 -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
:cc; bh=V7THAYn57NiXWs2RW0WjSSx5NlWO4Aa6rc0G0WPJMRE=;
b=O6Pr8qFGrQp6UmFxH2HUu40SmM6iJgsW65av8AqPymI9CxEg9ijFw4Dbwh+xqG/k+/
6BFCZadHp6Cnt/I8oxX2wQRyR7NBPOEQ52a6AN51lRRXPtuHQqPwo5Kzz0CiSwW4h5aD
3uiFUOfbv/xTrmwbl0kM4EPyVANJaikw03LaY=
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=V7THAYn57NiXWs2RW0WjSSx5NlWO4Aa6rc0G0WPJMRE=;
b=qJ2TI254bePjadmf22At9bCjFGCZVJYjask6vByPoHEqvGUPIsqDxsqhqgqQLLZw7L
X/FDpDJtya9Hkvc4z4LQSMygrv2OPDm2Vv7vLEBU7ZGJ8byD4OQrBxvgXF3d8Qyp88+K
aV5lymRkA+Cy4TGwCOnrf8RpMQXjBfEFkgTv5+ECiTGrK3fmpfhCo4Kyl7BZ7/TOW5bW
agRlQKrY72FZRP0ZO2HFUx3WrP7tMa6PfwjQjbVck6u5qyG82OjCulu2i9HMBDyZNBQj
GtVmc+1CelD21YLTuPydYRf9ULAbhYshtY0sJ//poMLgfFwOyA9pjM7Er49iUqZFWNLg
dNGA==
X-Gm-Message-State: AGRZ1gLa0GkTMvkzFcNB50edv3C2afCzhkZ8ftiGMHI0pYGLj4kDZH57
cRjQcMSWc/kWv32+WlrxuC7ydRhaO8DHmKSsf5Ude5ch1HY=
X-Google-Smtp-Source: AJdET5fwEkeA3VlwuJbVLlzinE3L/vVUhrij58vnXzSmiQGB3/1QrKPnkXmGOOrhjmrOOCTN4jqVpTXO5rXo8Pekikg=
X-Received: by 2002:a02:98bb:: with SMTP id q56mr14612443jaj.24.1543004305413;
Fri, 23 Nov 2018 12:18:25 -0800 (PST)
MIME-Version: 1.0
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
<CAMZUoK==Bdn73Lc=swgf2F5_mqE84TR1GRBFhrFkn7kab4jBaw@mail.gmail.com>
<20181123050330.x4xrgouit7apwk45@erisian.com.au>
In-Reply-To: <20181123050330.x4xrgouit7apwk45@erisian.com.au>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Fri, 23 Nov 2018 15:18:13 -0500
Message-ID: <CAMZUoK=SC3+d73SNfu7rAdwE4tcJK6jmg9-UHDJVN53ZU_HqMw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="00000000000082ffc5057b5aafe0"
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: Sat, 24 Nov 2018 02:17:49 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 23 Nov 2018 20:18:26 -0000
--00000000000082ffc5057b5aafe0
Content-Type: text/plain; charset="UTF-8"
On Fri, Nov 23, 2018 at 12:03 AM Anthony Towns <aj@erisian.com.au> wrote:
> On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev
> wrote:
> > 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.
>
> Would it be sufficient to sign the position within the script of the
> last OP_CODESEPARATOR? That is, if your script is:
>
> I think that covers all the behaviour you can currently achieve with
> CODESEP (which is pretty limited since every sig effectively commits
> to the full redeem script, and you can't commit to subsets of the
> signature/witness), and it keeps the things you can do with the various
> features a bit orthogonal:
>
Thanks for bringing this up. I was thinking the same thing as well, that
yes that should be sufficient to cover the semantics of OP_CODESEPARATOR.
Though to be more precise you would sign the position of the last
_executed_ OP_CODESEPARATOR.
That said, while I agree the above is a superior realization of the
OP_CODESEPARATOR, given that we are probably going to support
OP_CODESEPARATOR inside legacy P2SH scripts indefinitely, it is probably
better to keep the existing akward implementation of OP_CODESEPARATOR in
future versions of Script. (At least until we decide to stop mangling the
Script consensus code with more and more flag combinations and decide it is
better to cut and paste code for new versions of Script to help ensure we
don't make consensus changes to legacy behaviour).
> [0] (I think I'm going to claim "MAST" stands for "merkelized alternative
> script tree" these days, since they're not "abstract syntax trees")
>
:thumbs-up:
Sorry for hijacking the thread about OP_MASK and friends.
--00000000000082ffc5057b5aafe0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, N=
ov 23, 2018 at 12:03 AM Anthony Towns <<a href=3D"mailto:aj@erisian.com.=
au">aj@erisian.com.au</a>> wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoi=
n-dev wrote:<br>
> Given that we want to move away from OP_CODESEPARATOR, because each ca=
ll to<br>
> this operation effectively takes O(script-size) time, we need a replac=
ement for<br>
> the functionality it currently provides.=C2=A0 While perhaps the origi=
nal motivation<br>
> for OP_CODESEPARTOR is surrounded in mystery, it currently can be used=
(or<br>
> perhaps abused) for the task of creating signature that covers, not on=
ly which<br>
> input is being signed, but which specific branch within that input Scr=
ipt code<br>
> is being signed for.<br>
<br>
Would it be sufficient to sign the position within the script of the<br>
last OP_CODESEPARATOR? That is, if your script is:<br>
<br>
I think that covers all the behaviour you can currently achieve with<br>
CODESEP (which is pretty limited since every sig effectively commits<br>
to the full redeem script, and you can't commit to subsets of the<br>
signature/witness), and it keeps the things you can do with the various<br>
features a bit orthogonal:<br></blockquote><div><br></div><div>Thanks for b=
ringing this up.=C2=A0 I was thinking the same thing as well, that yes that=
should be sufficient to cover the semantics of OP_CODESEPARATOR.=C2=A0 Tho=
ugh to be more precise you would sign the position of the last _executed_ O=
P_CODESEPARATOR.</div><div><br></div><div>That said, while I agree the abov=
e is a superior realization of the OP_CODESEPARATOR, given that we are prob=
ably going to support OP_CODESEPARATOR inside legacy P2SH scripts indefinit=
ely, it is probably better to keep the existing akward implementation of OP=
_CODESEPARATOR in future versions of Script.=C2=A0 (At least until we decid=
e to stop mangling the Script consensus code with more and more flag combin=
ations and decide it is better to cut and paste code for new versions of Sc=
ript to help ensure we don't make consensus changes to legacy behaviour=
).<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[0] (I think I&=
#39;m going to claim "MAST" stands for "merkelized alternati=
ve<br>
=C2=A0 =C2=A0 =C2=A0script tree" these days, since they're not &qu=
ot;abstract syntax trees")<br></blockquote><div><br></div><div>:thumbs=
-up: <br></div><div><br></div><div>Sorry for hijacking the thread about OP_=
MASK and friends.<br></div></div></div></div>
--00000000000082ffc5057b5aafe0--
|
