Private key WIF's

Propulsion

Propulsion

The buck stops here.
Cross post from BCT. https://bitcointalk.org/index.php?topic=836451.0

I have a private key that is valid but I don't understand why. This is a long post so bear with me. Note: this address is worthless.
The below is a full key. Version 76.
Code: 
3081d30201010420ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54a08185308182020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a12403220003c0ef03fc45624122c85791557be9782cc7a2a813125f317aa0136b25ce5cec76

Code: 
ehco -n "3081.." | xxd -r -p | openssl asn1parse -i -inform DER -dump

 0:d=0  hl=3 l= 211 cons: SEQUENCE          
    3:d=1  hl=2 l=   1 prim:  INTEGER           :01
    6:d=1  hl=2 l=  32 prim:  OCTET STRING      
      0000 - ca 7b 50 f4 1b 2f 43 e1-e9 13 bd b6 f6 ff 32 89   This is the private key. 
      0010 - 22 3d 9e c0 eb e6 10 f8-01 a1 e9 3c b2 56 4d 54   //ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54
   40:d=1  hl=3 l= 133 cons:  cont [ 0 ]        
   43:d=2  hl=3 l= 130 cons:   SEQUENCE          
   46:d=3  hl=2 l=   1 prim:    INTEGER           :01
   49:d=3  hl=2 l=  44 cons:    SEQUENCE          
   51:d=4  hl=2 l=   7 prim:     OBJECT            :prime-field
   60:d=4  hl=2 l=  33 prim:     INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
   95:d=3  hl=2 l=   6 cons:    SEQUENCE          
   97:d=4  hl=2 l=   1 prim:     OCTET STRING      
      0001 - <SPACES/NULS>
  100:d=4  hl=2 l=   1 prim:     OCTET STRING      
      0000 - 07                                                .
  103:d=3  hl=2 l=  33 prim:    OCTET STRING      
      0000 - 02 79 be 66 7e f9 dc bb-ac 55 a0 62 95 ce 87 0b   .y.f~....U.b....
      0010 - 07 02 9b fc db 2d ce 28-d9 59 f2 81 5b 16 f8 17   .....-.(.Y..[...
      0020 - 98                                                .
  138:d=3  hl=2 l=  33 prim:    INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
  173:d=3  hl=2 l=   1 prim:    INTEGER           :01
  176:d=1  hl=2 l=  36 cons:  cont [ 1 ]        
  178:d=2  hl=2 l=  34 prim:   BIT STRING        
      0000 - 00 03 c0 ef 03 fc 45 62-41 22 c8 57 91 55 7b e9   This is the public key. Exclude the first byte.
      0010 - 78 2c c7 a2 a8 13 12 5f-31 7a a0 13 6b 25 ce 5c   //03c0ef03fc45624122c86791557be9782cc7a2a813125f317aa0136b25ce5cec76
      0020 - ec 76
Above here is an asn1parse of the full key.
Doing such reveals that "ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54" is the private key.

Now, I'll convert it to WIF. (wallet import format)
Code: 
1.)For 76, add '4c' to the front of it, and '01' to the back. (01 for compressed keys)
2.)SHA256sum it. "echo -n '4cca7b...' | xxd -r -p | sha256sum
3.)SHA256sum the previous result once more. 
4.)Take the first 4 bytes from the result (8 characters) This is the checksum.
5.)Put the checksum at the end of step 1. The 4c....01 string[checksum].
6.)Convert it to Base58. This is now your WIF format.

S0.) ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54
S1.) 4cca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d5401
S2.) 54f1aa00273e23379fc4a08ad08b918d7e97b6ff1ebfa097350fb93dffdd00e6
S3.) 17f77291600662c7c2d7ae3969172dda3ec1885bdac75c356ba3dee94b4ce305
S4.) 17f77291
S5.) 4cca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d540117f77291
S6.) CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G

The above converted the private key to WIF format of 'CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G'.
Which is valid for the public address of "Xf5QNbxmxtBRK1BXY5yYNYZCJuugX5ro6v".

______________________________________________________________
Now this is the part I don't understand.
______________________________________________________________
The WIF format is valid and returns the correct private key for this address but it's completely different! (yet valid)
The above WIF when ran through pywallet returns 'XJ5EKWJQkxRENadpJAXoN4UJ3r3TN4mqn1UB8ecckBgSXnmFF3FW' as the private key. Which does return the public address I was working with.

