path: root/6f/af0b81c4c47ca26c5f709e7fc2044c2b34ae70

Return-Path: <shymaa.arafat@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6F0C7C000E;
 Fri, 20 Aug 2021 05:45:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 5692B401B2;
 Fri, 20 Aug 2021 05:45:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HYFCU00lCp00; Fri, 20 Aug 2021 05:45:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com
 [IPv6:2607:f8b0:4864:20::1029])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 23E0E400D9;
 Fri, 20 Aug 2021 05:45:45 +0000 (UTC)
Received: by mail-pj1-x1029.google.com with SMTP id n5so6599345pjt.4;
 Thu, 19 Aug 2021 22:45:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=PrHBw3dx1oFexsTr4rXR24jU09QFyWORRvwRzEWEfHI=;
 b=Y3B1qdjMSXRSEjlkU69cpEmgujqFER0J0Shk2xjE0Cdhv39tbMgMn5adMQNQqSAZdK
 09EADcgDgmB9BihHWmazrTZQQVY7I2EfrTb0ifJ56ZKjtNGhRR1m1jiPPell6A38IoXV
 K3RJk2t86cH7MbbPGAh4PJL9QLBV998iZrESbDQkKoXEIhBXBrBU004j/OMWixVCZQwm
 VtXbyCuk3r16UFJ8aDQJmnDa78oVY+P8T/uztMD3oYom4teVlCo3QvzwedfS/+zmzxV2
 F/8/ajpeH2BRgrOJ1/qaDQB1o5KTqdHhpDYkTIzS+KshtVLDwK8XrqWl0plpVxZHt8Rf
 nCTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=PrHBw3dx1oFexsTr4rXR24jU09QFyWORRvwRzEWEfHI=;
 b=LpRlWExWe0Jqf3gP85jHm/xk3OWfQE/Miagd3e+hk/quLrJiwxxe37g1DN03JreLWS
 h/COtCwaabFa3912LfZwy8E5YWAjmQ402ndFW463W8EG0uHQ9DFMK16dhbaBKvyNiH+q
 kljJ3USMUP+MNHcX23iua7EtxJIqKx6WEovmBtTZ4NMVgr8W/O3HR3st+u+ZHLPzTjXE
 wVPQ/If5F/jHfm4sGKJe9kbkk5biuidi4ncz63DZ/Os2BnNw5g0T7xiJlLMkjBac95fy
 g2ks4TkMQ3uTEvq9qiWTcb6my4GyWeCMbY2FI5mGhrVwitc7hrQbZiQkS3BM7aUfAb0g
 nGVg==
X-Gm-Message-State: AOAM533vmxlSIweP1hj/ToPK4XSp73hlKQYMGuaWK/Cw+NMwjZNwwVTV
 l/sWcURmjJvhl0aJE4/MvjlX3SVGng2vnaz2xiE=
X-Google-Smtp-Source: ABdhPJy8zrXxapQYvpEUR4PlDpyXqJEgUtHPyBCay5CUd9Ek9Rm59VBJTDcPh6X1jOzZIyRF4elKWrce9qWFSk6+P4Y=
X-Received: by 2002:a17:90a:604e:: with SMTP id
 h14mr2844335pjm.181.1629438344531; 
 Thu, 19 Aug 2021 22:45:44 -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>
 <CAD5xwhiEDa2KjF265iDZ1ism4AFzh3S3D4cJSESVVKNwv9L7zA@mail.gmail.com>
In-Reply-To: <CAD5xwhiEDa2KjF265iDZ1ism4AFzh3S3D4cJSESVVKNwv9L7zA@mail.gmail.com>
From: shymaa arafat <shymaa.arafat@gmail.com>
Date: Fri, 20 Aug 2021 07:45:31 +0200
Message-ID: <CAM98U8nmzHOGNS63sw9C_U-capnaOBuMLYzOHaX7YMuk91JO4Q@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b591ac05c9f72dee"
X-Mailman-Approved-At: Fri, 20 Aug 2021 08:23:17 +0000
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 05:45:49 -0000

--000000000000b591ac05c9f72dee
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 20, 2021, 06:52 Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
>
-Here, u  r assuming miners not running full nodes, or even stateless nodes
as in Utreexo
-otherwise they suffer from storing dust UTXOS/their effect on proof
length, right?

- 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.
>
Why not having dust limit improves Utreexo, I think (and tried to suggest
many times) separate storing of dust&other non spendable UTXOS (and their
hashes) so that they do not affect other UTXOS proofs ( and not brought
into main memory unless called as a TXO)

2) it's hard to quantify the magnitude of the incentives, which does matter.
>
I honestly don't get the long term perspective of miners Incentivised to
storing small dust UTXOS instead of having their values added to the fee.

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000b591ac05c9f72dee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Fri, Aug 20, 2021, 06:52 Jeremy via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,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 beli=
eve is new to this discussion (it was new to me):</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor: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 =
can be reduced to:</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">- dust limit is a per-node relay policy.</di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">- it is rational for miners to mine d=
ust outputs given their cost of maintenance=C2=A0(storing the output potent=
ially forever) is lower than their immediate reward in fees.</div></div></b=
lockquote></div></div><div dir=3D"auto">-Here, u=C2=A0 r assuming miners no=
t running full nodes, or even stateless nodes as in Utreexo</div><div dir=
=3D"auto">-otherwise they suffer from storing dust UTXOS/their effect on pr=
oof length, right?</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">- if txn relaying nodes censor something tha=
t a miner would mine, users will seek a private/direct relay to the miner a=
nd vice versa.</div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- if direct relay t=
o miner 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 in=
centive to increase network centralization=C2=A0(immediately)</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize: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)">t=
he tradeoff is if a short term immediate incentive to promote network centr=
alization is better or worse than a long term node operator overhead.</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-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,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">///////////////////</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)">my take is that:</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">1)=C2=A0having a dust limit is worse=
 since we&#39;d rather not have an incentive to produce or roll out central=
izing software, whereas not having a dust limit creates an mild incentive f=
or node operators to improve utreexo decentralizing software.</div></div></=
blockquote></div></div><div dir=3D"auto">Why not having dust limit improves=
 Utreexo, I think (and tried to suggest many times) separate storing of dus=
t&amp;other non spendable UTXOS (and their hashes) so that they do not affe=
ct other UTXOS proofs ( and not brought into main memory unless called as a=
 TXO)</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">2) it&#39;s hard to quantify the magnitude of the incenti=
ves, which does matter.</div></div></blockquote></div></div><div dir=3D"aut=
o">I honestly don&#39;t get the long term perspective of miners Incentivise=
d to storing small dust UTXOS instead of having their values added to the f=
ee.</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--000000000000b591ac05c9f72dee--