Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

Private key WIF's

Discussion in 'Development Tech Discussion' started by Propulsion, Oct 27, 2014.

  1. Propulsion

    Propulsion The buck stops here.

    Joined:
    Feb 26, 2014
    Messages:
    1,008
    Likes Received:
    467
    Trophy Points:
    183
    Dash Address:
    XerHCGryyfZttUc6mnuRY3FNJzU1Jm9u5L
    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?
     
    • Like Like x 1
  2. camosoul

    camosoul Grizzled Member

    Joined:
    Sep 19, 2014
    Messages:
    2,194
    Likes Received:
    1,115
    Trophy Points:
    1,183
    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.
     
    #2 camosoul, Oct 27, 2014
    Last edited by a moderator: Oct 27, 2014
  3. moli

    moli Grizzled Member

    Joined:
    Aug 5, 2014
    Messages:
    3,262
    Likes Received:
    1,837
    Trophy Points:
    1,183
    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
     
  4. UdjinM6

    UdjinM6 Official Dash Dev
    Dash Core Team Moderator

    Joined:
    May 20, 2014
    Messages:
    3,633
    Likes Received:
    3,533
    Trophy Points:
    1,183
    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...
     
    #4 UdjinM6, Oct 27, 2014
    Last edited by a moderator: Oct 27, 2014
    • Like Like x 1
  5. Propulsion

    Propulsion The buck stops here.

    Joined:
    Feb 26, 2014
    Messages:
    1,008
    Likes Received:
    467
    Trophy Points:
    183
    Dash Address:
    XerHCGryyfZttUc6mnuRY3FNJzU1Jm9u5L
    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)
     
    #5 Propulsion, Oct 27, 2014
    Last edited by a moderator: Oct 27, 2014
  6. Jabba

    Jabba New Member

    Joined:
    Oct 23, 2019
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    1
    You have probably lost the last "W" char? I came out with "XJ5EKWJQkxRENadpJAXoN4UJ3r3TN4mqn1UB8ecckBgSXnmFF3FW"
     

Share This Page