From: Jeremy <jlrubin@mit.edu>
To: 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, 19 Aug 2021 23:51:31 -0500 [thread overview]
Message-ID: <CAD5xwhiEDa2KjF265iDZ1ism4AFzh3S3D4cJSESVVKNwv9L7zA@mail.gmail.com> (raw)
In-Reply-To: <20210812220339.GA3416@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 3477 bytes --]
next prev parent reply other threads:[~2021-08-20 4:51 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-08 18:52 [bitcoin-dev] Removing the Dust Limit 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 [this message]
2021-08-20 5:45 ` shymaa arafat
2021-08-21 3:10 ` ZmnSCPxj
2021-08-26 21:21 ` Billy Tetrud
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=CAD5xwhiEDa2KjF265iDZ1ism4AFzh3S3D4cJSESVVKNwv9L7zA@mail.gmail.com \
--to=jlrubin@mit.edu \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=lightning-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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