<div>Good morning Rene,<br></div><div><br></div><div>Packet switching could theoretically be done if switching ephkeys were possible, which would be needed for rendezvous nodes anyway.<br></div><div>An intermediate node is handed an opaque onion and the node to give that onion to, which, when you squint, is what the payer is given in the rendezvous node case.<br></div><div>Christian said it's not possible because math, but I cannot confirm it as I know too little of the relevant math.<br></div><div><br></div><div>If not possible by ephkey switching, then we could switch to a new onion construction.<br></div><div><br></div><div>---<br></div><div><br></div><div>That said, there are already a few items discussed, which improve payment reliability.<br></div><div><br></div><div>1. Active probing. This lets us update our maps before the user even starts a payment.<br></div><div>2. Ping before commitment.<br></div><div><br></div><div>The second has greater improvement in reliability, as I understand it.<br></div><div>The main reason for stuck payments is that a hop node forwarded the payment to the next, but the next crashes or disconnects before it could claim the HTLC.<br></div><div>The next node can theoretically claim the money up to the timelock by dropping to chain while disconnected from previous node.<br></div><div>The previous node thus cannot report an error until it itself drops onchain and triggers the timelock branch, which it can only do if the timelock has passed.<br></div><div><br></div><div>Ping before commit reduces the window this can happen, by pinging the next node before we even offer an HTLC.<br></div><div>This is because of how TCP/IP works.<br></div><div>We can send a message, then learn the connection was closed, we cannot reliably say if the message was received.<br></div><div>If we send the commitment, that lets the next node potentially claim the HTLC.<br></div><div>If we then find out the connection closed, we do not know certainly if it was received, or if the next node was already down for an hour and we just didn't notice.<br></div><div><br></div><div>If we send a ping beforehand, though, that lets us figure out if the connection dropped before we send the HTLC.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user protonmail_signature_block-empty"><br></div><div class="protonmail_signature_block-proton">Sent with <a target="_blank" href="https://protonmail.com">ProtonMail</a> Secure Email.<br></div></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Friday, November 16, 2018 6:27 PM, René Pickhardt via Lightning-dev &lt;lightning-dev@lists.linuxfoundation.org&gt; wrote:<br></div><div> <br></div><blockquote type="cite" class="protonmail_quote"><div dir="ltr"><div dir="ltr"><div><br></div><div>Good morning list,&nbsp;<br></div><div><br></div><div>in Adelaide I had a long conversation with another participant who complained that slow payments and failing payments are still a major UX issue for people that try to use the lightning network. While I believe this is a very valid point and we might want to think heavily about altering some design decisions after BOLT1.1 in order to mitigate this I want to make another proposal which could still be an improvement to some of the problems that we currently have with path finding. This proposal is basically a standalone thread to my suggestions sketched in Connors PR at <a href="https://github.com/lightningnetwork/lightning-rfc/pull/503">https://github.com/lightningnetwork/lightning-rfc/pull/503</a> for non strict forwarding.&nbsp;<br></div><div><br></div><div>I propose to implement a second routing algorithm that works on the principle of best effort routing / forwarding with the help of local payment fragmentation or maybe better called local AMP. I understand this sounds drastic to start with, in particular since it seems that the destination has to be known but I believe there&nbsp;&nbsp;are ways to still keep up with privacy.&nbsp;<br></div><div><br></div><div>The core idea is to allow intermediate nodes to fragment an HTLC to something similar as Base AMP to reach the next hop that was specified in the onion. This would still allow to forward a payment and allow the next hop to to continue with the regular onion package.&nbsp;<br></div><div><br></div><div>The idea is if Alice is supposed to forward an HTLC to Bob with a value smaller than their channel capacity but alice has not enough funds on her side alice could try to fragment the payment and try to find several paths (or maybe just one path without splitting) to Bob.&nbsp;<br></div><div><br></div><div>One particular strategy to find such a path&nbsp;would be to share friend of a friend (FOAF) information.<br></div><div>Alice could look at the nodes that both she and Bob are connected to and use them as bridge nodes for the payment. In particular she could even ask Bob how much inbound capacity he has from those nodes. In case Bob would share this information about the channel balance of mutual friends it could deterministically be decided if the original HTLC could be forwarded from Alice to Bob in a fragmented way.&nbsp;<br></div><div><br></div><div>With the autopilot we are trying to create many triangles in the network so that there is always the chance for friend of a friend nodes which could be used with this approach.&nbsp;<br></div><div><br></div><div>On the downside the original payer would have to allow a package to be locally fragmented by including more fees at each hop and also by increasing the CLTV deltas in each hop (so that an additional hop can be included and financed).&nbsp;<br></div><div><br></div><div>With the suggestion I made the payer can still select the basic route and the full route would still be private. The sender however could chose paths on which a lot of common friends exist for each pair of nodes on the path (thereby increasing the probability that the local fragmentation of the payment has a higher likelihood to be successful)&nbsp;&nbsp;<br></div><div><br></div><div>Of course another solution is if we think that local AMP is too complex and expensive we could still have the two nodes that fail to forward the htlcs work collaboratively to find a path between them and return this information about such a (multi) path as a routing suggestion in the error message so that the adapted onion package could be tried and sent by the payer.<br></div><div><br></div><div>best regards Rene<br></div><div><br></div><div><div>-- <br></div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><a href="https://www.rene-pickhardt.de" target="_blank">https://www.rene-pickhardt.de</a><br></div><div><br></div><div>Skype: rene.pickhardt&nbsp;<br></div><div><br></div><div>mobile: +49 (0)176 5762 3618 &nbsp;&nbsp;<br></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div>