bip324 notes

bip324notes.md

Background and goals:

• Privacy (main goal)
• Make it so censorship resistance is not precluded by our design
• Increase the cost for ISPs to identify (and maybe supress) Bitcoin P2P traffic
• Upgrade path that allows for authentication, PQC upgrades without needed a major overhaul

BIP324 history

• 2016:
  • BIP150: Authentication (currently stalled)
  • BIP151: Encryption
• 2019:
  • BIP324: Supersedes BIP151
• 2021:
  • BIP324 revision (encryption-only, allows for upgrade path for authentication)

Design considerations

• Connection establishment latency is not critical
• Being modular is important

Current state:

• Handshake
  • Even-only pubkeys
  • Differentiate v1 and v2
  • Key derivation
  • Session ID for authentication
• Dual-cipher suite instances
  • ChaCha20-Poly1305@(TLS1.3, openssh, bitcoin)
  • Forward secrecy changes (key rotation)
• v2 p2p message format
  • Short message IDs
  • MAC instead of dbl-SHA256 (cpu gains - it's actually faster)

Things discussed:

• Pseudo-random bytestream (active attacks are still possible)
  • Cheap (3x normal ECDH, but still sub-100us) and hard to add in the future
  • Enables traffic shapers without protocol wrapping
• Not precluding censorship resistance
• Why x-cordinates are distinguishable

Changes coming up:

• Elligator-squared encoding for pubkey enchanges (indistinguishable from random)
• v2 protocol versioning (v2.0, v2.1, ...)
  • Explain hypothetical v2.1 with PQC KEM upgrade, v2.2 with authentication