Aymeric Vitte [ARCHIVE] on Nostr: 📅 Original date posted:2023-03-06 🗒️ Summary of this message: A Lightning ...
đź“… Original date posted:2023-03-06
🗒️ Summary of this message: A Lightning developer suggests using gossip messages to announce liquidity balances and differentiated services of channel liquidity levels instead of relying on sender-side probing.
đź“ť Original message:
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 at lists.linuxfoundation.org
> <mailto:lightning-dev at 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 at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230306/a0b1de03/attachment-0001.html>;
🗒️ Summary of this message: A Lightning developer suggests using gossip messages to announce liquidity balances and differentiated services of channel liquidity levels instead of relying on sender-side probing.
đź“ť Original message:
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 at lists.linuxfoundation.org
> <mailto:lightning-dev at 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 at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230306/a0b1de03/attachment-0001.html>;