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
|
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9320E83D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Aug 2016 00:11:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com
[209.85.220.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B72E61F1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Aug 2016 00:11:57 +0000 (UTC)
Received: by mail-qk0-f180.google.com with SMTP id v123so3090289qkh.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Aug 2016 17:11:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=gBIpv3Hu0WmTsezeXmvsrnZ9cuLrvGwosAkRJR1uhMY=;
b=nDvbHy9NVkxLw3zJxy9cLrurAGkYFWQccbtDqMmqSQp/MpOgE9jn2bW37+TsW2aka7
5TcxKhkgY5KL6w3Jj//wqpTQ6DJlvD5gOQJcboydk9HMDnSTsx2OCDG0ISMGuNmWT5i+
TLaIaeAP7oiLDxka3IqOhFS4f1vpTKbW90kzabvnLm0QUZWZlAlkbLkXM/7mWXQviXRq
dGBbwkuQYpNL8kVAbsb0fmINV/jf75+jpxi977mSprSTKn1jbO5eri9UhB7J37v2N2DY
VbX55EolynSQriVxvMO6W99MYf4mM7vetV//qF4xRtJrf+4jy9VkuDW+p2zoiuGPFS/D
QT/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=gBIpv3Hu0WmTsezeXmvsrnZ9cuLrvGwosAkRJR1uhMY=;
b=eC+9OB30XWVG7dLS0zp8/U0YyWntgG3Y7X7qSvgSHymyeZBvdI9YiDe2ICotfRipN7
kdTdw3Xdd/i4efUCrJutvo8/QWJ8K9x2pJIIYsUm+CssSlL0gf1HBNn1pK4ycUIskstL
lLQKmWInXiVqU7gnYhhbI6xdQCouM6ls0RrL37T3L74hjS/0pIXIlXjf97DumdfscImf
lpevqRz0lJv36H5WaE0cNJXa5nBW5APe3N3d+2Pa2RNa26Syx1ihy3OZBLNSu+YF2Fv0
NRoJazvhCas6fP6tE4jxs9cnVgkvnDr91ahwRvpsiM2PFLBPcUFcc9vUYt+KFjbgV1so
x9Bw==
X-Gm-Message-State: AEkoousTtO6sjbdrn/n5XY1tUn2BZolLGl/ad12946uusP/gbkW51u6O5wsHm7Zwap26odjrLqAnt1KXFaa1LA==
X-Received: by 10.55.130.130 with SMTP id e124mr27147938qkd.51.1471479116970;
Wed, 17 Aug 2016 17:11:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.46.221 with HTTP; Wed, 17 Aug 2016 17:11:16 -0700 (PDT)
In-Reply-To: <703193091.96057.1471428948569@privateemail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
<976728541.94211.1471402973613@privateemail.com>
<201608170440.35767.luke@dashjr.org>
<703193091.96057.1471428948569@privateemail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Wed, 17 Aug 2016 21:11:16 -0300
Message-ID: <CAKzdR-qmL0Em058ama8CyAONrY2TbCSU7_SbfKoDEy0ZwnsFBA@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c06e1800fbe42053a4d6e61
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
malleability in P2WSH
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, 18 Aug 2016 00:11:58 -0000
--94eb2c06e1800fbe42053a4d6e61
Content-Type: text/plain; charset=UTF-8
I think that we're not attacking the real source of the problem: that the
witness data size is not signed. It may be the case that a new source of
malleability is detected in witness programs later, or related to new
opcodes we'll soft-fork in the future.
The problem is real, as some systems (such as hardware wallets or other
low-memory IoT embedded systems) may have hard limits in the size of the
witness program they can accept. So we need a solution for all current and
future segwit extension problems.
We could soft-fork to add an opcode OP_PROGSIZE using segwit script
versioning that pushes in the stack the size of the segwit program being
evaluated, and then the script can take any action it wishes based on that.
Example:
<0x50> OP_PROGSIZE OP_GREATERTHAN OP_VERIFY ..... OP_CHECKSIG
Then an attacker cannot create a clone of the transaction having a witness
ECDSA signature longer than 0x50 bytes. (many details omitted in this
example)
On Wed, Aug 17, 2016 at 7:15 AM, Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > On August 17, 2016 at 12:40 AM Luke Dashjr <luke@dashjr.org> wrote:
> >
> >
> > On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev
> wrote:
> > > To completely replicate the original behaviour, one may use:
> > > "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if
> script}
> > > ELSE DROP {else script} ENDIF"
> >
> > This is much uglier than expected. IMO if that's the best workaround for
> the
> > current behaviour, people should just use "OP_1 OP_EQUAL OP_IF" when/if
> they
> > need to avoid malleability issues.
>
> It is ugly only if you want to faithfully replicate the behaviour. I'd
> argue that in no real use case you need to do this. For example, "OP_SIZE
> OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF", since OP_SIZE must
> return a valid MINIMALDATA number.
>
> And your workaround does not fix malleability, since any non-0x01 values
> are valid FALSE
>
> However, in some case, enforcing MINIMALIF does require 1 more witness
> byte: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/
> 013036.html
>
> I think the best strategy is to make it a relay policy first, and decide
> whether we want a softfork later.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--94eb2c06e1800fbe42053a4d6e61
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I think that we're not attacking the real so=
urce of the problem: that the witness data size is not signed. It may be th=
e case that a new source of malleability is detected in witness programs la=
ter, or related to new opcodes we'll soft-fork in the future.<br><br></=
div><div>The problem is real, as some systems (such as hardware wallets or =
other low-memory IoT embedded systems) may have hard limits in the size of =
the witness program they can accept. So we need a solution for all current =
and future segwit extension problems.<br><br>We could soft-fork to add an o=
pcode OP_PROGSIZE using segwit script versioning that pushes in the stack t=
he size of the segwit program being evaluated, and then the script can take=
any action it wishes based on that. <br><br>Example:<br><0x50> OP_PR=
OGSIZE OP_GREATERTHAN OP_VERIFY ..... OP_CHECKSIG<br></div></div><br>Then a=
n attacker cannot create a clone of the transaction having a witness ECDSA =
signature longer than 0x50 bytes. (many details omitted in this example)<br=
><br><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Wed, Aug 17, 2016 at 7:15 AM, Johnson Lau via bitcoin-dev <span=
dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><u></u>
=20
<div><span class=3D""><p><br></p><p>> On August 17, 2016 at 12:40 AM Luk=
e Dashjr <<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dash=
jr.org</a>> wrote:<br>> <br>> <br>> On Wednesday, August 17, 20=
16 3:02:53 AM Johnson Lau via bitcoin-dev wrote:<br>> > To completely=
replicate the original behaviour, one may use:<br>> > "DEPTH TO=
ALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script}<br>> =
> ELSE DROP {else script} ENDIF"<br>> <br>> This is much ugli=
er than expected. IMO if that's the best workaround for the <br>> cu=
rrent behaviour, people should just use "OP_1 OP_EQUAL OP_IF" whe=
n/if they <br>> need to avoid malleability issues.</p></span><p>It is ug=
ly only if you want to faithfully replicate the behaviour. I'd argue th=
at in no real use case you need to do this. For example, "OP_SIZE OP_I=
F" could just become "OP_SIZE OP_0NOTEQUAL OP_IF", since OP_=
SIZE must return a valid MINIMALDATA number.</p><p>And your workaround does=
not fix malleability, since any non-0x01 values are valid FALSE</p><p>Howe=
ver, in some case, enforcing MINIMALIF does require 1 more witness byte:=C2=
=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-=
August/013036.html" target=3D"_blank">https://lists.<wbr>linuxfoundation.or=
g/pipermail/<wbr>bitcoin-dev/2016-August/<wbr>013036.html</a></p><p>I think=
the best strategy is to make it a relay policy first, and decide whether w=
e want a softfork later.</p></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--94eb2c06e1800fbe42053a4d6e61--
|
