Author

Topic: REWARD offered for hash collisions for SHA1, SHA256, RIPEMD160 and other (Read 40742 times)

copper member
Activity: 1330
Merit: 899
🖤😏
I was curious about a question that came to my mind.

I saw a dead wallet address from 2010 which holds about 30,000BTC. Pretty sure either owner is already dead by now, or he's now at least 50 years old. Anyways...

What would happen if someone miraculously hit the jackpot and successfully managed to generate the same hashes that produces the same address that holds the coins?

Can he sells the coins and just change from nothing to Billionaire overnight? Could we try to lock and prevent him from selling the coins that he stoleny illegally took and held?
Hash alone is not enough, if he finds a valid private key that has a public key with the same hash as the hash of that address's public key then he can spend them and no one can stop him.
member
Activity: 194
Merit: 14
I was curious about a question that came to my mind.

I saw a dead wallet address from 2010 which holds about 30,000BTC. Pretty sure either owner is already dead by now, or he's now at least 50 years old. Anyways...

What would happen if someone miraculously hit the jackpot and successfully managed to generate the same hashes that produces the same address that holds the coins?

Can he sells the coins and just change from nothing to Billionaire overnight? Could we try to lock and prevent him from selling the coins that he stoleny illegally took and held?
copper member
Activity: 821
Merit: 1992
Real example: "1" and "01" give this "4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a"
You use identical message. In binary, it is "00000001". In hex, this implementation for some reason use padding to 8-bit values, so better switch to binary values. In general, for every message you have at least one 512-bit block, for example for your message it looks like that:
Code:
01800000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000008
Here, you can see that the raw data is "01", then you have "80", because of that added "1" bit, and then you have a lot of zeroes (padding), and "8" in the end, as the size of the message in bits (not bytes, for that reason you can hash single bits).
copper member
Activity: 1330
Merit: 899
🖤😏
No, it doesn't exist. If it does, then all the news would say it. If you insist, show me the proof.
Read back the previous pages, I have explained how to find them with 100% certainty, there is no other proof that I know of, and what I have explained is good for sha256 and rmd160, I was unable to even understand what does (sha256(rmd160) mean, but I know what does sha256 double collision mean, having 2 different inputs generating 2 different first hash but having identical second hash, that's a bit (very) hard to construct a sure method.

However, every problem has not one but many solutions, and in order to find them you need no computational power at first, what you need is to come up with an algorithm to perform a task and then you let the computer to do the heavy work. For now the safety of all hash functions and elliptic curves depend on DLP.
~dig.
member
Activity: 162
Merit: 65
But even if a collision related to sh256 or double sha256 were found, this would not be a problem for Bitcoin.  not for wallet security and not for mining.  Right?
They already exist, we just don't know whether they have been found and are being exploited or not, however if they become publicly known then we'd be sure they can be exploited, thus requiring a major change which will render all miners useless, this is what worries me.

No, it doesn't exist. If it does, then all the news would say it. If you insist, show me the proof.
copper member
Activity: 1330
Merit: 899
🖤😏
But even if a collision related to sh256 or double sha256 were found, this would not be a problem for Bitcoin.  not for wallet security and not for mining.  Right?
They already exist, we just don't know whether they have been found and are being exploited or not, however if they become publicly known then we'd be sure they can be exploited, thus requiring a major change which will render all miners useless, this is what worries me.
jr. member
Activity: 47
Merit: 18
But even if a collision related to sh256 or double sha256 were found, this would not be a problem for Bitcoin.  not for wallet security and not for mining.  Right?
copper member
Activity: 1330
Merit: 899
🖤😏
Guess that explains why the following inputs have the same hash:
"ffffffffffffffffffff000000"  ,  "ffffffffffffffffffff00000". =
"02de980e731d160a92b4f41fe07d1b2763f167906db488e4cd380f3936e51ff4". The software I use is a broken open source implementation.😉
full member
Activity: 161
Merit: 230
Question regarding hash functions:
Do they all operate based on 2 character set hexadecimal or we can hash a single hex character as well?
I'm asking this because I have found 2 strings with only 1 character difference having the same digest, maybe it's a bug?
Like if they are not supposed to give you any hash for a single bit, then all the 16 bit hex chars used bit by bit should never produce a hash while they do, so why is it when I use a 30 long char hex string and a 31 long char string they both produce the same output?

*For example: "1234567890" and "12345678901" give me the same output.

*=Fake example.

Real example: "1" and "01" give this "4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a"

Am I missing something?
And please don't tell me the algorithm pads a 0 to 1 when we only use 1 as input, because I have 2 strings not starting with a 0 but have the same hash.

Whatever you use to calculate hashes is broken and deletes leading nulls.


SHA-256 can technically be used on an arbitrary number of bits that don't divide by 8, but in practice no implementations ever use that feature, and only do full byte sequences.
copper member
Activity: 1330
Merit: 899
🖤😏
Question regarding hash functions:
Do they all operate based on 2 character set hexadecimal or we can hash a single hex character as well?
I'm asking this because I have found 2 strings with only 1 character difference having the same digest, maybe it's a bug?
Like if they are not supposed to give you any hash for a single bit, then all the 16 bit hex chars used bit by bit should never produce a hash while they do, so why is it when I use a 30 long char hex string and a 31 long char string they both produce the same output?

*For example: "1234567890" and "12345678901" give me the same output.

*=Fake example.

Real example: "1" and "01" give this "4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a"

Am I missing something?
And please don't tell me the algorithm pads a 0 to 1 when we only use 1 as input, because I have 2 strings not starting with a 0 but have the same hash.
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
is SHA512 better than SHA256? if yes, why don't we use that?

First of all, define "better". SHA-512 probably have better collision better resistance due to longer output, but SHA-256 have shorter output which save bandwidth/storage which have some importance when using Bitcoin. And if we're looking for better hash algorithm, we probably should look for to more modern/secure standard rather than SHA-2 standard (such as SHA-256 and SHA-512).
member
Activity: 162
Merit: 65
is SHA512 better than SHA256? if yes, why don't we use that?
full member
Activity: 161
Merit: 230
i haven't had time to go through all the replies here. But did anyone successfully find the collision?

If someone found a SHA256 collision it would be all over tech news. The only collision so far is the SHA1 one, where someone simply copied the collision published by Google at https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html.
copper member
Activity: 1330
Merit: 899
🖤😏
[6]dacb99a98b80d48adbd8b94c9a7905996503d2ab

[5]32f51406f6d584a5b62365de425d01f308fc56a33682492284cc7577ceeb8868
Let's pretend there was funds in the address in your example 1ArWUwF2WfPnDubReohn2vtPodfPpG5Evq ,  still they won't be able to move those funds since they don't know the private key of that address, the steps you provided is not enough to do that.
If you hash the public key of the address above, you will get [5], if you hash [6] you'd still get [5]. And I don't know how we could spend the funds if it was loaded, I'm not trying to find people's private keys, this is about hash collisions.


"avalanche effect"?
Not applicable to SHA-256, I just exercised the method to prove avalanche effect  is an illusion, Satoshi inadvertently created an algorithm that can be used to draw a map of all SHA-256 collisions, it's like a knife cutting it's own handle.
This is as far as I am willing to go on this matter, I have decided to stop working on it and will not publish further findings, telling people 5x5=25 makes it easy, but showing them "25" makes it hard for them to figure out the proper equation. I need to confuse the outsiders, while the insiders know what 5-5-2-5 means.

i haven't had time to go through all the replies here. But did anyone successfully find the collision?
No, we are just talking about how to easily find them, one way is brute force, other way is beyond my comprehension, you should read "vjudeu's posts to know what I mean.😉


Even if we find a collision, we must not publicly disclose it to the world, instead we should convince the world that the algorithm "is no longer secure".
If anyone is interested to further discussing the issue, come and visit my special penthouse at digaran's tower.

member
Activity: 162
Merit: 65
i haven't had time to go through all the replies here. But did anyone successfully find the collision?
legendary
Activity: 3472
Merit: 10611
Except they have chosen the same atom due to the fact of reverse snow ball effect on SHA-256, where having an infinite combinations of different data as input will drastically increase the probability of collisions.
You mean the "avalanche effect"? That still doesn't change the fact that the probability of finding a collision is only high when you compute an unimaginably high number of hashes.
Our input is also not infinite, it is finite if we are talking about public key hashes (points on the curve which is a subgroup and finite). Although since the number is too big, it could be seen as infinite and impossible Tongue

Quote
People always wanted to see actual collisions, I merely satisfied the general public's desire, mine as well.
I'm glad you had no comment/ mistake correction on that.
I honestly didn't quite get what you said in the first part so I decided not to comment on that and let others do.
jr. member
Activity: 38
Merit: 8

Second attempt, this time on SHA-256.

We take this and use it as our public key:

[6]dacb99a98b80d48adbd8b94c9a7905996503d2ab
Then we perform a SHA-256 on it to get our hash of pub ready to convert to an address:
[5]32f51406f6d584a5b62365de425d01f308fc56a33682492284cc7577ceeb8868
Now we do a RMD160 on it:
6c161fcca8bbd0fe7a393b11b0499bb0754e3f7f
And the resulting address is:
[4]1ArWUwF2WfPnDubReohn2vtPodfPpG5Evq

Once again we have arrived at the scene of a collision, if you find the actual public key of [4], and perform a SHA-256 on it, you will see that the result is the same as[5], which means [6] and the actual public key of [4] which are different in value and length etc, collide with a similar SHA-256 hash, 2 different inputs, producing 1 unchanged output.




Let's pretend there was funds in the address in your example 1ArWUwF2WfPnDubReohn2vtPodfPpG5Evq ,  still they won't be able to move those funds since they don't know the private key of that address, the steps you provided is not enough to do that.
copper member
Activity: 1330
Merit: 899
🖤😏
That would be like saying 2 people can choose the same atom in the universe....
Except they have chosen the same atom due to the fact of reverse snow ball effect on SHA-256, where having an infinite combinations of different data as input will drastically increase the probability of collisions.

People always wanted to see actual collisions, I merely satisfied the general public's desire, mine as well.
I'm glad you had no comment/ mistake correction on that.
legendary
Activity: 3472
Merit: 10611
Do that long enough on too many objects, you will have a collection of collisions, conditionally if you could find the public keys of your generated addresses though.
Except that "long enough" in this context means thousands of years since there are a little less than 2256 public keys and you need to check about 2160+1 of them to find a collision. Something that is not possible with existing hardware or in our lifetime.

Quote
More over, there are some funded addresses and obviously their owners are unaware that they are holding the key to an actual collision,
That would be like saying 2 people can choose the same atom in the universe....
copper member
Activity: 1330
Merit: 899
🖤😏
I hope this act as a heads up for manufacturers, miners, developers, this also could be a known fact, I haven't seen it discussed any where.

Demonstrating two collision attacks in details.

This is a unc public key:
[1]0425f587ba19c90b6e4a6606929bc6a01c44a051805797662ca2cb735dba3c009859f01d2a9e6fa d26fd0fda518271ab0dc32e9a9de6ad3b0f000bd09edfa98ca3
We perform RMD160 on it:
[3]dacb99a98b80d48adbd8b94c9a7905996503d2ab
Result:
[2]1LwtDDHxpvo6Uh9sbRTNSU7r5rukqCFRGC
Now, since there are no SHA-256 hash that long[1] if we find the actual public key of our address[2] and perform a SHA-256 on it, the resulting hash which is a 64 char long hex will produce the same RMD160[3], therefore the SHA-256 of [2]'s actual public key and our fake hash[1] of a public key collide with each other on RMD160 hash function, 2 different inputs with one unchanged output.

Second attempt, this time on SHA-256.

We take this and use it as our public key:

[6]dacb99a98b80d48adbd8b94c9a7905996503d2ab
Then we perform a SHA-256 on it to get our hash of pub ready to convert to an address:
[5]32f51406f6d584a5b62365de425d01f308fc56a33682492284cc7577ceeb8868
Now we do a RMD160 on it:
6c161fcca8bbd0fe7a393b11b0499bb0754e3f7f
And the resulting address is:
[4]1ArWUwF2WfPnDubReohn2vtPodfPpG5Evq

Once again we have arrived at the scene of a collision, if you find the actual public key of [4], and perform a SHA-256 on it, you will see that the result is the same as[5], which means [6] and the actual public key of [4] which are different in value and length etc, collide with a similar SHA-256 hash, 2 different inputs, producing 1 unchanged output.


Do that long enough on too many objects, you will have a collection of collisions, conditionally if you could find the public keys of your generated addresses though.

More over, there are some funded addresses and obviously their owners are unaware that they are holding the key to an actual collision, sooner or later people will figure this out and will exploit it, also the owners of such addresses should transfer their funds to avoid unwanted stalkers, I imagine that top level gov agencies already are aware of this, the reason for publishing this, is to prevent unexpected harm to people and to the entire crypto-system in the future.
copper member
Activity: 906
Merit: 2258
Quote
Isn't using ASICs much faster
No, because ASICs can only compute hashes in a way they are designed. So, if some ASIC is designed to get 80-byte values, and hash them twice, then you cannot use it for some other purpose, and execute a different attack. You have to build a new ASIC if you want to execute things differently.

Quote
and since there are already mining software available you don't need to code
Existing software can only do brute force, and not much more than that. It can try every single value, but it won't give you solutions for reduced number of rounds, won't execute hash functions backwards, and won't allow many other things you may want to test, that will come from mathematical equations.

Quote
However I doubt if working on SHA-1 would help you to figure out other hash functions.
Working on SHA-1 is easier (and safer, because since collisions are known, then SHA-1 usage is already discouraged, so any progress will not be that harmful as it would be on SHA-256). Also, some attacks can be used on many different hash functions, because some of them have similar structure (if you know how to get all zeroes for the first 16 rounds of SHA-1, then you can use the same method to do that on SHA-256). Another thing is I don't expect to execute a successful attack, the main reason is to better understand why those things are safe.

Quote
Unless they all follow the same blueprint only producing larger values?
Internally, SHA-1 and SHA-256 use 32-bit values. Just SHA-1 uses five registers, A,B,C,D,E, and SHA-256 uses three more: F,G,H. There are also differences in internal algorithms, more K-values for SHA-256, and stronger dependencies for SHA-256, but the whole concept is similar: you have some internal state of the round, you take next 32-bit data chunk, and you compute next internal state from that, where usually some 32-bit value is altered, and the rest is only tweaked. That way or another, you work on 32-bit values, and create expressions like "a[​i+1]=rol5(a[​i])+f[​i]+e[​i]+k[​i]+w[​i]", then put known values in their places, and by having some equations like that, you try to find values matching all conditions.

Quote
SHA-256 is extremely vulnerable and guess that's why Satoshi used them twice
It is stronger than you may think. However, those hash functions are not resistant to length extension attack. So, if you know that the hash of some message is X, and you know the size of that message, then you can extend it by one block, by just putting any content, then putting '1' bit, adding a new size of the whole thing, and voila, you will have a valid hash for this extended message. But if you hash things twice, then the final hash is always computed from the single block of the same structure, and the final message has always the same size, so it cannot be extended by any attacker.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
SHA-256 is extremely vulnerable
Why is SHA-256 extremely vulnerable?

that's why Satoshi used them twice, because if you give a 256 bit input all the time, then the chance of producing 2 identical 256 bit outputs is extremely near impossible
This is not correct. The fact that the SHA-256 hash of nearly every single function of Bitcoin has a 256-bit pre-image (due to double-hashing) doesn't make it more secure. The input remains the same, so the first hash remains the same.

you can use infinite number of different inputs.
To be pedantic, it's nearly infinite. SHA-256 can take up to 2^61-1 bytes as input, which is approximately 2.92 x 10^18 terabytes. The possible combinations are virtually infinite though.

unfortunately there is financial incentive to find and exploit weaknesses
I find this rather a feature. Progress comes with questioning.
copper member
Activity: 1330
Merit: 899
🖤😏
I will write some code to check it out.
Isn't using ASICs much faster and since there are already mining software available you don't need to code, but that is for SHA-256 of course. However I doubt if working on SHA-1 would help you to figure out other hash functions.
Unless they all follow the same blueprint only producing larger values?
SHA-256 is extremely vulnerable and guess that's why Satoshi used them twice, because if you give a 256 bit input all the time, then the chance of producing 2 identical 256 bit outputs is extremely near impossible, in the case of SHA-256, you can use infinite number of different inputs.

Now if we compare it with bitcoin, by using hash 160 we are reducing the security of hash functions further, though that's just hash functions, bitcoin has 3 firewalls after the two hashes we have ECC. unfortunately there is financial incentive to find and exploit weaknesses, and IMO ASIC manufacturers will greatly suffer if there is a collision because nobody would buy their ASICs after that and their products would become obsolete.

I'd suggest anyone finding such collisions to give a heads up warning to big manufacturers before revealing the vulnerability.

Thank you guys for your delightful insights, I couldn't have learned this much if I wasn't here, I am proud to be amongst the elites of crypto-coders.❤
copper member
Activity: 906
Merit: 2258
Quote
Another example is trying to use less bits in a hash function. If you have SHA-1, you have IV equal to "0x67452301,0xefcdab89,0x98badcfe,0x10325476,0xc3d2e1f0", and you have k-values equal to "0x5a827999,0x6ed9eba1,0x8f1bbcdc,0xca62c1d6". There are three types of left rotations, equal to "1,5,30". You can switch from 32-bit values into 8-bit values, and produce 40-bit hashes, instead of 160-bit hashes. You can use IV equal to "0x67,0xef,0x98,0x10,0xc3", k-values equal to "0x5a,0x6e,0x8f,0xca", and left rotations, equal to "1,5,6". Then, you can produce a message, where w-values will be also 8-bit. After that, you can find some 128-bit chunk with many leading zeroes:
Code:
00 2e 35 3c
f9 80 00 00
00 00 00 00
00 00 00 28
It has "0000000093" hash, so it has eight leading nibbles, that means at least 32 leading zero bits. So far so good, but then, the question is, how to use that in real SHA-1, and produce an equivalent, so a hash with 128 leading zero bits? As I said, you will have only a random message, it won't help you in that case. And even if you check 2^40 combinations to find a full 40-bit preimage in this fake hash, it won't help you to get closer to the real 160-bit preimage, because even if many SHA-1 properties are preserved, the avalanche effect will make a complete mess, and a single different computation in the middle, will alter the whole result.
I tried that method, and found a block that can give us all zeroes in this hash:
Code:
b5 cd 37 67
28 80 00 00
00 00 00 00
00 00 00 28
I wonder how that can give us any clues to fill those gaps:
Code:
0 | 67 ef 98 10 c3 | 67452301 efcdab89 98badcfe 10325476 c3d2e1f0
 1 | 56 67 fb 98 10 | ........ 67452301 7bf36ae2 98badcfe 10325476
 2 | fc 56 d9 fb 98 | ........ ........ 59d148c0 7bf36ae2 98badcfe
 3 | c1 fc 95 d9 fb | ........ ........ ........ 59d148c0 7bf36ae2
 4 | 89 c1 3f 95 d9 | ........ ........ ........ ........ 59d148c0
 5 | a1 89 70 3f 95 | ........ ........ ........ ........ ........
 6 | d9 a1 62 70 3f | ........ ........ ........ ........ ........
 7 | 44 d9 68 62 70 | ........ ........ ........ ........ ........
 8 | bc 44 76 68 62 | ........ ........ ........ ........ ........
 9 | bf bc 11 76 68 | ........ ........ ........ ........ ........
10 | 0b bf 2f 11 76 | ........ ........ ........ ........ ........
11 | 60 0b ef 2f 11 | ........ ........ ........ ........ ........
12 | a6 60 c2 ef 2f | ........ ........ ........ ........ ........
13 | 2c a6 18 c2 ef | ........ ........ ........ ........ ........
14 | 0e 2c a9 18 c2 | ........ ........ ........ ........ ........
15 | 15 0e 0b a9 18 | ........ ........ ........ ........ ........
16 | e7 15 83 0b a9 | ........ ........ ........ ........ ........
17 | 0f e7 45 83 0b | ........ ........ ........ ........ ........
18 | e0 0f f9 45 83 | ........ ........ ........ ........ ........
19 | b0 e0 c3 f9 45 | ........ ........ ........ ........ ........
20 | 53 b0 38 c3 f9 | ........ ........ ........ ........ ........
21 | 16 53 2c 38 c3 | ........ ........ ........ ........ ........
22 | 17 16 d4 2c 38 | ........ ........ ........ ........ ........
23 | 01 17 85 d4 2c | ........ ........ ........ ........ ........
24 | a5 01 c5 85 d4 | ........ ........ ........ ........ ........
25 | e8 a5 40 c5 85 | ........ ........ ........ ........ ........
26 | ed e8 69 40 c5 | ........ ........ ........ ........ ........
27 | 48 ed 3a 69 40 | ........ ........ ........ ........ ........
28 | 5d 48 7b 3a 69 | ........ ........ ........ ........ ........
29 | 19 5d 12 7b 3a | ........ ........ ........ ........ ........
30 | c3 19 57 12 7b | ........ ........ ........ ........ ........
31 | 89 c3 46 57 12 | ........ ........ ........ ........ ........
32 | 2f 89 f0 46 57 | ........ ........ ........ ........ ........
33 | 25 2f 62 f0 46 | ........ ........ ........ ........ ........
34 | d8 25 cb 62 f0 | ........ ........ ........ ........ ........
35 | 64 d8 49 cb 62 | ........ ........ ........ ........ ........
36 | 4f 64 36 49 cb | ........ ........ ........ ........ ........
37 | b5 4f 19 36 49 | ........ ........ ........ ........ ........
38 | 94 b5 d3 19 36 | ........ ........ ........ ........ ........
39 | 93 94 6d d3 19 | ........ ........ ........ ........ ........
40 | bc 93 25 6d d3 | ........ ........ ........ ........ ........
41 | d9 bc e4 25 6d | ........ ........ ........ ........ ........
42 | 6b d9 2f e4 25 | ........ ........ ........ ........ ........
43 | cd 6b 76 2f e4 | ........ ........ ........ ........ ........
44 | b7 cd da 76 2f | ........ ........ ........ ........ ........
45 | e7 b7 73 da 76 | ........ ........ ........ ........ ........
46 | 14 e7 ed 73 da | ........ ........ ........ ........ ........
47 | 36 14 f9 ed 73 | ........ ........ ........ ........ ........
48 | 0c 36 05 f9 ed | ........ ........ ........ ........ ........
49 | 23 0c 8d 05 f9 | ........ ........ ........ ........ ........
50 | 56 23 03 8d 05 | ........ ........ ........ ........ ........
51 | 20 56 c8 03 8d | ........ ........ ........ ........ ........
52 | c9 20 95 c8 03 | ........ ........ ........ ........ ........
53 | a8 c9 08 95 c8 | ........ ........ ........ ........ ........
54 | 78 a8 72 08 95 | ........ ........ ........ ........ ........
55 | 27 78 2a 72 08 | ........ ........ ........ ........ ........
56 | 1b 27 1e 2a 72 | ........ ........ ........ ........ ........
57 | 7e 1b c9 1e 2a | ........ ........ ........ ........ ........
58 | dd 7e c6 c9 1e | ........ ........ ........ ........ ........
59 | 1c dd 9f c6 c9 | ........ ........ ........ ........ ........
60 | 29 1c 77 9f c6 | ........ ........ ........ ........ ........
61 | 55 29 07 77 9f | ........ ........ ........ ........ ........
62 | 70 55 4a 07 77 | ........ ........ ........ ........ ........
63 | d3 70 55 4a 07 | ........ ........ ........ ........ ........
64 | db d3 1c 55 4a | ........ ........ ........ ........ ........
65 | 76 db f4 1c 55 | ........ ........ ........ ........ ........
66 | f8 76 f6 f4 1c | ........ ........ ........ ........ ........
67 | c3 f8 9d f6 f4 | ........ ........ ........ ........ ........
68 | 56 c3 3e 9d f6 | ........ ........ ........ ........ ........
69 | b5 56 f0 3e 9d | ........ ........ ........ ........ ........
70 | 8c b5 95 f0 3e | ........ ........ ........ ........ ........
71 | ec 8c 6d 95 f0 | ........ ........ ........ ........ ........
72 | b8 ec 23 6d 95 | ........ ........ ........ ........ ........
73 | 39 b8 3b 23 6d | ........ ........ ........ ........ ........
74 | 1a 39 2e 3b 23 | ........ ........ ........ ........ ........
75 | 37 1a 4e 2e 3b | ........ ........ ........ ........ ........
76 | f4 37 86 4e 2e | f0b47840 ........ ........ ........ ........
77 | c3 f4 cd 86 4e | bf36ae2b f0b47840 ........ ........ ........
78 | a1 c3 3d cd 86 | 9d148c09 bf36ae2b 3c2d1e10 ........ ........
79 | 11 a1 f0 3d cd | 10325477 9d148c09 efcdab8a 3c2d1e10 ........
80 | 99 11 68 f0 3d | 98badcff 10325477 67452302 efcdab8a 3c2d1e10
81 | 00 00 00 00 00 | 00000000 00000000 00000000 00000000 00000000
Maybe that result alone is not very helpful, but what about starting from single bits, and expanding it bit-by-bit? So, starting from SHA-1, simplified into single boolean values, it would take 16-bit chunk, will have 5-bit internal state A,B,C,D,E, and will produce 5-bit hash. Then, by adding a second bit, we will reach 10-bit hash. For the case above, 8-bit values can give us 40-bit hash. So, maybe by using that kind of expansion, there will be some hint? I will write some code to check it out.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
My bad about the OS arc bit confusion. But I'm not wrong about the collision, if you hash the Shakespeare to derive the address, but if you manage to get a hold of that address on bitcoin network, you'd have yourself a SHA-256 collision.
An SHA256 collision happens when two inputs give the same output-- different messages, same hash. If you hash a Shakespeare image or text, you need another different input to check for collision.

Thanks to the nature of 160 bit hashes in bitcoin, we can now safely collide with a 256 bit hash only by looking in 160 bit range.
If you happen to have two SHA256 hashes that begin with the same 160 first bits, it doesn't make it a collision.
full member
Activity: 161
Merit: 230
What do you even mean by "get a hold of that address on bitcoin network"? And how does something unrelated to SHA-256 result in a SHA-256 collision?

If you mean "generate address through some nonstandard means, then check if someone else used that address on the Bitcoin network", then the probability of that happening is exactly the same as if you generated a standard Bitcoin address and checked if that was used on the Bitcoin network, basically (number of addresses on the blockchain)/2^160, which would still be around 2^150, which is completely unlikely to happen by chance. And in any case, you would have a RIPEMD160 collision, not SHA256, since it is the RIPEMD160 function that would generate the same hash for two different inputs.
copper member
Activity: 1330
Merit: 899
🖤😏
My bad about the OS arc bit confusion. But I'm not wrong about the collision, if you hash the Shakespeare to derive the address, but if you manage to get a hold of that address on bitcoin network, you'd have yourself a SHA-256 collision. Thanks to the nature of 160 bit hashes in bitcoin, we can now safely collide with a 256 bit hash only by looking in 160 bit range.
full member
Activity: 161
Merit: 230
Well, you say we can't do RIPEMD-160 directly on public keys, well I have done it and have got valid addresses, FYI, all the "theories" about the possible collisions are inaccurate, almost all of the Y coordinates could be used as X coordinates for other addresses, and vice versa.

There are only 2^32 truly unique compressed addresses and 2^32 truly unique uncompressed addresses without a single collision, that's because of the nature of 64 bit architecture in computers. Unless you didn't know about the limits of physically possible collisions where you can't have any collision under 64 bit.


I just gave you an attack vector, which has nothing to do with bitcoin, it just happens that bitcoin has put itself in the middle of 2 hash collisions ( rather who ever designed them did ).

You should ignore me, I'm just a stupid troll.


Well, you "can" do anything. You could do RIPEMD-160 on the works of Shakespeare and it will be a "valid" address, but you won't have the private key for that address since no software support Shakespeare as the key. (And no Bitcoin node supports skipping the SHA256 step)

Also where do you get the 2^32 number from? And what does it have to do with the 64 bit architecture? That's like saying there are no human numbers above 9 because we only have the digits 0-9.

Bitcoin works just fine on certain 32 bit processors, the current version has an ARM32 download link.
copper member
Activity: 1330
Merit: 899
🖤😏
Well, you say we can't do RIPEMD-160 directly on public keys, well I have done it and have got valid addresses, FYI, all the "theories" about the possible collisions are inaccurate, almost all of the Y coordinates could be used as X coordinates for other addresses, and vice versa.


I just gave you an attack vector, which has nothing to do with bitcoin, it just happens that bitcoin has put itself in the middle of 2 hash collisions ( rather who ever designed them did ).

full member
Activity: 161
Merit: 230
Your post is very confusing so I'm not even sure what you're saying, and I think you're confused about how addresses are generated. The private key is made into a serialized public key (compressed or uncompressed), THEN it is sent through SHA-256 and THEN the result of that is sent through RIPEMD160. You can't pick, both hash algorithms are done in sequence. You never apply RIPEMD160 to the public key directly.

And here's the math:

There exists approx 2^256 different private keys, which result in 2^256 different uncompressed public keys, but also 2^256 different compressed public keys, for a total of 2^257 different public keys.

To get an address, first the public key is hashed with SHA-256. Due to the reduction from 2^257 to 2^256, each SHA-256 hash will have on average a collision with 1 other public key. Some might collide with 2 other keys, some will collide with none.

Then that SHA-256 hash is hashed with RIPEMD160. This is a reduction from 2^256 to 2^160, meaning that on average each SHA-256 hash will collide with 2^96 other addresses (because 256-160=96).
copper member
Activity: 1330
Merit: 899
🖤😏
I'm back with more questions 🤭.
In regards to private key collision, are we talking about 2^96 different private keys, 2^96 different public keys which only result in a single RIPEMD-160 ( Address )?

Would that mean 2^96 bitcoin public keys hash to the same SHA-256 hash value? I guess there are indeed 2^96 different public keys that their SHA-256 collides, because we can't mathematically derive 2 different addresses from 1 hash.

However there is also an option to directly use RIPEMD-160 on your public key and get 2 different addresses, but the blockchain doesn't know how to verify your ownership of the new address unless you tell the nodes/ miners to do RIP-160 directly and skip the SHA-256.

Now with the idea explained above, it opens up a window of collision attack on hash-160 and SHA-256 algos. In such a way where if you perform RIP-160 on your pub you would get an address e.g. ( 1digaranXXXXXXXXXXXXXXXXXXXsomething) then knowing the private/public keys of that address is equal to knowing that the SHA-256 hash of the pub key of that address collides with your original public key on RIPEMD-160 algo.

If I'm wrong, good for all, but if I'm right then this should be taken care of because if I could get this right, others might have already figured it out.
legendary
Activity: 3472
Merit: 10611
Surprisingly, it was confirmed on regtest. I didn't expect that, last time I checked P2SH addresses, there was a strict requirement that the underlying script has to be standard. I wonder, in which version that was changed, because I remember times, where I had problems with non-standard scripts under P2SH in the past.
It depends on the standard rule, there are other checks taking place in other places (not everything is checked in policy.cpp). For example the interpreter.cpp also performs certain checks on the scriptsig before it reaches the redeemscript and it could be rejecting the tx as non-standard there.
copper member
Activity: 821
Merit: 1992
Quote
My understanding is that the redeem script is not subjected to the usual standard rules that would reject the scripts in OP which is why I said "anyone".
It can be checked on regtest. First, generate some blocks:
Code:
dumpprivkey bcrt1qz5szl8r5ysxmcrfdggt84r83ewr9hy9k2qnmex
cVQHivxE1ZSJvX1xZxNRSzUY9j7ZUtFTQWPXbHEcZN1NkWPczSQe
generatetoaddress 101 bcrt1qz5szl8r5ysxmcrfdggt84r83ewr9hy9k2qnmex
Then, use that address with OP_ABS: 3QsT6Sast6ghfsjZ9VJj9u8jkM2qTfDgHV. Convert to regtest:
Code:
decodescript a914fe441065b6532231de2fac563152205ec4f59c7487
{
  "asm": "OP_HASH160 fe441065b6532231de2fac563152205ec4f59c74 OP_EQUAL",
  "desc": "addr(2NGRfABWuVZC3sfN6pcvbmr7zxhF1BTYSAw)#3xnzta3l",
  "address": "2NGRfABWuVZC3sfN6pcvbmr7zxhF1BTYSAw",
  "type": "scripthash"
}
decodescript 6e879169907c9087
{
  "asm": "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_ABS OP_SWAP OP_ABS OP_EQUAL",
  "desc": "raw(6e879169907c9087)#yaqxx9nt",
  "type": "nonstandard",
  "p2sh": "2NGRfABWuVZC3sfN6pcvbmr7zxhF1BTYSAw",
  "segwit": {
    "asm": "0 414fcb4322bbf4f5b89e94b0749b8504f61937ce8ed3cdee78a70f685420c822",
    "desc": "addr(bcrt1qg98uksezh060twy7jjc8fxu9qnmpjd7w3mfummnc5u8ks4pqeq3q6asxr9)#7zg82sfu",
    "hex": "0020414fcb4322bbf4f5b89e94b0749b8504f61937ce8ed3cdee78a70f685420c822",
    "address": "bcrt1qg98uksezh060twy7jjc8fxu9qnmpjd7w3mfummnc5u8ks4pqeq3q6asxr9",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2N6LJuD5PY3woKAZAN2qgpwwbC7wpfaJDWV"
  }
}
Send to that regtest address: 2NGRfABWuVZC3sfN6pcvbmr7zxhF1BTYSAw
Code:
decoderawtransaction 02000000000101c2c2f6a1760cad50e51f91dd112a0c3f1423e53d0b32106f922741e82368d35f0000000000fdffffff0191f1052a0100000017a914fe441065b6532231de2fac563152205ec4f59c748702473044022022b4fce5367029c66e1bfbe1615e584e393c516430966a22ad83eb415600190d02205ebb08eeee83e525af76f9a860c923af724bd6f00fabac390b44b0ec20d1bccd01210243b3106e0e478bbffa9561afc0caad73525ea1f09a763ff1b9b9e50fe591b9fdf4000000
{
  "txid": "cee6e8dd048868cb0a74855efeaecaeead3295a2ad8151818b9e62c4950550eb",
  "hash": "c23550c07178b00e28615e0c3bca518c87104c67993569117942ecc37a5c2143",
  "version": 2,
  "size": 192,
  "vsize": 111,
  "weight": 441,
  "locktime": 244,
  "vin": [
    {
      "txid": "5fd36823e84127926f10320b3de523143f0c2a11dd911fe550ad0c76a1f6c2c2",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "3044022022b4fce5367029c66e1bfbe1615e584e393c516430966a22ad83eb415600190d02205ebb08eeee83e525af76f9a860c923af724bd6f00fabac390b44b0ec20d1bccd01",
        "0243b3106e0e478bbffa9561afc0caad73525ea1f09a763ff1b9b9e50fe591b9fd"
      ],
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 49.99999889,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 fe441065b6532231de2fac563152205ec4f59c74 OP_EQUAL",
        "desc": "addr(2NGRfABWuVZC3sfN6pcvbmr7zxhF1BTYSAw)#3xnzta3l",
        "hex": "a914fe441065b6532231de2fac563152205ec4f59c7487",
        "address": "2NGRfABWuVZC3sfN6pcvbmr7zxhF1BTYSAw",
        "type": "scripthash"
      }
    }
  ]
}
Then, we can try spending those coins, in the same way as it was demonstrated on mainnet. First, we prepare our transaction, sending it back to a new address:
Code:
dumpprivkey bcrt1qj9lfeupv50xg3cym08qfqwe5fxcxenyr2a5h67
cT5k4GH315YFRKiy2VGxG8DVFcXAh9wF7nPZnanMjbsgEd9PypWn
createrawtransaction "[{\"txid\":\"cee6e8dd048868cb0a74855efeaecaeead3295a2ad8151818b9e62c4950550eb\",\"vout\":0}]" "[{\"bcrt1qj9lfeupv50xg3cym08qfqwe5fxcxenyr2a5h67\":49.99999000}]" 0 true
0200000001eb500595c4629e8b815181ada29532adeecaaefe5e85740acb688804dde8e6ce0000000000fdffffff0118ee052a01000000160014917e9cf02ca3cc88e09b79c0903b3449b06ccc8300000000
decoderawtransaction 0200000001eb500595c4629e8b815181ada29532adeecaaefe5e85740acb688804dde8e6ce0000000000fdffffff0118ee052a01000000160014917e9cf02ca3cc88e09b79c0903b3449b06ccc8300000000
{
  "txid": "18c65cd8c233106ab9156c4589e65b20fdcbcb3d8cda4c2f87e1b73fdf7ac55d",
  "hash": "18c65cd8c233106ab9156c4589e65b20fdcbcb3d8cda4c2f87e1b73fdf7ac55d",
  "version": 2,
  "size": 82,
  "vsize": 82,
  "weight": 328,
  "locktime": 0,
  "vin": [
    {
      "txid": "cee6e8dd048868cb0a74855efeaecaeead3295a2ad8151818b9e62c4950550eb",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 49.99999000,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 917e9cf02ca3cc88e09b79c0903b3449b06ccc83",
        "desc": "addr(bcrt1qj9lfeupv50xg3cym08qfqwe5fxcxenyr2a5h67)#q8c9z43p",
        "hex": "0014917e9cf02ca3cc88e09b79c0903b3449b06ccc83",
        "address": "bcrt1qj9lfeupv50xg3cym08qfqwe5fxcxenyr2a5h67",
        "type": "witness_v0_keyhash"
      }
    }
  ]
}
Our spending script would be "OP_1NEGATE OP_1", so "4f51" should do the trick:
Code:
decoderawtransaction 0200000001eb500595c4629e8b815181ada29532adeecaaefe5e85740acb688804dde8e6ce000000000b4f51086e879169907c9087fdffffff0118ee052a01000000160014917e9cf02ca3cc88e09b79c0903b3449b06ccc8300000000
{
  "txid": "726c8e7426506f697e82e897d97c04eb0aae9f55f98dad3dee5c14912af54740",
  "hash": "726c8e7426506f697e82e897d97c04eb0aae9f55f98dad3dee5c14912af54740",
  "version": 2,
  "size": 93,
  "vsize": 93,
  "weight": 372,
  "locktime": 0,
  "vin": [
    {
      "txid": "cee6e8dd048868cb0a74855efeaecaeead3295a2ad8151818b9e62c4950550eb",
      "vout": 0,
      "scriptSig": {
        "asm": "-1 1 6e879169907c9087",
        "hex": "4f51086e879169907c9087"
      },
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 49.99999000,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 917e9cf02ca3cc88e09b79c0903b3449b06ccc83",
        "desc": "addr(bcrt1qj9lfeupv50xg3cym08qfqwe5fxcxenyr2a5h67)#q8c9z43p",
        "hex": "0014917e9cf02ca3cc88e09b79c0903b3449b06ccc83",
        "address": "bcrt1qj9lfeupv50xg3cym08qfqwe5fxcxenyr2a5h67",
        "type": "witness_v0_keyhash"
      }
    }
  ]
}
And then, we can try to send this transaction:
Code:
sendrawtransaction 0200000001eb500595c4629e8b815181ada29532adeecaaefe5e85740acb688804dde8e6ce000000000b4f51086e879169907c9087fdffffff0118ee052a01000000160014917e9cf02ca3cc88e09b79c0903b3449b06ccc8300000000
726c8e7426506f697e82e897d97c04eb0aae9f55f98dad3dee5c14912af54740
Then, we can try to get it confirmed:
Code:
dumpprivkey bcrt1qv7kur5h9h3q74sz5p53q9uytktzzvrhym4qnm3
cNZeS6Mddi2wk7zcvxbEEhqd4oKwjEmSfs7qWdvSh6iRdHteJM7W
generatetoaddress 6 bcrt1qv7kur5h9h3q74sz5p53q9uytktzzvrhym4qnm3
Surprisingly, it was confirmed on regtest. I didn't expect that, last time I checked P2SH addresses, there was a strict requirement that the underlying script has to be standard. I wonder, in which version that was changed, because I remember times, where I had problems with non-standard scripts under P2SH in the past.
legendary
Activity: 3346
Merit: 3130
Can someone please explain what happens if there is a collision?
If there is a collision that means someone could have 2 different private keys for the same address.

