diff options
| author | Jeremy <jlrubin@mit.edu> | 2021-08-19 23:51:31 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-08-20 04:51:47 +0000 |
| commit | 22b1f2e574a329776ef19e0fa4c7c6d0ebba7253 (patch) | |
| tree | 23457e96de73d1fc2bff7d93ed8b32c89af86af6 | |
| parent | fdd9d051bda968a8af94486e623628ed5c427ee3 (diff) | |
| download | pi-bitcoindev-22b1f2e574a329776ef19e0fa4c7c6d0ebba7253.tar.gz pi-bitcoindev-22b1f2e574a329776ef19e0fa4c7c6d0ebba7253.zip | |
Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
| -rw-r--r-- | 4b/618db96c0a94b33f85d9149e7edebce385e74e | 153 |
1 files changed, 153 insertions, 0 deletions
diff --git a/4b/618db96c0a94b33f85d9149e7edebce385e74e b/4b/618db96c0a94b33f85d9149e7edebce385e74e new file mode 100644 index 000000000..054d00a4f --- /dev/null +++ b/4b/618db96c0a94b33f85d9149e7edebce385e74e @@ -0,0 +1,153 @@ +Return-Path: <jlrubin@mit.edu> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 22F86C000E; + Fri, 20 Aug 2021 04:51:47 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id F09E9613D4; + Fri, 20 Aug 2021 04:51:46 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.3 +X-Spam-Level: +X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 + tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, + SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id P7_gm53ZieUo; Fri, 20 Aug 2021 04:51:45 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) + by smtp3.osuosl.org (Postfix) with ESMTPS id AF9C4613B7; + Fri, 20 Aug 2021 04:51:45 +0000 (UTC) +Received: from mail-io1-f48.google.com (mail-io1-f48.google.com + [209.85.166.48]) (authenticated bits=0) + (User authenticated as jlrubin@ATHENA.MIT.EDU) + by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 17K4phtc015610 + (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); + Fri, 20 Aug 2021 00:51:44 -0400 +Received: by mail-io1-f48.google.com with SMTP id z1so10629361ioh.7; + Thu, 19 Aug 2021 21:51:43 -0700 (PDT) +X-Gm-Message-State: AOAM530izsukbIFfIMbFryisXmGyaBN9dGnM0707CLSaEALKJHknuJ6u + oQsdNXDqXHDhWf/eNRGvmk+8pIRxW6QVXGMnN/w= +X-Google-Smtp-Source: ABdhPJybe4/3MIg6XNJlMsd4NuJYO6AQlwzpyJuHS2RYXmnNEyEol1QE/RuGbYBGY3mitUpOVPyfnN0NxjgUTd4mzkA= +X-Received: by 2002:a05:6638:250a:: with SMTP id + v10mr12839874jat.21.1629435103199; + Thu, 19 Aug 2021 21:51:43 -0700 (PDT) +MIME-Version: 1.0 +References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com> + <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com> + <20210810061441.6rg3quotiycomcp6@ganymede> + <CALZpt+G0CRitWLwUTA+7NnnZWNNrsEmFTMW3VmFSQ=vzXZOQGA@mail.gmail.com> + <20210812220339.GA3416@erisian.com.au> +In-Reply-To: <20210812220339.GA3416@erisian.com.au> +From: Jeremy <jlrubin@mit.edu> +Date: Thu, 19 Aug 2021 23:51:31 -0500 +X-Gmail-Original-Message-ID: <CAD5xwhiEDa2KjF265iDZ1ism4AFzh3S3D4cJSESVVKNwv9L7zA@mail.gmail.com> +Message-ID: <CAD5xwhiEDa2KjF265iDZ1ism4AFzh3S3D4cJSESVVKNwv9L7zA@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000082c90a05c9f66c01" +Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 20 Aug 2021 04:51:47 -0000 + +--00000000000082c90a05c9f66c01 +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. + +--00000000000082c90a05c9f66c01 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">one interesting point = +that came up at the bitdevs in austin today that favors remove that i belie= +ve is new to this discussion (it was new to me):</div><div class=3D"gmail_d= +efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col= +or:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:= +arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">the argument c= +an be reduced to:</div><div class=3D"gmail_default" style=3D"font-family:ar= +ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div c= +lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font= +-size:small;color:rgb(0,0,0)">- dust limit is a per-node relay policy.</div= +><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser= +if;font-size:small;color:rgb(0,0,0)">- it is rational for miners to mine du= +st outputs given their cost of maintenance=C2=A0(storing the output potenti= +ally forever) is lower than their immediate reward in fees.</div><div class= +=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz= +e:small;color:rgb(0,0,0)">- if txn relaying nodes censor something that a m= +iner would mine, users will seek a private/direct relay to the miner and vi= +ce versa.</div><div class=3D"gmail_default" style=3D"font-family:arial,helv= +etica,sans-serif;font-size:small;color:rgb(0,0,0)">- if direct relay to min= +er becomes popular, it is both bad for privacy and decentralization.</div><= +div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= +;font-size:small;color:rgb(0,0,0)">- therefore the dust limit, should there= + be demand to create dust at prevailing mempool feerates, causes an incenti= +ve to increase network centralization=C2=A0(immediately)</div><div class=3D= +"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s= +mall;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font= +-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">the tr= +adeoff is if a short term immediate incentive to promote network centraliza= +tion is better or worse than a long term node operator overhead.</div><div = +class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon= +t-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti= +ca,sans-serif;font-size:small;color:rgb(0,0,0)">///////////////////</div><d= +iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;= +font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" st= +yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0= +,0)">my take is that:</div><div class=3D"gmail_default" style=3D"font-famil= +y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><d= +iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;= +font-size:small;color:rgb(0,0,0)">1)=C2=A0having a dust limit is worse sinc= +e 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 no= +de operators to improve utreexo decentralizing software.</div><div class=3D= +"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s= +mall;color:rgb(0,0,0)">2) it's hard to quantify the magnitude of the in= +centives, which does matter.</div></div> + +--00000000000082c90a05c9f66c01-- + |