[DINKDINK]

>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 attack the network is impractical and inefficient.

[1] https://bitcoinwisdom.com/bitcoin/difficulty

[2] https://www.reddit.com/r/Bitcoin/comments/1btgl1/i_was_curio...

[3] x/(5e18+x)=.51 y=x/.4e8

[codeisawesome]

In the OP, the author says there are "approximately 5,000 computers" in the bitcoin network. I'm curious if you believe this is right too? Those are some powerful computers... (yes, "duh" indeed, I'm still awed).

[Slartie]

That could very well be true. All mining for BTC is done via ASICs now, specialized silicon that just hashes crazy fast, but can't even get a TCP connection up and running. For networking, a bunch of ASIC chips is typically connected to some embedded computer, and even that usually isn't a direct peer on the Bitcoin network, but only connected to a mining pool server with hundreds of other such ASIC controllers. And this server then is the first actual part of the Bitcoin p2p network, single-handedly representing a mind-boggling multi-Megawatt hash power infrastructure.

Even most BTC users do not run actual clients anymore but use exchanges or wallet services which bundle huge numbers of users behind few actual Bitcoin network nodes.

[codeisawesome]

Those are interesting facts I never thought about! Thanks for the detailed explanation.

[KirinDave]

I'm happy to be wrong, but I feel like I don't have to overcome the entire network's hashing, I need to overcome several individual instances. If I could isolate and attack individual members of the cluster quickly, I could begin to leverage their role in the cluster as they join, convinced that a single block must be true.

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.

[DINKDINK]

>If I could isolate and attack individual members of the cluster quickly, I could begin to leverage their role in the cluster as they join, convinced that a single block must be true.

To do this you would need to have the equivalent hashing power of the network. Peers expect an nominally equivalent amount of Proof of Work for the difficulty adjustment. You would also need to guarantee that the peer connects to _no other_ peers

Your thinking is good adversarial thinking but it's already covered in the protocol.