An easier Lightning Network using three-party novation

I really believe the Lightning Network concept is the future, or more like Ryan Fugger’s idea of multihop payments where every user acts as an intermediary, and you could use collateral like Bitcoin or Ether in these payment channels or just rely on trust. But honestly, a simplified version could also be valuable pretty soon. There's this lesser-known process called three-party novation, which allows a decentralized system (in terms of computing) to function like a centralized one. It flips the typical centralized model. Instead of every node connecting to a common intermediary, they can connect directly to each other and compute results that are equivalent. So, how the three-party novation works is this: if a node has both incoming and outgoing debts, it checks if the node with incoming debt can pay directly to the node with outgoing debt. This is kinda what banks do as central intermediaries, but we’re doing it in a decentralized way. Plus, since every "router" in this setup has a payment channel with Bitcoin, there’s no room for lies. You’d have a 2-tier network where users hold their "router" and a payment channel with it, then those routers can connect to any other router in just one hop, and then reach the user. So, that’s three hops total. The full-blown Lightning Network definitely outshines this, but it’s way more complicated. I tackled the coordination issue with a 3-phase commit (check my earlier posts), but getting everyone worldwide to run their own node is tough with the current IP address system (I think the next big step is geographical IP addresses) and making it all work.

I don't know why there isn't much discussion about the Lightning Network on this forum. Is it because the current Lightning Network is too complex? Or is it that Bitcoin payments aren't the focus, and the focus is still on Bitcoin's appreciation potential?

Don't ask - do it yourself and start a thread if there isn't the one you are looking for, pal.

The payment coordination Lightning Network uses is the one invented by Ryan Fugger in 2003 (LN is his Ripple with "collateral" on top). It was never secure. Ryan had the right idea in 2006 ("chunked penalty") but it could not be done on his "cancel-on-timeout" 2-phase commit. It requires a more advanced 3-phase commit which was invented last year, see here. The idea I describe is the simpler paradigm. It is "singlehop clearing" in terms of trust as opposed to Ripple/LN which is "multihop clearing" in terms of trust (although Ripple/LN was typically assuming the multihop payments themselves are sufficient to clear asymmetric payment loops). I put together an over view of it here. I show how chained timeouts are not needed when it is just always 3-hops. Overall it is much simpler system, but still enough to scale to infinite capacity (it is a bit more centralized in terms of control is the issue, but speed it will have). Can work on real LN in parallel too.

Why that tone? The question he asked is good and valid, and as my response shows, there is a very logical answer to it. People often shy away from questions and answers and stick to mediocrity ("don't ask") but those who dare to ask questions will see a bit further.

A bit late to the party on the old "commit register" idea, “Party A promises X to Party B, claimable if a preimage to hash H is published in the commit register prior to timestamp T”, it seems it would work perfectly for any-hop payment channels.

An update on what to me seems ideal to coordinate the novation (and, note the "novation network" can exist as its own thing first, and you can place the second tier under it to serve 10 billion people later): Majority vote hash lock. Works with 3 node payments, tend to collapse with more. But here only 3 nodes. The hash lock has 3+1+3 preimages. Majority vote to either abort or commit (standard way to do things), i.e., 3+3, then a "pre-commit" preimage to initiate the commit vote (the process is a sort of 3-phase commit). Besides debtor lock X amount to transfer, creditor also locks - enforces cooperation (to abort specifically, replaces what a timeout usually does). Debtor can commit at any time, creditor abort at any time (majority vote abort is for situations where creditor is deterred from aborting, i.e., when they have already forwarded "prepare" to the next hop). All nodes first agree to "prepare" (sign promises that hash lock key will enforce on-chain) and vote. Then, the person who would lose if the vote was done before everyone was ready releases "pre-commit" preimage (the initiator of the novation... in ABC debt, it would be B who did prepare as BACB). Commit majority vote wins over abort majority vote (but needs pre-commit preimage), abort majority vote does not need pre-commit preimage (but can work with it too, it does not matter, it is not used to evaluate it). This may seem complex, but it is socially easy to coordinate. Never any timeouts to take into consideration. Everyone is just incentivized to always do the cooperative thing.

The collapse point *is* the whole issue here, and you're hand-waving past it. Technically, a three-node majority system is trivial. You've got a 2-of-3 abort/commit. The second you scale to five nodes, you need 3-of-5. Now your hash lock needs 5+1+5 preimages..(yes or no). The communication complexity isn't linear, it's combinatorial. Every new participant adds a new dimension to the state space that everyone else has to validate. Your 'pre-commit' phase becomes a bottleneck where one offline node freezes all the capital. Compare that to Lightning's penalty model: complexity is pushed to the individual channel. A node only monitors its direct peers, not an entire consortium. Your model reintroduces the consensus problem Bitcoin solves on-chain, but off-chain, without proof-of-work finality. It's a distributed systems "nightmare". Lightning uses HTLCs for routing because it's a *unilateral* guarantee. If you have the preimage, you claim the funds. No voting. No waiting too.. Your model needs synchronous agreement, which is a far harder, and arguably unsolvable, problem in an async network.

I'm not hand-waving anything, I'm describing a "novation network" with at most 3 nodes per agreement, and how that allows a much simpler coordination. I am stating this does not work for longer payment chains. This is the whole point. To build a simpler scaling system, payment channel network, first or as alternative to the more advanced. For N-hop payments, "commit register" idea from old Ripple source forge email list works great but requires state all accounts can interact with, so, Ethereum paradigm, and then for "chained timeout" approach (which is necessary p2p, but not with central ledger "court" as fallback) those require "chunked timeouts" which means you need penalty on all phases (and the "cancel-on-timeout" 2-phase commit Ryan Fugger  used since 2005, which Lightning Network built on, only has on second phase, thus Ryan could never achieve "chunked timeout" even though he wanted to in 2006). The ideal "chained timeout" is as below. You are simply lying that I am "hand-waving" anything and anyone can verify that.