human readable key algorithm (was: gpgkey2bc: Generating address of Bitcoin from public key)

[NIIBE Yutaka]

On 2014-01-16 at 11:47 +0100, Werner Koch wrote:
> On Thu, 16 Jan 2014 08:48, gniibe at fsij.org said:
> 
> > Attached 'gpgkey2bc.py'.
> 
> Cool.  Feel free to put it under tools/.

Thanks.  I think that it's a proof of concept (less checking, no
robustness, etc.), and I'm afraid of Python version dependency.  For
real use, it would be better to extend gpgkey2ssh to support Bitcoin
address, say, with --btc option.  I'll look into gpgkey2ssh.

N.B.  I don't recommend using Bitcoin, per se.  It's a bit
contradictory if GnuPG (GNU Privacy Guard) pushed something with no or
less privacy.               ^^^^^^^^^^^^^

My hack only means that I'm going to accept BTC for people who already
use Bitcoin and it's GnuPG where I want to put my secret key.
Nevertheless, it's interesting that you can send BTC to your friend
when you have his OpenPGP key with a subkey of secp256k1 (even if he
hasn't been Bitcoin user yet, just owning private key of secp256k1
curve).  Anyhow, this is very good opportunity for me to rethink about
network and privacy.

> Which shows one of the little things I have not found a solution so far:
> 
> The "256E" is not very descriptive.
[...]
> One idea how to change it would be to use descriptions like:
> 
>     nistp256/12345678
>     secp256k1/975B9053
>     ed25519/87654321

I like this, but other options are OK too.

Besides, there is another place: --card-status.  We discussed last
year and currently it's like "256E" (for ECDSA NIST P-256) or "256e"
(ECDH NIST P-256):

   http://lists.gnupg.org/pipermail/gnupg-devel/2013-February/027410.html

This is needed to fix, too.  We need to consider updating of ECC
support for OpenPGP card specification as well, anyway.
--