[tor-talk] Regarding #8244; Including a string not under authority control?
Sebastian G. <bastik.tor>
bastik.tor at googlemail.com
Tue Nov 26 18:56:08 UTC 2013
25.11.2013 19:10, Nick Mathewson:
> On Mon, Nov 25, 2013 at 11:53 AM, Nick Mathewson <nickm at alum.mit.edu> wrote:
>> On Fri, Oct 11, 2013 at 9:44 AM, Sebastian G. <bastik.tor>
>> <bastik.tor at googlemail.com> wrote:
>>> beside having each authority call in for their vote about the random
>>> string, how about including a string in the consensus not under control
>>> by any authority?
>>> For example a hash from the bitcoin blockchain (its popular and I had no
>>> other source in mind). The authorities get together at some point, lets
>>> say 10 minutes before each full hour. They all take the hash from
>>> hh:45:00 or the closest to that result, where the newest wins. (hh:46:00
>>> wins over hh:44:00)
>>> Clients and hidden-services use both the hash and the random string.
>>> If for whatever reason an authority picks a different hash than the
>>> others there is no error. Like with all(?) other votes the majority
>>> wins, so the majority would need to be buggy or compromised in order to
>>> vote for the 'desired' hash.
>>> The bitcoin blockchain is observable and so it is known where the hash
>>> in the consensus comes from. Anyone could see which hash is included
>>> look it up in the blockchain and see if it matches the criteria that
>>> were specified for selecting the hash.
>> That's a pretty clever idea!
All of them are! (Until they get analyzed)
> Oh, and to clarify: I rather like this approach. It's just that the
> only way I know to do good security analysis is start with the
> assumption that the idea must be broken somehow, and try to figure out
> how what the attack is.
I think the tricky part is to prove that such a string would be secure.
It's broken when the string is broken. In our case if bitcoin has a
cryptographic weakness the resulting hash might be unsuitable.
> The fact that bitcoin blocks contain many transactions help us out
> here, but makes the analysis less trivial than I'd thought before I
> started re-reading the protocol. Also, duh, it's not about getting
> the last transaction -- it's about being the miner who happens to
> generate the block.
I would have to start reading the protocol and had no intention in doing
so. (I don't think this would be helpful)
> 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 ?
I think this is the case, but it's about math so there's the possibility
that I got/get it wrong.
Sebastian G. (bastik)
More information about the tor-talk