path: root/b0/5426bd02170fa3aca23531a5c7afa00c06e5f6

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 A0FEDC000E;
 Fri, 27 Aug 2021 09:07:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 7BD4940248;
 Fri, 27 Aug 2021 09:07:53 +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 iEZdA_ctZY_0; Fri, 27 Aug 2021 09:07:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com
 [IPv6:2607:f8b0:4864:20::434])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 3B5B54020A;
 Fri, 27 Aug 2021 09:07:49 +0000 (UTC)
Received: by mail-pf1-x434.google.com with SMTP id x16so5178334pfh.2;
 Fri, 27 Aug 2021 02:07:49 -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=CYk3x4sVWRyTu3atf33VSDDyprD60ZtCoISlClQ/nOk=;
 b=aS2VyNj37snuOFGLoY6U+49P1ZRw0kgh9tKPpehSOAzRirna8NX11kSmWXBUNDx1NU
 ovopeBfNGYItoduAniC5bFP3/XD+DWbTdnescP2hyUZQB0iDF0zTxq8zkoKHwpHUXgRP
 wvXHmK5IlshVmNkyvOVcwIEIB4eTCYKu1FDShBGN8evID9KOT3Opi0KQQOTBi/IN6I6d
 S7/gdCPRAe88uatdoweih+6DfgfaUa/dVccPElBz6UsAPcku2/INOQLcaBORMr643Pus
 Rwq2IgciBWpL0QXGqNA//53f/+p2wC8IZMhyjSWSzu1AapGWsUVOapWDXMH1o/FVY+gh
 H0ZA==
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=CYk3x4sVWRyTu3atf33VSDDyprD60ZtCoISlClQ/nOk=;
 b=DLAOH4g2OzRHHv7WiOaToZyotw0RcmBQ9TZ3j3cXzbDDgGEe4ipEQHDSV7fMtVEgKk
 1rQEfRUefWxtsCzmYvZpX28bRSl+eJyw5oAdfjb0Z+1qjBl5ZNxPQhojShQoa89chPOs
 i583SLO3AlsFU1w0IYbntRvVbuH5QlWh7A0ynv1UUdPmmQWiX8NFC5wRDttrD0fPZZz+
 qyBYBPBYZi8FetN1lZllMXE7A0/TK8gjoTfkmzXM+9e4GTTfASSG3GBG4eId1gQHdJWN
 YOBpj1SxyY6/vuH8LOCDZcRPjY3PRXDFU00IuWUh4CMvXF17b6eRV9Js8g9assFuctkO
 cR2w==
X-Gm-Message-State: AOAM532QW/A3bx3DzXj9wT78Sqf/zepYQfJomm1c67E3o2AERpplteUG
 /7S1PTGtjynQkSwLoXGxXkgr4///whujtiydIRg=
X-Google-Smtp-Source: ABdhPJxc3RTu2CZaLYrHnR+eNSV93XngxpXSsmdUdQ2ZRcbx2Y8H1oJ9DekKmnFxnSfGXHLkCz+aVwgi99oVxa+OMqk=
X-Received: by 2002:a63:5024:: with SMTP id e36mr7127763pgb.66.1630055268586; 
 Fri, 27 Aug 2021 02:07:48 -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>
 <50s2eg2qZ_BSHhI1mT_mHP7fkDQ8EXnakOb9NmDfZlx_hN44l37UmopfAr2V4ws4yhx0YihNYBIOelJ01vhITI8K4G1UgmobTwf9FyJq_Yo=@protonmail.com>
 <CAGpPWDbseo6eYT1a54YB2-fpxpzj2cg9DL+s2_rpoa+dGfnhaQ@mail.gmail.com>
