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 add complexity. > 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 hidden-services. > 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[0]. 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[1], 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) Regards, Sebastian G. (bastik) -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
