The dust limit is required to prevent massive UTXO expansion. The details around miner incentives to process dust are irrelevant to this because there simply needs to be a buffer of friction to prevent spamming the UTXO set to be much, much larger, as an *attack* and long-term overhead on both storage size and resources in purposing UTXO data within applications/servers.
Even if I were wrong, it is still silly to propose changing a thing no one actually needs or wants changed for any practical application. It ain't broke, don't fix it. On Fri, Aug 20, 2021 at 7:00 AM < lightning-dev-requ...@lists.linuxfoundation.org> wrote: > Send Lightning-dev mailing list submissions to > lightning-dev@lists.linuxfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > or, via email, send a message with subject or body 'help' to > lightning-dev-requ...@lists.linuxfoundation.org > > You can reach the person managing the list at > lightning-dev-ow...@lists.linuxfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Lightning-dev digest..." > > > Today's Topics: > > 1. Re: [bitcoin-dev] Removing the Dust Limit (Jeremy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 19 Aug 2021 23:51:31 -0500 > From: Jeremy <jlru...@mit.edu> > To: Bitcoin Protocol Discussion > <bitcoin-...@lists.linuxfoundation.org> > Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org> > Subject: Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit > Message-ID: > < > cad5xwhieda2kjf265idz1ism4afzh3s3d4cjsesvvknwv9l...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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. > - 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. > 2) it's hard to quantify the magnitude of the incentives, which does > matter. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210819/831b9608/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > ------------------------------ > > End of Lightning-dev Digest, Vol 72, Issue 18 > ********************************************* > -- ~ John Carvalho Schedule: https://calendly.com/bitcoinerrorlog Chat: https://t.me/bitcoinerrorlog Social: https://twitter.com/bitcoinerrorlog
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev