[Lightning-dev] Network probes

[Olaoluwa Osuntokun]

Hi Andrea,

> This saves the receiving node from doing a database lookup

Nodes can and eventually should start using bloom filters to avoid most
database lookups for incoming payment hashes. The false positive rate can be
set to a very low value as the bloom filter doesn't need to transmitted, and
can even be stored persistently. As an optimization, nodes may opt to
maintain a series of hierarchical bloom filters, with the highest tier
filter containing only payment hashes for non-expired invoices. Clever bloom
filter usage by nodes would allow them to avoid almost all database lookups
for incoming unknown payment hashes (probes or not).

> we can improve it by using the `padding` of the `per_hop` field of the
> onion;

I recently implemented a type of spontaneous payment [1] that works today in
the wild (gotta love dat End to End Principle). A requirement for this was
fully functional EOB packing logic at the sender, and multi-packet
unwrapping at the receiver, the modified packet construction/processing can
be found here [2]. Using the terminology of the current draft code, all that
would need to be done is specify an EOB type for this special probe type of
HTLC. As it doesn't need any additional data, it only consumes a single
pivot hop and doesn't require the route to be extended.

Have you seen aj's prior post [3] on this front (making probe HTLCs
identifiable to the receiver, and allowing intermediate nodes to drop them)?
Allowing intermediate nodes to identify probe HTLCs has privacy
implications, as all of a sudden we've created two path-level classes of
HTLCs. On the other hand, this may help with QoS scheduling on the
forwarding plane for nodes, they may want to prioritize actual payments over
probes, with some nodes opting to not forward probes all together.

[1]: https://github.com/lightningnetwork/lnd/pull/2455
[2]: https://github.com/lightningnetwork/lightning-onion/pull/31
[3]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001554.html

-- Laolu


On Fri, Jan 18, 2019 at 8:47 AM Andrea RASPITZU <andrea.raspitzu at acinq.fr>
wrote:

> Good morning list,
>
> I know there have been discussion around how (and if) we should probe the
> network to check for the liveliness of a path before sending out the
> payment. Currently we issue a payment with a random payment_hash that is
> not redeemable by anyone, if the destination (and the path) is `lively` it
> will respond Error. Assuming we do want to probe, and it make sense to
> assume so because it can't be prevented, we can improve it by using the
> `padding` of the `per_hop` field of the onion; with a single bit of the
> padding we can tell the final node that this is a probe and not an actual
> payment. This saves the receiving node from doing a database lookup
> (checking if it has the preimage for such a payment_hash) and it does not
> reveal anything to intermediate nodes, we don't want them to change the
> behavior if they know it's a probe and not an actual payment. I believe
> probing can help reducing the error rate of payments (and even detect stale
> channels?) and I'm looking forward to have some feedback, and submit a
> draft.
>
> Cheers, Andrea.
> _______________________________________________
> 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/20190118/ca2dccc5/attachment.html>