Bitcoin Forum
November 21, 2017, 10:08:22 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 »  All
  Print  
Author Topic: Blockchain rollback limit?  (Read 4442 times)
Kupsi
Legendary
*
Offline Offline

Activity: 1191


9.9.2012: I predict that single digits... <- FAIL


View Profile
February 02, 2013, 01:07:23 PM
 #1

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.
1511302102
Hero Member
*
Offline Offline

Posts: 1511302102

View Profile Personal Message (Offline)

Ignore
1511302102
Reply with quote  #2

1511302102
Report to moderator
1511302102
Hero Member
*
Offline Offline

Posts: 1511302102

View Profile Personal Message (Offline)

Ignore
1511302102
Reply with quote  #2

1511302102
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511302102
Hero Member
*
Offline Offline

Posts: 1511302102

View Profile Personal Message (Offline)

Ignore
1511302102
Reply with quote  #2

1511302102
Report to moderator
1511302102
Hero Member
*
Offline Offline

Posts: 1511302102

View Profile Personal Message (Offline)

Ignore
1511302102
Reply with quote  #2

1511302102
Report to moderator
DannyHamilton
Legendary
*
Offline Offline

Activity: 1988



View Profile
February 02, 2013, 02:05:51 PM
 #2

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
Legendary
*
Offline Offline

Activity: 1302



View Profile
February 02, 2013, 02:22:23 PM
 #3

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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Kupsi
Legendary
*
Offline Offline

Activity: 1191


9.9.2012: I predict that single digits... <- FAIL


View Profile
February 05, 2013, 06:35:15 PM
 #4

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
Legendary
*
Offline Offline

Activity: 1078


If you want to walk on water, get out of the boat


View Profile
February 05, 2013, 07:31:26 PM
 #5

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"  Wink
Kupsi
Legendary
*
Offline Offline

Activity: 1191


9.9.2012: I predict that single digits... <- FAIL


View Profile
February 05, 2013, 07:43:36 PM
 #6

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
Legendary
*
Offline Offline

Activity: 1582


Democracy is vulnerable to a 51% attack.


View Profile WWW
February 05, 2013, 07:47:39 PM
 #7

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.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Kupsi
Legendary
*
Offline Offline

Activity: 1191


9.9.2012: I predict that single digits... <- FAIL


View Profile
February 05, 2013, 08:14:18 PM
 #8

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
Legendary
*
Offline Offline

Activity: 1988



View Profile
February 05, 2013, 08:16:42 PM
 #9

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
Legendary
*
Offline Offline

Activity: 1358



View Profile
February 05, 2013, 08:22:15 PM
 #10

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
Legendary
*
Offline Offline

Activity: 1191


9.9.2012: I predict that single digits... <- FAIL


View Profile
February 05, 2013, 08:24:02 PM
 #11

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
Legendary
*
Offline Offline

Activity: 1191


9.9.2012: I predict that single digits... <- FAIL


View Profile
February 05, 2013, 08:26:15 PM
 #12

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
Legendary
*
Offline Offline

Activity: 1358



View Profile
February 05, 2013, 08:30:14 PM
 #13

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 05, 2013, 08:35:53 PM
 #14

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
Legendary
*
Offline Offline

Activity: 1191


9.9.2012: I predict that single digits... <- FAIL


View Profile
February 05, 2013, 08:37:36 PM
 #15

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
Legendary
*
Offline Offline

Activity: 1358



View Profile
February 05, 2013, 08:38:16 PM
 #16

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
Legendary
*
Offline Offline

Activity: 1191


9.9.2012: I predict that single digits... <- FAIL


View Profile
February 05, 2013, 08:39:29 PM
 #17

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
Legendary
*
Offline Offline

Activity: 1191


9.9.2012: I predict that single digits... <- FAIL


View Profile
February 05, 2013, 08:42:04 PM
 #18

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
Legendary
*
Offline Offline

Activity: 1358



View Profile
February 05, 2013, 08:43:00 PM
 #19

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
Legendary
*
Offline Offline

Activity: 1191


9.9.2012: I predict that single digits... <- FAIL


View Profile
February 05, 2013, 08:51:48 PM
 #20

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.
Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!