Blockchain rollback limit?

[Kupsi]

Is there a limit for how many blocks that can be rolled back after a network split or if someone tries to do a 51% attack?

New coins can be spent after 120 blocks, and I guess a 120 blocks rollback limit makes sense. Then transfers would be 100% resistant against a 51% attack after about 20 hours. And if there was a network split with 50% hashing power on each side, the network would have about 40 hours to merge. If there was a network split with 75% and 25% hashing power on the two sides, the 25% side would have about 80 hours to connect to the 75% side again.

[1713491791]

1713491791

[1713491791]

1713491791

[1713491791]

1713491791

[DannyHamilton]

Is there a limit for how many blocks that can be rolled back after a network split or if someone tries to do a 51% attack?

The reference client (Bitcoin-Qt) includes checkpoints built in to the source code. It shouldn't be possible to orphan any blocks in the blockchain from prior to the most recent checkpoint.  I believe the last checpoint in the current version 0.7.2 was block 210,000.

[kjj]

Checkpoints are in checkpoints.cpp.  As of 0.7.1, the latest was 193,000.  I'm not sure if 0.7.2 moved it up.

There are problems with limiting rollback.  I've proposed a scheme where reorgs become exponentially more costly, but it still has the problem that it adds new state to the system and messes with automatic convergence.

[Kupsi]

There are problems with limiting rollback.  I've proposed a scheme where reorgs become exponentially more costly, but it still has the problem that it adds new state to the system and messes with automatic convergence.

I believe the problems with limiting (automatic) rollback to 120 blocks is smaller than the possible problem with a government building a lot of ASICs, making blocks in the dark and release them to the network after a long time. This could kill Bitcoin.

Can someone point me to a discussion on this topic? I've tried to search.

[Gabi]

There is no limit. Actually there is no "rollback" at all.

Why this 120 block thing? It is just the number of confirmations required to spend mined coins, nothing more. Totally unrelated to "rollback"

As long as someone have a backup blockchain (for example if the 51% attack use a chain where the modifies start 6 months ago or a year ago in the chain) we are totally fine.

Yes, this will require a fix in the client to tell the client "ehi ignore the wrong chain" 

[Kupsi]

Why this 120 block thing?

I thought about 144 blocks (24 hours), but since 120 blocks is the limit for spending fresh coins a 120 block limit makes sense.

As long as someone have a backup blockchain (for example if the 51% attack use a chain where the modifies start 6 months ago or a year ago in the chain) we are totally fine.

A 6 months rollback is not fine!

[JoelKatz]

I believe the problems with limiting (automatic) rollback to 120 blocks is smaller than the possible problem with a government building a lot of ASICs, making blocks in the dark and release them to the network after a long time. This could kill Bitcoin.

Say you limit rollback. Say about half the network watched chain X unfold and it's the longest chain. And say half the network is on chain Y and would need a rollback past the limit to get to chain X. Isn't it true that both chains are now equally correct by the rules? I'm not so sure it's such a good idea to introduce path dependence to a network that can't even remotely guarantee that all nodes take the same path.

I agree, if you ever need a rollback passed a sensible limit, you're kind of screwed. But it seems to me that you're screwed whether or not you limit the rollback. You can now have two perfectly functioning clients with the same information who disagree on the which set of blocks is valid.

I would say it makes sense to detect that a very large rollback would normally occur. But as for what you do in that case, I can't see not rolling back as being right. Perhaps prevent further operation until humans can decide what to do.

[Kupsi]

I believe the problems with limiting (automatic) rollback to 120 blocks is smaller than the possible problem with a government building a lot of ASICs, making blocks in the dark and release them to the network after a long time. This could kill Bitcoin.

Say you limit rollback. Say about half the network watched chain X unfold and it's the longest chain. And say half the network is on chain Y and would need a rollback past the limit to get to chain X. Isn't it true that both chains are now equally correct by the rules? I'm not so sure it's such a good idea to introduce path dependence to a network that can't even remotely guarantee that all nodes take the same path.

I agree, if you ever need a rollback passed a sensible limit, you're kind of screwed. But it seems to me that you're screwed whether or not you limit the rollback. You can now have two perfectly functioning clients with the same information who disagree on the which set of blocks is valid.

I would say it makes sense to detect that a very large rollback would normally occur. But as for what you do in that case, I can't see not rolling back as being right. Perhaps prevent further operation until humans can decide what to do.

So let's find the sensible limit and use that. If we set the limit at 288 blocks, we would have about 96 hours to merge the network again if there was a 50 / 50 split. I don't think we ever will have a network split larger than 96 hours with exactly 50 / 50 share on both sides. If the network merged again after 96 hours, and one side have made more blocks than the other side, miners would jump to the largest blockchain and the small one will die.

[DannyHamilton]

If the network merged again after 96 hours, and one side have made more blocks than the other side, miners would jump to the largest blockchain and the small one will die.

How could they do this if there was a limit.  Wouldn't the limit prevent those on the shorter chain from being rolled back to ump to the longer chain?

[SgtSpike]

I believe the problems with limiting (automatic) rollback to 120 blocks is smaller than the possible problem with a government building a lot of ASICs, making blocks in the dark and release them to the network after a long time. This could kill Bitcoin.

Say you limit rollback. Say about half the network watched chain X unfold and it's the longest chain. And say half the network is on chain Y and would need a rollback past the limit to get to chain X. Isn't it true that both chains are now equally correct by the rules? I'm not so sure it's such a good idea to introduce path dependence to a network that can't even remotely guarantee that all nodes take the same path.

I agree, if you ever need a rollback passed a sensible limit, you're kind of screwed. But it seems to me that you're screwed whether or not you limit the rollback. You can now have two perfectly functioning clients with the same information who disagree on the which set of blocks is valid.

I would say it makes sense to detect that a very large rollback would normally occur. But as for what you do in that case, I can't see not rolling back as being right. Perhaps prevent further operation until humans can decide what to do.

So let's find the sensible limit and use that. If we set the limit at 288 blocks, we would have about 96 hours to merge the network again if there was a 50 / 50 split. I don't think we ever will have a network split larger than 96 hours with exactly 50 / 50 share on both sides. If the network merged again after 96 hours, and one side have made more blocks than the other side, miners would jump to the largest blockchain and the small one will die.

Isn't this the very definition of a "rollback"?  Miners always jump to the longest chain.

[Kupsi]

If the network merged again after 96 hours, and one side have made more blocks than the other side, miners would jump to the largest blockchain and the small one will die.

How could they do this if there was a limit.  Wouldn't the limit prevent those on the shorter chain from being rolled back to ump to the longer chain?

They will manually delete the x last blocks and download the longest chain.

[Kupsi]

I believe the problems with limiting (automatic) rollback to 120 blocks is smaller than the possible problem with a government building a lot of ASICs, making blocks in the dark and release them to the network after a long time. This could kill Bitcoin.

Say you limit rollback. Say about half the network watched chain X unfold and it's the longest chain. And say half the network is on chain Y and would need a rollback past the limit to get to chain X. Isn't it true that both chains are now equally correct by the rules? I'm not so sure it's such a good idea to introduce path dependence to a network that can't even remotely guarantee that all nodes take the same path.

I agree, if you ever need a rollback passed a sensible limit, you're kind of screwed. But it seems to me that you're screwed whether or not you limit the rollback. You can now have two perfectly functioning clients with the same information who disagree on the which set of blocks is valid.

I would say it makes sense to detect that a very large rollback would normally occur. But as for what you do in that case, I can't see not rolling back as being right. Perhaps prevent further operation until humans can decide what to do.

So let's find the sensible limit and use that. If we set the limit at 288 blocks, we would have about 96 hours to merge the network again if there was a 50 / 50 split. I don't think we ever will have a network split larger than 96 hours with exactly 50 / 50 share on both sides. If the network merged again after 96 hours, and one side have made more blocks than the other side, miners would jump to the largest blockchain and the small one will die.

Isn't this the very definition of a "rollback"?  Miners always jump to the longest chain.

If they manually need to jump to the longest chain, if it's more than x number of blocks to roll back, we are much better protected against a hostile attack.

[SgtSpike]

I believe the problems with limiting (automatic) rollback to 120 blocks is smaller than the possible problem with a government building a lot of ASICs, making blocks in the dark and release them to the network after a long time. This could kill Bitcoin.

Say you limit rollback. Say about half the network watched chain X unfold and it's the longest chain. And say half the network is on chain Y and would need a rollback past the limit to get to chain X. Isn't it true that both chains are now equally correct by the rules? I'm not so sure it's such a good idea to introduce path dependence to a network that can't even remotely guarantee that all nodes take the same path.

I agree, if you ever need a rollback passed a sensible limit, you're kind of screwed. But it seems to me that you're screwed whether or not you limit the rollback. You can now have two perfectly functioning clients with the same information who disagree on the which set of blocks is valid.

I would say it makes sense to detect that a very large rollback would normally occur. But as for what you do in that case, I can't see not rolling back as being right. Perhaps prevent further operation until humans can decide what to do.

So let's find the sensible limit and use that. If we set the limit at 288 blocks, we would have about 96 hours to merge the network again if there was a 50 / 50 split. I don't think we ever will have a network split larger than 96 hours with exactly 50 / 50 share on both sides. If the network merged again after 96 hours, and one side have made more blocks than the other side, miners would jump to the largest blockchain and the small one will die.

Isn't this the very definition of a "rollback"?  Miners always jump to the longest chain.

If they manually need to jump to the longest chain, if it's more than x number of blocks to roll back, we are much better protected against a hostile attack.

How would mining software know which chain is legitimate and which chain is not?  How would mining software look at a brand new block and say "oh, hey, this one's not legit!"?

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?

[DeathAndTaxes]

Exactly this is a non-trivial problem.  If it was trivial there would be no 51% attack.  Another issue becomes what happens when part of the network believes X chain is correct and part believe Y chain is correct.  Of course some people have legit transactions on X and some have legit transactions on Y and there is a double spend by the attacker on both (thus someone always loses) how are you going to convince everyone that "X" (or "Y") is the correct chain and everyone should jump to it.

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

[Kupsi]

I believe the problems with limiting (automatic) rollback to 120 blocks is smaller than the possible problem with a government building a lot of ASICs, making blocks in the dark and release them to the network after a long time. This could kill Bitcoin.

Say you limit rollback. Say about half the network watched chain X unfold and it's the longest chain. And say half the network is on chain Y and would need a rollback past the limit to get to chain X. Isn't it true that both chains are now equally correct by the rules? I'm not so sure it's such a good idea to introduce path dependence to a network that can't even remotely guarantee that all nodes take the same path.

I agree, if you ever need a rollback passed a sensible limit, you're kind of screwed. But it seems to me that you're screwed whether or not you limit the rollback. You can now have two perfectly functioning clients with the same information who disagree on the which set of blocks is valid.

I would say it makes sense to detect that a very large rollback would normally occur. But as for what you do in that case, I can't see not rolling back as being right. Perhaps prevent further operation until humans can decide what to do.

So let's find the sensible limit and use that. If we set the limit at 288 blocks, we would have about 96 hours to merge the network again if there was a 50 / 50 split. I don't think we ever will have a network split larger than 96 hours with exactly 50 / 50 share on both sides. If the network merged again after 96 hours, and one side have made more blocks than the other side, miners would jump to the largest blockchain and the small one will die.

Isn't this the very definition of a "rollback"?  Miners always jump to the longest chain.

If they manually need to jump to the longest chain, if it's more than x number of blocks to roll back, we are much better protected against a hostile attack.

How would mining software know which chain is legitimate and which chain is not?  How would mining software look at a brand new block and say "oh, hey, this one's not legit!"?

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?

A human will know it.

[SgtSpike]

I believe the problems with limiting (automatic) rollback to 120 blocks is smaller than the possible problem with a government building a lot of ASICs, making blocks in the dark and release them to the network after a long time. This could kill Bitcoin.

Say you limit rollback. Say about half the network watched chain X unfold and it's the longest chain. And say half the network is on chain Y and would need a rollback past the limit to get to chain X. Isn't it true that both chains are now equally correct by the rules? I'm not so sure it's such a good idea to introduce path dependence to a network that can't even remotely guarantee that all nodes take the same path.

