Bitcoin Forum
December 08, 2016, 10:19:01 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Should Gavin's client banning be merged?
No, this is a feature, and risky to merge. - 1 (33.3%)
No, this is a feature, and shouldn't be merged on principle. - 0 (0%)
Yes, while the original code isn't really a fix, the orphan spam fix is. - 0 (0%)
Yes, it's all really fixing security issues anyway. - 2 (66.7%)
Total Voters: 3

Pages: [1]
  Print  
Author Topic: Bitcoind Stable 0.4.x: Merge client banning?  (Read 2409 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
December 01, 2011, 10:50:41 PM
 #1

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.

1481235541
Hero Member
*
Offline Offline

Posts: 1481235541

View Profile Personal Message (Offline)

Ignore
1481235541
Reply with quote  #2

1481235541
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481235541
Hero Member
*
Offline Offline

Posts: 1481235541

View Profile Personal Message (Offline)

Ignore
1481235541
Reply with quote  #2

1481235541
Report to moderator
1481235541
Hero Member
*
Offline Offline

Posts: 1481235541

View Profile Personal Message (Offline)

Ignore
1481235541
Reply with quote  #2

1481235541
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
December 01, 2011, 10:53:54 PM
 #2

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
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 02, 2011, 12:20:43 AM
 #3

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.

How often do you get the chance to work on a potentially world-changing project?
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
December 02, 2011, 12:42:11 AM
 #4

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
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 02, 2011, 01:02:21 AM
 #5

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.

How often do you get the chance to work on a potentially world-changing project?
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
December 02, 2011, 03:05:56 AM
 #6

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
December 02, 2011, 05:53:23 PM
 #7

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
Hero Member
*****
Offline Offline

Activity: 528


View Profile
December 02, 2011, 06:15:59 PM
 #8

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
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
December 02, 2011, 06:33:10 PM
 #9

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
Member
**
Offline Offline

Activity: 119


View Profile
December 07, 2011, 07:24:26 PM
 #10

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
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 07, 2011, 10:12:23 PM
 #11

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.

How often do you get the chance to work on a potentially world-changing project?
paraipan
Legendary
*
Offline Offline

Activity: 924


Firstbits: 1pirata


View Profile WWW
December 07, 2011, 11:21:03 PM
 #12


......

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


small question... is that possible ?

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 08, 2011, 02:52:06 AM
 #13

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).

How often do you get the chance to work on a potentially world-changing project?
paraipan
Legendary
*
Offline Offline

Activity: 924


Firstbits: 1pirata


View Profile WWW
December 08, 2011, 03:25:10 AM
 #14

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  Smiley

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!