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"
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Precedence: list

--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--