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.







