>If miners chose to mine on a chain that no-one wants, then everybody has to grudgingly go along with it
No, if the miners mine on a chain that doesn't meet consensus rules, users will not follow it. If miners decide that the coinbase issuance schedule isn't to their liking, and decide to revert it back to 50 bitcoins per block, users will reject those blocks. This is a fundamental governance property of a blockchain.
But the problem is that soft forks can do basically anything. Yes, even increase the block reward, in a roundabout way, (by using added extension blocks that have special rules, and then requiring all transactions to go through the extension blocks.)
Although from the perspective of a non-conforming Node, this would just look like a DDOS style mining empty blocks attack.
At this point the only thing that users can do is change the Proof of Work algorithm. .... But, if the big players in mining have a bunch of GPUs on standby... well, it is not even guaranteed that this will work.
You're also referring to a major weakness in the distributed consensus of bitcoin: the longest-chain-preferred mechanism is almost certainly a vector of attack on the chain.
Wouldn't you need to have a majority of the hash power to fork the chain and generate a longer one anyway? I think it's well understood that anybody managing to go above 50% of the hash capacity effectively "rules" the currency.
This is a common response to this but I don't think it's true in every case. I think if your goal is strictly to disrupt the Bitcoin service you can accomplish that by disrupting and attacking individual nodes in parallel and letting the resulting chaos from these cheaper attacks widen the scope of your disruption, stepwise.
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 attack the network is impractical and inefficient.
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).
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.
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.
>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.
Only the longest chain that users consider legitimate. If users reach consensus on using rules that have lower transaction costs, it won't matter how long miners mine their higher transaction cost chain.
The big question is: can users achieve such consensus politically, or in practice do the miners lead the users because they need less organization to do so?
If miners chose to mine on a chain that no-one wants, they'll run into losses. Users will probably move to some other chain.
As an example: Bitcoin users might wanna switch to Litecoin. And guess what miners will do then ?
No, if the miners mine on a chain that doesn't meet consensus rules, users will not follow it. If miners decide that the coinbase issuance schedule isn't to their liking, and decide to revert it back to 50 bitcoins per block, users will reject those blocks. This is a fundamental governance property of a blockchain.