In-Reply-To: <CAGpPWDbseo6eYT1a54YB2-fpxpzj2cg9DL+s2_rpoa+dGfnhaQ@mail.gmail.com>
From: shymaa arafat <shymaa.arafat@gmail.com>
Date: Fri, 27 Aug 2021 11:07:35 +0200
Message-ID: <CAM98U8nOqvOSBvP15dGup-LoW-af9EHFKyTy_XDOjfR-NGjJYA@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003f99e905ca86d1a5"
X-Mailman-Approved-At: Fri, 27 Aug 2021 09:16:57 +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, 27 Aug 2021 09:07:53 -0000

--0000000000003f99e905ca86d1a5
Content-Type: text/plain; charset="UTF-8"

Allow me to ask:

-Untill you find a mitigation that consolidate all dust UTXOS, why don't
you separate them and all probably Unspendable UTXOS in a different
partition?
-I'm talking at the real UTXO storage level (to be kept in secondary
storage), and at the Merkleization level in any accumulator design Utreexo
or what so ever(putting them in one or two subtree/forest with hardly
changing roots according to the categorization will reduce the proof size,
even if slightly)
-This will also help things like Bloom filters, assume UTXOs,...etc when
about 10% with almost zero probability are trimmed from the pool you are
withdrawing from.
.
-The paper I mentioned earlier says in Feb 2018, there was about 2.4m UTXOS
less than 1000 Satoshi, of which ~824,892 holds exactly 1 Satoshi
-I don't think any of those were spent since that time, in fact there could
be a possibility that the numbers may have increased
-As the last previous reply mentioned you have to consider the long run
effect on the UTXO set forever, this is a straight forward improvement that
comes with almost no effort
.
Ps.
-If there is something wrong, something I missed in this idea please
explain it to me
-Or do you find the improvement itself a "dust" that doesn't worth the
effort???
.
Regards & thank you all for your time in reading & replying
Shymaa M. Arafat
On Fri, Aug 27, 2021, 00:06 Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> One interesting thing I thought of: the cost of maintenance of the dust
> creates a (very) small incentive to mine transactions that *use* dust
> outputs with a slightly lower fee that contain dust, in order to reduce the
> future maintenance cost for themselves. However, the rational discount
> would likely be vanishingly small.  It would be interesting to add
> something to the consensus rules to decrease the vbytes for a transaction
> that consumes dust outputs such that the value of removing them from the
> system (saving the future cost of maintenance) is approximately equal to
> the amount that the fee could be made lower for such transactions. Even
> measuring this as a value over the whole (future) bitcoin network, I'm not
> sure how to evaluate the magnitude of this future cost.
>
>
>
>
>
> On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning Jeremy,
>>
>> > 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.
>>
>> Against the above, we should note that in the Lightning spec, when an
>> output *would have been* created that is less than the dust limit, the
>> output is instead put into fees.
>>
>> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs
>>
>> Thus, the existence of a dust limit encourages L2 protocols to have
>> similar rules, where outputs below the dust limit are just given over as
>> fees to miners, so the existence of a dust limit might very well be
>> incentivize-compatible for miners, regardless of centralization effects or
>> not.
>>
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto"><div dir=3D"auto"></div>Allow me to ask:<div dir=3D"auto"=
><br><div dir=3D"auto"><div dir=3D"auto">-Untill you find a mitigation that=
 consolidate all dust UTXOS, why don&#39;t you separate them and all probab=
ly Unspendable UTXOS in a different partition?</div><div dir=3D"auto">-I&#3=
9;m talking at the real UTXO storage level (to be kept in secondary storage=
), and at the Merkleization level in any accumulator design Utreexo or what=
 so ever(putting them in one or two subtree/forest with hardly changing roo=
ts according to the categorization will reduce the proof size, even if slig=
htly)</div><div dir=3D"auto">-This will also help things like Bloom filters=
, assume UTXOs,...etc when about 10% with almost zero probability are trimm=
ed from the pool you are withdrawing from.</div><div dir=3D"auto">.</div><d=
iv dir=3D"auto">-The paper I mentioned earlier says in Feb 2018, there was =
about 2.4m UTXOS less than 1000 Satoshi, of which ~824,892 holds exactly 1 =
Satoshi</div><div dir=3D"auto">-I don&#39;t think any of those were spent s=
ince that time, in fact there could be a possibility that the numbers may h=
ave increased</div><div dir=3D"auto">-As the last previous reply mentioned =
you have to consider the long run effect on the UTXO set forever, this is a=
 straight forward improvement that comes with almost no effort</div><div di=
