Bitcoin WIF collision?

[doublerainbow]

Hello,

probably i found BTC WIF collision. According to TP's Go Bitcoin Tests webpage https://gobittest.appspot.com/PrivateKey

WIF: 5JfM6SDgNxT7L6xvma2UEGhJG8H9dr8gLQcW48yZEaHP59SV3fZ
and
WIF: 5JfM6SDgNxT7L6xvma2UEGhJG8H9dr8gLQcW48yZEaHP5919kdr

leads to same private key:
6F65E4E681B948BC85E4843BBFF14F2AAAA231059D894AC82A90BF1B511E9D73

Is it possible? Is it bug? Is it collision?

Please share your opinions. Thank you.

[1715122785]

1715122785

[BlackHatCoiner]

Take:

Code:

6F65E4E681B948BC85E4843BBFF14F2AAAA231059D894AC82A90BF1B511E9D73

Find the checksum (of the uncompressed version):

Code:

74D690F4

Now add prefix, the private key and the checksum:

Code:

806F65E4E681B948BC85E4843BBFF14F2AAAA231059D894AC82A90BF1B511E9D7374D690F4

Convert the above to WIF:

Code:

5JfM6SDgNxT7L6xvma2UEGhJG8H9dr8gLQcW48yZEaHP59SV3fZ

So, it's probably just a bug of the gobittest.appspot.com. It shouldn't give you the second WIF. It's not valid either way.

[hosseinimr93]

So, it's probably just a bug of the gobittest.appspot.com. It shouldn't give you the second WIF. It's not valid either way.

The problem is that it doesn't check the checksum when you enter a (WIF) private key.

To OP:
As already stated by BlackHatCoiner, only the first (WIF) private key corresponds to the hexademical format of the private key you posted. The second one is not valid at all.
As you see, the difference between the two (WIF) private keys you posted is only in a few last characters. That's because the tool in question doesn't check the checksum and those last characters don't make any change in the final result when deriving the hexadecimal format of the private key. 

[pooya87]

Is it possible? Is it bug? Is it collision?

Each encoded string only corresponds to a single data and can not have collision so your question is wrong to begin with since WIF is just an encoding of a 32 byte data and if that data is the same then the string (WIF) is going to be the same too and if even a single bit of it changes, the string changes too.

The second "WIF" you posted doesn't have a valid checksum.

[mynonce]

So, it's probably just a bug of the gobittest.appspot.com. It shouldn't give you the second WIF. It's not valid either way.

The problem is that it doesn't check the checksum when you enter a (WIF) private key.

Yes, you can check it, changing the last character and you will get the same private key result:


1 - Wallet import format

5JfM6SDgNxT7L6xvma2UEGhJG8H9dr8gLQcW48yZEaHP59SV3fA
5JfM6SDgNxT7L6xvma2UEGhJG8H9dr8gLQcW48yZEaHP59SV3fB
5JfM6SDgNxT7L6xvma2UEGhJG8H9dr8gLQcW48yZEaHP59SV3fC
5JfM6SDgNxT7L6xvma2UEGhJG8H9dr8gLQcW48yZEaHP59SV3fD
5JfM6SDgNxT7L6xvma2UEGhJG8H9dr8gLQcW48yZEaHP59SV3fE
...
5JfM6SDgNxT7L6xvma2UEGhJG8H9dr8gLQcW48yZEaHP59SV3fZ


4 - Dropping first byte. This is the private key

6F65E4E681B948BC85E4843BBFF14F2AAAA231059D894AC82A90BF1B511E9D73

[doublerainbow]

Thank you very much guys for explanation it looks https://gobittest.appspot.com/PrivateKey is not checking WIF checksum so WIF 5JfM6SDgNxT7L6xvma2UEGhJG8H9dr8gLQcW48yZEaHP5919kdr is not valid at all.