Great interview on the What Bitcoin Did podcast:
https://www.whatbitcoindid.com/podcast/peter-rizuns-lightning-critique-fud-or-fairI assume a number of you will summarily dismiss this, rushing to judgement before examining the evidence. But for the open-minded, certainly worth a listen.
I am truly looking forward to the necessitated responses from the LN-faithful. Well, to the extent that such responses be substantive. If this conversation carries forward in a respectful manner, we may
all learn a thing or two.
edit: Incidentally, this has been 'Lightning Month' on What Bitcoin Did. Quite a few good installments, each focusing on a different aspect of Lightning.
https://stephanlivera.com/episode/68Joost Jager, Lightning Network Infrastructure Engineer at Lightning Labs, joins me in this episode to talk about Lightning Loop Out and In. We also discuss some of the recent criticisms of the Lightning Network by Peter Rizun. We talk:
How Lightning Loop helps you manage inbound liquidity, or pay with BTC on chain to get outgoing capacity on a lightning channel
Practical uses of Lightning Loop technology
Some of the technicals behind how Lightning Loop works e.g. hodlinvoice
Thoughts and responses to Peter Rizun’s criticisms of the Lightning Network
Cool. Thanks. Will listen.
So I got around to listening to the Stephan Livera podcast featuring Joost Jager. If this is what serves as comprehensive rebuttal to Rizun’s points, you might want to start worrying about the efficacy of LN. Of course, this is just response from a single LN dev, who may not have prepared to discuss Rizun’s ‘Five Fundamental Flaws of LN’. The first half of the interview covered Jager’s work on loop in/out.
For the record, the following is my restatement as best I concisely can of Rizun’s ‘Five Fundamental Flaws of LN’:
1) Lightning scales txs not users
2) Friction in layer 1 leaks into layer 2
3) Routing failures are inevitable
4) Much trapped liquidity in the system
5) Running a non-custodial wallet is more cumbersome than onchain
And the following is my brief capture of the points made by host and guest on these points. These are very brief - I would suggest listening to the podcast yourself to get the full flavor. The numbers on each point correspond to my impression which of Rizun’s FFFoLN are being referred to. YEs, these are sketchy outlines of their discussion. Again, listen to the podcast for in depth info devoid of my spin (which I have tried to avoid). In roughly chronological order:
SL (stating Rizun’s points):
2) variability of fees cause problems at the Lightning layer
5) drive too much custodial wallet use
JJ:
5) very true at the moment - decentralized solutions are hard - just early - lot of work to do
don’t see why fundamentally it won’t work to automate cumbersome parts
SL:
1) hard to onboard users - LN scales txs, not users - over time, not enough UTXOs for each person to be sovereign; think this can be solved via multiparty txs
JJ:
1) good problem to have
SL:
2) can’t we just wait for fees to come down?
JJ:
2) yes
SL:
2) Friction from layer 1 can cause problems on layer 1
JJ:
2) have no answer - if need to post cancel on chain at $1000 fee, that’s a problem
SL:
2) Stop and Decrypt says that fees only go up in USD value, not BTC
5) Need to be online to receive payment
JJ:
5) who is not always online?
5) permanent uptime at home, mobile client as a remote control to that server
5) maybe create some sort of mailbox which would hold payment until online
SL:
some can be solved by engineering
2) just make the retaliation window sizable
3) problem finding route with sufficient liquidity
JJ:
3) perhaps reputation can inform routing - this would increase success percentage
SL:
3) what about mobile phones needing to route? Does phone require entire graph?
JJ:
3) reputational routing might lead to many channels being private to guard reputation, this will reduce size of routing graph
3) hybrid - whitelisted/blacklisted nodes - weakens decentralization, but may work for mobile
SL:
4) trapped liquidity
4) but loop will help
JJ:
4) yes, loop can help inbound liquidity (seems to misunderstand the issue as only transactional -ed)
4) perhaps inbound liquidity may be provided at no cost
SL:
Rizun skeptical this complexity cannot be abstracted away
I think SPV is overly romanticized - holding onto UX that is infeasible in long term
JJ:
The question may be whether onchain is viable in the long term
LN is inherently complex, onchain is easier
SL:
Last thoughts?
JJ:
In general, it’s pretty early - huge fees are speculative; 4B people to use? LN solves a current problem
Would like to see a killer app that LN uniquely solves. Micro tx space would be likely as unique value.
Would like to improve payment reliability
——
All in all, as a rebuttal to Rizun’s FFFoLN, I find this unpersuasive in the extreme. While I am already a known LN skeptic, I see nothing in the above that contradicts a single one of Rizun’s points.
Perhaps I should just wait until the next contender arrives to dispel Rizun’s FFFoLN? Dunno. But as I said earlier, if all my eggs were in the Lightning basket, I be starting to get scared about now.
As you likely know, no one has any burden to rebutt Rizun. If Rizun or any other lightning hater does not like lightning, they can either not use it or go build something better.
Furthermore, all of bitcoins eggs are not in the lightning basket, so fuck off with those kinds of accusations. Bitcoin is going to continue to work, whether lightning is successful or not. Lighting network happens to be one of many developments in bitcoin, albiet lightning is a fairly BIG development in bitcoin, it is not the only thing going on in bitcoin.. it provides one option that is still being worked upon... and still seems to be in decently early stages of adoption and development.
In essence we already realize that Rizun and co, are just attempting to pump their own inferior shit that includes scaling on chain bullshit... good luck with that.