A simpler (less sophisticated but much easier) Lightning Network by 3-party novation

If you can’t point to this described historically, this is an important discovery. It isn’t “LN but more hub-and-spoke”. LN is by definition Ryan Fugger’s Ripple + “collateral”. Ryan never included novation at all. He did consider Evgeni Pandurski’s idea of loop clearing but that quickly gets roughly as complex as multihop. Both Ryan, Lightning Network, Evgeni, are jumping to the more complex solution. But there is a simpler one they do not even consider. And it is what built the global banking infrastructure. It’s not a “hub and spoke”, it is an inverted central network, not a central network. It is not at all correct to say “like hub and spoke”, it misses the point. The inverted network does not have a hub but it operates, accounting-wise, as if it was a hub and spoke. Without payment channels this meant you needed a monopoly on trust within the global banking system, but with payment channels you can do it trustlessly.

“Capacity problem” is not a real problem. It is the imaginary problem that money systems have not solved asymmetry in payments issue, they did thousands of years ago. “UserA” mostly sending and rarely receiving means they are broke. It is not a “capacity problem”. You are not thinking clearly. Start from the basics instead and work your way up.

“what happens when a large payment exceeds available capacity on any single path?”

That is called being broke. Asymmetry in payment clears loops, it does not magically give people infinite credit. These are thousands of years solve problems. You bring up the “what if” that is what was brought up thousands of years ago and solved. Rather than reject history (and Satoshi…) you can embrace it and also build the future.

You demonstrate low understanding by trying to position non-issues as important.

On how to coordinate the payment itself, it is possible it could be done with “two-party double deposit” rather than HTLC. I am not sure. A->R1->R2->B directly that way does not work (A+B risk only half of R1+R2 thus can attack). But if it is A ->R1 and B->R2 first (equal risk between users and routers), and then you are down to a single hop left. If that is signed by all four, so that the signature will both unlock pending at A ->R1 and B->R2, but also commit R1->R2? And R1 is the last to sign.

Do you see? This is vastly simpler, and scales extremely well. Yes the “real deal” with true multihop is better but much more complex. What this might be able to do is reduce a multihop payment to a singlehop, in terms of the coordination. As I just described. A and R1 lock equal amount, and B and R2. That leaves just one step, and the “key” to unlock that step also commits the other two steps, just like the hash lock works but a singular atomic step. This, I considered first now. Does it seem to add up? If not, the HTLC will always work, but it seems this simpler system could use a simpler coordination.

No - UserA can receive through other channels (external to this network), other networks, or L1 transactions. Real users don’t conduct all their finances through a single payment network. They’ll use whatever is convenient, creating asymmetries this system can’t cheaply rebalance at the user-router level.

“If everyone would just” use this network for everything then it might work on paper. But there’s no smooth transition path from today (people use whatever’s convenient) to that hypothetical state. A network that can’t handle asymmetric usage patterns loses to alternatives that can.

The whole idea fits in a sentence: if routers form a full mesh, any 3 routers can coordinate to transform some R1→R2→R3 balances into R1→R3 (and vice versa). That maybe useful in some contexts, but it’s not a discovery. It’s just arithmetic. Channel rebalancing among a mesh of cooperative nodes isn’t the hard problem in payment networks. The hard problems are channel depletion, capital efficiency, and handling users who don’t exclusively use your network.

PS it can only be done if R1 → R3 has enough channel capacity to support the state transition. The “beads” will move in opposite directions. You move one bead from R2 to R1, one bead from R3 to R2, but one bead from R1 to R3. Basically R3 pays R1 through R2 and R1 pays R3 directly. What if all beads in R1-R3 are already on R3 end and channel is saturated? You can’t novate your way out of channel capacity problem, which is the problem of LN, and reason why people have developed alternatives where a single commitment can “hold” balances for millions of users. Novating won’t magically enable R3’s users to receive more money from R1’s users. It will just transfer capacity from one route to the other.


CSW is not Satoshi. You invoke him like a prophet and treat our skepticism as heresy, but it only undermines your credibility. CSW had a signature move: take something trivial, dress it in appeals to ancient wisdom and esoteric jargon, and present it as a profound discovery that only the enlightened could appreciate. “This was solved thousands of years ago” - classic CSW energy. You’ve learned from the master.

Real Satoshi, if you bother to read his e-mails, never engaged in this kind of grandiosity. He explained things plainly and acknowledged limitations. You worship a fake prophet.

Is a 3-party novation routing network trivial though? I was unaware it could scale like that until recently. Have you known about it? Has Jeremy known about it? Tom? Anything in hindsight is trivial if you are starved of credit yourself and can’t show appreciation of anyone else. Bitcoin is trivial in hindsight too, but something put the guy who built it apart from everyone who did not and only trivialize things in hindsight. My 3-phase commit is trivial, from a certain point of view, but was hard to discover at first. Craig was a bit rude in 2009 too in emails and forums, he was a bit rude to Bytemaster. “Capacity problem” is fiction, you then argue response to it since in a fiction you can have control. But there’s a real world out there, with real people, and dictating in chat groups is mostly fiction.

This is just a circular payment which happens to map to the concept of novation.

If we eliminate A and replace it with a C-F channel, then it maps to 3-party novation: F pays to himself F->B->C->F moves state from F-B and B-C channels to C-F channel. This is documented, implemented, and has been used in LN for years. Calling it “novation” and invoking ancient history doesn’t make it new.

1 Like

“Loop clearing” by circular payment is multihop in terms of trust. It was in Ryan Fugger’s Ripple from Evgeni Pandurski’s work (Ryan invented the cancel-on-timeout 2-phsa commit round 2005 with staggered timeout added in 2008 as Lightning Network then used). Novation is single-hop in terms of trust. Both are thousands of years old. Since you say it is grandiose I mention that they are old, would you not already be well educated on the two concepts and that they are different?

In this table you see the two paradigms. Singlehop in terms of trust, and multihop. Lightning Network is focused on multihop. It is much more complex. It’s better but much harder. More things that can break or be wrong. Like Ryan’s cancel-on-timeout 2-phasa commit that is not secure, so the 3-phase I invented last year is needed (which is here…). Both are good, one is much simpler.

Only if the loop is long. As illustrated above, a triangle is special case of loop, and such loop maps to the concept of novation.

Novation is like a “virtual loop”. It is a loop that would exist in the central network. The “inverted central network” can accounting-wise pretend like such loops exist, and therefore clear them. As you see below, there is actually not a loop in the graph. As I said, these concepts are not well known by people. I was not aware this operation could parallelize a normal “hub and spoke”. I have already asked if Jeremy or Tom was. Were you? It’s trivial, sure. But seems people have missed the possibility.

A->B->C if there was a central network, it was A->bank->B->bank->C which is a loop bank<->B.

It’s a real loop. To replace some state in A-B-C with some state in A-C requires real update of all 3 channel states.

This preserves capacity between A and C (if either wants to pay 4 to the other he’d have to use both routes) but creates asymmetry in A-B and B-C channels. Rotation could fully exhaust the channels to become 0-4. But what’s the use of this? If B needs to pay 4 to C he can just do it by using both B-C and B-A-C routes, paying 2 through each. Or, you can first do novation which actually increases total volume of channel updates. Novation will create volume of 2 in A-B, B-C and A-C, and then payment will create volume of 4 in B-C.

Extending to 4 nodes: if D connects only to A and B (2-2 each), we get a triangular mesh but C-D capacity is limited to 4 regardless of how we rotate the triangles. To get full connectivity we need a direct D-C channel - a full mesh.

With a full 4-node mesh (6 channels, 2-2 each), any node can pay up to 6 to any other. But we’ve locked 24 total to achieve this. Capital efficiency gets worse as the mesh grows: n nodes requires n(n-1)/2 channels. At 10 routers that’s 45 channels; at 100 it’s 4,950.

This is the fundamental tradeoff: full mesh enables novation-based rebalancing but has O(n²) capital requirements. LN’s sparser topology with multi-hop routing exists precisely because full meshes don’t scale economically.

Credit clearing to deal with asymmetry in payments is systems. Loop clearing, is where there is debt in a loop. Novation, is where there was not a loop of debt, rather an intermediary in debt (both in and out) moves it. This requires a payment in a loop yes. The periodic routines to do 3-party novation is distinct from what loop clearing uses. It isn’t built-in to Lightning Network. To just randomly make a payment to yourself is not looking for novation. There is no way of knowing if you simplify or complicate the debt graph when doing so. You are raising non-issue after non-issue, then making it the center of discussion, since that way you can have a feeling of control. The 3-party novation payment channel network I describe is a good idea. Not well known about. Very simple. Peace

Maybe you meant to eliminate B from the graph instead of just fully draining the A-B and B-C channels to shift the A-C channel in opposite direction.

image

But that last step requires on-chain transactions to close the depleted channels. You can’t remove B from the network off-chain - those channels exist as on-chain UTXOs. In this context novation doesn’t avoid on-chain transactions, it just describes the end state after you’ve deliberately drained channels to remove intermediaries. That’s… just closing channels with extra steps?

1 Like

3-party novation is well known idea but they often use other terms like “delegation” historically. It simplifies debt graph by doing the same thing a central intermediary would do (but it does this “virtually”, it achieves same result but in a different way). If you have a balance with a central network and you pay out to someone and receive back, of course this does not mean you have to close your bank account. You are pulling out non-issue or fiction after fiction. Start from the right premises instead. I have already asked Jeremy and Tom if they were aware of 3-party novation. You one second say it is trivial then you show complete inability to comprehend it. What if is actually a pretty interesting possibility for how to scale Bitcoin to infinity? You would basically put the historical central banking system under Bitcoin but with payment channels, thus transcending the trust monopoly it required. Yes the real Lightning Network vision is better, but harder, and, it would reasonably end up including novation as well regardless.

LN is entirely the right column below. I suggest a system entirely the left below. Eventually both will be in a unified one, but the left is easier.

BitcoinAutist, some interesting things on coordinating the payment in the inverse central network model. The main problem in multihop payments is the “stop-propagation” attack, that an intermediary node simply… does nothing. This is why the timeout in HTLC was invented. It is a strange attack, to do nothing. A single link in a chain can destroy everything, by simply… doing nothing. The problem is no one has oversight, no one can know who is stopping it. But with 3-hops? A->B->C->D, B and C know everything. They have complete oversight. So, the timeout is not needed. But there is still another problem: how to enforce each “pair” (A/B, B/C, C/D) cooperate. Here, it can instead use “double deposit”, which requires both sign to abort (not just peer sending at each hop locks, but also the peer receiving locks equal amount). Then, to coordinate the payment, you use similar mechanism to Ryan Fugger’s from 2005 (the one LN uses), prepare A->B->C->D, then commit D->C->B->A with a signature (preimage or similar). The problem with this in Ryan’s model was the race against time. I solve that with the 3-phase (in way Ryaan suggested in 2006) but without timeouts, there is no race against time. If C and D have signed, C would never abort with B. But if D refuses to sign, C will just abort with B. Likewise, B will not abort with A until they can know if they can abort with C. With just 3-hops, this “dumb” approach works, but it stops working with more hops since no intermediary knows the full chain.

What I am suggesting is that by starting with a simpler system, it will be easier to get up and running. Then, society can use the slightly improved organization it will have, to reach the full goal.

No, it’s you who’s trying to discard the main issue (channel capacity) by declaring it a non-issue. You use confusing language to present a simple primitive: rotation of money in a triangle graph. Then you try to mock us for not having the preexisting knowledge of the term or the concept, even though the concept can be explained in a single sentence instead of having to reference tomes of history. No, I was not familiar with the concept of “novation” before this discussion, but now that I am I can rightfully declare it trivial.

Anyway, no matter how you rotate it (left or right) the capacity between any 2 nodes is invariant. All 3 states have equal capacity. Each step is a “novation”. Novation redistributes capacity but doesn’t increase utility for any of the 3 nodes - it doesn’t create anything new, just moves it around. Like splitting 0 into +1 and -1 (which, amusingly, is the basis of accounting). The total capacity problem remains unsolved. You’re mixing up accounting (representation of tangible assets, which can be reshuffled freely) with tangible assets (UTXOs on chain, which can not).

image

But above I demonstrated that this simpler system doesn’t scale. You add more nodes and maintain a full mesh and the number of channels will grow quadratically. At 4600 nodes and 2 BCH in each channel, we’d lock up entirety of 21M BCH. Initially, any node could move 4600 BCH to any other node - once (only 0.02% of BCH supply). And then to restore symmetry they’d have to create 9200 L1 transactions + do all the off-chain work to re-balance the entire graph of 10.5M channels by performing some sequence of rotations (or novations, if you will).

1 Like

You are making up a non-issue that you stick to because you need a sense of control. Yes of course 3-party novation is trivial, it’s been the basis of the money system for thousands of years. It’s as trivial as sticks and stones. It is what scaled payments for the past thousands of years, including in the banking system today. I have not ridiculed you for not understanding it. You have a sub-culture that built it’s identity on ridiculing “outsiders” which included Lightning Network attempts (which is Ryan Fugger’s Ripple from 2003 + “collateral”) and since 2016 even your founder. It would seem anyone who is not in that bubble would appear to be doing to you what you simply normalize internally to do to anyone outside your bubble. Novation, you cannot just arbitrarily do loop payments between three nodes, you have no way of knowing if you reduce or increase complexity of debt graph if you just do that. You need rules that do the novation. Yes, they are simple. This is the whole point, a simpler system is very easy to build and scale. Instead of spending 15+ years hoping “cancel-on-timeout” 2-phase commit would work (as LN did), can start simple, in parallel work towards more advanced. I have solved the multihop issue (see here…), but can still start simple. On scaling of course it scales. The problem with non-issues, is if you bring up them constantly, it is not much of a conversation. You are still stuck at the asymmetry of payment problem, which was solved thousands of years ago. You don’t “restore symmetry” by some “closing channels”, you do novation. Dozens of comments in you still have not gotten past the fundamentals which are, again, thousand of years old and known to anyone educated in the topic. Novations are not “closing channels”. You can’t just say “if you will” after saying something nonsensical. And why would you place all BCH in the routers, you need in the users too, roughly divided half half and in both directions.

We don’t ridicule outsiders for being outsiders. We’ve had productive discussions with BTC people (like moonsettler and polyd) working on better payment networks: eltoo, ln-symmetry, enigma. They understand LN’s fundamental limitations instead of hand-waving them as “non-issues,” and they’re exploring new primitives. I’ve hoped to bring them over to BCH since we already have the Script capabilities they need.

We ridicule specific beliefs that deserve it. Believing CSW is Satoshi deserves ridicule. Believing 2-party payment channels can scale to a global payment network despite the documented capacity problems: that deserves skepticism at minimum.

I was genuinely curious about your proposal. I asked clarifying questions, drew diagrams, worked through the mechanics. The conclusion: novation is just circular rebalancing, it doesn’t solve capacity scaling, and full mesh has O(n²) capital requirements. You responded with “thousands of years” and “you don’t understand.” That’s not us being closed to outsiders. That’s you not engaging with the critique.

1 Like

Ah. Your previous posts make a lot more sense now.

1 Like

The BitcoinAutist is pointing at a problem that is a non-issue as proof that the architecture I describe is “wrong” and that I am “not responding to the critique”. It is not possible to respond to a nonsensical critique, this is often the purpose of a nonsensical critique.

The problem that people can run out of money if they use up all the money… it is ridiculous to present that as “a problem”. And if this demonstrates your intellect, it explains why you are completely incapable of common sense when it comes to that of course Craig was Satoshi.

That novation is “circular rebalancing”, well, it is a very simple mechanism, yes. That’s the whole point of it. It is not built-in to Ryan’s 2003 vision nor to when people started to add “collateral” on top of his vision (Lightning Network or Raiden Network, etc). It’s actually a very simple mechanism that people seem to mostly miss. It is a different category from loop clearing, as there everyone in the loop has debt in a loop (each an intermediary in debt). Here, only one node is an intermediary in debt, and not the other two. Thus you can’t just randomly make three node loop payments and hope that most of them would be where one was an intermediary and the other two not. Then you’d on average increase complexity of debt graph, not reduce it. So you need your platform to search for novation paths, and then perform the novation. Lightning Network does not do this. Dismissing the architecture as “this is already in LN” well it is not. It is not on the horizon for any of the projects that are similar to LN nor in the older projects LN was inspired by.

To those interested (and despite the vocal minority here who flex what you could call their muscles, I know there are people interested), a 3-hop payment happens to have the central pair with oversight, whereas in longer payments there is no oversight. This likely means you do not need to rely on the timeout, and avoid the issue of race with chained timeouts. Thus much simpler. Time locks are great for the “real deal” in the future, but a simpler system is good to also start with in parallel.

And on in-group/out-group, I would guess your “in-group” is a small “crypto community” but that’s less than 0.001% of the real world. The world is a bigger thing than your Telegram chat group.

Good, I maintain since 2015 all evidence showed he was of course Satoshi. Between 2015 and 2018 I also invented this. Peace whoever you may be.

Except for minting or burning, money can not be “used up”, it can only change hands.
When you put money in a channel you didn’t “use it up”, you locked it up and reduced its utility in moving value by moving money.
The main purpose of money is for it to move, and in exchange someone moves a good or a service to you.
The capacity to move is your purchasing power.
If you can move a lot of money, you can bid for someone to move a lot of something.
When you lock money in a payment channel you made it immovable, you turned a free little bead into a bead locked on a string, and it can move only left or right but can not escape the string.
This is a fundamental problem of payment channels, which you insist is not a problem.

Payment channels are useful when expectation is they’ll be settled at the end of some session, not when they’ll have indefinite lifetime as with LN or whatever network that tries to use channels as the building block.

Examples of channel usefulness:

  • EV charging: you open a channel and start charging, and your wallet and station automatically keep channel updates ticking, at the end you close the channel. Instead of 100s of on-chain transactions for small charge increments: you only need 2.
  • Instant check-out shopping: you enter a shop and open a channel, by the time you’re done shopping and go to checkout the channel opening will confirm and you can check out instantly by having your wallet and POS device coordinate an updated state.

These don’t lock-up money, they just optimize money flow and move start of PoW security accumulation to before the checkout rather than after.

1 Like

The BitcoinAutist has, since his first comment, simply maintained a nonsensical “but this means you are wrong”. And any response to it, is reinforcing the nonsense. What I describe is a good idea, it is a valid idea, it is an underexplored idea. Here is a good overview for anyone interested: Bitcoin thing.pdf (282.5 KB). As this is a public forum with many people using it, not just the very loud minority. And I also solved coordinating longer multihop, see here, but such networks are more complex, more moving parts. Can build both, but sometimes the simpler “dumber” succeeds first.