<unnamed>

Public Key

npub1l7ldumxqplqv4h9lfkwpwp3lapj3xnla2hnf8h8mm9da3qlv6shqfhgr56

Profile Code

nprofile1qqs0l0k7dnqqlsx2mjl5m8qhqcl7segnfl74te5nmnaajk7cs0kdgtspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsxdp40t

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-09 15:05:13 CEST

- reply

📅 Original date posted:2022-02-13
📝 Original message:
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 at 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 at 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 at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220213/eb38bf91/attachment.html>