People who code: we want your input. Take the Survey
12

There are many facts that can increase a node's banscore. A node's banscore is updated in the Misbehaving function from main.cpp. Some of the reasons that trigger such update are: Sending invalid blocks. Sending duplicate version messages. Not sending first a version message (before other communication). Sending addr messages with more than 1000 addresses. ...


5

If some client's actions do not correspond with the Bitcoin protocol in a disruptive manner (e.g. flooding with invalid messages) a ban counter is increased depending on the seriousness of the violation of the protocol. When the ban meter reaches some predefined value (can be set with the -banscore option in bitcoind, default is 100) connection to that ...


4

The concept of banscore is mostly historical at this point in time. The original concept was that minor misconfiguration or implementation wouldn't cause the whole network to disconnect itself instantly from one another. Small violations would just be counted towards their ban score, with large violations (like sending invalid block data) resulting in ...


4

Your current peers can ban (for some time, not forever) your IP-address. Just connect to other nodes in case. The network itself can not do anything with you because there is no such thing in protocol. Your peers do not know - are you a double-spender or you just relaying somebody's else packets. (Sorry, my English is also very poor)


3

There is no way to know which node created a transaction or block, unless they publish that information themselves. Nodes should not have an identity that leaks into transaction or block data. So banning for relaying invalid blocks or transactions always applies to the peer that gave you the information, based on their IP address. The protocol requires you ...


3

No, spending an already spent output is not a DoS banning offense. Sending invalid transactions will however get you banned from your peers.


2

For a node to be disconnected the default threshold of banscore is 100. In versions prior to v0.18, the default time to keep the misbehaving peer from reconnecting is 86,400 seconds or 1 day. However, this was circumvented by attackers with multiple IP addresses. v0.18 release, allows peers that your node automatically disconnected for misbehavior (e.g. ...


2

First of all, IP addresses are not stored in transactions nor can a node just "generate IP addresses". How banning works is that nodes connect to each other via TCP sockets which are stream sockets so both nodes know the IP address of the other node. So when a node is banned, the banning node refuses to open a connection to the banned node. Nothing else is ...


2

When state->fShouldBan is set, the network thread will disconnect the node, and cleanup memory. As a result, the state object disappears entirely. Because of that, there is no need to ever unset fShouldBan. What does happen is that when the actual ban happens (not just the setting of the fShouldBan field), it is added to the ban table (which is IP based)....


2

Correct: there's no provision in the P2P network protocol for your peers to tell you what ban score they've computed for you. Since each node connected to you separately computes a ban score using its own rules, there's no way for you to confidently know your ban score unless you have some sort of monitor that knows all the ban score rules for all the full ...


Only top voted, non community-wiki answers of a minimum length are eligible