This means I would probably stick with letting the BOD do the drawing because they have a 99% uptime guarantee and are generally trusted. As long as a single one is honest you are ok.
Think this is probably the best approach put forward so far, but still feels like there might be a better trustless solution.
Yes, agree, I think I missed the bright ideas from bytemaster.
How about the ticket transactions vote for some from BOD, and not too many so could easy be collected.
Just some ideas from here:
http://www.dc.uba.ar/inv/tesis/licenciatura/2010/lernerHow about this way:
When the block round of ticket purchase begins, all the participants select fixed number of players out from BOD, this player provide hash/pubkey together with this block.
After the block is done, the next block these player could publish the priv_keys to generate the random number for that ticket purchase block.
The key point is that, the players are fixed and 99% online, so would be very easy for collecting, BOD thus act as CO-PRNGP Player service.
The leaving problem is only how will the tickets choose limit number the players, e.g. top 10 voted. all might be too many for collecting.
CO-PRNGP algorithm from that paper:
1) Each player i :
1.1) Chooses a random number ri := RandomNumber(csprng-seed-bit-length)
1.2) Computes cri := H(ri)MPF – Sergio Demian Lerner 44/83
1.3) Broadcasts cri (a commitment to ri )
2) Each player i:
2.1) Broadcasts ri
2.2) For each j, verifies that cri := H(ri)
2.3) Computes S = H(r1;r2;..;rn)
2.4) Uses S as seed for a common CSPRNG.
2.5) Use CSPRNG to generate the symmetric algorithm (CGC) common parameters.
2.6) Uses the CSPRNG to generate c distinct suitable encodings of the real cards in a deck to be
used as open cards. The generated cards are saved in the Open-Deck list.
2.7) Computes dhi := H(Open-Deck).
3) The first player broadcasts dh1.
4) Everybody verifies having computed dhi equal to dh1. If a player detects a mismatch, the protocol aborts