Why does bitcoind not recognize the uncompressed version of my address?

Question

I have an address representing a compressed public address, which bitcoind is recognizing as "ismine":

compressed_address = n2HCyN8GWPuc8CrwbiiBASCS7iWku3Ke8S
compressed_key     = 03c6debc01d8cf1c7eae826b8acb0ba6ff5d37b8d840b2bfc5244cdebab83a6781
> bitcoind  -testnet validateaddress n2HCyN8GWPuc8CrwbiiBASCS7iWku3Ke8S
{
    "isvalid" : true,
    "address" : "n2HCyN8GWPuc8CrwbiiBASCS7iWku3Ke8S",
    "ismine" : true,
    "isscript" : false,
    "pubkey" : "03c6debc01d8cf1c7eae826b8acb0ba6ff5d37b8d840b2bfc5244cdebab83a6781",
    "iscompressed" : true,
    "account" : ""
}

I extract the y value from the compressed public keys, and create an address from that (with the same function I wrote for compressed keys):

decompressed_key     = 04c6debc01d8cf1c7eae826b8acb0ba6ff5d37b8d840b2bfc5244cdebab83a6781a8b69757635c64ce32eed71115b68174d7241c716b1f76d317c6440635d8bc01
decompressed_address = mfjsW5m8CL5EazGBvjutZ4dgJwd6AjHM11

The address is valid since if satisfies the curve equation... x, y values are as follows:

x = 89951481645973345162937095289811840492311042685266238084455665220379660150657
y = 76311169247456070080081989221882104208438035444189442719121845261776897752065
y * y         = 107822876231389859288843816887520488062823501023166616425651229464214081607136
x * x * x - 7 = 107822876231389859288843816887520488062823501023166616425651229464214081607136

However, bitcoind does not recognize the decompressed address as "ismine".

> bitcoind  -testnet validateaddress mfjsW5m8CL5EazGBvjutZ4dgJwd6AjHM11
{
    "isvalid" : true,
    "address" : "mfjsW5m8CL5EazGBvjutZ4dgJwd6AjHM11",
    "ismine" : false
}

I don't understand... the only difference between the two is that one key is compressed to save 32 bytes... the private key should be the same! Shouldn't they be interchangeable? Does this mean I won't be able to spend to spend coins send to the de/uncompressed address?

Answer 1

Compressed and uncompressed keys are treated completely separately. Funds sent to the compressed point address will not be available to a client that has the uncompressed key in their wallet.

That is to say, although mfjsW5m8CL5EazGBvjutZ4dgJwd6AjHM11 and n2HCyN8GWPuc8CrwbiiBASCS7iWku3Ke8S have the same private key, they are treated as completely separate to the Bitcoin network. Ideally they would be treated the same, but compressed ECDSA keys just weren't considered by Satoshi originally, it's only a more recent addition (sipa's, probably) to the client.