Alternative algorithms for accepting deep block-chain re-orgs sound like a research project to me. Before changing something that critical I would like to see simulations of how different re-org policies behave under different attack scenarios, and non-attack "what if there is a bug that causes an inadvertent block chain split" scenarios.
And I'd like to see a whitepaper that lays out the issues and summarizes simulation results. And lots of extra credit if it gets peer-reviewed and published in one of the IEEE or ACM journals.
Topic: BitCoin Deanonymization (Read 13157 times)
It would be a good idea for the client to enter safe mode when it sees a deep reorg, but it still must switch chains. Otherwise the network can become permanently segmented, and an attacker that gets control for some time can keep control much more easily. Keep in mind that it is not impossibly expensive to take control of the network for several weeks.
I don't understand this argument...if an attacker successfully generated a few blocks in succession, one of their blocks would indeed become old enough that it is permanently embedded...but so what? Even if the attacker had 70 or 80% of the processing power, they could only force reorgs say 6 blocks deep...or ~1 hour into the past...and blocks from other miners would still beat out the attacker on occasion (rendering ineffective an attack where legitimate transactions were being ignored). If this was pervasively happening for some period of time, people could simply start waiting a full 6 (assuming 6 is the point where reorgs are only allowed manually) transactions when dealing with untrusted people (but you could still safely accept transactions immediately when dealing with a counterparty that is trusted). 
My first thought was an alert message. Presumably Satoshi had the exact same idea years ago.
The maintainers could generate a key pair for each release, with the public key embedded in each client. If a critical bug is found in some client, the maintainer signs a message telling the node to notify the operator. If the message is informational only, and has some anti-spam provisions (embed the message in a transaction sig?), it should be pretty widely accepted by the community. Each node operator then has the choice of how they want to handle the message.
If I was running a store, and the devs found a critical bug that made my client unreliable, I would set up a handler that disabled my store first, and paged me second. Operators that ignored the messages would do so at their peril. Having a deep reorg trigger the same exception handler would be good too.
Theymos is right that having a higher barrier for deep reorgs would allow an attacker to maintain control over some nodes for a longer time (or forever), but under my scenario, those are the nodes with careless operators, which is their own fault. I'm all in favor of protecting all nodes, even those with careless operators, when it happens for free. But I'd throw half of the network under the bus if it made the remaining half twice as secure. Hell, I'm almost at the point where I'd be willing to do it just to stop all of the "51%" threads here.
The maintainers could generate a key pair for each release, with the public key embedded in each client. If a critical bug is found in some client, the maintainer signs a message telling the node to notify the operator. If the message is informational only, and has some anti-spam provisions (embed the message in a transaction sig?), it should be pretty widely accepted by the community. Each node operator then has the choice of how they want to handle the message.
If I was running a store, and the devs found a critical bug that made my client unreliable, I would set up a handler that disabled my store first, and paged me second. Operators that ignored the messages would do so at their peril. Having a deep reorg trigger the same exception handler would be good too.
Theymos is right that having a higher barrier for deep reorgs would allow an attacker to maintain control over some nodes for a longer time (or forever), but under my scenario, those are the nodes with careless operators, which is their own fault. I'm all in favor of protecting all nodes, even those with careless operators, when it happens for free. But I'd throw half of the network under the bus if it made the remaining half twice as secure. Hell, I'm almost at the point where I'd be willing to do it just to stop all of the "51%" threads here.
It would be a good idea for the client to enter safe mode when it sees a deep reorg, but it still must switch chains. Otherwise the network can become permanently segmented, and an attacker that gets control for some time can keep control much more easily. Keep in mind that it is not impossibly expensive to take control of the network for several weeks.
The longest reorg I'm aware of was 25 blocks. Someone correct me if I missed one.
The one after the overflow bug was 54 blocks. If all old clients had ignored the longer chain because the split was too far back, then lots of damage could have been done by the attacker.I'm not sure that is a good argument here.
While the current reorg logic was certainly a boon in that situation, and future situations like it are easy to imagine, we should recognize that we are overloading that operation to do something that it wasn't intended to do.
Maybe we should think of a proper mechanism to deal with nodes that are known to have critical bugs, and allow the block chain logic to concentrate on protecting the chain.
The longest reorg I'm aware of was 25 blocks. Someone correct me if I missed one.
The one after the overflow bug was 54 blocks. If all old clients had ignored the longer chain because the split was too far back, then lots of damage could have been done by the attacker.I'm not sure that is a good argument here.
While the current reorg logic was certainly a boon in that situation, and future situations like it are easy to imagine, we should recognize that we are overloading that operation to do something that it wasn't intended to do.
Maybe we should think of a proper mechanism to deal with nodes that are known to have critical bugs, and allow the block chain logic to concentrate on protecting the chain.
The longest reorg I'm aware of was 25 blocks. Someone correct me if I missed one.
The one after the overflow bug was 54 blocks. If all old clients had ignored the longer chain because the split was too far back, then lots of damage could have been done by the attacker.
In that case, I wouldn't really be comfortable with automatically locking the chain at less than, say, 5000 blocks.
The longest reorg I'm aware of was 25 blocks. Someone correct me if I missed one.
The one after the overflow bug was 54 blocks. If all old clients had ignored the longer chain because the split was too far back, then lots of damage could have been done by the attacker.
The longest reorg I'm aware of was 25 blocks. Someone correct me if I missed one.
The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks. Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background. The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.
Yeah, but what makes me nervous is that someone with that kind of power could lay in wait for an indefinite period of time...spending whatever it takes to remain substantially ahead of the network...waiting for the most opportune time to reveal themselves and completely undermine bitcoin.
The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks. Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background. The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.
Yeah, but what makes me nervous is that someone with that kind of power could lay in wait for an indefinite period of time...spending whatever it takes to remain substantially ahead of the network...waiting for the most opportune time to reveal themselves and completely undermine bitcoin.That could cause a pretty big chaos, but is no real danger of cheating.
The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks. Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background. The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.
Yeah, but what makes me nervous is that someone with that kind of power could lay in wait for an indefinite period of time...spending whatever it takes to remain substantially ahead of the network...waiting for the most opportune time to reveal themselves and completely undermine bitcoin.That is one of the reasons why the Satoshi Client includes hardcoded block chain checkpoints.
The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks. Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background. The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.
Yeah, but what makes me nervous is that someone with that kind of power could lay in wait for an indefinite period of time...spending whatever it takes to remain substantially ahead of the network...waiting for the most opportune time to reveal themselves and completely undermine bitcoin. The 50% mark is not really a tipping point, as you can still get left behind in many potential attacks. Percentage of network power just means are you ever-more-likely to be able to double-spend while waiting with a chain of length X in the background. The attack is still very, very difficult and reliant upon probability even at 60%, 70%, etc.
I'm going to sound like the guy you see on TV that's portrayed to be crazy on TV because of his fear of government. Well ever since I learned how our monetary system worked and researched the truth about governments I personally know without a doubt that deanonymization is a bad thing.
Just my 2 bit cents that I don't believe anyone will listen to just like when I started telling all my friends and family how the monetary system works. They are slowly starting to listen as things get worse and worse. So why go down a path that has been historically BAD!
Just my 2 bit cents that I don't believe anyone will listen to just like when I started telling all my friends and family how the monetary system works. They are slowly starting to listen as things get worse and worse. So why go down a path that has been historically BAD!
And yes, resolving a permanent split would require human intervention. Essentially, the minority network would be forced to discard all blocks since the split if they wanted to rejoin the global network. Personally, I think the potential cost to individual miners and nodes is a small price to pay to protect the network as a whole.
Agreed. The other attack is the offline attack, where the attacker does not publish his blocks until his chain is at least X blocks longer than the public chain. In this attack, 51% is indeed a tipping point, because once he reaches 51% he is assured that if he waits long enough, he will eventually have enough blocks saved up to perform the chain reversion.
But this attack is so easy to detect that it makes no sense to try it.You mean like everyone would notice if 7 blocks get swapped all at once? Yeah, we would notice, but they would be the correct chain then, so what would we do about it?
Sell their bitcoins!!!
Quote from: kjj
This attack can be countered by changing the calculation for deciding which chain is valid. An exponential function would solve the problem.
Interesting idea. IIUC, this makes it such that the deeper the reorg, the higher the barrier for it to be accepted. Which means that you effectively force the >51% attacker out into the open (they have to publish their blocks or their private chain will quickly become virtually impossible to get accepted) and basically force them to periodically build off of other's blocks...and you effectively require miners (and all nodes really) to take steps to ensure blocks get widely distributed. However, if there is a temporary split in the network, doesn't this run the risk of a temporary split becoming permanent? I suppose you could come up with a non technical means of resolving such a split should it ever occur...it might be an acceptable trade off considering that this proposal might have a huge benefit (in the sense that it would severely inhibit the damage that could be done by a miner with >50% could do). Yup, you understand correctly. If you require reorgs with more than X (six might be a good value for X) blocks to require 2^(Y-X) difference in difficulty, a recipient can wait 12 blocks and know that unless the attacker has 64 times more power than the rest of the world, the transaction won't be reversed. Or they can wait 26 blocks and know that an attacker would need more than a million times as much. After a day, I would be pretty confident that not even ET could reverse it.
The risk of splits isn't as great as you might imagine. If the network was cut in half (weighted by hashing power), we would have about 2 hours to notice the problem and fix it. If the network was cut 90/10, we would have 10 hours. The less even the network break, the more time we have until it becomes a problem, and also the less effort will be needed to fix it.
And yes, resolving a permanent split would require human intervention. Essentially, the minority network would be forced to discard all blocks since the split if they wanted to rejoin the global network. Personally, I think the potential cost to individual miners and nodes is a small price to pay to protect the network as a whole.
The other attack is the offline attack, where the attacker does not publish his blocks until his chain is at least X blocks longer than the public chain. In this attack, 51% is indeed a tipping point, because once he reaches 51% he is assured that if he waits long enough, he will eventually have enough blocks saved up to perform the chain reversion.
But this attack is so easy to detect that it makes no sense to try it.You mean like everyone would notice if 7 blocks get swapped all at once? Yeah, we would notice, but they would be the correct chain then, so what would we do about it?
Sell their bitcoins!!!
Quote from: kjj
This attack can be countered by changing the calculation for deciding which chain is valid. An exponential function would solve the problem.
Interesting idea. IIUC, this makes it such that the deeper the reorg, the higher the barrier for it to be accepted. Which means that you effectively force the >51% attacker out into the open (they have to publish their blocks or their private chain will quickly become virtually impossible to get accepted) and basically force them to periodically build off of other's blocks...and you effectively require miners (and all nodes really) to take steps to ensure blocks get widely distributed. However, if there is a temporary split in the network, doesn't this run the risk of a temporary split becoming permanent? I suppose you could come up with a non technical means of resolving such a split should it ever occur...it might be an acceptable trade off considering that this proposal might have a huge benefit (in the sense that it would severely inhibit the damage that could be done by a miner with >50% could do). You mean like everyone would notice if 7 blocks get swapped all at once? Yeah, we would notice, but they would be the correct chain then, so what would we do about it?
+1 would be nice to know
Blockchain correction already happened:
https://en.bitcoin.it/wiki/Incidents#Value_overflow
The other attack is the offline attack, where the attacker does not publish his blocks until his chain is at least X blocks longer than the public chain. In this attack, 51% is indeed a tipping point, because once he reaches 51% he is assured that if he waits long enough, he will eventually have enough blocks saved up to perform the chain reversion.
But this attack is so easy to detect that it makes no sense to try it.You mean like everyone would notice if 7 blocks get swapped all at once? Yeah, we would notice, but they would be the correct chain then, so what would we do about it?
I didn't say that you can't. You can. But it is obvious. And you needed more computing power than the rest of the net - and can reverse transactions that are just "confirmed".
Jump to: