Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7C5FDC000B; Sun, 13 Feb 2022 05:19:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5D8A140361; Sun, 13 Feb 2022 05:19:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSubfVK4ZC0X; Sun, 13 Feb 2022 05:19:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by smtp4.osuosl.org (Postfix) with ESMTPS id 66F184035F; Sun, 13 Feb 2022 05:19:18 +0000 (UTC) Received: by mail-ej1-x62f.google.com with SMTP id h8so4378534ejy.4; Sat, 12 Feb 2022 21:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8oNppmSlPD/2GJYjv4ApjIV9brgcu8WZsoIir9zIpfc=; b=kGa881G2Er30Erc2S4HdHpzpJnSrZrsdY6umAXe6Rtp0lSQjdqK8l4+lqJV4NHSIl1 NEzw6SLWBONafCr1J4Fq832SJP4DKL7hxw4+wP6guLb1lq4VpbvzOfBhlC8ZoScnNSI5 MHn3moyQQ8b6EbF/HRXWg95V+65B8ZelpyWxvST+P8myE3okrKDD5CA3cFl+udv0tMFQ FArVFKBzAuusWO3avO0mv6/tcb0X5sXzBjh3pw96oUHWEQvurkg8RidTjYxUa6MZon4G sjKd+NU9Mvc+8O5QjydGHbfaTsP/GM/hs6u9LlUmf5ICN0qJPDiwAEMXxlmnUHxRL3D8 S0+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8oNppmSlPD/2GJYjv4ApjIV9brgcu8WZsoIir9zIpfc=; b=Y134AmTVUJHmls5fXGFKAeU43+CSj8Jz4yc/HmqybU6ksNNNP2soJBLDYPRx3yEDPI jdlMxGLwRWVgGLgSrR+Z0GYb7w1F3LQ1ZdzBON+B2KiwmxNj+wm3ngOjP86HdFIBIOxa yISrd2N4VWAriWr6YNNchClq/iZ1KaSowh+7HQcRvd4BEMzrujCemQZPvCXBF6vAdKsa 3GMvh4pSNEFamFSDRky+dCJv9XLgKpOB6qaNp9wt1hnVWJ5gR6EE1ea3EzhX/GbhFje+ q0PDxMnS+L2XSlm0/eNWPBuF/80rH9NGcnAk5kYEizDyDaugP65CKiv+sTdYbLNCcrkL Xa6g== X-Gm-Message-State: AOAM5302jR41iMtSEok3VL6wrepp4PzOu3iCsFrXDWEkBG2E4wz/iCZ7 WD4fbPCNqJDTnONx5S5pDn4mVqMYcJJkB60F+o1EoeG1 X-Google-Smtp-Source: ABdhPJz3dta8jGcynoI4vVBXssEeLPi6ft6vicwu9MT8mhFjZkt93oqEc9l9J59xFAXxIk13oFmPbAyxblSFz8mN0Ac= X-Received: by 2002:a17:906:60d5:: with SMTP id f21mr6937217ejk.482.1644729556050; Sat, 12 Feb 2022 21:19:16 -0800 (PST) MIME-Version: 1.0 References: <382073c28af1ec54827093003cbec2cc@willtech.com.au> In-Reply-To: From: shymaa arafat Date: Sun, 13 Feb 2022 07:19:04 +0200 Message-ID: To: Bitcoin Protocol Discussion , lightning-dev Content-Type: multipart/alternative; boundary="000000000000f0a4dd05d7df7073" X-Mailman-Approved-At: Sun, 13 Feb 2022 08:44:10 +0000 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 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2022 05:19:22 -0000 --000000000000f0a4dd05d7df7073 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I just want to add an alarming info to this thread... *There are at least 5.7m UTXOs=E2=89=A41000 Sat (~7%), * *8.04 m =E2=89=A41$ (10%), * *13.5m =E2=89=A4 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 =3D1,712,706 with a few real UTXOs holding the bulk of 415 BTC) https://bitinfocharts.com/bitcoin/address/1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLa= Z =C2=BB=C2=BB=C2=BB=C2=BB=C2=BB 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 =E2= =89=A41000 > Sat (3.15 m address) or even =E2=89=A410,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=E2=89=A44.1$) or 1$ (5.248m=E2=89=A41$) your decision. > > -During 4 days after showing the smaller intervals, those =E2=89=A41000Sa= t > increase by ~2K everyday with total holding increased by 0.01BTC. Address= es > in millions: > 3.148, 3.1509, 3.152895, 3.154398 > Total BTC: > 14.91,14.92,14.93,14.94 > > -The number of =E2=89=A410,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 =E2=89= =A4 >> >> 0.000001 BTC (1000 Sat) with total value of 14.9BTC; an average of 47= 3 >> >> 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 >> > --000000000000f0a4dd05d7df7073 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just want to add an alarming info to this thread...
There are at= least 5.7m UTXOs=E2=89=A41000 Sat (~7%),=C2=A0
8.04 m =E2=89=A41$ (10%),=C2=A0
13.5m =E2=89=A4 0.0001B= TC (17%)

It seems t= hat bitInfoCharts took my enquiry seriously and added a main link for dust = analysis:
Here, you can see just the first address contains more = than 1.7m dust UTXOs
(ins-outs =3D1,7= 12,706 with a few real UTXOs holding the bulk of 415 BTC)=C2=A0
<= div dir=3D"auto">
=C2=BB=C2=BB=C2=BB=C2=BB=C2=BB=
=C2=A0That's alarming isn't it?, is it due = to the lightning networks protocol or could be some other weird activity go= ing on?
.
The following addre= ss are similar but less severe
~394k UTXOs, 170k, 92= k, 10*20k, 4or5 *14k,...etc
add at least 2.7m UTXOs = coming from addresses with a higher balance to the interval numbers here (c= alculated & mentioned in my previous email)


I think it seems bitInfoCharts will p= robably make their own report about it soon

Regards
Shymaa M. Arafat

On Wed, Feb 9, 2022, 07:19 shymaa arafat <shymaa.ar= afat@gmail.com> wrote:
If 1 Sat reached 100$, you may adjust the delete( or call it o= mitting or trimming) threshold, since you will need to acquire decimal plac= es inside the Sat variable too ( people may have TXs less than 100$)

it is hard to imagine that someon= e's all holdings in Bitcoin is just =E2=89=A41000 Sat (3.15 m address) = or even =E2=89=A410,000 Sat (4.1$, with currently 7.6m addresses in additio= n 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 U= TXOs into one of at least 5$ (10.86m=E2=89=A44.1$) or 1$ (5.248m=E2=89=A41$= ) your decision.

-During= 4 days after showing the smaller intervals, those =E2=89=A41000Sat increas= e by ~2K everyday with total holding increased by 0.01BTC. Addresses in mil= lions:
3.148, 3.1509, 3.152895, 3.154398
Total BTC:=C2=A0
14.91,14.92,14.93,14.94=

-The number of =E2=89= =A410,000 Sat increases by 4-8 k per day.
Addresses = in millions:
7.627477, 7.631436, 7.639287, 7.644925<= /div>
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 co= uld be even more.
.
+ There&#= 39;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-addresse= s.html
>> -You can see that there are more than 3.1m addresses holding =E2= =89=A4
>> 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, <= br> >> 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 (furth= er)
> 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, shoul= d
> be.
>
> Cheers,
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.= linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>
--000000000000f0a4dd05d7df7073--