maintaining a perfect and complete connectivity graph - hard.

maintaining imperfect and incomplete connectivity graph - much less hard.

be careful, maybe you're invested into something that becomes irrelevant if LN works, in which case you might want to be less rigid in your thinking and follow the developments more closely to pull out or risk losing your investment. because LN already works: tens of thousands of nodes and channels, millions of dollars in the network and growing at healthy rates.

And the bigger the network are and the more transactions there are, the more important a complete connectivity graph is, and the more failed transfers you will get if you have an inaccurate graph. However, the bigger the network is, the harder it is to actually gather an accurate graph.

Thus, it doesn't scale.

> Thus, it doesn't scale

you're wrong for two reasons:

- hubs do exist (big and small) and can exchange connectivity information more efficiently (and take fees for that service), so the network isn't growing like a full mesh (that is indeed very hard to maintain connectivity graph of) but rather as a collection of interconnected smaller meshes

- payments can be split up into smaller chunks that follow different paths and are executed atomically (either all or none), and if some chunks fail you can retry them within the same payment context

So in the first case, as I said, it can work with a few giant hubs. In the second case, it just progressively works worse and worse. Doing multiple routes atomically just gives you more reasons a single payment can fail.

> as I said, it can work with a few giant hubs

right, there will definitely be huge hubs. what you didn't even try to demonstrate is why can't there be smaller hubs?

> it just progressively works worse and worse. Doing multiple routes atomically just gives you more reasons a single payment can fail.

no, exactly the opposite is true. in case with single payment for X satoshi you need to re-try it multiple times until you find a route that has X capacity on every hop. with atomic multipath payments you need to find N routes that support X/N capacity (much easier) and if any number of those fail you can retry only those failed parts, so after 2-3 iterations your entire payment succeeds.

But again, at actual scale, there is no guarantee that the transactions that worked on your previous attempt will work on the next one, because lots of other people will also be attempting to use them.

when you run multipath payment, each chunk that succeeds locks that capacity for some time until you figure out rest of the chunks. and since each chunk is tiny, the chance that all of them succeed on first try is actually quite large.

So you can DoS the network by spamming it with transactions that are set up to fail and lock up large sums of money?

Maybe you are right that I do not know enough about the Lightning network, because I was not aware there was a vulnerability that big and easy to exploit built into it.

well i'm glad you've conceded all the ground from "it's unsolvable comp sci problem" up until "but one can DoS the tiny payments by spamming". i've covered a mile, you're still fighting for inches, i think that's enough for me. cheers, i'm glad you learned a lot about lightning today!

p.s. i'm sure you can google about DoS attacks on lightning and how to deal with them yourself

No, it's still an unsolvable problem. But it seems a kludge has been added that makes the damage a tiny bit smaller, and also introduces a massive vulnerability, so I wouldn't exactly call that a win.