Have all the ceremony in compressed form

[shamatar]

There are two options for a ceremony:

• Participant downloads 2M of data (points are in uncompressed form) and uploads M of data. Hash of 2M of data is written at the beginning of his contribution file. Then and operator takes M data that was uploaded, decompressed it and writes hash of the M data at the beginning of 2M data that will be a challenge for the next participant. It saves point decompression work for the participant at the expense of additional download, separate work by the ceremony master and additional steps required to verify the transcript (check decompression operation). At the other side a participant DOES NOT verify the correctness of the decompressed form
• Participants directly gets a contribution from the previous participant. Then he HAS TO validate the contribution (and it's a risk of breaking a ceremony chain!) and decompress forms, but downloads much less and there is no decompression work by ceremony master.

My opinion is that decompression is a pain, but it gives form of checkpointing (if some participant screws up - he can be directly blamed, everyone can re-run a verification locally). Decompression chain itself can be checked even after the ceremony.

Please discuss

[josojo]

Validating the previous contributions is quite resource intensive on slower machines. I think it would nearly double the execution-time for each participant.

I thought that the ceremony master would simply perform all validation tasks and people trust them. If there is a fault in the ceremony master"s work, then this is unfortunate,( as we would have to redo the ceremony), but it would be obvious.

Then and operator takes M data that was uploaded, decompressed it and writes hash of the M data at the beginning of 2M data that will be a challenge for the next participant.

it would be neat to give every participant both options:

• download 2M file and no uncompress work
• download M file and let him uncompress the file.
  In both options, the challenge should always have the hash of the uncompressed 2M challenge file.

[barryWhiteHat]

I prefer to reduce computation time and require more download.

If a participant is worried they can always validate the transcript after the fact. Or even before they contribute. So the logic to do the decompression in the client can be removed as long as the client is able to validate a transcript. Which we will need to have anyway.

[josojo]

From this upper input, I think we should go with 2M download and each client only verifies that they downloaded the right data via a hash check of the 2M file.

@shamatar , are you willing to write the code for this, if there is any code needed?

[shamatar]

Hash checking is done in the original implementation - when an operator uncompresses a file, it's hash changes, then this hash should be made public and when contribution begins user should compare those hashes. I've cleaned up a code, now it's ready to roll