Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

From: Billy Tetrud <billy.tetrud@gmail•com>
To: Eric Voskuil <eric@voskuil•org>,
	 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
Date: Mon, 7 Feb 2022 08:34:42 -0600	[thread overview]
Message-ID: <CAGpPWDbR5ctxf=HjLjqy0ADcQZMy9HQv-ZJfyFKmSBTntvkE9A@mail.gmail.com> (raw)
In-Reply-To: <86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org>

[-- Attachment #1: Type: text/plain, Size: 3833 bytes --]

> every lightning network transaction adds one dust UTXO

Could you clarify what you mean here? What dust do lightning transactions
create?

I do think that UTXO set size is something that will need to be addressed
at some point. I liked the idea of utreexo or some other accumulator as the
ultimate solution to this problem. In the mean time, I kind of agree with
Eric that outputs unlikely to be spent can easily be stored off ram and so
I wouldn't expect them to really be much of an issue to keep around. 3
million utxos is only like 100MB. If software could be improved to move
dust off ram, that sounds like a good win tho.

On Sun, Feb 6, 2022, 13:14 Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

>
>
> > On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> 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.
>
> You recall correctly. Libbitcoin has never used a UTXO store. A full node
> has no logical need for an additional store of outputs, as transactions
> already 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
> relevant only to pruning. Given linear worst case growth, even that is
> ultimately a non-issue.
>
> >> 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
>

[-- Attachment #2: Type: text/html, Size: 5177 bytes --]