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
|
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 464CE919
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Aug 2016 20:52:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com
[209.85.220.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 99A09146
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Aug 2016 20:52:28 +0000 (UTC)
Received: by mail-qk0-f177.google.com with SMTP id z190so27681844qkc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Aug 2016 13:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to;
bh=3aEtvbU0slo5ImEiL2BCYv5e7Gmcwps4we4mcaUY76o=;
b=Q8HpxJtS10wiyp5OT+Oj8YHdo7ycQbMTqhJOcnRryB9BakOPbWR79cLY7frF4pB1AQ
4Mui6lcYZnjvdHwEtpZVb31MQA51+i62y8jk40+LBtrpj3a/xkOdJzhVspozikLLjq24
ogX/c5tpT1UF0udf76oytvO2914mUPe8ZnUuZ8zcMmA6D2xBMwRshxzZjeV0fRALs1Sh
ThjwNt2QmqrAsZtbNpFd+tNlDE9qrnx1HQx21z7fHtPQBTiphvvGNDpqFZUQxplIYpZo
FUhyhjDZ5JHiIRd9NJoykhYuhW8LyNcfioaeB52LE8ELn1KaCnyTq0MFC2+uRAUMGs04
LdcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=3aEtvbU0slo5ImEiL2BCYv5e7Gmcwps4we4mcaUY76o=;
b=OXVcjXmynCdv/Wubse/I5DutJNWGDQ8XHSkvikrOHx8FsWz2wGdJPiD0fX/9AuvYI5
DSzQz8/AzBX+b5A3V9HOkvIQDezjwZmb7jw7x0bvb5JxGcEwScqZSI0kbdgv3Tl7zRUP
Uh31q6VfAJvW+rnhlH9EH0Qi3lF51HBQukYsDPH7l+W8xSPD+au1muGLR8KbBVm0Ddmk
jw8A6EsqbpQJK+bA/JCJ9DfpsaO83kw0B/kAenBmeHlYmlZfmlQLO0pKxJBbxsV/2V5b
0tZ49iU+LI2djvNXDbhIDQZcQWFOmpPtXxcL1ozQ60K2XM7zugD+wI0+wAvCeRBoCYWM
zM6w==
X-Gm-Message-State: AE9vXwO05GUZBOwXdaufat0DDHkGwdL3TmXo2pKDGw3fN9JPNEW1rHr2drPSLqKAdzdPSyIsWffymZ0F6tUL6w==
X-Received: by 10.55.111.135 with SMTP id k129mr6225754qkc.51.1472071947739;
Wed, 24 Aug 2016 13:52:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.46.221 with HTTP; Wed, 24 Aug 2016 13:51:47 -0700 (PDT)
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Wed, 24 Aug 2016 17:51:47 -0300
Message-ID: <CAKzdR-q4hagujzWxJxmwpxJUQFLe7SKukbDNs=_S_VKgJ9N_TA@mail.gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c05dcec8780b6053ad7751e
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: [bitcoin-dev] Attack by modifying non-segwit transactions after
segwit is accepted ?
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: Wed, 24 Aug 2016 20:52:29 -0000
--94eb2c05dcec8780b6053ad7751e
Content-Type: text/plain; charset=UTF-8
In a previous thread ("New BIP: Dealing with OP_IF and OP_NOTIF
malleability in P2WSH") it was briefly discussed what happens if someone
modifies segwit data during transmission. I think the discussion should
continue.
What worries me is what happens with non-segwit transactions after segwit
is activated. I've followed the code from transaction arrival to
transaction relay and it seems that a malicious node could receive a
non-segwit tx, and re-format it into a segwit tx having as high as 400
Kbytes of segwit witness program data, and then relay it. Both transaction
would have the same hash.
The MAX_SCRIPT_ELEMENT_SIZE limit is only enforced on segwit execution, not
in old non-segwit execution, so witness program stack elements could be as
large as 400 Kbytes (MAX_STANDARD_TX_WEIGHT prevents increasing more).
Such large modified transaction will probably not be properly relayed by
the network due too low fee/byte, so the honest miner will probably win and
forward the original transaction through the network.
But if the attacker has better connectivity with the network and he
modifies the original transaction adding segwit witness program data only
up to the point where the transaction is relayed but miners are discouraged
to include it in blocks due to low fees/byte, then the attacker has
successfully prevented a transaction from being mined (or at least it will
take much more).
Also an attacker can encode arbitrary data (such as virus signatures or
illegal content) into passing non-segwit transactions.
One solution would be to increase the transaction version to 3 for segwit
transactions, so a non-segwit transaction cannot be converted into a segwit
transaction without changing the transaction hash. But this seems not to be
a good solution, because it does not solve all the problems. Transactions
having a mixture of segwit and non-segwit inputs could suffer the same
attack (even if they are version 3).
I proposed that a rule is added to IsStandardTX() that prevents witness
programs of having a stack elements of length greater than
MAX_SCRIPT_ELEMENT_SIZE. (currently this is not a rule)
That's a simple check that prevents most of the problems.
A long term solution would be to add the maximum size of the witness stack
in bytes (maxWitnessSize) as a field for each input, or as a field of the
whole transaction.
Regards
--94eb2c05dcec8780b6053ad7751e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>In a previous thread ("New BIP: D=
ealing with OP_IF and OP_NOTIF malleability in P2WSH") it was briefly =
discussed what happens if someone modifies segwit data during transmission.=
I think the discussion should continue.<br><br></div>What worries me is wh=
at happens with non-segwit transactions after segwit is activated. I've=
followed the code from transaction arrival to transaction relay and it see=
ms that a malicious node could receive a non-segwit tx, and re-format it in=
to a segwit tx having as high as 400 Kbytes of segwit witness program data,=
and then relay it. Both transaction would have the same hash.<br><br>The M=
AX_SCRIPT_ELEMENT_SIZE limit is only enforced on segwit execution, not in o=
ld non-segwit execution, so witness program stack elements could be as larg=
e as 400 Kbytes (MAX_STANDARD_TX_WEIGHT prevents increasing more).<br>Such =
large modified transaction will probably not be properly relayed by the net=
work due too low fee/byte, so the honest miner will probably win and forwar=
d the original transaction through the network. <br>But if the attacker has=
better connectivity with the network and he modifies the original transact=
ion adding segwit witness program data only up to the point where the trans=
action is relayed but miners are discouraged to include it in blocks due to=
low fees/byte, then the attacker has successfully prevented a transaction =
from being mined (or at least it will take much more).<br><div><br></div><d=
iv>Also an attacker can encode arbitrary data (such as virus signatures or =
illegal content) into passing non-segwit transactions.<br></div><br></div>O=
ne solution would be to increase the transaction version to 3 for segwit tr=
ansactions, so a non-segwit transaction cannot be converted into a segwit t=
ransaction without changing the transaction hash. But this seems not to be =
a good solution, because it does not solve all the problems. Transactions h=
aving a mixture of segwit and non-segwit inputs could suffer the same attac=
k (even if they are version 3). <br></div><br></div><div>I proposed that a =
rule is added to IsStandardTX() that prevents witness programs of having a =
stack elements of length greater than MAX_SCRIPT_ELEMENT_SIZE. (currently t=
his is not a rule)<br></div><div><br>That's a simple check that prevent=
s most of the problems.<br><br>A long term solution would be to add the max=
imum size of the witness stack in bytes (maxWitnessSize) as a field for eac=
h input, or as a field of the whole transaction.<br></div><div><div><br><di=
v>Regards</div></div></div></div>
--94eb2c05dcec8780b6053ad7751e--
|
