From laolu32 at gmail.com Fri Jan 18 21:06:51 2019 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Fri, 18 Jan 2019 13:06:51 -0800 Subject: [Lightning-dev] Network probes In-Reply-To: References: Message-ID: 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 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: