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 <laol...@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.raspi...@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@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