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
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E64BF95D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Jan 2017 07:15:09 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender163-mail.zoho.com (sender163-mail.zoho.com
[74.201.84.163])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 90832D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Jan 2017 07:15:07 +0000 (UTC)
Received: from [10.7.56.158] (ip-123-255-103-183.wlan.cuhk.edu.hk
[123.255.103.183]) by mx.zohomail.com
with SMTPS id 148541489689657.51783491382582;
Wed, 25 Jan 2017 23:14:56 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <CAAcC9ys4dH3hFzXJon7ho_TP3YwOd=SB2DB0oW5-NnNY5Q19Cw@mail.gmail.com>
Date: Thu, 26 Jan 2017 15:14:52 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <CEA70782-BE59-486E-BD79-0446A73DEDC3@xbt.hk>
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
<93ac7433-470c-d59e-e085-29f0f1613676@mattcorallo.com>
<CAAcC9ys4dH3hFzXJon7ho_TP3YwOd=SB2DB0oW5-NnNY5Q19Cw@mail.gmail.com>
To: Chris Priest <cp368202@ohiou.edu>
X-Mailer: Apple Mail (2.3259)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork
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, 26 Jan 2017 07:15:10 -0000
I don=E2=80=99t think this is how the blockchain consensus works. If =
there is a split, it becomes 2 incompatible ledgers. Bitcoin is not a =
trademark, and you don=E2=80=99t need a permission to hardfork it. And =
what you suggest is also technically infeasible, as the miners on the =
new chain may not have a consensus only what=E2=80=99s happening in the =
old chain.
> On 26 Jan 2017, at 15:03, Chris Priest <cp368202@ohiou.edu> wrote:
>=20
> I don't think the solution should be to "fix the replay attack", but
> rather to "force the replay effect". The fact that transactions can be
> relayed should be seen as a good thing, and not something that should
> be fixed, or even called an "attack".
>=20
> The solution should be to create a "bridge" that replays all
> transactions from one network over to the other, and vice-versa. A
> fork should be transparent to the end-user. Forcing the user to choose
> which network to use is bad, because 99% of people that use bitcoin
> don't care about developer drama, and will only be confused by the
> choice. When a user moves coins mined before the fork date, both
> blockchains should record that transaction. Also a rule should be
> introduced that prevents users "tainting" their prefork-mined coins
> with coins mined after the fork. All pre-fork mined coins should
> "belong" to the network with hashpower majority. No other networks
> should be able to claim pre-forked coins as being part of their
> issuance (and therefore part of market cap). Market cap may be
> bullshit, but it is used a lot in the cryptosphere to compare coins to
> each other.
>=20
> The advantage of pre-fork coins being recorded on both forks is that
> if one fork goes extinct, no one loses any money. This setup
> encourages the minority chain to die,and unity returned. If pre-fork
> coins change hands on either fork (and not on the other), then holders
> have an incentive to not let their chain die, and the networks will be
> irreversibly split forever. The goal should be unity not permanent
> division.
>=20
> On 1/25/17, Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> "A. For users on both existing and new fork, anti-replay is an =
option,
>> not mandatory"
>>=20
>> To maximize fork divergence, it might make sense to require this. Any
>> sensible proposal for a hard fork would include a change to the =
sighash
>> anyway, so might as well make it required, no?
>>=20
>> Matt
>>=20
>> On 01/24/17 14:33, Johnson Lau via bitcoin-dev wrote:
>>> This is a pre-BIP. Just need some formatting to make it a formal BIP
>>>=20
>>> Motivation:
>>>=20
>>> In general, hardforks are consensus rule changes that make currently
>>> invalid transactions / blocks valid. It requires a very high degree =
of
>>> consensus and all economic active users migrate to the new rules at =
the
>>> same time. If a significant amount of users refuse to follow, a
>>> permanent ledger split may happen, as demonstrated by Ethereum =
(=E2=80=9CDAO
>>> hardfork"). In the design of DAO hardfork, a permanent split was not
>>> anticipated and no precaution has been taken to protect against
>>> transaction replay attack, which led to significant financial loss =
for
>>> some users.
>>>=20
>>> A replay attack is an attempt to replay a transaction of one network =
on
>>> another network. It is normally impossible, for example between =
Bitcoin
>>> and Litecoin, as different networks have completely different =
ledgers.
>>> The txid as SHA256 hash guarantees that replay across network is
>>> impossible. In a blockchain split, however, since both forks share =
the
>>> same historical ledger, replay attack would be possible, unless some
>>> precautions are taken.
>>>=20
>>> Unfortunately, fixing problems in bitcoin is like repairing a flying
>>> plane. Preventing replay attack is constrained by the requirement of
>>> backward compatibility. This proposal has the following objectives:
>>>=20
>>> A. For users on both existing and new fork, anti-replay is an =
option,
>>> not mandatory.
>>>=20
>>> B. For transactions created before this proposal is made, they are =
not
>>> protected from anti-replay. The new fork has to accept these
>>> transactions, as there is no guarantee that the existing fork would
>>> survive nor maintain any value. People made time-locked transactions =
in
>>> anticipation that they would be accepted later. In order to maximise =
the
>>> value of such transactions, the only way is to make them accepted by =
any
>>> potential hardforks.
>>>=20
>>> C. It doesn=E2=80=99t require any consensus changes in the existing =
network to
>>> avoid unnecessary debate.
>>>=20
>>> D. As a beneficial side effect, the O(n^2) signature checking bug =
could
>>> be fixed for non-segregated witness inputs, optionally.
>>>=20
>>> Definitions:
>>>=20
>>> =E2=80=9CNetwork characteristic byte=E2=80=9D is the most =
significant byte of the
>>> nVersion field of a transaction. It is interpreted as a bit vector, =
and
>>> denotes up to 8 networks sharing a common history.
>>>=20
>>> =E2=80=9CMasked version=E2=80=9D is the transaction nVersion with =
the network
>>> characteristic byte masked.
>>>=20
>>> =E2=80=9CExisting network=E2=80=9D is the Bitcoin network with =
existing rules, before a
>>> hardfork. =E2=80=9CNew network=E2=80=9D is the Bitcoin network with =
hardfork rules. (In
>>> the case of DAO hardfork, Ethereum Classic is the existing network, =
and
>>> the now called Ethereum is the new network)
>>>=20
>>> =E2=80=9CExisting network characteristic bit=E2=80=9D is the lowest =
bit of network
>>> characteristic byte
>>>=20
>>> =E2=80=9CNew network characteristic bit=E2=80=9D is the second =
lowest bit of network
>>> characteristic byte
>>>=20
>>> Rules in new network:
>>>=20
>>> 1. If the network characteristic byte is non-zero, and the new =
network
>>> characteristic bit is not set, this transaction is invalid in the =
new
>>> network. (softfork)
>>>=20
>>> 2. If the network characteristic byte is zero, go to 4
>>>=20
>>> 3. If the network characteristic byte is non-zero, and the new =
network
>>> characteristic bit is set, go to 4, regardless of the status of the
>>> other bits.
>>>=20
>>> 4. If the masked version is 2 or below, the new network must verify =
the
>>> transaction with the existing script rules. (no change)
>>>=20
>>> 5. If the masked version is 3 or above, the new network must verify =
the
>>> signatures with a new SignatureHash algorithm (hardfork). Segwit and
>>> non-segwit txs will use the same algorithm. It is same as BIP143, =
except
>>> that 0x2000000 is added to the nHashType before the hash is =
calculated.
>>>=20
>>> Rules in the existing network:
>>>=20
>>> 6. No consensus rule changes is made in the existing network.
>>>=20
>>> 7. If the network characteristic byte is non-zero, and the existing
>>> network characteristic bit is not set, this transaction is not =
relayed
>>> nor mined by default (no change)
>>>=20
>>> 8. If the network characteristic byte is zero, no change
>>>=20
>>> 9. If the network characteristic byte is non-zero, and the existing
>>> network characteristic bit is set, the masked version is used to
>>> determine whether a transaction should be mined or relayed (policy
>>> change)
>>>=20
>>> 10. Wallet may provide an option for setting the existing network
>>> characteristic bit.
>>>=20
>>>=20
>>> Rationales (by rule number):
>>>=20
>>> 1. This makes sure transactions with only existing network
>>> characteristic bit set is invalid in the new network (opt-in =
anti-replay
>>> for existing network transactions on the new network, objective A)
>>>=20
>>> 2+4. This makes sure time-locked transactions made before this =
proposals
>>> are valid in the new network (objective B)
>>>=20
>>> 2+5. This makes sure transactions made specifically for the new =
network
>>> are invalid in the existing network (anti-replay for new network
>>> transactions on the old network); also fixing the O(n^2) bug =
(objectives
>>> A and D)
>>>=20
>>> 3. This is to prepare for the next hardfork from the new network
>>> (objective A)
>>>=20
>>> 6, 7, 8. These minimise the change to the existing network =
(objective C)
>>>=20
>>> 9, 10. These are not strictly needed until a hardfork is really
>>> anticipated. Without a significant portion of the network and miners
>>> implement this policy, however, no one should create such =
transactions.
>>> (objective A)
>>>=20
>>>=20
>>> Limitations:
>>>=20
>>> * It is not possible to protect transactions made before the =
proposal.
>>> To avoid a replay of such transactions, users should first spend at
>>> least a relevant UTXO on the new network so the replay transaction =
would
>>> be invalidated.
>>>=20
>>> * It is up to the designer of a hardfork to decide whether this =
proposal
>>> is respected. As the DAO hardfork has shown how harmful replay =
attack
>>> could be, all hardfork proposals (except trivial and totally
>>> uncontroversial ones) should take this into account
>>>=20
>>> * The size of network characteristic byte is limited to 8 bits. =
However,
>>> if we are sure that some of the networks are completely abandoned, =
the
>>> bits might be reused.
>>>=20
>>>=20
>>> Reference implementation:
>>>=20
>>> A demo is available in my forcenet2
>>> branch:
>>> =
https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f554=
73c682a
>>> =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/01347=
2.html
>>>=20
>>>=20
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
|