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 5F7ED3C8 for ; Mon, 12 Oct 2015 17:06:43 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CD6AA20A for ; Mon, 12 Oct 2015 17:06:42 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=navy.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian)) id 1ZlgYa-0005ti-50 for ; Tue, 13 Oct 2015 03:06:41 +1000 Received: by navy.erisian.com.au (sSMTP sendmail emulation); Tue, 13 Oct 2015 03:06:37 +1000 Date: Tue, 13 Oct 2015 03:06:37 +1000 From: Anthony Towns To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20151012170637.GA21399@navy> References: <20151007150014.GA21849@navy> <1444633370859.8a298e9c@Nodemailer> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1444633370859.8a298e9c@Nodemailer> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY 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] 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: Mon, 12 Oct 2015 17:06:43 -0000 On Mon, Oct 12, 2015 at 12:02:51AM -0700, digitsu412 via bitcoin-dev wrote: > First I think your unsaid assumption about the fragility of a soft > fork showing incorrect confirmations is dependent on the percentage > of hash power that didn't upgrade.  If using your same numbers this > was only 5% of the hash power, the attack is effectively not effective > (u less the attacker knew an exact merchant that was unfortunately on > the minority of the network.  Actually, just to take this scenario more explicitly... Say you've got 5% of hashpower running on old software, along with, say, 1500 nodes; and meanwhile you've got 95% of hashpower running new software, along with 4000 nodes. There's still about 750 nodes running 0.9 or 0.8 of 5400 total according to bitnodes.21.co/nodes, so those numbers seems at least plausible to me for the first week or two after a soft-fork is activated. Eventually an old-rules block gets found by the 5% hashpower. The 4000 new nodes and 95% of hashpower ignore it, of course. With 8 random connections, old nodes should have 92% chance of seeing an old node as a peer, so I think around ~1300 of them should still be a connected subgraph, and the old-rules block should get propogated amongst them (until two new-rules blocks come along and orphan it). An SPV client with 12 random connections here has 96% chance of having one of the ~1300 old nodes as a peer, and if so, will see the old-rules block, that will be orphaned, and may be at risk from double-spends as a result. So I think even with just 5% hashpower and ~30% of nodes left running the old version, a "damaging soft fork" still poses a fairly high risk to someone receiving payments via an SPV client, and trusting transactions with few confirmations. Cheers, aj