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.ara...@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 <dam...@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 >> >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
