Earlier quoted context omitted.
If by strength you mean, "A clear methodology from which a sufficiently large ec2 buy can rapidly fragment the Bitcoin consensus" then yes, I suppose that's fantastic. From the perspective of people transacting on Bitcoin's infrastructure I suspect they'd call it "an attack."
>a sufficiently large ec2 buy can rapidly fragment the Bitcoin consensus You grossly underestimate the hashing capacity of the bitcoin network. The hashing capacity, at time of posting, is approximately 5,000,000,000 Gigahashes/second[1]. Spot measurement of the hashing capacity of an EC2 instance is 0.4 Gigahashes/second[2]. You would need 12 BILLION EC2 instances to 51% attack the bitcoin network.[3] Using EC2 to a…
I don't need to overcome the network, I need to invite the network to have arguments with itself, by finding a way to introduce widespread partitioning of the network.
In this, the preference to longer hash chains seems like a good idea in a unified clock model but a somewhat optimistic decision in a split clock world.