Pith. sign in

REVIEW 2 major objections 3 minor 38 references

Bitcoin as an Interplanetary Monetary Standard with Proof-of-Transit Timestamping

T0 review · 2 major / 3 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Bitcoin can bridge Earth and Mars without changing consensus.

desk verdict 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. read the letter →

arxiv 2508.20591 v1 pith:NJC4YAOS submitted 2025-08-28 cs.CR

Jose E. Puente , Carlos Puente This is my paper · ORCID
classification cs.CR
keywords BitcoinProof-of-TransitTimestampingDelay/Disruption-TolerantNetworkingLightningNetworkinterplanetarysettlementtimesynchronizationtimelockpolicyblindmergedmining
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 3 minor

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.

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 (2)
  1. [§5.2, §5.4, §7] 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.
  2. [Abstract, §1, §10] 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.'
minor comments (3)
  1. [§6, Observation 1] 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.
  2. [§5.2] 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.
  3. [§5.4] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: PoTT is defined independently of its claimed uses, and the paper's central derivations are parameterizations and protocol definitions, not fitted predictions.

full rationale

I walked the paper's derivation chain searching for the enumerated circularity patterns. The central primitive, PoTT, is introduced in §5.2 as a new receipt format with its own formal definition: receipts bind h, ν, NodeID, ingress/egress TAI timestamps, and a previous-link hash, with each relay signing the encoded tuple. None of these quantities is defined in terms of the paper's conclusions (interplanetary Bitcoin feasibility, Lightning dispute evidence, or peg auditability). The latency-aware CLTV margin, Δextra_CLTV = ceil((RTT + J)/btarget), is a direct arithmetic consequence of the stated physical latency and jitter parameters, not a fit to a target outcome; the worked example (RTT = 44 min, J = 60 min, margin = 11 blocks) is just arithmetic. The arrived-before-expiry condition in §5.4 is a stated policy rule comparing a verified chain's terminal timestamp to Bitcoin MTP; the terminal timestamp is defined by the receipt chain itself, and the condition is not used to retroactively define the receipts. The verification rules (§5.2) and PoTT-M2 profile (§7) are presented as requirements the authors propose, not as results derived from hidden fitted inputs. I checked for self-citation load-bearing steps: the paper cites BIPs, BOLTs, RFCs, CCSDS, and prior systems (Sprites, time-dilation attacks, strong federations) as external standards or prior work, and none of these citations is from the present authors. The only potentially self-referential material is a limitation disclosure, which the paper states explicitly: if all relays collude and both time-beacon regimes are compromised, PoTT-M2 and PoTT degrade to administrative assertions rather than cryptographic time-anchoring. That is an honest threat-model limitation, not a circular reduction; it does not define PoTT's output in terms of its conclusions. The skeptical observation about suffix truncation (the terminal timestamp is not authenticated by an expected endpoint or hop count) is a security weakness of the proposed protocol, not an instance of circular reasoning: the paper does not claim that the chain's endpoint is authenticated, and the truncation issue does not arise because an output was fitted to an input or because a citation was used as proof. Since no parameter is fit to a target result, no load-bearing result is justified solely by a self-citation, and no equation reduces to its own input by construction, the appropriate finding is no significant circularity, score 0.

Assumptions & free parameters 10 free parameters · 8 assumptions · 1 invented entities

PoTT and the architecture rest on operator-chosen timing margins (J, σt, δ, ΔMTP, κ, Bbase, Mop, n, ε) and on domain assumptions about honest relays, signed time beacons, correct ephemerides, and Bitcoin's unchanged consensus. No parameters are fitted to data, and no circular dependence on the authors' prior results appears. The main heuristic, Observation 1, adds an ad hoc Poisson and stale-rate model that the paper itself calls not a formal proof.

free parameters (10)
  • J (jitter/contact allowance) = 60 minutes in worked example; (0, 30, 60) listed
    Operator-chosen jitter allowance enters Eq. (1) and the PoTT-M2 per-hop timing bound; no fitting to data.
  • sigma_t (time-source uncertainty) = ≤ 1 minute
    Chosen bound on clock and beacon skew; enters δ = J + 2σt; no empirical calibration shown.
  • δ (safety allowance) = J + 2σt by default
    Derived from chosen J and σt; used in the arrived-before-expiry inequality.
  • Δ_MTP (MTP-UTC policy bound) = 1 hour
    Chosen conservative bound; affects false accepts in time verification; not empirically fit.
  • κ (reorg margin) = 0-6 blocks
    Optional margin in the MTP check; chosen by the operator.
  • Bbase (operator base CLTV margin) = 144 blocks
    Earth policy example; enters the recommended Btotal.
  • Mop (operational margin) = 1-2 blocks
    Queueing and retry margin chosen by the operator; enters Btotal.
  • n (MTP drift estimation window) = 4032 blocks
    Chosen window for MTP drift; dispute bundles must include it.
  • ε (target stale fraction) = 0.05
    Chosen heuristic threshold; drives the 880-minute bound in the Observation 1 proof sketch.
  • M (validation/queueing margin in Observation 1) = unspecified, 'small relative to b'
    Unquantified margin in the stale-rate heuristic; not measured.
assumptions (8)
  • domain assumption Cryptographic primitives such as hashes and Schnorr signatures are unbroken.
    Stated in §7 security assumptions; PoTT guarantees depend on it.
  • domain assumption Signed time-beacons are available and within σt of true time, and at least one honest relay exists on each verified path.
    Assumption (PoTT-M2), §7; the paper concedes degradation to administrative assertions when both beacon regimes are compromised.
  • domain assumption Ephemerides and contact plans used for OWLT envelopes are correct and versioned.
    PoTT-M2 timing checks and Eq. (1) depend on the OWLT envelope from JPL/SPICE; see §7 and Table 2.
  • domain assumption Earth-Mars one-way light time ranges from 3 to 22 minutes over a synodic cycle.
    Input to Eq. (1) and the PoTT-M2 OWLT envelope; treated as a trusted external measurement.
  • domain assumption Bitcoin L1 consensus and scripting, including CLTV, CSV, and MTP per BIP-113, remain effective and unchanged.
    The architecture composes with existing BIPs and BOLTs; no modifications are proposed.
  • domain assumption DTN, BPv7, and BPSec provide store-and-forward, custody transfer, and bundle authentication as specified.
    Transport substrate for PoTT, cited in §3 and §4.
  • domain assumption MTP-UTC divergence is conservatively bounded by 1 hour.
    Used in the arrived-before-expiry check; the paper notes historic observations within tens of minutes but sets a policy bound.
  • ad hoc to paper Block arrivals are Poisson with rate 1/b and stale probability approximately D/b for D much less than b.
    Observation 1 proof sketch, §6; explicitly a heuristic, not a formal proof, and used to motivate keeping L1 parameters fixed.
invented entities (1)
  • Proof-of-Transit Timestamping (PoTT) receipt chain
    purpose: Cryptographically chained, hop-timed custody attestations bound to Bitcoin payload hashes, for dispute evidence and watchtower policy.
    A new protocol primitive defined in §5 and Appendix A; security and utility rest on the paper's analysis, with no external implementation or formal proof.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Bitcoin as an Interplanetary Monetary Standard with Proof-of-Transit Timestamping." pith.science (2026). https://pith.science/paper/NJC4YAOS

@misc{pith2026250820591,
  author       = {Pith},
  title        = {Pith review of: Bitcoin as an Interplanetary Monetary Standard with Proof-of-Transit Timestamping},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NJC4YAOS}},
  note         = {Machine review of arXiv:2508.20591}
}
read the original abstract

