MIME-Version: 1.0
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
 <20210808215101.wuaidu5ww63ajx6h@ganymede>
 <MkPutJpff5rqUxXFQrEyHZl6Iz0DfrJU_-BQD-y0El65GQFnj7igVfmWU79fPCtiFztUYl4ofzrqeaN0HFMB45YPErY9rYY7_h1XkuTMfvc=@wuille.net>
 <CAJowKgKt=yYdNOYYNsWh7FJ2EH7rz0bd2EjUjmyA=cA6k5cvUQ@mail.gmail.com>
 <BtaljKLqpe75GB6pHEPQMF6_L-hBaE0ZCBGaXrUfnHRYeEbCqFWZ12DaMRm5jEADceL3uPfCiL-WU9MOZJ_m54Zi3Pzu0vSFN3nQvuSKvBM=@protonmail.com>
 <CAM98U8nSOQ9HpdRLBdkcFAdToW=z7_EhnYisMb7F46ExmJkT-w@mail.gmail.com>
 <ZKZ4RR6uAv0mG8yFQyRkWDTFQ7JnsGVfLQcMTmsc5ui7MTJXuzMkVk5YQTniPuc4F_KRhn7BEZZHEK60IZYZYU9A1r-tbmfPTnIs0pOd7oU=@protonmail.com>
 <CAM98U8kKud-7QoJKYd5o245o8vGeUD7YD2OnXF_QeKaO33dSTw@mail.gmail.com>
 <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com>
In-Reply-To: <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com>
From: shymaa arafat <shymaa.arafat@gmail.com>
Date: Fri, 8 Oct 2021 09:44:59 +0200
Message-ID: <CAM98U8=NGcwoip5CVKrT2LNWjinCogxRjEYLxMtQ4-O+49wsLw@mail.gmail.com>
To: lightning-dev <lightning-dev@lists.linuxfoundation.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000019b70005cdd28f2e"
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Precedence: list

--00000000000019b70005cdd28f2e
Content-Type: text/plain; charset="UTF-8"

The suggested idea I was replying to is to make all dust TXs invalid by
some nodes. I suggested a compromise by keeping them in secondary storage
for full nodes, and in a separate Merkle Tree for bridge servers.
-In bridge servers they won't increase any worstcase, on the contrary this
will enhance the performance even if slightly.
-In full nodes, and since they will usually appear in clusters, they will
be fetched rarely (either by a dust sweeping action, or a malicious
attacker)
In both cases as a batch
-To not exhaust the node with DoS(as the reply mentioned)one may think of
uploading the whole dust partition if they were called more than certain
threshold (say more than 1 Tx in a block)
-and then keep them there for "a while", but as a separate partition too to
exclude them from any caching mechanism after that block.
-The "while" could be a tuned parameter.
-Take care that the more dust is sweeped, the less dust to remain in the
UTXO set; as users are already much dis-incentivised to create more.
.
Thanks for allowing the reply

On Thu, Oct 7, 2021, 16:43 ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

>
>
> > I don't know what brings up sorting here, unless as an example.
>
> Yes, it is an example: quicksort is bad for network-facing applications
> because its ***worst-case behavior*** is bad.
> Bitcoin is a network-facing application, and similarly, ***worst-case
> behavior*** being bad is something that would strongly discourage
> particular approaches.
> Your proposal risks bad ***worst-case behavior***.
>
> > Anyways, I was comparing to rejecting them completely, not to keeping
> them in one set. In addition, those dust sweep Transactions will probably
> be a dust sweep and thus contain so many inputs which "maybe" makes 1-one
> disk visit  to fetch all their hashes at once, 2-from a smaller subset with
> max size 5-10% the UTXO set, justifiable.
>
> Do not consider the ***average case*** where a block is composed of only a
> few dust sweep transactions and most transactions are normal,
> non-dust-sweep transactions.
>
> Instead, consider the ***worst case*** where ***all*** transactions in a
> block are dust sweep transactions, because that is what attackers will use.
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"auto"><div>The suggested idea I was replying to is to make all =
dust TXs invalid by some nodes. I suggested a compromise by keeping them in=
 secondary storage for full nodes, and in a separate Merkle Tree for bridge=
 servers.</div><div dir=3D"auto">-In bridge servers they won&#39;t increase=
 any worstcase, on the contrary this will enhance the performance even if s=
lightly.</div><div dir=3D"auto">-In full nodes, and since they will usually=
 appear in clusters, they will be fetched rarely (either by a dust sweeping=
 action, or a malicious attacker)</div><div dir=3D"auto">In both cases as a=
 batch</div><div dir=3D"auto">-To not exhaust the node with DoS(as the repl=
y mentioned)one may think of uploading the whole dust partition if they wer=
e called more than certain threshold (say more than 1 Tx in a block)=C2=A0=
=C2=A0</div><div dir=3D"auto">-and then keep them there for &quot;a while&q=
uot;, but as a separate partition too to exclude them from any caching mech=
anism after that block.</div><div dir=3D"auto">-The &quot;while&quot; could=
 be a tuned parameter.</div><div dir=3D"auto">-Take care that the more dust=
 is sweeped, the less dust to remain in the UTXO set; as users are already =
much dis-incentivised to create more.</div><div dir=3D"auto">.</div><div di=
r=3D"auto">Thanks for allowing the reply</div><div dir=3D"auto"><br><div cl=
ass=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On T=
hu, Oct 7, 2021, 16:43 ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.c=
om" target=3D"_blank" rel=3D"noreferrer">ZmnSCPxj@protonmail.com</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
&gt; I don&#39;t know what brings up sorting here, unless as an example.<br=
>
<br>
Yes, it is an example: quicksort is bad for network-facing applications bec=
ause its ***worst-case behavior*** is bad.<br>
Bitcoin is a network-facing application, and similarly, ***worst-case behav=
ior*** being bad is something that would strongly discourage particular app=
roaches.<br>
Your proposal risks bad ***worst-case behavior***.<br>
<br>
&gt; Anyways, I was comparing to rejecting them completely, not to keeping =
them in one set. In addition, those dust sweep Transactions will probably b=
e a dust sweep and thus contain so many inputs which &quot;maybe&quot; make=
s 1-one disk visit=C2=A0 to fetch all their hashes at once, 2-from a smalle=
r subset with max size 5-10% the UTXO set, justifiable.<br>
<br>
Do not consider the ***average case*** where a block is composed of only a =
few dust sweep transactions and most transactions are normal, non-dust-swee=
p transactions.<br>
<br>
Instead, consider the ***worst case*** where ***all*** transactions in a bl=
ock are dust sweep transactions, because that is what attackers will use.<b=
r>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div></div>

--00000000000019b70005cdd28f2e--