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
|
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 63241D88
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Dec 2018 16:50:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f174.google.com (mail-it1-f174.google.com
[209.85.166.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B01167C3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Dec 2018 16:50:22 +0000 (UTC)
Received: by mail-it1-f174.google.com with SMTP id z7so4686553iti.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Dec 2018 08:50:22 -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=RfteMk0A/UunasAhYOHs8jaSRXoCziux4JUSr3j5uQE=;
b=YmFH5NJXC35THoQx6D7AI8AhYvmdlguWV8R/z8ZI0A7G0b7FDPD1EeweZj/aKxnJ6b
KslSbL5FWxL1uFkjEPoiuDMYiviiChkcsCA3owGCDtdSDcbfF+jjkQ5Ci6RAUsoveLqb
YUdk/xknhecg6E893nPcU5WYeJLXa11iIDxPU=
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=RfteMk0A/UunasAhYOHs8jaSRXoCziux4JUSr3j5uQE=;
b=GkerDtQE00YF7KfQ0t+1s6MP9x93AUGRV1+f+eCt4OfCt8yfy7QCtFHzaBnK56km8m
gPxrjcoJCwO/Cmqeey+qXiZBmoRBv1HOxitVkc2rfo2LiXLFtu5HvVPi7Jumcn7alPD5
6hSwizVQs/RWSrrBsHpLy1bDbgW79MIkoq4MpH2yFyI4QzMYXIpM2NKezjSe5xb5jY+T
4eRKWQ6DpyidemwgGtoO63+eylHFavL3EjuGk5vxpOpVVmRR+KtNKo5hhzVfrVXv0p3v
GL0J52SIz23Jq9CcRcu0v2jRUSsMl/+IPrWefVRYyUamtL4dm0Dd14DHAw1uJnWVYNHI
R0qg==
X-Gm-Message-State: AA+aEWZGsH/J3x/TMLJAshgCQo0YMisbsKJnqS+2YtMwDvTkLs2nuvW9
bW/JsHxwo4cxt5Bn3KGeG0p+1Xcl+uNaZdhuN7ZX4Q==
X-Google-Smtp-Source: AFSGD/VGAfY2YEKDsDVTWKw60VB+MN5lqyROg4bp29PpfOxGyFZKJZCChsGPV4jklrtrBJ+6z47K+Xe1Jk/8lc0WQSc=
X-Received: by 2002:a02:3da:: with SMTP id e87mr21903345jae.78.1544719821795;
Thu, 13 Dec 2018 08:50:21 -0800 (PST)
MIME-Version: 1.0
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
<CAPg+sBiu0BjZEtz-t7m3M+TnAEDG_k1GKtxwkOKh6qrSezUO7g@mail.gmail.com>
<CAMZUoKkJdU0P_dVRvHn5zY6xUHYUptdK221ioQMp3FXZAerp3Q@mail.gmail.com>
<702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk>
<CAMZUoKkYcXt7O39zdpz494f9Jm195mBtWyrH3siX4PBEAf8OKQ@mail.gmail.com>
<864604F8-0BAF-403B-9A61-4788930F065F@xbt.hk>
In-Reply-To: <864604F8-0BAF-403B-9A61-4788930F065F@xbt.hk>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Thu, 13 Dec 2018 11:50:10 -0500
Message-ID: <CAMZUoKkXJCWxm4_bGLrXzBPzVjxCanU9-0uLw8tXBu+QaYE5hw@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary="000000000000418a23057cea1ce0"
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, 13 Dec 2018 22:09:29 +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: Thu, 13 Dec 2018 16:50:23 -0000
--000000000000418a23057cea1ce0
Content-Type: text/plain; charset="UTF-8"
On Wed, Dec 12, 2018 at 2:53 PM Johnson Lau <jl2012@xbt.hk> wrote:
>
> I think the root cause of witness weight malleability is some opcodes
> accept variable size input (without affecting the output), and that input
> is provided by the puzzle solver. Going through the opcode list, I think
> such opcodes include IF, NOTIF, VERIFY, DROP, 2DROP, NIP, DEPTH, and all
> arithmetic opcode that accepts CScriptNum (including CHECKMULTISIG)
>
> VERIFY, DROP, 2DROP, NIP are not real problem, since they should not be
> the first opcode to interact with data directly provided by the puzzle
> solver.
>
> CHECKMULTISIG is fixed by BIP147. For the key number and sig number, they
> should be part of the script, so not malleable.
>
> DEPTH is a problem only if its inputs are not later examined by other
> opcodes. Again, this is pointless.
>
> The liberally example should be protected by the MINIMAL_IF policy, which
> requires the input of OP_IF be minimal. As you note, OP_IF could be
> replaced by taproot in many cases
>
> Non-minimal CScriptNum is also banned as BIP62 policy.
>
> For the purpose of preventing malicious third party witness bloating, all
> we need is the miners to enforce the policy. There is no reason for miners
> to accept size malleated txs, as that will reduce the usable block space.
> If they hate a tx, they would simply drop it, instead of wasting the block
> space.
>
I don't know if it such a clear cut case for miner's policy. A miner is
passed a malleated tx. They know that there is probably a non-malleated
variant floating around out there somewhere, and they would rather have
it. But right now they don't, and they probably not going to try to
unmalleate it themselves. So, why not stick it into their mempool? If it
eventually makes it into one of their blocks, then it will because it has
the best fee rate available, and to reject it outright is harmful to their
bottom line. If they find the non-malleated variant later, great, they can
replace it and gain a higher-fee rate tx. Of course, such a policy opens
them up to a Denial of Service attack.
So what do they do? Do they accept malleated tx's and implement an RBF
policy that requires sufficient fee rate increases? Do they reject
malleated txs outright to avoid falling in this trap in the first place as
you suggest? I don't know, but I don't think things are as clear cut as
you present.
That aside, your list of weight malleable opcodes is shorter than I
imagined and I'm grateful you've compiled it. Perhaps the best solution is
to make MINIMAL_IF and minimal CScriptNum consensus enforced in the next
version of Script and all but eliminate weight malleability in practice?
--000000000000418a23057cea1ce0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, Dec 12, 2018 at 2:53 PM Johnson Lau <<a href=3D"mailto:jl2012@xbt.hk">=
jl2012@xbt.hk</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div s=
tyle=3D"word-wrap:break-word;line-break:after-white-space"><br><div>I think=
the root cause of witness weight malleability is some opcodes accept varia=
ble size input (without affecting the output), and that input is provided b=
y the puzzle solver. Going through the opcode list, I think such opcodes in=
clude IF, NOTIF, VERIFY, DROP, 2DROP, NIP, DEPTH, and all arithmetic opcode=
that accepts CScriptNum (including CHECKMULTISIG)</div><div><br></div><div=
>VERIFY, DROP, 2DROP, NIP are not real problem, since they should not be th=
e first opcode to interact with data directly provided by the puzzle solver=
.</div><div><br></div><div>CHECKMULTISIG is fixed by BIP147. For the key nu=
mber and sig number, they should be part of the script, so not malleable.</=
div><div><br></div><div>DEPTH is a problem only if its inputs are not later=
examined by other opcodes. Again, this is pointless.</div><div><br></div><=
div>The liberally example should be protected by the MINIMAL_IF policy, whi=
ch requires the input of OP_IF be minimal. As you note, OP_IF could be repl=
aced by taproot in many cases</div><div><br></div><div>Non-minimal CScriptN=
um is also banned as BIP62 policy.</div><div><br></div><div>For the purpose=
of preventing malicious third party witness bloating, all we need is the m=
iners to enforce the policy. There is no reason for miners to accept size m=
alleated txs, as that will reduce the usable block space. If they hate a tx=
, they would simply drop it, instead of wasting the block space.</div></div=
></blockquote><div><br></div><div>I don't know if it such a clear cut c=
ase for miner's policy.=C2=A0 A miner is passed a malleated tx.=C2=A0 T=
hey know that there is probably a non-malleated variant floating around out=
there somewhere, and they would rather have it.=C2=A0 But right now they d=
on't, and they probably not going to try to unmalleate it themselves.=
=C2=A0 So, why not stick it into their mempool?=C2=A0 If it eventually make=
s it into one of their blocks, then it will because it has the best fee rat=
e available, and to reject it outright is harmful to their bottom line.=C2=
=A0 If they find the non-malleated variant later, great, they can replace i=
t and gain a higher-fee rate tx.=C2=A0 Of course, such a policy opens them =
up to a Denial of Service attack.</div><div><br></div><div>So what do they =
do?=C2=A0 Do they accept malleated tx's and implement an RBF policy tha=
t requires sufficient fee rate increases?=C2=A0 Do they reject malleated tx=
s outright to avoid falling in this trap in the first place as you suggest?=
=C2=A0 I don't know, but I don't think things are as clear cut as y=
ou present.</div><div><br></div><div><br></div><div>That aside, your list o=
f weight malleable opcodes is shorter than I imagined and I'm grateful =
you've compiled it.=C2=A0 Perhaps the best solution is to make MINIMAL_=
IF and minimal CScriptNum consensus enforced in the next version of Script =
and all but eliminate weight malleability in practice?<br></div></div></div=
>
--000000000000418a23057cea1ce0--
|
