Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-28 📝 Original message: On Tue, Sep 27, 2022 at ...
📅 Original date posted:2022-09-28
📝 Original message:
On Tue, Sep 27, 2022 at 12:23:38AM +0000, ZmnSCPxj via Lightning-dev wrote:
> All monetisation is fee-based; the question is who pays the fees.
This isn't true. For example, if you can successfully track the payments
you route, you can monetize by selling data about who's buying what
from whom. (Unless you meant it in some trivial sense, I guess, like
"all monetisation is money-based; the question is who pays the money")
> In particular, discussing with actual forwarding node operators reveals
> that most of them think that CLBOSS undercuts fees too much searching
> a short-term profit, quickly depleting its usable liquidity in the
> long term.
> In short, they want CLBOSS modified to raise fees and preserve the
> liquidity supply.
> This suggests to me that channel saturation due to being cheaper by
> 0.0001% is not something that will occur often,
That seems a bit of a backwards conclusion: "undercutting fees depletes
liquidity" therefore "channel saturation due to offering cheaper fees
seems unlikely" -- channel saturation *is* depleted liquidity...
On Wed, Sep 28, 2022 at 02:07:51AM +0000, ZmnSCPxj via Lightning-dev wrote:
> Forwarding nodes sell liquidity.
> If a forwarding node runs out of stock of liquidity (i.e. their channel is unbalanced against the direction a payment request fails) they earn 0 profit.
I get what you're saying, but I don't think a "stock of liquidity"
is a helpful metaphor/mental model here.
"Liquidity" usually means "how easy it is to exchange X for Y" -- assets
for cash, etc; but for lightning, liquidity is guaranteed by being
able to drop to chain. Likewise, "running out of stock" isn't usually
something that gets automatically fixed by someone else coming in and
buying something different.
(Also, you don't earn 0 profit on an imbalanced channel; you're just
forced to stop accepting some txs. Every time you forward $1 in the
available direction, you become able to forward another $1 back in the
saturated direction; and you earn fees on both those $1s)
I think it's better to think in terms of "payment flow" -- are you
forwarding $5/hour in one direction, but $10/hour in the other? Is
that an ongoing imbalance, or something that evens itself out over time
($120/day in both directions)?
Once you start in that direction, there's also a few other questions
you can ask:
* can I get make more revenue by getting more payment flow at a
lower fee, or by charging a higher fee over less payment flow?
* if I had a higher capacity channel, would that let me tolerate
a temporarily imbalanced flow over a longer period, allowing me
to forward more payments and make more fee revenue?
If you want to have a long running lightning channel, your payment flows
will *always* be balanced. That might be through luck, it might be through
clever management of channel parameters, but if it's not through those,
it'll be because your channel's saturated, and you're forced to fail
payments.
Ultimately, over the *entire* lifetime of a lightning channel, the only
imbalance you can have is to either lose the funds that you've put in,
or gain the funds your channel partner put in.
That *is* something you could sensibly model as a stock that gets depleted
over time, if your payment flows are reliably unbalanced in a particular
direction. For example, consider a channel that starts off with $100k in
funds and has a $5k imbalance every day: after 20 days, you'll have to
choose between failing that $5k imbalance (though you could still route
the remaining balanced flows), or between rebalancing your channels,
possibly via on-chain transactions. Does the fee income from an additional
$100k of imbalanced transactions justify the cost of rebalancing?
You can calculate that simply enough: if the on-chain/rebalance cost is
$300, then if you were getting a fee rate of more than 0.3% ($300/$100k),
then it's worth paying for the rebalance.
But if "lifetime drain" is the dominant factor, you're reducing
lightning to the same performance as one-way payment channels: you move
the aggregate payments up to the channel capacity, and then close the
channel. If you get balanced payment flows, that allows you to cancel
out 30,000 $1 transactions against 1,000 $30 transactions, and maintain
the channel indefinitely, with all the off-chain scaling that implies.
> If a forwarding node finds a liquidity being sold at a lower price than they would be able to sell it, they will buy out the cheaper stock and then resell it at a higher price.
> This is called rebalancing.
All that does is move the flow imbalance to someone else's channel;
it doesn't improve the state of the network.
There definitely are times when that makes sense:
* maybe the channel's run by "dumb money" that will eat the fee for
closing on-chain, so you don't have to
* maybe you have secret information about the other channel, allowing
you to route through it for cheaper than the general public
* maybe you and they have different demand at different times of the
day, so time-shifting imbalances is mutually beneficial? I don't
see how this works out without secret information though -- the
people who want to route payments should be choosing the cheapest
link at all times of the day already
But those don't generally seem aligned with the long-term health of the
lightning network?
> * Thus, channels advertising low fees are likely to have their liquidity bought out by patient forwarding nodes.
I think the "liquidity" metaphor isn't doing you any favours here.
Here's what (I think) that scenario looks like under "flow":
- overall, there's unbalanced flow: for example, people want to pay a
higher amount from A to B than from B to A.
- X charges low fees to forward from A to B, so their channel is always
depleted in that direction.
- Y charges high fees to forward from A to B
- Y takes advantage of being constantly online to always be the first
to route their rebalance through X (Y->A->X->B->Y) when X's channel
clears up
Y's rebalancing then is limited by the legitimate payment volume going
back through X (ie B->X->A). Because there's an unbalanced flow overall,
that means Y cannot rebalance to compensate for the total amount of
payments it routes, and eventually both X and Y will become depleted in
the same direction, and one or both channels will have to decide whether
to rebalance on-chain. If X rebalances on-chain, allowing Y to repeatedly
take advantage of their low fees, that's the "dumb money" situation.
> If you introduce an artificial impediment and say "I will only accept
> payment sizes below N millisats", and then go "I will #zerofeerouting
> guy", then a forwarding node will just split their rebalance into quanta
> of N millisats and make a spike in the payment size distribution and
> drain your channel anyway, so that they can turn around and resell the
> liquidity at a higher price later.
Of course, it's possible that overall flows *are* balanced, and you're
just able to take advantage of your better understanding of lightning
routing to charge higher fees than this "X" character.
But the same scenario applies in the max_msat world too, with only
slight modifications.
* instead of constantly probing the A->X->B channel so that you keep it
drained, you create fake traffic over A->X->B causing X to detect an
imbalance and lower their max_msat in order to get the flows
balanced.
* this causes users to send more traffic through A->Y->B, giving you
more fee income
* you can then repeatedly generate more fake traffic over A->X->B,
causing X to lower max_msat further, perhaps giving you most of the
A->B traffic
* meanwhile you do regular rebalances (Y->A->X->B->Y) at values less
X's than max_msat
* your node sees perhaps 90% of A->B payment flows, and does the same
volume in rebalancing
* X's node sees 10% of legit A->B payment flows, and your 90% of legit
payment flows via your rebalancing; and also 100% of legit B->A
payment flows
* so both nodes remain balanced, reducing payment failures; and Y can
rebalance constantly, allowing them to operate with a smaller
capacity channel making it more capital efficient
I think there's a few limitations on that "attack":
* it only works if you're willing to forego legitimate fee income
from B->Y->A -- but if you're competing with someone who charges
zero fees anyway, maybe that's fine
* it only works if A->X->B is charging much lower fees so your
rebalancing really is cheap
* you probably need to reserve capital in order to create the fake
payment flows -- afterall, if you try to rebalance the capital you
used to create the fake payment flow, that creates a payment flow
in the other direction, which risks undoing your work
* that A->X->B is overloaded (max_msat is lowish) that's a public
indication that there's high demand at X's fee rate along that path,
which may encourage people to create additional channels. creating
fake payment flow for all of those channels may become prohibitively
capital intensive.
> i.e. #zerofeerouting will never be a reliable forwarding node, because all the other forwarding nodes will be taking their liquidity for cheap long before you think to make a payment through them.
I don't think it's ideal if a world that includes both:
* altruists, who'll forward your payments for cheap/free
* profiteers, who are trying to make a living offering lightning
services
results in "oops, optimising for low lightning fees becomes horribly
unreliable".
[repeating this one, to followup in a different way]
> If you introduce an artificial impediment and say "I will only accept
> payment sizes below N millisats", and then go "I will #zerofeerouting
> guy", then a forwarding node will just split their rebalance into quanta
> of N millisats
I mean, that's already a fundamental problem with max_msat: why wouldn't
payment initiators do exactly that in the first place?
Making this incentive compatible with AMP payments does seem like a
challenge. Why pay higher fees routing through some other channel,
instead of just AMPing as many max_msat payments as you need through
the cheapest channel? (Hmm, I guess I didn't express that concern as
clearly as I thought I did; at least outside of any deleted drafts...)
I wonder whether a (per source/dest channel?) token bucket rate limit
might suffice, though. Hmm, it maybe would so long as you're optimising
for small/frequent payments to be reliable, and aren't worried so much
about large/infrequent ones, which *might* be reasonable... That way
you start rejecting payment flow *before* your channel's depleted if it
becomes unusually bursty in one direction, despite you having indicated
you want senders to throttle. And then the early rejections mean there's
not so much value AMPing lots of max_msat payments through a single
cheap channel.
I suppose in a *completely* ideal world, I might imagine something like
this:
* $100,000 a day travels from A to B; $90,000 a day travels from B to A
* all the A->B payments are $5 each
* onchain fees for rebalancing a channel is $200
* X and Y run routing nodes and want to make stuff cheap, so charge
0.001% (10-parts-per-million)
* Z is happy to rebalance on chain, has $50,000 committed in his
channel, so charges fees of $200/$50,000 = 0.4% (or, probably, more)
In order to get balanced flows, X and Y set their max_msat in the A to B
direction to $2.25, meaning:
* 20k $5 payments from A to B gets split into $2.25 through X, $2.25
through Y, and $0.50 through Z
* 90 $1000 payment from B to A get split into $500 through X and $500
through Y.
Every day:
* X and Y see $45000 going each way, collecting $0.90 in routing fees
per day, and having their channel not go out of balance
* Z sees $10,000 going from A to B, collecting $40 a day
* Z's channel runs out after 5 days, at which point he's collected $200
total, and has to spend $200 rebalancing on-chain
* each person paying $5 to B pays $0.002045 in fees; each person
paying $1000 to A pays $0.01 in fees
Z could reduce his fee rate below 0.4% and still break even if he
increased his channel capacity above $50k. He can't make his channel last
longer by getting more B->A channel flow though, because that would just
lead X and Y's flows to be unbalanced, causing payers to have to route
more flow through Z.
Cheers,
aj
📝 Original message:
On Tue, Sep 27, 2022 at 12:23:38AM +0000, ZmnSCPxj via Lightning-dev wrote:
> All monetisation is fee-based; the question is who pays the fees.
This isn't true. For example, if you can successfully track the payments
you route, you can monetize by selling data about who's buying what
from whom. (Unless you meant it in some trivial sense, I guess, like
"all monetisation is money-based; the question is who pays the money")
> In particular, discussing with actual forwarding node operators reveals
> that most of them think that CLBOSS undercuts fees too much searching
> a short-term profit, quickly depleting its usable liquidity in the
> long term.
> In short, they want CLBOSS modified to raise fees and preserve the
> liquidity supply.
> This suggests to me that channel saturation due to being cheaper by
> 0.0001% is not something that will occur often,
That seems a bit of a backwards conclusion: "undercutting fees depletes
liquidity" therefore "channel saturation due to offering cheaper fees
seems unlikely" -- channel saturation *is* depleted liquidity...
On Wed, Sep 28, 2022 at 02:07:51AM +0000, ZmnSCPxj via Lightning-dev wrote:
> Forwarding nodes sell liquidity.
> If a forwarding node runs out of stock of liquidity (i.e. their channel is unbalanced against the direction a payment request fails) they earn 0 profit.
I get what you're saying, but I don't think a "stock of liquidity"
is a helpful metaphor/mental model here.
"Liquidity" usually means "how easy it is to exchange X for Y" -- assets
for cash, etc; but for lightning, liquidity is guaranteed by being
able to drop to chain. Likewise, "running out of stock" isn't usually
something that gets automatically fixed by someone else coming in and
buying something different.
(Also, you don't earn 0 profit on an imbalanced channel; you're just
forced to stop accepting some txs. Every time you forward $1 in the
available direction, you become able to forward another $1 back in the
saturated direction; and you earn fees on both those $1s)
I think it's better to think in terms of "payment flow" -- are you
forwarding $5/hour in one direction, but $10/hour in the other? Is
that an ongoing imbalance, or something that evens itself out over time
($120/day in both directions)?
Once you start in that direction, there's also a few other questions
you can ask:
* can I get make more revenue by getting more payment flow at a
lower fee, or by charging a higher fee over less payment flow?
* if I had a higher capacity channel, would that let me tolerate
a temporarily imbalanced flow over a longer period, allowing me
to forward more payments and make more fee revenue?
If you want to have a long running lightning channel, your payment flows
will *always* be balanced. That might be through luck, it might be through
clever management of channel parameters, but if it's not through those,
it'll be because your channel's saturated, and you're forced to fail
payments.
Ultimately, over the *entire* lifetime of a lightning channel, the only
imbalance you can have is to either lose the funds that you've put in,
or gain the funds your channel partner put in.
That *is* something you could sensibly model as a stock that gets depleted
over time, if your payment flows are reliably unbalanced in a particular
direction. For example, consider a channel that starts off with $100k in
funds and has a $5k imbalance every day: after 20 days, you'll have to
choose between failing that $5k imbalance (though you could still route
the remaining balanced flows), or between rebalancing your channels,
possibly via on-chain transactions. Does the fee income from an additional
$100k of imbalanced transactions justify the cost of rebalancing?
You can calculate that simply enough: if the on-chain/rebalance cost is
$300, then if you were getting a fee rate of more than 0.3% ($300/$100k),
then it's worth paying for the rebalance.
But if "lifetime drain" is the dominant factor, you're reducing
lightning to the same performance as one-way payment channels: you move
the aggregate payments up to the channel capacity, and then close the
channel. If you get balanced payment flows, that allows you to cancel
out 30,000 $1 transactions against 1,000 $30 transactions, and maintain
the channel indefinitely, with all the off-chain scaling that implies.
> If a forwarding node finds a liquidity being sold at a lower price than they would be able to sell it, they will buy out the cheaper stock and then resell it at a higher price.
> This is called rebalancing.
All that does is move the flow imbalance to someone else's channel;
it doesn't improve the state of the network.
There definitely are times when that makes sense:
* maybe the channel's run by "dumb money" that will eat the fee for
closing on-chain, so you don't have to
* maybe you have secret information about the other channel, allowing
you to route through it for cheaper than the general public
* maybe you and they have different demand at different times of the
day, so time-shifting imbalances is mutually beneficial? I don't
see how this works out without secret information though -- the
people who want to route payments should be choosing the cheapest
link at all times of the day already
But those don't generally seem aligned with the long-term health of the
lightning network?
> * Thus, channels advertising low fees are likely to have their liquidity bought out by patient forwarding nodes.
I think the "liquidity" metaphor isn't doing you any favours here.
Here's what (I think) that scenario looks like under "flow":
- overall, there's unbalanced flow: for example, people want to pay a
higher amount from A to B than from B to A.
- X charges low fees to forward from A to B, so their channel is always
depleted in that direction.
- Y charges high fees to forward from A to B
- Y takes advantage of being constantly online to always be the first
to route their rebalance through X (Y->A->X->B->Y) when X's channel
clears up
Y's rebalancing then is limited by the legitimate payment volume going
back through X (ie B->X->A). Because there's an unbalanced flow overall,
that means Y cannot rebalance to compensate for the total amount of
payments it routes, and eventually both X and Y will become depleted in
the same direction, and one or both channels will have to decide whether
to rebalance on-chain. If X rebalances on-chain, allowing Y to repeatedly
take advantage of their low fees, that's the "dumb money" situation.
> If you introduce an artificial impediment and say "I will only accept
> payment sizes below N millisats", and then go "I will #zerofeerouting
> guy", then a forwarding node will just split their rebalance into quanta
> of N millisats and make a spike in the payment size distribution and
> drain your channel anyway, so that they can turn around and resell the
> liquidity at a higher price later.
Of course, it's possible that overall flows *are* balanced, and you're
just able to take advantage of your better understanding of lightning
routing to charge higher fees than this "X" character.
But the same scenario applies in the max_msat world too, with only
slight modifications.
* instead of constantly probing the A->X->B channel so that you keep it
drained, you create fake traffic over A->X->B causing X to detect an
imbalance and lower their max_msat in order to get the flows
balanced.
* this causes users to send more traffic through A->Y->B, giving you
more fee income
* you can then repeatedly generate more fake traffic over A->X->B,
causing X to lower max_msat further, perhaps giving you most of the
A->B traffic
* meanwhile you do regular rebalances (Y->A->X->B->Y) at values less
X's than max_msat
* your node sees perhaps 90% of A->B payment flows, and does the same
volume in rebalancing
* X's node sees 10% of legit A->B payment flows, and your 90% of legit
payment flows via your rebalancing; and also 100% of legit B->A
payment flows
* so both nodes remain balanced, reducing payment failures; and Y can
rebalance constantly, allowing them to operate with a smaller
capacity channel making it more capital efficient
I think there's a few limitations on that "attack":
* it only works if you're willing to forego legitimate fee income
from B->Y->A -- but if you're competing with someone who charges
zero fees anyway, maybe that's fine
* it only works if A->X->B is charging much lower fees so your
rebalancing really is cheap
* you probably need to reserve capital in order to create the fake
payment flows -- afterall, if you try to rebalance the capital you
used to create the fake payment flow, that creates a payment flow
in the other direction, which risks undoing your work
* that A->X->B is overloaded (max_msat is lowish) that's a public
indication that there's high demand at X's fee rate along that path,
which may encourage people to create additional channels. creating
fake payment flow for all of those channels may become prohibitively
capital intensive.
> i.e. #zerofeerouting will never be a reliable forwarding node, because all the other forwarding nodes will be taking their liquidity for cheap long before you think to make a payment through them.
I don't think it's ideal if a world that includes both:
* altruists, who'll forward your payments for cheap/free
* profiteers, who are trying to make a living offering lightning
services
results in "oops, optimising for low lightning fees becomes horribly
unreliable".
[repeating this one, to followup in a different way]
> If you introduce an artificial impediment and say "I will only accept
> payment sizes below N millisats", and then go "I will #zerofeerouting
> guy", then a forwarding node will just split their rebalance into quanta
> of N millisats
I mean, that's already a fundamental problem with max_msat: why wouldn't
payment initiators do exactly that in the first place?
Making this incentive compatible with AMP payments does seem like a
challenge. Why pay higher fees routing through some other channel,
instead of just AMPing as many max_msat payments as you need through
the cheapest channel? (Hmm, I guess I didn't express that concern as
clearly as I thought I did; at least outside of any deleted drafts...)
I wonder whether a (per source/dest channel?) token bucket rate limit
might suffice, though. Hmm, it maybe would so long as you're optimising
for small/frequent payments to be reliable, and aren't worried so much
about large/infrequent ones, which *might* be reasonable... That way
you start rejecting payment flow *before* your channel's depleted if it
becomes unusually bursty in one direction, despite you having indicated
you want senders to throttle. And then the early rejections mean there's
not so much value AMPing lots of max_msat payments through a single
cheap channel.
I suppose in a *completely* ideal world, I might imagine something like
this:
* $100,000 a day travels from A to B; $90,000 a day travels from B to A
* all the A->B payments are $5 each
* onchain fees for rebalancing a channel is $200
* X and Y run routing nodes and want to make stuff cheap, so charge
0.001% (10-parts-per-million)
* Z is happy to rebalance on chain, has $50,000 committed in his
channel, so charges fees of $200/$50,000 = 0.4% (or, probably, more)
In order to get balanced flows, X and Y set their max_msat in the A to B
direction to $2.25, meaning:
* 20k $5 payments from A to B gets split into $2.25 through X, $2.25
through Y, and $0.50 through Z
* 90 $1000 payment from B to A get split into $500 through X and $500
through Y.
Every day:
* X and Y see $45000 going each way, collecting $0.90 in routing fees
per day, and having their channel not go out of balance
* Z sees $10,000 going from A to B, collecting $40 a day
* Z's channel runs out after 5 days, at which point he's collected $200
total, and has to spend $200 rebalancing on-chain
* each person paying $5 to B pays $0.002045 in fees; each person
paying $1000 to A pays $0.01 in fees
Z could reduce his fee rate below 0.4% and still break even if he
increased his channel capacity above $50k. He can't make his channel last
longer by getting more B->A channel flow though, because that would just
lead X and Y's flows to be unbalanced, causing payers to have to route
more flow through Z.
Cheers,
aj