--- Log opened Sat Nov 06 00:00:24 2021
16:24 < dergoegge> i have been thinking about using minisketch for efficiently sending proofs from bridges to CSNs (assuming the CSNs are caching proofs in some way)
16:24 < dergoegge> in a way we are facing a set reconciliation problem here where a bridge has a number of hashes more than a CSN in its set for a specific proof and we want to "reconcile" those two sets
16:24 < dergoegge> if the bridge knows the number of hashes the CSN is missing (guessing would be fine as well) it could construct a sketch of the entire proof and send the sketch instead of the proof
16:24 < dergoegge> the CSN could then construct a sketch of the partial proof that it has cached and merge the two sketches
16:24 < dergoegge> finally the CSN can decode the missing hashes from the merged sketch
16:24 < dergoegge> this has some cool benefits:
16:24 < dergoegge> 1. CSNs don't specifically request the missing hashes which is good for privacy (probably)
16:24 < dergoegge> 2. the sketches that bridges send have the same size as the missing hashes, so we don't waist bandwidth
16:24 < dergoegge> 3. bridges don't need to care about what caching strategy CSNs are using
16:24 < dergoegge> i am not entirely sure if this would work and i already see some problems with this:
16:24 < dergoegge> 1. we would need minisketch to support 256 bit elements (is that even possible or practical?) (pieter said that more than 64 bits is possible: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001742.html)
16:24 < dergoegge> 2. the order of the hashes after the CSN decodes the merged sketch is random (according to the minisketch readme) so we would need to address that somehow.
--- Log closed Sun Nov 07 00:00:25 2021