612 sats \ 8 replies \ @TonyGiorgio 8 Jun 2023 \ on: A discussion about layers bitcoin
I'm still excited about the improvements to Lightning to come. Splicing will be game changer for user experience, and async payments ("offline receives") as well. Hopefully later this year.
Fedimint for ease of onboarding should be pretty powerful too.
wen eltoo?
reply
I'm not holding my breath or getting excited about anything that requires a soft fork. It's hard enough waiting for things that could be done today to actually hit the market.
reply
Two weeks ago, in a episode of the @kr show, Maxim Orlovsky (not sure if he is on SN) mentioned why he thinks "Lightning takes so long to adopt all the new things".
We've been for ages talking about channel splits; about channel factories. And they are kind of happening but still they haven't happened for the last 3 or 4 years. Things like Lightning offers (BOLT12) or messaging in Lightning network like they one used by Sphinx chat, they are being discussed to be merged as a standard for already more than 2 years. This all takes longer than the Taproot itself in Bitcoin. The Lightning network which is not a consensus layer network so it can evolve, it doesn't require to be ossified. The Lightning network which was created with an idea of being reckless, quickly in the ???, iterate, experiment even not being afraid of failing, it ended up being more ossified than Bitcoin layer one. That is the funny part. And one of the reasons for that is the way how the standards are structured and how the governance over these strong standards are made.
What do you think about this?
Link: (Timestamp: 10:23)
reply
There's some truth to that. My opinion:
There's tons of competing priorities with those mostly* in charge of maintaining the popular lightning implementations. And part of that is normal maintance, improvements on existing features, bug fixes, and non-protocol related features. Normal stuff you'd find anywhere, not to mention many other priorities not directly related to the specific lightning implementation. Like supporting services like Loop/Terminal (lnd), greenlight (cln), and phoenix (eclar). There's existing stuff with existing users to support at a pretty large scale as lightning is already.
It's not about ossifying, nobody wants that and they all improve things on the protocol level at the pace they can support, taking into consideration their level of interests in any few of the many enhancements that exist.
One of the exciting things about LDK's role in this is that they at least can take a step back and not have to maintain user-side binaries. Libraries focused on the protocol work and leave user support to developers. There might be some trade offs but I think in general it's the right approach letting protocol experts in this space focus on protocols, especially if that's where they find the most enjoyment. It's such a gift to have them and for them to excel in that area, and I think we'll see some great protocol enhancements we've been waiting for come out of it soon.
reply
Well said. Thanks for this great explanation. As always.
reply
Which is why I'm so excited about Hierarchical channels. It's a proposal that could add channel factories/multiparty channels without a soft-fork, while still keeping penalty transactions (unlike LN-symetry on eltoo).
reply
now it's "LN Symmetry"
reply
Ah so there's one thing that changed about it in the last 5 years
reply