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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F8FEAD7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Mar 2019 02:23:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9FED2C4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Mar 2019 02:23:35 +0000 (UTC)
Received: from [30.91.248.69] (unknown [172.56.2.254])
by mail.bluematt.me (Postfix) with ESMTPSA id 7E7C01201F6;
Tue, 12 Mar 2019 02:23:34 +0000 (UTC)
Content-Type: multipart/alternative;
boundary=Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2
Mime-Version: 1.0 (1.0)
From: Matt Corallo <lf-lists@mattcorallo.com>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <CAMZUoKkJY6UpN=OmOsR0tDAwLw++dYrZtuo_Vir-+DHrK3ckNg@mail.gmail.com>
Date: Mon, 11 Mar 2019 22:23:33 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <FD3AE549-3DD4-48E0-9804-73BFBB30A9B0@mattcorallo.com>
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
<CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>
<6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
<D2014BB7-1EFC-4604-ACF6-3C5AC74B6FC0@sprovoost.nl>
<D631175F-0704-4820-BE3C-110E63F9E3FF@mattcorallo.com>
<PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
<CABLeJxS1sK8x-dgkOJ5f4=vjB4xja6EVeca-aHbeqOyS7SwWWQ@mail.gmail.com>
<CAMZUoKkJY6UpN=OmOsR0tDAwLw++dYrZtuo_Vir-+DHrK3ckNg@mail.gmail.com>
To: Russell O'Connor <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
MIME_QP_LONG_LINE 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: Tue, 12 Mar 2019 05:45:13 +0000
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
Consensus Cleanup
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: Tue, 12 Mar 2019 02:23:37 -0000
--Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
I think you may have misunderstood part of the motivation. Yes, part of the m=
otivation *is* to remove OP_CODESEPARATOR wholesale, greatly simplifying the=
theoretical operation of checksig operations (thus somewhat simplifying the=
implementation but also simplifying analysis of future changes, such as sig=
hash-caching code).
I think a key part of the analysis here is that no one I've spoken to (and w=
e've been discussing removing it for *years*, including many attempts at com=
ing up with reasons to keep it) is aware of any real proposals to use OP_COD=
ESEPARATOR, let alone anyone using it in the wild. Hiding data in invalid pu=
bic keys is a long-discussed-and-implemented idea (despite it's discourageme=
nt, not to mention it appears on the chain in many places).
It would end up being a huge shame to have all the OP_CORESEPARATOR mess lef=
t around after all the effort that has gone into removing it for the past fe=
w years, especially given the stark difference in visibility of a fork when c=
ompared to a standardness change.
As for your specific proposal of increasing the weight of anything that has a=
n OP_CODESEPARATOR in it by the cost of an additional (simple) input, this d=
oesn't really solve the issue. After all, if we're assuming some user exists=
who has been using sending money, unspent, to scripts with OP_CODESEPARATOR=
to force signatures to commit to whether some other signature was present a=
nd who won't see a (invariably media-covered) pending soft-fork in time to c=
laim their funds, we should also assume such a user has pre-signed transacti=
ons which are time-locked and claim a number of inputs and have several path=
s in the script which contain OP_CODESEPARATOR, rendering their transcriptio=
n invalid.
Matt
> On Mar 11, 2019, at 15:15, Russell O'Connor via bitcoin-dev <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
>=20
> Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size limi=
t) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few more (o=
verhead for varints) =3D 572ish bytes should be enough to completely elimina=
te any vulnerability caused by OP_CODESEPARATOR within P2SH transactions wit=
hout the need to remove it ever. I think it is worth attempting to be a bit=
more clever than such a blunt rule, but it would be much better than elimin=
ating OP_CODESEPARATOR within P2SH entirely.
>=20
> Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goa=
l is to eliminate the vulnerability associated with it.
>=20
>> On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org> wrote:
>> What about putting it in a deprecated state for some time. Adjust the tra=
nsaction weight so using the op code is more expensive (10x, 20x?) and get t=
he word out that it will be removed in the future.
>>=20
>> You could even have nodes send a reject code with the message =E2=80=9COP=
_CODESEPARATOR is depcrecated.=E2=80=9D
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">I t=
hink you may have misunderstood part of the motivation. Yes, part of the mot=
ivation *is* to remove OP_CODESEPARATOR wholesale, greatly simplifying the t=
heoretical operation of checksig operations (thus somewhat simplifying the i=
mplementation but also simplifying analysis of future changes, such as sigha=
sh-caching code).</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">I think a=
key part of the analysis here is that no one I've spoken to (and we've been=
discussing removing it for *years*, including many attempts at coming up wi=
th reasons to keep it) is aware of any real proposals to use OP_CODESEPARATO=
R, let alone anyone using it in the wild. Hiding data in invalid pubic keys i=
s a long-discussed-and-implemented idea (despite it's discouragement, not to=
mention it appears on the chain in many places).</div><div dir=3D"ltr"><br>=
</div><div dir=3D"ltr">It would end up being a huge shame to have all the OP=
_CORESEPARATOR mess left around after all the effort that has gone into remo=
ving it for the past few years, especially given the stark difference in vis=
ibility of a fork when compared to a standardness change.</div><div dir=3D"l=
tr"><br></div><div dir=3D"ltr">As for your specific proposal of increasing t=
he weight of anything that has an OP_CODESEPARATOR in it by the cost of an a=
dditional (simple) input, this doesn't really solve the issue. After all, if=
we're assuming some user exists who has been using sending money, unspent, t=
o scripts with OP_CODESEPARATOR to force signatures to commit to whether som=
e other signature was present and who won't see a (invariably media-covered)=
pending soft-fork in time to claim their funds, we should also assume such a=
user has pre-signed transactions which are time-locked and claim a number o=
f inputs and have several paths in the script which contain OP_CODESEPARATOR=
, rendering their transcription invalid.</div><div dir=3D"ltr"><br></div><di=
v dir=3D"ltr">Matt</div><div dir=3D"ltr"><br>On Mar 11, 2019, at 15:15, Russ=
ell O'Connor via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><br></=
div><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"=
ltr"><div>Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript s=
ize limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few=
more (overhead for varints) =3D 572ish bytes should be enough to completely=
eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH transact=
ions without the need to remove it ever. I think it is worth attemptin=
g to be a bit more clever than such a blunt rule, but it would be much bette=
r than eliminating OP_CODESEPARATOR within P2SH entirely.</div><div><br></di=
v><div>Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; th=
e goal is to eliminate the vulnerability associated with it.<br></div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon,=
Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.=
org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div><div dir=3D"auto">What about putting it in a deprecated state for some=
time. Adjust the transaction weight so using the op code is more expensive (=
10x, 20x?) and get the word out that it will be removed in the future.</div>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">You could even have node=
s send a reject code with the message =E2=80=9COP_CODESEPARATOR is depcrecat=
ed.=E2=80=9D</div>
</blockquote></div></div>
</div></blockquote><blockquote type=3D"cite"><div dir=3D"ltr"><span>________=
_______________________________________</span><br><span>bitcoin-dev mailing l=
ist</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href=3D"https:=
//lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquot=
e></body></html>=
--Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2--
|