Why does 'CMRX8....' translate to 'XJ5EKW...' and why didn't it return 'XJ5EKW....' when I completed the previous steps?

Basically, why are "XJ5EKWJQkxRENadpJAXoN4UJ3r3TN4mqn1UB8ecckBgSXnmFF3FW" and "CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G" both valid and different private keys for the public address of "Xf5QNbxmxtBRK1BXY5yYNYZCJuugX5ro6v"?

Summary

There are two valid Private WIF keys for the same public key. Why?
 
The odds of this are so amazingly astronomical... Two different, valid privkeys that result in the same pubkey.

Instead of your own methods and that pywallet script, have you tried importing them into a fresh wallet just to "see what happens?" Not scientific, but it would be more information... And that might lead to something scientific... Might expose a mistake if they end up with different pubkeys when you import them.

Basically, check for human error (you, or the tools you're using) by letting the machine do it and see what comes out.

If it really does work out that they both become the same pubkey... Wow.

I don't pretend to be competent in the details... But sometimes a fresh look at the process, and a certainty that what you're seeing really is what you're seeing, can help... Try a different, less manual, tool and see what happens.
 
Last edited by a moderator:
Propulsion said:
Cross post from BCT. https://bitcointalk.org/index.php?topic=836451.0

I have a private key that is valid but I don't understand why. This is a long post so bear with me. Note: this address is worthless.
The below is a full key. Version 76.
Code: 
3081d30201010420ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54a08185308182020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a12403220003c0ef03fc45624122c85791557be9782cc7a2a813125f317aa0136b25ce5cec76

Code: 
ehco -n "3081.." | xxd -r -p | openssl asn1parse -i -inform DER -dump

0:d=0  hl=3 l= 211 cons: SEQUENCE         
    3:d=1  hl=2 l=   1 prim:  INTEGER           :01
    6:d=1  hl=2 l=  32 prim:  OCTET STRING     
      0000 - ca 7b 50 f4 1b 2f 43 e1-e9 13 bd b6 f6 ff 32 89   This is the private key.
      0010 - 22 3d 9e c0 eb e6 10 f8-01 a1 e9 3c b2 56 4d 54   //ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54
   40:d=1  hl=3 l= 133 cons:  cont [ 0 ]       
   43:d=2  hl=3 l= 130 cons:   SEQUENCE         
   46:d=3  hl=2 l=   1 prim:    INTEGER           :01
   49:d=3  hl=2 l=  44 cons:    SEQUENCE         
   51:d=4  hl=2 l=   7 prim:     OBJECT            :prime-field
   60:d=4  hl=2 l=  33 prim:     INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
   95:d=3  hl=2 l=   6 cons:    SEQUENCE         
   97:d=4  hl=2 l=   1 prim:     OCTET STRING     
      0001 - <SPACES/NULS>
  100:d=4  hl=2 l=   1 prim:     OCTET STRING     
      0000 - 07                                                .
  103:d=3  hl=2 l=  33 prim:    OCTET STRING     
      0000 - 02 79 be 66 7e f9 dc bb-ac 55 a0 62 95 ce 87 0b   .y.f~....U.b....
      0010 - 07 02 9b fc db 2d ce 28-d9 59 f2 81 5b 16 f8 17   .....-.(.Y..[...
      0020 - 98                                                .
  138:d=3  hl=2 l=  33 prim:    INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
  173:d=3  hl=2 l=   1 prim:    INTEGER           :01
  176:d=1  hl=2 l=  36 cons:  cont [ 1 ]       
  178:d=2  hl=2 l=  34 prim:   BIT STRING       
      0000 - 00 03 c0 ef 03 fc 45 62-41 22 c8 57 91 55 7b e9   This is the public key. Exclude the first byte.
      0010 - 78 2c c7 a2 a8 13 12 5f-31 7a a0 13 6b 25 ce 5c   //03c0ef03fc45624122c86791557be9782cc7a2a813125f317aa0136b25ce5cec76
      0020 - ec 76
Above here is an asn1parse of the full key.
Doing such reveals that "ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54" is the private key.

Now, I'll convert it to WIF. (wallet import format)
Code: 
1.)For 76, add '4c' to the front of it, and '01' to the back. (01 for compressed keys)
2.)SHA256sum it. "echo -n '4cca7b...' | xxd -r -p | sha256sum
3.)SHA256sum the previous result once more.
4.)Take the first 4 bytes from the result (8 characters) This is the checksum.
5.)Put the checksum at the end of step 1. The 4c....01 string[checksum].
6.)Convert it to Base58. This is now your WIF format.

