MIME-Version: 1.0
From: shymaa arafat <shymaa.arafat@gmail.com>
Date: Wed, 18 Aug 2021 21:06:30 +0200
Message-ID: <CAM98U8m9=D115g-wHuVsVcSP6z7Q0EqNt0bbQKFo00ZZx0QR1g@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="00000000000081e9ad05c9da2247"
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Precedence: list

--00000000000081e9ad05c9da2247
Content-Type: text/plain; charset="UTF-8"

Dear Sir,

I'm not discussing the dust limit here, but I'm suggesting some mitigations
to the dust problem which tackles almost the same points mentioned here
especially the scalability of the UTXOS set and the corresponding Merkle
proofs/witnesses in Utreexo or any similar design ....
.
I suggest:
1-Dust UTXOS, along with burned & non-standard UTXOS, to be stored
separately in secondary storage; their Hashes in a separate Merkle too in
any accumulator design
(an earlier draft of the idea
https://bitcointalk.org/index.php?topic=5343748.new#new)
.
-In fact, the idea of separating the real UTXO values was first suggested in
https://royalsocietypublishing.org/doi/10.1098/rsos.180817
In their words
"Similarly, one can think of a two-tier data structure where a UTXO subset
containing UTXOs with a low probability of being selected such as dust is
kept on disk, while the other UTXOs are kept in memory."
.
2-I suggest also that existing dust UTXOS (from the same paper, in some
cases a UTXO could be added as an extra input with the cost of 68*fee/byte)
, to be selected with large UTXO whenever they fit in a spending ( use one
large & one small to get rid of the small)
.
3-In general when user is not willing to leave the dust to the fee, and if
there's no dust UTXOS, do not let the coin selection algorithm select the
closest match; let it choose the smallest that doesn't create dust.
For example if there's UTXOS 0.00013 & 0.00012 and user want to spend
0.0001198 choose 0.00013 so that the change is not dust (with same cost).
.
Thank you for your time,
This is the first time I send a suggestion to your emailing list, so sorry
if I missed any regulations
.
Shymaa M. Arafat

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

<div dir=3D"auto">Dear Sir,<div dir=3D"auto"><br></div><div dir=3D"auto">I&=
#39;m not discussing the dust limit here, but I&#39;m suggesting some mitig=
ations to the dust problem which tackles almost the same points mentioned h=
ere especially the scalability of the UTXOS set and the corresponding Merkl=
e proofs/witnesses in Utreexo or any similar design ....</div><div dir=3D"a=
uto">.</div><div dir=3D"auto">I suggest:</div><div dir=3D"auto">1-Dust UTXO=
S, along with burned &amp; non-standard UTXOS, to be stored separately in s=
econdary storage; their Hashes in a separate Merkle too in any accumulator =
design</div><div dir=3D"auto">(an earlier draft of the idea</div><div dir=
=3D"auto"><a href=3D"https://bitcointalk.org/index.php?topic=3D5343748.new#=
new" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://bit=
cointalk.org/index.php?topic=3D5343748.new#new</a>)</div><div dir=3D"auto">=
.</div><div dir=3D"auto">-In fact, the idea of separating the real UTXO val=
ues was first suggested in</div><div dir=3D"auto"><a href=3D"https://royals=
ocietypublishing.org/doi/10.1098/rsos.180817" rel=3D"noreferrer noreferrer =
noreferrer" target=3D"_blank">https://royalsocietypublishing.org/doi/10.109=
8/rsos.180817</a></div><div dir=3D"auto">In their words</div><div dir=3D"au=
to">&quot;Similarly, one can think of a two-tier data structure where a UTX=
O subset containing UTXOs with a low probability of being selected such as =
dust is kept on disk, while the other UTXOs are kept in memory.&quot;</div>=
<div dir=3D"auto">.</div><div dir=3D"auto">2-I suggest also that existing d=
ust UTXOS (from the same paper, in some cases a UTXO could be added as an e=
xtra input with the cost of 68*fee/byte) , to be selected with large UTXO w=
henever they fit in a spending ( use one large &amp; one small to get rid o=
f the small)</div><div dir=3D"auto">.</div><div dir=3D"auto">3-In general w=
hen user is not willing to leave the dust to the fee,  and if there&#39;s n=
o dust UTXOS, do not let the coin selection algorithm select the closest ma=
tch; let it choose the smallest that doesn&#39;t create dust.</div><div dir=
=3D"auto">For example if there&#39;s UTXOS 0.00013 &amp; 0.00012 and user w=
ant to spend 0.0001198 choose 0.00013 so that the change is not dust (with =
same cost).</div><div dir=3D"auto">.</div><div dir=3D"auto">Thank you for y=
our time,</div><div dir=3D"auto">This is the first time I send a suggestion=
 to your emailing list, so sorry if I missed any regulations</div><div dir=
=3D"auto">.</div><div dir=3D"auto">Shymaa M. Arafat</div><div dir=3D"auto">=
<br></div></div>

--00000000000081e9ad05c9da2247--