Bitcoin-Hashed Transport Protocol (BHTP)

Abstract

The Bitcoin-Hashed Transport Protocol: A First-Principles Approach to Metadata-Resistant Communication Technical Specification v1.1 — Proposed Nostr Implementation Possibility (NIP) Overview Modern encrypted communication protocols achieve strong content confidentiality but systematically fail to protect communication metadata. Deep Packet Inspection (DPI) systems deployed at national firewalls and network chokepoints can identify, track, and selectively block encrypted communications without ever decrypting payload content—exploiting handshake patterns, packet size distributions, timing correlations, and protocol-specific signatures. The Bitcoin-Hashed Transport Protocol (BHTP) addresses this fundamental limitation through a novel approach: deriving ephemeral transport encryption keys from the Bitcoin blockchain, a globally synchronized and publicly observable source of cryptographic entropy. By eliminating key exchange negotiations entirely, BHTP renders encrypted traffic statistically indistinguishable from random noise to any observer not synchronized with the blockchain. Technical Architecture The Russian Doll Model BHTP implements a layered security architecture providing defense in depth: Outer Layer (Transport Obfuscation): AES-256-GCM encryption with keys derived via BLAKE3 from Bitcoin block hashes. Keys rotate approximately every 10 minutes with each new block. Provides censorship resistance by defeating real-time traffic analysis. Inner Layer (Payload Confidentiality): Standard NIP-44 encryption using XChaCha20-Poly1305 with keys derived from ECDH between Nostr identity key pairs. Provides true cryptographic confidentiality independent of transport layer security. This separation reflects that censorship resistance and confidentiality are orthogonal concerns with different security requirements and threat models. Key Derivation Function Kₙ = BLAKE3( Hₙ ‖ Hₙ₋₁ ‖ Tₙ ) Where: Hₙ: Current block hash (32 bytes) Hₙ₋₁: Previous block hash (32 bytes) Tₙ: Block timestamp (8 bytes, big-endian) The 72-byte input produces a 256-bit AES key. Including both current and previous hashes prevents edge-case failures during block propagation and increases entropy. Protocol Specification Event Structure (Kind 10059) json { "kind": 10059, "created_at": <unix_timestamp>, "tags": [ ["h", "<block_hash_hex>"], ["p", "<receiver_pubkey>"], ["iv", "<aes_gcm_nonce_hex>"] ], "content": "<base64_ciphertext>", "pubkey": "<sender_pubkey>", "sig": "<schnorr_signature>" } Anti-Fingerprinting Measures Standardized Padding: ISO/IEC 7816-4 padding to bucket sizes (1 KiB, 16 KiB, 256 KiB, 1 MiB) prevents size-based traffic analysis Lookback Window: Decryption attempts against Hₙ, Hₙ₋₁, Hₙ₋₂ accommodate block propagation latency and minor reorganizations Timestamp Validation: Events rejected if created_at exceeds 20 minutes from referenced block timestamp Failure Mode Handling Missing block headers: Queue messages until consensus reestablished (MUST NOT fallback to cleartext) Decryption failure: Retain temporarily for potential reorganization; discard after 1 hour Inner layer failure: Discard silently (message not intended for recipient) Security Analysis Threat Model Assumes adversary with: network observation at backbone level, sophisticated DPI capabilities, active probing, historical traffic recording ("harvest now, decrypt later"), and full blockchain access. Bounded by: no endpoint compromise, no private key access, no blockchain manipulation capability. Security Properties Traffic Indistinguishability: AES-256-GCM ciphertext is computationally indistinguishable from random bytes; bucket padding eliminates size-based fingerprinting Cost Asymmetry: Legitimate users: ~0.2ms per message. Mass surveillance adversary: O(N × B) decryption attempts for N packets across B blocks Layer Independence: Transport layer compromise reveals only NIP-44 ciphertext; inner layer security unaffected The Permanent Record Threat: Explicitly acknowledged—outer layer provides temporal obfuscation, not long-term secrecy. Inner NIP-44 layer provides actual confidentiality. Performance Characteristics Operation Time Throughput BLAKE3 (72 bytes) ~50 ns 1.4 GB/s AES-256-GCM (1 KB) ~150 ns 6.6 GB/s Total per message ~0.2 ms 5,000 msg/s Bandwidth overhead: ~3x for small messages (dominated by padding), decreasing proportionally for larger payloads. Implementation Bitcoin Header Acquisition Options: Full node (most trustworthy, ~500 GB storage) SPV client (~50 MB headers with proof-of-work validation) Multi-API queries (lightweight, trust assumptions) Library Requirements: Rust: blake3, aes-gcm, bitcoin crates JavaScript: blake3, @noble/ciphers, bitcoinjs-lib Python: blake3, cryptography, python-bitcoinlib Reference implementation provided in Rust demonstrating complete encryption/decryption flow. Contributions Complete cryptographic construction for time-based transport obfuscation using Bitcoin block hashes Layered "Russian Doll" security architecture separating censorship resistance from confidentiality Full protocol specification with data structures, procedures, padding, and failure handling Formal security analysis with proofs for indistinguishability, cost asymmetry, and layer independence Performance benchmarks and implementation guidance Keywords traffic analysis, censorship resistance, metadata protection, Bitcoin, Nostr, ephemeral encryption, deep packet inspection, protocol obfuscation, BLAKE3, AES-256-GCM, NIP-44, decentralized communication