{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-08-15\n📝 Original message:\nThanks, AJ, for kicking off the thread.\n\nI'm frankly still very confused why we're having these conversations now. In one particular class of applicable routing \nalgorithms you could use for lightning routing having a base fee makes the algorithm intractably slow, but:\n\na) to my knowledge, no one has (yet) done any follow-on work to investigate pulling many of the same heuristics Rene et \nal use in a Dijkstras/A* algorithm with multiple passes or generating multiple routes in the same pass to see whether \nyou can emulate the results in a faster algorithm without the drawbacks here,\n\nb) to my knowledge, no one has (yet) done any follow-on work to investigate mapping the base fee to other, more \nflow-based-routing-compatible numbers, eg you could convert the base fee to a minimum fee by increasing the \"effective\" \nproportional fees. From what others have commented, this may largely \"solve\" the issue.\n\nc) to my knowledge, no one has (yet) done any follow-on work to analyze where the proposed algorithm may be most optimal \nin the HTLC-value\u003c-\u003echannel liquidity ratio ranges. We may find that the proposed algorithm only provides materially \nbetter routing when the HTLC value approaches X% of common network channel liquidity, allowing us to only use it for \nlarge-value payments where we can almost ignore the base fees entirely.\n\nThere's real cost to distorting the fee structures on the network away from the costs of node operators, especially as \nwe move towards requiring and using Real (tm) amounts of capital on routing nodes. If we're relying purely on hobbyists \nforever who are operating out of goodwill, we should just remove all fees. If we think Lightning is going to involve \ncapital with real opportunity cost, matching fees to the costs is important, or at least important enough that we \nshouldn't throw it away after one (pretty great) paper and limited further analysis.\n\nImagine we find some great way to address HTLC slot flooding/DoS attacks (or just chose to do it in a not-great way) by \ncharging for HTLC slot usage, now we can't fix a critical DoS issue because the routing algorithms we deployed can't \nhandle the new costing. Instead, we should investigate how we can apply the ideas here with the more complicated fee \nstructures we have.\n\nColor me an optimist, but I'm quite confident with sufficient elbow grease and heuristics we can get 95% of the way \nthere. We can and should revisit these conversations if such exploration is done and we find that its not possible, but \nuntil then this all feels incredibly premature.\n\nMatt\n\nOn 8/14/21 21:00, Anthony Towns wrote:\n\u003e Hey *,\n\u003e \n\u003e There's been discussions on twitter and elsewhere advocating for\n\u003e setting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing\n\u003e this to summarise my understanding in a place that's able to easily be\n\u003e referenced later.\n\u003e \n\u003e Setting the base fee to zero has a couple of benefits:\n\u003e \n\u003e   - it means you only have one value to optimise when trying to collect\n\u003e     the most fees, and one-dimensional optimisation problems are\n\u003e     obviously easier to write code for than two-dimensional optimisation\n\u003e     problems\n\u003e \n\u003e   - when finding a route, if all the fees on all the channels are\n\u003e     proportional only, you'll never have to worry about paying more fees\n\u003e     just as a result of splitting a payment; that makes routing easier\n\u003e     (see [1])\n\u003e \n\u003e So what's the cost? The cost is that there's no longer a fixed minimum\n\u003e fee -- so if you try sending a 1sat payment you'll pay 0.1% of the fee\n\u003e to send a 1000sat payment, and there may be fixed costs that you have\n\u003e in routing payments that you'd like to be compensated for (eg, the\n\u003e computational work to update channel state, the bandwith to forward the\n\u003e tx, or the opportunity cost for not being able to accept another htlc if\n\u003e you've hit your max htlcs per channel limit).\n\u003e \n\u003e But there's no need to explicitly separate those costs the way we do\n\u003e now; instead of charging 1sat base fee and 0.02% proportional fee,\n\u003e you can instead just set the 0.02% proportional fee and have a minimum\n\u003e payment size of 5000 sats (htlc_minimum_msat=5e6, ~$2), since 0.02%\n\u003e of that is 1sat. Nobody will be asking you to route without offering a\n\u003e fee of at least 1sat, but all the optimisation steps are easier.\n\u003e \n\u003e You could go a step further, and have the node side accept smaller\n\u003e payments despite the htlc minimum setting: eg, accept a 3000 sat payment\n\u003e provided it pays the same fee that a 5000 sat payment would have. That is,\n\u003e treat the setting as minimum_fee=1sat, rather than minimum_amount=5000sat;\n\u003e so the advertised value is just calculated from the real settings,\n\u003e and that nodes that want to send very small values despite having to\n\u003e pay high rates can just invert the calculation.\n\u003e \n\u003e I think something like this approach also makes sense when your channel\n\u003e becomes overloaded; eg if you have x HTLC slots available, and y channel\n\u003e capacity available, setting a minimum payment size of something like\n\u003e y/2/x**2 allows you to accept small payments (good for the network)\n\u003e when you're channel is not busy, but reserves the last slots for larger\n\u003e payments so that you don't end up missing out on profits because you\n\u003e ran out of capacity due to low value spam.\n\u003e \n\u003e Two other aspects related to this:\n\u003e \n\u003e At present, I think all the fixed costs are also incurred even when\n\u003e a htlc fails, so until we have some way of charging failing txs for\n\u003e incurring those costs, it seems a bit backwards to penalise successful\n\u003e txs who at least pay a proportional fee for the same thing. Until we've\n\u003e got a way of handling that, having zero base fee seems at least fair.\n\u003e \n\u003e Lower value HTLCs don't need to be included in the commitment transaction\n\u003e (if they're below the dust level, they definitely shouldn't be included,\n\u003e and if they're less than 1sat they can't be included), and as such don't\n\u003e incur all the same fixed costs that HTLCs that are committed too do.\n\u003e Having different base fees for microtransactions that incur fewer costs\n\u003e would be annoying; so having that be \"amortised\" into the proportional\n\u003e fee might help there too.\n\u003e \n\u003e I think eltoo can help in two ways by reducing the fixed costs: you no\n\u003e longer need to keep HTLC information around permanently, and if you do\n\u003e a multilevel channel factory setup, you can probably remove the ~400\n\u003e HTLCs per channel at any one time limit. But there's still other fixed\n\u003e costs, so I think that would just lower the fixed costs, not remove them\n\u003e altogether and isn't a fundamental change.\n\u003e \n\u003e I think the fixed costs for forwarding a HTLC are very small; something\n\u003e like:\n\u003e \n\u003e     0.02sats -- cost of permanently storing the HTLC info\n\u003e                 (100 bytes, $500/TB/year, 1% discount rate)\n\u003e     0.04sats -- compute and bandwidth cost for updating an HTLC ($40/month\n\u003e                 at linode, 1 second of compute)\n\u003e \n\u003e The opportunity cost of having HTLC slots or Bitcoin locked up until\n\u003e the HTLC succeeds/fails could be much more significant, though.\n\u003e \n\u003e Cheers,\n\u003e aj\n\u003e \n\u003e [0] https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message\n\u003e [1] https://basefee.ln.rene-pickhardt.de/\n\u003e \n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e"}