[bitcoin-dev] [Lightning-dev] Removing the Dust Limit

shymaa arafat shymaa.arafat at gmail.com
Fri Aug 20 05:45:31 UTC 2021

On Fri, Aug 20, 2021, 06:52 Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> one interesting point that came up at the bitdevs in austin today that
> favors remove that i believe is new to this discussion (it was new to me):
> the argument can be reduced to:
> - dust limit is a per-node relay policy.
> - it is rational for miners to mine dust outputs given their cost of
> maintenance (storing the output potentially forever) is lower than their
> immediate reward in fees.
-Here, u  r assuming miners not running full nodes, or even stateless nodes
as in Utreexo
-otherwise they suffer from storing dust UTXOS/their effect on proof
length, right?

- if txn relaying nodes censor something that a miner would mine, users
> will seek a private/direct relay to the miner and vice versa.
> - if direct relay to miner becomes popular, it is both bad for privacy and
> decentralization.
> - therefore the dust limit, should there be demand to create dust at
> prevailing mempool feerates, causes an incentive to increase network
> centralization (immediately)
> the tradeoff is if a short term immediate incentive to promote network
> centralization is better or worse than a long term node operator overhead.
> ///////////////////
> my take is that:
> 1) having a dust limit is worse since we'd rather not have an incentive to
> produce or roll out centralizing software, whereas not having a dust limit
> creates an mild incentive for node operators to improve utreexo
> decentralizing software.
Why not having dust limit improves Utreexo, I think (and tried to suggest
many times) separate storing of dust&other non spendable UTXOS (and their
hashes) so that they do not affect other UTXOS proofs ( and not brought
into main memory unless called as a TXO)

2) it's hard to quantify the magnitude of the incentives, which does matter.
I honestly don't get the long term perspective of miners Incentivised to
storing small dust UTXOS instead of having their values added to the fee.

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210820/607a4fa6/attachment-0001.html>

More information about the bitcoin-dev mailing list