How can someone exploit it?
With brute force, let's say your target is X RIPEMD160, and you test the hex private keys one by one, then you could find any address searching in 10% of all the total private keys.

How can we stop the exploit?
We can't, but to exploit this is just theoretical, doing it in real life with our current hardware would take too many years, I don't even worth the try.

Is it safe to publish such collisions like what the OP is asking?
Yes, it's safe, maybe 1 address gets compromised, but it will prove the collisions are real because we know they are real but no one has got one yet.

legendary
Activity: 3472
Merit: 10611
Not anyone, but only miners, because those scripts are non-standard. It would work for anyone if those puzzles would use P2WSH or P2TR instead of P2SH.
My understanding is that the redeem script is not subjected to the usual standard rules that would reject the scripts in OP which is why I said "anyone". Although I'm not 100% sure but according to the code it seems like the only "standard" check on redeem scripts is their max sigop count and nothing else:
https://github.com/bitcoin/bitcoin/blob/2a0c05defd32c37f083fa2cc890e03aecc451555/src/policy/policy.cpp#L201-L203
copper member
Activity: 906
Merit: 2258
Quote
Is there any tool that I could use offline to experiment on BTC's SHA-256 and both 160 hash functions on windows?
The easiest way is to write that tool in any programming language. Because some tools that are available, can give you the final hash, but won't let you see internal state of hash functions. And writing that is not hard: optimizing and making it fast enough for mining is hard, but if you are interested only in mathematical aspects of hash functions, then you can execute it round-by-round, and you don't need any optimizations, at least not at the beginning. Also, brute-forcing is not the way to go, so you are going to write some code anyway, if you want to get any of those coins.

Usually to understand hash functions, you don't need to go beyond a single block. That means, for SHA-256, you don't need longer messages than 512 bits if you want to try some simple attacks. The same for SHA-1, and for many other Merkle–Damgård hash functions. Also, if you will have some short implementation of SHA-1, then you can easily change how it works, and see how those changes can propagate.

Some example of C++ implementation for SHA-1, with displaying internal status, round-by-round:
Code:
#include 
#include
#include
#include

std::string toString32(std::uint32_t value)
{
    std::ostringstream out;
    out.width(8);
    out.fill('0');
    out<    return out.str();
}

std::uint32_t rotateLeft(std::uint32_t value,std::size_t n)
{
    return (value<<(n%32))|(value>>(32-(n%32)));
}

std::uint32_t f1(std::uint32_t b,std::uint32_t c,std::uint32_t d)
{
    return (b&c)|((~b)&d);
}

std::uint32_t f2(std::uint32_t b,std::uint32_t c,std::uint32_t d)
{
    return b^c^d;
}

std::uint32_t f3(std::uint32_t b,std::uint32_t c,std::uint32_t d)
{
    return (b&c)|(b&d)|(c&d);
}

void printRound(std::size_t i,std::uint32_t a,std::uint32_t b,std::uint32_t c,std::uint32_t d,std::uint32_t e,
                std::uint32_t f,std::uint32_t k,std::uint32_t w)
{
    std::cout<    if(i<80)
    {
        std::cout<<" | "<    }
    std::cout<<'\n';
}

