Bitcoind Stable 0.4.x: Merge client banning?

[Luke-Jr]

Shortly after 0.4.0 was released, Gavin added code to ban clients which misbehave (sending invalid blocks, transactions, etc). This is part of 0.5.0, but I didn't merge into 0.4.1 because it was questionable whether this was really a fix or a new feature, and it looked like there was some potential for new bugs introduced by it.

Recently, a certain "alternate" block chain has been experiencing floods of impossible orphan blocks which are filling its clients' databases. In order to preemptively try to stop such an attack on Bitcoin, Gavin just added an extension to his client banning code which also bans clients that send these impossible orphan blocks. This will become part of 0.5.1 and 0.6. Since this orphan block flooding has an actual potential to do damage, this new change seems more likely to be a bugfix than the original client banning was.

So my question to people who will be using the stable bitcoind 0.4.x on an ongoing basis is: should this be backported for 0.4.2, or not?

Note: Impossible orphan blocks are, for example, those with impossibly low difficulty or built on blocks older than the last "checkpoint" block.

[DeathAndTaxes]

Need more details on how and when this "banning" occurs, what happens when a node is banned, and when is a node unbanned.

[Gavin Andresen]

How:

CNode::Misbehaving(int howmuch) is called when code detects that a peer is doing something out-of-the-ordinary.  In this case, if a peer sends you a block that can't possibly be in the best chain, Misbehaving(100) is called.

When a Node accumulates a misbehavior score greater than or equal to "-banscore" (default 100), their connection is dropped and their IP address is banned from reconnecting for "-bantime" seconds (default 24 hours).

When are they un-banned:

After -bantime seconds. But the list of banned IP addresses is stored in memory, so if you shutdown and restart bitcoin everybody is un-banned.

There is no way to see the list of currently banned nodes, but you will see "Disconnected n.n.n.n for misbehavior" and "connection from n.n.n.n dropped (banned)" in the debug.log.

[Luke-Jr]

CNode::Misbehaving(int howmuch) is called when code detects that a peer is doing something out-of-the-ordinary.  In this case, if a peer sends you a block that can't possibly be in the best chain, Misbehaving(100) is called.

Hmm, does it also ignore the block? I wonder if it's maybe possible to merge this WITHOUT the banning part?

[Gavin Andresen]

Hmm, does it also ignore the block? I wonder if it's maybe possible to merge this WITHOUT the banning part?

Yes, it ignores the block.

Pulling out just the detect-too-low-difficulty-blocks parts wouldn't be terribly hard.

[theymos]

I don't think it should be merged. I like to see a heterogeneous network with regard to limits. If some limits cause network stability problems, it would be best for the entire network to not fail. The code is also new, and new code is the enemy of stability.

[Luke-Jr]

Managed to merge just the orphan-flood bugfix without the client banning feature. Hopefully this compromise is good enough for everyone.

0.5.x already has the client-banning feature, so it will ban orphan flooders.

[randomguy7]

What is the banning feature supposed to protect against? Aren't invalid blocks ignored anyways? Is it to protect against DOS like attacks against specific clients?

[gmaxwell]

What is the banning feature supposed to protect against? Aren't invalid blocks ignored anyways? Is it to protect against DOS like attacks against specific clients?

The blocks are only invalid because they have no hope of being part of the longest chain. They pass the checks otherwise and are stored just in case they might become part of the longest chain someday.

Thus the dos vulnerability.

[sebastian]

I dont understand this: How do we know if the block is coming from a misbehaving client (eg which sends "orphan" blocks on purpose), or a block that comes from a slow miner, so the block cannot go into the blockchain because that node was too slow and another node was first, and thus that block becomes orphan?

I know that miners dump the block they are currently working on and begin working on next block if someone races before the miner and completes a block, but this case with "legitimate orphans" can occur if 2 nodes complete a block in nearly the same time.

A legitimate orphan occurs when:
1: A miner A completes block before miner B
2: Miner B completes the block before getting notification from network that miner A completed the block
3: Miner B sends out the orphan block because he didnt know the block was orphan.

Now miner B would get banned for one single orphan block.


Maybe its a bit harsh to put a score of 100 on a orphan block. Maybe a score of 40 is better, 3 orphan blocks in 24 hours is a bit much.
I guess the score are reset each 24h period?

Then miners who know they have sent 2 legitimate orphan blocks (because they got the notification that a block was completed after he sent out his own block), can stop mine until 24 hours have passed, and thus avoid getting banned.

And if this happen regularly, for example 2 periods in row, the mining client could automatically add a little delay in the mining, so the mining client avoids his "twin node" which mines a little bit faster.

[Gavin Andresen]

I dont understand this: How do we know if the block is coming from a misbehaving client (eg which sends "orphan" blocks on purpose), or a block that comes from a slow miner, so the block cannot go into the blockchain because that node was too slow and another node was first, and thus that block becomes orphan?

The misbehaving client creates orphan blocks with very low proof-of-work; the unlucky miner creates orphan blocks with valid proof-of-work.

The misbehaving client gets away with their misbehavior by either anchoring their bogus blocks deep in the chain, when blocks had very easy proof-of-work.

Or giving them a bogus "previous block hash" so they're not anchored anywhere in the chain at all.

[paraipan]

......

Or giving them a bogus "previous block hash" so they're not anchored anywhere in the chain at all.

small question... is that possible ?

[Gavin Andresen]

Or giving them a bogus "previous block hash" so they're not anchored anywhere in the chain at all.

small question... is that possible ?

Sure-- it has to be possible, there is no guarantee that you'll see blocks announced on the network in order. An orphan block may just be one that you can't connect to the main chain yet because you haven't seen it's parent yet (maybe you're downloading blocks and haven't got them all yet, or maybe a miner got lucky and only needed eleven hashes to build on a block and you see her block before the parent because of network delays).

[paraipan]

Or giving them a bogus "previous block hash" so they're not anchored anywhere in the chain at all.

small question... is that possible ?

Sure-- it has to be possible, there is no guarantee that you'll see blocks announced on the network in order. An orphan block may just be one that you can't connect to the main chain yet because you haven't seen it's parent yet (maybe you're downloading blocks and haven't got them all yet, or maybe a miner got lucky and only needed eleven hashes to build on a block and you see her block before the parent because of network delays).

got it, so there are some cases when this would happen. Guess fine-tunning the protocol is the hardest part after all but we're lucky to have you and your team, Gavin