Bitcoin's Next Frontier: An Interplanetary Currency for Earth and Mars

The core challenge stems from the extreme physical constraints of interplanetary communication, specifically the "one-way light time" (OWLT) between Earth and Mars, which ranges from 3 to 22 minutes. This high latency, combined with intermittent contacts and blackouts, makes synchronized mining impractical for Bitcoin's current 10-minute block interval. Traditional blockchain mechanisms would either lead to unfair mining across planets or require significantly longer block intervals (on the order of hours or more), severely impacting throughput.

This proposal addresses this by preserving Bitcoin's base-layer parameters and shifting adaptation to higher layers. It introduces three coordinated layers:

• Header-first replication: Prioritizing the rapid transfer of block headers to ensure timely fork choice and Median-Time-Past (MTP) anchoring, while other data like compact filters and transactions can be transmitted opportunistically.
• Latency-aware Lightning policy: Utilizing the Lightning Network for retail payments with adjusted timelocks (CLTV/CSV) that account for the interplanetary one-way light time and potential jitter.
• Asynchronous settlement rails: Employing strong federations or blind-merge-mined commit chains (BMM sidechains) for secure, asynchronous settlement of high-value transactions between the planetary domains.

Crucially, it introduces Proof-of-Transit Timestamping (PoTT), a novel transport-level receipt primitive. PoTT provides cryptographic, tamper-evident audit trails for Bitcoin data across these high-latency links, enhancing reliability and accountability without altering Bitcoin's fundamental consensus or monetary base.

Proof-of-Transit Timestamping (PoTT) is a new transport-level receipt primitive that cryptographically chains hop-timed custody attestations to Bitcoin payload hashes. Essentially, it creates a tamper-evident propagation history for data traveling across deep-space links, providing a verifiable chain-of-custody.

PoTT is necessary for interplanetary Bitcoin because:

• High-latency dispute resolution: In an interplanetary context, disputes often revolve around the exact time a message (e.g., a Bitcoin transaction, a Lightning update, or a block header) arrived relative to a timelock or deadline. Existing communication layers lack cryptographically verifiable records of message propagation across such vast distances and intermittent connections.
• Accountability and reliability: PoTT provides verifiable evidence of when relays received and forwarded a payload, ensuring integrity of the payload and receipts, authenticity of relay claims, ordering/timeliness via monotonic timestamps, and publicly attributable claims at the relay level. This is critical for operational accountability and for resolving off-chain disputes, particularly in the Lightning Network and for sidechain pegs.
• No Bitcoin consensus changes: PoTT operates at the transport layer (out-of-band metadata) and does not require any changes to Bitcoin's core consensus rules or its monetary base, making it an additive and non-disruptive solution.

It complements existing Delay/Disruption-Tolerant Networking (DTN) protocols like BPv7/BPSec by adding a unique per-hop custody time chain anchored to external time beacons and an OWLT policy.

PoTT provides cryptographic proof of transit through a structured receipt system that is chained and signed at each hop. Here's how:

Receipt Structure: Each relay node appends a receipt containing:

• h: The payload digest (e.g., Bitcoin transaction hash).
• ν: A unique per-message nonce, minted by the originator, preventing replay attacks.
• NodeIDi: The identifier (public key) of the relay node.
• t(i)in: Ingress timestamp (when the relay received the message).
• t(i)out: Egress timestamp (when the relay sent the message).
• previ: A hash binding to the previous hop's receipt (excluding its signature), creating a tamper-resistant chain.
• si: A Schnorr signature from the relay node covering all the above data (except its own signature).

Chaining and Anti-splice: The previ field ensures that each receipt is cryptographically linked to the previous one. Any attempt to remove, reorder, or alter an interior hop will invalidate subsequent signatures and be detected, preventing splice/replay attacks.

Verification: A verifier can check:

• All signatures using an authorized relay key list.
• Consistency of the payload hash (h) and nonce (ν) across all receipts.
• Timestamp monotonicity (t(i)in ≤ t(i)out < t(i+1)in).
• The correctness of the previ hash chain.
• Compliance with relay policy checks and time-beacon audits.

PoTT aims to provide:

• Integrity of payload and receipts: Ensuring the data and its transit record have not been tampered with.
• Authenticity of relay claims: Verifying that each relay genuinely processed the message at the claimed times.
• Ordering/Timeliness via monotonic timestamps: Establishing a verifiable sequence of events and proving messages arrived within expected timeframes.
• Publicly attributable claims at the relay level: Making each relay accountable for its actions.

While PoTT doesn't prevent censorship or guarantee liveness, it makes such actions auditable and attributable to a specific segment of the path, degrading gracefully to administrative assertions if all relays collude and time beacons are compromised.

The system adapts the Lightning Network for interplanetary use through latency-aware timelocks and asynchronous settlement rails.

Latency-aware Lightning policy:

• The one-way light time (OWLT) and round-trip time (RTT) between planets necessitate significantly larger timelocks (CLTV and CSV) for Lightning channels to remain secure.
• A closed-form parameterization is introduced to calculate the ∆extra CLTV (additional CLTV blocks) based on RTT and a "jitter allowance" (J). For Earth-Mars, this could mean an additional 11 blocks, bringing total CLTV to potentially 157 blocks (vs. a base of 144).
• This ensures that HTLCs (Hashed Timelock Contracts) have sufficient time to propagate across interplanetary links, even under worst-case latency conditions and network disruptions, before they expire or become vulnerable to attacks.

PoTT Evidence Packaging: PoTT chains are attached to commitment and settlement evidence packages. This evidence is consumed by watchtowers and counterparties to strengthen disputes about "arrived-before-expiry" conditions without altering BOLT (Lightning Network Baseline Requirements) wire formats or on-chain enforceability, which remains purely timelock/script-based.

Asynchronous settlement rails:

• For higher-value flows and to bridge monetary domains (Earth's Bitcoin L1 and Mars' local block production), strong federations or blind-merge-mined (BMM) commit chains are used.
• These act as "sidechains" where Mars can operate a pegged commit chain with 1:1 pegged assets.
• Crucially, "peg-in/out bundles" (transactions moving assets between the main chain and the sidechain/federation) must include PoTT evidence. This ensures auditability and tamper-evident logistics histories for high-value asynchronous settlements, again without modifying Bitcoin's base monetary rules.

This layered approach allows for fast, local retail payments on Mars via Lightning, while securely settling larger, interplanetary transactions asynchronously.

Time synchronization and malicious relay behavior are critical concerns, and the architecture addresses them through several mechanisms:

Time Synchronization:

• Reference Time-Beacons: Each relay and gateway maintains a local clock and access to one or more reference time-beacons (e.g., GNSS on Earth, optical two-way time transfer on deep-space links).
• TAI Timestamps: PoTT timestamps specifically use 64-bit International Atomic Time (TAI) seconds, a highly stable time scale, with a defined epoch, for internal consistency. Conversions to UTC for display or comparison with Bitcoin's Median-Time-Past (MTP) use a valid leap-second table.
• Clock Uncertainty Bound (σt): The system accounts for a clock uncertainty bound (σt). If beacons are unavailable or exceed this bound, operators should increase verification margins (δ) or quarantine PoTT evidence.
• MTP Anchoring: When PoTT evidence is used for disputes, timeliness is assessed against Bitcoin's Median-Time-Past (MTP) (BIP-113), not wall-clock time. A safety allowance (δ) and a policy bound on MTP-UTC skew (∆MTP) are applied during verification.

Malicious Relay Behavior:

• Relay Collusion/Forged Timestamps: Administrative Diversity: Verification profiles (e.g., PoTT-M2) require a minimum number of relays (e.g., ≥3) from distinct operator domains and at least one time anchor from each planetary domain. This reduces the risk of collusion. Independent Time-Beacons: Verifiers check PoTT chains against signed public time-beacons on each domain and the ephemeris-derived one-way light time (OWLT) envelope. Multiple independent beacons and cross-checks limit the feasibility of forging timestamps. Path Diversity: For high-stakes disputes, verifiers should require evidence from at least two path-diverse PoTT chains (disjoint relay operators and, when feasible, disjoint time-beacon regimes).
• Receipt Omission or Truncation: Verifiers enforce minimum-hop and diversity policies. Missing receipts invalidate policy compliance. DTN's custody-based retransmission (RFC 9171) provides a mechanism for recovery.
• Sybil Relays: Operators maintain authorized relay key lists with revocation procedures. Watchtowers and federation members reject chains containing unauthorized NodeIDs.
• Censorship: While PoTT doesn't prevent censorship, it makes it auditable and attributable to a segment of the path, ensuring accountability.
• Denial-of-Service via Oversized Metadata: PoTT chains are capped (e.g., ≤32 hops or ≤8 kB per bundle) to prevent abuse.

In essence, the system relies on a combination of cryptographic proofs, administrative oversight, and redundancy (multiple paths, multiple time-beacons) to maintain security and accountability.

Practical Implications:

• Bitcoin as Universal Monetary Standard: Demonstrates that Bitcoin can indeed function as a shared monetary standard between Earth and Mars, preserving its core monetary base and decentralized validation.
• Local and Fast Payments: Local verification remains cheap and efficient. Retail payments can proceed quickly over the Lightning Network with adjusted safety margins.
• Auditable High-Value Settlement: High-value flows can settle asynchronously with tamper-evident logistics histories provided by PoTT, enhancing trust and accountability.
• Incremental Deployment: The architecture is designed for phased deployment, starting with Earth testbeds and gradually expanding to Mars orbit and surface networks.
• Compatibility: It composes with existing Bitcoin Improvement Proposals (BIPs) and Lightning Network BOLTs without requiring changes to Bitcoin's L1 consensus, making it highly interoperable.
• Physics-Aware Policy: Turns the hard physical limit of light-time into explicit policy knobs (e.g., adjusted timelocks) rather than requiring fundamental changes to Bitcoin's protocol.

Limitations and Scope:

