<p>Since 0.13.0 nodes will tell their peers via the <code>feefilter</code> p2p message what their current minimum acceptable feerate is. Given that it's fairly uncommon for nodes to run with something other than the default, I don't think nodes use this information for preferential peering. I guess you could parse the log to identify nodes that announce something lower than the default and then add them as peers via <code>addnode</code>.</p>
<p>When I last checked in January 2022, it was obvious that no miners were mining transactions that pay less than the default <code>minRelayTxFee</code>. That seems rational to me: a full block of 1 s/vB transactions brings a total of ₿0.01 in fees, and transactions below the <code>minRelayTxFee</code> even less than that. Compared the current subsidy of ₿6.25, that's less than a sixth of a percent. My understanding is that mining pools are mostly large logistics endeavors, and they tend to have a limited contingent of programmers on staff. Given a limited pool of skilled labor, you'd probably want to prioritize other things such as energy efficiency of your operation, reducing latency, stable power supply, redundant internet connections, improving pool worker management, or any of a dozen other things that could cause your very expensive hardware to run at less than optimal performance.</p>
<p>Additionally, having a minimum price for blockspace is in the interest of node operators, because every transaction has the externality of needing to be transmitted, validated, and stored by every node operator. Maintaining a minimum fee rate on their mempool is also a safeguard against a malicious party wasting lots of bandwidth with unconfirmed transactions that they later replace or don't get confirmed otherwise.</p>
<p>There is some discussion of those findings on Twitter here: <a href="https://twitter.com/murchandamus/status/1480553169239355393" rel="nofollow noreferrer">https://twitter.com/murchandamus/status/1480553169239355393</a></p>

CC BY-SA 4.0
2022-02-21T07:19:17.277Z
I don't quite see what's irrational about NOT including a transaction into an otherwise non-full block. Also, there is a precise configuration setting in the core client.
Markus Rother
CC BY-SA 4.0
2022-02-21T16:01:36.783Z
I updated my answer to more clearly express why I think miners wouldn't prioritize low feerate transaction processing.
Murch
CC BY-SA 4.0
2022-02-21T22:37:39.517Z
Thx.
I don't understand what you mean by "cost of all future synchronizations".
(see my update)
Markus Rother
CC BY-SA 4.0
2022-02-22T02:16:08.363Z
The bigger the blockchain, the longer it takes to catch up with the current state of the network for new nodes. Therefore, it may be beneficial, if blockspace maintains a minimum price rather than every single block being full.
Murch
CC BY-SA 4.0
2022-02-22T06:43:08.303Z
Sorry, no. You're essentially saying Bitcoin cannot handle full blocks.
Markus Rother
CC BY-SA 4.0
2022-02-22T12:48:50.680Z
No, that's not what I said. There is an externality to every confirmed transaction that is being paid by every full node operator. I'm pointing out that giving away the remaining blockspace does not align with the interests of full node operators, even while the miners could earn a minuscule amount of additional fees, and it obviously would be beneficial to the senders that get cheaper blockspace. The Bitcoin network could handle it fine, although it may cause there to be some amount of fewer full nodes.
Murch
CC BY-SA 4.0
2022-02-22T12:56:51.270Z
Also, it is in the interest of full nodes to enforce minimum feerates on their own mempools, because it puts a minimum price on transaction senders using their bandwidth. Removing the minimum feerate would make it trivial to waste a lot of node operators' bandwidth with unconfirmed transactions that never make it into blocks.
Murch
CC BY-SA 4.0
2022-02-22T13:56:30.447Z
What was the argument for the drop from 5000 down to 1000 then? Why 1000 and not 2500? How can you assume that 1000 is optimal?

Also, transactions can be filtered dynamically or by mempool size limit.
Markus Rother
CC BY-SA 4.0
2022-02-22T14:17:29.347Z
The last drop of the minRelayTxFee was from 10,000 to 1,000 in this PR: https://github.com/bitcoin/bitcoin/commit/6a4c196dd64da2fd33dc7ae77a8cdd3e4cf0eff1. If you're referring to https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4, you may want to consider that it was just reverting this change: https://github.com/bitcoin/bitcoin/commit/28e3249e53b8ef7516636df0f1406466a513095d and never got shipped.
Murch
CC BY-SA 4.0
2022-02-22T14:20:07.670Z
You can read the arguments people had in the PR here: https://github.com/bitcoin/bitcoin/pull/3305
Murch
CC BY-SA 4.0
2022-02-21T05:24:52.147Z
2022-02-22T13:00:55.073Z
2022-02-22T13:00:55.073Z
Murch
<p>Technically, it is up to each node operator to set the <code>minRelayTxFee</code> as he pleases.</p>
<p>Assume a transaction with less than 1Sat/vB in transaction fees and a fairly empty mempool.</p>
<p>Is it possible to identify nodes on the network that are likely to forward or have previously forwarded transactions with less than default minimum fees?</p>
<p>If a subnet of such nodes existed, miners should be incentivized to also connect to it -- at least in times of empty mempool.</p>
<p>EDIT:</p>
<p>Originally, I did not intend to discuss my assumptions about miners' incentives. However, I find that discussion rather interesting, and will happily clarify my views.</p>
<p>I understand that close to zero fee transactions may (currently) not incentivize miners enough. On the other hand, we can be certain that in principle miners are willing to include transactions at a fee of 999 Sat/vB. That being said, I think it is a fair assumption that a market price could be established somewhere in between, i.e. 0 &lt; fee &lt; 1000 Sat/vB. If that is true, transaction fees currently do NOT represent a market price, due to <code>minRelayTxFee</code> = 1000.</p>
<p>Furthermore the incentive to include non-standard transactions is likely to depend on the fiat price of Bitcoin, as the labour necessary for a transition is likely to be priced in fiat. I conclude that the incentive will grow in the future.</p>
<p>Finally, I do not agree with the notion that the demand for transaction is flat (static, fixed). I am absolutely certain of a demand for cheaper transactions.</p>
<p>EDIT:</p>
<p>Regardless of the transactions miners receive, nobody can force them to include those transactions in a block anyhow. If miners regard transactions as too cheap, they may very well omit them. It may not be wise to do so, because the fees, as little as they may be, will be picked up by another miner. Miners (i.e. some miners/a miner/somebody) will eventually change their parameters if the volume of non-standard transactions becomes large enough.</p>
<p><strong>My entire argument is about extending the fee market to the lower side.</strong></p>

<transaction-fees><relay>
How to find nodes forwarding transactions with less than minRelayTxFee?
Markus Rother
# How to find nodes forwarding transactions with less than minRelayTxFee?

(Asked by: username_0 on 2022-02-20)

Technically, it is up to each node operator to set the `minRelayTxFee` as he pleases.

Assume a transaction with less than 1Sat/vB in transaction fees and a fairly empty mempool.

Is it possible to identify nodes on the network that are likely to forward or have previously forwarded transactions with less than default minimum fees?

If a subnet of such nodes existed, miners should be incentivized to also connect to it -- at least in times of empty mempool.

EDIT:

Originally, I did not intend to discuss my assumptions about miners' incentives. However, I find that discussion rather interesting, and will happily clarify my views.

I understand that close to zero fee transactions may (currently) not incentivize miners enough. On the other hand, we can be certain that in principle miners are willing to include transactions at a fee of 999 Sat/vB. That being said, I think it is a fair assumption that a market price could be established somewhere in between, i.e. 0 < fee < 1000 Sat/vB. If that is true, transaction fees currently do NOT represent a market price, due to `minRelayTxFee` = 1000.

Furthermore the incentive to include non-standard transactions is likely to depend on the fiat price of Bitcoin, as the labour necessary for a transition is likely to be priced in fiat. I conclude that the incentive will grow in the future.

Finally, I do not agree with the notion that the demand for transaction is flat (static, fixed). I am absolutely certain of a demand for cheaper transactions.

EDIT:

