Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-15 🗒️ Summary of this message: The Lightning ...
📅 Original date posted:2023-02-15
🗒️ Summary of this message: The Lightning Network could use forward-error-correction code on top of MPP to send more payment shards than the requested sum, reducing the impact of failed HTLCs on payment latency.
📝 Original message:
On 2/14/23 1:42 PM, Antoine Riard wrote:
> Hi Joost,
>
> > I think movement in this direction is important to guarantee competitiveness with centralised
> payment systems and their (at least theoretical) ability to
> > process a payment in the blink of an eye. A lightning wallet trying multiple paths to find one
> that works doesn't help with this.
>
> Or there is the direction to build forward-error-correction code on top of MPP, like in traditional
> networking [1]. The rough idea, you send more payment shards than the requested sum, and then
> you reveal the payment secrets to the receiver after an onion interactivity round to finalize payment.
Ah, thank you for bringing this up! I'd thought about it and then forgot to mention it in this thread.
I think this is very important to highlight as we talk about "building a reliable lightning network
out of unreliable nodes" - this is an *incredibly* powerful feature for this.
While its much less capital-effecient, the ability to over-commit upfront and then only allow the
recipient to claim a portion of the total committed funds would substantially reduce the impact of
failed HTLCs on payment latency. Of course the extra round-trip to request the "unlock keys" for the
correct set of HTLCs adds a chunk to total latency, so senders will have to be careful about
deciding when to do this or not.
Still, now that we have onion messages, we should do (well, try) this! Its not super complicated to
implement (like everything it seems, the obvious implementation forgoes proof-of-payment, and like
everything the obvious solution is PTLCs, I think). Its not clear to me how we get good data from
trials, though, we'd need a sufficient set of the network to support this that we could actually
test it, which is hard to get for a test.
Maybe someone (anyone?) wants to do some experiments doing simulations using real probing success
rates to figure out how successful this would be and propose a concrete sender strategy that would
improve success rates.
Matt
🗒️ Summary of this message: The Lightning Network could use forward-error-correction code on top of MPP to send more payment shards than the requested sum, reducing the impact of failed HTLCs on payment latency.
📝 Original message:
On 2/14/23 1:42 PM, Antoine Riard wrote:
> Hi Joost,
>
> > I think movement in this direction is important to guarantee competitiveness with centralised
> payment systems and their (at least theoretical) ability to
> > process a payment in the blink of an eye. A lightning wallet trying multiple paths to find one
> that works doesn't help with this.
>
> Or there is the direction to build forward-error-correction code on top of MPP, like in traditional
> networking [1]. The rough idea, you send more payment shards than the requested sum, and then
> you reveal the payment secrets to the receiver after an onion interactivity round to finalize payment.
Ah, thank you for bringing this up! I'd thought about it and then forgot to mention it in this thread.
I think this is very important to highlight as we talk about "building a reliable lightning network
out of unreliable nodes" - this is an *incredibly* powerful feature for this.
While its much less capital-effecient, the ability to over-commit upfront and then only allow the
recipient to claim a portion of the total committed funds would substantially reduce the impact of
failed HTLCs on payment latency. Of course the extra round-trip to request the "unlock keys" for the
correct set of HTLCs adds a chunk to total latency, so senders will have to be careful about
deciding when to do this or not.
Still, now that we have onion messages, we should do (well, try) this! Its not super complicated to
implement (like everything it seems, the obvious implementation forgoes proof-of-payment, and like
everything the obvious solution is PTLCs, I think). Its not clear to me how we get good data from
trials, though, we'd need a sufficient set of the network to support this that we could actually
test it, which is hard to get for a test.
Maybe someone (anyone?) wants to do some experiments doing simulations using real probing success
rates to figure out how successful this would be and propose a concrete sender strategy that would
improve success rates.
Matt