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
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>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list


--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--