Nice work again, python just seems so much easier to deal with than these other libraries, I guess just preference though
I agree. I always choose Python if I can
In this case, I chose a mixture of Python and C. I am glad I stuck with C/OpenSSL when other people are using Java/Bouncy Castle or other approaches. My code can be integrated into the main Bitcoin codebase without introducing any new dependencies. I am interested to see if I can extend it to deal with this .bitkey format people are talking about.
I have
stated elsewhere that I wanted to replace the Wallet format (which I regard as an ugly black box with way too much unnecessary data in it -- data like transactions and public keys are redundant and are not necessary for restoring precious coins from a backup) with a new one. I see now (having worked with the wallet) that it's quite integral to Bitcoin and it isn't going to be replaced any time soon.
Therefore, I am thinking that Bitcoin should be reading and writing two formats simultaneously. It keeps a wallet.bitkey file in the home directory. Whenever it writes a new private key to the wallet.dat, it also appends it to wallet.bitkey in human-readable format. When it starts up, it scans wallet.bitkey and if it sees any private keys which aren't in the wallet, it loads them in. That way, you can always check your wallet.bitkey file to see what keys you have in human readable format. And you can import/merge such files manually, and Bitcoin will slurp them in at startup.
In this case, my code would be useful because it uses OpenSSL to read in a private key and make a full DER key which is required by wallet.dat. The code to read wallet.bitkey and insert keys into wallet.dat would need this mechanism.
