Look for cyptocurrency (Bitcoin) private keys

[gchan]

I have started my attempt at addressing #76 (looking for cryptocurrency private keys). This is my first GoLang PR for an OS project and I welcome any feedback and assistance.

There is a few things I'm unsure of in my approach:

• Should I be creating a new type and functions for handling private keys (37 bytes vs 25 bytes for addresses)
• My implementation is based on the format described here but in bitcoin.html on line 91 the private key begins with an 'L'. When using this private key validator, it it unable to validate this private key. Even when I remove the 'L' character, it does not pass the checksum tests.

[laanwj]

I believe this is just an artifact - pinging @laanwj to confirm :)

I may have screwed up there. When in doubt I generally use python-bitcoinlib to check:

>>> from bitcoin import wallet
>>> key=wallet.CBitcoinSecret('L52r4HGHVKCUAtVxEhwvtSRakbLyDLRzCnWxm41mF2ceoPcd4zdY')
>>> key
CBitcoinSecret('L52r4HGHVKCUAtVxEhwvtSRakbLyDLRzCnWxm41mF2ceoPcd4zdY')
>>> key.nVersion
128
>>> binascii.b2a_hex(key)
b'e91c3515a558a7d11210534886ac73d2e007b628ef31e8dd5013e86be2e7d5af01'
>>> wallet.P2PKHBitcoinAddress.from_pubkey(key.pub)
P2PKHBitcoinAddress('1E2yYxpLeoauVFppDj4R5QTsx4NApbnSxs')

Seems like a typical mainnet private key (prefix 128), and it works out to the address mentioned in bitcoin.html. I think I used stock bitcoind to generate it. Also that wiki page confirms they can start with L or K:

Private keys associated with compressed public keys are 52 characters and start with a capital L or K on mainnet (c on testnet).

I suspect that private key validator doesn't handle compressed keys, which are the most common type of key these days (their private data is 33 bytes - 32 bytes key data | 0x01).

[gchan]

Thanks for the information @laanwj . It appears the mainnet keys do begin with a prefix. I have adjusted my implementation and completed the checksum validation.

@s-rah, I believe I have addressed all of your feedback in my latest changed. I also decided to move away from the using the structs to abstracted functions. WDYT?

[s-rah]

Thanks, This looks good to me. @gchan - can you rebase onto the onionscan-0.3 branch please - that has some extra testing/coverage checks and will be where this commit ends up until we finalize the 0.3 release.

[coveralls]

Coverage increased (+0.9%) to 26.288% when pulling cc9f078f09ee73aec399bb8a1d89b1daee0d4c0e on gchan:onionscan-0.2 into d48ca1b1c86132e40a370873fdc7035f96f22555 on s-rah:onionscan-0.3.

[coveralls]

Coverage increased (+0.9%) to 26.288% when pulling cc9f078f09ee73aec399bb8a1d89b1daee0d4c0e on gchan:onionscan-0.2 into d48ca1b1c86132e40a370873fdc7035f96f22555 on s-rah:onionscan-0.3.

[coveralls]

Coverage increased (+0.9%) to 26.288% when pulling edad49fff7b98ed2802278e9a6b4970de2eec7da on gchan:onionscan-0.2 into d48ca1b1c86132e40a370873fdc7035f96f22555 on s-rah:onionscan-0.3.

[gchan]

I've rebased the branch on onionscan-0.3. I also changed the base branch to the same.

Oops, I didn't create branch a when working on this and I can't change the branch on GitHub without creating a new PR. I don't think it should matter for our purposes (it will just say I want to merge from gchan:onionscan-0.2).

[coveralls]

Coverage increased (+0.9%) to 26.307% when pulling f5f8226ad88b906bfed369efef4cd5779d751a2e on gchan:onionscan-0.2 into d48ca1b1c86132e40a370873fdc7035f96f22555 on s-rah:onionscan-0.3.

[s-rah]

Woohoo! & Thanks! I'll take the +0.9% code coverage increase any day.