path: root/4b/618db96c0a94b33f85d9149e7edebce385e74e

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&#39;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&#39;s hard to quantify the magnitude of the in=
centives, which does matter.</div></div>

--00000000000082c90a05c9f66c01--