|
Title: Blockchain rollback limit? Post by: Kupsi on February 02, 2013, 01:07:23 PM 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. Title: Re: Blockchain rollback limit? Post by: DannyHamilton on February 02, 2013, 02:05:51 PM 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.Title: Re: Blockchain rollback limit? Post by: kjj on February 02, 2013, 02:22:23 PM 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. Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 06:35:15 PM 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. Title: Re: Blockchain rollback limit? Post by: Gabi on February 05, 2013, 07:31:26 PM 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" ;) Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 07:43:36 PM 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! Title: Re: Blockchain rollback limit? Post by: JoelKatz on February 05, 2013, 07:47:39 PM 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. Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 08:14:18 PM 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. Title: Re: Blockchain rollback limit? Post by: DannyHamilton on February 05, 2013, 08:16:42 PM 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?Title: Re: Blockchain rollback limit? Post by: SgtSpike on February 05, 2013, 08:22:15 PM 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. Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 08:24:02 PM 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. Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 08:26:15 PM 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. 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. Title: Re: Blockchain rollback limit? Post by: SgtSpike on February 05, 2013, 08:30:14 PM 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. 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. 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? Title: Re: Blockchain rollback limit? Post by: DeathAndTaxes on February 05, 2013, 08:35:53 PM 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. Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 08:37:36 PM 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. 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. 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. Title: Re: Blockchain rollback limit? Post by: SgtSpike on February 05, 2013, 08:38:16 PM 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. 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. 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. Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 08:39:29 PM 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. Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 08:42:04 PM 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. 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. 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. Because it has most users, and have been public in contrast to the new blockchain suddenly showing up. Title: Re: Blockchain rollback limit? Post by: SgtSpike on February 05, 2013, 08:43:00 PM 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. 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? Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 08:51:48 PM 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. Title: Re: Blockchain rollback limit? Post by: SgtSpike on February 05, 2013, 08:56:54 PM 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. Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 09:05:49 PM 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. Title: Re: Blockchain rollback limit? Post by: DeathAndTaxes on February 05, 2013, 09:16:59 PM 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.
Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 09:29:42 PM 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? Title: Re: Blockchain rollback limit? Post by: DeathAndTaxes on February 05, 2013, 09:35:29 PM No it is better to come up with a solution which provides real security not feel good security. Like I said up thread.
Quote 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. Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 10:01:45 PM 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. Title: Re: Blockchain rollback limit? Post by: DeathAndTaxes on February 05, 2013, 10:03:33 PM 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.
Title: Re: Blockchain rollback limit? Post by: Gabi on February 05, 2013, 10:07:13 PM Quote The last legitimate block is already gone. Don't underestimate people backuping the chain. Title: Re: Blockchain rollback limit? Post by: Kupsi on February 05, 2013, 10:12:04 PM 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? Title: Re: Blockchain rollback limit? Post by: JoelKatz on February 05, 2013, 10:27:25 PM 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. Title: Re: Blockchain rollback limit? Post by: Gabi on February 05, 2013, 10:30:24 PM 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.
Title: Re: Blockchain rollback limit? Post by: JoelKatz on February 05, 2013, 11:29:27 PM 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.Title: Re: Blockchain rollback limit? Post by: DeathAndTaxes on February 05, 2013, 11:57:38 PM 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. Title: Re: Blockchain rollback limit? Post by: Matthew N. Wright on February 06, 2013, 12:07:25 AM Could you just run 2 clients using different chains and live in both worlds?
Title: Re: Blockchain rollback limit? Post by: Kupsi on February 06, 2013, 12:17:16 AM 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... Title: Re: Blockchain rollback limit? Post by: JoelKatz on February 06, 2013, 12:17:56 AM 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!Title: Re: Blockchain rollback limit? Post by: Matthew N. Wright on February 06, 2013, 12:18:23 AM 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! Title: Re: Blockchain rollback limit? Post by: Qoheleth on February 06, 2013, 12:20:46 AM 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.Title: Re: Blockchain rollback limit? Post by: Kupsi on February 06, 2013, 12:23:06 AM 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. Title: Re: Blockchain rollback limit? Post by: Matthew N. Wright on February 06, 2013, 12:23:14 AM 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. Title: Re: Blockchain rollback limit? Post by: Qoheleth on February 06, 2013, 12:26:47 AM 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... How easy is there for an attacker to keep the forks separated from each other for days so they get past the "rollback limit"? That would be hard to manage. They have more hashing power than the rest of the network put together, or they couldn't execute a 51% attack to begin with. Thus, by definition, they can mine in parallel with the rest of the network and keep up. So however many branches exist with someone else mining on them, this adversary is able to equally mine a branch of it.Title: Re: Blockchain rollback limit? Post by: DannyHamilton on February 06, 2013, 12:36:28 AM I suspect that there is a reason that none of the many attempts to create a crypto-currency succeeded until Satoshi put together the idea of a proof-of-work transaction ledger. Attempting to short-circuit this solution simply results in a currency that becomes more and more like the many that failed in the past, and more and more likely to fail for the same reasons. There is enough risk with the checkpoints that are already coded into the clients. Trying to create a moving checkpoint that tries to actively keep up with the blockchain as it grows sounds like a disaster to me. If it was implemented, I'd probably abandon bitcoin and look for something else.
Title: Re: Blockchain rollback limit? Post by: Matthew N. Wright on February 06, 2013, 12:37:22 AM I'd probably abandon bitcoin and look for something else. (Start by getting into Ripple just in case!)Title: Re: Blockchain rollback limit? Post by: Kupsi on February 06, 2013, 12:37:39 AM 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... User base... fewest users. Sorry for my bad English. What I'm suggesting isn't perfect. But if you set the rollback limit big enough, it can't be worse than how it is today. How easy is there for an attacker to keep the forks separated from each other for days so they get past the "rollback limit"? That would be hard to manage. They have more hashing power than the rest of the network put together, or they couldn't execute a 51% attack to begin with. Thus, by definition, they can mine in parallel with the rest of the network and keep up. So however many branches exist with someone else mining on them, this adversary is able to equally mine a branch of it.They need a decent percent of the users on each fork if they shall succeed. Title: Re: Blockchain rollback limit? Post by: Qoheleth on February 06, 2013, 12:44:15 AM User base... fewest users. Sorry for my bad English. How do you tell how many users are using a particular fork?What I'm suggesting isn't perfect. But if you set the rollback limit big enough, it can't be worse than how it is today. Title: Re: Blockchain rollback limit? Post by: Kupsi on February 06, 2013, 12:46:25 AM I suspect that there is a reason that none of the many attempts to create a crypto-currency succeeded until Satoshi put together the idea of a proof-of-work transaction ledger. Attempting to short-circuit this solution simply results in a currency that becomes more and more like the many that failed in the past, and more and more likely to fail for the same reasons. There is enough risk with the checkpoints that are already coded into the clients. Trying to create a moving checkpoint that tries to actively keep up with the blockchain as it grows sounds like a disaster to me. If it was implemented, I'd probably abandon bitcoin and look for something else. So, if I change my client so it does this, would you abandon bitcoin? No one can stop me ;) Title: Re: Blockchain rollback limit? Post by: DannyHamilton on February 06, 2013, 12:49:17 AM I suspect that there is a reason that none of the many attempts to create a crypto-currency succeeded until Satoshi put together the idea of a proof-of-work transaction ledger. Attempting to short-circuit this solution simply results in a currency that becomes more and more like the many that failed in the past, and more and more likely to fail for the same reasons. There is enough risk with the checkpoints that are already coded into the clients. Trying to create a moving checkpoint that tries to actively keep up with the blockchain as it grows sounds like a disaster to me. If it was implemented, I'd probably abandon bitcoin and look for something else. So, if I change my client so it does this, would you abandon bitcoin? No one can stop me ;) Title: Re: Blockchain rollback limit? Post by: Kupsi on February 06, 2013, 12:50:42 AM I suspect that there is a reason that none of the many attempts to create a crypto-currency succeeded until Satoshi put together the idea of a proof-of-work transaction ledger. Attempting to short-circuit this solution simply results in a currency that becomes more and more like the many that failed in the past, and more and more likely to fail for the same reasons. There is enough risk with the checkpoints that are already coded into the clients. Trying to create a moving checkpoint that tries to actively keep up with the blockchain as it grows sounds like a disaster to me. If it was implemented, I'd probably abandon bitcoin and look for something else. So, if I change my client so it does this, would you abandon bitcoin? No one can stop me ;) When the original blockchain is rolled back 12 months, people will jump over to my blockchain :D Title: Re: Blockchain rollback limit? Post by: Kupsi on February 06, 2013, 12:52:22 AM User base... fewest users. Sorry for my bad English. How do you tell how many users are using a particular fork?What I'm suggesting isn't perfect. But if you set the rollback limit big enough, it can't be worse than how it is today. Time will tell... (Time to go to bed.) Title: Re: Blockchain rollback limit? Post by: pointbiz on February 06, 2013, 01:08:08 PM You have not properly stated what would happen during the rollback. Let me explain.
Your scenario involves the good chain and a bad chain. The good chain is the one that manually gets checkpoints in the Satoshi client. Checkpointing is not part of the Satoshi white paper. It is just a way for the devs to tell us what chain they use and to put a limit (like u r demanding) on a rollback. It goes against the theory and is only not controversial because Satoshi went along with it. During a rollback that goes back to the last Gavin checkpoint the attacker with the bad chain can only double spend coins that he owned before Gavin's checkpoint. He can also exclude everyone's transactions from the block chain that happened since the chechpoint. Or maybe he won't exclude people's transactions therefore most won't care which chain is good or bad. Let's assume this is a none monetary attacker where the goal is to discredit Bitcoin. So we will assume he has excluded ever transaction he doesn't own. Every node on the network will still know about these transactions they will just become unconfirmed... that is the WORST case scenario. Once the attack is over those transactions can be reconfirmed. Also everyone will still have the shorter good chain on disk it is not like it would be deleted. Title: Re: Blockchain rollback limit? Post by: JoelKatz on February 06, 2013, 01:23:08 PM During a rollback that goes back to the last Gavin checkpoint the attacker with the bad chain can only double spend coins that he owned before Gavin's checkpoint. He can also exclude everyone's transactions from the block chain that happened since the chechpoint. Or maybe he won't exclude people's transactions therefore most won't care which chain is good or bad. Let's assume this is a none monetary attacker where the goal is to discredit Bitcoin. So we will assume he has excluded ever transaction he doesn't own. Every node on the network will still know about these transactions they will just become unconfirmed... that is the WORST case scenario. Once the attack is over those transactions can be reconfirmed. Also everyone will still have the shorter good chain on disk it is not like it would be deleted. You're assuming an attacker trying to discredit Bitcoin who doesn't actually do anything to discredit Bitcoin!A realistic attacker would deposit a large number of Bitcoins to Mt. Gox and then wait. When he introduces his own rollback chain, it will include a double spend of that deposit to Mt. Gox. This will invalidate all transactions that re-spend those coins, all transactions that re-spend outputs of transactions that spend those coins, and so on. With just a bit of effort, he can invalidate a significant fraction of the transactions that occurred in that time period. He could probably invalidate more than half of them with moderate effort. He doesn't even need a lot of money to do this. He can deposit, withdraw different coins, and deposit again. He can then double spend both of those deposits, doing double damage with the same coins. (Assuming that double-spending his first deposit doesn't contaminate his own withdrawal. But if it does, then he's already doing major damage.) Title: Re: Blockchain rollback limit? Post by: Kupsi on February 06, 2013, 08:16:04 PM During a rollback that goes back to the last Gavin checkpoint the attacker with the bad chain can only double spend coins that he owned before Gavin's checkpoint. He can also exclude everyone's transactions from the block chain that happened since the chechpoint. Or maybe he won't exclude people's transactions therefore most won't care which chain is good or bad. Let's assume this is a none monetary attacker where the goal is to discredit Bitcoin. So we will assume he has excluded ever transaction he doesn't own. Every node on the network will still know about these transactions they will just become unconfirmed... that is the WORST case scenario. Once the attack is over those transactions can be reconfirmed. Also everyone will still have the shorter good chain on disk it is not like it would be deleted. You're assuming an attacker trying to discredit Bitcoin who doesn't actually do anything to discredit Bitcoin!A realistic attacker would deposit a large number of Bitcoins to Mt. Gox and then wait. When he introduces his own rollback chain, it will include a double spend of that deposit to Mt. Gox. This will invalidate all transactions that re-spend those coins, all transactions that re-spend outputs of transactions that spend those coins, and so on. With just a bit of effort, he can invalidate a significant fraction of the transactions that occurred in that time period. He could probably invalidate more than half of them with moderate effort. He doesn't even need a lot of money to do this. He can deposit, withdraw different coins, and deposit again. He can then double spend both of those deposits, doing double damage with the same coins. (Assuming that double-spending his first deposit doesn't contaminate his own withdrawal. But if it does, then he's already doing major damage.) An attacker don't need to do a double spend with his own coins. All mined coins from the rolled back blocks will disappear, making all transaction that can be traced back to these coins invalid. |