"Thomas Jakobsen" <[EMAIL PROTECTED]> writes:

> I suggest that we - as far as it's reasonable - write unit tests
> that don't depend on a specific number of players and threshold, but
> instead use number of players and threshold as defined by
> runtime.threshold and runtime.players. This will allow us to
> automatically run these tests with many combinations of (no of
> players, threshold), say, (3,1), (5,2), (5,1), (7,3).

That is an excellent idea! You're right that the current unit tests
are hard-coded to use a particular number of players (3 player for
most of tests and 4 for the Bracha broadcast test). We should change
this and make a setup where the same test is run with different
parameters.

Changing it is quite easy (but somewhat tedious):

        a, b, c = runtime.shamir_share([1, 2, 3], self.Zp, 42 + runtime.id)

becomes

        everybody = range(1, len(runtime.players)+1)
        shares = runtime.shamir_share(everybody, self.Zp, 42 + runtime.id)

and we can then loop over shares as we see fit. I think I will make a
num_players field in Runtime so that we can stop writing
len(runtime.players) so often...

One can almost just use runtime.players.keys(), but since
runtime.players is a dictionary we don't really know in which order
the keys will come out, or more importantly, if the order is the same
for all players.

> My experience from developing protocols for the previous SIMAP
> prototype was that testing all protocols with (3,1), (5,1) (5,2) and
> (7,3) sometimes caught subtle bugs that wouldn't have been caught
> when testing only (3,1) and, say, (5,2).

Yeah, there might be some strange bugs hiding there...

I think we should do this after a 0.4 release. There has been quite a
lot of new features since 0.3: some asymmetric protocols, Bracha
broadcast, xor overloading. When we have asymmetric open and
prss_share, then I think we should release the code as VIFF 0.4.

-- 
Martin Geisler
_______________________________________________
viff-devel mailing list (http://viff.dk/)
[email protected]
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk

Reply via email to