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.
Topic: Bitcoin WIF collision? (Read 195 times)
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
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.
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.
Take:
Find the checksum (of the uncompressed version):
Now add prefix, the private key and the checksum:
Convert the above to WIF:
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.
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.
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.
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.
Jump to: