{"id":"2bada1c7-7c17-464d-8ad9-1777590dca7b","arxiv_id":"2508.20591","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":10,"one_line_summary":"An architecture for interplanetary Bitcoin that keeps Earth's base layer unchanged and adds PoTT, a cryptographically chained, hop-timed receipt layer for dispute evidence across high-latency links.","lead":"This paper proposes an architecture for using Bitcoin between Earth and Mars, built on delay-tolerant networking, long-horizon Lightning channels, and a new receipt primitive called Proof-of-Transit Timestamping (PoTT). A smart generalist might read it to see how a hard physical limit, interplanetary light delay, could be absorbed by higher protocol layers rather than changing Bitcoin itself.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"PoTT's chain endpoint is not authenticated: suffix truncation makes the terminal timestamp attacker-controllable, which breaks the arrived-before-expiry anchor in §5.4.","rationale":"The paper's central claim is that PoTT receipts provide tamper-evident, splice-resistant, hop-timed custody chains usable in Lightning disputes. That claim has two parts: the receipt chain is bound to the payload, and the chain's timing is a reliable record of transit. The first part is well specified (hash chain plus signatures). The second part silently assumes the chain's final receipt is the true end of the path. I could not find any mechanism in §5.2, §5.4, or Appendix A that commits to a chain length, a destination relay, or a delivery receipt. Since the verification algorithm checks each receipt's internal consistency but not completeness, a suffix-truncated chain is indistinguishable from a genuine shorter path. The paper's own §7 discussion of truncation relies on verifier policy (minimum hops, diversity), which cannot detect tail removal without an authenticated expectation of the full path. This is a concrete correctness gap, not a disagreement with external consensus. The abstract's caution about time-beacon compromise is a stated trust assumption and is handled honestly; the truncation issue operates inside the assumed model, so it is the more load-bearing concern. The reader's Observation 1 factor-of-1/ε inconsistency is a rigor issue, but it goes in the conservative direction for the paper's argument (larger b strengthens the case for higher-layer adaptation), so it is not the crux. A CONDITIONAL verdict remains appropriate, but it should be conditioned on fixing the chain-endpoint problem — for example by adding a destination-signed final receipt or an out-of-band commitment to the full receipt list — and verifying truncation resistance.","tokens_in":13763,"tokens_out":10938,"duration_ms":108928,"concrete_test":"Take the Appendix A CBOR test-vector receipt and append two more valid receipts with monotonic TAI times generated according to §5.2, then run the §5.2 verification algorithm on the full 3-hop chain and on the suffix-truncated 2-hop prefix. Record the terminal timestamp used by the §5.4 inequality in each case. If the prefix verifies and its earlier terminal time flips the arrived-before-expiry outcome, suffix truncation is an attack. Then repeat with a candidate fix (e.g., a terminal receipt signed by the destination gateway, or a commitment to the full receipt list) and check that truncation is rejected.","verdict_should_be":"UNCHANGED","load_bearing_attack":"PoTT's verification rules (§5.2) check signatures, h/ν consistency, timestamp monotonicity, and prev_i links, but they never authenticate the chain's end: there is no expected terminal NodeID, no total hop count, and no destination receipt. A valid chain can therefore be truncated by dropping all receipts after hop k; the remaining prefix passes every check, and the terminal timestamp t_out^(k) is earlier than the true terminal t_out^(N). Section 5.4's arrived-before-expiry test uses exactly this terminal timestamp, so a party can make a late payload appear to have arrived before expiry by omitting the later, slower hops. The Appendix A wire format has no length or terminal commitment, and §7's truncation mitigation (minimum-hop and diversity policies) cannot detect suffix removal, because the verifier has no authenticated expectation of the true path length or endpoint. This is not merely the degraded 'administrative assertions' case; it breaks the tamper-evidence guarantee even when PoTT-M2's at-least-one-honest-relay and time-beacon assumptions hold. The chain's splice-resistance protects interior hops but not the boundary, and the central dispute-resolution value depends on the boundary being genuine.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript proposes an architecture for operating Bitcoin between Earth and Mars without changing Bitcoin's consensus layer. The core technical novelty is Proof-of-Transit Timestamping (PoTT), a receipt primitive in which each DTN relay on a path appends a signed, timestamped receipt containing the payload hash h, a per-message nonce ν, the relay identity, ingress and egress times, and a hash link prev_i to the prior receipt. The paper claims that PoTT supplies a missing accountability layer for delay-tolerant Bitcoin: it provides tamper-evident, splice-resistant, ordered custody chains that can be used in Lightning disputes and peg audits, and it integrates with header-first replication and latency-aware CLTV/CSV timelock policy. The paper also gives overhead estimates, a verification profile (PoTT-M2) with minimum hop and diversity requirements, a wire format, and a test vector.","tokens_in":13998,"tokens_out":11052,"duration_ms":99994,"significance":"If PoTT delivered its stated guarantees, the contribution would be of genuine interest: it specifies a concrete, standards-aligned mechanism for making DTN custody timing auditable, with sensible choices such as TAI timestamps, BIP-340 Schnorr signatures, canonical CBOR, and a normative test vector. The paper is also transparent about the limitation that compromise of all time-beacon regimes degrades PoTT evidence to administrative assertions. However, the central tamper-evidence guarantee is undermined by a gap in chain-endpoint authentication, described below. The architecture-level ideas (header-first replication, latency-aware timelocks) are not themselves novel, but their combination with a receipt layer is a plausible direction. The significance therefore depends on whether the truncation vulnerability can be closed in revision.","major_comments":[{"comment":"A verified PoTT chain has no authenticated terminal receipt. The verification rules in §5.2 check signatures, h/ν consistency, timestamp monotonicity, and the prev_i links, but they never check that R_k is the expected final relay, that the hop count equals a committed value, or that a destination receipt exists. Consequently, removing all receipts after hop k yields a prefix that passes every check. §5.4's arrived-before-expiry test uses the terminal timestamp t*_TAI = t_out^(k), so a late payload can be made to appear to have arrived before expiry by presenting only the earlier-hop prefix, which has an earlier t_out. Section 7's truncation mitigation (minimum-hop and diversity policies) cannot detect suffix removal because the verifier has no expectation of the true path length or endpoint. This breaks the tamper-evidence guarantee even when Assumption (PoTT-M2) holds. The fix is to commit to the chain endpoint: for example, the originator signs the expected terminal NodeID and/or total hop count, or the destination emits a final receipt bound to the same (h,ν), and verifiers reject chains missing that terminal commitment.","section":"§5.2, §5.4, §7"},{"comment":"The abstract and §1 claim that the proposal 'measurably improves reliability and accountability' without altering consensus, but the manuscript reports no measurements, simulations, or testbed results. The only quantitative figures are overhead estimates (e.g., ≈203 bytes per receipt, ≈4.2 MB/yr for headers), which do not measure reliability or accountability. Section 10 lists 'end-to-end testbeds' as future work, so the evidence does not support the word 'measurably.' Either add measurements from an emulation or prototype, or revise the claim to describe a qualitative mechanism, e.g., 'provides tamper-evident evidence that can improve accountability.'","section":"Abstract, §1, §10"}],"minor_comments":[{"comment":"Observation 1's statement and its proof sketch are inconsistent: the statement gives b ≳ 2 max_t τ(t) + M, while the sketch derives b ≳ (2 max_t τ(t) + M)/ε. The numeric example with ε=0.05 yields 880 minutes ≈ 14.7 hours, which contradicts the observation's assertion that 'this implies b on the order of an hour or longer.' Also, the phrase 'throughput penalty of at least b/10 relative to Bitcoin's current 10-minute cadence' appears inverted; the relative throughput to Bitcoin's 10-minute cadence should be 10/b, not b/10.","section":"§6, Observation 1"},{"comment":"The statement 'a chain cannot be cut-and-rejoined without detection' is misleading: the hash chain binds each receipt only to its predecessor, so removing a suffix is not detected. Consider rephrasing to 'interior cuts' or 'splice attempts' to accurately reflect the property.","section":"§5.2"},{"comment":"The paper sets the MTP–UTC skew bound ΔMTP to 1 hour as a 'conservative policy bound' and mentions a default drift estimation window n=4032 blocks, but it does not provide a procedure for estimating ΔMTP from observed MTP drift or cite published measurements supporting the 1-hour choice. A brief justification or reference would strengthen the policy's credibility.","section":"§5.4"}],"recommendation":"major_revision","confidential_remarks":"The truncation vulnerability is a genuine blocker for the paper's central claim, but it is fixable with a terminal commitment or destination receipt. If the authors also temper the 'measurably improves' claim and correct the Observation 1 heuristic, the paper could be publishable as a systems/standards contribution. Note that some load-bearing context relies on non-peer-reviewed preprints (e.g., [5], [16], [31]); this is acceptable for a forward-looking design paper but should be flagged to the authors."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"PoTT is genuinely new and clearly specified. The paper defines a per-hop, TAI-timestamped, hash-chained receipt bound to a Bitcoin payload digest, with a nonce-based anti-splice construction, and it gives a CBOR wire format, a test vector, and explicit verification rules. The survey of DTN/BPv7/BPSec, Lightning timelock work, and sidechain rails is competent, and the authors are honest about the degenerate case where both time-beacon regimes are compromised: they concede PoTT degrades to administrative assertions. That admission is to their credit.\n\nThe soft spots are real. The biggest is the truncation attack the stress-test note exposes. Verification checks signatures, hash consistency, monotonic timestamps, and prev-links, but nothing authenticates the end of the chain: there is no terminal NodeID, no total hop count, no destination receipt. A valid chain can be cut short, and the truncated prefix passes every check. Since the arrived-before-expiry test in §5.4 uses the terminal timestamp, a late payload can be made to look early by dropping the slower hops at the end. This isn't the degraded 'administrative assertions' case; it breaks the tamper-evidence guarantee even under the full PoTT-M2 assumptions. The fix is straightforward — a destination receipt or a signed total-hop-count and a final timestamp — but as written the central dispute-resolution anchor isn't sound.\n\nSecond, the security properties in §5.3 are asserted rather than proven, and §10 defers the formal work. That's acceptable for a design paper, but it means the paper should not claim PoTT 'measurably improves' anything; there are no measurements, no implementation, and no quantitative baseline. Observation 1's stale-rate heuristic is also internally inconsistent: the statement gives b ≳ 2 max τ + M, while the sketch divides by ε. That's a factor of 1/ε between the result and its derivation — worth fixing even if the heuristic is explicitly informal.\n\nWho is this for? Readers interested in delay-tolerant settlement, Lightning under long RTT, or DTN-based evidence layers. The architecture is coherent, the PoTT primitive is reproducible from the paper, and the limitations are stated rather than hidden. With the truncation issue resolved, the paper would be a solid contribution; without it, the headline claim of tamper-evident time-anchoring doesn't hold.\n\nI'd send it out for review — a serious referee could push the authors to either fix the endpoint authentication or weaken the claims. It's not a desk reject.","headline":"PoTT is a well-specified new primitive, but the chain endpoint is unauthenticated, so suffix truncation breaks the arrived-before-expiry anchor; fixable but load-bearing.","tokens_in":14603,"tokens_out":2501,"would_cite":false,"duration_ms":22381,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Bitcoin can bridge Earth and Mars without changing consensus.","keywords":["Bitcoin","Proof-of-Transit Timestamping","Delay/Disruption-Tolerant Networking","Lightning Network","interplanetary settlement","time synchronization","timelock policy","blind merged mining"],"falsifier":"Run a controlled experiment where every relay on a path colludes and both planetary time-beacon domains are treated as compromised to generate a PoTT chain for a payload that never traversed the path; if the fabricated chain passes signature, monotonicity, OWLT-envelope, and beacon-consistency checks, then PoTT-M2's core assumption is violated and the receipt layer no longer anchors time.","tokens_in":13458,"feed_emoji":"🪐","tokens_out":6798,"duration_ms":56720,"temperature":0.7,"pith_summary":"Bitcoin's 10-minute block cadence cannot support synchronized competitive mining across Earth and Mars, where one-way light time varies from 3 to 22 minutes; the paper argues this does not prevent Bitcoin from serving as a shared interplanetary monetary standard. It introduces Proof-of-Transit Timestamping (PoTT), a transport-level receipt layer that cryptographically chains ordered, hop-timed custody records to Bitcoin payload hashes over delay-tolerant links. With header-first replication, latency-aware Lightning timelocks, and asynchronous settlement through federations or blind-merge-mined commit chains, the paper claims a practical interplanetary Bitcoin economy emerges without touching Bitcoin consensus or its monetary base. A sympathetic reader should care because the architecture turns physics constraints into explicit policy parameters rather than consensus changes.","feed_headline":"Bitcoin can bridge Earth and Mars without changing consensus","feed_subtitle":"A Proof-of-Transit receipt chain adds accountably timed custody for interplanetary Bitcoin data.","key_machinery":"Proof-of-Transit Timestamping (PoTT) is the carrying mechanism: each relay appends a CBOR-serialized receipt R_i = (h, ν, NodeID_i, t_in, t_out, prev_i, sig_i), where prev_i is the hash of the previous receipt with its signature stripped, and sig_i is a Schnorr signature over h concatenated with ν, NodeID_i, t_in, t_out, and prev_i. The chained prev values make the transcript tamper-evident and splice-resistant, while TAI-encoded timestamps and per-hop jitter checks tie custody to physical light-time geometry. The argument also relies on a closed-form timelock rule: the extra HTLC CLTV margin is ceil((RTT + J) / b_target) blocks, converting one-way light time and jitter into concrete Bitcoin blocks.","core_discovery":"PoTT binds each relay's signed ingress/egress timestamps to a payload digest and a per-message nonce, with every receipt hashing the previous receipt's unsigned bytes to form a splice-resistant chain; retransmissions must mint a new nonce, and removing or reordering a hop breaks all subsequent signatures. Verification checks signature validity, monotone timestamps within a one-way-light-time envelope, and time-beacon consistency; the recommended profile PoTT-M2 requires at least three relays from two administrative domains and independent time anchors per domain. The paper uses the chain to anchor 'arrived-before-expiry' claims to Bitcoin's MedianTimePast (BIP-113), so Lightning watchtowers and peg operators can treat receipts as dispute-grade evidence while full-node validation remains unchanged.","pith_inferences":["If PoTT matures, the same receipt layer could be reused for any high-latency Bitcoin transport, including Earth-only links with long outages, not just interplanetary paths.","A terrestrial delay-tolerant emulation with controlled round-trip time and blackout intervals could measure whether the proposed timing margins actually yield zero false channel closures; that experiment is testable now.","The anti-splice hash chain is generic enough to serve as audit evidence for non-Bitcoin interplanetary cargo or data custody, though the paper only applies it to Bitcoin payloads.","The paper leaves as future work a formal game-based proof of PoTT's anti-splice property; until that exists, the security claim rests on the informal chain-binding argument."],"forward_implications":["Earth's layer-one stays exactly as it is; Mars operates a 1:1 pegged commit chain or strong federation for local block production, so no new Bitcoin is issued.","Interplanetary Lightning channels can be sized in advance: at maximum Earth–Mars light time with a 60-minute jitter allowance, the timelock premium is 11 blocks, giving a worked total of 157 blocks with common base margins.","Header-first replication needs about 4.2 MB per year for headers and about 1.05 GB per year for compact filters, small enough for deep-space link budgets.","PoTT evidence packages connect custody timing to BIP-113 MedianTimePast, giving watchtowers and federations a concrete arrived-before-expiry test in disputes.","The same receipt chain supports both near-term strong-federation settlement and longer-term blind-merge-mined commit chains if those are adopted."],"supporting_citations":[{"why":"The Bitcoin whitepaper supplies the base-layer monetary model that the architecture explicitly preserves.","marker":"[4]"},{"why":"Bundle Protocol v7 is the delay-tolerant transport substrate that carries PoTT receipts across interplanetary links.","marker":"[8]"},{"why":"BPSec defines the bundle-level security mechanisms whose coverage PoTT extends with custody timestamps.","marker":"[9]"},{"why":"Sprites provides the constant-locktime payment-channel reasoning used to set latency-aware Lightning timelocks.","marker":"[15]"},{"why":"Time-dilation attack analysis motivates the need for auditable transport timing in watchtower policy.","marker":"[17]"},{"why":"BIP-113 median-time-past supplies the Bitcoin-time anchor for the arrived-before-expiry verification rule.","marker":"[25]"},{"why":"Strong federations define the near-term asynchronous settlement rail for Mars-side pegged assets.","marker":"[37]"},{"why":"Blind merge-mining defines the optional commit-chain mechanism that serves as the longer-term settlement alternative.","marker":"[2]"}],"fun_headline_variants":["Earth-Mars Bitcoin: PoTT timestamps chain custody","Proof-of-Transit: Tamper-evident interplanetary Bitcoin audit","Bitcoin without forks: New receipt chain for Mars bridges","Interplanetary Bitcoin: Timestamp receipts keep relays honest","PoTT: Secure custody chains for high-latency Bitcoin links"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The design's dispute value depends on at least one relay on the verified path being honest and on both planetary time-beacon systems staying within a bounded error of true time, since if all relays and both beacons are compromised, PoTT receipts reduce to administrative assertions.","fun_headline_variants_meta":{"raw":{"variants":["Earth-Mars Bitcoin: PoTT timestamps chain custody","Proof-of-Transit: Tamper-evident interplanetary Bitcoin audit","Bitcoin without forks: New receipt chain for Mars bridges","Interplanetary Bitcoin: Timestamp receipts keep relays honest","PoTT: Secure custody chains for high-latency Bitcoin links"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000205,"raw_usage":{"total_tokens":1392,"prompt_tokens":940,"completion_tokens":452,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":556,"completion_tokens_details":{"reasoning_tokens":365}},"tokens_in":556,"tokens_out":452,"duration_ms":4495,"temperature":1.0,"reasoning_tokens":365,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T16:42:52.200281+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a controlled experiment where every relay on a path colludes and both planetary time-beacon domains are treated as compromised to generate a PoTT chain for a payload that never traversed the path; if the fabricated chain passes signature, monotonicity, OWLT-envelope, and beacon-consistency checks, then PoTT-M2's core assumption is violated and the receipt layer no longer anchors time.","supporting_citations":[{"cited_title":"Nakamoto.Bitcoin: A Peer-to-Peer Electronic Cash System","cited_arxiv_id":null,"evidence_quote":"The Bitcoin whitepaper supplies the base-layer monetary model that the architecture explicitly preserves."},{"cited_title":"Burleigh et al.Bundle Protocol Version 7","cited_arxiv_id":null,"evidence_quote":"Bundle Protocol v7 is the delay-tolerant transport substrate that carries PoTT receipts across interplanetary links."},{"cited_title":"Birrane III, K","cited_arxiv_id":null,"evidence_quote":"BPSec defines the bundle-level security mechanisms whose coverage PoTT extends with custody timestamps."},{"cited_title":"Sprites and State Channels: Payment Networks that Go Faster than Lightning","cited_arxiv_id":null,"evidence_quote":"Sprites provides the constant-locktime payment-channel reasoning used to set latency-aware Lightning timelocks."},{"cited_title":"Median time-past as endpoint for lock-time calculations","cited_arxiv_id":null,"evidence_quote":"BIP-113 median-time-past supplies the Bitcoin-time anchor for the arrived-before-expiry verification rule."},{"cited_title":"Strong Federations: An Interoperable Blockchain Solution to Centralized Third-Party Risks","cited_arxiv_id":"1612.05491","evidence_quote":"Strong federations define the near-term asynchronous settlement rail for Mars-side pegged assets."},{"cited_title":"Blind Merged Mining (Consensus layer)","cited_arxiv_id":null,"evidence_quote":"Blind merge-mining defines the optional commit-chain mechanism that serves as the longer-term settlement alternative."}],"review_version":2}