Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Anthony Towns <aj@erisian.com.au>]

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