From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: <20210810061441.6rg3quotiycomcp6@ganymede> <20210812220339.GA3416@erisian.com.au> In-Reply-To: <20210812220339.GA3416@erisian.com.au> From: Jeremy Date: Thu, 19 Aug 2021 23:51:31 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000082c90a05c9f66c01" Cc: lightning-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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):

the argument c= an be reduced to:

- dust limit is a per-node relay policy.
- 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.
- 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.
- if direct relay to min= er becomes popular, it is both bad for privacy and decentralization.
<= 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)

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.


///////////////////

my take is that:

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.
2) it's hard to quantify the magnitude of the in= centives, which does matter.
--00000000000082c90a05c9f66c01--