Re: [Lightning-dev] Network probes
This seems like a bad idea as it could create timing attacks to discover if a node is the target for a payment. Matt On 1/18/19 9:06 PM, Olaoluwa Osuntokun wrote: Nodes can and eventually should start using bloom filters to avoid most database lookups for incoming payment hashes. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Network probes
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 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 > 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@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] Network probes
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@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
[Lightning-dev] Network probes
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
