<p><strong>How the network deals with bad actors (either intentionally (ie- attacker) or unintentional (ie- misconfigured node or a node running outdated code, forked code, etc))</strong>: Most bitcoin software is designed to listen for information on the Internet and pass it on if it's valid.  If it isn't valid enough times from the same peer, then the software will stop listening to that peer.  This cuts off nodes that are not providing valid data.</p>

<p><strong>What recourse is available for other users or miners to 'report' or blacklist or avoid the affected nodes or transactions</strong>: Only a few nodes will have connected to the source, and the best protection for ALL the other nodes is the answer above.  No one sends data to boatloads of peers, so no one can muck up lots of machines at once.  Since, if you send a mess, the node to which you send it will NOT pass it on, there is no need for reporting or blacklisting.</p>

<p>One of the problems with blacklists is that they can be abused.  Bitcoin's model of connecting to a few nodes and then passing messages between them after validation is an elegant solution to this decentralization problem.</p>

<p><strong>Dealing with intentional "attacks"</strong>: For attacks that use invalid transactions, abelenky's answer suffices.  For scam artists and hackers, Bitcoin has no internal mechanisms to identify people.  Bitcoin enthusiasts have been developing their own personal methods of connecting such dots (messaging apps, forums on Bitcoin sites, "Web of Trust" arrangements, etc.) for several years.  I doubt they could all be catalogued, but if you buy from or sell to someone, just ask and you'll get more and more info over time.</p>

CC BY-SA 4.0
2018-11-15T05:04:43.857Z
2018-11-15T05:04:43.857Z
Dave Scotese
<p>Assuming there is a miner that will put invalid transactions into a block:</p>

<p>First, this miner has to find a very high-difficulty hash to make the block valid.<br>
That alone is extremely improbable, as it is trying to find a hash faster than hundreds of thousands of honest miners.  The honest miners will probably find a correct hash to a valid, honest block, much much faster than the dishonest miner can complete his corrupt block.</p>

<p>Secondly, if the miner can find a hash, and successfully publish this corrupted/invalid block, any node that receives this invalid block will examine the data and recognize it as invalid.  When they see an invalid block, they will refuse to add it to their block chain, refuse to share it with other nodes, and probably blacklist the node that sent it to them.</p>

<p>The corrupt miner will have spent a lot of time and effort finding a hash, only to find itself quickly blacklisted and ignored.</p>

CC BY-SA 3.0
2017-12-06T08:40:20.960Z
Ah, so it seems the block itself can be the 'data model' I alluded to; for which nodes/miners can pragmatically check to verify validity. This is dot-connecting, thank-you for the clear explanation.
Derrick
CC BY-SA 3.0
2017-12-06T08:47:01.877Z
A non-crypto solution for example, could be that a node examines the previous confirmed block and then does a 'diff' against the new block (diffing only transactions which exist on both blocks).  If there are any conflicts, it knows the new block is invalid.
Derrick
CC BY-SA 3.0
2017-12-06T08:48:17.287Z
However, Bitcoin blocks don't contain old transactions.  So, this is where some of the heavy crypto math comes in - from my understanding, protocol says the new valid block needs to contain a hash which is a result of all previous blocks' hashes combined - as such, if you were to remove any one of those blocks/hashes (or tamper with the transactions contained within) the new hash would not compute.  Therefore your block validity logic needs not examine transaction history specifically - it only needs to check that the new hash correctly returns the expected result of all previous hashes.
Derrick
CC BY-SA 3.0
2017-12-06T08:48:33.397Z
If the hash doesn't line up - then it's invalid - at this point the node should reject it and optionally take defensive measures against the source of that block ie- flag or blocklist it.
Derrick
CC BY-SA 3.0
2017-12-05T03:16:52.567Z
2017-12-05T13:31:52.257Z
2017-12-05T13:31:52.257Z
abelenky
<p>Can someone explain at a high level how the network deals with bad actors (either intentionally (ie- attacker) or unintentional (ie- misconfigured node or a node running outdated code, forked code, etc)) ? </p>

<p>Without knowing too much about Bitcoin's low level internals, I am assuming there are routine checks as data flows through the code on the network to test that the protocol is adhered to; and that anything outside of expected protocol becomes rejected or flagged.  I assume these checks are all essentially checked exclusively against the expected 'data model'  since obviously it's impossible to directly analyze what code is being run on independent miners/nodes. </p>

<p>So please correct me if I'm wrong here, or elaborate further to fill in the big picture a bit more. </p>

<p>Secondly, I wanted to know - in the case of a known hostile miner/node (or to a lesser extent, a known outdated or misconfigured network participant)- what recourse is available for other users or miners to 'report' or blacklist or avoid the affected nodes or transactions? </p>

<p>Ie- is there built in function for reporting a violation of protocol (either that can be executed on attacker's system or by means of other participants in the network identifying said attacker) ? </p>

<p>Your clarification appreciated, thanks ! </p>

<protocol><nodes><attack>
How does the Bitcoin network deal with bad actors?
Derrick
# How does the Bitcoin network deal with bad actors?

(Asked by: username_0 on 2017-12-05)

Can someone explain at a high level how the network deals with bad actors (either intentionally (ie- attacker) or unintentional (ie- misconfigured node or a node running outdated code, forked code, etc)) ?

Without knowing too much about Bitcoin's low level internals, I am assuming there are routine checks as data flows through the code on the network to test that the protocol is adhered to; and that anything outside of expected protocol becomes rejected or flagged. I assume these checks are all essentially checked exclusively against the expected 'data model' since obviously it's impossible to directly analyze what code is being run on independent miners/nodes.

So please correct me if I'm wrong here, or elaborate further to fill in the big picture a bit more.

Secondly, I wanted to know - in the case of a known hostile miner/node (or to a lesser extent, a known outdated or misconfigured network participant)- what recourse is available for other users or miners to 'report' or blacklist or avoid the affected nodes or transactions?

Ie- is there built in function for reporting a violation of protocol (either that can be executed on attacker's system or by means of other participants in the network identifying said attacker) ?

Your clarification appreciated, thanks !

**Tags:** protocol, nodes, attack


---

## 2 answers

### Answer by username_2 on 2017-12-05. Score: 4 | Accepted answer

Assuming there is a miner that will put invalid transactions into a block:

First, this miner has to find a very high-difficulty hash to make the block valid.  
That alone is extremely improbable, as it is trying to find a hash faster than hundreds of thousands of honest miners. The honest miners will probably find a correct hash to a valid, honest block, much much faster than the dishonest miner can complete his corrupt block.

Secondly, if the miner can find a hash, and successfully publish this corrupted/invalid block, any node that receives this invalid block will examine the data and recognize it as invalid. When they see an invalid block, they will refuse to add it to their block chain, refuse to share it with other nodes, and probably blacklist the node that sent it to them.

The corrupt miner will have spent a lot of time and effort finding a hash, only to find itself quickly blacklisted and ignored.

> **Comments:**
> **username_0**: Ah, so it seems the block itself can be the 'data model' I alluded to; for which nodes/miners can pragmatically check to verify validity. This is dot-connecting, thank-you for the clear explanation.  
> **username_0**: A non-crypto solution for example, could be that a node examines the previous confirmed block and then does a 'diff' against the new block (diffing only transactions which exist on both blocks).  If there are any conflicts, it knows the new block is invalid.  
> **username_0**: However, Bitcoin blocks don't contain old transactions.  So, this is where some of the heavy crypto math comes in - from my understanding, protocol says the new valid block needs to contain a hash which is a result of all previous blocks' hashes combined - as such, if you were to remove any one of those blocks/hashes (or tamper with the transactions contained within) the new hash would not compute.  Therefore your block validity logic needs not examine transaction history specifically - it only needs to check that the new hash correctly returns the expected result of all previous hashes.  
> **username_0**: If the hash doesn't line up - then it's invalid - at this point the node should reject it and optionally take defensive measures against the source of that block ie- flag or blocklist it.  

---

### Answer by username_1 on 2018-11-15. Score: 1

**How the network deals with bad actors (either intentionally (ie- attacker) or unintentional (ie- misconfigured node or a node running outdated code, forked code, etc))**: Most bitcoin software is designed to listen for information on the Internet and pass it on if it's valid. If it isn't valid enough times from the same peer, then the software will stop listening to that peer. This cuts off nodes that are not providing valid data.

**What recourse is available for other users or miners to 'report' or blacklist or avoid the affected nodes or transactions**: Only a few nodes will have connected to the source, and the best protection for ALL the other nodes is the answer above. No one sends data to boatloads of peers, so no one can muck up lots of machines at once. Since, if you send a mess, the node to which you send it will NOT pass it on, there is no need for reporting or blacklisting.

One of the problems with blacklists is that they can be abused. Bitcoin's model of connecting to a few nodes and then passing messages between them after validation is an elegant solution to this decentralization problem.

**Dealing with intentional "attacks"**: For attacks that use invalid transactions, username_2's answer suffices. For scam artists and hackers, Bitcoin has no internal mechanisms to identify people. Bitcoin enthusiasts have been developing their own personal methods of connecting such dots (messaging apps, forums on Bitcoin sites, "Web of Trust" arrangements, etc.) for several years. I doubt they could all be catalogued, but if you buy from or sell to someone, just ask and you'll get more and more info over time.


---

