Bitcoin networks surpasses 2^80 hashes per week
https://blockexplorer.com/q/hashestowin log(171833398380382098659*24*60*7)/log(2) Gives context to the obsolescence of 80-bit block ciphers (it only takes ten million dollars of dedicated hardware to crack an 80-bit cipher). And context to the NSA's design of Skipjack. Naturally even a 2^64 collision attack requires implausible amounts of storage, so properly designed hash functions should be secure for the indefinite future.
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
Cheers, Joe [1] https://blockexplorer.com/q/interval
24 = hours 60 = minutes 7 = days so I'm only off by a factor of 2^3.3, not by a factor of 2^9.3 Cheers. On Mon, Dec 8, 2014 at 3: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
Cheers, Joe
On Mon, Dec 08, 2014 at 09:44:22AM -0800, Ryan Carboni wrote:
24 = hours 60 = minutes 7 = days
so I'm only off by a factor of 2^3.3, not by a factor of 2^9.3
Cheers.
Isn't this enough to find 128 bit md5 collision? Appears to me they can do it distributed in about 2 days even with the most naive rho attack. AFAIK it is open problem if 128 bit md5 collision exists (though it is believed to exist).
On Mon, Dec 8, 2014 at 3: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
Cheers, Joe
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.
Naturally even a 2^64 collision attack requires implausible amounts of storage, so properly designed hash functions should be secure for the indefinite future. That'd only be the case for a naive collision finding attack. But
On Mon, Dec 8, 2014 at 11:40 AM, Ryan Carboni <ryacko@gmail.com> wrote: there are attacks that require little memory. Search for "distinguished points".
participants (5)
-
CodesInChaos -
Georgi Guninski -
grarpamp -
Joseph Birr-Pixton -
Ryan Carboni