public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Date: Thu, 26 Aug 2021 14:21:25 -0700	[thread overview]
Message-ID: <CAGpPWDbseo6eYT1a54YB2-fpxpzj2cg9DL+s2_rpoa+dGfnhaQ@mail.gmail.com> (raw)
In-Reply-To: <50s2eg2qZ_BSHhI1mT_mHP7fkDQ8EXnakOb9NmDfZlx_hN44l37UmopfAr2V4ws4yhx0YihNYBIOelJ01vhITI8K4G1UgmobTwf9FyJq_Yo=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 2696 bytes --]

One interesting thing I thought of: the cost of maintenance of the dust
creates a (very) small incentive to mine transactions that *use* dust
outputs with a slightly lower fee that contain dust, in order to reduce the
future maintenance cost for themselves. However, the rational discount
would likely be vanishingly small.  It would be interesting to add
something to the consensus rules to decrease the vbytes for a transaction
that consumes dust outputs such that the value of removing them from the
system (saving the future cost of maintenance) is approximately equal to
the amount that the fee could be made lower for such transactions. Even
measuring this as a value over the whole (future) bitcoin network, I'm not
sure how to evaluate the magnitude of this future cost.





On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3886 bytes --]

  reply	other threads:[~2021-08-26 21:21 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-08 18:52 [bitcoin-dev] " Jeremy
2021-08-08 21:14 ` Matt Corallo
2021-08-08 21:41   ` Oleg Andreev
2021-08-08 21:51 ` [bitcoin-dev] [Lightning-dev] " David A. Harding
2021-08-08 22:46   ` Jeremy
2021-08-08 23:07   ` Jeremy
2021-09-30 22:07   ` Pieter Wuille
2021-10-01 13:40     ` Erik Aronesty
2021-10-07  4:52       ` ZmnSCPxj
2021-10-07  8:17         ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07  8:34           ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07 10:35             ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07  9:13         ` shymaa arafat
2021-10-07 10:01           ` ZmnSCPxj
     [not found]             ` <CAM98U8kKud-7QoJKYd5o245o8vGeUD7YD2OnXF_QeKaO33dSTw@mail.gmail.com>
     [not found]               ` <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com>
2021-10-08  7:44                 ` shymaa arafat
2021-10-08 10:38                   ` ZmnSCPxj
2021-10-08 22:47     ` ZmnSCPxj
2021-08-09 13:22 ` Antoine Riard
2021-08-10  0:30   ` Billy Tetrud
2021-08-10  5:04     ` Jeremy
2021-08-10  5:44       ` Billy Tetrud
2021-08-10 11:37         ` ZmnSCPxj
2021-08-10 18:39           ` Charlie Lee
2021-08-10  6:14   ` David A. Harding
2021-08-10 22:37     ` Antoine Riard
2021-08-11  0:46       ` ZmnSCPxj
2021-08-12 22:03       ` Anthony Towns
2021-08-20  4:51         ` Jeremy
2021-08-20  5:45           ` shymaa arafat
2021-08-21  3:10           ` ZmnSCPxj
2021-08-26 21:21             ` Billy Tetrud [this message]
2021-08-27  9:07               ` shymaa arafat
2021-08-30  3:31                 ` LORD HIS EXCELLENCY JAMES HRMH
2021-08-18 19:06 shymaa arafat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGpPWDbseo6eYT1a54YB2-fpxpzj2cg9DL+s2_rpoa+dGfnhaQ@mail.gmail.com \
    --to=billy.tetrud@gmail$(echo .)com \
    --cc=ZmnSCPxj@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=lightning-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox