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