Topic: REWARD offered for hash collisions for SHA1, SHA256, RIPEMD160 and other - page 4. (Read 40724 times)
February 23, 2017, 08:15:31 PM
Congratulations! I had completely forgotten about this thread.
February 23, 2017, 02:40:31 PM
The SHA1 bounty has been claimed - currently 1 confirmation.
https://blockchain.info/tx/8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc
https://blockchain.info/tx/8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc
https://i.imgflip.com/1k7p0t.jpg
February 23, 2017, 12:14:57 PM
... meanwhile, MD5 is still widely used 
February 23, 2017, 12:00:56 PM
Obviously he ran a bot checking if the challenge is solved and trying to double-spend using the challenge answer before the real winner is confirmed
In fact the bot is looking for all inputs which do not require signing by private key 
February 23, 2017, 09:05:49 AM
A double spend with 3 confirms?? i never thought i would see the day. Is this not a Zero day and needs too be patched? should we be happy this collision happened??
Not a problem, the other ones are not confirmedHow the guy did it:
- The first SHA1 collision ever has been found today: https://shattered.io/
- He took the data from the header to the "collision blocks" (see image at bottom, 320 bytes)
- With the data after these blocks (from JPEG data to PDF footer) being the same and the 2 hashes having the same value, we know the hashes of "header -> collision blocks" will be the same due to what SHA1 is
Congratulations to 1EohDhHJT9byKsYhxp5zX6PNkuGhxoEu9r, I completely forgot this challenge
By the way, it looks like 1aa5cmqmvQq8YQTEqcTmW7dfBNuFwgdCD is trying something: https://blockchain.info/fr/address/37k7toV1Nv4DfmQbmZ8KuZDQCYK9x5KpzP
This guy is known: https://bitcointalksearch.org/topic/instant-bitcoin-doubler-1572130 (amaclin: https://bitcointalksearch.org/user/amaclin-197593, Trust: -512: -9 / +0 Warning: Trade with extreme caution!)
Obviously he ran a bot checking if the challenge is solved and trying to double-spend using the challenge answer before the real winner is confirmed
February 23, 2017, 09:00:54 AM
A double spend with 3 confirms?? i never thought i would see the day. Is this not a Zero day and needs too be patched? should we be happy this collision happened??
February 23, 2017, 08:43:06 AM
The SHA1 bounty has been claimed - currently 1 confirmation.
https://blockchain.info/tx/8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc
https://blockchain.info/tx/8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc
February 05, 2014, 12:24:17 PM
Someone please produce a news article with this sensational title :" The Bitcoin creator's $ 1 billion hidden reward to those who break NSA's super secret algorithm".
Hmmm, a catch-22:
If an intelligent person can derive a fast enough algorithm to invert SHA-2 (256-bit), then he can also use it to mine Bitcoins faster than anyone else and gain complete control of the network. And therefore, he has no incentive to share the knowledge.
But if an intelligent person can derive a fast enough algorithm to break ECDSA signatures based on secp256k1, then he will have complete control of the crypto economy. His only option will be to keep the algorithm private. He has no incentive to share the knowledge because he can now manipulate transactions at will.
December 20, 2013, 03:59:35 AM
Someone please produce a news article with this sensational title :" The Bitcoin creator's $ 1 billion hidden reward to those who break NSA's super secret algorithm".
December 19, 2013, 07:47:10 PM
are at risk.
In context, of course— thats assuming a compromise of ECC on our curve. 
December 19, 2013, 07:25:43 PM
Not to take away from Peters wonderful challenge to the world but shouldn't this have been better directed at the ECDSA weaknesses implied by Schnier assuming of course this was his motivation for posting this?
All of Satoshi's coins are a reward for breaking the ECDSA, since they are not protected by the RIPEMD160 hash function.
Also, this has nothing to do with "Satoshi's coins". All block rewards generated by bitcoind's internal miner or getwork are at risk.
September 16, 2013, 05:08:10 AM
The updated system requires the hashing function and the signing algorithm to be broken at around the same time.
You need a preimage attack on the hash function where the preimage is a valid pubkey for which you know the corresponding privkey. There are about 2^256 pubkeys and 2^160 hashed addresses, so the attacker has to find one ECDSA keypair as the preimage out of about 2^96 possible candidates.
It's true to say that if the hash function is resistant to preimage attacks then we have 160 bits of security, compared to the 128 bits of security of ECDSA with 256 bit security parameter. But saying that the attacker must break both the hash function and ECDSA is too strong.
September 13, 2013, 04:57:28 PM
And that this (government backed security services employed) someone has not publicly disclosed it
They now have a way to get paid a bit for anonymously disclosing it. How sure do you want to be? Insert coins. 
September 13, 2013, 04:39:34 PM
Is there a way to know that someone hasn't already tested such a possibility? And that this (government backed security services employed) someone has not publicly disclosed it? I would suggest not, although I'd like to hear commentary from the more technically informed.
September 13, 2013, 03:03:29 PM
Added 1.0 BTC to SHA1 bounty.
September 13, 2013, 11:45:12 AM
Not to take away from Peters wonderful challenge to the world but shouldn't this have been better directed at the ECDSA weaknesses implied by Schnier assuming of course this was his motivation for posting this?
I don't believe there is a way to construct such a thing— beyond all the coins which are pay to pubkey (e.g. early unspent blocks) and all the coins which are assigned to addresses which have spent before so the pubkey is known.I'm not sure if anyone has identified any known-lost pay to pubkeys which can be redeemed without stealing from someone. Might be good for someone to do that.
September 13, 2013, 11:03:46 AM
No, there's no relation between a pubkey and a pubkey-hash. Once the pubkey is known, hash160 isn't relevant at all. Coinbase transactions in the pre-pool days were simply the public key and OP_CHECKSIG. "All" you have to spend this is find a way to generate a signature from the public key only. No hash preimage is required.
September 13, 2013, 09:22:37 AM
What are those and how do they compare to what we have today?
The standard transaction is "This coin can be spent by someone who signs the transaction with the private key that matches a public key that hashes to
To spend that, you need to provide the public key and then sign it. Even if the signature algorithm was broken, those coins couldn't be spent, since the attacker wouldn't know the public key. This is one of the reasons why re-using addresses is a bad idea. Once you spend money from the address, you give away the public key.
The original transactions were "This coin can be spent by someone who signs the transactions with the private key that matches
The updated system requires the hashing function and the signing algorithm to be broken at around the same time.
interesting. i never knew that the original Bitcoin didn't involve Hash160's.
but doesn't this get back to the point i was making to you that pubkeys are in fact more moderately protected by unspent addresses, ie Hash160's, of those pubkeys?
furthermore, my original point was i'd love to see Peter erect a scripting challenge to hack an ECDSA-related problem that Schnier so blatantly highlighted.
September 13, 2013, 09:11:34 AM
What are those and how do they compare to what we have today?
The standard transaction is "This coin can be spent by someone who signs the transaction with the private key that matches a public key that hashes to
To spend that, you need to provide the public key and then sign it. Even if the signature algorithm was broken, those coins couldn't be spent, since the attacker wouldn't know the public key. This is one of the reasons why re-using addresses is a bad idea. Once you spend money from the address, you give away the public key.
The original transactions were "This coin can be spent by someone who signs the transactions with the private key that matches
The updated system requires the hashing function and the signing algorithm to be broken at around the same time.
September 13, 2013, 08:27:27 AM
Not to take away from Peters wonderful challenge to the world but shouldn't this have been better directed at the ECDSA weaknesses implied by Schnier assuming of course this was his motivation for posting this?
All of Satoshi's coins are a reward for breaking the ECDSA, since they are not protected by the RIPEMD160 hash function.
Well they are as a public key is protected by an unspent address.
"Satoshi's early public keys"
What are those and how do they compare to what we have today?
Jump to: