Proposal to migrate PeerIDs to match Tor v3 addresses

[Zolmeister]

Moved to: #172

I propose adapting Tor's .onion v3 spec for all PeerIDs moving forward:

peer_id = base32(PUBKEY | CHECKSUM | VERSION)
CHECKSUM = SHA3("peerid checksum" | PUBKEY | VERSION)[:2]

where:
  - PUBKEY is the 32 bytes ed25519 public key
  - VERSION is a 1-byte version field (default value '\x03')
  - "peerid checksum" is a constant string
  - CHECKSUM is truncated to two bytes

Examples (invalid checksum):
  pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd
  sp3k262uwy4r2k3ycr5awluarykdpag6a7y33jxop4cs2lu5uz5sseqd
  xa4r2iadxm55fbnqgwwi5mymqdcofiu3w6rpbtqn7b2dyn7mgwj64jyd

Main points:

• base32 for DNS
  • always, ux consistency. no multibase
• version byte at end
  • using a common prefix (Qm) makes it much harder for people to distinguish addresses
  • better vanity addresses
• has checksum
• fixed encryption key type
  • public key is always inline
  • changing encryption algorithm requires version byte increment, forces consistency within PeerID versions
• allows development of 'hidden services' (encrypted DHT records) a la Tor hidden services

Prior discussion:
Tor mailing list thread

Solves design constrains in #138
This solves #111 without adding the hash function to the protobuf

[Zolmeister]

Migration path:

1. Add Ed25519_inline key type to protobuf
   • All new keys will have this type

enum KeyType {
  RSA = 0;
  Ed25519 = 1;
  Secp256k1 = 2;
  Ed25519_inline = 3;
}

2. Ed25519_inline will always use the peer_id calculation above
   - 'implicit' hash function - solves Specify peer ID hash function in public key #111
   - no conflict with previous implementation Peer ID Calculation History And Resolution #138

[Stebalien]

In what way does this solve the design constraints in #138?

[Zolmeister]

It obviates (no hashing of keys)

• We need to provide a way to for users to select a hash function other than sha256 when computing their peer ID.

It meets

• Given a public key, peer ID calculation must be deterministic.
• There must be a case-insensitive way to express peer IDs appearing in IPNS paths (for browsers). Currently, peer IDs are always base58 encoded which is not case-insensitive.

It also has

• We'd like a way to "inline" public keys into peer IDs (if the public key is small enough to fit comfortably). This will allow encrypting a message to a peer without needing to look up their key first.
• (potentially) Peer ID Calculation History And Resolution #138 (comment)

  querying the DHT for PeerID -> metadata without disclosing PeerID or metadata

[yusefnapora]

@Zolmeister I think this would be a good candidate to go through the new process defined in #169.

If you want to write up a draft spec PR, we can form up an interest group and pull it into the repo as an initial draft to get some discussion around it.

[mxinden]

Closing here as discussion has continued on #172.