search

WebOfTrustInfo / btcr-hackathon-2017

Virtual hackathon to create spec and code for Bitcoin-based Decentralized Identifiers (DIDs)
https://weboftrustinfo.github.io/btcr-hackathon-2017/
14 stars 7 forks source link

Encoding of Koblitz Public Key #16

Closed ChristopherA closed 7 years ago

ChristopherA commented 7 years ago

It doesn't appear that there is any standard yet for encoding of a koblitz curve public key (i.e. the secp256k1 curve).

There is a proposal of base58 prefix of 4 for compact Bitcoin public keys (see https://en.bitcoin.it/wiki/Base58Check_encoding ), but as far as I know no one uses that.

Bech32 is superior to base58 in a variety of ways, may be we should consider using that? I do know that Lightning is proposing using bech32 for public keys, but they are also putting other info there.

@jonasschnelli I know that your lib will output a hex encoded public key. Do you know of anyone else directly encoding public keys in base58? Are you aware of anyone using Bech32 for public keys besides in Lightning? Since you are adding bech32 to your lib, would you consider offering a public key encoder?

jonasschnelli commented 7 years ago

I guess the quasi standard for pubkey is hex representation. The length will define if it's compressed or not. It's not ideal but works.

Libbtc can work with hex pubkeys (as well as bitcoind).

The libbtc tool (as well as the C API) can do hex pubkey/bip32/privkey operations.

However, private keys have a base58 check standard (WIF). Ideally, we form a new private key encoding standard based on Bech32.

ChristopherA commented 7 years ago

@jonas I guess I dislike hex encoded public keys. I like how in the 25519 based app minilock you can share it easily for file sharing (mine is at 7rXYBKi1Xf9g9nupb9f8u6MHbobEJCMK3r3sChjN5RmGN and I shared it on Twitter at https://twitter.com/ChristopherA/status/634466769311105024).

Now normally for the twitter case you wouldn't share your public key verbally, you'd share your bech32 encoded DID, but there are still times in which you want to confirm a public key, especially in our case where our DID can point to other keys using the optional DDO.

I'd love it if libbtc could support a few other formats for public keys besides hex. At one point in the past there was a proposal to do it base58 with a prefix of 4, but I don' t know the history of why it never happened. Clearly we could do it better than base58check with bech32 and a different prefix.

Or I could just live with it being hex in my JSON files ;-)

kimdhamilton commented 7 years ago

This issue was moved to WebOfTrustInfo/rebooting-the-web-of-trust-fall2017#11