> On 13 Jan 2016, at 20:02, David Goulet <[email protected]> wrote: > > On 13 Jan (11:34:05), Tim Wilson-Brown - teor wrote: >> >>> On 13 Jan 2016, at 01:46, George Kadianakis <[email protected]> wrote: >>> >>> ... >>> 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.) > > We've done extensive testing already with chutney. I don't think we need > a specific SR template since this is part of the voting system which > ultimately put the SR values in the consensus. > > I mostly used the "hs" template for this and sometimes used a variation > of it with 9 dirauths instead of 3. > >> >> 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.) > > For now, that won't be possible :S, the number of rounds per phase (12 > commits and 12 reveals) are hardcoded so no torrc options to change > them. We could make it that in TestingNetwork, this is divided by 4 > having 3 and 3 but then we are at 60 seconds so :S... Do you think even > just that would be useful?
If the minimum number of rounds per phase is 3, then let's set it at 3 in test networks. (But leave it as a configurable, test-network-only parameter, like the many other test network parameters.) 60 seconds is better than 240 seconds, and it means the tests are more likely to get run. > On the other hand, a very very useful test would be to have a way to > kill/spawn/kill/spawn dirauth to simulate reboots or a way to make them > miss voting periods. That doesn't sound to me that crazy difficult to > achieve with chutney and in that case we could have an epic SR template > that imposes conditions on dirauth lifetime. I think this is one of those future features that would require a rewrite of chutney, or at least substantially more code. I agree it would be useful. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
