[tor-talk] Regarding #8244; Including a string not under authority control?
Sebastian G. <bastik.tor>
bastik.tor at googlemail.com
Tue Nov 26 19:10:25 UTC 2013
26.11.2013 02:48, Tom Fitzhenry:
> On Mon Nov 25 18:10:44 UTC 2013, Nick Mathewson <nickm at alum.mit.edu> wrote:
>> So unless I'm missing my guess, the cost of setting N bits of the hash
>> with probability P here is equal to the cost of generating a target
>> bitcoin block with probability P, times 2^N ?
> If this factor (2^N) is considered too low, we could be make it harder by adding an
> additional superfluous computation. For example, rather choosing the block header as
> our random value, choose SHA-256(SHA-256...(SHA-256(block_header)...) as our random
> value. Say, k iterations.
Welcome into my head. :) I had included to idea to hash the string,
possibly several hundred times to make it harder for someone to
influence the result, but I removed that part as I felt it would only
> This increases the cost factor to be k*2^N.
Indeed, I should have removed it. Thank you for bringing it up.
> Optionally, replace "repeated SHA-256" with one of PBKDF2/bcrypt/scrypt/similar.
> Bonus points for the additional computation not being SHA-256 based, because an
> attacker is likely to have the ability to compute SHA-256 quickly (to be able to
> compete with other miners, who have machines built to compute SHA-256 quickly).
I hadn't considered this. I don't know what it does to weaker clients or
> One problem with a /constant/ factor, k, is that as attackers/miners become more
> powerful, the constant factor becomes less of a problem. To combat this, k could
> track Bitcoin's difficulty. Doing this is more complex, however, and may mean the
> directory services have to implement more of the bitcoin client spec.
I hadn't considered that either.
> As an aside, note also that it takes a certain amount of time for a mined block to be
> considered part of the block chain. Conventional wisdom defines this to be 6
> blocks, which is on average one hour. So, if the authorities got together at
> 23:00, they should look at the block closest(?) to 22:00.
I hadn't considered huge delays either, but they would need to be
considered. I might be wrong, but what if the gaps between mined block
get bigger. Maybe this is flawed.
(no reply to Paul as I have not read anything)
Sebastian G. (bastik)
More information about the tor-talk