pull down to refresh
17 sats \ 3 replies \ @k00b OP 13h \ parent \ on: Lightning payment probing behavior is implementation dependent lightning
I agree, but they're both fruit which is about as much as I was saying.
You mean peers interact with each other more often and directly in lightning therefore L1 is relatively noninteractive, right? If you mean something else, I need help because I wouldn't say that L1 "isn't" interactive.
It's probably at least a minor disaster for miners and economic nodes running the minority implementation in a fork. I agree the network could cope though.
Would these accidental forks be more common with a plurality of implementations? If so, wouldn't that be enough to create a network effect that defaults the network to one implementation?
Would the framing of L1 is asynchronous where L2 is synchronous help? Or broadcast/unicast?
If you wanted, you go as far as signing a transaction to miners via carrier pidgeon, since there's not any sort liveness or quorum inherent to that communication.
Even miners which do need to stay online to function are dealing only in broadcast traffic, and implementation chooses only to listen and shout correctly, having no implications on its peers.
Even a minor implementation mining a block out of spec (shout correctly) would have that block rejected, with the user having their tx mined in that block remaining unaffected as it would still be mined in both forks, all without any handshake happening first.
nodes running the minority implementation
In Lightning it effects all nodes if its size-able enough to cascade given the interconnected-ness of the network, not necessarily just those running the breaching implementation as would be the case in an L1 situation.
Would these accidental forks be more common with a plurality of implementations?
Likely, the trade-off of that being more isolation. Better to have 10x more fork issues at 1/10th the size, like forest fires, controlled burns prevent uncontrolled ones.
90% of the network running one distribution is a risk even with its own prior versions, new version can quickly become a large share of the network just given that distributions overwhelming share.
If so, wouldn't that be enough to create a network effect that defaults the network to one implementation?
That's the effectively case now, I'd expect it to remain so. However, it would demarcate implementation from distribution, which is more important given how a large break on either layer likely has to come in the form of an "update".
Archiving Core would decentralize that distribution, but not necessarily the consensus code, since replacement distributions would largely be forks of it.
Any changes to consensus code, or new/ported implementations, would then be either graceful or ungraceful based on its ability to gain distribution first. The more likely it is to break something, the less likely it is to be widely distributed.
The result of that would I think inevitably become library-ification, and a lexicon shift to Bitcoin distributions rather than Bitcoin implementations. To further analogize to Linux, the equivalent to consensus code there is the hardware.
BTCD has shown this is possible, its a differing implementation with a solid track record of "just working", yet the majority of its users use it as a Library (LND). Libbitcoin literally intends to be a library.
reply
I get your definition of interactivity now. I sense there's something generalizable there that might help me reason about systems better. Like, what can we say about highly interactive systems that isn't true of less interactive systems and vice versa?
In Lightning it effects all nodes if its size-able enough to cascade given the interconnected-ness of the network, not necessarily just those running the breaching implementation as would be the case in an L1 situation.
tbh I haven't given this much thought nor interactivity vs interconnectedness vs consensus. I think I've underappreciated the risks of having different lightning implementations at the very least.
The result of that would I think inevitably become library-ification, and a lexicon shift to Bitcoin distributions rather than Bitcoin implementations. To further analogize to Linux, the equivalent to consensus code there is the hardware.
That certainly seems like a direction we're heading in - more modularization. Even with consensus code isolated and safe from accidental forks, I suspect we'll never break free of a dominant distribution. There are too many network effects at play. Switching costs would be lower which should yield more diversity than we have now at least.
reply
something generalizable
mutual dependency vs. one-way dependency maybe, participant behavior vs. environment behavior, relationships vs. language
the risks of having different lightning implementations
Yea I think its a bit of a paradox, everyone has taken for granted that its less risky on the L2 because the L1 is what's notoriously consensus driven... ignoring that its a loose-consensus on L2 that's inherently more fragile
Incentives are likely a factor in this narrative remaining undisputed, there's service layers to offer in L2 stacks that influence the implementations, there's not really any services that coupled closely to the L1. The Lightning implementations are all very modular, the bolts necessitate it, yet they all ship as part of value-added ecosystems (even if they're optional)
we'll never break free of a dominant distribution
Likely, but even Debian, RedHat, Arch and their children is more distributed than Bitcoin is at this stage.... all generally dividing up the same hardware.
My issue with Core is that, due to its legacy, very few even think about distribution and are never forced to make a decision. That default distribution had made it a politburo more than it is an implementation, leaving both ossifists and expressionists dissatisfied.
Archiving it would at least shake that up, even if it was a 1:1 Team/NGO migration to a new repo under a new name achieving a similar share of update distribution, Core loyalists would stand to benefit the most in affirming such a mandate.
This has become apparent with the Nostr NIP's repo already too, the repo is a politburo for the distribution channel that is nostr-tools and dictates by default how any number of things are done. This despite really only a handful of the NIP's resembling a level of network-wide consensus.
reply