public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: shymaa arafat <shymaa.arafat@gmail•com>
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	 lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: Re: [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, 13 Feb 2022 07:19:04 +0200	[thread overview]
Message-ID: <CAM98U8=Skhz8ETxHd+aBZssHDcj3qNikDa_JYuR5dcSMUJP32g@mail.gmail.com> (raw)
In-Reply-To: <CAM98U8mJvYcBur01Z32TS4RYW+jMDCVQAUtrg5KXF+50d0zirA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6194 bytes --]

I just want to add an alarming info to this thread...

*There are at least 5.7m UTXOs≤1000 Sat (~7%), *
*8.04 m ≤1$ (10%), *
*13.5m ≤ 0.0001BTC (17%)*

It seems that bitInfoCharts took my enquiry seriously and added a main link
for dust analysis:
https://bitinfocharts.com/top-100-dustiest-bitcoin-addresses.html
Here, you can see just *the first address contains more than 1.7m dust
UTXOs*
(ins-outs =1,712,706 with a few real UTXOs holding the bulk of 415 BTC)
https://bitinfocharts.com/bitcoin/address/1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ

»»»»»
 That's alarming isn't it?, is it due to the lightning networks protocol or
could be some other weird activity going on?
.
The following address are similar but less severe
~394k UTXOs, 170k, 92k, 10*20k, 4or5 *14k,...etc
add at least 2.7m UTXOs coming from addresses with a higher balance to the
interval numbers here (calculated & mentioned in my previous email)
https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html


I think it seems bitInfoCharts will probably make their own report about it
soon

Regards
Shymaa M. Arafat

On Wed, Feb 9, 2022, 07:19 shymaa arafat <shymaa.arafat@gmail•com> wrote:

> If 1 Sat reached 100$, you may adjust the delete( or call it omitting or
> trimming) threshold, since you will need to acquire decimal places inside
> the Sat variable too ( people may have TXs less than 100$)
>
> -Talking with today's numbers,
> https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
>
> it is hard to imagine that someone's all holdings in Bitcoin is just ≤1000
> Sat (3.15 m address) or even ≤10,000 Sat (4.1$, with currently 7.6m
> addresses in addition to the 3.15m)
> So we'll just incentivise those people to find a low fee time in say a 6
> month interval and collect those UTXOs into one of at least 5$
> (10.86m≤4.1$) or 1$ (5.248m≤1$) your decision.
>
> -During 4 days after showing the smaller intervals, those ≤1000Sat
> increase by ~2K everyday with total holding increased by 0.01BTC. Addresses
> in millions:
> 3.148, 3.1509, 3.152895, 3.154398
> Total BTC:
> 14.91,14.92,14.93,14.94
>
> -The number of ≤10,000 Sat increases by 4-8 k per day.
> Addresses in millions:
> 7.627477, 7.631436, 7.639287, 7.644925
> Total BTC
> 333.5, 333.63, 333.89, 334.1
>
> -remember that no. of addresses is a lowerbound on no. of UTXOs; ie., the
> real numbers could be even more.
> .
> + There's also non-standard & burned , yes they're about 0.6m UTXOs, but
> they're misleading on the status of the value they hold.
> .
> At the end, I'm just suggesting...
> .
> Regards,
> Shymaa
>
> On Wed, Feb 9, 2022, 00:16 <damian@willtech•com.au> wrote:
>
>> Good Morning,
>>
>> I wish to point out that because fees are variable there is no reason
>> fees could not be less than 1 sat in future if fees climb. You may
>> consider this optimistic but I recall in the first days of Bitcoin when
>> fees were voluntary. It is not unreasonable provided the fungibility
>> (money-like-quality) of Bitcoin is maintained for 1 sat to be worth over
>> $100.00 in the future.
>>
>> KING JAMES HRMH
>> Great British Empire
>>
>> Regards,
>> The Australian
>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>> of Hougun Manor & Glencoe & British Empire
>> MR. Damian A. James Williamson
>> Wills
>>
>> et al.
>>
>>
>> Willtech
>> www.willtech.com.au
>> www.go-overt.com
>> duigco.org DUIGCO API
>> and other projects
>>
>>
>> m. 0487135719
>> f. +61261470192
>>
>>
>> This email does not constitute a general advice. Please disregard this
>> email if misdelivered.
>> --------------
>> On 2022-02-06 09:39, Pieter Wuille via bitcoin-dev wrote:
>> >> Dear Bitcoin Developers,
>> >
>> >> -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.
>> >
>> >> -Therefore, a simple solution would be to follow the difficulty
>> >> adjustment idea and just delete all those
>> >
>> > That would be a soft-fork, and arguably could be considered theft.
>> > While commonly (but non universally) implemented standardness rules
>> > may prevent spending them currently, there is no requirement that such
>> > a rule remain in place. Depending on how feerate economics work out in
>> > the future, such outputs may not even remain uneconomical to spend.
>> > Therefore, dropping them entirely from the UTXO set is potentially
>> > destroying potentially useful funds people own.
>> >
>> >> or at least remove them to secondary storage
>> >
>> > Commonly adopted Bitcoin full nodes already have two levels of storage
>> > effectively (disk and in-RAM cache). It may be useful to investigate
>> > using amount as a heuristic about what to keep and how long. IIRC, not
>> > even every full node implementation even uses a UTXO model.
>> >
>> >> 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).
>> >
>> > Do you mean this as a standardness rule, or a consensus rule?
>> >
>> > * As a standardness rule it's feasible, but it makes policy (further)
>> > deviate from economically rational behavior. There is no reason for
>> > miners to require a higher price for spending such outputs.
>> > * As a consensus rule, I expect something like this to be very
>> > controversial. There are currently no rules that demand any minimal
>> > fee for anything, and given uncertainly over how fee levels could
>> > evolve in the future, it's unclear what those rules, if any, should
>> > be.
>> >
>> > Cheers,
>> >
>> > --
>> > Pieter
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists•linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 9517 bytes --]

  parent reply	other threads:[~2022-02-13  5:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-06 12:41 shymaa arafat
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 [this message]
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='CAM98U8=Skhz8ETxHd+aBZssHDcj3qNikDa_JYuR5dcSMUJP32g@mail.gmail.com' \
    --to=shymaa.arafat@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=lightning-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