On Mon, Aug 09, 2021 at 09:22:28AM -0400, Antoine Riard wrote: > I'm pretty conservative about increasing the standard dust limit in any > way. This would convert a higher percentage of LN channels capacity into > dust, which is coming with a lowering of funds safety [0].
I think that reasoning is incomplete. There are two related things here: - **Uneconomical outputs:** outputs that would cost more to spend than the value they contain. - **Dust limit:** an output amount below which Bitcoin Core (and other nodes) will not relay the transaction containing that output. Although raising the dust limit can have the effect you describe, increases in the minimum necessary feerate to get a transaction confirmed in an appropriate amount of time also "converts a higher percentage of LN channel capacity into dust". As developers, we have no control over prevailing feerates, so this is a problem LN needs to deal with regardless of Bitcoin Core's dust limit. (Related to your linked thread, that seems to be about the risk of "burning funds" by paying them to a miner who may be a party to the attack. There's plenty of other alternative ways to burn funds that can change the risk profile.) > the standard dust limit [...] introduces a trust vector My point above is that any trust vector is introduced not by the dust limit but by the economics of outputs being worth less than they cost to spend. > LN node operators might be willingly to compensate this "dust" trust vector > by relying on side-trust model They could also use trustless probabalistic payments, which have been discussed in the context of LN for handling the problem of payments too small to be represented onchain since early 2016: https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098_0_178 (Probabalistic payments were discussed in the general context of Bitcoin well before LN was proposed, and Elements even includes an opcode for creating them.) > smarter engineering such as utreexo on the base-layer side Utreexo doesn't solve this problem. Many nodes (such as miners) will still want to store the full UTXO set and access it quickly, Utreexo proofs will grow in size with UTXO set size (though, at best, only log(n)), so full node operators will still not want their bandwidth wasted by people who create UTXOs they have no reason to spend. > I think the status quo is good enough for now I agree. -Dave
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
