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

Infrastructure
#1

Tom here favors the idea that users use payment channels simply for back and forth payments. This is a step backwards by 10000 years or so. But, it is also a very simple system. A slightly more advanced version of that, is to use 3-party novation. 3-party novation is a mostly unknown mechanism even though it has been around for thousands of years. It is very simple: you take a normal central network, you invert it, and then you can computationally operate in decentralized way but still work accounting-wise as if it was a central network.

Network_Topology_1_
Network_Topology_1_1000×300 32.7 KB

Any node in the inverted central network that has both debt in and debt out, can then request to move, or “novate”, that debt so it is directly between the debt in node and to the debt out node. This is the same thing that happens in the central network variant with A to bank to B to bank to C, but it is computationally decentralized, i.e., fast. And with payment channels with Bitcoin behind them, also trustless or trust-minimized.

The network of routers does not have to be a perfect inverted central network. I.e., everyone does not need to have links to everyone else, but the closer you get to the ideal the better it works (to the point where it works perfectly when it is perfect inverted central network).

I 100% favour the multihop payment approach and a true Lightning Network (or Raiden Network and anything else) but sometimes a simpler system can be good for the short term. This I describe here is meant to be a 2-tier system. There will be the routers, and, then the users. The users have payment channels to a router. And they can pay any other user via the routing network, over three hops. The routing network internally does 3-party novation to simplify the debt graph maximally.

This is an extremely simple, yet powerful, system. It might work well with something like Nostr, which is intended to be a two-tier system anyway (also a compromise…) You’d have users running their “LN light” wallet on a mobile phone, via Nostr they do payments, and the routers interact internally to do most of the complexity.

I have an implementation of 3-party novation since the past few weeks, I coordinated it as here.

This is for open discussion. Yes the “just build it and shut up” argument can be made. But there can also be discussion. I do not think most people here are even aware of this possibility. 3-party novation sems to be pretty unknown even though it is thousands of years old.

1 Like
#2

/thread

Also: Your “mesh” diagram = BCH L1. You reinvented BCH.

#3

Jeremy here I have corresponded with a few times earlier, the quality of his comments are typically like this. I think Jeremy tries to say he does not think any payment channel network is needed. That the inverted central network payment channel network is “just bitcoin” is not true, but Jeremy is against the idea of payment channel networks, and is saying “bitcoin can already do payments” or something similar. And yes sure, bitcoin nodes are a tight mesh, and the diagram for them looks similar, but so does diagram for any tight mesh so this is a bit low level response from Jeremy. This time as well. The inverted central network model is one that most people are not aware of. People (some “peter todd” according to Claude AI) have suggested a simple central network payment channel rather than multihop but there they actually do not add much over just using central ledger (there, Jeremy’s comment would fit), but the inverted central network is N times faster than the central network payment channel idea where N is number of routing nodes. It is a good idea, valid, and many people are not aware of 3-party novation as a mechanism, a single operation that can simplify debt graph to the point it becomes equivalent with a central network. Are you Jeremy? Aware of 3-party novation? Peace, Johan

#4

How is this different from LN hubs? e.g. Alice – Hub – Bob. On LN Alice pays Bob through the Hub, without having a channel open with Bob.
Is the idea that the 3 parties can coordinate to create an Alice – Bob channel and transfer their 2-hop relationship to a 1-hop relationship? But each channel locks liquidity. If Alice wants to use the Hub to pay some other party through the Hub, she’d still want to maintain a channel with the Hub.

Here’s a nice illustration of the liquidity problem: https://medium.com/@peter_r/visualizing-htlcs-and-the-lightning-networks-dirty-little-secret-cb9b5773a0

How does your scheme work around this?

#5

I have also previously corresponded with the BitcoinAutist here as well. He has varying quality comments. This one is low quality. As I already replied, the just a central hub approach would fit with Jeremy’s comment, more or less.

system
system1920×714 39.3 KB

Payments scale in terms of trust by introducing an intermediary, see here. Bitcoin is a central intermediary that happens to use majority consensus to oversee it. Whereas the model Tom likes, is singlehop in terrms of trust. Three party novation is an little-known alternative, that is single-hop in terms of trust, but still operates as if it was a central intermediary. It is decentralized computationally but not trustwise. Jeremy has already been asked if he is aware of 3-party novation or not. If you place such a single-hop network as the central node instead, you get not 2-hops (as in central network) but 3-hops. It’s very simple to organize.

True arbitrary multihop is harder, it requires solving the coordination, which I have with the 3-phase commit (see here). But a simpler Lightning Network “light” can still be good to bootstrap.

The BitcoinAutist here previously threw out 30 pages of text he believed is a big problem, that just describes a trivial attack that is barely an attack. Now, he also throws out a trivial problem, that some payment channel network implement in such a way that their smallest possible payment is whatever. I solved the big coordination problem, but to maintain the fiction of importance it has to be irrelevant thing after another, all while banning anyone who acknowledges who invented Bitcoin to start with. Cowardly.

Peace

#6

But your picture still looks like LN. LN hubs can have channels with each other, too. Both my simple example structures and your structures can be found in the real LN graph, and so can Tom’s structure - the single channel is a building block of more complex structures.

image
image960×669 110 KB

(source)

But LN has the capacity problem illustrated by the “beads on string”:

image
image1200×95 3.65 KB

You can’t move capacity from one channel to another without making two on-chain transactions. Moving capacity from A-H-B to direct A-B requires 3 on-chain transactions (3 channel updates).

So, did you solve the capacity problem, or did you not?

You misunderstood my intent. We don’t all have infinite attention to spare, and we didn’t ponder these problems as much as you did. I can’t even tell if your proposal is good or not, if it could be useful or not, because I can’t seem to understand it. Either I study this more deeply (I won’t, because I don’t feel like spending the required time), or you try answer our low-effort questions and try to spare us the work and then maybe we can still have some fruitful discussion, or wait until someone who already understands it all appears and decides to engage with you.

I didn’t expect you to read that (if you hadn’t already). I happened to find it while looking for something else and was reminded of your work. My only question was “found this today, are you aware of it?”.

1 Like
#7

Thanks for pinging me, I’ve read through this and found it a fun read.

If everyone has links to every one else, you get to the “what Tom likes” image, where no routing is needed as everyone has links to everyon else. I.e. there is no intermediate in what you call the “ideal”.

WRT to the term:

Novation refers to the substitution of a new contract or obligation for an existing one, where one party transfers its rights and obligations to a third party, with the agreement of all involved. This inherently requires three parties: the original obligor (transferor), the new obligor (transferee), and the obligee (the counterparty who consents).

The actual term ‘3-party novation’ did not give any results in wider searches, but I can imagine that this is just clarifying the term as quoted above.

So, I disagree with Jeremy, OP didn’t reinvent BCH because BCH is trustless transfer of coin. The concept of Novation is adding trust and participants to the system. That is not Bitcoin Cash. It is less.

I won’t claim I fully understand what OP describes, I just know that I’m not interested :man_shrugging:

#8

Asymmetry in payment channels in who tends to pay in what direction. If they were always symmetric, “barter” (just back and forth) works. Ways to clear asymmetric debt were invented historically because payments are not symmetrical (or it allowed them to not be). A more advanced one is to find loops (and then do multihop payment from loop-finder back to themselves), but the simpler one is 3-party novation. The “inverted central network” I suggest works because it uses 3-party novation. The same architecture with just multihop payments, would not work unless all payments were symmetrical. They most likely are not. Traditional multihop tends to “transcend” this problem as there are so many possible paths one is always found (and it eats up the debt), but for just “single-hop” effectively within routing network (and from user to routing node irrelevant) likely not enough. So if current Lightning Network had collapsed down to such architecture, it will become stuck in terms of liquidity.

1 Like
#9

This shows a complete inability to understand even the most basic concepts. The issue is about asymmetry in payments. This is something anyone has known for thousands of years, it is why money systems exist. Asymmetry in payments is solved with credit clearing mechanisms, either loop finding, or, novation (which reduces to 3-party novation). In a central network, novation happens automatically. In an “inverted central network”, it can be done via 3-party novation.

The concept of Novation is adding trust and participants to the system.

“Trust” as in payment channels, which are trustless. Historically, the same system required trust. This is clear in my post, “And with payment channels with Bitcoin behind them, also trustless or trust-minimized.” So another low-quality response. You were not pinged, you were used as an example, very deliberately, of someone who rather than transcending a problem instead falls back on an world-view where the problem does not exist. This is a common psychological coping mechanism. What set Satoshi apart from 99.99% of everyone else who did not make a leap and transcend a problem, is he had courage.

#11

To BitcoinAustist or anyone else interested. I think my point is not coming across. Presumably because the mechanism I describe is not well known. Historically it is well known since Rome and middle ages and plenty of books from 1700s and 1800s, and still well known today. But maybe average person misses it (I did until a few weeks ago). The mechanism seems meaningless at first. If nodes do singlehop payments, and end up having both IOU in and IOU out, they can ask the in-peer to instead pay that directly to the out-peer. This may seem meaningless but it is actually powerful. Imagine there was a loop A → B → C → D → E → F → A. The nodes themselves are not aware this loop exists. As they then follow the protocol, the 3-party novation rule, and lets say C → D → E was the first to do it (nodes periodically run attempts routinely…), you removed D from the chain and you get A → B → C → E → F → A. Then someone else did it, maybe A → B → C, and you get A → C → E → F → A. Then maybe F → A → C did it, and you get C → E → F → C. Then C → E → F did it, you get C → F → C which is just C <-> F. You see how you had asymmetric payments, and a single extremely simple operation managed to socially figure out if that the debt had been repaid by forming a loop. This 3-party novation is infinitely simpler than the alternative (to search for loops, which is also what LN does when it searches payment paths), but, it requires every node “trust” every other. But with payment channels this is not the same type of limitation, since “trust” is actually a trustless payment channel. So this extremely simple infrastructure could quite easily scale Bitcoin or similar to infinite speed.

novation
novation723×307 11.5 KB

#12

I now understand what it is you are not understanding. The “capacity problem” you point out is a result of asymmetry in payments, and not accounting for it in the architecture when Lightning Network has failed to reach the complexity it would need to solve it, and instead behaves more like a quite centralized network. The problem of asymmetry of payments is thousands of years old and how to solve it as well thousands of years old. The article you shared talked about another “problem” but apparently your intention was yet another irrelevant “problem” that is not actually a problem coordination-theory wise.

I also understand Tom’s response now, where he likens what I describe to a central network. Tom as well, misunderstands the topic, but I see his point of view now. The thing is, yes a central hub can operate as fast as the “inverted central hub” but there you have to split it internally based on trust. This also explains Tom’s comment “you are just reintroducing trust” - Tom assumes I describe the old “central hub” idea. But I am not. When you spit a “central hub” internally, you would do so by using novation between the “routers” in it (the same design I describe) and then use the inverted central network internally. But if you instead do it with payment channels between the routers, you get a system that does not operate internally by trust. You get the historical global central banking system, without trust. It scales very well. Yes multihop is better and for that, I invented the coordination solution already… but sometimes a “simpler” system can take off easier, can still work on “the real deal” in parallel.

example
example1008×1017 91.2 KB

#13

So to be as clear as possible: You seem to describe the problem of asymmetry in payments (but article you shared did not, so you are not communicating very well). How this is solved historically, is by credit clearing mechanisms. This is known and practiced for thousands of years. These are either loop finding (across trust silos) or novation (within trust silo). The thing with multihop payments is that it can achieve the equivalent of loop clearing, if the network is sufficiently decentralized. The architecture I suggest is the “simplest possible”, for the reason that sometimes the simplest tool is easiest to start with. It uses novation, the simplest version of it, 3-party novation. So yes, it does not have the problem you call “capacity problem”. Yes it solves it in the context in which you ask if it has been solved. And to be clear if anyone misses that, the benefit over a central hub only - which could internally parallelize in same way by “inverted central network” - is that the one with payment channels between routers do not use trust. The other one is the global central banking system since the renaissance and it uses trust, so you get a single group monopolizing it.

#14

This post was flagged by the community and is temporarily hidden.

#15

But does your novation transaction happen on-chain or off-chain?

A owes B who owes C and if B’s debt to C is less than A’s debt to B then all 3 parties could agree to replace the graph so that A’s debt to B and B’s debt to C is replaced with A’s debt directly to C, is that it?

Technically LN can do novation, too, but it requires an L1 TX. The 3 parties can coordinate to create a CoinJoin transaction where same transaction can atomically settle or rebalance 2 channels and create the new A-C channel. It requires a 2-in-3-out L1 TX. This can’t be done by updating some off-chain commitment. Are you suggesting you have a way to have payment channels that can somehow transfer state off-chain in order to achieve off-chain novation?

#16

You are starting from the wrong premise. Payment channels as a concept is well understood. You brought up an “issue” which is not an issue in a good architecture, and then bring up a “problem” of having to always close and open channels. This is taking a valid and well known concept, then just misrepresenting it, to move discussion to a fictional problem.

Of course it is “off-chain”. It’s three nodes who all trust one another. Since they all trust one another, it can likely be coordinated simpler than traditional multihop. Rather than HTLC, “two-party double deposit” may be enough. Both peers in pair at “prepare” step lock same amount from being withdrawable. They then have to come to agreement if the process committed or aborted. They can then use the simpler coordination rules below. For the payment, it could be coordinated similar to traditional ideas for multihop payment (or possibly simpler since just 3-hops).

novation
novation600×543 52.7 KB

#17

This sidesteps the actual mechanism. Do all channels A-B, B-C, and A-C have to exist beforehand? Does A-C channel exist before the A-B-C debt is transformed to A-C?

The issue is: in Bitcoin/BCH payment channels, the channel state is a commitment to a specific on-chain transaction (which usually never happens, unless one party force-settles). You can’t “transfer” capacity from an A-B channel to an A-C channel without on-chain transactions to close/open channels, unless A-C channel already exists (then it’s just coordinated off-chain updates across existing channels).

The proposal seems to assume routers maintain a near-complete mesh of channels with each other, so novation just means coordinated balance updates across existing channels rather than creating new ones. That’s feasible off-chain but requires significant locked liquidity upfront.

I’m having trouble making sense of this, sorry.

#18

Nothing is sidestepped in my explanation. The basic concepts of payment channel networks are well understood. Silly to role play they are not, just like it is silly to role play Craig was not Satoshi, etc. You point out a problem of “capacity used up” that is solved historically since thousands of years and was always solved in architecture of Ryan Fugger’s system Ripple and it + “collateral” (which became “Lightning Network” and “Raiden Network” etc). The “actual mechanism” to solve asymmetry in problems, is known since thousands of years. I could not “sidestep” it even if I wanted to in a discussion since it is public domain common knowledge. But you are uneducated, so you maintain “no explanation is given” even though 1) it is, and 2) it is a well-known mechanism so it should not have to be given, nor should there be a claim it was not given.

Payment channels always “exist beforehand” that’s the point. You refute the common points, so you can somehow control the discussion. Erase a decade or a thousand years.

The “issue” you bring up is not an issue in a correctly designed system. Ryan’s was correctly design, and so is the simpler one I have described.

The proposal seems to assume routers maintain a near-complete mesh of channels with each other, so novation just means coordinated balance updates across existing channels rather than creating new ones. That’s feasible off-chain but requires significant locked liquidity upfront.

Any payment channel network assumes that, yes. They are based on “locked collateral” yes. That’s the whole point. Yes, as close as possible to links between everyone. Anyone joining into the routing system gets plenty of routing fees, there is nothing inconsistent about the design at all, in any way.

It is extremely simple to make sense of. As was the proof Craig was of course Satoshi.

#19

Thanks for clarifying. So to confirm: novation happens only between routers (who maintain a full mesh), while user-router channels remain fixed? Users don’t switch routers - they just have their balance updated with their single router, and routers rebalance amongst themselves via novation on their pre-existing mesh of channels?

image
image624×714 46.4 KB

Novation to have user switch router would still need an on-chain TX: to replace A->R1->R2 with A->R2

#20

Yes. It’s a two-tier system. Each routing node is also a central network under it. There, you do not need novation, since it is a central network, the intermediary makes loops form that have same result as if you were to use novation in “inverted” one. But the routing core is an inverted central network. There you need novation.

invert
invert1244×448 134 KB

If a user switches router that’s not “novation”. They just close their account with one and open with another… This is another non-issue, has never been issue in payment channel networks that users could close and open payment channels.

Yes it is like you describe in the image.

1 Like
#21

Ok so the proposal is essentially:

“Make LN more hub-and-spoke with a fully connected hub layer, then do periodic rebalancing between hubs”

This is a topology constraint on existing payment channel networks. The “3-party novation” is circular rebalancing between three routers who already have channels, which LN can already do.

The capacity problem still applies at the user-router level. If UserA mostly sends and rarely receives, the UserA → Router1 channel depletes in one direction regardless of how well the router mesh rebalances. Inter-router novation keeps the hub layer healthy but doesn’t address user-channel depletion from asymmetric payment patterns.

And at the router level: what happens when a large payment exceeds available capacity on any single path? If UserA wants to send more than the Router1 → Router3 channel can handle, you’d need multi-path routing or on-chain rebalancing: the same problems LN faces today.

The novation mechanism helps with gradual imbalance accumulation between routers, but doesn’t seem to address capacity limits or asymmetric user flows.

1 Like