Regardless of the transactions miners receive, nobody can force them to include those transactions in a block anyhow. If miners regard transactions as too cheap, they may very well omit them. It may not be wise to do so, because the fees, as little as they may be, will be picked up by another miner. Miners (i.e. some miners/a miner/somebody) will eventually change their parameters if the volume of non-standard transactions becomes large enough.

**My entire argument is about extending the fee market to the lower side.**

**Tags:** transaction-fees, relay


---

## 1 answers

### Answer by username_1 on 2022-02-21. Score: 4

Since 0.13.0 nodes will tell their peers via the `feefilter` p2p message what their current minimum acceptable feerate is. Given that it's fairly uncommon for nodes to run with something other than the default, I don't think nodes use this information for preferential peering. I guess you could parse the log to identify nodes that announce something lower than the default and then add them as peers via `addnode`.

When I last checked in January 2022, it was obvious that no miners were mining transactions that pay less than the default `minRelayTxFee`. That seems rational to me: a full block of 1 s/vB transactions brings a total of ₿0.01 in fees, and transactions below the `minRelayTxFee` even less than that. Compared the current subsidy of ₿6.25, that's less than a sixth of a percent. My understanding is that mining pools are mostly large logistics endeavors, and they tend to have a limited contingent of programmers on staff. Given a limited pool of skilled labor, you'd probably want to prioritize other things such as energy efficiency of your operation, reducing latency, stable power supply, redundant internet connections, improving pool worker management, or any of a dozen other things that could cause your very expensive hardware to run at less than optimal performance.

Additionally, having a minimum price for blockspace is in the interest of node operators, because every transaction has the externality of needing to be transmitted, validated, and stored by every node operator. Maintaining a minimum fee rate on their mempool is also a safeguard against a malicious party wasting lots of bandwidth with unconfirmed transactions that they later replace or don't get confirmed otherwise.

There is some discussion of those findings on Twitter here: <https://twitter.com/murchandamus/status/1480553169239355393>

> **Comments:**
> **username_0**: I don't quite see what's irrational about NOT including a transaction into an otherwise non-full block. Also, there is a precise configuration setting in the core client.  
> **username_1**: I updated my answer to more clearly express why I think miners wouldn't prioritize low feerate transaction processing.  
> **username_0**: Thx. I don't understand what you mean by "cost of all future synchronizations". (see my update)  
> **username_1**: The bigger the blockchain, the longer it takes to catch up with the current state of the network for new nodes. Therefore, it may be beneficial, if blockspace maintains a minimum price rather than every single block being full.  
> **username_0**: Sorry, no. You're essentially saying Bitcoin cannot handle full blocks.  
> **username_1**: No, that's not what I said. There is an externality to every confirmed transaction that is being paid by every full node operator. I'm pointing out that giving away the remaining blockspace does not align with the interests of full node operators, even while the miners could earn a minuscule amount of additional fees, and it obviously would be beneficial to the senders that get cheaper blockspace. The Bitcoin network could handle it fine, although it may cause there to be some amount of fewer full nodes.  
> **username_1**: Also, it is in the interest of full nodes to enforce minimum feerates on their own mempools, because it puts a minimum price on transaction senders using their bandwidth. Removing the minimum feerate would make it trivial to waste a lot of node operators' bandwidth with unconfirmed transactions that never make it into blocks.  
> **username_0**: What was the argument for the drop from 5000 down to 1000 then? Why 1000 and not 2500? How can you assume that 1000 is optimal?  Also, transactions can be filtered dynamically or by mempool size limit.  
> **username_1**: The last drop of the minRelayTxFee was from 10,000 to 1,000 in this PR: https://github.com/bitcoin/bitcoin/commit/6a4c196dd64da2fd33dc7ae77a8cdd3e4cf0eff1. If you're referring to https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4, you may want to consider that it was just reverting this change: https://github.com/bitcoin/bitcoin/commit/28e3249e53b8ef7516636df0f1406466a513095d and never got shipped.  
> **username_1**: You can read the arguments people had in the PR here: https://github.com/bitcoin/bitcoin/pull/3305  

---

