pull down to refresh
153 sats \ 3 replies \ @dusty OP 19 Aug 2022 \ parent \ on: Dusty Daemon | Core Lightning dev & splicing implementer | AMA bitcoin
I think the process is the right level of difficulty at the moment.
At its core the protocol is really defined by what features nodes have & enable, negotiated between two of them.
The spec process doesn’t really have control over that, it’s more of a coordination effort that provides a place for the Lightning developers to both establish interoperability and also get vital feedback from each other.
Since we’re coding money itself that feedback process is great for revealing potential problems early on that one person may be more equipped to understand than another.
It also functions as a blue print for future Lightning implementations and I think that’s important in its own right.
what kinds of problems might a future LN node implementation solve that the existing implementations can’t or won’t solve?
reply
Hm that’s an interesting question and kind of hard to speculate on. Before LDK came along I didn’t think an enterprise-first style implementation would exist and now we have one of those with phantom nodes and other cool scale based features.
I think pretty highly of the existing Lightning devs out there. If they won’t add a particular feature I suspect there would probably be a good reason for not doing it.
In the near term it does feel like there is just a ton to be done and too few to do it all. But perhaps one day lightning will ossify and we’ll look be able to look back and say oh hey it’s done.
I don’t see a day like that coming anytime soon though.
One area Lightning devs aren’t working on is automated channel management and rebalancing and I do suspect that area will see some pretty awesome innovation over time. If that progress well, and I suspect it will, we’ll eventually have one button lightning node deployments that just do everything for you automatically.
reply
appreciate the insight, thanks!
reply