<h2>Validation</h2>
<p>All Bitcoin nodes are validator nodes. There are no special validator nodes. No nodes rely on other nodes to perform validation. No nodes need to trust other nodes.</p>
<p>The only partial exception would be lightweight nodes that use Simplified Payment Verification (SPV) and which do not retain their own copy of the Bitcoin transaction journal (blockchain). But even SPV nodes perform as much validation as possible themselves.</p>
<p>Any miner that colludes with others to publish blocks that contain invalid transactions is throwing away money and harming themselves.</p>
<h2>Mining</h2>
<p>You have this part backwards. First the mining controllers have to obtain details of pending transactions and construct a block template <em>before</em> the mining hardware (typically ASICs) can start searching for a nonce value that causes the block hash to be less than the current target.</p>
<p>Hashes are not magic numbers that can be plugged into any old block. Block hashes can only be derived from a complete block (though pools can arrange that the hashing work be broken up and spread among pool members)</p>
<hr />
<p>Related</p>
<ul>
<li><a href="https://bitcoin.stackexchange.com/q/111116/13866">Can a node be maliciously programmed to validate all the transactions coming from a specific entity?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/108206/13866">Is it possible that most validating nodes are dishonest nodes?</a></li>
</ul>

CC BY-SA 4.0
2022-03-23T14:54:22.790Z
Thank you for all of your help with this!
apleroy
CC BY-SA 4.0
2022-03-22T18:09:17.180Z
2022-03-22T18:28:13.767Z
2022-03-22T18:28:13.767Z
RedGrittyBrick
<p>As RedGrittyBrick points out, every node unilaterally validates all data they receive, thereby enforcing all rules of the Bitcoin protocol. Nodes can't be convinced by many peers telling them about invalid data. If data doesn't fit the consensus rules, they'll just drop that data and ban the peers that sent them invalid data. So, to respond with a bit more detail to your last paragraph:</p>
<blockquote>
<p>For example, if a given party controlled the majority (or even smaller percentage) of validator nodes, could they change their Bitcoin Core code to do any of the following and disrupt the network?</p>
<ul>
<li>Reject incoming mempool transactions based on their own implementation of an address block list</li>
<li>Flood the mempool with faulty transactions and slow things down for all other node participants (ie remove the initial verification checks for transactions (<a href="https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp</a>))</li>
<li>Work in coordination with a miner to accept a mined transaction block that has invalid transactions</li>
<li>Reject a valid block that a miner legitimately has created, causing the reward to go elsewhere</li>
</ul>
</blockquote>
<p>It doesn't matter how many nodes misbehave, having a single honest peer is enough to learn about the actual best chain, and to learn about more peers. One exception is if <strong>all</strong> your peers are colluding to trick you. Then they can hide new data from you, and, if they also have sufficient mining power, even present you with an alternative shorter chaintip that your node will misconstrue as the best chain in absence of better information. If all your peers are controlled by an attacker, this is referred to as an <strong>eclipse attack</strong>.</p>
<p>Beyond that, yes, someone could do the things you propose, but they would not have the intended effect: nodes can reject transactions locally, but that will not stop other nodes from forwarding the same transactions to each other. Nodes can create faulty data and spam their peers with it, but their peers will simply ban them for relaying invalid data—your node won't ever accept invalid data just because it's presented multiple times. Nodes can deliberately accept invalid blocks, but that won't cause other nodes to accept those blocks. Nodes can reject a valid block, but that just forks them off from the best chain.</p>
<p>A node is free to create an alternate reality for themselves, but they cannot change other nodes' evaluation of the situation.</p>

CC BY-SA 4.0
2022-03-23T14:53:48.817Z
Thank you for all of these details, this is very helpful!
apleroy
CC BY-SA 4.0
2022-03-22T19:11:15.803Z
2022-03-23T12:39:49.220Z
2022-03-23T12:39:49.220Z
Murch
<p>I am hoping to better understand the difference between miner nodes and validator nodes and <strong>the decentralization risks (if any) posed by one party controlling X% of all validator nodes</strong>.</p>
<p>I have been making my way through some great resources on validation and miners here:</p>
<ul>
<li><a href="https://bitcoin.org/en/bitcoin-core/features/validation" rel="nofollow noreferrer">https://bitcoin.org/en/bitcoin-core/features/validation</a></li>
<li><a href="https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch08.asciidoc" rel="nofollow noreferrer">https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch08.asciidoc</a></li>
</ul>
<p>From what I understand, miner nodes do not have to have any of the blockchain downloaded, they can simply create hash attempts as fast as possible and report back to a ‘parent node/mining pool’ who can take the correct hash, form the block candidate, and propagate it to the rest of the network for verification and inclusion.  There exists a risk of the 51% attack when a miner (or group of miners) controls the hash rate and is able to create a longer chain or proof of work.</p>
<p><strong>Is there also a similar requirement for the distribution of validator nodes to be decentralized?</strong></p>
<p>For example, if a given party controlled the majority (or even smaller percentage) of validator nodes, could they change their Bitcoin Core code to do any of the following and disrupt the network?</p>
<ul>
<li>Reject incoming mempool transactions based on their own implementation of an address block list</li>
<li>Flood the mempool with faulty transactions and slow things down for all other node participants (ie remove the initial verification checks for transactions (<a href="https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp</a>))</li>
<li>Work in coordination with a miner to accept a mined transaction block that has invalid transactions</li>
<li>Reject a valid block that a miner legitimately has created, causing the reward to go elsewhere</li>
</ul>

CC BY-SA 4.0
2022-03-22T18:51:24.353Z
Possible duplicate of https://bitcoin.stackexchange.com/q/95564/5406
Murch
<mining-theory><mempool><validation><decentralization>
Understanding Bitcoin Validator Node Decentralization
apleroy
# Understanding Bitcoin Validator Node Decentralization

(Asked by: username_0 on 2022-03-22)

I am hoping to better understand the difference between miner nodes and validator nodes and **the decentralization risks (if any) posed by one party controlling X% of all validator nodes**.

I have been making my way through some great resources on validation and miners here:

* <https://bitcoin.org/en/bitcoin-core/features/validation>
* <https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch08.asciidoc>

From what I understand, miner nodes do not have to have any of the blockchain downloaded, they can simply create hash attempts as fast as possible and report back to a ‘parent node/mining pool’ who can take the correct hash, form the block candidate, and propagate it to the rest of the network for verification and inclusion. There exists a risk of the 51% attack when a miner (or group of miners) controls the hash rate and is able to create a longer chain or proof of work.

**Is there also a similar requirement for the distribution of validator nodes to be decentralized?**

For example, if a given party controlled the majority (or even smaller percentage) of validator nodes, could they change their Bitcoin Core code to do any of the following and disrupt the network?

* Reject incoming mempool transactions based on their own implementation of an address block list
* Flood the mempool with faulty transactions and slow things down for all other node participants (ie remove the initial verification checks for transactions (<https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp>))
* Work in coordination with a miner to accept a mined transaction block that has invalid transactions
* Reject a valid block that a miner legitimately has created, causing the reward to go elsewhere

**Tags:** mining-theory, mempool, validation, decentralization

> **Comments:**
> **username_1**: Possible duplicate of https://bitcoin.stackexchange.com/q/95564/5406  

---

## 2 answers

### Answer by username_1 on 2022-03-22. Score: 3 | Accepted answer

As username_2 points out, every node unilaterally validates all data they receive, thereby enforcing all rules of the Bitcoin protocol. Nodes can't be convinced by many peers telling them about invalid data. If data doesn't fit the consensus rules, they'll just drop that data and ban the peers that sent them invalid data. So, to respond with a bit more detail to your last paragraph:

> For example, if a given party controlled the majority (or even smaller percentage) of validator nodes, could they change their Bitcoin Core code to do any of the following and disrupt the network?
>
> * Reject incoming mempool transactions based on their own implementation of an address block list
> * Flood the mempool with faulty transactions and slow things down for all other node participants (ie remove the initial verification checks for transactions (<https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp>))
> * Work in coordination with a miner to accept a mined transaction block that has invalid transactions
> * Reject a valid block that a miner legitimately has created, causing the reward to go elsewhere

It doesn't matter how many nodes misbehave, having a single honest peer is enough to learn about the actual best chain, and to learn about more peers. One exception is if **all** your peers are colluding to trick you. Then they can hide new data from you, and, if they also have sufficient mining power, even present you with an alternative shorter chaintip that your node will misconstrue as the best chain in absence of better information. If all your peers are controlled by an attacker, this is referred to as an **eclipse attack**.

Beyond that, yes, someone could do the things you propose, but they would not have the intended effect: nodes can reject transactions locally, but that will not stop other nodes from forwarding the same transactions to each other. Nodes can create faulty data and spam their peers with it, but their peers will simply ban them for relaying invalid data—your node won't ever accept invalid data just because it's presented multiple times. Nodes can deliberately accept invalid blocks, but that won't cause other nodes to accept those blocks. Nodes can reject a valid block, but that just forks them off from the best chain.

A node is free to create an alternate reality for themselves, but they cannot change other nodes' evaluation of the situation.

> **Comments:**
> **username_0**: Thank you for all of these details, this is very helpful!  

---

### Answer by username_2 on 2022-03-22. Score: 4

## Validation

All Bitcoin nodes are validator nodes. There are no special validator nodes. No nodes rely on other nodes to perform validation. No nodes need to trust other nodes.

The only partial exception would be lightweight nodes that use Simplified Payment Verification (SPV) and which do not retain their own copy of the Bitcoin transaction journal (blockchain). But even SPV nodes perform as much validation as possible themselves.

Any miner that colludes with others to publish blocks that contain invalid transactions is throwing away money and harming themselves.

## Mining

You have this part backwards. First the mining controllers have to obtain details of pending transactions and construct a block template *before* the mining hardware (typically ASICs) can start searching for a nonce value that causes the block hash to be less than the current target.

Hashes are not magic numbers that can be plugged into any old block. Block hashes can only be derived from a complete block (though pools can arrange that the hashing work be broken up and spread among pool members)

---

Related

* [Can a node be maliciously programmed to validate all the transactions coming from a specific entity?](https://bitcoin.stackexchange.com/q/111116/13866)
* [Is it possible that most validating nodes are dishonest nodes?](https://bitcoin.stackexchange.com/q/108206/13866)

> **Comments:**
> **username_0**: Thank you for all of your help with this!  

---

