add split key generation

[ryancdotorg]

Add split key generation. If using bitaddress.org's vanity tool, conversion from uncompressed to compressed keys may be required.

[ryancdotorg]

This uses the addition method. Also note that compressed, uncompressed and hybrid public keys will all work.

[klynastor]

Thanks for writing. I just commited some bug fixes & speed improvements that I was working on earlier this morning. I will take a look at your new code soon.

[ryancdotorg]

Oh, nice. I was actually just looking at writing the code to coalescing adjacent/overlapping patterns myself, but you beat me to it.

I'm also planning on submitting a patch that iterates through keys by doubling them rather than incrementing, which appears to be 10-15% faster.

[klynastor]

Can you explain to me the security ramifications of doubling keys rather than incrementing them (as I am not an expert in ECDSA)? As I understand it, there are only 256 bits in a private key, so you can only double the key up to 256 times before the key becomes 0. Or are we talking something closer to left-shift operations, where bits at the top wrap around to the bottom? (Then, is this done 256 times before incrementing by 1? Or what other permutation is applied?)

[ryancdotorg]

No security impact. The key is a scalar value in a prime field, so you're actually doubling modulo the finite field order which is a large prime. As a result, the cycle length is effectively endless. The only other thing is that split key generation will require multiplication rather than addition to get the combined key, but tooling already supports this.

[RonaldSwaine]

Was right about to beginning making my own when saw there was already a PR for this.
Since its not pulled, I made the same changes for split key (only that one change set) but am not able to get correct values, testing with bitaddress.org and gobittest.appspot.com/VanityAll
(also cloned ryancdotorg/supervanitygen just in case as well, no success)

The printed PrivPart value, though a valid private key, does not produce the correct address when added to the mystery private key. Tried compressed and uncompressed too, just in case it was an issue reading it.

[ryancdotorg]

@RonaldSwaine I just tested it with gobittest.appspot.com/VanityAll and it's working there. I have a pull request against bitaddress.org that makes the vanity wallet tool support compressed keys.

I also have a fork of the original vanitygen tool somewhere that can just add two compressed private keys, and that works fine. Not sure if i've pushed it.

[RonaldSwaine]

You are correct, it is working correctly. The compression had me mixed up. I think I've been staring at too much hex. Thanks for reminding me to check what I already should have checked. :P

[klynastor]

Sorry, I really dropped the ball on this one. This is a classic case of me taking on too many projects at once and never getting back to it all. I will investigate soon.

[ryancdotorg]

@klynastor It looks like there's some minor merge conflicts with this - do you want to fix them, or shall I?

I neglected to add anything to the usage screen or readme - I could do that at create a new pull.