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. 
Topic: Blockchain rollback limit? - page 2. (Read 4772 times)
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.
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.
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?
Quote
The last legitimate block is already gone.
Don't underestimate people backuping the chain. 
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.
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.
No it is better to come up with a solution which provides real security not feel good security. Like I said up thread.
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.
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.
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?
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.
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.
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.
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.
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 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?
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.
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 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.
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.
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.
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 doesn't mean it is impossible but if your first thought is "oh this is easy just do ..." then you are likely wrong.
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?
Jump to: