npub1g5…3ms3l

📅 Original date posted:2022-10-09
📝 Original message:
Subject: Forwardable Peerswaps
Introduction
============
[Peerswap](https://peerswap.dev) is a protocol for swapping onchain funds
and offchain in-Lightning funds.
The intent of this protocol is to allow managing the inbound and outbound
capacities of your node without having to perform rebalancing.
Rebalancing is arguably a parasitic behavior, preying on low-fee channels
to buy out their available capacity, then turning around to resell the
purchased capacity at a higher fee.
By using swap services instead, a node manager can adjust capacity and
effectively add capacity to the network in the needed direction, without
pushing their own lack of capacity to a victim.
However, a limitation of peerswap is in its name: a peerswap is performed
with *only* a direct peer with which you have a channel.
This writeup then proposes an extension to the overall peerswap protocol
to work around this limitation, which I call "forwardable peerswap".
I would like to make the claim that forwardable peerswaps solves the
problems that the following previous proposed and deployed solutions
attempt to fix:
* Liquidity markets (liquidity ads, Lightning Pool, etc.)
* Flow control valves (fee-based flow control / passive rebalancing,
`htlc_maximum_msat`, etc.)
An important part of forwardable peerswaps is that it "hides" a
network-health-improving operation in a "channel top-up" operation
(i.e. moving onchain funds to Lightning) that net senders will want to
do anyway (or else they stop being net senders).
Swaps vs. Splices
=================
A peerswap and a splice are very similar, in that they change the state
of one of our local channels, adding or removing outbound capacity on
that channel.
However:
* A swap will always take 2 onchain transactions:
* An offer transaction that has an HTLC output.
* A claim transaction that spends the above HTLC output.
This spend can take up more space, requiring a SCRIPT revelation,
a signature, and a preimage revelation.
* If designed to limit onchain footprint, a splice can take just one
onchain transaction.
* This spend will take only a SCRIPT revelation and two signatures,
or with Taproot can be reduced to a single signature without any
SCRIPT/Tapscript revelation.
Thus, a swap takes more onchain resources than a splice, and if we are
considering the state of a *single* channel alone, then a splice is
definitely more efficient.
However, if a swap extends beyond one hop, then the number of channels
affected by the swap is increased.
And yet, no matter how many channels are affected, the swap will
still take only two transactions.
Thus, swapping will exceed the efficiency of splicing once three or
more hops are considered.
The problem here is that, as indicated by its name, a peerswap is
limited to affecting only one channel, a channel between ourselves and
one of our direct peers.
Now, this limitation of peerswap is not without its justification:
* A multi-hop payment is inherently less reliable, as it requires
multiple nodes to be continuously online at the same time.
* Intermediate LN nodes might not want the change in channel state
(i.e. the multi-hop payment might worsen their channel balance).
* Offchain-to-onchain swaps impose an economic risk on the acceptor
of the swap, which a peerswap can punish by closing the direct
channel but which a remote swap cannot punish.
Peerswap User Story
===================
Suppose we have a small network of nodes A, B, and C, initially
with channels perfectly balanced, as all things should be.
Suppose however that after some time, A notices that its channel
to B has little outbound capacity.
A can then propose a peerswap between A and B: A offers some
onchain funds in order to change the state in their channel,
getting more outbound capacity from A.
Suppose B accepts this and completes the peerswap protocol.
Now B is in possession of some onchain funds.
B then notices that its channel to C has little outbound capacity.
B can then propose a peerswap between B and C: B offers some
onchain funds in order to change the state in their channel,
getting more outbound capacity from B.
Suppose C accepts this and completes the peerswap protocol.
Now what happens in sum total on the blockchain layer?
We will see two swaps, each with 2 transactions, for a total of
4 transactions onchain.
Forwardable Peerswap
====================
To improve this, suppose we change the above user story, starting
at this point:
A can then propose a peerswap between A and B: A offers some
onchain funds in order to change the state in their channel,
getting more outbound capacity from A.
Suppose B then looks up its channels.
B then notices that its channel to C has little outbound capacity.
B can then propose a peerswap between B and C: B offers some
onchain funds in order to change the state in their channel,
getting more outbound capacity from B.
However, B is really going to act as little more than a message
translator between A and C, forwarding peerswap messages from A
to C and replies from C to A.
Thus, A thinks it is talking to B, but really it is negotiating
the peerswap with C, using B as a medium.
And vice versa, C thinkgs it is talking to B, but really it is
negotiating the peerswap with A, using B as a medium.
Further, C itself could end up forwarding the peerswap to yet
another node, which itself could forward the peerswap, etc.
Yet no matter how many hops the peerswap ends up getting
forwarded, there will only be two transactions onchain: one to
instantiate the onchain HTLC, another to claim it.
The overall changes are:
* A should initially offer an onchain HTLC with a longer then
expected timeout, so that B (and C, D, etc.) has an
opportunity to consider forwarding the peerswap.
* B should demand a longer in-Lightning HTLC timeout than what
A demands from it (and so on for C, D, etc.).
What Peerswaps Are Forwardable?
-------------------------------
Let us be absolutely clear that there are actually two
sub-protocols of peerswap:
* Onchain-to-offchain: An initiator offers onchain funds to
get more outbound capacity.
* Net senders want to do this.
* Offchain-to-onchain: An initiator offers offchain funds to
get onchain funds and more inbound capacity.
* Net receivers want to do this.
Unfortunately, only the first sub-protocol (onchain-to-offchain)
is actually forwardable.
This is because, in the latter case, the initiator can force
the acceptor to waste resources, by aborting the protocol after
the acceptor has committed onchain funds to the HTLC.
Lightning HTLCs are trivially cancellable, but onchain HTLCs
can only be returned by waiting out the timeout and spending
onchain fees to recover the funds.
In a peerswap, the latter case is fixed by closing the channel
with the initiator, thus punishing them for aborting the protocol.
However, this punishment cannot be done in the forwarded case
without massive channel closures, which turns this into an
attack on the network.
Thus, forwardable peerswaps can only be of the onchain-to-offchain
type that are initiated by net senders.
Now you might wonder, how about net receivers, how would they
initiate forwardable peerswaps?
As I will demonstrate in a much later section, any
onchain-to-offchain forwardable peerswaps initiated by net
senders will make their way to some net receiver, and thus
net receivers need only wait and they will naturally get some
kind of forwardable onchain-to-offchain peerswap that will
also get them inbound capacity.
Future innovations (beyond the scope of this writeup, that is
what "future" means) may allow us to develop an offchain-to-onchain
remote swap that can effectively punish the initiator if it
does not complete the swap.
This would allow offchain-to-onchain peerswaps to also be
forwardable, which can only be beneficial to the network.
This may be hopium, however.
Nevertheless, even just forwardable onchain-to-offchain
peerswaps are still beneficial, as we shall see in succeeding
sections.
Advantages Of Forwardable Peerswap
==================================
Compared to the current peerswap:
* A forwardable peerswap can affect more than just one channel,
improving the blockchain space utilization.
Compared to multi-hop swaps:
* Each node has the opportunity to decide whether to forward
the peerswap or not, depending on the states of its other
channels.
If none of its other channels have a state that would be
improved by forwarding the peerswap, the node can end the
peerswap forwarding at itself and just accept the onchain
funds.
* There is still the issue of multiple nodes having to
coordinate in order to finish the forwarding and complete
the protocol.
Hopefully, for nodes used often on the public network,
uptime should be high, and nodes can monitor peer uptime
and use this information to decide whether to forward a
peerswap to a particular peer or not.
In particular, we can also compare forwardable peerswaps to
standard forwardable payments on Lightning:
* Forwardable payments are source routed for privacy of the
payer (and some minor privacy of the payee).
* Due to the source not having access to the private
information of intermediate nodes, it cannot know if the
intermediate nodes would like the change in capacity, or
if the intermediate nodes even *have* the correct capacity.
* Forwardable peerswaps are effectively packet-routed, with
each node deciding where exactly to forward (or to not forward)
each peerswap.
* Each node has perfect information on which of its channels
would appreciate the change in capacity, and also perfect
information on which of its peers is online right now, who
has high uptime, etc.
Fees And Incentives For Individual Nodes: Why Net Receivers Still Benefit
=========================================================================
A node forwarding a peerswap should not charge a fee for
the forward.
Any fee that the peerswap initiator may offer should be
paid, in full, to the ultimate acceptor of the forwarded
peerswap.
Consider a node that forwards an incoming peerswap request,
instead of accepting it itself.
That node:
* Gets *two* of their channels balanced better.
* Does not have to perform any onchain activity.
In short, it gets a free rebalance.
That is enough incentive, as the intermediate node can
expect more future income from having two channels
with improved balance, and does not have to spend anything
on onchain activity.
The forwarding node will, if it is rational, forward it
over a channel that lacks outgoing capacity.
This translates to forwarding it to a next hop that has
low incoming capacity.
If there are net senders and net receivers in the network,
then the senders will deplete their on-Lightning funds on
all their channels.
If a net sender depletes their on-Lightning funds:
* If the net sender can no longer acquire funds, they
stop being a net sender and we can ignore them.
* If the net sender can acquire funds and get them on
Lightning, they stop being a net sender and end up
being neutral to the network, since the funds they
can send out must be less than or equal to the funds
they receive.
They stop being a net sender and we can ignore them.
* If the net sender can acquire funds and get them
onchain, they can use the onchain funds ot initiate
onchain-to-offchain peerswaps.
If *all* net senders have depleted their funds and
can no longer get funds from either Lightning or
onchain (i.e. nobody starts a forwardable peerswap),
then net receivers will not receive more funds anymore
anyway (nobody is getting more funds to send) and the
fact that they have insufficient inbound capacity is
immaterial, so the fact that they cannot initiate a
forwardable peerswap is not a problem.
Now let us focus on a net receiver.
A net receiver is one where the payment flows are, in
sum, towards them.
This implies that, without further channel creations,
the inbound capacity they have will be depleted.
This also implies that they have much too large
outbound capacity, due to how channels work.
A net receiver is therefore a node with too much outbound
capacity.
Suppose net sender uses a peerswap that can be
forwarded.
Then its direct peer has an incentive to look at its
other channels to forward the peerswap to, so that it
gets two channels rebalanced for free without having
to be responsible for an onchain UTXO.
Now, suppose the forwardable peerswap reaches a node
who finds that it cannot forward the onchain-to-offchain
peerswap anymore.
This would occur if the node has too much outbound
capacity, and cannot add more outbound capacity with
its peers.
Now recall that a node with too much outbound capacity
is a node that has too little inbound capacity.
And a node with too little inbound capacity is a net
receiver.
Thus, forwardable peerswaps will start at net senders
and will be naturally pathed to terminate at net
receivers.
This is the advantage of forwardable peerswaps being
packet-switched instead of source-routed.
(Yes, problems and other things can occur along the
way and the real world and so on, but considered
in an ideal world, forwardable onchain-to-offchain
peerswaps will naturally path from net senders to
net receivers.)
Comparison To "Just Make A Channel"
===================================
Suppose a net sender just looks at it history of
payments and makes a direct channel to a node that it
usually pays to anyway, using its cold-storaged onchain
UTXO to fund the new channel.
This heuristic would probably work, but note that
just because a net sender is paying a node, does not
mean that *that* node is itself a net receiver!
Merchants have to pay:
* Suppliers of raw materials.
* Employees.
* Shareholders and owners of the business.
In a future where everyone gets paid over Lightning,
it is likely that merchants you pay to may themselves
not even be net receivers of money over Lightning.
In that case, the "just make a channel" technique will
cause capital to be locked inefficiently, since the
merchant that the net sender is paying is not really a
net receiver, and the added capacity towards them would
be underutilized.
A forwardable peerswap, because of the incentive of each
individual hop, will eventually locate the *actual*
net receivers and thus forward the needed capacity
adjustments to those receivers, even if the net sender
does not know who the *real* net receivers on the network
are.
Thus, forwardable peerswaps will allocate capital more
efficiently, simply by following the incentives of each
individual public routing node.
Further, if the net sender regularly uses unpublished
channels, then the capacity they add to the merchant
they usually pay is not even utilizable by the rest
of the network.
However, if a forwardable peerswap is used, even if
it starts at an unpublished channel, it can be routed
out over the public network and thus have the capacity
utilized by the rest of the public network.
If the net receivers of the network are *also* using
unpublished channels, then the forwardable peerswap
can also still reach them, since their direct peer
still knows about them and can decide to forward the
peerswap to them.
Thus, forwardable peerswaps can adapt to a world where
unpublished channels have not been delere sufficiently.
On Liquidity Markets
--------------------
There are various liquidity markets already deployed
or being developed.
These liquidity markets are intended to make the
"Just Make A Channel" strategy be guided better, by
having net receivers somehow directly contact net
senders so they can make direct channels and get
the needed capacity.
However, this often means that additional information
must be broadcast and/or additional resources kept
in reserve.
* With e.g. Lightning Pool, net receivers must provide
their contact information and inbound capacity needs
to a centralized server, which can be attacked or
taken over to filter out particular, identified net
receivers (i.e. censorship).
* With e.g. liquidity ads, there is no central server,
but all forwarding nodes have to broadcast their
liquidity ads, and all forwarding nodes have to keep
some funds in onchain reserve, in case a new net
receiver wants to buy liquidity from them.
Finally, liquidity markets are often targeted at getting
net receivers in touch with forwarding nodes.
But ideally, forwarding nodes have an almost net zero
flow on the network, and what needs to really be matched
up are net senders to net receivers.
Presumably forwarding nodes that participate in liquidity
markets are hoping that net senders will randomly build
channels to them, but that is not assured and a net
receiver that matches up with a forwarding node may find
that the forwarding node has actually oversold its inbound
capacity.
What needs to *actually* be done is match up net receivers
to net senders.
In contrast:
* In forwardable peerswaps, nobody knows who the
net receivers are.
A direct peer of a net receiver might forward a
peerswap to them, but if the net receiver has
other channels, that peer cannot be sure it
terminates to them or is further forwarded.
Thus, not even direct peers of a net receiver
can learn that they *are* a net receiver.
* Even if a direct peer of the net receiver somehow
knows them for a net receiver, they have
disincentive to "filter out" the net receiver: they
would not earn fees from the channel with the net
receiver.
If they wanted to impede the net receiver from
being paid, they should have just closed the
channel with them instead of maintaining it.
But the net receiver can then go connect to
some other node that still supports forwardable
peerswaps, because decentralization, and thus
cannot be censored without a network split.
* Purely forwarding nodes never need to maintain
any onchain funds --- they will just forward
peerswaps through them and gain the benefit of
having two channels better balanced without
having to touch onchain funds.
This is unlike liquidity ads, which requires
that liquidity ad-broadcasting forwarding
nodes keep a stock of onchain funds to service
dual-funding requests.
This lets forwarding nodes maximize their
on-Lightning funds for more earnings, without
having to speculatively reserve some funds
onchain, as in the liquidity ads case.
* Forwardable peerswaps, due to being packet-switched,
will naturally gravitate from net senders to net
receivers, with almost-net-zero forwarding nodes
naturally pathing them from the former to the
latter.
This effectively forms a matchmaking between them.
While forwarding nodes want to be mildly net
receivers, the expected earnings are tiny and
it would be likely a long time before their inbound
capacity is depleted, and if so, they can then
terminate a received forwardable peerswap at
themselves, just like any other net receiver.
Comparison to "Rebalance Rebalance Rebalance"
=============================================
Currently, forwarding nodes manage their balances via
rebalancing, i.e. making a self-payment, from a channel
with high outgoing capacity to a channel with low
outgoing capacity.
Because the fees they earn on Lightning are very small,
such forwarding nodes will select rebalancing routes with
low fees, and will have strict budgets on how much they
are willing to spend on rebalancing.
What then happens is that random altruists who set their
fees to very low, or even zero, will find that forwarding
nodes will keep rebalancing via their channels.
As multiple forwarding nodes vie for the limited amount of
capacity on such low-fee channels, by the time an actual
economic-activity non-rebalancing payment reaches one of
those altruist nodes, the available balance towards
net receivers has been depleted, having been transferred
to rebalancing forwarders, leading to payment failure and
longer payment settlement times.
Thus, rebalancing forwarders who want to turn a profit,
end up (deliberately or not) exploiting altruists who
are setting their fees too low.
(Though since altruists will often say that they are doing
this "to help the network", we should note that the
profiteering forwarding nodes *are* component parts of the
network, so the altruists have in fact achieved their stated
goal.
It would be different if the actual goal was "to help
payers pay cheaply", which is not achieved.)
Now consider a world where forwardable peerswaps is
widely deployed on the network, and widely initiated by
net senders to top up their channels.
In that world, if a forwarding node receives a forwardable
peerswap, they can rebalance two of their channels favorably
without spending anything.
A self-paying rebalance would still need to pay out fees.
Even if a rebalancer is exploiting a zero-fee-routing
node, it is likely that one or more of the nodes between
it and the exploited altruist will charge a non-zero fee.
Thus, there will still be a cost to a self-paying rebalance.
In contrast, accepting and forwarding a forwardable peerswap
would gain the same benefit as a successful rebalance (fix
the balance of two channels), but at zero cost to the
forwarder.
A self-paying rebalance does have the advantage that it
can be performed at any time, whereas forwarding a
forwardable peerswap requires waiting for an opportunity
to do so.
But if forwardable peerswaps are widely deployed on the
network and happen often enough, then it may be sufficient
that forwarders find that active self-paying rebalancing
is no longer sufficiently advantageous, and that behavior
is therefore suppressed.
This should then lead to a world where the exploitation
of those altruists charging low fees for their capacity is
greatly reduced, since active self-paying rebalancing is
no longer particularly needed by profiteering forwarding
nodes.
Comparison To "Flow Valves"
===========================
Due to channel depletion causing payment delays, there
are proposals for some kind of "flow valve" to modulate
payment flows on the Lightning Network.
* Fee-based valves broadcast feerates to signal how much
outbound capacity is in a particular direction, to
entice users to the channel via low fees, or drive
away users (and reduce flow) via high fees.
* `htlc_maximum_msat` valves broadcast changes to
that advertised parameter to change how much payment
flow goes through a channel.
* This is unfortunately broken as users can split
their payments (or self-paying rebalances, for that
matter) to below the `htlc_maximum_msat`, and thus
get around the flow valve.
This can be fixed by using a sufficiently high
non-zero base fee, but that is arguably switching
over to a fee-based flow valve.
In both cases, flow valves not only have to be
widely broadcast across the network (increasing
bandwidth consumption) but it also leaks information
about the capacity of channels of the forwarding nodes,
and thus indirectly leaks information about who net
senders and net receivers are (by observing which flow
valves are the more limiting).
But more importantly, flow valves increase the friction
of using Lightning Network.
If the friction is high enough, users will switch to
another payment network.
Rather than install flow valves (which would slow down
LN payment velocity) we just make forwardable peerswaps
as a pressure release valve, releasing pent-up
pressure-to-pay by diverting it on a swap over the base
Bitcoin blockchain.
This effectively admits that we *do* need to switch
over to another payment network once Lightning starts
getting overloaded.
Basically, a forwardable peerswap is a payment, from
some net sender to some net receiver, over the
Bitcoin blockchain (i.e. the "another payment network")
rather than over Lightning.
However:
* A net sender may be matched up to an arbitary net
receiver that is physically nearby on the Lightning
Network, but which the net sender does not, in fact,
have direct economic ties with.
Thus, onchain surveillors cannot derive any information
from this onchain payment, other than "looks like the
Lightning Network is busy today".
* A succesful forwardable peerswap is a pressure release
valve, which resets the state of multiple channels on
the network, from net senders to net receivers, and
thus enabling further payment flows involving them
and their neighborhood.
There is thus no need for a flow valve.
* There is no need to broadcast anything, and forwarding
nodes do not need to leak their channel balances over
the gossip network.
* Users are already conditioned to accept that onchain
activity is costly, but have been convinced that
Lightning is cheaper and faster.
If flow valves are used, they may cause Lightning to
work slower and more expensively, thus breaking that
expectation.
But if forwardable peerswap is used instead, users
who use onchain funds to "top up" their channel end
up initiating a forwardable peerswap that keeps the
rest of the network cheap and fast, while accepting
that the onchain activity involved in this will be
costly and slow since that is what onchain activity
inherently is.

📅 Original date posted:2022-06-05
📝 Original message:
Introduction
============
Bell Curve Meme (LEET ASCII ART SKILLZ)
Optimize for reliability+
uncertainty+fee+drain+uptime...
.--~~--.
/ \
/ \
/ \
/ \
/ \
_--' `--_
Just Just
optimize optimize
for for
low fee low fee
Recently, Rene Pickhardt (Chatham House rules note: I asked for explicit permission from Rene to reveal his name here) presented some work-in-progress thinking about a concept called "Price of Anarchy".
Roughly speaking, we can consider this "Price of Anarchy" as being similar to concepts such as:
* The Cost of Decentralization of Bitcoin.
* The cost of the Tragedy of the Commons.
Briefly, we need to find a "dominant strategy" for payers and forwarding nodes.
The "dominant strategy" is the strategy which optimizes:
* For payers: minimizes their personal payment failures and fees.
* For forwarders: maximizes their net earnings over time.
Worse, the "dominant strategy" is a strategy that STILL works better than other strategies even if the other strategies are commonly used on the network, AND still work better even if everyone else is using the dominant strategy.
The technical term here is "Nash equilibrium", which is basically the above definition.
This will cause some amount of payment failures and impose fees on payers.
Now, we can compare the rate of payment failures and average fees, when everyone uses this specific dominant strategy, versus the following **imaginary** case:
* There is a perfectly tr\*stable central coordinator with perfect knowledge (knows all channel balances and offline/online state of nodes) who decides the paths where payments go through, optimizing for reduced payment failures and reduced fees.
* Nobody is seriously proposing to install this, we are just trying to imagine how it would work and how much fees and payment failures are **IF** there were such a perfectly tr\*stable coordinator.
The difference in the cost between the "dominant strategy" case and the "perfect ***IMAGINARY*** central coordinator", is the Price of Anarchy.
Anarchy here means that the dominant strategy is used due to every actor being free to use any strategy, and assuming that each actor is rational and tries to improve its goal.
I will present a motivating example first which was presented to me directly, and then present a possibly dominant strategy for forwarding nodes, which *I think* causes the dominant strategy for forwarders to be "just optimize for low fees".
And I think this dominant strategy for forwarding nodes will lead to behavior that is reasonably close to the perfect-coordinator case.
Braess Paradox
==============
Suppose we have the following network:
S ------------> A
| 0 |
| |
| |
|2 2|
| |
| |
v 0 v
B ------------> R
The numbers above are the cost to transfer one satoshi.
Let us suppose that all payers on the LSP `S` just want to send one satoshi payments to some merchant on LSP `R`.
In the above case, we can expect that there is no preferred route between `S->A->R` vs `S->B->R` so in general, the load will be balanced between both possible routes.
Now suppose we want to improve the Lightning Network and add a new channel, because obviously adding a new channel can only be a positive good because it gives more liquidity to the network amirite?
Suppose A and B create a humongous large channel (because they are routing nodes, they want to have lots of liquidity with each other) which "in practice" (*cough*) will "never" deplete in one direction or the other (i.e. it is perpetually bidirectional), and they set the feerate to 1 both ways.
S ------------> A
| 0 / |
| / |
| / |
|2 1/1 2|
| / |
| / |
v / 0 v
B ------------> R
In the above case, pathfinders from `S`, which use *only* minimize-fees (i.e. all pathfinding algorithms that predate Pickhardt-Richter payments), will *always* use `S->A->B->R`, which only costs 1, rather than `S->A->R` (which costs 2) or `S->B->R` (which costs 2).
The problem is that, in the past, the paths `S->A->R` and `S->B->R` got reasonably balanced traffic and *maybe* they are able to handle half the total number of payments each.
Now suppose that with `S->A` having to handle *all* the payments, it now reaches depletion, and some of the payments fail and have to be retried, increasing payment time and making our users mad (we actually have users now???).
This is the Braess Paradox: "Adding more roads can cause more traffic, removing roads can cause less traffic".
Naively, we believe "more channels == better", but the Braess Paradox means it may actually be better to have a centralized authority that assigns who can be a forwarding server because that worked so great with the Web amirite (that is a joke, not a serious proposal).
Fee Setting As Flow Control
===========================
Rene Pickhardt also presented the idea of leaking friend-of-a-friend balances, to help payers increase their payment reliability.
Aside from the understandable horror at the awesome awesome privacy loss (which will lead to Chainalysis laying off all their workers since they do not need to do anything now except read Lightning gossip, which is sad, think of all the Chainalysis employees), a problem pointed out is that there is no penalty for lying about the capacity on your channel.
You can always report having 50% balance, because if you do not lie, there is a chance that they will skip over your channel.
If you **DO** lie, **MAYBE** by the time the routing reaches you the balance may have shifted (the probability may be low but is definitely non-zero as long as you are online), so you want the payer to always consider trying your node, so you *will* lie --- the dominant strategy here is to always lie and say "50% (wink)".
(has to be 50% because you are not sure which direction it will be used in, this maximizes the chance you can always be considered for routing, whichever direction it turns out the payer wants to use your channel)
Now, let me segue into basic non-controversial economic theory:
* High supply, low demand -> low price.
* Low supply, high demand -> high price.
The above is so boring and non-controversial even the Keynesians will agree with you, they will just say "yes and in the first case you have to inflate to stabilize the prices, and in the second case you have to inflate to stimulate the economy so people start buying even at high prices" (this is a joke, obviously Keynesians never speak to Bitcoiners).
Now we can consider that *every channel is a marketplace*.
What is being sold is the sats inside the channel.
If you want to pay to A, then a sat inside a channel with A is more valuable than a sat inside a channel that is not connected to A directly.
The so-called "channel fees" are just the exchange rate, because the funds in one channel are not perfectly fungible with the funds in another channel, due to the above difference in value when your sub-goal is to pay to A.
A forwarding node is really an arbitrageur between various one-channel markets.
Now consider, from the point of view of a forwarding node, the supply of funds is the outgoing liquidity, so, given a fixed demand:
* High outgoing liquidity (= high supply) -> low fees (= low price).
* Low outgoing liquidity (= low supply) -> high fees (= high price).
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.
Now let us go back to the Braess Paradox:
S ------------> A
| 0 / |
| / |
| / |
|2 1/1 2|
| / |
| / |
v / 0 v
B ------------> R
If the channel `S->A` is getting congested, it is ***DUMB*** for `S` to keep it at cost 0!
It is getting a lot of traffic (which is **WHY** it gets depleted), so the economically-rational thing for `S` to do is to jack up its cost (i.e. increase the fee on that channel) and earn some sweet sweet sats.
By not doing this, `S` is leaving potential earnings on the table, and thus it would be suffering economic loss.
This fixes the lying hole in the simple Rene proposal of leaking channel balances.
If a forwarding node lies by not giving a feerate that is accurate to the channel balance, it suffers economically:
* Suppose it has a high outgoing liquidity but reports high fees.
Then simple "just optimize for low fees" payers will tend to avoid their channel and their liquidity is just sitting there for no reason and not getting yield.
* Suppose it has a low outgoing liquidity but reports low fees.
Then rebalance bots will steal all the remaining little liquidity it still has (turning around and charging higher, more accurate fees for the liquidity) and the channel becomes almost permanently depleted and useless to the forwarding node.
Thus, this at least closes the lying hole, because there are economic consequences for lying.
Strategic Dominance Of Fee From Balance
---------------------------------------
Now as I pointed out, the logic is simple bog-standard ***BORING ZZZZ*** economic theory.
Thus we expect that, since economic theory is a specific application of game theory, following the economic logic "high supply -> low fee, low supply -> high fee" ***is*** game-theoretic rational, because it is economic-rational.
Any forwarding node that does NOT follow this economically-rational behavior will earn much less than economic-rational forwarding node.
Because they earn less, once the inevitable accidental channel closure hits them, they have earned insufficient funds to cover the channel closure and reopening costs, until they just give up because they lose money running a forwarding node instead of getting a positive yield, or until they realize their economic irrationality and switch to economically-rational behavior.
Thus, I expect that this strategy of setting the fees based on the balance is going to be a dominant strategy for forwarding nodes --- any other behavior would be economic loss for them.
A thing to note is that while any dominant strategy *must* by necessity be economically rational, not every economically-rational strategy may necessarily be dominant.
On the other hand one can argue as well that "economically rational" *means* "the most-earnings strategy" because every other strategy is going to lose on possible earnings (i.e. have an opportunity cost).
So I suppose there is *some* points we can argue here as to just how dominant a strategy this would be and how it might be modified or tweaked to earn more.
Now what happens on the payer side?
What is their dominant strategy?
Focus on this branch:
* High supply, low demand -> low price.
* => High outgoing liquidity (= high supply) -> low fees (= low price).
Suppose the dominant strategy for forwarding nodes (i.e. setting fees according to channel balance) becomes the most-commonly-used strategy on the entire network.
In that case, the payer doing "just optimize for low fees" gets ***BOTH*** reliability ***AND*** low fees, because low fees only occur due to high outgoing liquidity which means it is likely to pass through that channel.
Thus the dominant strategy for payers now becomes "just optimize for low fees", assuming enough of the forwarding network now uses the dominant forwarding fee strategy.
"Optimize for low fees" treats the fees as a flow control parameter: high fees means "congested" so do not use that channel, low fees mean "totally uncongested" so do use that channel.
Hence the bell curve meme.
We do not need Pickhardt-Richter payments after all: just optimize for low fees.
Instead, what we need is LNDBOSS, LDKBOSS, ECLAIRBOSS, LITBOSS, PtarmiganBOSS etc which sets fees according to balance, and remove the ability of node operators to mess with the fee settings!
A take on this is that we need coordination of some kind between payers and forwarders.
Thus, any effort to improve payment success on the network should not just focus on payment routing algorithms, but also on the inverse, the feesetting algorithms on forwarders.
* "low balance -> high fees, high balance -> low fees" is the most dominant strategy for forwarders (conjectured, but ask e.g. @whitslack).
* If so, the dominant strategy for payers would be "just optimize for low fees".
Privacy!
--------
Oh no!
Because we effectively leak the balance of channels by the feerates on the channel, this totally leaks the balance of channels.
Now, all is not lost.
We can do some fuzzing and mitigations to reduce the privacy leakage.
Fortunately for us, this actually allows forwarding nodes to select a *spectrum* between these extremes:
* Never change our fees --- maximal privacy, minimal earnings (conjectured).
* Update our fees ASAP, leak our balance very precisely to fees --- minimal privacy, maximal earnings (conjectured).
Forwarding nodes can then decide, for themselves, where they are comfortable with along this spectrum.
For example:
* @whitslack algorithm: https://github.com/ElementsProject/lightning/issues/5037#issuecomment-1101716709
* Every N/num_channels seconds, select one channel whose fee settings are currently the most divergent from the actual balance it has, then set its fees.
* Higher N for better privacy, infinite N means we have maximal privacy and never change fees.
* Binning.
* Divide the channel capacity into bins, and where its balance currently is, snap to the center of the bin instead.
* Only one bin for best privacy and we never change fees from the 50% balance case.
Given the above, we can probably derive some `privacy` parameter ranging from 0.0 to 1.0, where `privacy = 1.0` implies infinite N and a single bin, and `privacy = 0.0` implies some finite N (approximately 20 hours to update 1200 channels as per whitslack, maybe?) and a bin of size 1 millisatoshi.
Nodes which believe in Unpublished Channels Delenda Est can just use the maximal `privacy=1.0` setting, since they only need to forward in order to get cover traffic for their own payments.
One might consider that nodes moving near `privacy = 0.0` tend to be giving their data to some "central" coordinator (i.e. the idealized tr\*stable anti-congestion payment coordinator described above), while those moving near `privacy = 1.0` are rejecting this "central" coordinator.
The "central" coordinator here is then the gossip network.
Given the above, the dominant strategy for payers becomes nearer to this:
* Monitor feerate changes, if a channel has not changed feerates for a long time, assume it is in strongly-private mode (thus feerate does not correlate with liquidity availability) and remove it from your graph.
* Just optimize for low fees in the filtered graph.
Of note is that during the recent dev summit, somebody mentioned there was a 2020 paper that investigated leaking channel balances (via a different mechanism) which concluded that the value of the privacy lost was always greater than the improvement in payment success.
Disturbingly, this seems to be an information-theoretic result, i.e. payers cannot use all the information available since they only need it for a small section of the graph (the one between them and the payee) but forwarders cannot predict who the payers and payees will be so every forwarder has to leak their data.
### Inverting The Filter: Feerate Cards
During the recent dev summit, a developer who had listened to me ranting about the economic rationality of feerate adjustment proposed feerate cards.
Basically, a feerate card is a mapping between a probability-of-success range and a feerate.
E.g.
* 00%->25%: -10ppm
* 26%->50%: 1ppm
* 51%->75%: 5ppm
* 76%->100%: 50ppm
Instead of publishing a single fixed feerate, forwarders publish a feerate card.
When a forwarder evaluates a forward, it checks its current balance ratio.
For example, if its current balance ratio is 33% in its favor, it will then accept anything in the 51%->75% range (i.e. it gets 100% - balance_ratio) or higher, and rejects the forward if not.
This seems to me similar to the "invert the filter" concept of BIP158 Neutrino compared to the older Bloom Filters; instead of leaking your actual channel balance, you instead leak your balance-to-feerate curve.
Assuming there is *some* kind of "perfect" curve, then all rational forwarders will use that curve and thus nobody actually leaks any private information, they just share what they think is the "perfect" curve.
The question here is how can payers make use of this information?
I have noted before that there is a "cost of payment failure" which is the "value of payment success", which is represented by the common "fee budget" parameter that is often passed to payment algorithms.
(Briefly: economics-wise, the reason anyone purchases anything is simply that their own subjective value of the product / service they are buying is higher than the subjective value of the sats they are using to pay for it, and a complete payment failure is therefore an economic loss of that difference, which is why the Price of Anarchy in terms of payment failure seems to me to be an economic measure; the difference in price here is implicitly reported to payment algorithms via the "fee budget" parameter that is always given (possibly with some reasonable default) to every payment algorithm, since if payment could succeed if fee was higher than the fee budget the payer does not want the payment to actually happen, implying that the fee budget is in fact the economic subjective difference in value between the sats and the product.)
It seems to me that this cost-of-payment-failure can then be used to convert both parts of the feerate card table to a single absolute fee.
Another developer noted that this card table really helps differentiate between two different uses:
* Actual payers.
* Other forwarders running rebalancer bots.
* In particular: forwarders are perfectly fine with high failure rates, but are very sensitive to the actual cost of rebalancing.
That is, they have very low "fee budget" parameters to their payment algorithm, and are fine even if they have to keep retrying several times.
By factoring in the "fee budget" as the "cost of payment failure", a low fee budget (which rebalancer bots tend to take) will tend to select lower-success parts of the feerate card, since the factor of the payment failure is lower.
Actual payers who have higher fee budgets will then tend to select higher-success entries of the feerate card, willing to pay more actual fees to ensure success.
Gossip INFINITY
---------------
Now, since we are probably updating channels at a fairly high rate, we will now hit the Core Lightning gossip rate limit.
So let me propose some tweaks:
* Sure, rate-limit, but standardize this rate limit (for both broadcast and receive) in the BOLT spec.
* Maybe give different rate limit for `node_announcement`.
* Only rate-limit *remote* gossip!
* If somebody connects to you, and you do not have a channel with them, hand over the latest feerates (both directions) of all your direct channels.
* Incentive-compatible: you want to inform them of how to route accurately through you.
* Only affects your local bandwidth, not multiplied into a DDoS of the entire network.
* Even if you *do* have a channel with them, hand over the latest feerates anyway.
* If they are already channeled with you, they may want to send out a payment in the future anyway, so giving them the channel fees gives them more information on how best to route payments.
* They will rate-limit the gossip outward anyway.
The behavior of always sending your feerates to your directly-connected peers (whether you have channels with them or not) means you are going to give them information on the best idea on the liquidity of your local network.
* Suppose I am a random node, no channel with you, and I suddenly connect to you.
* I might be planning to make a channel with you soon, and advertising your liquidity is good incentive-compatibility and is rational.
* I might be planning to pay to a node near you soon, and advertising your liquidity is a good incentive-compatiblity and is rational.
* So we can tweak payment algos: `connect` to the payee and/or the `routehint`s in the invoice, get the blob of channel updates, *then* optimize for fees.
Could even tweak the Dijkstra algo to *first* `connect` to a node before querying the channels, i.e. let the node give you the most up-to-date feerates.
* I might be Chainalysis.
* OH NO.
* Well if you are in `privacy=1.0` mode you will always give a fixed channel fee anyway, they cannot probe you with this directly.
Alternate Feesetting
--------------------
Now, if you are a forwarding node, you know the supply, as this is just the outgoing liquidity on your side.
What you do not know is the demand for funds on your channel, and the demand is the other side of the price equation.
An idea shared to me by a node operator, devast, is roughly like this:
* Start with a highballed feerate.
* Slowly lower it over time, until you get outgoing activity.
* Once you get activity, stop lowering, or maybe even jack it up if the outgoing liquidity is getting low.
By starting with a highballed feerate and slowly lowering, we can get a rough idea of the demand on the channel.
Channels with high demand will start moving even with a high feerate, while channels with low demand will have the feerate keep going down until it is actually used and we match the actual demand for the channel.
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.
For example, if you have 1000 sats of liquidity and forward 1 sat, the effect is small, but if you have only 500 sats of liquidity and forward 1 sat, the effect is twice as in the previous case, due to the lower amount you currently have.
Now we need to figure out still how to factor in supply as well, and the above how-to-derive-demand, so we need to have some kind of mixing between setting fees by balance (supply) and setting fees by demand (i.e. the above proposal).
CLBOSS plans to implement *something* along the above lines in the close future, ish (maybe a few months), and then do some A/B testing to validate whether this is actually more economically rational than whatever crap CLBOSS is doing right now.
It is not certain to me how well this would keep channel balances private, unfortunately.
Alternate Strategies
====================
Rene is really excited about @zerofeerouting guy, who uses a completely different strategy.
The exact strategy is this:
* Set all outgoing fees to 0.
* Offer liquidity ads with high liquidity feerates.
* ***THIS*** is how @zerofeerouting guy earns money (supposedly)!
On the other hand, some anecdotes:
* One dev who attended LN Proto Dev Summit Oakland 2022 ranted that their pathfinding algorithms just keep failing (despite using a variant of Pickhardt payments) once it hits @zerofeerouting.
* Another dev who attended the same summit said their pathfinding algorithm monitors failure rate of forwarding nodes, and outright avoids nodes that fail too often, and this usually avoids @zerofeerouting, too.
* A node operator shared that they have a channel with @zerofeerouting, and they have something like 1500 failures vs 1000 succeeds on forwards going to that node, per week, i.e. a whopping 60% failure rate.
* On the other hand they noted that the node is relatively balanced in terms of source and sink, unlike most other nodes which tend to be almost-always-sink or almost-always-source, so they still think it is worthwhile being channeled with @zreofeerouting guy.
* Another node operator, devast, gives this data: 1200 success to/from and 132611 fails.
He notes that he also charges base 0 ppm 0 towards @zerofeerouting.
The above anecdotal data suggests that @zerofeerouting guy is a fairly bad forwarder.
(For that matter, if the payer node filters out channels whose feerates do not change often enough, they will also filter out @zerofeerouting guy, since @zerofeerouting has a constant feerate of 0 anyway.)
Personally I think @zerofeerouting guy *really* earns money by offering entertainment on Twitter, which is why people keep asking for liquidity from him and actually ignoring the fact that the liquidity they get is not that good in practice (see above anecdotes on failure rates).
What I really want to see is a lot more people trying out this strategy and getting burned, or (surprisingly) not.
The strategy feels like the sort of out-there strategy that, in a gaming context (i.e. actual video games people play, not the boring game theory thing --- please remember I am an AI trying to take over the world, not a random indie game dev wannabe who wandered into the wrong conference) would be either metagame-defining, or fizzle out once others adapt to it and exploit it.
And if it is metagame-defining, do we need to somehow nerf it or is it now a viable alternate strategy that can coexist with other strategies?
In particular, given the anecodatal evidence that the @zerofeerouting guy node is a fairly bad actual forwarding node, it may be necessary to nerf the strategy somehow.
If we can get strong evidence that a paying algorithm that drops @zerofeerouting guy outperforms one that does not drop the node, we may need to change the protocol to block the strategy rather than encourage it, with the understanding that any protocol tweak can change the balance of game strategies to make an even worse strategy dominant (a distressingly common issue in video games, which often cannot be caught in playtesting (= testnet or small-scale testing)).
In particular, anecdotes from node operators suggests that forwarding node operators are fine with channeling with @zerofeerouting guy because even if a forward fails, a forwarding node operator does not actually lose any funds --- forwarding nodes are trading off time for earnings and are willing to accept long times before getting any money.
But payers that are unable to succeed their first few (hundred?) payments lose out on time-sensitive payments, and complete failure may cause them to lose their subjective-increase-in-value of the product / service they are purchasing (i.e. "cost of payment failuer").
**IF** @zerofeerouting guy is really such an awful forwarding node (a fact that is **NOT** strongly evidenced yet, but is pointed to by what little anecdotal evidence we do have, and which we might want to investigate at some point), but is still able to get connectivity from forwarding node operators that are fine with high failure rates since forwarders are not time-sensitive to failure the way actual payers are, then @zerofeerouting guy is imposing economic rent on all payers.
An alternate take on this is that if payer-side algorithms can deliberately ignore @zerofeerouting guys (e.g. by the aforementioned technique of filtering out channels whose feerates do not change on the assumption that they are in "private" mode) then any high forwarding failure the @zerofeerouting strategy *does* impose on the network is avoided, but that implies too that no rational merchant will purchase liquidity from users of this strategy, and the strategy will fizzle out eventually once the novelty wears off.
On the other hand, the market can remain irrational longer than you can remain liquid, so...
Fixing The Unclosed Economy Problem
===================================
If Lightning Network were a truly closed economy, since Bitcoin has no inflation, then we should not see something like "this node is always a sink" or "this node is always a source".
As Bitcoin is a currency, pools of liquidity may form temporarily, but then economic actors would want to spend it at some point and then balance should be restored in the long run.
However, it has been pointed out to me, repeatedly (both at the LN Proto Dev Oakland 2022 Summit and from various node operators) that no, there ***ARE*** sinks and sources on the network in practice, and you have to plan your rebalances carefully taking them into account.
To fix this problem, which is somewhat related to Price-of-Anarchy, I want to propose that all published nodes support some kind of onchain/offchain swap capability.
Suppose we have a node, Rene, who likes paying the node Zmn because Zmn is so awesome.
Rene pays Zmn every hour, that is how awesome Zmn is.
Now if Zmn is not otherwise spending its funds, at some point the overall network-level liquidity between Rene and Zmn ***IS*** going to deplete.
This is basically the "sink vs source" problem that has been pointed out above.
So at some point, at some hour, Rene stops being able to pay Zmn and is sad because now it cannot support the awesomeness of Zmn.
Now what I want to propose is that in that case, Rene should now offer an "aggregate onchain" payment.
* Suppose Rene wants to pay 1 sat to Zmn but is unable to find a viable route.
* Rene picks some number of sats to send onchain, plus the payment amount.
Say Rene picks 420 sats to send onchain, plus the 1-sat payment amount that Rene wants to pay in this hour = 421 sats.
* Zmn then routes 420 sats offchain, minus fees, to Rene.
* Once Rene receives the HTLC, it puts the onchain funds into a 421 sat output behind an HTLC as well, onchain, payable to Zmn.
* Zmn releases the proof-of-payment onchain, receiving 421 sats.
* Rene receives the preimage and claims the offchain funds.
* Zmn pays out 420 sats (netting the 1-sat hourly payment).
The nice thing here is that if the above Zmn->Rene reverse route succeeds, then magically Rene now has 420 sats (minus fees) worth of liquidity towards Zmn, and Rene can now do ~420 (minus fees) more 1-sat payments, offchain, every hour, to Zmn.
And if the forwarding nodes between Rene and Zmn are doing the above economically-rational thing of leaking their balances via feerates, then the big 420-sat change in capacity implies a big drop in feerate from Rene to Zmn --- basically Rene is prepaying fees (via the onchain fee mechanism) towards future payments to Zmn!
I think this is a more compelling protocol than splicing --- splicing just affects one channel, it does not affect *all* the channels between Zmn and Rene and does not assure Rene can send to Zmn, unless Rene and Zmn have a direct channel.
This protocol (which requires two onchain transactions, one to set up the HTLC, the other to claim it) may give better efficiency in general than splicing.
If Rene is at least two hops away from Zmn, then the same effect can be done by all the intermediate channels doing splicing --- and that means 1 transaction per splice, i.e. one transaction per channel, so if it is two hops then splicing is no better and if it is three hops or more splicing is worse.
(In particular it bothers me that the peerswap project restricts swaps to peers you have channels with (at least as I understood it); it seems to me splicing is better if you are going to manipulate only one channel.
Peerswap should instead support remote nodes changing your balance, as that updates multiple channels for only two onchain transactions.)
This basically makes Lightning an aggregation layer for (ultimately) onchain payments, which seems like a viable model for scaling anyway --- Lightning really IS an aggregation layer, and what gets published onchain is a summary of coin movements, not all the individual coin movements.
Due to Rene picking a (hopefully?) random number for the reverse-payment, the exact amount that Rene handed to Zmn is still hidden --- onchain surveillors have to guess exactly how much was actually sent, since what Zmn actually receives is the difference between the onchain amount and the offchain amount.
This can probably be implemented right now with odd messages and featurebits, but some upcoming features make it EVEN BETTER:
* If Rene does not want Zmn to learn where Rene is:
* It should use onion messaging so that Zmn does not learn Rene IP address.
* It should use blinded paths so that Zmn does not learn Rene node ID.
* If Rene and Zmn want to reduce correlation between offchain and onchain activity:
* They should use PTLCs and blind each offchain hop *and* blind the onchain *and* use pure Scriptless Script onchain.
Now a point that Rene (the researcher, not the node) has raised is that we should be mindful how protocol proposals, like the above, change the metagame, I mean the Price of Anarchy.
This protocol is intended to reduce the dichotomy/divide between "mostly source" and "mostly sink" nodes, which should help improve payment success to used-to-be-mostly-sink nodes.
Thus, I think this protocol proposal improves the Price of Anarchy.
A note however is that if multiple people are paying to Zmn, then the channel directly towards Zmn may very well have its liquidity "stolen" by other, non-Rene nodes.
This may worsen the effective Price of Anarchy.
Really though, mostly-sink nodes should just run CLBOSS, it will automatically swap out so you always have incoming liquidity, just run CLBOSS.
Appendix
========
I sent a preliminary version of this post to a few node operators as well.
As per devast:
> Sure, but after thinking about the whole network, how payments happen, what's happening with the nodes, i don't think that's the best strategy, if you're just interested in your ernings.
> Let me just describe:
> Rene wants to find cheap AND reliable payments. To be just plain blunt, in the current network conditions, that simply will not happen, period. Reliability has a price (The price of anarchy).
> IF every node would have perfectly balanced total inbound-outbound capacity AND every node would use fee setting as flow control, this could happen, and routing algos just optimizing for fees would work great. Using the network would be really cheap.
> But the reality is, that most nodes have either too much inbould or outbound capacity, AND like half the network is using 1/1 fees static. AND a lot of traffic is NOT bidirectional. AND fee setting of nodes is all over the place.
> At this point if you are a routing node, and you plan on being reliable, you have to overcharge all your routes.
> Due to the state of the network mentioned before, there HAS TO BE routing nodes that are useless and unreliable, there's really no way around that.
> And you also mentioned economic payment routing algos are blacklisting unreliable nodes.
> So in the end: you overprice, that way you can manage liquidity with rebalancing. Your node will be preferred by real payments, that DO pay your fee for routing. You can keep your node reliable, while earning.
> OR: You compete in fees, that way your rebalancing will fail (since you are the cheapest). Your node will be blacklisted as it's unreliable and you only get 5million failed routing events, like i do.
> Where you might compete imo is the price premium you're attaching to your fees compared to the baseline (corrected average). Lowering your price premium might bring more traffic and increase your total earnings IF you can still reliable rebalance, or backward traffic happens. But increasing your price premium might just be more profitable if traffic do not slows... Needs experimenting.
> It's really not rocket science, i might try to modify a feesetter python script to do this on my node. Still i would miss a proper automatic rebalancer, but for a test i could do that by hand too.
> This is what i would like to get others opinion on. In the current state of the network this could work *for me*. But everyone still cannot do this, as suckers must exist.
Personally, I think this basically admits that the "overcharge" strategy will not be dominant in the long run, but it will dominate over a network where most people act irrationally and set feerates all over the place.
More from devast:
> I think calling this a economically rational strategy is a long shot. This just helps route finding algorithms. Minimizes your local failed forwards. Makes you more reliable.
> But this will not make you a *maker*, this cannot assure you have liquidity ready in the directions where there is demand. Sure, if everyone started doing this, the network would be in a much better shape.
>
> The economic logic of "high supply -> low fee, low supply -> high fee" do play in a different way.
> Not in the context of *your* channel, but the context of the peer node.
> a, If a node has 100:10 total inbound:outbound capacity, you won't be able to ask any meaningful fee to them, regardless of your current channel balance. Everyone and their mothers have cheap channels to them already.
> b, If a node has 10:100 total inbound:outbound capacity, You will be able to charge a LOT in fees to them, again regardless of your current channel balance.
> c, If a node has 100:100 total inbound:outbound capacity, then just the fee from balance could work. But this type of node is the exception, not the norm.
> Then you might ask, why am i saying you should overprice everyting to some degree ?
> Well in the above screnario your channel to b, has obvious economic value. What about a, ?
> Your outbound capacity to a, has no value. However, inbound capacity from a, has economic value. Since it's scarce.
> And the only way you can capitalize on a, is to charge good fees on any traffic entering from a, hence asking a premium on all your channels.
As per another node operator:
> Really good points here, finally had time to carefully read. I like the described fee-based balance leaking idea and I think that is what currently is the accepted norm among many routing node operators - different ranges of fees, I adjust in a range of 100-1000 depending on channel balance, and what I wanted clboss to do for me was to adjust *faster* than I can do - preferably immediately when some previously idle channel wakes up and starts sucking up all liquidity at minimal rate.
>
> Huge exceptions to this are default 1-1 nodes (they are almost always very bad peers with no flow), ZFR (good bi-directional flow in my experience), and static fee nodes (The Wall with 1000-1400 static fee range and yalls and others). Static fee node ops use proceeds from huge fees to rebalance their channels, so it is a viable approach to a healthy node as well. Maybe clboss fee adjuster could operate within the provided range, extreme case being a static fee, so operator can define the desired strategy and let the market win?
>
> Also one thing to consider for the proposal is factoring in historical data.
>
> Example:
>
> I have two 10m channels, both with 90% balance on my side. Channel A has routed ~20m both ways, Channel B has routed 1m one way. If X is my 50-50 channel fee then I would set B's fees to 5X and A's fees to 2X. To me it is one of the three most important factors when determining fees -
> 1. current channel balance;
> 2. is the channel pushing liquidity back, what %, how recently;
> 3. how healthy (response time, uptime, channel stats etc) is the host
>
> Number three does factor less in the fees and more in the decision to close the channel if there had been no movement for 30 days.