<p>There are multiple reasons.</p>

<ul>
<li><p><strong>Wallets</strong> Maybe the node operator also has a wallet, and is interested in seeing unconfirmed transactions that pay him. It's generally discouraged to have a business depend on irreversible actions taken based on unconfirmed transactions, but this is not true for everything. You could for example start preparing a shipping order as soon as an unconfirmed payment comes in, but verify that the transaction is confirmed before it actually goes out the door.</p></li>
<li><p><strong>For fee estimation</strong> Maintaining a set of unconfirmed transactions in a way that lets you predict what will be confirmed in the near future (specifically, by running the same code as miners do) gives you insight in how fast network transactions with certain properties get confirmed. You cannot base this information purely on what you see in blocks, as that can be trivially gamed by miners (e.g. by stuffing their own blocks with a number of very high fee transactions).</p></li>
<li><p><strong>For network propagation</strong> Modern block relay solutions (like BIP152 Compact Blocks, FBRP, FIBRE, thin blocks, ...) rely on the fact that most transactions in a block can already be known to the receiver ahead of time, if they maintain a pool of unconfirmed transactions. These protocols massively reduce the time needed to get a block relayed across the network.</p></li>
</ul>

<p>Bitcoin Core since version v0.12.0 supports the <code>-blocksonly</code> flag, which disables all downloading and relay of transactions. It comes with a bandwidth reduction, but also loses the benefits listed above.</p>

CC BY-SA 3.0
2017-06-14T21:18:09.337Z
1. makes sense of course but if I am only interested in txs included in blocks it is meaningless to listen and broadcast. Let us say I am an evil and I don't want to spend 1KB of bandwith. 2. I am not sure I understand it. There is a formula that tells the priority of the transactions that the community agrees on. So why am I going to try to read the brain of Mr. Miner? That doesn't make sense. The relation between ordinary users and miners etc have to be analyzed from a game theory point of view, but I cannot  find a rigorous study. 3. makes sense thanks.
user8162717
CC BY-SA 3.0
2017-06-14T21:26:29.417Z
I think the whole point is this: If ordinary users do not listen and re-broadcast txs, then ordinary users cannot broadcast their own txs. In that case the network doesn't work. But let us say I am evil, and I broadcast only my own txs. What effect would such users have on the network?
user8162717
CC BY-SA 3.0
2017-06-14T21:31:15.750Z
1) You can run Bitcoin Core with the -blocksonly flag if you're really only interested in full blocks, but you'll also loose the benefit of 3. 2) Fee estimation is not that hard in a rational setting, as you can assume every miner will take the most profitable action, which can be very closely approximated by sorting by descending feerate, and pick the top 1M worth of transactions.
Pieter Wuille
CC BY-SA 3.0
2017-06-14T21:38:18.070Z
If a very large number of nodes on the network would stop relaying transactions, things could certainly break. If that were to happen, a response could be the creation of specially curated networks you can sign up for, or that people submit their transactions directly to miners, or algorithms that attempt preferential peering between nodes that do relay.
Pieter Wuille
CC BY-SA 3.0
2017-06-16T03:18:45.020Z
"as that can be trivially gamed by miners" - listening to txs prevents this in what way? An evil miner can do the same thing by broadcasting its own very high fee txs, for a certain period at least, to manipulate people to believe that they should increase the fees. Sorry, this works only if the miner has a lot of hash power, otherwise he will be paying fees to other miners.
user8162717
CC BY-SA 3.0
2017-06-17T00:22:45.580Z
Listening to transactions means that nodes aren't basing their estimations purely on the transactions that are in blocks. For example, in Bitcoin Core, fee estimation is partially done by seeing how long it takes for a transaction with a certain fee rate to be confirmed. Without listening to transactions, this calculation would be impossible. Even if some miners were stuffing blocks with high fee transactions, using this calculation involving unconfirmed transactions in order to get an estimate that is less effected by the miners.
Ava Chow
CC BY-SA 3.0
2017-06-14T20:58:53.403Z
2017-06-14T22:34:29.440Z
2017-06-14T22:34:29.440Z
Pieter Wuille
<p>I still don't understand why full but non-mining nodes listen to transactions. The validity of the transactions are ensured cryptographically. So what advantage does it give to either me or to the network? What am I supposed to do with that info when I get a live transaction? In my understanding, a full node should only listen to new blocks, unless it is also mining at the same time.</p>

