Two valid WIF's for one public address. Why?

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 -
  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?

Topic: Two valid WIF's for one public address. Why? (Read 978 times)