0

Having thought a lot of spam bloating my node, 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 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?

1 Answer 1

2

The dustrelayfee is used to calculate dust thresholds. 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.

2
  • 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
    Commented Apr 3 at 16:00
  • 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.
    – Murch
    Commented Apr 3 at 16:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.