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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AEC278CC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Nov 2015 09:27:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com
[209.85.192.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E84A7108
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Nov 2015 09:27:24 +0000 (UTC)
Received: by qgeb1 with SMTP id b1so34171107qge.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 06 Nov 2015 01:27:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=O3cXoCrnaV/PJIvlVRlufDintYat1itZGg8pO0hzW/s=;
b=BJ+uHxrd5rMeKLYhFTnp8TF0ID9uKMSYZjknVLn7CiL2UX7TmkkA5yu8GCYNfbTTCT
FrHDUwQYp+3l9OIrw6isssN3JPxFOgIraEqsxCSVTJo0XE1Cjmm8vAbMnFs3Eo1m0JQI
up0ZNQkwdXblzl566ORPVCtVSyTdVzGs4OEQSK5Nm3yLYvOf63cCYcMZTO6qJjc4Xdxd
+5ovln4gXsNE0m2LpSwwbS6LD8LoZNWrnr72A1fLHEH3pBD3HgXiI4EhFwcoSDfPs/VG
uXIligk2sdkWbRXeZmzYKYeGwN70Vj2M05wVV0RTjTzW/3W5eHHfrpAY+Dx+bqGjFoG9
f5Ig==
MIME-Version: 1.0
X-Received: by 10.140.81.21 with SMTP id e21mr12179641qgd.69.1446802044109;
Fri, 06 Nov 2015 01:27:24 -0800 (PST)
Received: by 10.140.93.82 with HTTP; Fri, 6 Nov 2015 01:27:24 -0800 (PST)
In-Reply-To: <0e72b173ea8e8aaf6b1b678182fa1ea7@xbt.hk>
References: <0e72b173ea8e8aaf6b1b678182fa1ea7@xbt.hk>
Date: Fri, 6 Nov 2015 09:27:24 +0000
Message-ID: <CAE-z3OUQyW9Hss-jMDx_HjT9y55SctmUiXiGYhTZe6=2Mj2OaA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11c121b4e662120523dbd9c6
X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
MALFORMED_FREEMAIL,
MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Dealing with OP_IF and OP_NOTIF malleability
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 06 Nov 2015 09:27:25 -0000
--001a11c121b4e662120523dbd9c6
Content-Type: text/plain; charset=UTF-8
One and zero should be defined as arrays of length one. Otherwise, it is
still possible to mutate the transaction by changing the length of the
array.
They should also be minimally encoded but that is covered by previous rules.
On Fri, Nov 6, 2015 at 8:13 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I have a new BIP draft for fixing OP_IF and OP_NOTIF malleability. Please
> comment:
> https://github.com/jl2012/bips/blob/master/opifmalleability.mediawiki
>
> Copied below:
>
> BIP: x
> Title: Dealing with OP_IF and OP_NOTIF malleability
> Author: jl2012 <jl2012@xbt.hk>
> Status: Draft
> Type: Standards Track
> Created: 2015-11-06
>
> Abstract
>
> As an supplement to BIP62, this document specifies proposed changes to the
> Bitcoin transaction validity rules in order to make malleability of
> transactions with OP_IF and OP_NOTIF impossible.
>
> Motivation
>
> OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system.
> The programme flow is decided by whether the top stake value is 0 or not.
> However, this behavior opens a source of malleability as a third party may
> alter a non-zero flow control value to any other non-zero value without
> invalidating the transaction.
>
> As of November 2015, OP_IF and OP_NOTIF are not commonly used in the
> blockchain. However, as more sophisticated functions such as
> OP_CHECKLOCKTIMEVERITY are being introduced, OP_IF and OP_NOTIF will become
> more popular and the related malleability should be fixed. This proposal
> serves as a supplement to BIP62 and should be implemented with other
> malleability fixes together.
>
> Specification
>
> If the transaction version is 3 or above, the flow control value for OP_IF
> and OP_NOTIF must be either 0 or 1, or the transaction fails.
>
> This is to be implemented with BIP62.
>
> Compatibility
>
> This is a softfork. To ensure OP_IF and OP_NOTIF transactions created
> before the introduction of this BIP will still be accpeted by the network,
> the new rules only apply to transactions of version 3 or above.
>
> For people who want to preserve the original behaviour of OP_IF and
> OP_NOTIF, an OP_0NOTEQUAL could be used before the flow control code to
> transform any non-zero value to 1.
>
> Reference
>
> BIP62: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a11c121b4e662120523dbd9c6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">One and zero should be defined as arrays of length one.=C2=
=A0 Otherwise, it is still possible to mutate the transaction by changing t=
he length of the array. <br><br>They should also be minimally encoded but t=
hat is covered by previous rules.<br></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Fri, Nov 6, 2015 at 8:13 AM, jl2012 via bitcoi=
n-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">I have a new BIP draft for f=
ixing OP_IF and OP_NOTIF malleability. Please comment: <a href=3D"https://g=
ithub.com/jl2012/bips/blob/master/opifmalleability.mediawiki" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/jl2012/bips/blob/master/opifmall=
eability.mediawiki</a><br>
<br>
Copied below:<br>
<br>
BIP: x<br>
=C2=A0 Title: Dealing with OP_IF and OP_NOTIF malleability<br>
=C2=A0 Author: jl2012 <<a href=3D"mailto:jl2012@xbt.hk" target=3D"_blank=
">jl2012@xbt.hk</a>><br>
=C2=A0 Status: Draft<br>
=C2=A0 Type: Standards Track<br>
=C2=A0 Created: 2015-11-06<br>
<br>
Abstract<br>
<br>
As an supplement to BIP62, this document specifies proposed changes to the =
Bitcoin transaction validity rules in order to make malleability of transac=
tions with OP_IF and OP_NOTIF impossible.<br>
<br>
Motivation<br>
<br>
OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system. The=
programme flow is decided by whether the top stake value is 0 or not. Howe=
ver, this behavior opens a source of malleability as a third party may alte=
r a non-zero flow control value to any other non-zero value without invalid=
ating the transaction.<br>
<br>
As of November 2015, OP_IF and OP_NOTIF are not commonly used in the blockc=
hain. However, as more sophisticated functions such as OP_CHECKLOCKTIMEVERI=
TY are being introduced, OP_IF and OP_NOTIF will become more popular and th=
e related malleability should be fixed. This proposal serves as a supplemen=
t to BIP62 and should be implemented with other malleability fixes together=
.<br>
<br>
Specification<br>
<br>
If the transaction version is 3 or above, the flow control value for OP_IF =
and OP_NOTIF must be either 0 or 1, or the transaction fails.<br>
<br>
This is to be implemented with BIP62.<br>
<br>
Compatibility<br>
<br>
This is a softfork. To ensure OP_IF and OP_NOTIF transactions created befor=
e the introduction of this BIP will still be accpeted by the network, the n=
ew rules only apply to transactions of version 3 or above.<br>
<br>
For people who want to preserve the original behaviour of OP_IF and OP_NOTI=
F, an OP_0NOTEQUAL could be=C2=A0 used before the flow control code to tran=
sform any non-zero value to 1.<br>
<br>
Reference<br>
<br>
BIP62: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0062.medi=
awiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bips=
/blob/master/bip-0062.mediawiki</a><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>
--001a11c121b4e662120523dbd9c6--
|
