Date: Fri, 18 Feb 2022 03:36:19 +0000
To: shymaa arafat <shymaa.arafat@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <TUXPKVrq0LQJ3nSS_t9HeG8iyRTnikkswCFL2onfsDGoxd9spW57jLXUDITsVNR6KjIMoiunF5ZUNqlauXj4qM3UigrigxX6rdtE7NuJCRE=@protonmail.com>
In-Reply-To: <CAM98U8=Skhz8ETxHd+aBZssHDcj3qNikDa_JYuR5dcSMUJP32g@mail.gmail.com>
References: <CAM98U8kJVMJOQ++cyP3WXFRSHUZw0ySp3dVuZ=BzoRj2qE4Dug@mail.gmail.com>
 <c7bdbBVd0KmLFPUeYk0QUdni7tbDwJSj4HGLlEOkdPzIYzOyaX147HWJPKE-isTL267nQeJds8-rsKNyzRrBhucsZvwZcg5dZjQxDnbwxAA=@wuille.net>
 <382073c28af1ec54827093003cbec2cc@willtech.com.au>
 <CAM98U8mJvYcBur01Z32TS4RYW+jMDCVQAUtrg5KXF+50d0zirA@mail.gmail.com>
 <CAM98U8=Skhz8ETxHd+aBZssHDcj3qNikDa_JYuR5dcSMUJP32g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: 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
Precedence: list

Good morning shymaa,

> 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.0001BTC (17%)
>
> It seems that bitInfoCharts took my enquiry seriously and added a main li=
nk 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 UTX=
Os
> (ins-outs =3D1,712,706 with a few real UTXOs holding the bulk of 415 BTC)=
=C2=A0
> https://bitinfocharts.com/bitcoin/address/1HckjUpRGcrrRAtFaaCAUaGjsPx9oYm=
LaZ
>
> =C2=BB=C2=BB=C2=BB=C2=BB=C2=BB
> =C2=A0That's alarming isn't it?, is it due to the lightning networks prot=
ocol 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 t=
he new 546-sat UTXO from the same address but spending to a different addre=
ss 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 ad=
dress it already spent from, precisely due to this (apparently common, sinc=
e 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 c=
an eliminate this effect by removing outputs of exactly 546 sats to reused =
addresses.

Regards,
ZmnSCPxj