As a friendly reminder, we start to pile up a very serious stack of security risks: pinnings, channel jamming, replacement cycling, time dilation (all those ones could kill lightning if exploited at scale - period) and more minor ones such as dust HTLC exposure, fee or liquidity griefing and other denial-of-service.
Hard things about hard things, every new major security risk discovered somehow constrains lightning developers to go back on the whiteboard and check that any mitigation in development for each risk is not broken or the security properties with. Most of the time, we might think in isolation to ease the mitigation of research and development work. Astute adversaries might not give us those flowers. At the end, technical reality advises that lightning security issues are better solved at the base-layer, and this is where expert time is cruelly missing to make lightning more robust on the very long-term.
Security of critical software systems is somehow akin to medical practice. If you wish to nurture an adequate clinical treatment, you have to get the diagnosis of the illness severity first, even if it's a painful truth for the patient. In my opinion, here the patient is the community of lightning node operators and lightning users, and if we wish for an adequate technical treatment to overcome the vulnerability severity, building consensus on the severity sounds a necessary step.
He seems to view the LN as being in far greater danger than others in the space. I wonder at the disconnect? One thing that occurs to me is that there might be a difference vulnerabilities with LN as it exists in practice (quite highly centralized; few people running nodes; custodial solutions dominate) vs LN as it could exist in theory. In practice, major players could collude to ensure that this risks are not really risks. But in the desired decentralized alternate reality, perhaps they render LN non-viable.
Anyway, I appreciate people who aren't afraid to raise hard truths. I do not believe in killing the messenger, even if the messenger might have his own issues.
One thing that occurs to me is that there might be a difference vulnerabilities with LN as it exists in practice (quite highly centralized; few people running nodes; custodial solutions dominate) vs LN as it could exist in theory.
That's definitely a recurring theme.1 Most protocol people will tell you (not on their websites or loudly in public) that you probably shouldn't be opening lightning channels to untrusted nodes. They've done their best to minimize the risks of certain low-medium probability attacks but they have not neutralized them.
The ideal requires trustlessness. The reality is Block and many of the other big players are establishing channels only after forming legal contracts with their channel partners.2 Others have designed their infrastructure in such a way that, for their use case at least, they've solved the risks inherent in the protocol.
Lightning before or after Antoine's disclosure is not a perfectly trustless scaling solution.
To be the cynic ...
It's an occupational hazard but I tend to weight opinions by the opinion holder's incentives/history. Fact is lightning companies (many of which are approaching late stages) have incentives to minimize bad news. Even bitcoiners broadly have incentives to minimize bad news about our primary scaling solution.3 I'm not saying that they are meaningfully minimizing bad news here, but there is undoubtably at least some low velocity PR spin going on.
Footnotes
You're describing the cause of most disconnects when discussing product IME. Opinion holders all have an opinion on product quality Q but Q is expected to change at some time t in the future where Q(t) is probably a sigmoid. I've found that when earnest people disagree unproductively on Q, they are usually holding a different t. ↩
Not exclusively for theft prevention I imagine, but they undoubtably have clauses about that. ↩
I'm included in this group. I'm weary of even myself. ↩
The ideal requires trustlessness. The reality is Block and many of the other big players are establishing channels only after forming legal contracts with their channel partners.2 Others have designed their infrastructure in such a way that, for their use case at least, they've solved the risks inherent in the protocol.
This point is so interesting! I'd never considered it in this way, but it makes sense, and is consistent w/ everything I know about reality and how systems change. Whatever btc is or becomes will be tied with a million tiny threads into what exists now. These LN operators can make legally-binding contracts, and that is useful in certain ways, so of course they do, and in this fashion the system morphs into something even more complex and layered, with its own virtues and vulnerabilities.
It has never been the case, in anything I'm aware of, where the existing thing, no matter how corrupt, just got shit-canned, and you started fresh. Not after the fall of Rome, not after the nuking of Japan. The new is built on the rotting flesh of the old. It's so hard to think clearly about this, and yet it's right there, in the open, dominating everything.
Footnotes
QbutQis expected to change at some timetin the future whereQ(t)is probably a sigmoid. I've found that when earnest people disagree unproductively onQ, they are usually holding a differentt. ↩