From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6844A18DC for ; 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 ; 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)" 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> <20150928132127.GA4829@savin.petertodd.org> <20150928142953.GC21815@savin.petertodd.org> <20150928144318.GA28939@savin.petertodd.org> To: Peter Todd 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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--