I agree, if you ever need a rollback passed a sensible limit, you're kind of screwed. But it seems to me that you're screwed whether or not you limit the rollback. You can now have two perfectly functioning clients with the same information who disagree on the which set of blocks is valid.

I would say it makes sense to detect that a very large rollback would normally occur. But as for what you do in that case, I can't see not rolling back as being right. Perhaps prevent further operation until humans can decide what to do.

So let's find the sensible limit and use that. If we set the limit at 288 blocks, we would have about 96 hours to merge the network again if there was a 50 / 50 split. I don't think we ever will have a network split larger than 96 hours with exactly 50 / 50 share on both sides. If the network merged again after 96 hours, and one side have made more blocks than the other side, miners would jump to the largest blockchain and the small one will die.

Isn't this the very definition of a "rollback"?  Miners always jump to the longest chain.

If they manually need to jump to the longest chain, if it's more than x number of blocks to roll back, we are much better protected against a hostile attack.

How would mining software know which chain is legitimate and which chain is not?  How would mining software look at a brand new block and say "oh, hey, this one's not legit!"?

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?

A human will know it.

How will a human know it?

[Kupsi]

Exactly this is a non-trivial problem.  If it was trivial there would be no 51% attack.  Another issue becomes what happens when part of the network believes X chain is correct and part believe Y chain is correct.  Of course some people have legit transactions on X and some have legit transactions on Y and there is a double spend by the attacker on both (thus someone always loses) how are you going to convince everyone that "X" (or "Y") is the correct chain and everyone should jump to it.

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

This isn't to protect against double spends. It's for protecting against a government building a new blockchain for months and release it, killing Bitcoin.

[Kupsi]

I believe the problems with limiting (automatic) rollback to 120 blocks is smaller than the possible problem with a government building a lot of ASICs, making blocks in the dark and release them to the network after a long time. This could kill Bitcoin.

Say you limit rollback. Say about half the network watched chain X unfold and it's the longest chain. And say half the network is on chain Y and would need a rollback past the limit to get to chain X. Isn't it true that both chains are now equally correct by the rules? I'm not so sure it's such a good idea to introduce path dependence to a network that can't even remotely guarantee that all nodes take the same path.

I agree, if you ever need a rollback passed a sensible limit, you're kind of screwed. But it seems to me that you're screwed whether or not you limit the rollback. You can now have two perfectly functioning clients with the same information who disagree on the which set of blocks is valid.

I would say it makes sense to detect that a very large rollback would normally occur. But as for what you do in that case, I can't see not rolling back as being right. Perhaps prevent further operation until humans can decide what to do.

So let's find the sensible limit and use that. If we set the limit at 288 blocks, we would have about 96 hours to merge the network again if there was a 50 / 50 split. I don't think we ever will have a network split larger than 96 hours with exactly 50 / 50 share on both sides. If the network merged again after 96 hours, and one side have made more blocks than the other side, miners would jump to the largest blockchain and the small one will die.

Isn't this the very definition of a "rollback"?  Miners always jump to the longest chain.

If they manually need to jump to the longest chain, if it's more than x number of blocks to roll back, we are much better protected against a hostile attack.

How would mining software know which chain is legitimate and which chain is not?  How would mining software look at a brand new block and say "oh, hey, this one's not legit!"?

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?

A human will know it.

How will a human know it?

Because it has most users, and have been public in contrast to the new blockchain suddenly showing up.

[SgtSpike]

Exactly this is a non-trivial problem.  If it was trivial there would be no 51% attack.  Another issue becomes what happens when part of the network believes X chain is correct and part believe Y chain is correct.  Of course some people have legit transactions on X and some have legit transactions on Y and there is a double spend by the attacker on both (thus someone always loses) how are you going to convince everyone that "X" (or "Y") is the correct chain and everyone should jump to it.

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

This isn't to protect against double spends. It's for protecting against a government building a new blockchain for months and release it, killing Bitcoin.

Ok, let's build off of that scenario.

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.

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?

[Kupsi]

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.