Thanks! Unfortunately the video only covers the case of 1 channel, and I'm assuming the two nodes are relatively close to each other (the majority of payments are settling in <= 0.05 seconds). With just a single payment channel you don't need to create an HTLC either AFAICT (because you're just updating the balance of this one channel). Unfortunately this is not quite as rigorous as I was hoping for. My latency to one of my channel peers alone is around 200 milliseconds (can you tell I have bad internet?), that's not accounting for the latency of that peer to their peer, and so on (until the final destination).
My concern is when hundreds of thousands/millions of people are routing payments, and those HTLCs take around a few hundred milliseconds to settle each
My concern is when hundreds of thousands/millions of people are routing payments.
You have a wrong perspective of how LN payments are done. NOT everybody will "route" payments. ONLY LSPs and public nodes that are running routing nodes will literally route payments. But the majority will NOT use public routing nodes, but just private nodes (mostly mobiles). And these private nodes DO NOT route payments, just make payments.
So your concern is for nothing.
reply
I worded the comment wrong, what I meant was when users are making payments through routes.
And again, when those private nodes make payments, that still requires funds to be locked up across the route until the payment is considered completed and the HTLCs are consolidated, which is what my post is concerned about
reply
You are worried too much for nothing. You also do not take in consideration other aspects:
  • in the Bitcoin standard, people will spend less, only when they really need it. That means less transactions (compared with other payment networks).
  • BTC and LN will always improve. We are just being starting, is too early right now, LN is only 4 years old, is just a small kid, barely starting to walk.
reply