Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 6 Feb 2022 11:14:28 -0800
Message-Id: <86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org>
References: <c7bdbBVd0KmLFPUeYk0QUdni7tbDwJSj4HGLlEOkdPzIYzOyaX147HWJPKE-isTL267nQeJds8-rsKNyzRrBhucsZvwZcg5dZjQxDnbwxAA=@wuille.net>
In-Reply-To: <c7bdbBVd0KmLFPUeYk0QUdni7tbDwJSj4HGLlEOkdPzIYzOyaX147HWJPKE-isTL267nQeJds8-rsKNyzRrBhucsZvwZcg5dZjQxDnbwxAA=@wuille.net>
To: Pieter Wuille <bitcoin-dev@wuille.net>,
 Bitcoin Protocol Discussion <bitcoin-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



> On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>=20
> =EF=BB=BF
>> Dear Bitcoin Developers,
>=20
>> -When I contacted bitInfoCharts to divide the first interval of addresses=
, they kindly did divided to 3 intervals. =46rom 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 473 Sat per=
 address.
>=20
>> -Therefore, a simple solution would be to follow the difficulty adjustmen=
t idea and just delete all those
>=20
> That would be a soft-fork, and arguably could be considered theft. While c=
ommonly (but non universally) implemented standardness rules may prevent spe=
nding them currently, there is no requirement that such a rule remain in pla=
ce. Depending on how feerate economics work out in the future, such outputs m=
ay not even remain uneconomical to spend. Therefore, dropping them entirely f=
rom the UTXO set is potentially destroying potentially useful funds people o=
wn.
>=20
>> or at least remove them to secondary storage
>=20
> Commonly adopted Bitcoin full nodes already have two levels of storage eff=
ectively (disk and in-RAM cache). It may be useful to investigate using amou=
nt as a heuristic about what to keep and how long. IIRC, not even every full=
 node implementation even uses a UTXO model.

You recall correctly. Libbitcoin has never used a UTXO store. A full node ha=
s no logical need for an additional store of outputs, as transactions alread=
y contain them, and a full node requires all of them, spent or otherwise.

The hand-wringing over UTXO set size does not apply to full nodes, it is rel=
evant only to pruning. Given linear worst case growth, even that is ultimate=
ly a non-issue.

>> for Archiving with extra cost to get them back, along with non-standard U=
TXOs and Burned ones (at least for publicly known, published, burn addresses=
).
>=20
> Do you mean this as a standardness rule, or a consensus rule?
>=20
> * As a standardness rule it's feasible, but it makes policy (further) devi=
ate from economically rational behavior. There is no reason for miners to re=
quire a higher price for spending such outputs.
> * As a consensus rule, I expect something like this to be very controversi=
al. There are currently no rules that demand any minimal fee for anything, a=
nd given uncertainly over how fee levels could evolve in the future, it's un=
clear what those rules, if any, should be.
>=20
> Cheers,
>=20
> --
> Pieter
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev