On Sun, Jun 05, 2022 at 02:29:28PM +0000, ZmnSCPxj via Lightning-dev wrote:
Just sharing my thoughts on this.
> Introduction
> ============
> Optimize for reliability+
> uncertainty+fee+drain+uptime...
> .--~~--.
> / \
> / \
> / \
> / \
> / \
> _--' `--_
> Just Just
> optimize optimize
> for for
> low fee low fee
I think ideally you want to optimise for some combination of fee, speed
and reliability (both liklihood of a clean failure that you can retry
and of generating stuck payments). As Matt/Peter suggest in another
thread, maybe for some uses you can accept low speed for low fees,
while in others you'd rather pay more and get near-instant results. I
think drain should just go to fee, and uncertainty/uptime are just ways
of estimating reliability.
It might be reasonable to generate local estimates for speed/reliability
by regularly sending onion messages or designed-to-fail htlcs.
Sorry if that makes me a midwit :)
> Rene Pickhardt also presented the idea of leaking friend-of-a-friend
> balances, to help payers increase their payment reliability.
I think foaf (as opposed to global) gossip of *fee rates* is a very
interesting approach to trying to give nodes more *current* information,
without flooding the entire network with more traffic than it can
cope with.
> Now we can consider that *every channel is a marketplace*.
> What is being sold is the sats inside the channel.
(Really, the marketplace is a channel pair (the incoming channel and
the outgoing channel), and what's being sold is their relative balance)
> So my concrete proposal is that we can do the same friend-of-a-friend balance
> leakage proposed by Rene, except we leak it using *existing* mechanisms ---
> i.e. gossiping a `channel_update` with new feerates adjusted according to the
> supply on the channel --- rather than having a new message to leak
> friend-of-a-friend balance directly.
+42
> Because we effectively leak the balance of channels by the feerates on the
> channel, this totally leaks the balance of channels.
I don't think this is true -- you ideally want to adjust fees not to
maintain a balanced channel (50% on each side), but a balanced *flow*
(1:1 incoming/outgoing payment volume) -- it doesn't really matter if
you get the balanced flow that results in an average of a 50:50, 80:20
or 20:80 ratio of channel balances (at least, it doesn't as long as your
channel capacity is 10 or 100 times the payment size, and your variance
is correspondingly low).
Further, you have two degrees of freedom when setting fee rates: one
is how balanced the flows are, which controls how long your channel can
remain useful, but the other is how *much* flow there is -- if halving
your fee rate doubles the flow rate in sats/hour, then that will still
increase your profit. That also doesn't leak balance information.
> ### Inverting The Filter: Feerate Cards
> Basically, a feerate card is a mapping between a probability-of-success range
> and a feerate.
> * 00%->25%: -10ppm
> * 26%->50%: 1ppm
> * 51%->75%: 5ppm
> * 76%->100%: 50ppm
Feerate cards don't really make sense to me; "probability of success"
isn't a real measure the payer can use -- naively, if it were, they could
just retry at 1ppm 10 times and get to 95% chances of success. But if
they can afford to retry (background rebalancing?), they might as well
just try at -10ppm, 1ppm, 5ppm, 10ppm (or perhaps with a binary search?),
and see if they're lucky; but if they want a 1s response time, and can't
afford retries, what good is even a 75% chance of success if that's the
individual success rate on each hop of their five hop path?
And if you're not just going by odds of having to retry, then you need to
get some current information about the channel to plug into the formula;
but if you're getting *current* information, why not let that information
be the feerate directly?
> More concretely, we set some high feerate, impose some kind of constant
> "gravity" that pulls down the feerate over time, then we measure the relative
> loss of outgoing liquidity to serve as "lift" to the feerate.
If your current fee rate is F (ppm), and your current volume (flow) is V
(sats forwarded per hour), then your profit is FV. If dropping your fee
rate by dF (<0) results in an increase of V by dV (>0), then you want:
(F+dF)(V+dV) > FV
FV + VdF + FdV + dFdV > FV
FdV > -VdF
dV/dF < -V/F (flip the inequality because dF is negative)
(dV/V)/(dF/F) < -1 (fee-elasticity of volume is in the elastic
region)
(<-1 == elastic == flow changes more than the fee does == drop the fee
rate; >-1 == ineleastic == flow changes less than the fee does == raise
the fee rate; =-1 == unit elastic == you've found a locally optimal
fee rate)
You could optimise base fee in the same way, if you set F to be sats/tx
and V to be txs/hour, but then you're trying to optimise two variables
on a 2 dimensional plane, which is harder. So probably better to do
zero base fees and just set it to 0 and ignore it, or use your actual
computation costs -- perhaps about 20msat if you're paying $100USD/month
for your lightning node, a channel update takes 10ms, each forwarded HTLC
accounts for 4 updates, 2 on the incoming channel, 2 on the outgoing,
with no batching, and only 40% of payments are successful, at $20k/BTC.
It's likely more important to have balanced flows than maximally
profitable ones though, as that's what allows you to keep your channel
open. That's probably pretty hard to optimise, since a changed fee on
one channel will affect the volume on ther channels as well.
Relatedly:
> I want to propose that all published nodes support some kind of
> onchain/offchain swap capability.
If you're running a forwarding node, and collecting fees for forwarding,
considered in net your channels won't be balanced: the fees you collect
are all coming in, and there's nothing to compensate for that. Having some
way to send those fees "out" is necessary to keep your channels balanced
and avoid the need to have to close them. Having a swap capability like
this is perhaps a relatively easy way to be able to (automatically)
fix imbalances caused by collecting fees, and thus preserve your older
channels.
Cheers,
aj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
