Blockchain rollback limit?

[SgtSpike]

The government builds a new blockchain and releases it.  Suddenly, months of transactions are reversed.  People realize the problem, and put a plan into action.  A new QT client is released with a hardcoded block checkpoint of the last legitimate block mined.  Half of everyone using Bitcoin quickly switches to it, the other half slowly switches over.

The last legitimate block is already gone.

But here's the question:  If the government could build a new blockchain for months and release it, then they must have more hashpower than the rest of the network combined.  What is stopping them from messing with the legitimate blockchain from the hardcoded checkpoint on forward?  If the checkpoint is block 240,000, how would a miner know whether block 240,001 came from the government or came from a legitimate miner?

If it's only possible to rollback 288 blocks, I know for sure that my payment is 100% safe after 288 blocks. If they release new blocks into the existing blockchain, there is no reason to don't accept the blocks from them.

Ok, new scenario.  I'm a new Bitcoin client.  I broadcast to the network to gather the blockchain.  I get the government IP responding.  Suddenly, I have a blockchain that doesn't match anyone else's.  It can't be "reversed" so I can get on the proper blockchain because the fork was earlier than 288 blocks ago.  What do I do?  How do I even know I'm on a different blockchain?

[Kupsi]

Ok, new scenario.  I'm a new Bitcoin client.  I broadcast to the network to gather the blockchain.  I get the government IP responding.  Suddenly, I have a blockchain that doesn't match anyone else's.  It can't be "reversed" so I can get on the proper blockchain because the fork was earlier than 288 blocks ago.  What do I do?  How do I even know I'm on a different blockchain?

If a government is attacking Bitcoin, it would be big news. And if it happens, I believe that to manually connecting to a trusted node the first time is OK. The government IP wouldn't respond any more when the attack fails, only costing the government money.

[DeathAndTaxes]

If the government is going to spend millions to attack the network wouldn't they take over the trusted nodes?  Actually having trusted nodes would be an even larger attack vector.  If clients are forced to trust trusted nodes then compromise them and you can feed them any kind of garbage you want even with a trivial amount of hashing power.

[Kupsi]

If the government is going to spend millions to attack the network wouldn't they take over the trusted nodes?  Actually having trusted nodes would be an even larger attack vector.  If clients are forced to trust trusted nodes then compromise them and you can feed them any kind of garbage you want even with a trivial amount of hashing power.

Is it better to let them attack the network, deleting months with transactions/blocks, without resistance?

[DeathAndTaxes]

No it is better to come up with a solution which provides real security not feel good security.  Like I said up thread.

This doesn't mean it is impossible but if your first thought is "oh this is easy just do ..." then you are likely wrong.

It is a non trivial problem.  The blockchain is a consensus agreement on where coins are.  It only works if every single nodes is part of the consensus.  Currently the consensus is reached by agreement that the longest chain is the correct one.  That is vulnerable to a 51% attack however it is deterministic.  No matter the state of a node online, offline, corrupted blockchain which needs to be rebuilt all nodes will reach the same consensus.

Any solution which relies on centralized trust nodes or is non-deterministic risks either making an attack easier (control the trust nodes, control the network) OR fragmenting the network into incompatible forks.

Stop treating it like a trivial problem.  It is a MASSIVELY complex problem which requires some real out of the box thinking.   If you believe that after thinking about it a few minutes you have a solution you likely are wrong.

[Kupsi]

Any solution which relies on centralized trust nodes or is non-deterministic risks either making an attack easier (control the trust nodes, control the network) OR risks fragmenting the network into incompatible forks.

I prefer a very tiny risk for a incompatible fork if that can protect against a big government attack.

[DeathAndTaxes]

What if the attack is to create incompatible forks each with its own double spend and thus no consensus can be reached as nobody is going to agree the fork they are double spent on is the "correct" one.   That is the risk of a non-deterministic method of choosing the longest chain.

[Gabi]

The last legitimate block is already gone.

Don't underestimate people backuping the chain.

[Kupsi]

What if the attack is to create incompatible forks each with its own double spend and thus no consensus can be reached as nobody is going to agree the fork they are double spent on is the "correct" one.   That is the risk of a non-deterministic method of choosing the longest chain.

How would they do that?

[JoelKatz]

That's the whole reason for automatically choosing the longest chain in the first place - it is assumed that the longest chain is the legitimate chain.  If not the longest, then how does your mining software determine which chain to mine on?

Exactly, the current design has no path dependence. The longest chain in existence is the valid chain, period.

Any rollback limit would introduce path dependence. Which chain is the valid chain depends on how you got there.

What I'm suggesting is a rollback limit, but if you encounter a case where you would rollback past the limit, you declare the network in an invalid state until and unless the chain you are on becomes the longest chain. That is, you enter a definitive "failed" state in which you declare the network broken.

If we do nothing, and this rare case happens, the network will be broken, we just will continue blissfully going on as if it was fine.

If we just implement a rollback limit and stay on our chain, the network will silently split. This is a solution that is not significantly better than the problem.

Whether the problem is serious enough that it's worth addressing is another issue. For purposes of this thread, I'm assuming it's a concern worth addressing.

