[Article Review] A Mathematical Theory of Payment Channel Networks
This is a review of Rene Pickhardt's unpublished manuscript titled A Mathematical Theory of Payment Channel Networks. Rene did a presentation of this work at bitcoin++ Berlin last October. I watched the original talk and it made me want to read the paper. Now I've finally had a chance to read it.
Someone give this man a PhDSomeone give this man a PhD
The first thing that stood out to me was the footnote on the title.
Due to personal circumstances related to my mental health I have not been able to receive a PhD--despite being a researcher since 2011. If you can give someone a PhD and think this work and my prior work about reliability in payment channel networks since 2018 reaches the merits of a PhD, then please feel free to get in contact with me. Thank you!
This hits me in the feels, because I know how difficult it can be to go through a PhD program. I've seen it affect the mental health of a few friends. Most were able to work past it, but some were not. I hadn't read any of Rene Pickhardt's work till now, but I hope to familiarize myself with it as I dive more into Bitcoin research. I hope he is able to earn his PhD one day. Unfortunately, my department does not have a PhD program so I'm not in a position to grant one (and it'd be in Economics anyway which I doubt is what he's looking for).
K so what's this aboutK so what's this about
The paper is about feasible liquidity states in the Lightning Network. Given a network topology (a fancy way to say the nodes and how they're connected and with what capacities), what are the possible wealth distributions on Lightning vs. on the main chain?
Since the main chain has no capacity limitations, all wealth distributions are possible as long as all the coins add up. So, let's imagine a toy universe with only 3 people (Alice, Bob, Carol) and 21 bitcoins. Any possible allocation of Bitcoin among the three people is possible as long as the total coins add up to 21.
What about on the Lightning Network? The answer is that it depends on the topology. If the network looks like this:
then the Lightning Network cannot support any allocation of bitcoin where Bob has more than two bitcoin. The limitation is due to the channel capacity going to Bob.
What implication does this have? This means that any payment which would result in Bob having more than two bitcoins would automatically fail. And that's one of the central insights of the paper, which is that a payment is simply a change in the wealth distribution. We can thus investigate the reliability of Lightning payments by studying the set of the feasible vs. infeasible wealth distributions. If a payment would result in an infeasible wealth distribution, then either that payment would have to be done on-chain, or the network topology would have to reconfigured to make that wealth state possible.
The above example may be a bit simplistic, so let's take a look at this network topology:
Quiz: Would A ever be able to send two bitcoins to D?
The answer is no. You probably could tell by looking at the channel from B to C and realizing it is too small.
But there's another way of looking at it, which is that any wealth distribution that results in a bitcoin imbalance of more than one coin between the left and the right sides of the network will be infeasible. In addition, no individual node would ever be able to have more than 11 coins (and if some nodes have 10 or 11 coins, that limits the possible wealth of their adjacent nodes).
The above discussion highlights the main contribution of the paper. It offers mathematical theorems and algorithmic tools for generalizing the set of infeasible payments based on any existing network topology. One of the main conclusions is that for any network with more than three nodes, there is always a wealth distribution which is infeasible. In other words, the Lightning Network always supports strictly fewer feasible wealth distributions than the main chain.
The paper then goes on to show that multi-party channels increases the set of feasible wealth distributions. Intuitively, this is not too hard to understand. Easiest way is to imagine everyone being part of the same multi-party channel; in that case, any wealth distribution is feasible. Going smaller, it's easy to see that within any multi-party channel, any sub-distribution of wealth inside that channel is feasible. Thus, having multi-party channel reduces some of the capacity constraints which limit feasible wealth distributions when only 2-party channels are allowed.
My commentsMy comments
This was definitely an interesting paper. I didn't fully grok all the math--(you'll have to pay me a lot more if you want me to do that)--but I think I absorbed enough to understand the intuition. At least for the main, big picture points.
The main conclusion seems to be that Lightning developers should work on implementing multi-party channels. Sounds good, but the paper doesn't really dive too much into the details of implementing that, so I don't know how technically difficult this is or what the trust tradeoffs are. This isn't necessarily a criticism of the paper, since the paper is about theory not implementation details; but it's a practical issue that I'm curious to hear developers' opinions on.
Finally, of course, as an economist, I have to nitpick one issue: which is that the paper ignores the endogeneity of the network topology. That is, the network topology isn't some fixed thing handed down to us by God (or by the devs, for that matter). Rather, the network topology is derived from the incentives of network participants. If certain popular payments are repeatedly failing, we can expect enterprising node runners to open channels to solve that payment failure. Thus, I'd be curious if Rene could extend his model to account for endogeneous network formation. When node runners are incentivized by fee potential to open channels that solve the most common payment failures, the network may turn out to be more robust than a fixed theory of network topology would suggest.
Anyway, there's a bunch of other stuff in the paper that I didn't talk about, including results on channel depletion, fee setting strategies, and circular rebalancing. I'm not an expert on this literature, but as a toolkit for mathematically modeling the Lightning Network, the paper seems like a nice contribution. I'm looking forward to engaging with this literature more (if and when I have time, but I am motivated). I think the paper is worth a read for anyone interested in the mathematical theory of payment networks, but probably too dense for the average layperson.
I’ll have to noodle on this more, but there might be some interesting things to build off in the context of a fully bifurcated network, say as a result of KYC or other regulatory splits.
If there were two lightning networks with no connection between them, then there might be significant price differences in each, which would create profit opportunities for a bridge.
I was personally triggered not so much in terms of KYC-gating (or any other gating) but more in terms of that we could (probably? haven't researched it deeply) identify emerging subnets / edges in the graph by looking not so much at a snapshot of the graph (i.e.
lnrouter.apptakes a monthly snapshot) but rather by the stream of opened and closed channels over time?I do think endogenizing the channels is the obvious next step for this theory.
Very good review! I was going to read the paper, but I kept waiting because I was hoping you'd do a write up and make my reading much less painful...and you delivered!
I wonder how he handled the case of multipath payments. For instance, in the case of the two "rings" of nodes connected by a single 1btc channel, as long as the total capacity for each ring never gets more than 1btc different from the other ring, wouldn't it still be possible for A to send D 2btc? They just need to split the payment in half and wait for some other payment to rebalance the "bridge" channel.
The theory can handle multi-path payments, but not the kind of multi-step thing you propose.
(It should be noted that your proposed method for getting 2 btc from A to D requires a change in the wealth states of other nodes. Still no direct payment of 2 btc from A to D that leaves the wealth of other nodes unchanged is possible)
Thanks for taking the time to review the paper. You did a good job of explaining how lightning channels work as well as pointing out one trade-off it has.
Lightning is like everything. It's not perfect and neither is the base chain. There are always tradeoffs. I dont think Lightning will necessarily be the solution for the small payments challenges of the base chain but it does work today.
I do tire of the extremes of both Lightning haters and ignorant fans of Lightning that have never ran a node. Honestly like in most topics we end up getting in the weeds and with people that mischaracterize the topic by oversimplification.
Every time you make a change to something there is a tradeoff. When we gloss over those three discussions cease to be productive and start to be ego driven.
Fantastic! Thanks very much for trying to keep this as simple as possible.
When I was trying to get my head around LN I found visuals the most helpful way of understanding how it all worked.
There are a few videos that do this. Forget who made them though.
Great review. Are things like Ark an answer? ChatGPT told me that some one or some combination of channel factories, coinpools, Ark, and eltoo could help address these issues what do you think?
He does touch on Ark as one of the proposed multiparty implementations, but doesn't dive into the details much. I don't know much about how Ark works, personally.
We need more shit like this in stacker news. Well done.
What I really appreciate about Rene’s work is that it pushes Lightning Network discussion into a more rigorous mathematical space. Too often, conversations get trapped in either anecdotal experience or surface-level technical chatter without probing the structural limitations in detail. By framing payments as shifts in wealth distribution across a constrained topology, Rene is essentially giving us a mental model for why certain payments fail before they even have a chance to propagate. That is a more fundamental insight than simply observing failed transactions in the wild.
The point about multi-party channels is particularly important. If you care about Lightning reliability you cannot just tune fees or routing algorithms in isolation. You have to reconsider the architecture itself. Multi-party channels are not just a scaling trick; they alter the feasible state space of the network and that directly changes the economic behavior of participants.
That said, the critique about endogeneity of topology is spot on. In the real world channels do not exist in a vacuum. Operators will strategically open and close them in response to routing opportunities and this dynamic element needs to be incorporated into modeling if the ultimate goal is predicting reliability. In economics we often deal with systems where network formation is itself part of the equilibrium and Lightning is no different. If Rene’s framework could be expanded to include adaptive topology, it would bridge the gap between theoretical feasibility and the evolving reality of Lightning.
Please don't let this be an LLM. Please don't let this be an LLM. It's the only comment here that is worth responding to.
Absolutely agree.
Agree again. But I would go further and say multi-party channels are the only effective mitigation he offers in the paper. The other two (batch settlement and taming depletion) do not solve the bottleneck problem. Section 5.2 proves that for sparse two-party networks, the expected cut size scales with the average channel capacity. So if you want to increase network throughput without changing the protocol, increase the average channel size. While this is mathematically true, it is operationally useless.
From the paper:
"Given the current incentives in the network, depletion is an emergent phenomenon even in a circular economy when all payments are net-zero. The existence of infeasible payments and depletion are consequences of the geometry of cuts and cycles under the given current protocol design. They are neither software bugs nor necessarily the consequence of poor node operator behavior."
Translation: Economically rational operator behavior will not fix depletion nor infeasible payments. See also
Aside: I would consider it a software bug. Surely LL intended to design a scalable offchain protocol.
From the paper: "every infeasible payment needs at least one on-chain transaction to change the topology of the network"
Your line of reasoning sidesteps the real issue that topology changes are a response to infeasible payments i.e. not a solution. When payments are infeasible, the network is forced to adapt its topology. This behavior can be framed as self-repair, but it can just as accurately be described as damage caused by misaligned incentives. Wouldn't the more meaningful goal be to reduce the rate of infeasible payments?
Really interesting read the feasible vs infeasible wealth idea makes Lightning much clearer, and multi party channels seem like a no brainer. Rene deserves that PhD.
Yes, he obviously deserves a PhD
Solid work and clearly important. It makes Lightning’s limits feel concrete instead of hand wavy, and the wealth distribution framing really clicks but the real test is how incentives and topology adapt in the wild, not in a fixed model.
Waiting for the snide spineless @anon comment to come in.
Thanks for the push, @kepford. I almost didn't say anything.
This is the worst review I've ever read. Incomplete, shallow, and full of their unsolicited, unsubstantiated, opinions.
Maybe leave the reviewing to someone else then. How are you going to review a paper you don't fully 'grok'?
I wouldn't be so snide if you wouldn't be so retarded.