<p>Nodes are just software, at the end of the day.</p>

<p>The Bitcoin Core software will automatically relay standard valid transactions provided they meed the minrelayfee.</p>

<p>It would be fairly trivial to modify the software to relay only if certain other rules are met, however. You could easily do this without impacting the rest of the node functionality.</p>

<p>Usually, the node broadcasting a tx will broadcast it to multiple peers, so even if some peers enforce additional relay rules, the transaction will be broadcasted further by those who don't.</p>

CC BY-SA 4.0
2018-08-10T10:33:34.733Z
2018-08-10T10:33:34.733Z
Raghav Sood
<blockquote>
  <p>Under the Bitcoin protocol, how much control does a node have on how a transaction is dealt with once received?</p>
</blockquote>

<p>Look in source code.</p>

<blockquote>
  <p>Can a node reject a valid transaction? </p>
</blockquote>

<p>The node has a right/ability to ignore anything :)</p>

<blockquote>
  <p>Can a node refuse to relay a valid transaction to neighboring nodes </p>
</blockquote>

<p>Yes, it can. Node can do everything coded in algorithm</p>

<blockquote>
  <p>or is the transaction relayed automatically once validated? </p>
</blockquote>

<p>Most of cliens do it.</p>

<blockquote>
  <p>If not relayed automatically, why not? </p>
</blockquote>

<p>Why yes? In decentralized system nobody will punish for it</p>

<blockquote>
  <p>Why give a node the option to control whether or not a valid transaction gets relayed?</p>
</blockquote>

<p>Why not? The presence of such option is better than the absence of it. This gives us on more freedom - to do or not to do</p>

CC BY-SA 4.0
2018-08-10T15:43:54.087Z
2018-08-10T15:43:54.087Z
amaclin
<p>If you run the standard node software, you can expect that they will relay all valid transactions.  A (edit: not only) configurable parameter (in Bitcoin Core) is the minrelayfee.  So you can choose not to relay transactions if the fees are too low.  This is to help prevent spam.</p>

<p>If you wanted to filter on other parameters (e.g. blacklist addresses), this would be easy to do by modifying the software as it is open source.  This would be difficult to detect if a node is doing this, and it would not greatly impact the network unless a vast majority of the nodes started doing this.  Even so, the bootstrap nodes will not do this and such an attack would not be feasible.</p>

CC BY-SA 4.0
2018-08-10T15:47:00.197Z
there is second configurable parameter `-blocksonly`
amaclin
CC BY-SA 4.0
2018-08-10T15:00:59.937Z
2018-08-10T18:59:34.303Z
2018-08-10T18:59:34.303Z
Zelgada
<p>Under the Bitcoin protocol, how much control does a node have on how a transaction is dealt with once received? Can a node reject a valid transaction? Can a node refuse to relay a valid transaction to neighboring nodes or is the transaction relayed automatically once validated? If not relayed automatically, why not? Why give a node the option to control whether or not a valid transaction gets relayed?</p>

CC BY-SA 4.0
2018-08-10T17:58:13.087Z
How do you imagine enforcing a requirement to relay transactions?
Gendarme
<transactions><bitcoin-core><transaction-verification><validation>
Reject or refuse to relay a valid transaction
Curious Cyrus
# Reject or refuse to relay a valid transaction

(Asked by: username_0 on 2018-08-10)

Under the Bitcoin protocol, how much control does a node have on how a transaction is dealt with once received? Can a node reject a valid transaction? Can a node refuse to relay a valid transaction to neighboring nodes or is the transaction relayed automatically once validated? If not relayed automatically, why not? Why give a node the option to control whether or not a valid transaction gets relayed?

**Tags:** transactions, bitcoin-core, transaction-verification, validation

> **Comments:**
> **username_1**: How do you imagine enforcing a requirement to relay transactions?  

---

## 3 answers

### Answer by username_2 on 2018-08-10. Score: 3

Nodes are just software, at the end of the day.

The Bitcoin Core software will automatically relay standard valid transactions provided they meed the minrelayfee.

It would be fairly trivial to modify the software to relay only if certain other rules are met, however. You could easily do this without impacting the rest of the node functionality.

Usually, the node broadcasting a tx will broadcast it to multiple peers, so even if some peers enforce additional relay rules, the transaction will be broadcasted further by those who don't.


---

### Answer by username_3 on 2018-08-10. Score: 2

> Under the Bitcoin protocol, how much control does a node have on how a transaction is dealt with once received?

Look in source code.

> Can a node reject a valid transaction?

The node has a right/ability to ignore anything :)

> Can a node refuse to relay a valid transaction to neighboring nodes

Yes, it can. Node can do everything coded in algorithm

> or is the transaction relayed automatically once validated?

Most of cliens do it.

> If not relayed automatically, why not?

Why yes? In decentralized system nobody will punish for it

> Why give a node the option to control whether or not a valid transaction gets relayed?

Why not? The presence of such option is better than the absence of it. This gives us on more freedom - to do or not to do


---

### Answer by username_4 on 2018-08-10. Score: 1

If you run the standard node software, you can expect that they will relay all valid transactions. A (edit: not only) configurable parameter (in Bitcoin Core) is the minrelayfee. So you can choose not to relay transactions if the fees are too low. This is to help prevent spam.

If you wanted to filter on other parameters (e.g. blacklist addresses), this would be easy to do by modifying the software as it is open source. This would be difficult to detect if a node is doing this, and it would not greatly impact the network unless a vast majority of the nodes started doing this. Even so, the bootstrap nodes will not do this and such an attack would not be feasible.

> **Comments:**
> **username_3**: there is second configurable parameter `-blocksonly`  

---

