<p>The <code>dustrelayfee</code> is used to calculate <a href="https://bitcoin.stackexchange.com/a/41082/5406">dust thresholds</a>. The change you propose would increase all dust thresholds by a factor of one hundred. This would make transactions with recipient <em>or change</em> outputs of less than 29,400–54,600 sats (depending on output type) non-standard. The proposed change would not increase the transaction fees users need to pay.</p>
<blockquote>
<p>Or at least to force a spammer such as this one to some additional Bitcoin so that instead of paying just the fee they would have to pay additional 13.220kb*0.003BTC/kb=0.039BTC to someone or to themselves.</p>
</blockquote>
<p>It is not clear to me how you got to this conclusion. The dust threshold for P2TR is currently 330 sats, and under your proposal would be 33,000 sats, 0.008 times of what you calculated. The linked transaction has a single P2TR output that is 10,000 sats which under your new rule would need to be at least 33,000 sats. Your value seems to be based on the transaction weight, but the minimum output amount does not scale with the actual transaction weight.</p>
<p>Given the larger minimum output amount, it seems to me that this change would increase the minimum HTLC amount that can be reliably enforced on chain, but other than that I don’t see how it would hamper LN much.</p>

CC BY-SA 4.0
2024-04-03T16:00:42.287Z
I compute the minimum output to be `virtual_size_of_tx * dustrelayfee` . If this is not the correct formula then what formula is? `dust = (input_vsize + output_size) × 3 sat/vB` is very enigmatic to me as `mempool.space` does no break down transactions details into `input_vsize` and `output_size`. *Your value seems to be based on the transaction weight, but the minimum output amount does not scale with the actual transaction weight.* I used virtual_size to compute the minimum input. Doesn't the minimum input from grow linearly with the growth of the virtual size of the transaction?
John Smith
CC BY-SA 4.0
2024-04-03T16:50:39.980Z
Since third parties cannot predict the vsize for an input based on outputs that commit via hash to arbitrary scripts, the input vsize is estimated per the corresponding keyhash input for scripthash outputs. For P2TR this is the size of a P2TR keypath input. The first topic I linked to goes into more details.
Murch
CC BY-SA 4.0
2024-04-03T11:37:44.950Z
2024-04-03T14:37:08.957Z
2024-04-03T14:37:08.957Z
Murch
<p>Having <a href="https://bitcoin.stackexchange.com/questions/122481/how-do-i-set-up-bitcoin-conf-in-bitcoin-knots-to-stop-spam-and-low-value-transac">thought a lot of spam bloating my node</a>, I cannot but wonder of what effect on Lightning Network would be of setting <code>dustrelayfee</code> to <code>0.003</code> by all  nodes, instead of the default value of <code>0.00003</code>. From my calculations it would force the minimum funding channel amounts, e.g. given the rate 15sats/vbyte and the size of the funding transaction being 164.2vBytes one would have to have the amount of 0.0483BTC for funding the channel.
It seems that such filering would prevent many spam transactions from being relayed. Or at least to force a spammer <a href="https://mempool.space/tx/681ec55c4a74f5fed4803e33a97b7f42c1c79ae4281efcffb8f9ede5017b4970" rel="nofollow noreferrer">such as this one</a> to some additional Bitcoin so that instead of paying just the fee they would have to pay additional 13.220kb*0.003BTC/kb=0.039BTC to someone or to themselves. In the case of the spammer not having that much BTC it may stop him in his tracks for some time.</p>
<p>Would such filter disrupt channel closing transactions of the Lightning Network?
In particular, would such filtering prevent closing of many single-funded channels that have exhausted their spending capacity?</p>

<lightning-network><mempool><dust><ln-closing-channels><spam>
What effect on Lightning Network would be of setting dustrelayfee to 0.003 by all nodes?
John Smith
# What effect on Lightning Network would be of setting dustrelayfee to 0.003 by all nodes?

(Asked by: username_0 on 2024-04-03)

Having [thought a lot of spam bloating my node](https://bitcoin.stackexchange.com/questions/122481/how-do-i-set-up-bitcoin-conf-in-bitcoin-knots-to-stop-spam-and-low-value-transac), I cannot but wonder of what effect on Lightning Network would be of setting `dustrelayfee` to `0.003` by all nodes, instead of the default value of `0.00003`. From my calculations it would force the minimum funding channel amounts, e.g. given the rate 15sats/vbyte and the size of the funding transaction being 164.2vBytes one would have to have the amount of 0.0483BTC for funding the channel.
It seems that such filering would prevent many spam transactions from being relayed. Or at least to force a spammer [such as this one](https://mempool.space/tx/681ec55c4a74f5fed4803e33a97b7f42c1c79ae4281efcffb8f9ede5017b4970) to some additional Bitcoin so that instead of paying just the fee they would have to pay additional 13.220kb\*0.003BTC/kb=0.039BTC to someone or to themselves. In the case of the spammer not having that much BTC it may stop him in his tracks for some time.

Would such filter disrupt channel closing transactions of the Lightning Network?
In particular, would such filtering prevent closing of many single-funded channels that have exhausted their spending capacity?

**Tags:** lightning-network, mempool, dust, ln-closing-channels, spam


---

## 1 answers

### Answer by username_1 on 2024-04-03. Score: 2 | Accepted answer

The `dustrelayfee` is used to calculate [dust thresholds](https://bitcoin.stackexchange.com/a/41082/5406). The change you propose would increase all dust thresholds by a factor of one hundred. This would make transactions with recipient *or change* outputs of less than 29,400–54,600 sats (depending on output type) non-standard. The proposed change would not increase the transaction fees users need to pay.

> Or at least to force a spammer such as this one to some additional Bitcoin so that instead of paying just the fee they would have to pay additional 13.220kb\*0.003BTC/kb=0.039BTC to someone or to themselves.

It is not clear to me how you got to this conclusion. The dust threshold for P2TR is currently 330 sats, and under your proposal would be 33,000 sats, 0.008 times of what you calculated. The linked transaction has a single P2TR output that is 10,000 sats which under your new rule would need to be at least 33,000 sats. Your value seems to be based on the transaction weight, but the minimum output amount does not scale with the actual transaction weight.

Given the larger minimum output amount, it seems to me that this change would increase the minimum HTLC amount that can be reliably enforced on chain, but other than that I don’t see how it would hamper LN much.

> **Comments:**
> **username_0**: I compute the minimum output to be `virtual_size_of_tx * dustrelayfee` . If this is not the correct formula then what formula is? `dust = (input_vsize + output_size) × 3 sat/vB` is very enigmatic to me as `mempool.space` does no break down transactions details into `input_vsize` and `output_size`. *Your value seems to be based on the transaction weight, but the minimum output amount does not scale with the actual transaction weight.* I used virtual_size to compute the minimum input. Doesn't the minimum input from grow linearly with the growth of the virtual size of the transaction?  
> **username_1**: Since third parties cannot predict the vsize for an input based on outputs that commit via hash to arbitrary scripts, the input vsize is estimated per the corresponding keyhash input for scripthash outputs. For P2TR this is the size of a P2TR keypath input. The first topic I linked to goes into more details.  

---

