1408 sats \ 7 replies \ @0330830bf9 17 Sep 2023 \ on: SLP513 Next Generation Lightning with Phoenix – Bastien Teinturier bitcoin
Mobile nodes, Bolt12, Splicing, and Gossip-based Apps like Liquidity Ads are some of the biggest counter-signals in Lightning right now.
It's the first item that created all the other bad ideas, the high time-preference notion that mobile device nodes are a viable solution. ACINQ unfortunately got themselves pot-committed to this silliness.
Instead of biting the bullet and tackling remote-node incentives and UX, these never-ending Rube Goldberg proposals have given many the impression there is no hope for Lightning.
The absolute state of mobile node maxi's:
- Re-inventing the utterly broken and useless Tor via Bolt12
- Bear-tech like splicing, the primary use-case of which is shrinking channels because their mobile LSP's aren't sustainable
- And abusing the gossip protocol with garbage like Liquidity Ads, because using nostr or other web tech might force them to pivot to using Lightning correctly as web money.
- All while letting Apple/Google exfiltrate everything the intel agencies need to PWN the network
The real future of Lightning is Nostr based offers, connections, accounts, and zero-configuration networking... directly to webapps and wallets... re-decentralized to better performing remote nodes run by Uncle Jim.
If you don't like what ACINQ is doing, you can always participate in or support the companies and projects that do what you want :)
reply
Very insightful, what makes you think I don't?
reply
There is a tendency in both of Bitcoin’s official layers to avoid relying on external dependencies not limited to but including the web. You make it seem like a childish position to hold though. For money, might it be desirable to avoid inheriting the threat model of less threat-conscious systems?
reply
That makes sense with the money protocols themselves, but the things mentioned above are applications over the money layer, not money protocols.
There is rightly a chorus of shriek when people propose doing things on Bitcoin that should be done at other/higher layers, the famous "you don't need a blockchain for that".
The analog here is, you don't need to bloat Lightning for that.
The web is the standard for applications, with its threats well-known and largely accustomed to and mitigated. It's also unavoidable, as in for all of Bitcoin's security efforts I would wager most nodes have implicit trust somewhere along the line of an SSL cert.
Nostr is an ideal application layer, it takes web commodities and makes them more ad-hoc network friendly with with relays and keys. Putting applications here is not only like practicing good QoS, it's simply meeting the world we want to get onboarded where they are: the web.
reply
When stated plainly, your broad point is fair.
What you're proposing and what you oppose aren't mutually exclusive though afaict. The best Rube Goldberg machine will win. It seems worthwhile for us to try building both. One could argue each existing meaningfully informs the design of the other and I'd predict we end up with a hybrid of the competing systems.
reply
I think you're right as a technical matter, but in networks it goes beyond tech into narratives, optics, and their effects on people. As such, and combined with several personal anecdotes, I see these proposals and the entities behind them as hostile to the mission.
The principles here so different that they repel each other. Maybe you're right in that's positive entropy, as order comes out of chaos. It has it's made me prioritize a protest build.
But on the other hand, it's disrupting momentum elsewhere. And these self-congratulating, self-annointed experts, projecting a consensus of the future of Lightning must be met with overwhelming resistance if we're to benefit from competition.
reply
The proposals are competing for scarce resources on some level for sure.
I think the principles are different because the winning principles are yet unknown.
If the side you oppose is competing unfairly, that sucks and I hope it changes.
reply