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
|
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 D897B958
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 04:03:49 +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 0D59C140
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 04:03:48 +0000 (UTC)
Received: from [192.168.1.111] (137.189.135.19 [137.189.135.19]) by
mx.zohomail.com with SMTPS id 1485317024391545.4686974422764;
Tue, 24 Jan 2017 20:03:44 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 25 Jan 2017 12:03:40 +0800
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
<efad941b-ce3e-1c98-ca5b-51da66badc6c@thinlink.com>
To: Tom Harding <tomh@thinlink.com>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <efad941b-ce3e-1c98-ca5b-51da66badc6c@thinlink.com>
Message-Id: <3F2FDFFC-A73B-4C0F-A7B2-8449332BE70E@xbt.hk>
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
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: Wed, 25 Jan 2017 04:03:50 -0000
Yes, it=E2=80=99s similar. I=E2=80=99ll quote your design if/when I =
formalise my BIP. But it seems they are not the same: yours is opt-out, =
while mine is opt-in.
However, my proposal in nowhere depends on standardness for the =
protection. It depends on the new network enforcing a new SignatureHash =
for txs with an nVersion not used in the existing network. This itself =
is a hardfork and the existing network would never accept such txs.
This is to avoid requiring any consensus changes to the existing =
network, as there is no guarantee that such softfork would be accepted =
by the existing network. If the new network wants to protect their =
users, it=E2=80=99d be trivial for them to include a SignatureHash =
hardfork like this, along with other other hardfork changes. Further =
hardforks will only require changing the network characteristic bit, but =
not the SignatureHash.
If the hardfork designers don=E2=80=99t like the fix of BIP143, there =
are many other options. The simplest one would be a trivial change to =
Satoshi=E2=80=99s SignatureHash, such as adding an extra value at the =
end of the algorithm. I just don=E2=80=99t see any technical reasons not =
to fix the O(n^2) problem altogether, if it is trivial (but not that =
trivial if the hardfork is not based on segwit)
> On 25 Jan 2017, at 02:52, Tom Harding <tomh@thinlink.com> wrote:
>=20
> On 1/24/2017 6:33 AM, Johnson Lau via bitcoin-dev wrote:
>> 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
> Johnson,
>=20
> Your proposal supports 8 opt-out bits compatible with may earlier
> description:
> =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.h=
tml.
>=20
> If the existing network really wants to play along, it should execute =
a
> soft fork as soon as possible to support its own hard-fork opt-out bit
> ("network characteristic bit"). It is totally inadequate for a new
> network to rely on non-standardness in the existing network to prevent
> replay there. Instead, in the absence of a supported opt-out bit in =
the
> existing network, a responsible new network would allow something that
> is invalid in the existing network, for transactions where replay to =
the
> existing network is undesirable.
>=20
> It is an overreach for your BIP to suggest specific changes to be
> included in the new network, such as the specific O(n^2) fix you
> suggest. This is a matter for the new network itself.
>=20
>=20
|
