From: shymaa arafat <shymaa.arafat@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
Date: Sun, 6 Feb 2022 14:41:33 +0200 [thread overview]
Message-ID: <CAM98U8kJVMJOQ++cyP3WXFRSHUZw0ySp3dVuZ=BzoRj2qE4Dug@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]
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 ≤ 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
[-- Attachment #2: Type: text/html, Size: 3239 bytes --]
next reply other threads:[~2022-02-06 12:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-06 12:41 shymaa arafat [this message]
2022-02-06 17:39 ` Pieter Wuille
2022-02-06 19:14 ` Eric Voskuil
2022-02-07 14:34 ` Billy Tetrud
2022-02-07 16:51 ` shymaa arafat
2022-02-13 9:56 ` yanmaani
2022-02-13 13:11 ` shymaa arafat
[not found] ` <382073c28af1ec54827093003cbec2cc@willtech.com.au>
[not found] ` <CAM98U8mJvYcBur01Z32TS4RYW+jMDCVQAUtrg5KXF+50d0zirA@mail.gmail.com>
2022-02-13 5:19 ` shymaa arafat
2022-02-18 3:36 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAM98U8kJVMJOQ++cyP3WXFRSHUZw0ySp3dVuZ=BzoRj2qE4Dug@mail.gmail.com' \
--to=shymaa.arafat@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox