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

[bitcoincashautist]

@bipedaljoe

As this is a public forum with many people using it, not just the very loud minority.

You are now the “loud minority”

Anyway, it was interesting to me to unpack what are you even talking about, your presentation actually piqued my curiosity because I didn’t know about how “novation” solved banking. But now that I unpacked it, it turns out it was just some hot air, you just called LN circular payments “novation” (as shown above, the “novation” operation is mathematically identical to circular payments that LN already does) and thought that somehow solves something when it solves nothing.

The thousands-of-years-of-banking appeals are a red herring. Traditional banking “solved” these problems by having a trusted central ledger that can create accounting entries at will. Payment channels are fundamentally different because they’re backed by actual UTXOs with fixed capacity. You can’t novate your way out of that constraint.

@bipedaljoe

And I also solved coordinating longer multihop, see here

I didn’t unwrap this yet (link to paper), don’t understand what problem it tries to solve, so can’t comment much now.
You should open a new topic for it so we can try unwrap it, too.

[bipedaljoe]

BitcoinAutist has reasoned falsely here from the start and demonstrated that. And acknowledged he was not aware of novation.

Lightning Network is based on Ryan Fugger’s ideas for Ripple that date back 2003. Satoshi (Craig…) referenced Fugger’s work in emails with Mike Hearn as “the only other project to do something interesting with trust besides centralizing it”. Now these days, Lightning Network is well known, but those were the roots. It uses the 2-phase “cancel-on-timeout” that Ryan invented (which is not secure, this is one thing holding such networks back, and the secure version was invented by me last year see here).

Neither Ripple nor LN or anything along those lines were about novation, since they were multihop in terms of trust. Novation is “dumber” as it is singlehop trust-wise (but with payment channels this is not the same type of problem). Both Fugger and LN had more advanced visions.

The multihop clearing is loop clearing. This is well known since thousands of years. That novation is “just circular payments” is misrepresentative. The typical loop clearing (in the paradigm that Fugger and LN was part of and Evgeni Pandurski worked on too) is along debt. These are “just circular payments” yes, that is exactly how those are done, and why they exist in LN. But novation is not just a circular payment. It is not along debt at each hop, and it is only meaningful in a specific scenario: only one of the three nodes is intermediary in terms of debt. Randomly doing three node “loop payments” would only achieve this in very few cases.

BitcoinAutist just demonstrates poor judgement and ability to discern. No, novation is not built-in to LN, it is anti-thetical to what LN had as the goal. It is a mostly missed possibility. I describe it well, and I show how it makes every step of everything easier, see article that I shared previously.

I am not so sure I am the “loud minority”. I think lots of people interested in Bitcoin and the Cash or any other fork or Ethereum or anything along the same lines, are pretty balanced and reasonable. But there are a few loud ones who build their identity on it, maybe life is poor otherwise.

The thousands-of-years-of-banking appeals are a red herring. Traditional banking “solved” these problems by having a trusted central ledger that can create accounting entries at will. Payment channels are fundamentally different because they’re backed by actual UTXOs with fixed capacity. You can’t novate your way out of that constraint.

They solved it most likely with the inverted central network. Which yes requires everything is trusted internally. This is why there were family monopolies or ethnic. But with payment channels, it does not require trust. This is something people miss.

I didn’t unwrap this yet (link to paper), don’t understand what problem it tries to solve, so can’t comment much now.

You need a penalty on each phase for “chunked timeout” to work. Otherwise, nothing stops attack on the phase without penalty, thus you end up undermining the timeout as the solution to “do-nothing” attack. Ryan never achieved a penalty on all phases. It is ideally done with the 3-phase I describe (and implemented, my network runs on it…) but you can also do it with 2-phase by both “cancel on timeout” and “commit on timeout” (Ryan likely knew that but he has not mentioned it in the 2003-2010 period when he lead things).

[bipedaljoe]

To be as clear as possible: What I describe is anti-thetical to the ideology of those who push for LN. This is one reason the possibility is missed. But, it actually is trustless with payment channels. LN is more “web-of-trust” people, Bitcoin was founded on not being that type of system. It is a system of competition. In the architecture I describe, there will be very high competition to be a router in the inverted central network. The rich will compete to be there, as it is a good way to make money. This is the ideology of Bitcoin in 2008. I prefer LN approach myself, but people are not ready for it maybe. True p2p, we still rely on permissioned IP addresses (as opposed to geographical that would be permissionless, i.e., no ISP) and those trying to bypass that with “Nostr” or similar come up with partly nonsense designs.

[bipedaljoe]

To be as clear as possible about “circular rebalancing” in LN. It seems to just make payment loops without any concern about if it is via debts or via unused biitcoin in the channels. This is like throwing a coin, in terms of if it simplifies or worsens the debt graph. You might clear the debt for one channel (the person who did the process) but introduce more on others than you removed from yourself. It is a terrible idea. The normal solution people have is via debt only. I.e., a special payment that is only via debt. Since it is like throwing a coin, the average improvement is: nothing. While everyone aggressively would do “circular rebalancing” and everyone else as well they just undo the work of each other. The correct solution is thousands of years old, you do the same thing but limited to debt pathways only (it can only ever reduce debt, not increase it, it never uses not spent bitcoin). Or, in a simpler and more centralized network, novation. BitcoinAutist has from the start of this thread demonstrated very poor judgement.

[bipedaljoe]

I noticed 3-party novation via a Hans-Florian Hoyer (he is very anti multihop whereas I am very pro multihop). He is all about centralized banking. But the thing is, with payment channels, the traditional centralized banking techniques behave very differently. Hoyer uses the terms “delegation” and “scontration” which are also the terms used for centuries or millennia. See Pothier 1761 who cites Justinianus Digester (533 CE), or Foran, and the terms are probably in Newcomb/Colwell that Hoyer likes to mention.

• 1761 - Pothier: “Treatise on Obligations”
• 1859 - Colwell: “The Ways and Means of Payment”
• 1885 - Newcomb: “Principles of Political Economy”
• 1886 - Foran: “An Essay on Obligations”

“Scontration” (loop clearing) reduces to “delegation” (novation) if every node trusts every other node, but otherwise “scontration” is how to solve the asymmetry in payments issue. It is what Ryan envisioned and early LN too.

Here is one of Hoyers PDF: Taking_the_Community_into_Account.pdf (1.4 MB)

How to deal with asymmetry in payments is not new. The idea you would just do magical “circular payments” and hope for the best, is not a serious idea. To argue about it here, like BitcoinAutist does, is to show poor judgement.

[bitcoincashautist]

@bipedaljoe

the debt graph

If the router graph is a full mesh then there exists a triangle of channels between any 3 nodes, and any triangle can be rotated left or right. But in a full mesh, every triangle’s edge will be shared by many triangles. Are you proposing some heuristic to identify which triangles should be rotated and which should be left alone?

@bipedaljoe

it can only ever reduce debt, not increase it

Is this the criteria for the heuristic? But what does “debt” mean in the context of payment channels? Do you label state asymmetry as the debt? If channel state is A 2 - 2 B then there is no debt. If it has been updated to A 3 - 1 B then you could say that B owes A 1 coin, and if channel is settled then the debt will disappear because debt will be paid. OK, so you’re after only such rotations that even out the triangle’s channels, is that it?

But making the parallel with banking and debt is what actually makes you come out as confusing and reach wrong conclusions. If banks A, B, and C each keep a ledger of who owes what to who, then, yes, you can do full novation of A-B-C to A-C, because the A-C ledger is unlimited in amount of debt it can record. You and me can conjure debt out of thin air, I say you owe me 1 billion, you say I owe you 1 billion, net is 0 but both of our ledgers will show Assets: 1B, Liabilities: 1B. You can’t do this with payment channels. If A-C channel is too small or already imbalanced, then it won’t have enough capacity to have state from A-B-C transferred over, the “rotation” will be stuck as soon as any channel’s endpoint reaches 0. Capacity limit is a real blocker.

[bipedaljoe]

If you start from the fundamentals instead. Look at Hans-Florian Hoyer’s material or read Pothier, Foran, or material on these topics, is a good start. I’m not suggesting anything new. What I call “3-party novation” (historical term seems to be “delegation” but 3-party novation is easier for anyone hearing it first time) works between three nodes who trust one another. In itself, it does not require “full mesh” in a network, just between the three nodes. But for a routing network, novation will only efficiently solve asymmetry in payments problem (which you seem to call “capacity problem”, a problem that is solved actually in LN design if they managed to scale to the original vision but since they do not the problem appears) if it is more or less a “full mesh”. You can imagine it. You can still do loop clearing otherwise, if LN did that instead of their “circular rebalancing” (assuming this is just a normal payment but in loop and does not care if it reduces or increases debt) but it is much more complex to implement and work with, and it actually requires my 3-phase commit as well unless you do like Michiel De Jong, “chunked clearing”, but it is a bit messy, and you still need loop finding which gets complex with many hops (it is doable sure, my implementation does it extremely well, but sometimes easier systems are easier to get launched and popular).

Are you proposing some heuristic to identify which triangles should be rotated and which should be left alone?

In the 3 node example the initiator knows there is 2 debt links and will become 1. This is not the same in longer loops. So there maybe you can ignore whether or not C and A also were intermediaries in debt (i.e., it was a debt link), since it would not be negative to clear a loop either. But this “shoot or miss” would not work with longer loops, since you risk introducing more debt than you clear. Or, initiator knows 2 links will be reducing debt, if there is 4 links it is 50-50 for the other 2. You end up with 100% for 2 links and 50% for the rest, so you reduce on average 2 every time. It is not complete nonsense, but it is extremely inefficient. Searching for paths is expensive, and then wasting it that way is not very serious. But for 3 hops yeah it will work to “shoot or miss” since it is beneficial in either case.

Is this the criteria for the heuristic?

See above. Of course you would aim to reduce debt, but the “shoot or miss” circular payment does reduce it by 2 on average so while it is extremely inefficient approach with longer loops, you would be technically right. But these are not new concepts. Yes, you here proven technically that I misrepresented “circular rebalancing” which is not a meaningful way to build clearing systems. But this was not the topic. You just focus in on a topic where you can control. I already in first post mention loop clearing. Yes you can do “shoot or miss” loop clearing like that but it is not a serious idea. But technically, sure, 2 on average cleared. You demonstrate you got me to misrepresent it slightly but it was never relevant to the topic to start with, it is just a strawman of the topic, as it has been from your first comment.

[bipedaljoe]

The 3-hop coordination rules I suggested previously were insecure. One possibility with 3-hops is it becomes possible to use a mechanism that has been “not on the table” for true (any-length) multihop: majority vote. Anyone who attempted to design multihop systems has noticed simply majority vote fails because anyone can sybil attack with fake accounts (the same type of attack BitcoinAutist shared the 30-page article on a ridiculous solution to as it is not an unsolved issue). But with just 4 nodes, it might work. It seems it would work well with “equal risk” approach, which works if it is balanced symmetrically. The result is one where no node would benefit from not cooperating.

3hop.pdf (32.0 KB)

On “makes you come out as confusing and reach wrong conclusions” it is known the standard HTLC approach would work for 3-hop too. I have assumed it must be possible to do it simpler, but even with HTLC the novation approach is still simpler. But HTLC to be secure is quite complex (you need penalty on all phases to do “chunked penalty” and avoid or reduce the chained timeout race condition problem, as shown here). Having a simpler network, simpler rules, simpler code, as an alternative, is beneficial. My responses have not been “confusing” they’ve been very coherent. That I did mention some brainstorming for alternatives to the HTLC (note, I am also the person who solved the HTLC race condition problem in the perfect way) is not “confusing”, I stated it was brainstorming.

[bitcoincashautist]

@bipedaljoe

In the 3 node example the initiator knows there is 2 debt links and will become 1.

Can you clarify what “debt” means in the context of payment channels? Is the below schematic correct?

  Max. debt    -> Rotate left ->       No debt
