25.11.2013 19:10, Nick Mathewson: > On Mon, Nov 25, 2013 at 11:53 AM, Nick Mathewson <ni...@alum.mit.edu> wrote: >> On Fri, Oct 11, 2013 at 9:44 AM, Sebastian G. <bastik.tor> >> <bastik....@googlemail.com> 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@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
