Martin Geisler <[EMAIL PROTECTED]> writes: > Martin Geisler <[EMAIL PROTECTED]> writes: > >> That would be a good idea, also for performance. I suggest that we >> use a round-robin system where we determine the perticipating >> subset based on the current program counter. > > Code for this would look like this: > > + def select_subset(self, threshold): > > [...]
A full patch is here: http://article.gmane.org/gmane.comp.cryptography.viff.patches/49 Add /raw to the end of the URL if you want the raw email for importing with 'hg import'. (Let me know again if you guys would prefer such code posted here instead. It is slightly stupid to split the traffic in two like this.) I tested this briefly yesterday evening and more this morning: (n, t) Old New (3, 1) 1.3 ms 2.1 ms (4, 1) 1.6 ms 1.9 ms (5, 1) 1.9 ms 1.8 ms (6, 1) 2.2 ms 1.7 ms (7, 1) 2.5 ms 1.6 ms (8, 1) 2.8 ms 1.6 ms (9, 1) 3.1 ms 1.7 ms With n=3 and t=1 the code does extra work compared to the old code, but when the number of players increase compared to the threshold, then each player ends up doing less and less, and the average time per comparison therefore drops! The new code lets n - (2t+1) players avoid: * waiting for the two shares * a local multiplication * Shamir sharing * network traffic The good question is now how we can get the best of both worlds so that the case with (n, t) = (3, 1) remains fast. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/. _______________________________________________ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
