Quote from: hhanh00 on June 14, 2016, 09:37:10 AM

1.
sid that gets passed to RUN comes from

Code:

Run(P, my, VK[ ], sk, sid', 0)

where sid' is (sid, P, VK[ ]).

Why do you need to have sid' if you are building a hash H((sid, sid, P ∪ {my}, VK[ ], run)). At this point sid is sid'.

As Tim pointed out in a previous comment, we try to include the complete view of the peers in the hash. In this manner, we ensure that they do not continue if something is not as expected. (Even though some inputs of the hash function may not be necessary it cannot be wrong to include them in the hash.)

Quote from: hhanh00 on June 14, 2016, 09:37:10 AM

2.
I don't understand the commitment phase.
"it is even for a rushing malicious peer a infeasible to have committed to an ill-formed vector that
leaves mp intact".

The DC-VECTOR exchanged between peers contain a DC-PAD component that cancels out when everything is summed up. Could you explain how would a malicious peer benefit from omitting it?

The general idea of having commitments is to ensure termination. In order to understand what can we wrong if there is no commitment phase, you can imagine the following simple case: the malicious peer could wait for the DC-VECTOR from all other peers before he publishes his own (i.e., rushing malicious peer). At that point, he can locally sum them up and recover the m_p message from every other peer p. Thus, now the malicious user have enough information to create an ill-formed DC-VECTOR that changes m_p for for a peer p but not for the rest. In this scenario, the tricked honest peer p won't sign the final output because her message m_p is not there (and she might be excluded), however she correctly followed the protocol.

The use of commitments thus is necessary to ensure termination for the honest peers: Intuitively, since the malicious peer has to commit to his DC-VECTOR before seeing the DC-VECTOR of the other peers, he cannot create a DC-VECTOR that changes m_p for a peer p but not for the rest.