We explore the feasibility of deploying Bitcoin as the shared monetary standard between Earth and Mars, accounting for physical constraints of interplanetary communication. We introduce a novel primitive, Proof-of-Transit Timestamping (PoTT), to provide cryptographic, tamper-evident audit trails for Bitcoin data across high-latency, intermittently-connected links. Leveraging Delay/Disruption-Tolerant Networking (DTN) and optical low-Earth-orbit (LEO) mesh constellations, we propose an architecture for header-first replication, long-horizon Lightning channels with planetary watchtowers, and secure settlement through federated sidechains or blind-merge-mined (BMM) commit chains. We formalize PoTT, analyze its security model, and show how it measurably improves reliability and accountability without altering Bitcoin consensus or its monetary base. Near-term deployments favor strong federations for local settlement; longer-term, blind-merge-mined commit chains (if adopted) provide an alternative. The Earth L1 monetary base remains unchanged, while Mars can operate a pegged commit chain or strong federation with 1:1 pegged assets for local block production. For transparency, if both time-beacon regimes are simultaneously compromised, PoTT-M2 (and PoTT generally) reduces to administrative assertions rather than cryptographic time-anchoring.

Figures

Figures reproduced from arXiv: 2508.20591 by the authors.

Figure 1
Figure 1. Conceptual architecture for interplanetary Bitcoin using Proof-of-Transit Timestamping (PoTT). DTN deep-space link carries BPv7 bundles with PoTT receipts; each planetary domain runs its own Bitcoin/Lightning network; asynchronous settlement via federations or BMM sidechains [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Proof-of-Transit Timestamping (PoTT) detailed flow across a DTN deep-space path. Each relay appends a signed receipt and the concatenated receipts form a verifiable chain-of-custody used for Lightning dispute evidence and sidechain pegs. 3 [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Incremental Lightning CLTV margin due to interplanetary latency. For a given jitter allowance J, the additional blocks are ∆extra CLTV = l RTT+J btarget m , where RTT = 2 · OWLT and btarget is the L1 target block interval (Bitcoin: 10 minutes). Steps occur at RTT + J = k btarget and increase only when RTT + J > k btarget for k ∈ Z≥0; at equality the value remains k. Operators then add their base policy (e.g., 144 bl… view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Stack integration map. PoTT receipts are attached in transport metadata (out-of-band) at every relay; Bitcoin P2P carries headers, filters, compact blocks, and transactions. Lightning/watchtowers and settlement rails consume receipts; full-node validation remains uncha…

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 35 canonical work pages

  1. [1]

    Paul Sztorc, CryptAxe. BIP 300. Hashrate Escrows (Consensus layer). (2017). https: //github.com/bitcoin/bips/blob/master/bip-0300.mediawiki

    work page 2017

  2. [2]

    Blind Merged Mining (Consensus layer)

    Paul Sztorc, CryptAxe.BIP 301. Blind Merged Mining (Consensus layer). (2019). https: //github.com/bitcoin/bips/blob/master/bip-0301.mediawiki

    work page 2019

  3. [3]

    (Accessed: August 1, 2025)

    JPL Horizons / NAIF.JPL Horizons On-Line Ephemeris System; NAIF SPICE Toolkit. (Accessed: August 1, 2025). https://ssd.jpl.nasa.gov/horizons/; https://naif.jpl.nasa.gov/ naif/

    work page 2025

  4. [4]

    Nakamoto.Bitcoin: A Peer-to-Peer Electronic Cash System

    S. Nakamoto.Bitcoin: A Peer-to-Peer Electronic Cash System. (2008). https://bitcoin.org/ bitcoin.pdf

    work page 2008

  5. [5]

    Hypothetical Problems concerning the Theory of Relativity on Cryptographic Currency Implementations

    A. Ladha,Hypothetical Problems concerning the Theory of Relativity on Cryptographic Cur- rency Implementations, arXiv:1604.04265 [cs.CR], 2016. https://arxiv.org/abs/1604.04265

    work page Pith review arXiv 2016

  6. [6]

    Bradner.Key words for use in RFCs to Indicate Requirement Levels

    S. Bradner.Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119 (1997). https://www.rfc-editor.org/rfc/rfc2119

    work page 1997

  7. [7]

    Leiba.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

    B. Leiba.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. IETF RFC 8174 (2017). https://www.rfc-editor.org/rfc/rfc8174

    work page 2017

  8. [8]

    Burleigh et al.Bundle Protocol Version 7

    S. Burleigh et al.Bundle Protocol Version 7. IETF RFC 9171 (2022). https://www.rfc- editor.org/rfc/rfc9171

    work page 2022

Show all 38 references
  1. [9]

    Birrane III, K

    E. Birrane III, K. McKeever,Bundle Protocol Security (BPSec), IETF RFC 9172. (2022). https://www.rfc-editor.org/rfc/rfc9172

    2022

  2. [10]

    Delay/Disruption Tolerant Networking

    NASA. Delay/Disruption Tolerant Networking. (Accessed: August 1, 2025). https:// www.nasa.gov/communicating-with-missions/delay-disruption-tolerant-networking/

    2025

  3. [11]

    LunaNet Interoperability Specification (LNIS) - Version 5, Baseline

    NASA. LunaNet Interoperability Specification (LNIS) - Version 5, Baseline. (2025). https: //www.nasa.gov/wp-content/uploads/2025/02/lunanet-interoperability-specification-v5- baseline.pdf

    2025

  4. [12]

    (Accessed: August 1, 2025)

    European Space Agency.Moonlight. (Accessed: August 1, 2025). https://www.esa.int/ Applications/Connectivity_and_Secure_Communications/Moonlight. 17

    2025

  5. [13]

    Blockstream Satellite

    Blockstream. Blockstream Satellite. (Accessed: August 1, 2025). https://blockstream.com/ satellite/

    2025

  6. [14]

    Blockchain payloads on the ISS and commercial satellites

    SpaceChain. Blockchain payloads on the ISS and commercial satellites. (Accessed: August 1, 2025). https://spacechain.com/

    2025

  7. [15]

    Sprites and State Channels: Payment Networks that Go Faster than Lightning

    Andrew Miller, Iddo Bentov, Ranjit Kumaresan, Patrick McCorry. Sprites and State Channels: Payment Networks that Go Faster than Lightning. IACR Cryptology ePrint Archive 2017/1076 (2017). https://eprint.iacr.org/2017/1076

    2017

  8. [16]

    arXiv:2107.05322 (2021)

    Rene Pickhardt and Stefan Richter.Optimally Reliable & Cheap Payment Flows on the Lightning Network. arXiv:2107.05322 (2021). https://arxiv.org/abs/2107.05322

    2021 arXiv

  9. [17]

    arXiv:2006.01418 (2020)

    Antoine Riard and Gleb Naumenko.Time-Dilation Attacks on the Lightning Network. arXiv:2006.01418 (2020). https://arxiv.org/abs/2006.01418

    2020 arXiv

  10. [18]

    Peer Protocol for Channel Management.(ongoing).https://github .com/lightning/ bolts/blob/master/02-peer-protocol.md

    BOLT #2. Peer Protocol for Channel Management.(ongoing).https://github .com/lightning/ bolts/blob/master/02-peer-protocol.md

  11. [19]

    Bitcoin Transaction and Script Formats

    BOLT #3. Bitcoin Transaction and Script Formats. (ongoing). https://github.com/ lightning/bolts/blob/master/03-transactions.md

  12. [20]

    Onion Routing Protocol

    BOLT #4. Onion Routing Protocol. (ongoing). https://github.com/lightning/bolts/blob/ master/04-onion-routing.md

  13. [21]

    P2P Node and Channel Discovery

    BOLT #7. P2P Node and Channel Discovery. (ongoing). https://github.com/lightning/ bolts/blob/master/07-routing-gossip.md

  14. [22]

    Peter Todd. BIP 65. OP_CHECKLOCKTIMEVERIFY. (2014). https://github.com/ bitcoin/bips/blob/master/bip-0065.mediawiki

    2014

  15. [23]

    O’Connor, P

    R. O’Connor, P. Todd, and M. Friedenbach.BIP 68: Relative lock-time using consensus- enforced sequence numbers. (2015). https://github.com/bitcoin/bips/blob/master/bip- 0068.mediawiki

    2015

  16. [24]

    OP_CHECKSEQUENCEVERIFY

    BtcDrak, Mark Friedenbach, Eric Lombrozo.BIP 112. OP_CHECKSEQUENCEVERIFY. (2016). https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

    2016

  17. [25]

    Median time-past as endpoint for lock-time calculations

    Thomas Kerin, Mark Friedenbach.BIP 113. Median time-past as endpoint for lock-time calculations. (2015). https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki

    2015

  18. [26]

    Compact Block Relay

    Matt Corallo.BIP 152. Compact Block Relay. (2016). https://github.com/bitcoin/bips/ blob/master/bip-0152.mediawiki

    2016

  19. [27]

    Client Side Block Filtering

    Olaoluwa Osuntokun, Alex Akselrod, Jim Posen.BIP 157. Client Side Block Filtering. (2017). https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki

    2017

  20. [28]

    Compact Block Filters for Light Clients

    Olaoluwa Osuntokun, Alex Akselrod.BIP 158. Compact Block Filters for Light Clients. (2017). https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki

    2017

  21. [29]

    Version 2 P2P En- crypted Transport Protocol

    Dhruv Mehta, Tim Ruffing, Jonas Schnelli, Pieter Wuille.BIP 324. Version 2 P2P En- crypted Transport Protocol. (2019). https://github.com/bitcoin/bips/blob/master/bip- 0324.mediawiki

    2019

  22. [30]

    Schnorr Signatures for secp256k1

    Pieter Wuille, Jonas Nick, Tim Ruffing.BIP 340. Schnorr Signatures for secp256k1. (2020). https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki. 18

    2020

  23. [31]

    Krugman.The Theory of Interstellar Trade

    Paul R. Krugman.The Theory of Interstellar Trade. Economic Inquiry 48(4), 1119–1123 (2010). https://doi.org/10.1111/j.1465-7295.2010.00269.x

    2010

  24. [32]

    Business | Aviation

    Starlink. Business | Aviation. (Accessed: August 1, 2025). https://www.starlink.com/ business/aviation

    2025

  25. [33]

    Starshield

    SpaceX. Starshield. (Accessed: August 1, 2025). https://www.spacex.com/starshield

    2025

  26. [34]

    Deep Space Optical Communications (DSOC) Mission Updates

    NASA/JPL. Deep Space Optical Communications (DSOC) Mission Updates. (2023-2024). (Accessed: August 1, 2025). https://www .jpl.nasa.gov/missions/deep-space-optical- communications-dsoc/

    2023

  27. [35]

    Bormann and P

    C. Bormann and P. Hoffman.Concise Binary Object Representation (CBOR). IETF RFC 8949 (2020). https://www.rfc-editor.org/rfc/rfc8949

    2020

  28. [36]

    (Accessed: August 1, 2025)

    International Earth Rotation and Reference Systems Service (IERS).Bulletin C (Leap Second Announcements). (Accessed: August 1, 2025). https://www.iers.org/IERS/EN/ Publications/Bulletins/bulletins.html

    2025

  29. [37]

    Dilley et al.Strong Federations: An Interoperable Blockchain Solution to Centralized Third-Party Risks

    J. Dilley et al.Strong Federations: An Interoperable Blockchain Solution to Centralized Third-Party Risks. arXiv:1612.05491 (2016). https://arxiv.org/abs/1612.05491

    2016 arXiv

  30. [38]

    Time Code Formats and Interoperability

    Consultative Committee for Space Data Systems (CCSDS). Time Code Formats and Interoperability. CCSDS 301.0-B-4, Blue Book (2010). https://public.ccsds.org/Pubs/ 301x0b4e1.pdf. 19

    2010

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.