51% attack will not kill Bitcoin - Plan B

[Michael_S]

I did not find anything, but maybe someone thought this up already...

I always read everywhere: A 51% would kill bitcoin. Sure it would kill today's bitcoin protocol.

So I am wondering, what would happen then? Will all bitcoiner's just say "sorry" and go home? Will people accept their bitcoins are gone and switch to litecoin or "XYZcoin"?

No, there is too much market cap in bitcoin. So I think "some developers" will pull out a new client "bitcoin 2.0" that implements a new protocol (based on a new hashing algo incompatible with today's bitcoin ASICs, and maybe also adding some Proof of Stake component) but builds on the bitcoin 1.0 blockchain, adding a checkpoint to the last block before the attack.

This way, after some outage time, the bitcoin network, will be operational again, and all the bitcoin funds are safe. Only those users who have received BTC payments after the checkpoint (i.e. after the attack started) will have these bitcoins lost.

I hope that those "some developers" are the bitcoin core developers. I don't expect them to answer here, I just hope that they read this and have the "Plan B" already in the drawer, ready for launch if needed.

[1715646074]

1715646074

[1715646074]

1715646074

[1715646074]

1715646074

[Kluge]

Reversing a big swath of transactions is probably worse than double-spends as far as faith in Bitcoin's security goes. It's going to be a pretty long span of outage before this could be done unless pools are willing to rush it through. But then, we're not exactly known for slowing down and taking deep breaths when disaster strikes. 

[gmaxwell]

Of course Bitcoin wouldn't go quietly into the night— but any countermeasure will depend on the very fine specifics of the attack. There is also an advantage for the honest users if the attacker doesn't know how we'll respond for sure.

Though it's not clear, ultimately, how much it will matter in terms of long term trust. Such an attack would be strong evidence that our security assumptions are not sufficient.  No one has described an alternative to our sibyl resistance which is clearly better.  (I see you repeat the oft chanted "proof of stake"— but the problem with Proof of Stake is that there is nothing at stake, rational POS miners will concurrently mine all forks that don't screw them. The existing POS coin is secured by a developer controlled (centralized) checkpoint that is constantly broadcast).

[Michael_S]

Reversing a big swath of transactions is probably worse than double-spends as far as faith in Bitcoin's security goes. It's going to be a pretty long span of outage before this could be done unless pools are willing to rush it through. But then, we're not exactly known for slowing down and taking deep breaths when disaster strikes.  

...ok, if it's just about a few double-spendings...

I was rather thinking about a nasty attack where the attackers mine a parallel branch of the chain secretly (maybe for many days or weeks...) and then suddenly connect to the rest of the bitcoin network, and the last few days (or weeks) of what everyone thought was the "correct chain" would suddenly become an orphan (i.e. "extinct" block)..., with all transactions from that time lost.

In this case the client 2.0 would have to declare the "weaker" branch of the chain the "correct one" (which would of course constitute a one-time centralistic decision) and implement another, new, mining method (hasing algo/PoS...) that does not empower the same attacker to take over again.

[Michael_S]

[...] I see you repeat the oft chanted "proof of stake"— but the problem with Proof of Stake is that there is nothing at stake, rational POS miners will concurrently mine all forks that don't screw them. [...]

I don't want to go off-topic with PoS discussion (on which I have no final opinion yet), but as far as I understood there are also ideas for hybrid methods combining PoW/PoS in the same block, e.g. in the sense that a block is accepted if it matches a difficulty target which is not a global constant (same Threshold for all miners), but instead a global constant adjusted by a value that is a function of the stake he throws in... (just the basic idea... one could think of many ways how to do it in detail...)

[yacoin]

Don't know if that could be done.

Will they even know a 51% attack took place?

[Michael_S]

Don't know if that could be done.

Will they even know a 51% attack took place?

Hello Yet Another Alt-Coin expert,

If I have received some BTCs 10 days ago, and today my client suddenly says I have never received these BTCs, sure would I know what's going on. Moreover you would see a long orphan (extinct chain of blocks) at blockchain.info. (that's the scenario I was mentioning)

If the 51% attackers are less malicious and just create some orphan's of length 1 or 2 blocks from time to time, then this is not what I would call a dangerous 51% attack - such "attackers" are not worth being called attackers, they still contribute more than what they harm I would say. The benefit they would get from a potential double spending is probably MUCH less than the cost they have to pay for the attack, so this is not a realistic threat anyway.

I was rather talking about a really hostile 51% attack from a "system enemy", like a central bank or a hostile government or so, aiming at destroying the network altogether (and not just aiming at performing some little double-spendings), even if it costs a billion USD or so.
That's what I had in mind in my original post.

[casascius]

I think in the event of a 51% attack, trusted people, miners, mining pools, businesses with a big stake in bitcoin, and other entities will start signing blocks to say that they have received them and believe they are legitimate (i.e. not attack) blocks.  Clients will evolve so that the signatures of trusted people will be considered as weight towards block validation.  In the interim before that happens, you'll also have trustworthy entities offering an emergency solution: "We'll filter out the attack blocks if you connect to us... bitcoind -connect=xxx.xxx.xxx.xxx".  It'll be temporary centralization of the network.

In the long run, a 51% attack won't succeed.  A system that uses a combination of proof-of-work as primary, human consensus for fork resolution as secondary, will raise the bar from 51% all the way up to 99%.  That's about as democratic as it gets.

[Michael_S]

I think in the event of a 51% attack, trusted people, miners, mining pools, businesses with a big stake in bitcoin, and other entities will start signing blocks to say that they have received them and believe they are legitimate (i.e. not attack) blocks.  Clients will evolve so that the signatures of trusted people will be considered as weight towards block validation.

This would be some sort of centralization that is hard-coded into the clients - certain market participants (those owning these "trusted" keys acc. to client source code) would have a stronger weight by the power of client source code.

I think, if we have a protocol change, then the other protocol change (namely having the difficulty threshold a function of the stake (a second term, on top of today's formula)) would serve a similar purpose, but without pre-compiled centralization. So I would prefer such change, and only if this fails again, i.e. if the former 51% attacker still continues and also accumulates enough stake so that he can again attack the network successfully, then I would consider the above mentioned solution as a last resort.

In the interim before that happens, you'll also have trustworthy entities offering an emergency solution: "We'll filter out the attack blocks if you connect to us... bitcoind -connect=xxx.xxx.xxx.xxx".  It'll be temporary centralization of the network.

In the long run, a 51% attack won't succeed.  A system that uses a combination of proof-of-work as primary, human consensus for fork resolution as secondary, will raise the bar from 51% all the way up to 99%.  That's about as democratic as it gets.

Exactly, and this thread is just about how this "human consensus for fork resolution" (i.e. modest adaptation of the bitcoin protocol) may look like in practice (should it ever become necessary).