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