#define PRINT_ROUND(i) printRound((i),a[i],b[i],c[i],d[i],e[i],f[i],k[i],w[i])

int main()
{
    std::uint32_t a[82],b[82],c[82],d[82],e[82];
    a[0]=0x67452301;
    b[0]=0xefcdab89;
    c[0]=0x98badcfe;
    d[0]=0x10325476;
    e[0]=0xc3d2e1f0;
    std::uint32_t w[82]=
    {
        0x80000000,0x00000000,0x00000000,0x00000000,
        0x00000000,0x00000000,0x00000000,0x00000000,
        0x00000000,0x00000000,0x00000000,0x00000000,
        0x00000000,0x00000000,0x00000000,0x00000000
    };
    for(std::size_t i=16;i<80;++i)
    {
        w[i]=rotateLeft(w[i-3]^w[i-8]^w[i-14]^w[i-16],1);
    }
    std::uint32_t f[82],k[82];
    std::cout<<"i       a[i]     b[i]     c[i]     d[i]     e[i]       f[i]     k[i]     w[i]    \n";
    std::cout<<"---------------------------------------------------------------------------------\n";
    for(std::size_t i=0;i<20;++i)
    {
        f[i]=f1(b[i],c[i],d[i]);
        k[i]=0x5a827999;
        PRINT_ROUND(i);
        a[i+1]=rotateLeft(a[i],5)+f[i]+e[i]+k[i]+w[i];
        b[i+1]=a[i];
        c[i+1]=rotateLeft(b[i],30);
        d[i+1]=c[i];
        e[i+1]=d[i];
    }
    for(std::size_t i=20;i<40;++i)
    {
        f[i]=f2(b[i],c[i],d[i]);
        k[i]=0x6ed9eba1;
        PRINT_ROUND(i);
        a[i+1]=rotateLeft(a[i],5)+f[i]+e[i]+k[i]+w[i];
        b[i+1]=a[i];
        c[i+1]=rotateLeft(b[i],30);
        d[i+1]=c[i];
        e[i+1]=d[i];
    }
    for(std::size_t i=40;i<60;++i)
    {
        f[i]=f3(b[i],c[i],d[i]);
        k[i]=0x8f1bbcdc;
        PRINT_ROUND(i);
        a[i+1]=rotateLeft(a[i],5)+f[i]+e[i]+k[i]+w[i];
        b[i+1]=a[i];
        c[i+1]=rotateLeft(b[i],30);
        d[i+1]=c[i];
        e[i+1]=d[i];
    }
    for(std::size_t i=60;i<80;++i)
    {
        f[i]=f2(b[i],c[i],d[i]);
        k[i]=0xca62c1d6;
        PRINT_ROUND(i);
        a[i+1]=rotateLeft(a[i],5)+f[i]+e[i]+k[i]+w[i];
        b[i+1]=a[i];
        c[i+1]=rotateLeft(b[i],30);
        d[i+1]=c[i];
        e[i+1]=d[i];
    }
    PRINT_ROUND(80);
    a[81]=a[80]+a[0];
    b[81]=b[80]+b[0];
    c[81]=c[80]+c[0];
    d[81]=d[80]+d[0];
    e[81]=e[80]+e[0];
    PRINT_ROUND(81);
}
And then, you can see exactly, step-by-step, how SHA-1 of the empty message is changed into its hash:
Code:
i       a[i]     b[i]     c[i]     d[i]     e[i]       f[i]     k[i]     w[i]    
---------------------------------------------------------------------------------
0 67452301 efcdab89 98badcfe 10325476 c3d2e1f0 | 98badcfe 5a827999 80000000
1 1fb498b3 67452301 7bf36ae2 98badcfe 10325476 | fbfbfefe 5a827999 00000000
2 5d43e370 1fb498b3 59d148c0 7bf36ae2 98badcfe | 79d36ac0 5a827999 00000000
3 158d2f62 5d43e370 c7ed262c 59d148c0 7bf36ae2 | 45d12aa0 5a827999 00000000
4 cdecfb5d 158d2f62 1750f8dc c7ed262c 59d148c0 | d760284c 5a827999 00000000
5 4953565e cdecfb5d 85634bd8 1750f8dc c7ed262c | 97704bd8 5a827999 00000000
6 e44ab766 4953565e 737b3ed7 85634bd8 1750f8dc | c5731fd6 5a827999 00000000
7 c09d7f27 e44ab766 9254d597 737b3ed7 85634bd8 | 93719d97 5a827999 00000000
8 87074800 c09d7f27 b912add9 9254d597 737b3ed7 | 9250ad91 5a827999 00000000
9 41376611 87074800 f0275fc9 b912add9 9254d597 | b817edd9 5a827999 00000000
10 cbdbff31 41376611 21c1d200 f0275fc9 b912add9 | b1015bc8 5a827999 00000000
11 40166973 cbdbff31 504dd984 21c1d200 f0275fc9 | 6049d900 5a827999 00000000
12 adc0e0ca 40166973 72f6ffcc 504dd984 21c1d200 | 505ff9c4 5a827999 00000000
13 84c05eb2 adc0e0ca d0059a5c 72f6ffcc 504dd984 | d2369f4c 5a827999 00000000
14 1512c8b9 84c05eb2 ab703832 d0059a5c 72f6ffcc | d045987e 5a827999 00000000
15 40182905 1512c8b9 a13017ac ab703832 d0059a5c | ab7030aa 5a827999 00000000
16 d8fd6547 40182905 4544b22e a13017ac ab703832 | e12036ac 5a827999 00000001
17 06bf9173 d8fd6547 50060a41 4544b22e a13017ac | 55049269 5a827999 00000000
18 28a9520e 06bf9173 f63f5951 50060a41 4544b22e | 563f1b51 5a827999 00000000
19 0b3088dd 28a9520e c1afe45c f63f5951 50060a41 | d6bf495d 5a827999 00000002
20 e758e8da 0b3088dd 8a2a5483 c1afe45c f63f5951 | 40b53802 6ed9eba1 00000000
21 90eb9850 e758e8da 42cc2237 8a2a5483 c1afe45c | 2fbe9e6e 6ed9eba1 00000000
22 7dbb787d 90eb9850 b9d63a36 42cc2237 8a2a5483 | 6bf18051 6ed9eba1 00000004
23 1c64d028 7dbb787d 243ae614 b9d63a36 42cc2237 | e057a45f 6ed9eba1 00000000
24 1e97b73a 1c64d028 5f6ede1f 243ae614 b9d63a36 | 6730e823 6ed9eba1 00000002
25 62d7f53f 1e97b73a 0719340a 5f6ede1f 243ae614 | 46e05d2f 6ed9eba1 00000008
26 34f3d6d8 62d7f53f 87a5edce 0719340a 5f6ede1f | e26b2cfb 6ed9eba1 00000000
27 4f2ed1c1 34f3d6d8 d8b5fd4f 87a5edce 0719340a | 6be3c659 6ed9eba1 00000000
28 c7b11e2d 4f2ed1c1 0d3cf5b6 d8b5fd4f 87a5edce | 9aa7d938 6ed9eba1 00000010
29 874b786f c7b11e2d 53cbb470 0d3cf5b6 d8b5fd4f | 99465feb 6ed9eba1 00000000
30 ca4556cb 874b786f 71ec478b 53cbb470 0d3cf5b6 | a56c8b94 6ed9eba1 0000000a
31 6a2e466e ca4556cb e1d2de1b 71ec478b 53cbb470 | 5a7bcf5b 6ed9eba1 00000020
32 62ea3d59 6a2e466e f29155b2 e1d2de1b 71ec478b | 796dcdc7 6ed9eba1 00000006
33 b77bac25 62ea3d59 9a8b919b f29155b2 e1d2de1b | 0af0f970 6ed9eba1 00000000
34 4b1347e2 b77bac25 58ba8f56 9a8b919b f29155b2 | 754ab2e8 6ed9eba1 00000040
35 391ef0c4 4b1347e2 6ddeeb09 58ba8f56 9a8b919b | 7e7723bd 6ed9eba1 00000008
36 abbab988 391ef0c4 92c4d1f8 6ddeeb09 58ba8f56 | c604ca35 6ed9eba1 00000028
37 04f07669 abbab988 0e47bc31 92c4d1f8 6ddeeb09 | 3739d441 6ed9eba1 00000080
38 b201788b 04f07669 2aeeae62 0e47bc31 92c4d1f8 | 2059643a 6ed9eba1 00000008
39 62273351 b201788b 413c1d9a 2aeeae62 0e47bc31 | d9d3cb73 6ed9eba1 00000000
40 9bdbdd71 62273351 ec805e22 413c1d9a 2aeeae62 | 60241f12 8f1bbcdc 00000108
41 95aa398b 9bdbdd71 5889ccd4 ec805e22 413c1d9a | d889dc70 8f1bbcdc 00000000
42 5e28e858 95aa398b 66f6f75c 5889ccd4 ec805e22 | 54aafddc 8f1bbcdc 000000a0
43 95642485 5e28e858 e56a8e62 66f6f75c 5889ccd4 | 666aee58 8f1bbcdc 00000200
44 fa950aba 95642485 178a3a16 e56a8e62 66f6f75c | 956a2e06 8f1bbcdc 00000064
45 de1e3a01 fa950aba 65590921 178a3a16 e56a8e62 | 77990a32 8f1bbcdc 00000000
46 afe695ab de1e3a01 bea542ae 65590921 178a3a16 | fe1d0a21 8f1bbcdc 00000408
47 a195ba90 afe695ab 77878e80 bea542ae 65590921 | bfa786aa 8f1bbcdc 00000088
48 e6d39f43 a195ba90 ebf9a56a 77878e80 bea542ae | e395ae80 8f1bbcdc 0000029c
49 0bca9922 e6d39f43 28656ea4 ebf9a56a 77878e80 | eaf1af62 8f1bbcdc 00000800
50 6ae826ff 0bca9922 f9b4e7d0 28656ea4 ebf9a56a | 29e4efa0 8f1bbcdc 00000080
51 01ff3253 6ae826ff 82f2a648 f9b4e7d0 28656ea4 | eaf0a6d8 8f1bbcdc 00000028
52 e2581ce0 01ff3253 daba09bf 82f2a648 f9b4e7d0 | 82fa225b 8f1bbcdc 00001088
53 56ce73ab e2581ce0 c07fcc94 daba09bf 82f2a648 | c27a0cb4 8f1bbcdc 00000000
54 ae56e542 56ce73ab 38960738 c07fcc94 daba09bf | 50de47b8 8f1bbcdc 00000a40
55 8590c0e8 ae56e542 d5b39cea 38960738 c07fcc94 | bc96856a 8f1bbcdc 00002000
56 be4a4bea 8590c0e8 ab95b950 d5b39cea 38960738 | 859198e8 8f1bbcdc 00000668
57 168ce0bb be4a4bea 2164303a ab95b950 d5b39cea | ab44397a 8f1bbcdc 00000080
58 e1afab22 168ce0bb af9292fa 2164303a ab95b950 | 2784b0ba 8f1bbcdc 00004088
59 982bcbca e1afab22 c5a3382e af9292fa 2164303a | e5a3ba2a 8f1bbcdc 00000880
60 9b9d2913 982bcbca b86beac8 c5a3382e af9292fa | e5e3192c ca62c1d6 000028c8
61 d37db937 9b9d2913 a60af2f2 b86beac8 c5a3382e | 85fc3129 ca62c1d6 00008000
62 85b9d227 d37db937 e6e74a44 a60af2f2 b86beac8 | 93900181 ca62c1d6 000008a8
63 cd98fbb7 85b9d227 f4df6e4d e6e74a44 a60af2f2 | 9781f62e ca62c1d6 00000080
64 bb0f226f cd98fbb7 e16e7489 f4df6e4d e6e74a44 | d829e173 ca62c1d6 000108e8
65 eb59446c bb0f226f f3663eed e16e7489 f4df6e4d | a907680b ca62c1d6 00000000
66 d37225cb eb59446c eec3c89b f3663eed e16e7489 | f6fcb21a ca62c1d6 0000a000
67 111341f3 d37225cb 3ad6511b eec3c89b f3663eed | 0767bc4b ca62c1d6 00020080
68 e79afbf0 111341f3 f4dc8972 3ad6511b eec3c89b | df19999a ca62c1d6 00006400
69 8ba00627 e79afbf0 c444d07c f4dc8972 3ad6511b | d702a2fe ca62c1d6 00000000
70 503c7ae0 8ba00627 39e6befc c444d07c f4dc8972 | 760268a7 ca62c1d6 00040800
71 3cd517f9 503c7ae0 e2e80189 39e6befc c444d07c | 8b32c595 ca62c1d6 00008800
72 b47ddf0e 3cd517f9 140f1eb8 e2e80189 39e6befc | ca3208c8 ca62c1d6 00029c10
73 5e3a0780 b47ddf0e 4f3545fe 140f1eb8 e2e80189 | ef478448 ca62c1d6 00080000
74 63db37b2 5e3a0780 ad1f77c3 4f3545fe 140f1eb8 | bc1035bd ca62c1d6 00008080
75 15e98d17 63db37b2 178e81e0 ad1f77c3 4f3545fe | d94ac191 ca62c1d6 00002820
76 b0149467 15e98d17 98f6cdec 178e81e0 ad1f77c3 | 9a91c11b ca62c1d6 001088c0
77 14b7106a b0149467 c57a6345 98f6cdec 178e81e0 | ed983ace ca62c1d6 00000000
78 666b8bc6 14b7106a ec052519 c57a6345 98f6cdec | 3dc85636 ca62c1d6 000a40c0
79 6e9d9f84 666b8bc6 852dc41a ec052519 c57a6345 | 0f436ac5 ca62c1d6 00200080
80 72f480ed 6e9d9f84 999ae2f1 852dc41a ec052519
81 da39a3ee 5e6b4b0d 3255bfef 95601890 afd80709
Then, you can compare it with other tools, and check that SHA-1("")=da39a3ee5e6b4b0d3255bfef95601890afd80709, that means all computations are correct.

