Good morning aj, > > 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.
Semantics. You got what I am saying anyway. So let me invent a completely new term derived from my local `/dev/random`, "IPpvHg". When your channel is imbalanced against a particular direction, you cannot forward against the balance. In that case, we say "you have insufficient stock of IPpvHg". A forwarding node is in the business of selling IPpvHg. If a forwarding node sets the price of its IPpvHg too low, another forwarding node, one which is more patient, can buy out its stock of IPpvHg to add to its own stock of IPpvHg. A patient and rich forwarding node can buy out the IPpvHg stock of many cheaper nodes, and that I think is what we are mostly seeing in the network. > (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) But that is based on the existence of a stock of IPpvHg in another channel. Actual forwarding node operators classify their peers as "mostly a source" and "mostly a drain" and "mostly balanced", they want CLBOSS to classify peers similarly. Their stock of IPpvHg is getting depleted from "mostly a drain" peers, and the stock of IPpvHg they get from "mostly a source" peers, which they get in compensation, is less valuable. Which is the whole point: there is a price to IPpvHg, and that should be reflected in the feerates your forwarding node should publish. > 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)? It is helpful to notice that the channel balance is the integral of the sum of payment flows in both directions. This is why actual forwarding node operators are obsessed with channel balance. They already *are* thinking in terms of payment flow, and using an analytical technique to keep track of it: the channel balance itself. > > 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? As I pointed out, if you sell your stock of IPpvHg at too low a price point, other forwarding nodes will snatch up the cheap IPpvHg, buying out that stock. They can then form an effective cartel, selling the stock of IPpvHg at a higher price later. > * 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. I agree. "something you can sensibly model as a stock that gets depleted over time" is, in fact, the channel balance that forwarding node operators are so obsessed with. This all implies to me that the main problem might not be *local* imbalances, but *global* ones. * There are net receivers who just keep their funds in Lightning. Long ago I proposed that we add to the base protocol a mandatory global functionality to support onchain-to-offchain swaps. * A node whose channels have depleted contacts one of the payees it often pays to. * The first node constructs an onchain HTLC offer to the second node. * The second node routes back a payment over the Lightning Network to the first node. * The first node releases the payment preimage over Lightning. * The second node claims the onchain HTLC via the payment preimage. I proposed that as an alternative to splicing. Splicing involves (with current technology) one transaction (spending a 2-of-2 and creating another P2WSH) but only changes the state of a single local channel. Onchain-to-offchain swaps require two transactions, but can change the state of many channels. The onchain-to-offchain swap direction also follows "initiator pays", since it is the initiator who takes on the risk of performing an onchain action and will pay fees in case the swap protocol does not run to completion. The existence of such a protocol would force any net receivers to move their funds from Lightning to onchain, and thus make available any global IPpvHg stocks towards them. > > 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 Channel balance is private information. If you know you have a low balance on your side of a channel, that implies that you have the (private) information that forwards to it are in high demand. Thus you can rationally buy any cheaply-offered IPpvHg towards the same node and resell it later at a higher price. > * 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 Channel balance *is* the private information you are looking for here: it is the integral of the sum of payment flows. Knowing this integral at any time implies knowledge of the recent time-based payment flow. Sure, a remote node through which you rebalance might not share this information to you, but half-knowing is one-fourth of the battle or else either math does not work or I should never have listened to G.I. Joe. > But those don't generally seem aligned with the long-term health of the > lightning network? If there is no incentive to run a forwarding node, then the Lightning Network cannot exist, and its long-term health would be moot. This is similar to mining nodes on the base blockchain. > > * 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. Yes, but again: the integral of payment flows is the channel balance, and you can replace every reference to "flow" here with "channel balance". > > 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. But the same thing can be done in a world where fees are the valve, and you work directly with supply and demand instead of at one-layer-removed like `htlc_max_msat` does, which may hide more attacks: complexity is where exploits lurk. > > 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". In the world outside of Lightning, we usually make the stink eye at any profiteers who exploit altruists and make noises about how such profiteers are evil, and occasionally even punish them a little bit. Until you can import such a mechanism into Lightning --- which would, I think, require that forwarding nodes provide their identity, and for payments to have proof-of-identity from both sender and receiver --- then that is the result that will indeed occur. > [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? Indeed, which suggests that the use of `htlc_max_msat` for a flow valve is flawed: it requires continuous payment flow / payment size curve, and the payment size can be manipulated trivially by any third parties. What would limit this would be a decently high and definitely non-zero `base_fee`, but that is a fee-based valve already, which is what I have been pointing out is the simply best option we have. > > 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. Given that a published channel is a global resource, any rate limit is going to be shared amongst many users, and if you underquote the value of the IPpvHg you are providing, rebalancers are going to grab as much of the rate limit as they can. > 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. I think this implies we need to have a mechanism to move funds outside of the Lightning network, i.e. every published node should have onchain/offchain swap capability. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
