On Mon, Feb 7, 2022, 16:44 Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > every lightning network transaction adds one dust UTXO
>
> Could you clarify what you mean here? What dust do lightning transactions
> create?
>
I mean this msg
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019636.html
Even though, the writer clarified after my enquiry I still think it is the
same meaning most of the time only one will be spent. His words:
..............
*My statement was technically incorrect, it should have been "most of the
time only one of them is spent".*
*But nothing prevents them to be both spent, or none of them to be spent.*
*They are strictly equivalent, the only difference is the public key that
can sign for them: one of these outputs belongs to you, the other belongs
to your peer.*

*You really cannot distinguish anything when inserting them into the utxo
set, they are perfectly symmetrical and you cannot know beforehand for sure
which one will be spent.*
*You can guess which one will be spent most of the time, but your heuristic
will never be 100% correct, so I don't think it's worth pursuing.*
*.........*........

>
> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>