A 0 ----- 4 B                       A 2 ----- 2 B
   4     0                             2     2
    \   /                               \   /
    0   4                               2   2
      C                                   C

So finding a triangle where all 3 channels are exhausted in a circular direction, then rotating it back into perfect balance, sets “debt” in all 3 channels to 0? Does this qualify as “novation”?

If so, it’s a circular payment with specific criteria:

• Triangle path only
• All channels equal capacity and fully exhausted in one circular direction
• Rotation restores symmetry in all 3 channels

Now imagine a full mesh of many nodes. Are you claiming that this algorithm (find only these specific triangles and rotate them) is the optimal way to keep the graph balanced? What happens when triangles share edges? Does greedy “rotate any valid triangle” converge to a balanced state of the whole graph? Can you get stuck in local minima where no triangle is fully exhausted but the graph is still imbalanced? Does rotation order matter for convergence? These are the interesting questions.

[bipedaljoe]

Why do you ask eternal clarification for concepts that are defined for thousands of years? If you are so knowledgeable and you can throw your founder under the bus because he does not live up to your great intellect, wouldn’t you know these things?

“So finding a triangle where all 3 channels are exhausted in a circular direction, then rotating it back into perfect balance, sets “debt” in all 3 channels to 0? Does this qualify as “novation”?”

The two categories historically are clearing debt in a loop (“scontration” is the term in Enlightenment period that builds on Roman law that is the basis for European law. Three or more) and moving debt when one node is an intermediary (“delegation” the term historically, always three).

Your example is “scontration”. It is how debt is cleared across “trust silos” but it also works where everyone trusts one another. It is not novation. It’s a mechanism that works across “trust silos”. Novation only works inside trust silos. 3-party novation and “loop clearing” happen to overlap in the situation three nodes happen to have loop debt, technically if you apply novation it also does “scontration” in that case. As I already said, you can “shoot and miss” in that scenario. In the central intermediary case, A to B to C to A, the central intermediary would also clear that loop, A to bank to B to bank to C to bank to A. Doing the operation on longer chains than 3 requires the machinery of “scontration” which includes loop finding. It is what Ryan’s Ripple and LN are based on, but in the special case all nodes know one another you can reduce it to the 3 node operation.

• All channels equal capacity and fully exhausted in one circular direction
• Rotation restores symmetry in all 3 channels

No it is the opposite. But clearing in a debt loop is also meaningful, so you can let it do both. This is clear in the term and definitions and well known.

The point with novation in full mesh is the accounting is identical to a central network, but you do it decentralized (so faster, and with payment channels still trustless). If you start to try and do the same thing in longer loops, it is the wrong tool there. There, you do payments along debt, not along debt+unused bitcoin. You need a lot of complex machinery to find loops, and you waste that if you are just on average clearing 2 links in any N node payment loop.

However you want to raise non-issues to try and control this discussion, these are all concepts that people have known and understood for thousands of years. You are showing poor judgement. You have not even managed to understand what 3-party novation is, after 30 comments. You are wasting this conversation for fun, with a couple of your friends and then you’ll say “oh look at him explaining poorly” just like you’ve thrown your founder under the bus. But I am explaining well, and I’m successful, and there is people even in your “community” who are interested.

[bitcoincashautist]

@bipedaljoe

The two categories historically are clearing debt in a loop (“scontration” is the term in Enlightenment period that builds on Roman law that is the basis for European law. Three or more) and moving debt when one node is an intermediary (“delegation” the term historically, always three).

So this is clearing the debt, right?

  Max. debt    -> Rotate left ->       No debt
A 0 ----- 4 B                       A 2 ----- 2 B
   4     0                             2     2
    \   /                               \   /
    0   4                               2   2
      C                                   C

Is this a scenario where you take the perspective that A is an intermediary in debt between B and C?

C owes B through A    -> Rotate left ->  C owes B directly
A 0 ----- 4 B                              A 2 ----- 2 B
   4     2                                    2     4
    \   /                                      \   /
    0   2                                      2   0
      C                                          C

Is this what differentiates “clearing” from “novation”? The operation (rotate left by 2) is the same. It’s just the context of before/after states that differs.

[bipedaljoe]

“Shoot and miss” loop payment averages two cleared links regardless of loop length. This is most efficient at three nodes. If everyone trusts one another, instead of finding a chain of intermediaries (in debt) ABCDEF and then moving from A to F, it can be done by a single operation that is always only three nodes. CDE moves CE. CEF moves CF. BCE moves BF. ABF moves AF. This also works if the debt chain was a loop. Think of it like digital logic. You can use building blocks, AND, OR, NAND, NOR, XOR, XNOR. Reducing things down to building blocks makes it simpler to work with, and reason about. Being able to build a relatively advanced “payment channel network” with such a simple operation, is powerful. It does not make the operation “hard”, you have no problem understanding it. The point is not to demonstrate “oh look I can be so advanced no one understands anything”. The point is simple tools are also powerful. It is not supposed to be “hard”, it’s a simple singular operation that can do pretty impressive things.

[bitcoincashautist]

@bipedaljoe

The point is simple tools are also powerful. It is not supposed to be “hard”, it’s a simple singular operation that can do pretty impressive things.

I think finally see it! The “novation” framing matters because:

• It only requires identifying one intermediary node, not a complete debt cycle
• In a full mesh, any node that’s intermediary between two others forms a triangle by definition
• The search problem is “find nodes that are intermediaries” rather than “find complete debt cycles”

Clearing balances all 3 edges. Novation balances 2 edges but unbalances 1, still a net benefit towards full graph normalization.

But why is it important to distinguish these cases? Take the perspective of A. He notices that he’s the intermediary between C and B. Either novation or clearing will restore his channel’s balances, he needs not care about the state of C-B channel, he only needs to know that it has enough capacity in the correct direction so that he can initiate a 2-left rotation.

[bipedaljoe]

Great. Yes it’s a concept specifically within aa centralized community. It only makes sense there. I found the concept nonsensical at first too, it required someone arguing a lot for me to notice that “oh this is actually pretty interesting” (but he would not explain it, he would just critique any other approach than his, so I had to discover it by myself, that it all reduces down to a three node operation that is). People in “crypto” typically dislike centralized banking system, and me too. But the thing with this idea is that payment channels make the “central banking system” (that deals with this type of novation internally) actually trustless. During our back and forth here, I have tried to figure out how payment coordination can have benefits from it being just 3 hops. I think this may be it: 3hop.pdf (34.4 KB)

[bipedaljoe]

But why is it important to distinguish these cases?

The “novation” case (when “shoot blindly”) only makes sense in three hops. “Scontration” (loop clearing) makes sense in any number of hops, and more specifically, it is across trust silos. “Scontration” is the more advanced one, but it is much more complex. Finding loops is not free. Coordinating along more than 3 hops is more complex (requires timeout thus needs 3-phase commit) than 3 hops (can likely be much simpler, possibly skip timeouts, see game theory I suggest).

For 3 hops. It is not important for the operation to distinguish. You and me can still distinguish, because it matters (one is centralized, novation, the other decentralized, scontration).

[bipedaljoe]

Instead of “beads on a string” you can think of it as mutual credit.

You and me lock 100 XYZ in payment channel.

I transfer you 10 XYZ, this shows up in system as - 10 XYZ on my side, + 10 XYZ on your side.

Then if we update the channel “on-chain”, it applies the balance changes, 90 XYZ on my side and 110 on yours.

The simple trust based system has no “collateral” locked so it is instead an agreement, “I trust you to go into debt with me up to 100 XYZ”. Payment channels are built on top, but the underlying system is the same. For any blockchain custom approach to implementing the collateral might exist, but it is a mutual credit system accounting-wise underneath the “collateral”. It’s two layers.

Here for the real future Lightning (or equivalent) Network eventually:

[bitcoincashautist]

@bipedaljoe

“oh this is actually pretty interesting”

I had the same moment just now, yeah, it’s pretty interesting.

@bipedaljoe

For 3 hops.

Yes, triangle rotation is always 3 hops A->B B->C C->A. From any node’s perspective, the algorithm is just:

1. Am I an intermediary? (e.g. A-B and A-C imbalanced in opposite directions)
2. Does C-B have capacity in the right direction?
3. If yes, call on B and C to rotate.

What if B or C is uncooperative? And what’s the incentive for A to want to do it?

@bipedaljoe

The simple trust based system has no “collateral” locked so it is instead an agreement, “I trust you to go into debt with me up to 100 XYZ”. Payment channels are built on top, but the underlying system is the same.

This is an interesting perspective. If you view channel state as record of debt, the money locked inside the channel is that debt’s collateral. Channels are debt with 100% collateral.

---

But how does this apply to a whole payment network?

The problem you seem to be solving is that of entirely avoiding any operation of 4 or more hops, ever. By having a full mesh of routers, any router’s user could pay any other router’s user through just 3 hops. A-R1-R2-B. Then what? A can’t pay anyone else until he receives money from someone. It can be B (back-and-forth) or some C or D pays A. In between, routers can just keep looping the “intermediary removal algorithm” to keep the graph normalized and support 3-hop payments between any 2 users. Does this sum it up?

[bipedaljoe]

@bitcoincashautist

The problem you seem to be solving is that of entirely avoiding any operation of 4 or more hops, ever.

Keeping things simple solves more problems than just that. With this two-tier architecture and an “inverted central network”, each user (or router) can know the exact path to another user. So you do not need path finding mechanisms. Path finding is not too hard, I implemented it in full, but it is still hard. Every level of complexity introduces problems. Path finding for example, you need to prevent spam, which means you need “pay-per-query” (which mine does…) Keeping things simple avoids that. This is a similar rationale to why Linux sticks to C. High level programming languages are not worse, they are potentially better but they introduce more complexity which means potential problems. And they have started looking at Rust now since they consider the “higher level” approach might be getting ready to take over. Likewise, we can do the same with payment channel networks.

A-R1-R2-B. Then what? A can’t pay anyone else until he receives money from someone.

This is called running out of money. If your bank account has suddenly lost all money because you spent it, you have to go out and earn money. But yes, they can receive that from anyone else or top up their channel.

Latest idea on how to more simply coordinate 3-hop payment:

HDLC, “hash deposit lock contract”. With “staggered deposit”. The “abort” decision enforced by a deposit rather than timeout. The decision is centralized (at each hop) to the recipient side. And each, that peer deposits as much as all previous hops combined. The HDLC is only used for the first two hops, so the exponential deposit increase only reaches 3X, and the peer who deposits that is completely in control and can abort at any time. Then at the last hop, it is just a normal HTLC. This approach avoids the chained timeouts which brings with it problems (that are solvable with “chunked timeout” and my 3-phase commit but it adds a lot of complexity). As you see, this staggered deposit approach solves the problem my first deposit idea had (and in between I considered majority vote instead, but now found how to get the “HDLC” to work).

[bipedaljoe]

Multisig HTLC easier. “Party A promises X to Party B, claimable if a 3-sig on agreement R is published in the commit register prior to timestamp T”. Easy on Ethereum. Not sure on BCH/BTC/BSV. Did not understand “commit register” idea until now (that it enforces cooperation off-chain rather than requiring publishing the proof each payment) but my main interest is p2p and there the chained timeouts are necessary (and therefore “chunked timeouts”). Edit: actually no multisig needed, it’s just the old commit register idea (from 2010 or earlier at last) of publishing the preimage on-chain. Edit: The depoit idea does seem good for the novation. ABC, B->A->C->B “prepare”, both peers in pair lock X amount, only creditor can abort (deposit enforces abort). Then, majority vote with a 2-of-3 preimage hash lock. Any “promise” needs two of the three preimages to be valid. How these are exchanged is arbitrary, an attack requires 2-vs-1 and 1 of attackers will hurt themselves by doing so. Edit: hm has to be 3-of-3 “vote”.

[bipedaljoe]

Does this add up to you game theoretically BitcoinAutist? It seems it works with 3 nodes, but not more. This was one of the ideas with the “dumber” approach, that it might allow simpler/dumber mechanisms at all levels.