From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id A89F5C000B for ; 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 ; 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 ; 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 ; Sun, 6 Feb 2022 12:41:46 +0000 (UTC) Received: by mail-ej1-x636.google.com with SMTP id d10so34343136eje.10 for ; 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 Date: Sun, 6 Feb 2022 14:41:33 +0200 Message-ID: To: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Dear Bitcoin Developers,

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

-When I contacted bitInfoCharts to divide the first inte= rval of addresses, they kindly did divided to 3 intervals. From here:
=
-You can see that there are more th= an 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 sm= all values.
-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, this number= of dust UTXOs will probably increase with time.
.
-Therefore, a simple solution would be to fol= low 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<= /b> (at least for publicly known, published, burn addresses). Benefits a= re:

1- you wi= ll relieve the system state from the burden of about 3.8m = UTXOs=C2=A0
(3.148952m=C2=A0
+ 0.45m non-standard
+ 0.178m burned=C2=A0
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 amoun= t like 14.9 BTC.
3-You will remove away th= e risk of using any of these kinds for attacks as happened befor= e.
.
-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)
.
That's all
Thank you very much
.
Shymaa M Arafat

--0000000000006dd25605d758ceb7--