Good morning aj, et al. > Hey *, > > There's been discussions on twitter and elsewhere advocating for > setting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing > this to summarise my understanding in a place that's able to easily be > referenced later. > > Setting the base fee to zero has a couple of benefits: > > - it means you only have one value to optimise when trying to collect > the most fees, and one-dimensional optimisation problems are > obviously easier to write code for than two-dimensional optimisation > problems
Indeed, this is a good point regarding this. > - when finding a route, if all the fees on all the channels are > proportional only, you'll never have to worry about paying more fees > just as a result of splitting a payment; that makes routing easier > (see [1]) If we neglect roundoff errors. On the other hand, roundoff errors involved are <1msat per split, so it probably will not matter to most people. > So what's the cost? The cost is that there's no longer a fixed minimum > fee -- so if you try sending a 1sat payment you'll pay 0.1% of the fee > to send a 1000sat payment, and there may be fixed costs that you have > in routing payments that you'd like to be compensated for (eg, the > computational work to update channel state, the bandwith to forward the > tx, or the opportunity cost for not being able to accept another htlc if > you've hit your max htlcs per channel limit). > > But there's no need to explicitly separate those costs the way we do > now; instead of charging 1sat base fee and 0.02% proportional fee, > you can instead just set the 0.02% proportional fee and have a minimum > payment size of 5000 sats (htlc_minimum_msat=5e6, ~$2), since 0.02% > of that is 1sat. Nobody will be asking you to route without offering a > fee of at least 1sat, but all the optimisation steps are easier. Should this minimum a node will be willing to forward be part of gossip, and how does this affect routing algorithms? > You could go a step further, and have the node side accept smaller > payments despite the htlc minimum setting: eg, accept a 3000 sat payment > provided it pays the same fee that a 5000 sat payment would have. That is, > treat the setting as minimum_fee=1sat, rather than minimum_amount=5000sat; > so the advertised value is just calculated from the real settings, > and that nodes that want to send very small values despite having to > pay high rates can just invert the calculation. I like this idea, as I think it matches more what the incentives are. But it requires a change in gossip and in routing algorithms, and more importantly it requires routing algorithms to support two different fee schemes (base + proportional vs min + proportional). On the other hand, this still is a two-dimensional optimization algorithm, with `minimum_fee` and `proportional_fee_millionths` as the two dimensions. So maybe just have a single proportional-fee mechanism... > > I think something like this approach also makes sense when your channel > becomes overloaded; eg if you have x HTLC slots available, and y channel > capacity available, setting a minimum payment size of something like > y/2/x**2 allows you to accept small payments (good for the network) > when you're channel is not busy, but reserves the last slots for larger > payments so that you don't end up missing out on profits because you > ran out of capacity due to low value spam. > > Two other aspects related to this: > > At present, I think all the fixed costs are also incurred even when > a htlc fails, so until we have some way of charging failing txs for > incurring those costs, it seems a bit backwards to penalise successful > txs who at least pay a proportional fee for the same thing. Until we've > got a way of handling that, having zero base fee seems at least fair. Yes, the dreaded mechanism against payment lockup, which as far as I understand has a lot of thought already sunk into it without any widely-accepted solution, sigh. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