r=3D"auto">.</div><div dir=3D"auto">Ps.</div><div dir=3D"auto">-If there is=
 something wrong, something I missed in this idea please explain it to me</=
div><div dir=3D"auto">-Or do you find the improvement itself a &quot;dust&q=
uot; that doesn&#39;t worth the effort???</div><div dir=3D"auto">.</div><di=
v dir=3D"auto">Regards &amp; thank you all for your time in reading &amp; r=
eplying</div><div dir=3D"auto">Shymaa M. Arafat</div><div dir=3D"auto"><div=
 class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Fri, Aug 27, 2021, 00:06 Billy Tetrud via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer noreferrer" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></di=
v><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><br></div><div><span=
 style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">One inte=
resting thing I thought of: the cost of maintenance of the dust creates a (=
very) small incentive to mine transactions that *use* dust outputs with a s=
lightly lower fee that contain dust, in order to reduce the future maintena=
nce cost for themselves. However, the rational discount would likely be van=
ishingly small.=C2=A0 It would be interesting to add something to the conse=
nsus rules to decrease the vbytes for a transaction that consumes dust outp=
uts such that the value of removing them from the system (saving the future=
 cost of maintenance) is approximately equal to the amount that the fee cou=
ld be made lower for such transactions. Even measuring this as a value over=
 the whole (future) bitcoin network, I&#39;m not sure how to evaluate the m=
agnitude of this future cost. </span><br></div><div><span style=3D"color:rg=
b(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><spa=
n style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></s=
pan></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,=
sans-serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-fami=
ly:arial,helvetica,sans-serif">=C2=A0</span><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Aug 20, 2021=
 at 8:12 PM ZmnSCPxj via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" rel=3D"noreferrer noreferrer noreferrer" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">Good morning Jeremy,<br>
<br>
&gt; 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):=
<br>
&gt;<br>
&gt; the argument can be reduced to:<br>
&gt;<br>
&gt; - dust limit is a per-node relay policy.<br>
&gt; - it is rational for miners to mine dust outputs given their cost of m=
aintenance=C2=A0(storing the output potentially forever) is lower than thei=
r immediate reward in fees.<br>
&gt; - if txn relaying nodes censor something that a miner would mine, user=
s will seek a private/direct relay to the miner and vice versa.<br>
&gt; - if direct relay to miner becomes popular, it is both bad for privacy=
 and decentralization.<br>
&gt; - therefore the dust limit, should there be demand to create dust at p=
revailing mempool feerates, causes an incentive to increase network central=
ization=C2=A0(immediately)<br>
&gt;<br>
&gt; the tradeoff is if a short term immediate incentive to promote network=
 centralization is better or worse than a long term node operator overhead.=
<br>
<br>
Against the above, we should note that in the Lightning spec, when an outpu=
t *would have been* created that is less than the dust limit, the output is=
 instead put into fees.<br>
<a href=3D"https://github.com/lightningnetwork/lightning-rfc/blob/master/03=
-transactions.md#trimmed-outputs" rel=3D"noreferrer noreferrer noreferrer n=
oreferrer" target=3D"_blank">https://github.com/lightningnetwork/lightning-=
rfc/blob/master/03-transactions.md#trimmed-outputs</a><br>
<br>
Thus, the existence of a dust limit encourages L2 protocols to have similar=
 rules, where outputs below the dust limit are just given over as fees to m=
iners, so the existence of a dust limit might very well be incentivize-comp=
atible for miners, regardless of centralization effects or not.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div></div></div>

--0000000000003f99e905ca86d1a5--