From ZmnSCPxj at protonmail.com Sat Aug 21 03:10:46 2021 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Sat, 21 Aug 2021 03:10:46 +0000 Subject: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit In-Reply-To: References: <20210810061441.6rg3quotiycomcp6@ganymede> <20210812220339.GA3416@erisian.com.au> Message-ID: <50s2eg2qZ_BSHhI1mT_mHP7fkDQ8EXnakOb9NmDfZlx_hN44l37UmopfAr2V4ws4yhx0YihNYBIOelJ01vhITI8K4G1UgmobTwf9FyJq_Yo=@protonmail.com> Good morning Jeremy, > 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. Against the above, we should note that in the Lightning spec, when an output *would have been* created that is less than the dust limit, the output is instead put into fees. https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs Thus, the existence of a dust limit encourages L2 protocols to have similar rules, where outputs below the dust limit are just given over as fees to miners, so the existence of a dust limit might very well be incentivize-compatible for miners, regardless of centralization effects or not. Regards, ZmnSCPxj