Re: [Lightning-dev] [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
Good morning shymaa, > 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? > . I believe some blockchain tracking analysts will "dust" addresses that were spent from (give them 546 sats), in the hope that lousy wallets will use the new 546-sat UTXO from the same address but spending to a different address and combining with *other* inputs with new addresses, thus allowing them to grow their datasets about fund ownership. Indeed JoinMarket has a policy to ignore-by-default UTXOs that pay to an address it already spent from, precisely due to this (apparently common, since my JoinMarket maker got dusted a number of times already) practice. I am personally unsure of how common this is but it seems likely that you can eliminate this effect by removing outputs of exactly 546 sats to reused addresses. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
Good Afternoon,
I am briefly reading the suggestion subject titled this email message.
The problem this idea addresses is not new, it is as old as computer
science with complexity and security varying from unused products in a
supermarket database to unused bank accounts and records of transactions
for archival. In the former, it is of no consequence to remove unused
products from the database if the itemised sales history is not
necessary and the report data is maintained ie. where the reporting is
stored generated. Once the products are removed it is impossible to
regenerate the detailed reports that called on the product-specific and
sales information. Archival works in a manner to remove data from
commonly used tables and to optimise them and if the data is later
required it can be recalled from larger possibly slower storage, or
simply kept in a larger less optimised table, in either case, all of the
data is still available. In the latter, it is a matter of consequence
and although archival is possible it is still necessary to ensure that
all archives are backed up, and the data can never be removed. This is
because if in an example transaction data is deleted after seven years
then it is no longer possible to see how an account has its balance and
an empty account with no transactions may be removed while actually
still holding a significant balance. If a mistake is made the result is
the same. This is because we allowed deletion of accounting records.
Actually, the recommendation from Computer Science all along is the same
as our case with Bitcoin - nothing should be deleted from the Blockchain
forever. For one substantiative reason, this is because it is necessary
for any client to be able to validate the blockchain in its entirety and
some clients may only be receiving information as to the state of the
blockchain from you. When you keep the entire blockchain you validate to
everybody else that you have the correct records. I arbitrarily object
to the use of pruned nodes but find them useful since the process of
validation is completed in its entirety when a new node comes online
even if it is pruned, but if only pruned nodes are available then
everybody has to believe the other nodes and this is unacceptable for
Bitcoin. It should be if some node is archiving UTXO's then it should
count as a pruned node, but my suggestion is, instead of making a
programming change just set your node with the parameter `prune=1` if
you wish to allow manually pruning from the Blockchain to a specific
height when you wish, or `prune= {>550} automatically prune blocks to
stay under target size in MiB`. My chain state database after all is
only 4.9GB and is hardly a concern for any operation of the standard
Bitcoin Core client. The answer, again, is you should just leave it and
get used to dealing with the bigger database.
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.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
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 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 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.01 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