Edit:
Quote
I tried different online services and all of their output differed from bitcoin's. That's why I asked.
I guess you used text mode, while Bitcoin uses binary mode. For example, if you have "12345678" as some message to be hashed, then your message probably was in this form:
Code:
31323334 35363738 80000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000040
But what you should use, was that form:
Code:
12345678 80000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000020
And then, you can compare those hashes:
Code:
SHA-1("12345678")=7c222fb2927d828af22f592134e8932480637c0d
SHA-1(0x12345678)=9bce73d0c8b9eca4f24154f3bd3b8aa473b1c3a9
Another thing is endianness. For example, maybe you used 0x78563412, while you should use 0x12345678.

To move things forward, I can give you the Genesis Block hash as an example of how things should be computed:
Code:
SHA-256(0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c)=af42031e805ff493a07341e2f74ff58149d22ab9ba19f61343e2c86c71c5d66d
SHA-256(af42031e805ff493a07341e2f74ff58149d22ab9ba19f61343e2c86c71c5d66d)=6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
And then, you can notice that the result of SHA-256 is reversed. The reason is that little-endian is used in many places, for example in hashes. And that's why you have to change endianness many times, and process hashes byte-by-byte, and put them in reversed order. The same is true for many other fields, for example you can see 0x01000000 as version, that means 0x00000001, because of endianness.

Edit: Also, I made some introduction to hash functions in another topic, it can be useful if you want to try some basic attacks: https://bitcointalksearch.org/topic/why-hash-functions-are-safe-5402178
copper member
Activity: 821
Merit: 1992
Quote
I can only think of weird ways of abusing the scripts but they all involve you stealing your own coins which make no sense.
It is also about spending funds from multisig addresses. And in case of LN or other networks, where public keys are known, it is possible to prepare the right script upfront, because you usually know the public key upfront.

Quote
If you publish the collision, anybody would be able to spend the reward of these puzzles.
Not anyone, but only miners, because those scripts are non-standard. It would work for anyone if those puzzles would use P2WSH or P2TR instead of P2SH.

Quote
the algorithm is defined to let you compute the hash of a 1 bit input but implementations don't let you and it has to be padded to 8 bits
It depends which implementations: https://sha256algorithm.com/
Code:
SHA-256("")=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
SHA-256(singleZeroBit)=bd4f9e98beb68c6ead3243b1b4c7fed75fa4feaab1f84795cbd8a98676a2a375
SHA-256(singleOneBit)=b9debf7d52f36e6468a54817c1fa071166c3a63d384850e1575b42f702dc5aa1
copper member
Activity: 1330
Merit: 899
🖤😏
Btw, why bitcoin's SHA256 is different, is it because it hashes bytes?
The only difference is the size and the algorithm, otherwise all hash functions deal with bytes although the algorithm is defined to work with octet strings, they are all implement to deal with full octets (ie. the algorithm is defined to let you compute the hash of a 1 bit input but implementations don't let you and it has to be padded to 8 bits).
Is there any tool that I could use offline to experiment on BTC's SHA-256 and both 160 hash functions on windows? (Lol). I tried different online services and all of their output differed from bitcoin's. That's why I asked.

@long inactive OP, at the time of creating the reward transactions, you spent around 0.5BTC as a reward for something that challenging and at the time price of 0.5 bitcoin was less than 100$, was this a mockery of some sort or you guys were serious?
legendary
Activity: 3472
Merit: 10611
Can someone please explain what happens if there is a collision? How can someone exploit it?
I can only think of weird ways of abusing the scripts but they all involve you stealing your own coins which make no sense. That is because in a collision you have to create two different messages that produce the same hash, the hash that would be used in a pay to script script meaning you are creating the output script yourself.

Quote
How can we stop the exploit?
By changing the hash algorithms that are used, for example by switching to version 3 of SHA.

Quote
Is it safe to publish such collisions like what the OP is asking?
If you publish the collision, anybody would be able to spend the reward of these puzzles. That's about it.

Quote
Btw, why bitcoin's SHA256 is different, is it because it hashes bytes?
The only difference is the size and the algorithm, otherwise all hash functions deal with bytes although the algorithm is defined to work with octet strings, they are all implement to deal with full octets (ie. the algorithm is defined to let you compute the hash of a 1 bit input but implementations don't let you and it has to be padded to 8 bits).
copper member
Activity: 1330
Merit: 899
🖤😏
Can someone please explain what happens if there is a collision? How can someone exploit it? How can we stop the exploit? Is it safe to publish such collisions like what the OP is asking?  Btw, why bitcoin's SHA256 is different, is it because it hashes bytes?
Since this is technical I don't know where else to ask.
copper member
Activity: 821
Merit: 1992
Quote
That should give us some starting points on how to look for collisions in our real EC, right?
No, because those things are more complex than that, and your changes would not propagate in the way you want. For example, you can take the first 32 bits of SHA-256, and try to find preimages with all zeroes. In practice, every Bitcoin header is a matching preimage for such "fake hash function". But it won't push you any further, you will get a random matching value (called nonce), that will be useless in the real hash function, because it will be still only partial preimage, and won't give you any hints for full preimage.

It is like trying to break RSA by using low numbers, and thinking that if you can factorize a small number like 323 into two primes, 17 and 19, then you can do the same on bigger numbers. You cannot, because you need a better algorithm, and your simplified solution will not give you any hints.

Even worse, some inefficient algorithms will give you some answers in a reasonable time, so you won't improve them if you stay on lower numbers. For example, if you will use some fake EC y^2=x^3+7, with p=67 and n=79, then to find an inverse of a number, you don't even need to use Extended Euclidean algorithm, because for such low numbers, bruteforcing every combination will work. So, you won't encounter some problems on smaller numbers, that you will encounter on bigger ones.

Another example is trying to use less bits in a hash function. If you have SHA-1, you have IV equal to "0x67452301,0xefcdab89,0x98badcfe,0x10325476,0xc3d2e1f0", and you have k-values equal to "0x5a827999,0x6ed9eba1,0x8f1bbcdc,0xca62c1d6". There are three types of left rotations, equal to "1,5,30". You can switch from 32-bit values into 8-bit values, and produce 40-bit hashes, instead of 160-bit hashes. You can use IV equal to "0x67,0xef,0x98,0x10,0xc3", k-values equal to "0x5a,0x6e,0x8f,0xca", and left rotations, equal to "1,5,6". Then, you can produce a message, where w-values will be also 8-bit. After that, you can find some 128-bit chunk with many leading zeroes:
Code:
00 2e 35 3c
f9 80 00 00
00 00 00 00
00 00 00 28
It has "0000000093" hash, so it has eight leading nibbles, that means at least 32 leading zero bits. So far so good, but then, the question is, how to use that in real SHA-1, and produce an equivalent, so a hash with 128 leading zero bits? As I said, you will have only a random message, it won't help you in that case. And even if you check 2^40 combinations to find a full 40-bit preimage in this fake hash, it won't help you to get closer to the real 160-bit preimage, because even if many SHA-1 properties are preserved, the avalanche effect will make a complete mess, and a single different computation in the middle, will alter the whole result.
copper member
Activity: 1330
Merit: 899
🖤😏
Hi inactive devs, 🤨 are you an MCU fan? Then you should know the term "what if?". I don't care if my suggestion is stupid or not because I can't tell if it is, that's why I'm posting it here.

Regarding collisions, "what if" we could create our own fake EC, base58, hash160, using imaginary and rigged numbers and then generate our own collisions, like a billion private key matching an address. We could then apply the rules and standards of the real EC to our fake EC to see how our rigged collisions spread out through the curve, we wouldn't be able to map them directly to the real private keys of our real EC, but we could see how our fake numbers react and behave when introduced to the curve.

That should give us some starting points on how to look for collisions in our real EC, right?

Stay tuned for more earth shattering discoveries.🤭
Thank you for reading my half baked proposal.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
The addresses are not at risk of being swiped by internet surfers as long as the researcher claims the rewards from the script before disclosing the collision - since the act of spending from one of these addresses also happens to be a practical collision demonstration as well.

So I don't see the big fuss about any of this.
copper member
Activity: 821
Merit: 1992
Quote
The point is to reward the person who found the collision. Not just someone, because someone else found a collision.
There are some things to distinguish here:
1) If we want to reward the winner, and not reveal the solution, then the proof should be wrapped, for example by operating on public keys, to reach some equation, which will correspond to the situation, where the same algorithm will be performed directly on the private keys.
2) If we want to reward the winner, and also reveal the solution, then it should be two-step: first, the reward should be allocated to the winner, and then that reward should be claimed after getting enough confirmations, and that claim should require revealing the solution.
3) It is hard to make sure who really found the solution. Even in that case of SHA-1, I don't think that reward was taken by the authors of the research. Changing that requires wrapping the solution, and that requires some tricks like homomorphic encryption or zero knowledge proofs.

