On 13 Jan 2016, at 01:46, George Kadianakis <desnacked@riseup.net> wrote:

Hello there,

we are happy to tell you that we finished coding proposal 250 and our first
attempt at implementation is ready for review.

You can find the final specification here:
https://gitweb.torproject.org/user/dgoulet/torspec.git/log/?h=prop250_final_v1
and the corresponding code here:
https://gitweb.torproject.org/user/dgoulet/tor.git/log/?h=prop250_final_v1

Trac ticket #16943 (https://trac.torproject.org/projects/tor/ticket/16943) will
be used for code review. Please use this mailing list to discuss any issues
with the spec.

Some notes: We've separated this in 7 commits prefixed with prop250: except
first one that adds a needed tor_htonll/ntohll function to tor utils. This code
is mostly contained in two *new* files (with their headers) that are
shared-random.{c|h} and shared-random-state.{c|h}.

For what it's worth, we expect this code to run for a long time before the
shared random values generated by the authorities are used for anything
(e.g. HSDir scrambling).

I've seen you talk about using chutney for shared randomness generation.

Can you open a ticket with a branch for the chutney SR template, so people can use it for testing?

(And then we can merge it into chutney master about the same time this code goes into tor master.)

There's a make target, "test-network-all", that runs a series of chutney tests.

Each of these tests finish in around 35 seconds.

Can we get a SR chutney template to finish in around that time?

(With 10 second voting periods?)

What is the minimum number of voting periods that shared randomness requires?

(I understand the standard setting is 24, 12 for the commit, and 12 for the reveal.)

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F