> George Kadianakis writes:
>
>> Hello there,
>>
>
> Hello,
>
> I'm inlining the latest version of proposal250.
>
> It includes various improvements, like completely removing the need for an SR
> doc (which will make implementation much much easier), and switching to
> signature-based commitme
George Kadianakis writes:
> Hello there,
>
Hello,
I'm inlining the latest version of proposal250.
It includes various improvements, like completely removing the need for an SR
doc (which will make implementation much much easier), and switching to
signature-based commitments which are attribut
On Tue, Sep 8, 2015 at 7:10 AM, David Goulet wrote:
> On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote:
>>
>> > On 7 Sep 2015, at 23:36, David Goulet wrote:
>> > ...
>> > Please review it, mostly format of the state (before the SR document)
>> > has changed. As well as a new "conflict" line is
On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote:
>
> > On 7 Sep 2015, at 23:36, David Goulet wrote:
> > ...
> > Please review it, mostly format of the state (before the SR document)
> > has changed. As well as a new "conflict" line is added to the vote.
> > …
>
>
> > If an authority sees tw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I disagree. can you describe how exactly? What exactly can be gamed,
if we use the protection described by me? It will provide the same
security as directory authorities already have for voting about
relays. It's true that ultimately anything can be
> On 7 Sep 2015, at 23:36, David Goulet wrote:
> ...
> Please review it, mostly format of the state (before the SR document)
> has changed. As well as a new "conflict" line is added to the vote.
> …
> If an authority sees two distinct commitments from an other authority in
> the same period, th
Hello!
While working on the implementation of this proposal, we realized that
it was much more complicated to add a new consensus flavor than we
originally anticipated.
nickm then suggested to NOT use this new flavor (shared random document)
and instead change it to a persistent state on disk tha
I'm not a big fan of automated systems that ban authorities as it may get false
positives and it may be gamed and/or attacked.
An alternative solution is to make the voting a two-step system: first you
publish the sha256 hash of your vote, then a few minutes later you publish the
actual vote.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Sending the comments from #tor-dev here as well.
This is related to the attack where exactly half of the directory
authorities commit to some values, and the last directory authority
can send different values to both camps, and have the ultimat
> On 12 Aug 2015, at 04:35 , George Kadianakis wrote:
>
> teor writes:
>
>> Another implementation note on directory caching of the SR doc:
>>
>> I just noticed the following code in
>> update_consensus_networkstatus_downloads():
>>
>> for (i=0; i < N_CONSENSUS_FLAVORS; ++i) {
>>/*
teor writes:
> Another implementation note on directory caching of the SR doc:
>
> I just noticed the following code in
> update_consensus_networkstatus_downloads():
>
> for (i=0; i < N_CONSENSUS_FLAVORS; ++i) {
> /* need some way to download unknown flavors if we are caching. */
>
> Th
> On 10 Aug 2015, at 23:07 , George Kadianakis wrote:
>
> teor writes:
>
>>> On 4 Aug 2015, at 22:00 , George Kadianakis wrote:
>>>
>>> Hello,
>>>
>>>
>>>
> 3.7. Shared Randomness Disaster Recovery [SRDISASTER]
>
> If the consensus at 12:00UTC fails to be created, then there
Another implementation note on directory caching of the SR doc:
I just noticed the following code in update_consensus_networkstatus_downloads():
for (i=0; i < N_CONSENSUS_FLAVORS; ++i) {
/* need some way to download unknown flavors if we are caching. */
This means that any new consensus
teor writes:
>> On 4 Aug 2015, at 22:00 , George Kadianakis wrote:
>>
>> Hello,
>>
>>
>>
3.7. Shared Randomness Disaster Recovery [SRDISASTER]
If the consensus at 12:00UTC fails to be created, then there will be no new
shared random value for the day.
Directory
> On 4 Aug 2015, at 22:00 , George Kadianakis wrote:
>
>>> XXX The number of active participants is dynamic as authorities leave and
>>> join the protocol. Since the number of active participants is dynamic ,
>>> an attacker could trick some authorities believing there are N
>>> part
> On 4 Aug 2015, at 22:00 , George Kadianakis wrote:
>
> Hello,
>
> and thanks for the comments.
>
> I uploaded a new version of the proposal that addresses some of your feedback.
>
> You can find it here:
> https://gitweb.torproject.org/user/asn/torspec.git/log/?h=rng-draft-v4-asn
Thanks f
teor writes:
>> On 4 Aug 2015, at 00:03 , George Kadianakis wrote:
>> …
>
>> 3.1.2. Shared Random Document During Commitment Phase [SRDOCCOMMIT]
> …
Hello,
and thanks for the comments.
I uploaded a new version of the proposal that addresses some of your feedback.
You can find it here:
http
> On 4 Aug 2015, at 00:03 , George Kadianakis wrote:
> …
> 3.1.2. Shared Random Document During Commitment Phase [SRDOCCOMMIT]
…
> Also, an authority should not be able to register a commitment value for a
> different authority. Hence, an authority X should only vote and place in
> the SR doc
On Tue, Aug 04, 2015 at 12:39:50AM +1000, teor wrote:
>
> > On 4 Aug 2015, at 00:32 , Ian Goldberg wrote:
> >
> > Nice work! A couple of minor comments:
> >
> > On Mon, Aug 03, 2015 at 05:03:38PM +0300, George Kadianakis wrote:
> >> A shared random document requires 50% + 1 authority signatu
> On 4 Aug 2015, at 00:32 , Ian Goldberg wrote:
>
> Nice work! A couple of minor comments:
>
> On Mon, Aug 03, 2015 at 05:03:38PM +0300, George Kadianakis wrote:
>> A shared random document requires 50% + 1 authority signatures to be
>> considered valid. As this proposal is being written,
Nice work! A couple of minor comments:
On Mon, Aug 03, 2015 at 05:03:38PM +0300, George Kadianakis wrote:
>A shared random document requires 50% + 1 authority signatures to be
>considered valid. As this proposal is being written, there are 9
>authorities thus we would need 5.
Careful
Hello there,
we are glad to release a first draft of our proposal on distributed random
generation using the Tor voting process. It specifies how Tor dirauths can
generate a fresh random value every day using a commit-and-reveal protocol. The
protocol piggybacks on top of the regular Tor voting pr
22 matches
Mail list logo