Quote
What do you mean?
If you have P2WSH or P2TR, then you can spend some custom script. If you have P2SH, then standardness rules apply. Your script under P2SH has to be standard if used as a raw script. If it is not, then by default your transaction will be rejected as non-standard. So it is not "everyone's bitcoin for a while", but only "all miners' bitcoin for a while".

Quote
The only disadvantage is that it limits you try with a public key and not with any two possible messages.
This significantly slows down the whole process. I guess even if SHA-1 collisions are publicly known, it is much harder to do the same for public keys, and I guess today there are still no such collisions known. For now, even 64-bit public key is still available, so it is very hard limitation. You can also look at some collisions and their sizes to see that the structure of the messages is very specific, even limiting it by requiring any 512-bit value would be a very hard limitation, because it would limit the attack to a single block of SHA-1.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
No, because the point is to reward someone for finding a collision.
The point is to reward the person who found the collision. Not just someone, because someone else found a collision.

For the old address types, it is definitely not "everyone's bitcoin for a while", just because of standardness rules.
What do you mean? Isn't it standard to replace-by-fee a transaction that spends that puzzle-output? Or just double-spend it in another manner, before it gets confirmed.

For example, elliptic curves provide enough functionalities to handle 256-bit numbers directly, so something with OP_CHECKSIG could be done here, not to require the solution to be some valid key, but instead to force doing computations on public keys, without revealing private keys.
There's no private key here neither. Just a pre-image and its hash. A fairer way to setup such puzzle is to find two values that lead to the same hash, one of which is a public key that is provably owned by the solver.

Here's the locking script that does it:
Code:
OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_2DUP OP_SHA256 OP_SWAP OP_SHA256 OP_EQUALVERIFY OP_DROP OP_CHECKSIG

With input (unlocking script):
Code:
  

Once executed, it'll look like this, assuming signature is valid and SHA256(pubKey) = SHA256(x):
Code:
  
OP_2DUP:
OP_EQUAL: 0
OP_NOT: 1
OP_VERIFY:
OP_2DUP:
OP_SHA256:
OP_SWAP:
OP_SHA256:
OP_EQUALVERIFY:
OP_DROP:
OP_CHECKSIG: 1

That way, the solver can spend the output, knowing that there's nobody who can double-spend it. The only disadvantage is that it limits you try with a public key and not with any two possible messages.
copper member
Activity: 821
Merit: 1992
Quote
Isn't this whole thing pointless?
No, because the point is to reward someone for finding a collision. In centralized solutions, you can claim that you solved for example some mathematical problem, but then it has to be verified by mathematicians, and they can give you some reward or not, they can always disagree, even if you are technically right. Here, it is pretty clear: if you unlock the script, then you can claim the reward, no matter what, and no centralized entity can decide that "you shouldn't get it, because I don't like you, or because I don't like your solution, even if it is correct, because I had something else in mind, didn't expect that, whatever". See: Vertical Castling in Chess.

Quote
If you find a hash collision, and spend the bitcoin, it is potentially everyone's bitcoin for a while, because you've revealed the pre-image.
For the old address types, it is definitely not "everyone's bitcoin for a while", just because of standardness rules. But for P2WSH and P2TR, yes, it is.

Quote
In fact, nobody but the mining pool owners can actually claim the reward.
Still, the reward will always be paid if the solution will be revealed. But yes, it can be improved by wrapping that over some other kind of proofs. For example, elliptic curves provide enough functionalities to handle 256-bit numbers directly, so something with OP_CHECKSIG could be done here, not to require the solution to be some valid key, but instead to force doing computations on public keys, without revealing private keys. And the same for the famous puzzle: it can be improved by creating some kind of range proof, to prove that the private key has for example only 64 bits, without revealing it.

Quote
Even they have a pressure on who's going to mine it first.
You can say the same about every mined block. We currently have 6.25 BTC plus fees, and the pressure is the same for that reward. If you have 6.50 BTC in the first block and 6.30 BTC for the second block, then you can still pick transactions with the highest fees, and for example get 6.51 BTC in reorged block (it depends on details like transaction sizes).

Quote
In fact, with the computational power one pool might have, it is trivial to reorg the chain by 1 block, just to steal that reward from another mining pool.
You can say the same when the basic block reward will drop to zero. Miners will then decide if they want to honestly build the chain on top of the latest block, or maybe reorg it, and get the highest fees from both blocks. And that situation is not really that different than a situation where someone sends 50 BTC in fees, then that spike belongs to the miners, and then miners are also incentivized to reorg the chain, and to fight for that reward. And that's why "coinbase coverage" is important: if the coinbase reward is 7 BTC, then if you want to send 700 BTC, you need 700/7=100 blocks to be absolutely sure that dishonest miners will definitely give up (the probability is worse, but I think most people will stick with simple maths, instead of using formulas from the whitepaper to calculate Poisson distribution correctly).
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Isn't this whole thing pointless?

If you find a hash collision, and spend the bitcoin, it is potentially everyone's bitcoin for a while, because you've revealed the pre-image. In fact, nobody but the mining pool owners can actually claim the reward. Even they have a pressure on who's going to mine it first. In fact, with the computational power one pool might have, it is trivial to reorg the chain by 1 block, just to steal that reward from another mining pool.
legendary
Activity: 3038
Merit: 4418
Crypto Swap Exchange
Here you go.

https://block.d.evco.in/tx/e61339a40aa4e90e983fe0d64cf09eed5fa1e6eac227b6761f06ac7af1929baf

Not sure how to redeem myself. But there's the same pubkey as BTC Block 0.
The block of that coin merely sends the block rewards to the same address as Bitcoin's genesis block. It doesn't matter if they have the key pair or not and it is not a collision either.

It's based on Bitcoin and thus the addresses are the same.
hero member
Activity: 666
Merit: 516
Fuck BlackRock
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.

Here you go.

https://block.d.evco.in/tx/e61339a40aa4e90e983fe0d64cf09eed5fa1e6eac227b6761f06ac7af1929baf

Not sure how to redeem myself. But there's the same pubkey as BTC Block 0.
legendary
Activity: 3878
Merit: 1193
4) "When Will We See Collisions for SHA-1?" - Bruce Schneier -https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

Bruce sure knows his stuff.

Quote
A collision attack is therefore well within the range of what an organized crime syndicate can practically budget by 2018, and a university research project by 2021.

...the need to transition from SHA-1 for collision resistance functions is probably more urgent than this back-of-the-envelope analysis suggests.

Any increase in the number of cores per CPU, or the number of CPUs per server, also affects these calculations. Also, any improvements in cryptanalysis will further reduce the complexity of this attack.
sr. member
Activity: 378
Merit: 250
thats something we could see it coming, thats why it was developed sha256 and some other algos, like will be created many more algos to replace sha256, it will be interesting to see what would  btc core developers do on those coming scenarios
member
Activity: 84
Merit: 10
Entrepreneur
http://www.coindesk.com/who-broke-the-sha1-algorithm-and-what-does-it-mean-for-bitcoin/

SHA1 is like MD5  Grin

No Panic guys  Cool

SHA1 has also been deemed quite vulnerable to collision attacks which is why all browsers will be removing support for certificates signed with SHA1 by January 2017. SHA256 however, is currently much more resistant to collision attacks as it is able to generate a longer hash which is harder to break.
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
Is it a coincidence that this happened right when bitcoin was shattering throught the ATH?

Anyway, as far as I know we are safe for years with SHA256, or satoshi said so some years ago, he said we wouldnt see a SHA256 collision in our lifetime.
Yeah that's funny it happened the same day but I don't see how this could be related

And hopefully we won't see an SHA256 collision in our lifetime but you never know, it may have a major flaw discovered in the following years

