On Mon, Dec 8, 2014 at 6:23 AM, Joseph Birr-Pixton <jpixton@gmail.com> wrote:
On 8 December 2014 at 10:40, Ryan Carboni <ryacko@gmail.com> wrote:
https://blockexplorer.com/q/hashestowin log(171833398380382098659*24*60*7)/log(2)
I think your calculation is slightly off. hashestowin is the average number of hashes you need to perform to win the current block. It's not necessarily the case that a block is calculated each second: in fact one is found (on average) each 625 seconds[1].
So that gives:
log(171833398380382098659*24*60*7/625)/log(2) 71.23
Average hashes to win something amongst your peers is one way to think of it. Easier look at overall compute power deployed. This graph is more telling and running at about 310 PH/s worth of double SHA-256. (Around 2^77.x per week.) https://blockchain.info/charts/hash-rate?showDataPoints=false&show_header=true&daysAverageString=1×pan=all&scale=1&address= Generalize the subject a bit further... http://www.distributed.net/ http://boinc.berkeley.edu/ http://setiathome.ssl.berkeley.edu/ http://top500.org/ http://folding.stanford.edu/ Amazon http://en.wikipedia.org/wiki/List_of_distributed_computing_projects Work the sum of all those into basic compute ops, bits per sec, gates per dollar, watts per dollar, etc. Then assume adversary can at least duplicate it, and apply the result into a similarly customized ASIC compute base against some crypto target of choice like RSA-1024, SHA-1, RC4... something realworld in each of asym/hash/sym. Or even just to disrupt Bitcoin. What do you get?
Naturally even a 2^64 collision attack requires implausible amounts of storage
Storage vs. time tradeoff applies as usual.