{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-08-14\n📝 Original message:\nHey *,\n\nThere's been discussions on twitter and elsewhere advocating for\nsetting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing\nthis to summarise my understanding in a place that's able to easily be\nreferenced later.\n\nSetting the base fee to zero has a couple of benefits:\n\n - it means you only have one value to optimise when trying to collect\n   the most fees, and one-dimensional optimisation problems are\n   obviously easier to write code for than two-dimensional optimisation\n   problems\n\n - when finding a route, if all the fees on all the channels are\n   proportional only, you'll never have to worry about paying more fees\n   just as a result of splitting a payment; that makes routing easier\n   (see [1])\n\nSo what's the cost? The cost is that there's no longer a fixed minimum\nfee -- so if you try sending a 1sat payment you'll pay 0.1% of the fee\nto send a 1000sat payment, and there may be fixed costs that you have\nin routing payments that you'd like to be compensated for (eg, the\ncomputational work to update channel state, the bandwith to forward the\ntx, or the opportunity cost for not being able to accept another htlc if\nyou've hit your max htlcs per channel limit).\n\nBut there's no need to explicitly separate those costs the way we do\nnow; instead of charging 1sat base fee and 0.02% proportional fee,\nyou can instead just set the 0.02% proportional fee and have a minimum\npayment size of 5000 sats (htlc_minimum_msat=5e6, ~$2), since 0.02%\nof that is 1sat. Nobody will be asking you to route without offering a\nfee of at least 1sat, but all the optimisation steps are easier.\n\nYou could go a step further, and have the node side accept smaller\npayments despite the htlc minimum setting: eg, accept a 3000 sat payment\nprovided it pays the same fee that a 5000 sat payment would have. That is,\ntreat the setting as minimum_fee=1sat, rather than minimum_amount=5000sat;\nso the advertised value is just calculated from the real settings,\nand that nodes that want to send very small values despite having to\npay high rates can just invert the calculation.\n\nI think something like this approach also makes sense when your channel\nbecomes overloaded; eg if you have x HTLC slots available, and y channel\ncapacity available, setting a minimum payment size of something like\ny/2/x**2 allows you to accept small payments (good for the network)\nwhen you're channel is not busy, but reserves the last slots for larger\npayments so that you don't end up missing out on profits because you\nran out of capacity due to low value spam.\n\nTwo other aspects related to this:\n\nAt present, I think all the fixed costs are also incurred even when\na htlc fails, so until we have some way of charging failing txs for\nincurring those costs, it seems a bit backwards to penalise successful\ntxs who at least pay a proportional fee for the same thing. Until we've\ngot a way of handling that, having zero base fee seems at least fair.\n\nLower value HTLCs don't need to be included in the commitment transaction\n(if they're below the dust level, they definitely shouldn't be included,\nand if they're less than 1sat they can't be included), and as such don't\nincur all the same fixed costs that HTLCs that are committed too do.\nHaving different base fees for microtransactions that incur fewer costs\nwould be annoying; so having that be \"amortised\" into the proportional\nfee might help there too.\n\nI think eltoo can help in two ways by reducing the fixed costs: you no\nlonger need to keep HTLC information around permanently, and if you do\na multilevel channel factory setup, you can probably remove the ~400\nHTLCs per channel at any one time limit. But there's still other fixed\ncosts, so I think that would just lower the fixed costs, not remove them\naltogether and isn't a fundamental change.\n\nI think the fixed costs for forwarding a HTLC are very small; something\nlike:\n\n   0.02sats -- cost of permanently storing the HTLC info\n               (100 bytes, $500/TB/year, 1% discount rate)\n   0.04sats -- compute and bandwidth cost for updating an HTLC ($40/month\n               at linode, 1 second of compute)\n\nThe opportunity cost of having HTLC slots or Bitcoin locked up until\nthe HTLC succeeds/fails could be much more significant, though.\n\nCheers,\naj\n\n[0] https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message\n[1] https://basefee.ln.rene-pickhardt.de/"}