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