Here the team founds an algorithm 100000 times faster than bruteforcing

If a SHA256 collision happens what is the worst scenario? I think I would have a hearth attack or something.

How would the Core team proceed in order to make the switch to a safe algo? Would it be an absolute fuckfest or it is a smooth process? Because I presume we wouldn't have a lot of time to waste being exposed with SHA256 through the transition.

Could anti Core trolls or just bitcoin attackers in general try to delay the switch or somehow block it?

I hope those things are properly planned in the unfortunate even that happens otherwise im not going to be able to sleep ever again.

https://en.bitcoin.it/wiki/Weaknesses#Breaking_the_cryptography
legendary
Activity: 868
Merit: 1006
Is it a coincidence that this happened right when bitcoin was shattering throught the ATH?

Anyway, as far as I know we are safe for years with SHA256, or satoshi said so some years ago, he said we wouldnt see a SHA256 collision in our lifetime.
Yeah that's funny it happened the same day but I don't see how this could be related

And hopefully we won't see an SHA256 collision in our lifetime but you never know, it may have a major flaw discovered in the following years

Here the team founds an algorithm 100000 times faster than bruteforcing

If a SHA256 collision happens what is the worst scenario? I think I would have a hearth attack or something.

How would the Core team proceed in order to make the switch to a safe algo? Would it be an absolute fuckfest or it is a smooth process? Because I presume we wouldn't have a lot of time to waste being exposed with SHA256 through the transition.

Could anti Core trolls or just bitcoin attackers in general try to delay the switch or somehow block it?

I hope those things are properly planned in the unfortunate even that happens otherwise im not going to be able to sleep ever again.
jr. member
Activity: 38
Merit: 18
You may not recognize or agree with a or any legal distinction between stealing someone's BTC and claiming a BTC reward as was done here in this thread or is being done in the puzzle transaction.

But there is a huge moral distinction between the two:  stealing someone's BTC is wrong, claiming a BTC reward is not wrong.

Just because you can do something does not make it morally right.



Not all cases are morally clear cut. What if someone disagrees with how someone else acquired the coins in the first place?

A more interesting example of how "stealing" becomes fuzzy is LN payment channels. What if I close a channel with an earlier stage to my advantage, and I succeed because my peer for some reason fails to monitor the blockchain?

Am I stealing? Not really. My gains  would be the result of an explicit and well known  clause of our contract. Would you consider this morally wrong?

I think we should value the programmatic rules of contracts and as such not judge these types of theft in the same way as we would do with theft in the "real" world.
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
You may not recognize or agree with a or any legal distinction between stealing someone's BTC and claiming a BTC reward as was done here in this thread or is being done in the puzzle transaction.

But there is a huge moral distinction between the two:  stealing someone's BTC is wrong, claiming a BTC reward is not wrong.

Just because you can do something does not make it morally right.

jr. member
Activity: 38
Merit: 18
Stealing someone's coins by breaking ECDSA is not the same as a reward specifically for breaking something.


That is an interesting distinction as this implies that the blockchain should recognize some form of legal or moral ownership defined outside of the blockchain.

An alternative view more in line with the decentralized nature of bitcoin, is that "ownership" is simply defined as being able to produce a valid input script for an output script.

As such, someone being able to find the private key of an early public key by whatever means, must be considered the "owner". It doesn't matter if the keys are found on an (owned) usb-stick or by trial and error,
sr. member
Activity: 378
Merit: 250
sha256 for now can sleep peacefully, i dont know for how long, every day hardaware processing capabilities increase, and the news about china's quantum computer may affect all this
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
Is it a coincidence that this happened right when bitcoin was shattering throught the ATH?

Anyway, as far as I know we are safe for years with SHA256, or satoshi said so some years ago, he said we wouldnt see a SHA256 collision in our lifetime.
Yeah that's funny it happened the same day but I don't see how this could be related

And hopefully we won't see an SHA256 collision in our lifetime but you never know, it may have a major flaw discovered in the following years

Here the team founds an algorithm 100000 times faster than bruteforcing
legendary
Activity: 868
Merit: 1006
Is it a coincidence that this happened right when bitcoin was shattering throught the ATH?

Anyway, as far as I know we are safe for years with SHA256, or satoshi said so some years ago, he said we wouldnt see a SHA256 collision in our lifetime.
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
Congratulations!  I had completely forgotten about this thread.
newbie
Activity: 7
Merit: 0
... meanwhile, MD5 is still widely used  Grin
legendary
Activity: 1260
Merit: 1019
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
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
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 confirmed

How 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



full member
Activity: 201
Merit: 100
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??
newbie
Activity: 23
Merit: 0
sr. member
Activity: 278
Merit: 250
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.
hero member
Activity: 784
Merit: 1000
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".
staff
Activity: 4284
Merit: 8808
are at risk.
In context, of course— thats assuming a compromise of ECC on our curve. Smiley
legendary
Activity: 2576
Merit: 1186
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.
Stealing someone's coins by breaking ECDSA is not the same as a reward specifically for breaking something.

Also, this has nothing to do with "Satoshi's coins". All block rewards generated by bitcoind's internal miner or getwork are at risk.
sr. member
Activity: 360
Merit: 251
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.
staff
Activity: 4284
Merit: 8808
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.
legendary
Activity: 3430
Merit: 3080
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.
legendary
Activity: 1596
Merit: 1100
Added 1.0 BTC to SHA1 bounty.
staff
Activity: 4284
Merit: 8808
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.
legendary
Activity: 905
Merit: 1012
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.
legendary
Activity: 1764
Merit: 1002
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 ".  If the signature algorithm is broken, then those coins can be spent by the attacker, since he would know the public key.

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.
legendary
Activity: 1232
Merit: 1094
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 ".  If the signature algorithm is broken, then those coins can be spent by the attacker, since he would know the public key.

The updated system requires the hashing function and the signing algorithm to be broken at around the same time.
legendary
Activity: 1764
Merit: 1002
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?
legendary
Activity: 3472
Merit: 4801
- snip -

2) Note that the value of your SHA256, RIPEMD160, RIPEMD160(SHA256()) or SHA256^2 bounty may be diminished by the act of collecting it.

- snip -

 Grin  Grin  Grin
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
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.

No they aren't. Satoshi's early public keys aren't protected by anything.
legendary
Activity: 1764
Merit: 1002
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.
legendary
Activity: 1232
Merit: 1094
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.
legendary
Activity: 1764
Merit: 1002
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?
hero member
Activity: 560
Merit: 517
This is both incredibly fascinating, and a beautiful show of the kinds of innovation the Bitcoin system supports!
staff
Activity: 4284
Merit: 8808
I wrote up little description of how these scripts work on reddit.  This might be an honorable use for any "tainted" coins you have that you don't want associated with your identity and important outputs to watch if you want to learn about impressive cryptographic breakthroughs.
legendary
Activity: 1120
Merit: 1160
Rewards at the following P2SH addresses are available for anyone able to demonstrate collision attacks against a variety of cryptographic algorithms. You collect your bounty by demonstrating two messages that are not equal in value, yet result in the same digest when hashed. These messages are used in a scriptSig, which satisfies the scriptPubKey storing the bountied funds, allowing you to move them to a scriptPubKey (Bitcoin address) of your choice.

Further donations to the bounties are welcome, particularly for SHA1 - address 37k7toV1Nv4DfmQbmZ8KuZDQCYK9x5KpzP - for which an attack on a single hash value is believed to be possible at an estimated cost of $2.77M (4)

Details below; note that the "decodescript" RPC command is not yet released; compile bitcoind from the git repository at http://github.com/bitcoin/bitcoin

SHA1:

$ btc decodescript 6e879169a77ca787
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "37k7toV1Nv4DfmQbmZ8KuZDQCYK9x5KpzP"
}


SHA256:

$ btc decodescript 6e879169a87ca887
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA256 OP_SWAP OP_SHA256 OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "35Snmmy3uhaer2gTboc81ayCip4m9DT4ko"
}


RIPEMD160:

$ btc decodescript 6e879169a67ca687
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_RIPEMD160 OP_SWAP OP_RIPEMD160 OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "3KyiQEGqqdb4nqfhUzGKN6KPhXmQsLNpay"
}


RIPEMD160(SHA256()):

$ btc decodescript 6e879169a97ca987
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_HASH160 OP_SWAP OP_HASH160 OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "39VXyuoc6SXYKp9TcAhoiN1mb4ns6z3Yu6"
}


SHA256(SHA256()):

$ btc decodescript 6e879169aa7caa87
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_HASH256 OP_SWAP OP_HASH256 OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "3DUQQvz4t57Jy7jxE86kyFcNpKtURNf1VW"
}

and last but not least, the absolute value function:

$ btc decodescript 6e879169907c9087
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_ABS OP_SWAP OP_ABS OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "3QsT6Sast6ghfsjZ9VJj9u8jkM2qTfDgHV"
}

For example, this pair of transactions created, and then collected, an
absolute value function bounty:

0100000001f3194f7c2a39809d6ea5fa2db68326932df146aaab7be2f398a524bd269d0b6200000 0008a473044022039bc13cb7fe565ff2e14b16fbc4a9facd36b25a435d2f49de4534463212aeaee 022076413c7591385cd813df37d8104dd8110745c28178cef829b5ab3e56b7c30d22014104d3477 5baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f16880 9d36e2da1162f03412bf23aa5f949f235eb2e7141783ffffffff03207e7500000000001976a9149 bc0bbdd3024da4d0c38ed1aecf5c68dd1d3fa1288ac0000000000000000126a6e879169907c9087 086e879169907c908740420f000000000017a914fe441065b6532231de2fac563152205ec4f59c7 48700000000

0100000001f18cda90bbbcfb031c65ceda17c82dc046c7db0b96242ba4c5b53c411d8c056e02000 0000c510181086e879169907c9087ffffffff01a0bb0d00000000001976a9149bc0bbdd3024da4d 0c38ed1aecf5c68dd1d3fa1288ac00000000

Specifically with the scriptSig: 1 -1 6e879169907c9087


Notes:

1) We advise mining the block in which you collect your bounty yourself; scriptSigs satisfying the above scriptPubKeys do not cryptographically sign the transaction's outputs. If the bounty value is sufficiently large other miners may find it profitable to reorganize the chain to kill your block and collect the reward themselves. This is particularly profitable for larger, centralized, mining pools.

2) Note that the value of your SHA256, RIPEMD160, RIPEMD160(SHA256()) or SHA256^2 bounty may be diminished by the act of collecting it.

3) Due to limitations of the Bitcoin scripting language bounties can only be collected with solutions using messages less than 521 bytes in size.

4) "When Will We See Collisions for SHA-1?" - Bruce Schneier -https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
Jump to: