From aj at erisian.com.au Wed Aug 25 12:50:43 2021 From: aj at erisian.com.au (Anthony Towns) Date: Wed, 25 Aug 2021 22:50:43 +1000 Subject: [Lightning-dev] #zerobasefee In-Reply-To: References: <20210816020224.GC3971@erisian.com.au> <20210816040048.GA5895@erisian.com.au> <8420aca1-f027-67a3-aa41-165b5f7dcedf@mattcorallo.com> <20210821044638.GA9981@erisian.com.au> Message-ID: <20210825125043.GC11158@erisian.com.au> On Tue, Aug 24, 2021 at 08:50:42PM -0700, Matt Corallo wrote: > I feel like we're having two very, very different conversations here. On one > hand, you're arguing that the base fee is of marginal use, and that maybe we > can figure out how to average it out such that we can avoid needing it. I'm not sure about the "we" in that sentence -- I'm saying node operators shouldn't bother with it, not that lightning software devs shouldn't offer it as a config option or take it into account when choosing routes. The only software change that /might/ make sense is changing defaults from 1sat to 0msat, but it seems a bit early for that too, to me. (I'm assuming comments like "We'll most definitely support #zerobasefee" [0] just means "you can set it to zero if you like" which seems like a weird thing to have to say explicitly...) [0] https://twitter.com/Snyke/status/1418109408438063104 > On > the other hand, I'm arguing that, yes, maybe you can, but ideally you > wouldn't have to, because its still pretty nice to capture those costs > sometimes. I don't really think it captures costs at all, but I do agree it could be nice (at least in theory) to have it available since then you might be able to better optimise your fee income based on whatever demand happens to be. That's to increase profits, not match costs though, and I'm not convinced the theory will play out in practice presuming AMP is often useful/necessary. > Also, even if we can maybe do away with the base fee, that still > doesn't mean we should start relying on the lack of any > not-completely-linear-in-HTLC-value fees in our routing algorithms, I mean, exprimental/research routing algorithms should totally rely on that if they feel like it? I just don't see any evidence that anyone's thinking of moving that out of research and into production until there's feedback from operators and a lot more results from the research in general... > as maybe > we'll want to do upfront payments or some other kind of anti-DoS payment in > the future to solve the gaping, glaring, giant DoS hole that is HTLCs taking > forever to time out. Until we've got an even vaguely workable scheme for that, I don't think it's relevant to consider. (If my preferred scheme turns out to be workable, I don't think it needs to be taken into account when (multi)pathfinding at all) > I'm not even sure that you're trying to argue, here, that we should start > making key assumptions about the only fee being a proportional one in our > routing algorithms, but that is what the topic at hand is, so I can't help > but assume you are? No, that's not the topic at hand, at all? I mean, it's related, and interesting to talk about, but it's a digression into "wild ideas that might happen in the future", not the topic... I don't think anyone's currently advocating for node software to work that way? (I do think having many/most channels have a zero base fee will make multipath routing algos work better even when they *don't* assume the base fee is zero) I think I'm arguing for these things: a) "everyone" should drop their base fee msat from the default, probably to 0 because that's an easy fixed point that you don't need to think about again as the price of btc changes, but anything at or below 10msat would be much more reasonable than 1000msat. b) if people are concerned about wasting resources forwarding super small payments for correspondingly super small fees, they should raise min_htlc_amount from 0 (or 1000) to compensate, instead of raising their base fee. c) software should dynamically increase min_htlc_amount as the number of available htlc slots decreases, as a DoS mitigation measure. (presuming this is a temporary increase, probably this wouldn't be gossiped, and possibly not even communicated to the channel counterparty -- just a way of immediately rejecting htlcs? I think if something along these lines were implemented, (b) would almost never be necessary) d) the default base fee should be changed to 0, 1, or 10msat instead of 1000msat e) trivially: (I don't think anyone's saying otherwise) - 0 base fee should be a supported config option - research/experimental routing algorithms are great and should be encouraged - deploying new algorithms in production should only be done with a lot of care - changing the protocol should only be done with even more care - proportional fees should be rounded up to the next msat and never rounded down to 0 - research/experiments on charging for holding htlcs open should continue (likewise research on other DoS prevention measures) I'm not super sure about (c) or (d), and the "everyone" in (a) could easily not really be everyone. > If you disagree with the above characterization I'm happy to go line-by-line > tit-for-tat, but usually those kinds of tirades aren't exactly useful and > end up being more about semantics than the thrust of the argument. Thanks for the lack of a tirade :) Cheers, aj