Good morning list,
This is a short (relative to my typical crap) writeup on some strategies that
Lightning forwarding nodes might utilize.
I have been thinking of various strategies that actual node operators (as I
understood from discussing with a few of them) use:
* Passive rebalance / feerate by balance
* Set feerates according to balance: increase feerates when our side has low
balance, reduce feerates when our side has high balance.
* "passive rebalance" because we are basically encouraging payments via our
channel if the balance is in our favor, and discouraging payments if the
balance is against us, thus typical payments will "normally" rebalance our node
naturally without us spending anything.
* Low fee
* Just fix the fee to a low fee, e.g. base 1 proportional 1 or even the
@zerofeerouting guy of base 0 proportional 0.
* Ridiculously simple, no active management, no scripts, no nothing.
* Wall
* Set to a constant (or mostly constant) high feerate.
* Actively rebalance, targeting low-fee routes (i.e. less than our earnings),
and constantly probe the network for the rare low-fee routes that we can use to
rebalance.
* Basically, buy cheap liquidity and resell it at higher prices.
The interesting thing is how the three interact.
Suppose we have a mixed network composed ONLY of passive rebalancers and walls.
In that case, the passive rebalancers might occasionally set channels to low
fees, in which case the walls buy up their liquidity, but eventually the
liquidity of the passive rebalancer is purchased and the passive rebalancer
raises their price point.
The network then settles with every forwarding node having roughly equal
balance on their channels, but note that it was the walls who paid to the
passive rebalancers to get the channels into a nice balance.
In particular, if there were only a single wall node, it can stop rebalancing
once the price to rebalance costs more than 49% of its earnings, so it paid 49%
of its earnings to the passive rebalancers and keeps 51% of its earnings, thus
earning more than the passive rebalancers earn.
However, once multiple wall nodes exist, they will start bidding for the
available liquidity from the passive rebalancers and the may find it difficult
to compete once the passive rebalancers set their feerates to more than 50% of
the wall feerate, at which point the passive rebalancers now end up earning
more than the wall nodes (because the wall nodes now pay more to the passive
rebalancers than what they keep).
Thus, it seems to me that passive rebalancers would outcompete wall strategies,
if they were the only strategies on the network.
However, the network as-is contains a LOT of tiny nodes with low feerates.
In such an environment, walls can pick up liquidity for really, really cheap,
leaving the low-feerate nodes with no liquidity in the correct direction.
And thus, it seems plausible that they can resell the liquidity later at much
higher feerates, possibly outcompeting the passive rebalancers.
Unfortunately:
* Low feerate nodes are notoriously unreliable for payments; their channels are
usually saturated in one side or another. since walls keep taking their
liquidity.
* Because of this known unreliability, some payer strategies filter them out
via some heuristics (e.g. payment unreliability information).
Thus, even in the rare case where payment flows change on the network, they
are not used by payers --- instead, walls exploit them since walls do not care
if rebalancing fails, they will always just retry later.
* One argument FOR using low-feerate nodes is that it "supports the network".
* However, it seems to me that the low-feerate nodes are actually being
exploited by the wall nodes instead, and the low-feerate nodes have too little
payment reliability to actually support payers instead of large-scale
forwarders.
* Both low-feerates and walls do not leak their channel balances, whereas
passive rebalancers do leak their channel balance.
The above is just some thinking of mine --- actual experimentation on models or
on actual network nodes might be better than my speculation.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
