Error importing private key

[GoogleCodeExporter]

Hi, I am looking to import a private key from a string, but it seems the round 
trip does not quite work. Is there a workaround?

NetworkParameters nwp = NetworkParameters.testNet();

ECKey key = new ECKey();
System.out.println("Orig: " + key.toStringWithPrivate() );

ECKey reconstruct = ECKey.fromASN1(key.toASN1());
System.out.println("Reco: " + reconstruct.toStringWithPrivate() );

And it gives this output:

Orig: pub:02eca8d3c794307b28790ca51de1b29f6198255dfa430d8e905f6bb733df8e0eda 
timestamp:1385216458 
priv:6330d118aaaf188f811557bc5469d0a82dd5a1656a73a230ac59454a1bfe23d1

Reco: 
pub:04eca8d3c794307b28790ca51de1b29f6198255dfa430d8e905f6bb733df8e0edab8697f72dc
6df4d93ccf93344b158ca923257aba3bff33b72af10d1cd681c8e4 
priv:6330d118aaaf188f811557bc5469d0a82dd5a1656a73a230ac59454a1bfe23d1

Original issue reported on code.google.com by carlosm...@googlemail.com on 23 Nov 2013 at 2:34

[GoogleCodeExporter]

Apologies, it should be a bug report rather than an enhancement.

Original comment by carlosm...@googlemail.com on 23 Nov 2013 at 2:35

[GoogleCodeExporter]

I reckon it has something to do with EC symmetry. There was some talk about the 
shorter key being sufficient, as long as it had an indicator as to which side 
it was on. You can see it almost looks the same.

Original comment by carlosm...@googlemail.com on 23 Nov 2013 at 2:57

[GoogleCodeExporter]

Right, I've found a rather roundabout way to get the correct pubKey now. 
Basically I generate two candidates (starting with 02 or 03) from the long 
string and check which one of them is able to verify a signature generated by 
the original address. Alternatively just do a toAddress and see which one 
matches.

Original comment by carlosm...@googlemail.com on 23 Nov 2013 at 4:11

[GoogleCodeExporter]

There's also an ECKey constructor with "compressed" as an option. Set to true.

Original comment by carlosm...@googlemail.com on 23 Nov 2013 at 4:35

[GoogleCodeExporter]

The ECKey API needs a lot of work. The behaviour you're seeing is indeed due to 
compressed vs uncompressed keys. The new ECKey() c'tor creates a compressed 
key. The others will create uncompressed keys. The "compressedness" is supposed 
to be recorded out of band, it's not an inherent property of the serialized 
private key.

I'm going to mark this as Invalid because the API is not buggy, it's just not 
clear enough. But that doesn't mean it's not an issue - you were confused and 
that's understandable. Redesigning ECKey is a different project, however.

Original comment by mh.in.en...@gmail.com on 24 Nov 2013 at 8:05

• Changed state: Invalid