S0.) ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54
S1.) 4cca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d5401
S2.) 54f1aa00273e23379fc4a08ad08b918d7e97b6ff1ebfa097350fb93dffdd00e6
S3.) 17f77291600662c7c2d7ae3969172dda3ec1885bdac75c356ba3dee94b4ce305
S4.) 17f77291
S5.) 4cca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d540117f77291
S6.) CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G

The above converted the private key to WIF format of 'CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G'.
Which is valid for the public address of "Xf5QNbxmxtBRK1BXY5yYNYZCJuugX5ro6v".

______________________________________________________________
Now this is the part I don't understand.
______________________________________________________________
The WIF format is valid and returns the correct private key for this address but it's completely different! (yet valid)
The above WIF when ran through pywallet returns 'XJ5EKWJQkxRENadpJAXoN4UJ3r3TN4mqn1UB8ecckBgSXnmFF3FW' as the private key. Which does return the public address I was working with.

Why does 'CMRX8....' translate to 'XJ5EKW...' and why didn't it return 'XJ5EKW....' when I completed the previous steps?

Basically, why are "XJ5EKWJQkxRENadpJAXoN4UJ3r3TN4mqn1UB8ecckBgSXnmFF3FW" and "CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G" both valid and different private keys for the public address of "Xf5QNbxmxtBRK1BXY5yYNYZCJuugX5ro6v"?

Summary

There are two valid Private WIF keys for the same public key. Why?
Click to expand...
Propulsion, I found this link, so it's possible two private keys can have the same public address?

https://bitcoin.stackexchange.com/q...keys-generate-the-same-public-bitcoin-address
 
Propulsion said:
Cross post from BCT. https://bitcointalk.org/index.php?topic=836451.0

I have a private key that is valid but I don't understand why. This is a long post so bear with me. Note: this address is worthless.
The below is a full key. Version 76.
Code: 
3081d30201010420ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54a08185308182020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a12403220003c0ef03fc45624122c85791557be9782cc7a2a813125f317aa0136b25ce5cec76

Code: 
ehco -n "3081.." | xxd -r -p | openssl asn1parse -i -inform DER -dump

0:d=0  hl=3 l= 211 cons: SEQUENCE      
    3:d=1  hl=2 l=   1 prim:  INTEGER           :01
    6:d=1  hl=2 l=  32 prim:  OCTET STRING  
      0000 - ca 7b 50 f4 1b 2f 43 e1-e9 13 bd b6 f6 ff 32 89   This is the private key.
      0010 - 22 3d 9e c0 eb e6 10 f8-01 a1 e9 3c b2 56 4d 54   //ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54
   40:d=1  hl=3 l= 133 cons:  cont [ 0 ]    
   43:d=2  hl=3 l= 130 cons:   SEQUENCE      
   46:d=3  hl=2 l=   1 prim:    INTEGER           :01
   49:d=3  hl=2 l=  44 cons:    SEQUENCE      
   51:d=4  hl=2 l=   7 prim:     OBJECT            :prime-field
   60:d=4  hl=2 l=  33 prim:     INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
   95:d=3  hl=2 l=   6 cons:    SEQUENCE      
   97:d=4  hl=2 l=   1 prim:     OCTET STRING  
      0001 - <SPACES/NULS>
  100:d=4  hl=2 l=   1 prim:     OCTET STRING  
      0000 - 07                                                .
  103:d=3  hl=2 l=  33 prim:    OCTET STRING  
      0000 - 02 79 be 66 7e f9 dc bb-ac 55 a0 62 95 ce 87 0b   .y.f~....U.b....
      0010 - 07 02 9b fc db 2d ce 28-d9 59 f2 81 5b 16 f8 17   .....-.(.Y..[...
      0020 - 98                                                .
  138:d=3  hl=2 l=  33 prim:    INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
  173:d=3  hl=2 l=   1 prim:    INTEGER           :01
  176:d=1  hl=2 l=  36 cons:  cont [ 1 ]    
  178:d=2  hl=2 l=  34 prim:   BIT STRING    
      0000 - 00 03 c0 ef 03 fc 45 62-41 22 c8 57 91 55 7b e9   This is the public key. Exclude the first byte.
      0010 - 78 2c c7 a2 a8 13 12 5f-31 7a a0 13 6b 25 ce 5c   //03c0ef03fc45624122c86791557be9782cc7a2a813125f317aa0136b25ce5cec76
      0020 - ec 76
Above here is an asn1parse of the full key.
Doing such reveals that "ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54" is the private key.

Now, I'll convert it to WIF. (wallet import format)
Code: 
1.)For 76, add '4c' to the front of it, and '01' to the back. (01 for compressed keys)
2.)SHA256sum it. "echo -n '4cca7b...' | xxd -r -p | sha256sum
3.)SHA256sum the previous result once more.
4.)Take the first 4 bytes from the result (8 characters) This is the checksum.
5.)Put the checksum at the end of step 1. The 4c....01 string[checksum].
6.)Convert it to Base58. This is now your WIF format.

S0.) ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54
S1.) 4cca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d5401
S2.) 54f1aa00273e23379fc4a08ad08b918d7e97b6ff1ebfa097350fb93dffdd00e6
S3.) 17f77291600662c7c2d7ae3969172dda3ec1885bdac75c356ba3dee94b4ce305
S4.) 17f77291
S5.) 4cca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d540117f77291
S6.) CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G

The above converted the private key to WIF format of 'CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G'.
Which is valid for the public address of "Xf5QNbxmxtBRK1BXY5yYNYZCJuugX5ro6v".

______________________________________________________________
Now this is the part I don't understand.
______________________________________________________________
The WIF format is valid and returns the correct private key for this address but it's completely different! (yet valid)
The above WIF when ran through pywallet returns 'XJ5EKWJQkxRENadpJAXoN4UJ3r3TN4mqn1UB8ecckBgSXnmFF3FW' as the private key. Which does return the public address I was working with.

Why does 'CMRX8....' translate to 'XJ5EKW...' and why didn't it return 'XJ5EKW....' when I completed the previous steps?

Basically, why are "XJ5EKWJQkxRENadpJAXoN4UJ3r3TN4mqn1UB8ecckBgSXnmFF3FW" and "CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G" both valid and different private keys for the public address of "Xf5QNbxmxtBRK1BXY5yYNYZCJuugX5ro6v"?

Summary

There are two valid Private WIF keys for the same public key. Why?
Click to expand...
No magic here. 0x4c is for public key, 0xcc is for private key.
Code: 
> echo -n "ccca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d5401" | xxd -r -p | sha256sum
6ee14ce0122268ece5d75ed34e895a8cee631b88fb9512eea8a13118d72bb9bb
> echo -n "6ee14ce0122268ece5d75ed34e895a8cee631b88fb9512eea8a13118d72bb9bb" | xxd -r -p | sha256sum
9be26d611a9fba2bbe198758e04cf84b33e7c6c7efc847be734b153efbd0de4f
checksum - 9be26d61
after addition - ccca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54019be26d61
using bash base58 encoding function
Code: 
> function b58encode () { local b58_lookup_table=({1..9} {A..H} {J..N} {P..Z} {a..k} {m..z}); bc<<<"obase=58;ibase=16;${1^^}"|(read -a s; for b58_index in "${s[@]}" ; do printf %s ${b58_lookup_table[ 10#"$b58_index" ]}; done); }
> b58encode ccca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54019be26d61
XJ5EKWJQkxRENadpJAXoN4UJ3r3TN4mqn1UB8ecckBgSXnmFF3F
BINGO :)

EDIT: Btw, who is in charge of http://paper.darkcoin.io/ ? It doesn't accept compressed WIF private keys on "Wallet Details" page for some reason. However http://walletgenerator.net/?currency=Darkcoin# works as it should...
 
Last edited by a moderator:
Thanks dude. I knew something was up. "CC" for private. "4c" for public.

As far as who runs the paper site, no idea.

Edit: And for anyone who comes across this thread in the future, The CC and 4C are Hex converted from decimal.

CC is 204
4C is 76

The reason we know these values is because of the sourcecode of Darkcoin itself. Specifically, base58.h

On line 275 in base58.h it states addrtype is 76 decimal (4C hex)
On line 403 in base58.h it states addrtype is 204 decimal (CC hex)
 
Last edited by a moderator:
You have probably lost the last "W" char? I came out with "XJ5EKWJQkxRENadpJAXoN4UJ3r3TN4mqn1UB8ecckBgSXnmFF3FW"
 
You must log in or register to reply here.
Back
Top