The question is not really related to onion messages but why is Lightning not using a DHT system for gossip?
Le 01/03/2023 à 19:02, Antoine Riard a écrit : > Hi Val, > > Thanks for the proposal here. About using OM for payment probing, I > think there could be an alternative of the routing hops themselves > announcing their liquidity balances with an extension or new set of > gossip messages. > > Gossips messages could commit to a liquidity balance and duration > (e.g +1000 blocks from tip), rather relying on sender-side probing, > which might be less and less accurate with higher rate of network > liquidity congestion. Additionally, a routing hop could commit to > "private" gossip sent back to HTLC senders during HTLC successful > settlement. Those "private" gossip might announce "differentiated > services" of channel liquidity levels. I believe this can be > guaranteed transparently from the rest of the network thanks to > parallel channels. > > Any deviation from the gossip message could be penalized by sender's > scoring algorithms as the liquidity SLA parameters have been announced > explicitly by the routing hops. This is just an intuition on how > public channel liquidity discovery could be worked out, and I don't > know which of the alternatives would be more efficient in terms of > bandwidth/convergence delays. > > Best, > Antoine > > Le lun. 27 févr. 2023 à 21:32, vwallace via Lightning-dev > <lightning-dev@lists.linuxfoundation.org > <mailto:lightning-dev@lists.linuxfoundation.org>> a écrit : > > Hi list! > > I wanted to bring up the idea of using onion messages for payment > probing, which was briefly touched > on at the 2022 LN summit. Tadge Dryja has also brought up a > similar idea. > > I recommend reading the gist instead since it has the relevant > diagrams in-line: > https://gist.github.com/valentinewallace/ebe1741f0438c2360eda0f80f0e075c9 > but the scheme is also > posted below for convenience. > > ## Introduction > > For context, in today’s lightning, payment reliability tends to > heavily depend on having sufficient > payment volume to determine current liquidity balances of > channels, which is how most big nodes can > tell whether a given channel has enough liquidity to forward a > given amount. If a node is using HTLC > probing to achieve this payment volume, they use a regular > `update_add_htlc` message with a bogus > payment hash, where the error returned informs the sender of > whether the payment reached the final > recipient. Note that there is a tradeoff between always routing > through nodes that are known to > rebalance their channels vs leaning on probing smaller nodes and > “risking” payments through them > based on what’s learned. > > Today’s HTLC payment probing can work well, but risks channel > liquidity being locked up if a peer > along the route goes offline. On the upside, for just-in-time > probes, it works to loosely “reserve” > the channel liquidity along the route for the actual payment. > > Onion messages (OMs) present a convenient way to probe without > risking locked liquidity along the > route. > > ## Design Rationale > > A naive approach could be to send onion message probes directly to > individual nodes along the > desired route, including those to which you don’t have a direct > channel. However, this scheme is > problematic because it would enable monitoring the payment flows > of arbitrary nodes across the > network without having to have a channel path to them. This would > be a significant degradation of > privacy because, for comparison, in HTLC probing it is quite > difficult to probe the balances of > far-off nodes. And if you can’t probe a node using HTLCs, you > can’t send over it anyway, so there’s > not a lot of benefit (and significant privacy downside). > > Therefore, it is probably best to design a scheme that probes > along channel paths, like HTLC > probing. This adds more complexity to the case where an > intermediate node cannot forward the desired > amount due to the stateless nature of OMs, discussed further down. > > ## Scheme > > Let’s go through the happy path, where Alice is probing Alice > > Bob > Carol > Dave for a 100k msat > payment. > > She’ll construct an onion message for Bob, the first hop, as such: > https://imgur.com/BZg8yt8 > > Bob receives this OM, sees that he’s able to forward 110k msats to > his next-hop Carol, and forwards > Carol’s onion packet to her. Carol sees she can forward 105k msats > to Dave, and forwards his onion > packet. Finally, Dave receives his onion packet, sees he can > receive 100k msats from Carol, and uses > the provided reply path to send a simple probe success onion > message back to Alice: > > ``` > onion_message_probe_result { > data_tlv { > type: 4242, > probe_id: [u8; 32], > can_forward_desired_amt: true, > } > .. regular OM TLVs > } > ``` > > Note that Dave will use this same onion message if he can’t > receive; he’ll just set > `can_forward_desired_amt` to false. > > As an example of the sad path for an intermediate node, if Carol > can’t forward 105k msats to Dave, > she’ll fail the probe back to Bob by sending this onion message: > https://imgur.com/a/hqlzw4I > > This step justifies why we need to encode a failure onion for each > intermediate hop of a probe. If > we hadn’t done that, and Carol responded to Bob with an empty > “failed” message, Bob would have no > idea which peer to fail the probe back to, because OMs are > stateless. Instead, Bob unwraps his error > onion and sees that he needs to fail back to Alice with her > provided error onion. Alice receives the > failure onion and can see that Carol was not able to forward the > desired amount corresponding to the > probe id, thus completing the probe. > > ## Outro > > While there is nothing stopping nodes from lying about their > ability to forward, they may be > negatively scored if they do so. Further, adopting a protocol like > this could help routing nodes > attract more forwarding traffic, which is a nice incentive. > > I view this feature as a low priority enhancement, given there are > a lot more pressing issues in LN, > but open to feedback. Mostly, I thought it could be useful to > spark ideas and highlight the > flexibility of OMs. > > Cheers, > Val > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > <mailto:Lightning-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -- Sophia-Antipolis, France CV: https://www.peersm.com/CVAV.pdf LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26 GitHub : https://www.github.com/Ayms A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7 A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com Peersm : http://www.peersm.com
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
