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