• No Liveness Guarantee: PoTT provides accountable custody attestation but does not guarantee liveness or prevent relays from censoring or dropping traffic.
• Assumed Cryptographic Soundness: Relies on the soundness of cryptographic primitives (hashes, signatures) and the availability of bounded clock uncertainty and independently operated time-beacons. Extreme failures in these assumptions can weaken evidence quality.
• No L1 Miner Fairness Equalization: The design does not attempt to equalize miner fairness across planets at the base layer (L1). This means temporarily segmented fee markets and potential rebalancing costs/FX-like spreads between domains during periods of limited inter-domain connectivity.
• Throughput vs. Fairness Trade-off: Preserving Bitcoin's 10-minute block interval means accepting that synchronous cross-planet competitive mining is not feasible, rather than increasing block intervals to hours, which would drastically reduce global throughput.
• Privacy Concerns: Routine PoTT receipts expose hop count and coarse path structure. A "commit-and-reveal" privacy mode is proposed, where relays onion-encrypt metadata, and full transcripts are only revealed during disputes.

In summary, the design provides a practical pathway for interplanetary Bitcoin by accepting the unavoidable costs of distance at higher layers, but acknowledges that full synchronization at the base layer is impossible without sacrificing throughput.

The system handles the large amount of Bitcoin data through header-first replication and by differentiating the priority and timing of data transmission based on its importance. This leverages the Delay/Disruption-Tolerant Networking (DTN) model.

Header-first Replication:

• Priority for Headers: Gateways and relays prioritize the transmission of Bitcoin block headers. Headers are crucial for timely fork choice and for anchoring Bitcoin's Median-Time-Past (MTP), which is essential for timelock calculations.
• Low Bandwidth Requirement for Headers: Block headers are relatively small (around 80 bytes each). At Bitcoin's rate of approximately 52,560 blocks per year, the annual data budget for headers is only about 4.2 MB/year, translating to a very low sustained bandwidth of ≈1.07 bits per second (bps). This ensures critical chain awareness can be maintained even over very constrained interplanetary links.
• Opportunistic Transmission for Filters: Compact filters (BIP157/158), while larger (a conservative median of 20 kB per block), are treated separately. They amount to approximately 1.05 GB/year (≈267 bps). Deep-space relays may ship headers immediately and schedule filters opportunistically or via checkpoints, preserving safety while matching link budgets.
• On-Demand for Transactions/Compact Blocks: Full transactions and compact blocks are fetched on demand, meaning they are retrieved only when specifically needed, further optimizing bandwidth usage.

PoTT Overhead:

PoTT receipts themselves add overhead, but it's relatively small. Each receipt is approximately 203 bytes. For a chain of 10 hops, this would be around 2.0 kB. This metadata is carried alongside the Bitcoin payload in DTN extension blocks or as sidecar bundles, not directly embedded within Bitcoin's consensus data. PoTT adds kilobytes, not megabytes, per interplanetary bundle.

By strategically prioritizing small, critical data (headers) and deferring larger, less time-sensitive data, the architecture manages the bandwidth constraints of interplanetary links effectively, ensuring that essential Bitcoin operations can continue reliably.

The proposed roadmap for deploying this interplanetary Bitcoin architecture is phased, starting with terrestrial testing and gradually extending to Mars.

Phase 0: Earth Testbeds:

• This initial phase focuses on developing and testing the core components and concepts in terrestrial environments.
• It would involve emulating AU-scale (Astronomical Unit) RTT (Round-Trip Time) and blackout conditions to rigorously test the system's resilience and performance under conditions similar to deep space.
• This phase would also include formal security and timing proofs for PoTT and its anti-splice construction to strengthen confidence in the standard.

Phase 1: Cis-Mars Demos:

• This phase involves public pilot demonstrations linking separated ground stations.
• It would specifically test header-first replication, latency-aware Lightning channels, and PoTT evidence enforcement in a more realistic, though still terrestrial, distributed environment.
• During this phase, efforts would also focus on producing an open, interoperable specification (I-D/RFC-style) for PoTT's DTN extension block and receipt wire format, along with a public reference library for Bitcoin/Lightning integration.

Phase 2: Mars Orbit/Surface Networks:

• This phase marks the deployment of the architecture to Mars orbiters and surface networks.
• It would involve real-world testing and operation of the interplanetary Bitcoin infrastructure in the Mars environment.

Phase 3: Scale Security via Blind Merge-Mining and Mature Governance:

• The final phase aims to scale the security and robustness of the system.
• This includes the potential adoption of blind-merge-mined (BMM) commit chains (sidechains) as an alternative to strong federations for local block production and settlement on Mars, if this technology matures and is adopted.
• It also involves establishing mature governance frameworks for cross-domain trust, key management, and relay allowlists (e.g., DNSSEC-anchored manifests with mirrored roots and co-signed checkpoints by federated governance groups).

This phased approach allows for incremental development, testing, and refinement, moving from theoretical concepts to a fully operational, cross-vendor standard for interplanetary Bitcoin networks.