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
|
Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6844A18DC
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2015 13:30:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E3B6D164
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2015 13:30:49 +0000 (UTC)
Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197]
(may be forged)) (authenticated bits=0)
by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t8TDUgbR032339
(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Tue, 29 Sep 2015 06:30:43 -0700
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_14A1EB39-DF79-40C2-86EF-0DF68F6F4533";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.1
From: "Jonathan Toomim (Toomim Bros)" <j@toom.im>
In-Reply-To: <20150928144318.GA28939@savin.petertodd.org>
Date: Tue, 29 Sep 2015 06:30:41 -0700
Message-Id: <40B097BA-A389-4C46-B5DE-2EC4738086BA@toom.im>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<20150928132127.GA4829@savin.petertodd.org>
<CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com>
<20150928142953.GC21815@savin.petertodd.org>
<CA+w+GKTUz2eVJOpixSebWiQ59ovoELNhsZWSsbLHXWqk2eCn0A@mail.gmail.com>
<20150928144318.GA28939@savin.petertodd.org>
To: Peter Todd <pete@petertodd.org>
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVaCf/AQVhGmWFua/p0XYhIC1lSqV3JpQKWZFJ9DuoZnIUG5AG6maPxczTRbR+tMZb+CkhE3UYlXGR947MXpMsA3
X-Sonic-ID: C;QHfhR65m5RG6DL0U9jFv0A== M;7mmGSK5m5RG6DL0U9jFv0A==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Tue, 29 Sep 2015 13:30:50 -0000
--Apple-Mail=_14A1EB39-DF79-40C2-86EF-0DF68F6F4533
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Sep 28, 2015, at 7:43 AM, Peter Todd via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> Ok, so again, if that's your security criteria, what's the issue with
> soft-forks? With soft-forks, the result of a SPV wallet following the
> highest work chain is the same: eventually invalid blocks are reorged
> out.
>=20
> However, because soft-forks make it less likely that a long invalid
> chain will be generated, an attacker sybil attacking your SPV wallet =
has
> a much harder time tricking it into accepting a transaction. (they =
might
> get one or two confirmations, rather than dozens)
>=20
> What's the scenario where soft-forks are worse than hard-forks from a
> SPV wallet's perspective?
I don't think this was addressed clearly, so here's my attempt.
With a soft fork, miners who have not upgraded append their blocks to =
the longest block chain. To SPV clients and to old fully-validating =
clients, it appears to be a valid block that inevitably gets orphaned. =
SPV clients will be tricked to follow these blocks every time they =
appear, since every time they appear they will have a PoW advantage for =
a few minutes. SPV clients will appear to behave normally, and will =
continue to show new transactions and get confirmations in a timely =
fashion. However, they will be systematically susceptible to attack from =
double-spends that attempt to spend funds in a way that the upgraded =
nodes will reject. These transactions will appear to get 1 confirmation, =
then regress to zero conf, every single time. These attacks can be =
performed for as long as someone mines with the old version. If an =
attacker thinks he could get more than 25 BTC of double-spends per =
block, he might even choose to mine with the obsolete version in order =
to get predictable orphans and to trick SPV clients and fully verifying =
wallets on the old version.
With a hard fork, miners who have not upgraded will append their blocks =
on the shorter fork. SPV clients will ignore this fork unless Sybil =
attacked. If an SPV node only connects to one full node server, that's =
equivalent to a Sybil attack. In that case, transactions on the long =
chain will often not be present on the short chain due to its shortness. =
Confirmations will be slow, and will be shown to be very different from =
what's shown on block explorers. Displayed transaction dates and times =
will be off, when they show up at all. Any transactions that have been =
contaminated by recent mining revenue will not show up at all. SPV =
client users will probably notice something is wrong. If the SPV client =
connects to several full nodes, then this should rarely happen. For =
example, if 5% of full nodes are still on the old version, and an SPV =
wallet connects to 2 nodes at a time, there is a 0.05**2 =3D 0.25% =
chance. If the SPV client has headers cached on disk from a previous =
connection to the longer chain, then that chance effectively drops to =
zero. As a further benefit to hard forks, anybody who is ideologically =
opposed to the change can continue to use the old version successfully, =
as long as there are enough miners to keep the fork alive.
In short: soft forks mean frequent predictable and manipulable orphan =
blocks that SPV clients will always follow, with transactions that get =
confirmed once and then perma-orphaned. Hard forks mean that SPV clients =
will almost always work flawlessly, and will occasionally give very =
strange and noticeably wrong results. For fully-verifying nodes, soft =
forks make old versions insecure, but hard forks allow new and old =
versions to operate in parallel.
--Apple-Mail=_14A1EB39-DF79-40C2-86EF-0DF68F6F4533
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJWCpKCAAoJEIEuMk4MG0P1yS4H/j1rtS21GrV3RUhNAFFJ8MUz
ty7s5Cd2meD6Te13A6apwSBE1qChxAOb4QZIsdEcWAUFGWghr1BO0uh0wdZMdV0i
eTo0Uzy2cOVNiezYxAofCWgp8pWd2Ufp2m8zMGizT9CJWkGBgqYXZxtKfkgcOs+v
ovDrSLM8ojeu4SDC2Ib4ul0xJSV9b+9RsE+46FYFs0a4rJjnS3fr6vxI+kwM24x0
jg0dvrt5rY4vhbgE43fsfWKZDmCIIn67E1SSvg3bYIiGjQgIWzl4esVg7mESMSFN
sbKXZekJ8o/KO54GfCSabxJN5dFTzRHkwMIR1WkfOYL8cmfC61q4CBTJ9+ZwEk0=
=OagS
-----END PGP SIGNATURE-----
--Apple-Mail=_14A1EB39-DF79-40C2-86EF-0DF68F6F4533--
|
