pull down to refresh
17 sats \ 1 reply \ @k00b OP 13h \ parent \ on: Lightning payment probing behavior is implementation dependent lightning
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?
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.
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.
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