I would have loved to write an alternative SKS implementation that addresses the issues we were seeing recently. However, this:
- Set Reconciliation with Nearly Optimal Communication Complexity <http://ipsit.bu.edu/documents/ieee-it3-web.pdf> - Practical Set Reconciliation <http://ipsit.bu.edu/documents/BUTR2002-01.ps> is preventing me from doing so. I'm a software engineer, not a mathematician, and I have little willingness to attempt implementing an algorithm nobody understands. I wish the title said "simple" and "resilient" rather than "with nearly optimal communication complexity", and the contents matched the title. The pool of engineers willing and able to get us out of this mess would be much larger. On Fri, Jul 13, 2018 at 11:23 PM, Andrew Gallagher <andr...@andrewg.com> wrote: > > > On 13 Jul 2018, at 22:43, Moritz Wirth <m...@flanga.io> wrote: > > > > FWIW, has anybody even started working on a fix for any of the bugs? > > There has been a fair bit of discussion, but no consensus has been > reached, apart from a general agreement that major changes to the recon > model will be required, and that these will be necessarily > backwards-incompatible. That’s generally where the discussion dries up. > > I get the impression that everyone is holding fire until there is some > sign that one particular form of breakage will be more broadly acceptable > than the others. > > A > > _______________________________________________ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel >
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
