pull down to refresh
43 sats \ 7 replies \ @ek 20 Oct 2023 \ on: Large lightning vulnerability concern bitcoin
Mhh, very interesting and I get the dilemma.
Can't easily convince people who support ossification like @jimmysong (/cc @nerd2ninja) (for valid reasons!) about soft forks.
But explaining in detail why we need a soft fork to fix a vulnerability effectively discloses the vulnerability before it's fixed.
But explaining in detail why we need a soft fork to fix a vulnerability effectively discloses the vulnerability before it's fixed.
This is one reason we have layered systems. If Lightning devs have in fact screwed up, better that Bitcoin continues operating while Lightning figures out how to fix things with full disclosure and many competent people understanding the issue.
Right now, Antoine hasn't even published an easy to read explanation of what the problem actually is. He seems to have convinced a decent number of people involved in lightning development that there is an issue. But he hasn't convinced many people who aren't intimately involved with LN/BTC development. Nor is his "we're all doomed" view on it shared widely.
Anyway, there's no way this issue actually wrecks all of Lightning. You can do routing just fine through semi-trusted node relationships. It's not as decentralized as we want. But even in the worst case a large proportion of usage of lightning will work fine.
reply
You can do routing just fine through semi-trusted node relationships
I agree, that is what I understand from the write up (https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf).
An amateur node operator (one who has not already put in place some of the mitigation options) might want to review what channels they currently have open and may not want to accept new channels. Depending on there risk profile.
reply
From the very beginning, I always saw the Lightning layer as a replacement for the bank layer in the fiat system. Banks can and should have selected, trusted relationships with each other. Operating a Lightning node, I have always been frustrated with the assumption that a node operator wants to network willy nilly in a trustless world. I want to choose my channels wisely, not entirely trustlessly, and in my opinion the tooling for that is poor at present, (although admittedly I haven't spent enough time trying all available tools).
Some argue this semi-trust tends toward centralization, but the counterargument is that anyone can start up a Lightning node to fill in the gap anytime one feels like centralization is getting out of control. We still have complete freedom.
reply
This just leads to further centralization.
reply
I know I was only cc'd, but I want to make it clear that I don't necessarily support ossification. I know and respect the process of upgrades, of communicating to everyone involved to get on board, and to spend years on explanations, demo's, and pentesting on test networks. I currently like CTV and APO for example.
reply
Oh didn't mean to make it look like that
I CC'd you because you made me aware of @jimmysong's note on nostr where he mentioned he supports ossification and you mentioned you disagreed :)
reply
Interesting point
reply