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
- 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])
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.
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 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.
Lower value HTLCs don't need to be included in the commitment transaction
(if they're below the dust level, they definitely shouldn't be included,
and if they're less than 1sat they can't be included), and as such don't
incur all the same fixed costs that HTLCs that are committed too do.
Having different base fees for microtransactions that incur fewer costs
would be annoying; so having that be "amortised" into the proportional
fee might help there too.
I think eltoo can help in two ways by reducing the fixed costs: you no
longer need to keep HTLC information around permanently, and if you do
a multilevel channel factory setup, you can probably remove the ~400
HTLCs per channel at any one time limit. But there's still other fixed
costs, so I think that would just lower the fixed costs, not remove them
altogether and isn't a fundamental change.
I think the fixed costs for forwarding a HTLC are very small; something
like:
0.02sats -- cost of permanently storing the HTLC info
(100 bytes, $500/TB/year, 1% discount rate)
0.04sats -- compute and bandwidth cost for updating an HTLC ($40/month
at linode, 1 second of compute)
The opportunity cost of having HTLC slots or Bitcoin locked up until
the HTLC succeeds/fails could be much more significant, though.
Cheers,
aj
[0]
https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message
[1] https://basefee.ln.rene-pickhardt.de/
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
