path: root/79/a9c863f9193bf0ff28f18ed47c57cfd93b2a8d

Return-Path: <shymaa.arafat@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A89F5C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Feb 2022 12:41:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 834408149C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Feb 2022 12:41:47 +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_20=-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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 2l8V2Zg_XrwG
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Feb 2022 12:41:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [IPv6:2a00:1450:4864:20::636])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 19F0081499
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Feb 2022 12:41:46 +0000 (UTC)
Received: by mail-ej1-x636.google.com with SMTP id d10so34343136eje.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 06 Feb 2022 04:41:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=B0nuLCjzB1MOiYw6m9MzbF6jhIiX8UwZ1I7kZP7FEAY=;
 b=eoRf7SCor9/gYb7Q1JS4JqR+gE1HbDBT9/H4QFwtMH8T5Qx6NdCVZGHNnYCkJbPkFy
 fsOSse+MYP9azKCVbvnt8tlneVTR5cszqgvoTMoYkFCo/PodeDEXlB+P4pmkEsETDPgg
 x3BLzVMTfsDNgOhrEZuLsvxh5Ow0I2K2ZPKS7u8JaiFcJtxsRqHzSYtSGzujSwt20SOh
 B4tXt3ZywSARMlZqcTO5CsdotdoIL/63Vd/aZDoGQUc5KPPTacboxqCPgsFkKabTy/47
 E30M5mhMhfbTLXWGB1l6lXVZKpmF36QGvllPmI3KBSX9o0ccutQFkfMxSAXF+j2qoEgz
 YRFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=B0nuLCjzB1MOiYw6m9MzbF6jhIiX8UwZ1I7kZP7FEAY=;
 b=00YE0YrwZeDB9xK2mzHe8W5netIcRgThHmgNVfnuLcvbUxDL2k/hzdJlPu80TTevhl
 4Ec9Hgc63z6XoNbq3twQxLVR8OrjeUTM1ArUWpZnRJcIB6LkFXpBvjj+DvHQxq0sYVIa
 U5zgu8Py8OvPnaslbeDT6H+g1cg005kkXAjD6hZE2Q0A+4uMBFguZiOYfersEjej1GjY
 Al0vz5biL8AO38HOwz1ao0HoGgc+U9+3S+6/x+ajkLqtPvIhWmyTMsxGGhZHqyytlWL1
 NoGsFRdpNX6UYfqBdshU155qRPUJGDsI4uYHUPi3+oiCEVdxtEgUCCgwjlsXZFamBWAS
 G/4g==
X-Gm-Message-State: AOAM533LzFBAIWAFZlvgnZsnNW5nnhHMF6DcCAQI+mpbmN1xN8B2lO7n
 4PwWJc2o4f6yFqRfDBcX5Flm/GSB+B+COZzxS72R9W+7
X-Google-Smtp-Source: ABdhPJzRIcTMtIk6+9deCsPRrVwPJYZp6iACSLbNC0XetwiLT7Nx8pmzNqFRsXLVGGHhdAx5j/HmnLzcgM7qzs64sXU=
X-Received: by 2002:a17:907:7f91:: with SMTP id
 qk17mr6227856ejc.686.1644151303949; 
 Sun, 06 Feb 2022 04:41:43 -0800 (PST)
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"
X-Mailman-Approved-At: Sun, 06 Feb 2022 16:30:46 +0000
Subject: [bitcoin-dev] A suggestion to periodically destroy (or remove to
 secondary storage for Archiving reasons) dust, Non-standard UTXOs,
 and also detected burn
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: Sun, 06 Feb 2022 12:41:47 -0000

--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--