[Gabi]

Well, if in chain 1 i lose money and in chain 2 you lose it, we cannot agree, of course i would want chain 2, you would want chain 1. Probably the majority will decide.

[JoelKatz]

Well, if in chain 1 i lose money and in chain 2 you lose it, we cannot agree, of course i would want chain 2, you would want chain 1. Probably the majority will decide.

The thing is, if it remains split, you both lose money.

[DeathAndTaxes]

Well, if in chain 1 i lose money and in chain 2 you lose it, we cannot agree, of course i would want chain 2, you would want chain 1. Probably the majority will decide.

The thing is, if it remains split, you both lose money.

True however it sets up a prisoner's dilema type situation.  Also I would point out there is no "majority rule" while a Democracy is one method of achieving a consensus the anonymous nature of Bitcoin makes any democratic method to select the best blockchain doomed.  Also an active attack likely wouldn't be just a binary decision but rather a series of double spends on various forks creating new forks and a chaotic mess of conflicting priorities and viewpoints.

There is a reason that the blockchain was designed to be deterministic.  All nodes everywhere in the world regardless of being online or offline can via communication with other nodes reach a single consensus view of the blockchain.  Once you introduce the need for humans to "pick the winner" it becomes very easy to both game the system and crush any resistance by creating dissent.  The users who believe blockchain A is the "correct" one have no mechanism to prevent those who believe blockchain B is "correct" from continuing that fork.  An attacker just has to continually fork the forks over and over to divide and conquer.  Also the attacker wouldn't be foolish to always put "good tx" on one side of the fork and "double spends" on the other side of the fork.  Remember this is a non-economic attacker.  Far better to continually and randomly place the spend and double spend so that no matter which fork is chosen there is always a victim.

I think most 51% attack "solutions" niavely assume that the "attacker" will do something as stupid as just make a single obvious attack.  Something like fork the blockchain back 500+ blocks and then continue on that game plan blindly without reacting to the actions of defenders.  The reality is any entity which has the millions of dollars to acquire that amount of hashing power isn't going to use it like a club.  It would be far more effective to hire some smart minds to devise a continually adjusting attack pattern.  Any "solution" which requires humans to determine in real time the "correct" blockchain AND always do the right thing for the public even at personal consequence to him/herself is not a solution.

[Matthew N. Wright]

Could you just run 2 clients using different chains and live in both worlds?

[Kupsi]

Could you just run 2 clients using different chains and live in both worlds?

I believe the chain with the smallest user base will die...

[JoelKatz]

Could you just run 2 clients using different chains and live in both worlds?

That makes everyone who held bitcoins before and through the split twice as wealthy!

[Matthew N. Wright]

Could you just run 2 clients using different chains and live in both worlds?

That makes everyone who held bitcoins before and through the split twice as wealthy!

I know, right!

[Qoheleth]

Could you just run 2 clients using different chains and live in both worlds?

Theoretically. But if someone wants bitcoins, do you send them A-Bitcoins, or B-Bitcoins? Don't you have to send them both? If so, if the attacker is intelligent and hasn't pawned its mining equipment, why should they stop at two chains? If you define the maximum reorg as 288 blocks (two days), then the attacker can double the number of chains every three days. A month down the road, you would have to be running 1000 clients just to unambiguously send a coin.

[Kupsi]

There is a reason that the blockchain was designed to be deterministic.  All nodes everywhere in the world regardless of being online or offline can via communication with other nodes reach a single consensus view of the blockchain.  Once you introduce the need for humans to "pick the winner" it becomes very easy to both game the system and crush any resistance by creating dissent.  The users who believe blockchain A is the "correct" one have no mechanism to prevent those who believe blockchain B is "correct" from continuing that fork.  An attacker just has to continually fork the forks over and over to divide and conquer.  Also the attacker wouldn't be foolish to always put "good tx" on one side of the fork and "double spends" on the other side of the fork.  Remember this is a non-economic attacker.  Far better to continually and randomly place the spend and double spend so that no matter which fork is chosen there is always a victim.

How easy is there for an attacker to keep the forks separated from each other for days so they get past the "rollback limit"? Each fork needs a decent percent of the user base. That would be hard to manage.

[Matthew N. Wright]

Could you just run 2 clients using different chains and live in both worlds?

Theoretically. But if someone wants bitcoins, do you send them A-Bitcoins, or B-Bitcoins? Don't you have to send them both? If so, if the attacker is intelligent and hasn't pawned its mining equipment, why should they stop at two chains? If you define the maximum reorg as 288 blocks (two days), then the attacker can double the number of chains every three days. A month down the road, you would have to be running 1000 clients just to unambiguously send a coin.

Well, I suppose since it's all software anyway, a single client could be modified to just include all the chains in an array of sorts (not sure what the space/calculating requirements would be for that though) and just automatically update your account as such, and use the chain-specific addresses as you specific from a dropdown (or potentially automatic). Why do I suspect this is the future of bitcoin once the governments get involved? We all agree that they can't stop bitcoin, but governments never really stop anything, they just screw things up, and they do that very well.