rich1.0npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hhttps://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hnjumphttps://nostr.ae📅 Original date posted:2021-08-15 📝 Original message: On Sun, Aug 15, 2021 at 07:19:01AM -0500, lisa neigut wrote: > My suggestion would be that, as a compromise, we set a network wide minimum fee > at the protocol level of 1msat. Is that different in any meaningful way to just saying "fees get rounded up to the nearest msat" ? If the fee is 999.999msat, expecting to get away with paying less than 1sat seems kinda buggy to me. On Sun, Aug 15, 2021 at 08:04:52PM -0400, Matt Corallo wrote: > I'm frankly still very confused why we're having these conversations now. Because it's what people are thinking about. The bar for having a conversation about something is very low... > In > one particular class of applicable routing algorithms you could use for > lightning routing having a base fee makes the algorithm intractably slow, I don't think of that as the problem, but rather as the base fee having a multiplicative effect as you split payments. If every channel has the same (base,proportional) fee pair, and send a payment along a single path, you're paying n*(base+k*proportional). If you split the payment, and send half of it one way, and half the other way, you're paying n*(2*base+k*proportional). If you split the payment four ways, you're paying n*(4*base+k*proportional). Where's the value to the network in penalising payment splitting? Being denominated in sats, the base fee also changes in value as the bitcoin price changes -- c-lightning dropped the base fee to 1sat (from 546 sat!) in Jan 2018, but the value of 1sat has increased about 4x since then, and it seems unlikely the fixed costs of a successful HTLC payment have likewise increased 4x. Proportional fees deal with this factor automatically, of course. > There's real cost to distorting the fee structures on the network away from > the costs of node operators, That's precisely what the base fee is already doing. Yes, we need some other way of charging fees to prevent using up too many slots or having transactions not fail in a timely manner, but the base fee does not do that. > Imagine we find some great way to address HTLC slot flooding/DoS attacks (or > just chose to do it in a not-great way) by charging for HTLC slot usage, now > we can't fix a critical DoS issue because the routing algorithms we deployed > can't handle the new costing. I don't think that's true. The two things we don't charge for that can be abused by probing spam are HTLC slot usage and channel balance usage; both are problems only in proportion to the amount of time they're held open, and the latter is also only a problem proportional to the value being reserved. [0] Additionally, I don't think HTLC slot usage needs to be kept as a limitation after we switch to eltoo; and in the meantime, I think it can be better managed via adjusting the min_htlc_amount -- at least for the scenario where problems are being caused by legitimate payment attempts, which is also the only place base fee can help. [0] (Well, ln-penalty's requirement to permanently store HTLC information in order to apply the penalty is in some sense a constant cost, however the impact is also proportional to value, and for sufficiently low value HTLCs can be ignored entirely if the HTLC isn't included in the channel commitment) > Instead, we should investigate how we can > apply the ideas here with the more complicated fee structures we have. Fee structures should be *simple* not complicated. I mean, it's kind of great that we started off complicated -- if it turns out base fee isn't necessary, it's easy to just set it to zero; if we didn't have it, but needed it, it would be much more annoying to add it in later. > Color me an optimist, but I'm quite confident with sufficient elbow grease > and heuristics we can get 95% of the way there. We can and should revisit > these conversations if such exploration is done and we find that its not > possible, but until then this all feels incredibly premature. Depends; I don't think it makes sense to try to ban nodes that don't have a base fee of zero or anything, but random people on twitter advocating that node operators should set it to zero and just worry about optimising via the proportional fee and the min htlc amount seems fine. For an experimental plugin that aggressively splits payments up, I think either ignoring channels with >0 base fee entirely, or deciding that you're happy to spend a total of X sats on base fees, and then ignoring channels whose base fee is greater than X/paths/path-length sats is fine. But long term, I also think that the base fee is an entirely unhelpful complication that will eventually just be hardcoded to zero by everyone, and eventually channels that propose non-zero base fees won't even be gossiped. I don't expect that to happen any time soon though. Cheers, aj