usage flags for bitcoin addresses on OpenPGP keys [was: Re: human readable key algorithm]

Peter Todd pete at
Fri Jan 24 09:41:29 CET 2014

On Tue, Jan 21, 2014 at 11:30:24AM +0900, NIIBE Yutaka wrote:
> On 2014-01-16 at 17:00 -0500, Daniel Kahn Gillmor wrote:
> > That said, it's not an OpenPGP digital signature, so maybe the
> > traditional signing flag doesn't make sense either.  I certainly
> > wouldn't want attaching such a key to my OpenPGP certificate to make it
> > so that when i sent mail it signed my mail with my bitcoin wallet's key!
> Thank you for your suggestion.  You are right (and I am a kind of
> stupid to have such a strange subkey, even for my own experiment :-).

FWIW the thinking in the Bitcoin community right now is that you would
want to add a Bitcoin address to your OpenPGP key as a special type of
UID. The reason why you want to do that is a key problem in Bitcoin is
being sure that you're paying the person you think you are - not unlike
the problem of being sure you're encrypting a message to the right
person. Think of it as similar to how email addresses go in UID's.

You could still include a Bitcoin ECC private key in your GnuPG keyring,
but that's not actually all that important compared to the use-case of
knowing for sure that you're paying the right address.

Beyond that, we've come up with a scheme known as stealth addresses(1)
that lets the payee tell the payor how to derive a fresh bitcoin
addresss for every payment with ECDH so that from the stealth address
itself an outside observer can't link the payments together. This
privacy feature is considered to be very important.

Now, pragmatic question: What's a decent way to add a new UID type for
this? Seems that a User Attribute Packet is appropriate, I assume using
one of the private subpackets for now.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140124/4ae887f8/attachment.sig>

More information about the Gnupg-devel mailing list