CC BY-SA 3.0
2017-06-14T20:58:44.743Z
who will relay transactions to mining nodes?
amaclin
<transactions><bitcoind>
Why do non-mining nodes listen to transactions?
user8162717
# Why do non-mining nodes listen to transactions?

(Asked by: username_0 on 2017-06-14)

I still don't understand why full but non-mining nodes listen to transactions. The validity of the transactions are ensured cryptographically. So what advantage does it give to either me or to the network? What am I supposed to do with that info when I get a live transaction? In my understanding, a full node should only listen to new blocks, unless it is also mining at the same time.

**Tags:** transactions, bitcoind

> **Comments:**
> **username_1**: who will relay transactions to mining nodes?  

---

## 1 answers

### Answer by username_2 on 2017-06-14. Score: 5 | Accepted answer

There are multiple reasons.

* **Wallets** Maybe the node operator also has a wallet, and is interested in seeing unconfirmed transactions that pay him. It's generally discouraged to have a business depend on irreversible actions taken based on unconfirmed transactions, but this is not true for everything. You could for example start preparing a shipping order as soon as an unconfirmed payment comes in, but verify that the transaction is confirmed before it actually goes out the door.
* **For fee estimation** Maintaining a set of unconfirmed transactions in a way that lets you predict what will be confirmed in the near future (specifically, by running the same code as miners do) gives you insight in how fast network transactions with certain properties get confirmed. You cannot base this information purely on what you see in blocks, as that can be trivially gamed by miners (e.g. by stuffing their own blocks with a number of very high fee transactions).
* **For network propagation** Modern block relay solutions (like BIP152 Compact Blocks, FBRP, FIBRE, thin blocks, ...) rely on the fact that most transactions in a block can already be known to the receiver ahead of time, if they maintain a pool of unconfirmed transactions. These protocols massively reduce the time needed to get a block relayed across the network.

Bitcoin Core since version v0.12.0 supports the `-blocksonly` flag, which disables all downloading and relay of transactions. It comes with a bandwidth reduction, but also loses the benefits listed above.

> **Comments:**
> **username_0**: 1. makes sense of course but if I am only interested in txs included in blocks it is meaningless to listen and broadcast. Let us say I am an evil and I don't want to spend 1KB of bandwith. 2. I am not sure I understand it. There is a formula that tells the priority of the transactions that the community agrees on. So why am I going to try to read the brain of Mr. Miner? That doesn't make sense. The relation between ordinary users and miners etc have to be analyzed from a game theory point of view, but I cannot  find a rigorous study. 3. makes sense thanks.  
> **username_0**: I think the whole point is this: If ordinary users do not listen and re-broadcast txs, then ordinary users cannot broadcast their own txs. In that case the network doesn't work. But let us say I am evil, and I broadcast only my own txs. What effect would such users have on the network?  
> **username_2**: 1) You can run Bitcoin Core with the -blocksonly flag if you're really only interested in full blocks, but you'll also loose the benefit of 3. 2) Fee estimation is not that hard in a rational setting, as you can assume every miner will take the most profitable action, which can be very closely approximated by sorting by descending feerate, and pick the top 1M worth of transactions.  
> **username_2**: If a very large number of nodes on the network would stop relaying transactions, things could certainly break. If that were to happen, a response could be the creation of specially curated networks you can sign up for, or that people submit their transactions directly to miners, or algorithms that attempt preferential peering between nodes that do relay.  
> **username_0**: "as that can be trivially gamed by miners" - listening to txs prevents this in what way? An evil miner can do the same thing by broadcasting its own very high fee txs, for a certain period at least, to manipulate people to believe that they should increase the fees. Sorry, this works only if the miner has a lot of hash power, otherwise he will be paying fees to other miners.  
> **username_3**: Listening to transactions means that nodes aren't basing their estimations purely on the transactions that are in blocks. For example, in Bitcoin Core, fee estimation is partially done by seeing how long it takes for a transaction with a certain fee rate to be confirmed. Without listening to transactions, this calculation would be impossible. Even if some miners were stuffing blocks with high fee transactions, using this calculation involving unconfirmed transactions in order to get an estimate that is less effected by the miners.  

---

