pull down to refresh
In that thread I get into the incentives of Lightning implementations being different than on L1, I see no escape from this at present.
Every Lightning implementation serves its creators as distribution or scaffolding for other services, which isn't the case with alt-L1 implementations.
- LND for example has a suite of stuff that hooks into it like Loop, TapAss etc.
- Eclair itself is part of Phoenix's own LSP offerings
- CLN is a part of the Greenlight service
- LDK likewise is doing something similar to greenlight with "serverless" nodes and thinclients for CashApp's centralized exchange
So these aren't keeping consensus monoculture in-check like an L1 imp would, nor are they strictly being used as libraries to enable purpose-driven shells.
This delivery of ancillary services is a mal-incentive, as we've seen with hostile specs like Bolt12, where the minor and largely irrelevant implementations must dilute the protocol with trash in effort to gain share.
What a minor implementation needs to do to thrive is be purpose driven, "in Rust" is not purpose, bundling an LSP is not purpose, experimental new features should be a fork of the prevailing implementation, and challenging monoculture should be an LND-derived library. None of the minors have a clear stand-alone purpose.
If I had unlimited resources to shepherd an alt, it's purpose would be to decouple implementation from services. That would be a fork of LND that strips it down the essentials, making it both compatible with the network, and more flexible for ancillary services to build on. Once that kernel of sorts is functional, only then would I port to other languages with the sole emphasis being compatibility with what's prevailing regardless of the specs.
LDK does at least pays lip-service to this library model, which is good, but it's scope beyond that makes it ineffective at doing so. Complete re-imp in Rust is a disaster, and so they still try to influence LND to make their shit work. The NGO behind it is hostile, and the services they build on top of it are the ultimately dictate of roadmap. They're not simply making a better or more versatile implementation.
gotcha, staring point is the wrong one. Your approach make sense and I guess could provide much more value to other developers and engineers coming form outside-bitcoin spaces.
Interesting is your take on the incentive structures here. What would count as a "real" standalone purpose though? Would something like "optimized for embedded systems" or "hardened against specific attack vectors" be enough, or is that still too vague?
Where you'd draw that line?
What would count as a "real" standalone purpose though?
I think philosophical adherence to the model of L1 implementations
On L1, implementations exist to enforce/comply with the same rules.
(Core's monoculture has been deviating from this principle, hense the blowback, and rising interest in consensus libraries upon which to build new distributions)
On LN, implementations exists to capture users into an ecosystem of liquidity infrastructure and routing flows, hense protocol pollution and compatibility issues.
So the purpose of something new needs to be that its vertically neutral and consensus driven, therefore reusable into disparate distributions. Hardened surfaces or embedded use-cases are too specific, both would ideally be unique distributions of the same implementation.
I think CLN missed an opportunity here as they were on the scene at roughly the same time of LND, and the plug-in model was aligned to re-usability. LND hadn't built out its larger ecosystem yet, it just out-executed by being more developer friendly and active. I think the choice of C was a bad one as its hard to approach, Go was easier to build a network effect of community developers with. Blockstream was also never all-in on Lightning, they're primarily a Liquid shop.
It's LND's success in gaining overwhelming share enabled the larger ecosystem that its now optimizing for, though that was probably always the sustainability model. The problem with a new implementation, or a fork of LND, is it basically has to have no sustainability model.
True, building on top of the giants shoulders is always safer. But in this case how from your perspective, smaller implementations like LDK can thrive?