|
Title: proposal to reduce potential effects of majority miner attack Post by: kjj on May 27, 2011, 10:48:59 PM I'm a networking guy, so I propose that we use the term "chain flapping" or merely "flapping" to describe the phenomena evident when two long term competing branches are fighting for control of the chain. Look up route flapping, if you aren't familiar with the term already. In the case of an attacker with a lot of hashing power, since the attacker never has a 100% certain chance of getting their block out first, there will be times when an honest node will get a valid block out first, and the attacker will then have to publish multiple blocks to regain control. This is an inevitable result of this type of attack. I propose a countermeasure. Every time a node is forced to reshuffle because a side chain grows longer than the main chain, the peer that caused the shuffle is noted. If a third arrives within a certain timeframe, that link is considered to be flapping, and will be disconnected. This will have little effect on middle nodes, since on average they will only need to pass the block to a small fraction of their peers, and the remaining connections will not be closed. The attacker, however, will have to pass it to many peers, and will lose many connections. There is more, but I've gotta run. Gonna get drunk and watch game 7, but not necessarily in that order. Heh, I'm in such a hurry I haven't even had time to search on this. Hope I'm not rehashing something that was sorted out years ago. Quote from: kjj You would need not just 50% of the world's hashing power, but closer to 95%+ of it if you wanted to pull off any meaningful BTC scam. I don't think so. You can steal the vast majority of blocks from then on by storing up blocks you generate and release them only when someone else also solves one. Not sure if you consider that meaningful or not. (There was some long ago thread about this that I can't find now) You could double spend by getting one block ahead of the good network and then just stay ahead until you are ready to drop your one block longer chain.The time to find a block is not a linear function of your hashing speed, it is a probabilistic process. Having 10% more power than the other guy doesn't mean you find blocks 10% faster, it means that you have a ~5% chance of finding it before him. Say that you fraction of the global networking power is X, where 0 <= X <= 1; The probability that you will be able to do this for one block is X The probability that you will be able to do this for two blocks is X^2 The probability that you will be able to do this for three blocks is X^3 The probability that you will be able to do this for four blocks is X^4 Etc... Actually, those are the high end estimates. In reality, you will need another factor, Y, to correct for the portion of the network that believes in the attack chain. Over time, Y will get smaller and smaller. Since this topic keeps coming up over and over again, I'm going to propose a potential solution: every time a node reshuffles, they should make a note of which peer it came from. More than three reshuffles from the same peer in like 24 hours, and that node is dropped. Title: Re: proposal to reduce potential effects of majority miner attack Post by: goatpig on May 27, 2011, 10:56:31 PM Any attacker that has enough resources to have 50%+ of the network has enough resources have several entry points into the network. Being a node is really cheap compared to being providing hashing power.
The thing with public, anonymous distributed protocols is that you can trust nodes, but distrust is overall useless. This is why such systems are built to bypass the concept of trust altogether. Title: Re: proposal to reduce potential effects of majority miner attack Post by: markm on May 27, 2011, 10:58:09 PM Can''t the attacker constantly trawl the IRC-discovery channels looking for new nodes to connect to, and maybe even thereby never flap more than once at any specific node?
(Get 8 connections, flap at them, drop them, get 8 virgin nodes, flap at them, drop them, pick another 8, etc... ?) -MarkM- Title: Re: proposal to reduce potential effects of majority miner attack Post by: kjj on May 28, 2011, 03:15:56 PM The idea is not to kick them off the network. It is to make it harder to win block races.
If there is an honest disagreement about the block chain, the version that is believed by more nodes is likely to win eventually. That means that there is an advantage to being well connected. If you are intending to attack the chain, you will want to have as many connections as you can, to get as much of the network on your side as possible. This proposal makes it more difficult for an attacker to remain well connected. Not impossible, of course, just more difficult. Title: Re: proposal to reduce potential effects of majority miner attack Post by: gmaxwell on May 30, 2011, 11:17:27 AM The idea is not to kick them off the network. It is to make it harder to win block races. If there is an honest disagreement about the block chain, the version that is believed by more nodes is likely to win eventually. That means that there is an advantage to being well connected. If you are intending to attack the chain, you will want to have as many connections as you can, to get as much of the network on your side as possible. This proposal makes it more difficult for an attacker to remain well connected. Not impossible, of course, just more difficult. This isn't what an actual attack needs to look like. Lets imagine that I am evilMChacker with my 400,000 strong playstation 4 botnet or whatever, enough to have more hash power than the honest network. You are joeblow interested in selling a shiny new Lamborghini. At block 300000, I transmit a transaction (X) for our agreed on price of 2 BTC for the car. Simultaneously, I spin up my 400,000 playstations to start mining block 300001— they include transactions like normal but instead of transaction X they include transaction Y which is a payment to myself using the same coins as X spends. Once the playstations find 300001 they do not announce it, they continue working on 300002... If the rest of the network found 300001 in the meantime they just ignore it (as well any other blocks the network found). They keep merging in new tx from the network (though not any that conflict with Y, of course), but they do not announce and they never pay attention to blocks found on the main network. They just mine quietly in secret. In the meantime, you count up the confirmations— 1, 2 ... 6 ... 100. Okay, you're pretty confident that your transaction is guarded against reversal you hand over the keys. As I drive off cackling evilly into the sunset I send the final command to my botnet: "As soon as you're three blocks ahead of the main network, announce all your blocks and self destruct" Maybe moments later... hours later ... days ... weeks ... whatever. _Eventually_, because it has more hashpower, the evilMChacker chain will be three (or any amount) longer than the main chain and the blocks will be released causing a single sudden reorganization. The ever so slight sucking sound you hear is those precious two bitcoins leaving your wallet (and those of any dependent transactions) and ending back up in mine. No amount of flap dampening solves this. And besides, see RIPE-378, in the context of routing flap dampening is now considered harmful and I think the exact same thing would apply to dampening chain splits. When you dampen a split, you'll often end up on the wrong side, in which case you'll end up flapping towards all your peers whenever you do finally re-converge, thus causing them to dampen you and so on. |