{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-02-15\n📝 Original message:\nOn 2/14/23 1:42 PM, Antoine Riard wrote:\n\u003e Hi Joost,\n\u003e \n\u003e  \u003e I think movement in this direction is important to guarantee competitiveness with centralised \n\u003e payment systems and their (at least theoretical) ability to\n\u003e  \u003e process a payment in the blink of an eye. A lightning wallet trying multiple paths to find one \n\u003e that works doesn't help with this.\n\u003e \n\u003e Or there is the direction to build forward-error-correction code on top of MPP, like in traditional\n\u003e networking [1]. The rough idea, you send more payment shards than the requested sum, and then\n\u003e you reveal the payment secrets to the receiver after an onion interactivity round to finalize payment.\n\nAh, thank you for bringing this up! I'd thought about it and then forgot to mention it in this thread.\n\nI think this is very important to highlight as we talk about \"building a reliable lightning network \nout of unreliable nodes\" - this is an *incredibly* powerful feature for this.\n\nWhile its much less capital-effecient, the ability to over-commit upfront and then only allow the \nrecipient to claim a portion of the total committed funds would substantially reduce the impact of \nfailed HTLCs on payment latency. Of course the extra round-trip to request the \"unlock keys\" for the \ncorrect set of HTLCs adds a chunk to total latency, so senders will have to be careful about \ndeciding when to do this or not.\n\nStill, now that we have onion messages, we should do (well, try) this! Its not super complicated to \nimplement (like everything it seems, the obvious implementation forgoes proof-of-payment, and like \neverything the obvious solution is PTLCs, I think). Its not clear to me how we get good data from \ntrials, though, we'd need a sufficient set of the network to support this that we could actually \ntest it, which is hard to get for a test.\n\nMaybe someone (anyone?) wants to do some experiments doing simulations using real probing success \nrates to figure out how successful this would be and propose a concrete sender strategy that would \nimprove success rates.\n\nMatt"}