[Lightning-dev] Lightning-dev Digest, Vol 72, Issue 18

Bitcoin Error Log bitcoinerrorlog at gmail.com
Mon Aug 23 12:58:43 UTC 2021


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-request at lists.linuxfoundation.org> wrote:

> Send Lightning-dev mailing list submissions to
>         lightning-dev at 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-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
>         lightning-dev-owner at 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 <jlrubin at mit.edu>
> To: Bitcoin Protocol Discussion
>         <bitcoin-dev at lists.linuxfoundation.org>
> Cc: lightning-dev <lightning-dev at lists.linuxfoundation.org>
> Subject: Re: [Lightning-dev] [bitcoin-dev]  Removing the Dust Limit
> Message-ID:
>         <
> CAD5xwhiEDa2KjF265iDZ1ism4AFzh3S3D4cJSESVVKNwv9L7zA at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210823/dfbbf45c/attachment.html>


More information about the Lightning-dev mailing list