>
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
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 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