<div dir="ltr"><div>Hi Fabrice, </div><div><br></div><div>I think HORNET would address this rather nicely!</div><div><br></div><div>During the set up phase (which uses Sphinx), the sender is able to get a sense</div><div>of if the route is actually "lively" or not, as the circuit can't be finalized</div><div>if all the nodes aren't available. Additionally, during the set up phase, the</div><div>sender can drop a unique payload to each node. In this scenario, it may be the</div><div>amount range the node is looking to send over this circuit. The intermediate</div><div>nodes then package up a "Forwarding Segment" (FS) which includes a symmetric</div><div>key to use for their portion of the hop, and can also be extended to include</div><div>fee information. If this set up phase is payment value aware, then each node</div><div>can use a private "fee function" that may take into account the level of</div><div>congestion in their channels, or other factors. This would differ from the</div><div>current approach in that this fee schedule need not be communicated to the</div><div>wider network, only those wishing to route across that link.</div><div><br></div><div>Another cool thing that it would allow is the ability to receive a</div><div>protocol-level payment ACK. This may be useful when implementing AMP, as it</div><div>would allow the sender to know exactly how many satoshis have arrived at the</div><div>other site, adjusting their payment sharding accordingly. Nodes on either side</div><div>of the circuit can then also use the data forwarding phase to exchange payment</div><div>hashes, perform cool zkcp set up protcols, etc, etc.</div><div><br></div><div>The created circuits can actually be re-used across several distinct payments.</div><div>In the paper, they use a TTL for each circuit, in our case, we can use a block</div><div>height, after which all nodes should reject attempted data forwarding attempts.</div><div>A notable change is that each node no longer needs to maintain per-circuit</div><div>state as we do now with Sphinx. Instead, the packets that come across contain</div><div>all the information required for forwarding (our current per-hop payload). As a</div><div>result, we can eliminate the asymmetric crytpo from the critical forwarding</div><div>path!</div><div><br></div><div>Finally, this would let nodes easily rotate their onion keys to achieve forward</div><div>secrecy during the data phase (but not the set up phase), as in the FS, they</div><div>essentially key-wrap a symmetric key (using the derived shared secret for that</div><div>hop) that should be used for that data forwarding phase.</div><div><br></div><div>There're a number of other cool things integration HORNET would allow, perhaps</div><div>a distinct thread would be a more appropriate place to extol the many virtues</div><div>of HORNET ;)</div><div><br></div><div>-- Laolu</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 1, 2018 at 3:05 PM Fabrice Drouin <<a href="mailto:fabrice.drouin@acinq.fr">fabrice.drouin@acinq.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Context<br>
======<br>
<br>
Sent payments that remain pending, i.e. payments which have not yet<br>
been failed or fulfilled, are currently a major UX challenge for LN<br>
and a common source of complaints from end-users.<br>
Why payments are not fulfilled quickly is not always easy to<br>
investigate, but we've seen problems caused by intermediate nodes<br>
which were stuck waiting for a revocation, and recipients who could<br>
take a very long time to reply with a payment preimage.<br>
It is already possible to partially mitigate this by disconnecting<br>
from a node that is taking too long to send a revocation (after 30<br>
seconds for example) and reconnecting immediately to the same node.<br>
This way pending downstream HTLCs can be forgotten and the<br>
corresponding upstream HTLCs failed.<br>
<br>
Proposed changes<br>
===============<br>
<br>
It should be possible to provide a faster "proceed/try another route"<br>
answer to the sending node using probing with short timeout<br>
requirements: before sending the actual payment it would first send a<br>
"blank" probe request, along the same route. This request would be<br>
similar to a payment request, with the same onion packet formatting<br>
and processing, with the additional requirements that if the next node<br>
in the route has not replied within the timeout period (typically a<br>
few hundred milliseconds) then the current node will immediately send<br>
back an error message.<br>
<br>
There could be several options for the probe request:<br>
- include the same amounts and fee constraints than the actual payment request.<br>
- include no amount information, in which case we're just trying to<br>
"ping" every node on the route.<br>
<br>
Implementation<br>
============<br>
<br>
I would like to discuss the possibility of implementing this with a "0<br>
satoshi" payment request that the receiving node would generate along<br>
with the real one. The sender would first try to "pay" the "0 satoshi"<br>
request using the route it computed with the actual payment<br>
parameters. I think that it would not require many changes to the<br>
existing protocol and implementations.<br>
Not using the actual amount and fees means that the actual payment<br>
could fail because of capacity issues but as long as this happens<br>
quickly, and it should since we checked first that all nodes on the<br>
route are alive and responsive, it still is much better than “stuck”<br>
payments.<br>
And it would not help if a node decides to misbehave, but would not<br>
make things worse than they are now (?)<br>
<br>
Cheers,<br>
Fabrice<br>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div>