Re: [tor-talk] Regarding #8244; Including a string not under authority control?

["Sebastian G. <bastik.tor>" <bastik.tor@xxxxxxxxxxxxxx>]

25.11.2013 19:10, Nick Mathewson:
> On Mon, Nov 25, 2013 at 11:53 AM, Nick Mathewson <nickm@xxxxxxxxxxxx> wrote:
>> On Fri, Oct 11, 2013 at 9:44 AM, Sebastian G. <bastik.tor>
>> <bastik.tor@xxxxxxxxxxxxxx> wrote:
>>> Hello,
>>>
>>> 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.

Regards,
Sebastian G. (bastik)
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk