[Lightning-dev] Network probes

[Andrea RASPITZU]

Hi Laolu,

Great idea, effectively with a clever (hierarchical) usage of bloom filters
nodes can reduce to the bare minimum the DB lookups. I guess with that
considered it's probably redundant to have an explicit probe flag for the
sender? Not for technical reasons though (the EOB can easily support that -
just need an extra type) but it seems to me that the only benefit can be
already torn away by client-side optimizations and it wouldn't improve much
to have an explicit probe at this point. Cancellable probes is indeed an
attracting idea, if i understood it correctly it is about the sender being
able to send out another different type of probe that would tell the
intermediate nodes that the previous one wasn't  actually a payment -
allowing the network to free resources. I agree that introducing probes
that can be dropped and/or prioritized by intermediate nodes is a privacy
issue and can be abused, it allows them to respond differently thus the
probe result can not be trusted entirely, perhaps a node policy where nodes
would temporary ban a peer that is adding too many unredeemable HTLCs is
enough for the moment.

Cheers, Andrea.

On Fri, 18 Jan 2019 at 22:07, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:

> 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/20190121/c1df59f1/attachment-0001.html>