rich1.0npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuhttps://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcunjumphttps://nostr.ae📅 Original date posted:2021-08-16 📝 Original message: Dropped a number of replies to which the reply would otherwise be "see above". On 8/16/21 00:00, Anthony Towns wrote: > On Sun, Aug 15, 2021 at 10:21:52PM -0400, Matt Corallo wrote: >> On 8/15/21 22:02, Anthony Towns wrote: >>>> 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. >> Yes, matching the real-world costs of forwarding an HTLC. > > Actually, no, not at all. > > The base+proportional fees paid only on success roughly match the *value* > of forwarding an HTLC, they don't match the costs particularly well > at all. > > Why not? Because the costs are incurred on failed HTLCs as well, and > also depend on the time a HTLC lasts, and also vary heavily depending > on how many other simultaneous HTLCs there are. Sure, indeed, there's some additional costs which are not covered by failed HTLCs, nor incorporate the time the HTLC slot was used. But that wasn't my argument - my argument was that base + proportional is a much, much closer match for the costs of a node barring clever-er solutions around HTLC-slot-time-used. Dropping base fee makes the whole situation a good chunk *worse*. >> Yes. You have to pay the cost of a node. If we're really worried about this, >> we should be talking about upfront fees and/or refunds on HTLC fulfillment, >> not removing the fees entirely. > > (I don't believe either of those are the right approach, but based on > previous discussions, I don't think anyone's going to realise I'm right > until I implement it and prove it, so *shrug*) I think I agree, but I think they may currently be better than any *other* proposal, not that they're particularly good. >> The cost to nodes is largely [...] > > The cost to nodes is almost entirely the opportunity cost of not being > able to accept other txs that would come in afterwards and would pay > higher fees. > > And all those costs can be captured equally well (or badly) by just > setting a proportional fee and a minimum payment value. I don't know why > you keep ignoring that point. I didn't ignore this, I just disagree, and I'm not entirely sure why you're ignoring the points I made to that effect :). In all seriousness, I'm entirely unsure why you think proportional is just as good? As you note, the cost for nodes is a function of the opportunity cost of the capital, and opportunity cost of the HTLC slots. Lets say as a routing node I decide that the opportunity cost of one of my HTLC slots is generally 1 sat per second, and the average HTLC is fulfilled in one second. Why is it that a proportional fee captures this "equally well"?! Yes, you could amortize it, but that doesn't make it "equally" good, and there are semi-serious proposals to start ignoring nodes that *dont* set their fees to some particular structure in routing decisions. Sure, nodes can do what they want, but its kinda absurd to suggest that this is a perfectly fine thing to do absent a somewhat compelling reason. This goes doubly because deploying such things significantly will mean we cannot do future protocol changes which may better capture the time-value of node resources! >>> Additionally, I don't think HTLC slot usage needs to be kept as a >>> limitation after we switch to eltoo; >> The HTLC slot limit is to keep transactions broadcastable. I don't see why >> this would change, you still get an output for each HTLC on the latest >> commitment in eltoo, AFAIU. > > eltoo gives us the ability to have channel factories.... That doesn't solve the issue at all - you still have a ton of transactions and transaction outputs and spends thereof to put on the chain in the case of a closure with pending HTLCs. In fact, most nodes today enforce a lower limit than the 400-some-odd HTLCs that represent the transaction standardness limit, because 100KB transactions are stupid impractical. > (By "any time soon" I mean, I could see software defaults changing if > over 50% of the network deliberately switched to zero base fees and found > it worked fine; and I could see deprecating non-zero fees if that ended > up with 90% of the network on zero base fees, no good reasons for node > operators wanting to stick with running non-zero base fees, and the > experimental algos that relied on zero base fees being significantly > easier to maintain or faster/better) What is your definition of "works fine" here? In today's nearly-entirely-altruistic-routing-node network, we could probably entirely drop the routing fees and things would "work fine". That doesn't make it a good idea for the long-term health of the network. My suggestion is quite simple - that the software vendors wishing to rely on these types of algorithms *first* do the legwork to see what other ideas can be explored before jumping to "ignore all the nodes who've decided their fees are X", because I think *that* is pretty bad idea for the long-term health of the network. I even suggested several areas of future research for folks to look into before we get to the point of in any way seriously relying on routing algorithms that constrain our ability to adapt fees in the future. Matt