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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev