[EMAIL PROTECTED] writes:
Hi Tomas
> Potential future
>> if rt.id == 1:
>> # do something for P1
>> elif rt.id == 2:
>> # do something for P2
>> else:
>> # do something for P3
>>
>> Alternatively one could write three different source files, but
>> this does not scale to protocols with more players.
>
> While I really feel that it's necessary to let the parties perform
> different actions, I'm not sure that there's an elegant way to get
> around the problem. Symmetry is lost, so they *are* trying to do
> something different, so of course they need separate program-paths
> somehow. In the general case this is unavoidable.
Yeah, I think so too... we want the players to do different things,
but at the same time we want to minimize the amount of differnent
code. This was why I made the design symmetric initially, since it
"solves" the problem.
> I think one simple solution to break the symmetry could be just to
> provide the possibility of having one party share a value.
>
> x = rt.shamir_share(input, player_id)
>
> Party player_id plays the role of dealer, while all others simply
> receive their share. As receivers have to provide a dummy input it's
> not as pretty as I'd like, but alternatively the programs have to be
> different, which is also bad.
What about making the argument to shamir_share optional? If all three
players specify a value, then the code looks and behaves like it does
today:
a, b, c = rt.shamir_share(input)
If P1 and P2 provide input, all three players would execute:
if rt.id == 1:
a, b = rt.shamir_share(input)
elif rt.id == 2:
a, b = rt.shamir_share(input)
else:
a, b = rt.shamir_share()
Here all three players receive shares from two inputs, hence the
return type becomes a two-tuple.
If it is only P1 who provides input, this program is executed:
if rt.id == 1:
a = rt.shamir_share(input)
else:
a = rt.shamir_share()
Here the return value is a simple Share.
I think this is the natural generalization of what we have today...
Does it looks usable?
> Are there really other problems than sharing (and opening a shared
> value towards only one party)?
I don't think so. All other operations (addition, multiplication,
comparison, etc...) are done on variables which represent values in
the ideal functionality implemented by VIFF. So they are not tied to
any particular player and so I think we can limit these asymmetric
operations to sharing and opening.
--
Martin Geisler
_______________________________________________
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
