Let's deploy BIP65 CHECKLOCKTIMEVERIFY!



Summary:

In a discussion on bitcoin-dev, the question of the fragility of a soft fork showing incorrect confirmations was raised. The validity of this assumption is dependent on the percentage of hash power that didn't upgrade, and if only 5% of the hash power did not upgrade, the attack would be ineffective unless the attacker knew an exact merchant on the minority network. In a scenario where 5% of hash power is running old software, along with 1500 nodes, while the remaining 95% are running new software, along with 4000 nodes, roughly 750 nodes are still running the old software. An old-rules block gets found by the 5% hash power, which the 4000 new nodes and 95% of hashpower ignore. With eight random connections, old nodes should have a 92% chance of seeing an old node as a peer, so around ~1300 of them should still be a connected subgraph, and the old-rules block should get propagated amongst them until two new-rules blocks come along and orphan it. An SPV client with 12 random connections here has a 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.It was concluded that even with just 5% hash power 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.


Updated on: 2023-05-19T22:01:55.590007+00:00