Re: [Lightning-dev] Pinging a route for capacity

[ZmnSCPxj via Lightning-dev]

Good morning Rene,

Please consider the recent discussion about AMP, atomic multi-path. 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html

Note that only the source (payer) can split the payment into multiple smaller 
payments; we cannot safely let intermediaries split the payment as the 
intermediaries may very well decide to send it to a ridiculously high-fee 
channel.  So the payer will make multiple payments that can only be merged at 
the destination, each sub-payment has a single route and itself cannot be split 
unless the payer decides to split.

> Not sure however how the impacts to the HTLC would be and if it would 
> actually be possible to fragment a payment that is encapsulated within the 
> onion routing.

The timeouts in particular would be impossible to handle.  At any point the 
payment should reach the payee within some N blocks and each hop reduces that 
margin by a small amount (14 blocks for c-lightning if I remember correctly).  
It is likely that there will not be enough time if it goes through a detour, 
unless the detour has equal or smaller reduction (delay) than the original hop 
with insufficient monetary capacity.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On March 1, 2018 11:26 PM, René Pickhardt via Lightning-dev 
 wrote:

> Hey everyone,
>
> disclaimer I am new here and have not a full understanding of the complete 
> specs yet - however since I decided to participate in lighting dev I will 
> just be brave and try to add my ideas on the problem jimpo posed. So even in 
> case by ideas are complete bs please just tell me in a friendly way and I 
> know I need to read more code and specs in order to participate.
>
> Reading about the described problem techniques like IP-Fragmentation ( 
> https://en.wikipedia.org/wiki/IP_fragmentation ) come to my mind. The setting 
> is a little bit different but in from my current understanding it should 
> still be applicable and also be the favorable solution in comparison to the 
> proposed ping:
>
> 1.) IP setting: In IP-Fragmentation one would obviously just split the 
> IP-package in order to utilize a link layer protocol that doesn't have enough 
> bandwidth for a bigger size package.
> 2.) Lightning case: When the capacity of a channel during routing is not high 
> enough - which means that the channel balance on that side is somewhere 
> between 0 and the size of the payment - one would have to to send the second 
> part of the fragmented package on a different route. This is obvious since 
> the insufficient channel balance cannot come out of thin air (as in 
> IP-Routing).
>
> My first intuition was that this would become a problem for onion routing 
> since the router in question does not know the final destination but only 
> knows the next hop which can't be utilized as the channel doesn't have enough 
> funds. However I imagine one could just encapsulate the second part of the 
> fragmented payment in a new onion routed package that goes on a detour (using 
> different payment channels) to the original "next" hop und progresses from 
> there as it was originally thought of.
>
> Not sure however how the impacts to the HTLC would be and if it would 
> actually be possible to fragment a payment that is encapsulated within the 
> onion routing.
>
> If possible the advantage in comparison to your proposed ping method is that 
> fragmentation would be highly dynamic and still work if a channel runs out of 
> funds while routing payment. In your ping scenario it could very well happen 
> that you do a ping for a designated rout, everything looks great, you send a 
> payment but while it is on its way a channel on that way could run dry.
>
> best Rene
>
> On Thu, Mar 1, 2018 at 3:45 PM, Jim Posen  wrote:
>
>> My understanding is that the best strategy for choosing a route to send 
>> funds over is to determine all possible routes, rank them by estimated fees 
>> based on channel announcements and number of hops, then try them 
>> successively until one works.
>>
>> It seems inefficient to me to actually do a full HTLC commitment handshake 
>> on each hop just to find out that the last hop in the route didn't have 
>> sufficient remaining capacity in the first place. Depending on how many 
>> people are using the network, I could also forsee situations where this 
>> creates more payment failures because bandwidth is locked up in HTLCs that 
>> are about to fail anyway.
>>
>> One idea that would likely help is the ability to send a ping over an onion 
>> route asking "does every hop have capacity to send X msat?" Every hop would 
>> forward the onion request if the answer is yes, or immediately send the 
>> response back up the circuit if the answer is no. This should reveal no 
>> additional information about the channel capacities that the sender couldn't 
>> 

[Lightning-dev] refunds -- was Re: BOLT 11, real time micro payments, and route redundancy

[Andy Schroder]

On 09/14/2017 11:49 PM, Rusty Russell wrote:
 I guess I'm confused how this is going to work safely. If you 
 put a refund request in with your payment, isn't that revealing the 
 public key of your node and then defeating the whole purpose of the 
 onion routing of the payment in the first place (I'm, assuming the payee 
  node re-uses the same public key?)? It seems like rather than putting a
 >>> flag in BOLT 11 to instruct a payer to include a refund payment 
 >>> request,
 >>> shouldn't the payer just know to do that if they think they will need
 >>> to? Or maybe they won't always?
>>> >> Nobody along the route (B and C in our example above) can see it.  And D
>>> >> kind of has to, since it needs to send the refund.
>> >
>> > It seems to me like this is sort of a limitation in privacy with 
>> > lightening. With blockchain payments on my fuel pump, I could return a 
>> > refund back to the customer without always knowing who they are. With 
>> > lightning, it looks like the payer will reveal their identity to the 
>> > payee by offering a refund payment request. It's great that those along 
>> > the payment route don't know, but it's still bad to have the payer 
>> > revealed to the payee. Why does someone have to reveal their identity 
>> > just to get a refund?
> Indeed, it's deeply suboptimal for privacy.
>
> There's a more complex scheme which is possible, using round-trip
> payments (I think this was originally from Christian Decker?); I make a
> payment via you and back to myself, it's just that I pay your node an
> abnormally high "fee".  But unfortunately for security reasons each
> encrypted hop contains the amount it expects to be sent, which doesn't
> work if I don't know how much you're going to refund.
>
> Technically, you can put a really small amount in there (each node only
> insists that the amount sent is >= this amount), but this just allows
> one of those return nodes to untracably steal the extra refund amount.
>
> So, we really need to be able to include a (smaller) return onion to
> fix this properly.  I've added that to:
>
> 
> https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#refunds
>
> Thanks!
> Rusty.



If you are including a smaller return onion, you are including that with
the payment? That return onion would be created by the payer since they
know the routes from the payer to the payee? If so, how could this work
if the route no longer has capacity (or goes down) by the time the payee
decides it's going to send the refund back to the payer (which could be
minutes, hours, or days later)? Also, even if all routes are still up,
the payer may not necessarily know how much refund the payee will be
giving them, so they may not necessarily be able to even know what the
best route they should build an onion for?





Andy Schroder


___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Pinging a route for capacity

[gb via Lightning-dev]

 and any thoughts on protections against flood pinging?

On Thu, 2018-03-01 at 09:45 -0500, Jim Posen wrote:


> The main benefit is that this should make it quicker to send a
> successful payment because latency is lower than sending an actual
> payment and the sender could ping all possible routes in parallel,
> whereas they can't send multiple payments in parallel. The main
> downside I can think of is that, by the same token, it is faster and
> cheaper for someone to extract information about channel capacities on
> the network with a binary search.
> 
> 
> -jimpo
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Pinging a route for capacity

[René Pickhardt via Lightning-dev]

Hey everyone,

disclaimer I am new here and have not a full understanding of the complete
specs yet - however since I decided to participate in lighting dev I will
just be brave and try to add my ideas on the problem jimpo posed. So even
in case by ideas are complete bs please just tell me in a friendly way and
I know I need to read more code and specs in order to participate.

Reading about the described problem techniques like IP-Fragmentation (
https://en.wikipedia.org/wiki/IP_fragmentation ) come to my mind. The
setting is a little bit different but in from my current understanding it
should still be applicable and also be the favorable solution in comparison
to the proposed ping:

1.) IP setting: In IP-Fragmentation one would obviously just split the
IP-package in order to utilize a link layer protocol that doesn't have
enough bandwidth for a bigger size package.
2.) Lightning case: When the capacity of a channel during routing is not
high enough - which means that the channel balance on that side is
somewhere between 0 and the size of the payment - one would have to to send
the second part of the fragmented package on a different route. This is
obvious since the insufficient channel balance cannot come out of thin air
(as in IP-Routing).

My first intuition was that this would become a problem for onion routing
since the router in question does not know the final destination but only
knows the next hop which can't be utilized as the channel doesn't have
enough funds. However I imagine one could just encapsulate the second part
of the fragmented payment in a new onion routed package that goes on a
detour (using different payment channels) to the original "next" hop und
progresses from there as it was originally thought of.

Not sure however how the impacts to the HTLC would be and if it would
actually be possible to fragment a payment that is encapsulated within the
onion routing.

If possible the advantage in comparison to your proposed ping method is
that fragmentation would be highly dynamic and still work if a channel runs
out of funds while routing payment. In your ping scenario it could very
well happen that you do a ping for a designated rout, everything looks
great, you send a payment but while it is on its way a channel on that way
could run dry.

best Rene


On Thu, Mar 1, 2018 at 3:45 PM, Jim Posen  wrote:

> My understanding is that the best strategy for choosing a route to send
> funds over is to determine all possible routes, rank them by estimated fees
> based on channel announcements and number of hops, then try them
> successively until one works.
>
> It seems inefficient to me to actually do a full HTLC commitment handshake
> on each hop just to find out that the last hop in the route didn't have
> sufficient remaining capacity in the first place. Depending on how many
> people are using the network, I could also forsee situations where this
> creates more payment failures because bandwidth is locked up in HTLCs that
> are about to fail anyway.
>
> One idea that would likely help is the ability to send a ping over an
> onion route asking "does every hop have capacity to send X msat?" Every hop
> would forward the onion request if the answer is yes, or immediately send
> the response back up the circuit if the answer is no. This should reveal no
> additional information about the channel capacities that the sender
> couldn't determine by sending a test payment to themself (assuming they
> could find a loop). Additionally, the hops could respond with the latest
> fee rate in case channel updates are slow to propagate.
>
> The main benefit is that this should make it quicker to send a successful
> payment because latency is lower than sending an actual payment and the
> sender could ping all possible routes in parallel, whereas they can't send
> multiple payments in parallel. The main downside I can think of is that,
> by the same token, it is faster and cheaper for someone to extract
> information about channel capacities on the network with a binary search.
>
> -jimpo
>
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>


-- 
Skype: rene.pickhardt
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev