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>
In-Reply-To: <50s2eg2qZ_BSHhI1mT_mHP7fkDQ8EXnakOb9NmDfZlx_hN44l37UmopfAr2V4ws4yhx0YihNYBIOelJ01vhITI8K4G1UgmobTwf9FyJq_Yo=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 26 Aug 2021 14:21:25 -0700
Message-ID: <CAGpPWDbseo6eYT1a54YB2-fpxpzj2cg9DL+s2_rpoa+dGfnhaQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000015e76605ca7cf4aa"
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Precedence: list

--00000000000015e76605ca7cf4aa
Content-Type: text/plain; charset="UTF-8"

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
>

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

<div dir=3D"ltr"><div><br></div><div><span style=3D"color:rgb(0,0,0);font-f=
amily:arial,helvetica,sans-serif">One interesting thing I thought of: the c=
ost of maintenance of the dust creates a (very) small incentive to mine tra=
nsactions that *use* dust outputs with a slightly lower fee that contain du=
st, in order to reduce the future maintenance cost for themselves. However,=
 the rational discount would likely be vanishingly small.=C2=A0 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 removi=
ng them from the system (saving the future cost of maintenance) is approxim=
ately equal to the amount that the fee could be made lower for such transac=
tions. Even measuring this as a value over the whole (future) bitcoin netwo=
rk, I&#39;m not sure how to evaluate the magnitude of this future cost. </s=
pan><br></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvet=
ica,sans-serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-=
family:arial,helvetica,sans-serif"><br></span></div><div><span style=3D"col=
or:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div=
><span style=3D"color:rgb(0,0,0);font-family: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@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px 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" target=3D"_blank">http=
s://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.m=
d#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" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000015e76605ca7cf4aa--