MIME-Version: 1.0
From: shymaa arafat <shymaa.arafat@gmail.com>
Date: Sun, 6 Feb 2022 14:41:33 +0200
Message-ID: <CAM98U8kJVMJOQ++cyP3WXFRSHUZw0ySp3dVuZ=BzoRj2qE4Dug@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006dd25605d758ceb7"
Subject: [bitcoin-dev] A suggestion to periodically destroy (or remove to
 secondary storage for Archiving reasons) dust, Non-standard UTXOs,
 and also detected burn
Precedence: list

--0000000000006dd25605d758ceb7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Bitcoin Developers,

-I think you may remember me sending to you about my proposal to partition
( and other stuff all about) the UTXO set Merkle in bridge servers
providing proofs Stateless nodes.
-While those previous suggestions might not have been on the most interest
of core Developers, I think this one I happened to notice is:

-When I contacted bitInfoCharts to divide the first interval of addresses,
they kindly did divided to 3 intervals. From here:
https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
-You can see that there are *more than* *3.1m addresses* holding =E2=89=A4 =
0.000001
BTC (1000 Sat) with total value of *14.9BTC*; an average of *473 Sat* per
address.
-Keeping in mind that an address can hold more than 1 UTXO; ie, this is
even a lowerbound on the number of UTXOs holding such small values.
-Noticing also that every lightning network transaction adds one dust UTXO
(actually two one of which is instantly spent, and their dust limit is 333
Sat not even 546), ie, *this number of dust UTXOs will probably increase
with time.*
.
-Therefore, a simple solution would be to follow the difficulty adjustment
idea and just *delete all those*, or at least remove them to secondary
storage for Archiving with extra cost to get them back, *along with
non-standard UTXOs and Burned ones* (at least for publicly known,
published, burn addresses). *Benefits are:*

1- you will *relieve* the system state from the burden *of about 3.8m
UTXOs *
(*3.148952m*
+ *0.45m* non-standard
+ *0.178m* burned
https://blockchair.com/bitcoin/address/1111111111111111111114oLvT2
https://blockchair.com/bitcoin/address/1CounterpartyXXXXXXXXXXXXXXXUWLpVr
as of today 6Feb2022)
, a number that will probably increase with time.
2-You will add to the *scarcity* of Bitcoin even with a very small amount
like 14.9 BTC.
3-You will *remove* away *the risk of using* any of these kinds for
*attacks* as happened before.
.
-Finally, the parameters could be studied for optimal values; I mean the
1st delete, the periodical interval, and also the delete threshold (maybe
all holding less than 1$ not just 546 Sat need to be deleted)
.
That's all
Thank you very much
.
Shymaa M Arafat

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

<div dir=3D"auto">Dear Bitcoin Developers,<div dir=3D"auto"><br><div dir=3D=
"auto">-I think you may remember me sending to you about my proposal to par=
tition ( and other stuff all about) the UTXO set Merkle in bridge servers p=
roviding proofs Stateless nodes.</div><div dir=3D"auto">-While those previo=
us suggestions might not have been on the most interest of core Developers,=
 I think this one I happened to notice is:</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">-When I contacted bitInfoCharts to divide the first inte=
rval of addresses, they kindly did divided to 3 intervals. From here:</div>=
<div dir=3D"auto"><a href=3D"https://bitinfocharts.com/top-100-richest-bitc=
oin-addresses.html">https://bitinfocharts.com/top-100-richest-bitcoin-addre=
sses.html</a></div><div dir=3D"auto">-You can see that there are <u>more th=
an</u> <u>3.1m addresses</u> holding =E2=89=A4 0.000001 BTC (1000 Sat) with=
 total value of <u>14.9BTC</u>; an average of <u>473 Sat</u> per address.</=
div><div dir=3D"auto">-Keeping in mind that an address can hold more than 1=
 UTXO; ie, this is even a lowerbound on the number of UTXOs holding such sm=
all values.</div><div dir=3D"auto">-Noticing also that every lightning netw=
ork transaction adds one dust UTXO (actually two one of which is instantly =
spent, and their dust limit is 333 Sat not even 546), ie, <b><u>this number=
 of dust UTXOs will probably increase with time.</u></b></div><div dir=3D"a=
uto">.</div><div dir=3D"auto">-Therefore, a simple solution would be to fol=
low the difficulty adjustment idea and just <u><b>delete all those</b></u>,=
 or at least remove them to secondary storage for Archiving with extra cost=
 to get them back, <b><u>along with non-standard UTXOs and Burned ones</u><=
/b> (at least for publicly known, published, burn addresses). <u>Benefits a=
re:</u></div><div dir=3D"auto"><u><br></u></div><div dir=3D"auto">1- you wi=
ll <u>relieve</u> the system state from the burden <u>of about <b>3.8m</b> =
UTXOs=C2=A0</u></div><div dir=3D"auto">(<b>3.148952m</b>=C2=A0</div><div di=
r=3D"auto">+ <b>0.45m</b> non-standard</div><div dir=3D"auto">+ <b>0.178m</=
b> burned=C2=A0</div><div dir=3D"auto"><a href=3D"https://blockchair.com/bi=
tcoin/address/1111111111111111111114oLvT2">https://blockchair.com/bitcoin/a=
ddress/1111111111111111111114oLvT2</a><br></div><div dir=3D"auto"><a href=
=3D"https://blockchair.com/bitcoin/address/1CounterpartyXXXXXXXXXXXXXXXUWLp=
Vr">https://blockchair.com/bitcoin/address/1CounterpartyXXXXXXXXXXXXXXXUWLp=
Vr</a></div><div dir=3D"auto">as of today 6Feb2022)</div><div dir=3D"auto">=
, a number that will probably increase with time.</div><div dir=3D"auto">2-=
You will add to the <u>scarcity</u> of Bitcoin even with a very small amoun=
t like 14.9 BTC.</div><div dir=3D"auto">3-You will <u>remove</u> away <u>th=
e risk of using</u> any of these kinds for <u>attacks</u> as happened befor=
e.</div><div dir=3D"auto">.</div><div dir=3D"auto">-Finally, the parameters=
 could be studied for optimal values; I mean the 1st delete, the periodical=
 interval, and also the delete threshold (maybe all holding less than 1$ no=
t just 546 Sat need to be deleted)</div><div dir=3D"auto">.</div><div dir=
=3D"auto">That&#39;s all</div><div dir=3D"auto">Thank you very much</div><d=
iv dir=3D"auto">.</div><div dir=3D"auto">Shymaa M Arafat</div><div dir=3D"a=
uto"><br></div></div></div>

--0000000000006dd25605d758ceb7--