Topic: proposal to reduce potential effects of majority miner attack (Read 1367 times)

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.  

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.

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-

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.

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.