Reimagining Onion Messages as an Overlay Layer \ stacker news ~lightning

pull down to refresh

Reimagining Onion Messages as an Overlay Layer delvingbitcoin.org/t/reimagining-onion-messages-as-an-overlay-layer/1799

1613 sats \ 3 comments \ @k00b 18h lightning

Roasbeef proposes decoupling the onion messaging graph and the channel graph. afaik what we do now is send onion messages over the channel graph even though they aren't payments. Also, your ability to use some onion messaging features requires payment paths to your "contacts" upgrade else you need to connect directly to "contacts" or find new channel partners (which is expensive). Unless we intend to charge a sybil fee for non-payment onion messages, there's no reason we need to use the channel graph. I suspect these weren't decoupled sooner for that reason, but we also haven't seen sybil fees for non-payment messages emerge yet.

Roasbeef points out that there are many advantages to decoupling:

separation, and independent evolution, of concerns/services
onion messages won't compete with peer gossip and channel updates
adoption can be low on the onion messaging overlay yet still serve its purpose better than overloading the channel graph (which is established without considering onion messaging features)

I like it - so long as it won't need payments for sybil resistance. On that point, it may be less sybil resistant because anyone DoSing you with onion messages now is a channel peer afaik and has something to lose.

view all related items

50 sats \ 0 replies \ @justin_shocknet 5h

I’m disheartened to see mental cycles as valuable as yours Mr. Beef being used on something like this, onion messages are a terrible thing and beyond saving.

As I have long warned and been vindicated, each hop inherently increases latency and failure probability. This makes OM’s unfit for communication in areas where high reliability and performance are paramount, like payments. Bolt12 has no future because of this.

Anyone who has used Tor can attest to the fact there is no production value to OM’s. To the extent OM’s work on Lightning even conceptually is due only to the nature of the network being a defacto bonding apparatus, any further decoupling from that can only make reliability worse.

Now, Lightning would absolutely benefit from a better overlay network for communication, but that is almost unanimously Nostr. Concerns are properly separated, web comportability allows deprecation of things like LNURL, and identity can be either leveraged trivially or entirely de-coupled based on the use-case.

Better protocols like we’re developing with CLINK solve the node-to-app coordination problem without the unreliable p2p topology. The preceding link demonstrates Nostr static payment offers that retrieve bolt11 invoices from a simple static web page without wasm, and there are also specs for the reverse flow (debits) and a draft for remote management of static offers (app manages offers on a remote node).

https://delvingbitcoin.org/t/reimagining-onion-messages-as-an-overlay-layer/1799/2?u=shocknet_justin

17 sats \ 1 reply \ @k00b OP 18h

If I wasn't sure I'm an idiot I'd post this on delving:

If I require a channel with you to send onion messages to/through you, I have something to lose should I do it too much. afaict There's a weak but non-zero sybil resistance to onion messaging as is.

What mechanisms for sybil resistance will this overlay have? It'd be easy enough to require presence on the channel graph, but if I don't have a channel with you, how will you punish me? Personal banlist/reputations? A gossiped banlist/reputation? PoW? Payments? Some combination?

10 sats \ 0 replies \ @justin_shocknet 4h

I don't see anything retarded with this follow-up, except from the obvious answer which is that onion messages themselves are retarded. The ending of his post hand-waves that permissionless innovation will solve the "last 20%" and fact it sucks.

Poast.