[Cryptography] [RFC] Montana Protocol 2.0: Chronological Sealing, Metadata Unlinkability and Time-Invariant Signaling

Wed Oct 21 10:07:37 EDT 2026

Oct 10, 2026 at 16:42 by kaitozero at proton.me:

>
>
> Hi, Alejandro
>
> I read the specification after your post to the Cryptography list. Two things
> on the liveness question you asked for reading on, and then one request.
>
> I operate validators on a different chain with quorum finality, and the failure
> we actually hit there was not a partition. It was a quorum that was nominally
> present and functionally stuck: every validator reachable, answering, and
> signing heartbeats, while the frontier simply stopped advancing. That chain does
> have a commit phase timeout and a round change path, and it stalled anyway,
> which is why I do not think the timeout is the interesting variable. The
> interesting variable is that nothing in consensus state distinguished "waiting
> legitimately for cement" from "waiting forever on a bug". From inside the
> protocol a healthy wait and a permanent stall are identical.
>
> So no node could locally conclude it was in trouble. "A network that cannot
> reach the quorum waits rather than forking" is the right choice for safety, but
> it also makes a liveness failure unobservable from inside consensus. We found
> ours by comparing our own frontier against another operator's out of band, and
> that took weeks.
>
> I would therefore not measure the cost of no-timeout finality in liveness. I
> would measure it in time to detect, which suggests something cheap: export the
> cemented head together with the accumulated cement still short of the quorum
> share, as observable state, so an operator can tell "short of quorum since
> window N" from "advancing normally". That is monitoring rather than consensus
> and costs safety nothing, but it is the difference between an hour and a month.
>
> The second is narrower and comes from Canon rather than from experience. Entry
> is gated on lived continuity: segment_bitmap over continuity_segments = 14 of
> segment_windows = 1440, continuity_required 2 of 3, continuity_period = tau_2 =
> 20160 windows. Canon is explicit that the bitmap is read only after shifting it
> by the distance from last_active_segment to the current segment.
>
> Under that rule a whole-network stall looks harmless, since windows stop and the
> current segment stops with them. A minority partition does not. The majority
> keeps advancing windows while a part holding less than the quorum share carries
> nothing. On rejoin the minority replays the cements it missed, but the current
> segment has moved a long way, so the shift moves its lived segments out of the
> period.
>
> Does the replay of missed cements restore lived segments, or does only live
> participation at the time a window closed count? Canon fixes the shift
> precisely and I could not find where it answers this. If it is the latter, one
> partition event erases an honest candidate's entry progress, it re-accrues over
> up to 20160 windows, and the cost of no-timeout finality lands mostly on
> candidates on the minority side.
>
> Now the request. I would rather run a node against the live cohort than only
> read about it, and I have tried before: I still have a data directory from an
> earlier generation whose account table holds the moscow account_id from the
> manifest, so the genesis state loads correctly. But
> Code/scripts/genesis-manifest.json carries real peer_id, account_id_hex and
> node_id_hex values while its multiaddrs are <front>, <exit-de> and <exit-am>,
> and QUICKSTART confirms these are placeholder tokens rather than routable
> endpoints. Without dialable addresses the container reaches singleton consensus
> on its own private genesis, which exercises the code but not the network.
>
> Is there a manifest with real addresses you are willing to share, or a cohort
> currently accepting candidates? I have a machine on a static public IP that
> runs continuously and can keep a dedicated core on it.
>
>
>> Kaito
>>
>
>
>
Hello Cryptography Community,

Production-level federated and peer-to-peer messaging layers remain susceptible to end-to-end traffic correlation and timing analysis executed by global passive adversaries (GPA). Onion-routing topologies that fail to implement strict time-domain obfuscation inevitably leak the underlying communication graph through packet-burst intervals and relay synchronization logging.
We are presenting the Montana Protocol 2.0, an open-source transport-layer and chronological sealing framework engineered to achieve total metadata and relation unlinkability. This architecture treats cryptographic state transitions not as unverified ledger entries, but as immutable components of a sovereign time-bound chain.

Core Technical Specifications:
1. Constant-Rate Padding (CRP) & Bandwidth Optimization
To eliminate data-length fingerprinting, the transport layer standardizes all outbound control and signaling envelopes to a static block size of S = 4096 bytes using a cryptographically secure pseudo-random number generator (CSPRNG). Outbound transmission queues operate on an adaptive interval schedule (Delta t) to minimize mobile overhead:
• High-Anonymity Mode: Delta t = 1.0s, resulting in a predictable transport footprint of ~4.0 KB/s (~32 Kbps) and a saturation bound of ~345.6 MB/day.
• Mobile-Standby Mode: Delta t = 5.0s, dropping baseline bandwidth utilization to ~0.8 KB/s (~6.4 Kbps) and ~69.1 MB/day.
When the transmission queues are idle, the transport core generates indistinguishable dummy (chaff) frames. Heavy payload transfers isolate dynamically into high-throughput randomized window segments to isolate control line traffic signatures.

2. Time Asymmetry and the TimeChain Invariant ($TCM)
Montana Protocol 2.0 discards parallelizable, energy-intensive Proof-of-Work parameters. Computational scarcity is strictly modeled around sequential elapsed time. Token emission (MINT, denoted under ticker $TCM) is structurally bound to the continuous, non-parallelizable chronological existence of an ephemeral key pair in the time domain:
Y = X^(2^t) (mod N)
Where N represents an RSA composite (N = p * q) with eradicated prime factors, X is the deterministic SHA-256 hash of the preceding chain block paired with the node's ephemeral identity, and t defines the difficulty variable calibrated to sequential execution speeds. Since squaring is strictly non-parallelizable, hardware acceleration matrices (ASIC/GPU clusters) cannot forge or simulate the passage of human time. Validation occurs efficiently at O(1).

3. Unidirectional Zero-Knowledge Queues
The protocol decouples the identity of adjacent routing peers. Token propagation relies on single-use ephemeral tokens that mutate deterministically at each routing hop. Relay nodes retain zero historical or contextual knowledge regarding target queues or active vs. idle state distribution signatures.

Architectural Transparency and Open Vulnerabilities:
The protocol is hosted as a pure academic artifact. The repository tracks 13 security criteria (including node isolation, ledger finalization, and absolute user anonymity), currently recorded in a 0/13 verified state.
We explicitly state a critical structural vulnerability: the current iteration operates over a non-ratcheted conversation secret. While the transport layer provides post-quantum forward secrecy via hybrid ML-KEM-768 handshakes, physical compromise of a static node secret exposes historical backlogs. We invite cryptanalytic feedback and proposals regarding pluggable post-quantum ratcheting mechanisms implemented over a constant-rate transport pipeline.

APPENDIX: Real-Time Chronological Chain Dump (TimeChain Sample)

Below is an verified text dump extracted from the active node consensus logs, proving the non-invertible chronological sealing mechanism where each record hash encapsulates the preceding state:
• 485 · 17.10.2026 01:56:45 MSK · hash cf379e74d1c5bfddc683a4e9695682db5726a66052cb89602c59523b41f97ee2 · prev 54b9501f4ea4ea86ca8b21cb8b8b35984260fc4e443342a7f12d9226be44abb1 · Master 78 · Fable 5.1 · TCM contracts done.
• 484 · 17.10.2026 01:15:14 MSK · hash 54b9501f4ea4ea86ca8b21cb8b8b35984260fc4e443342a7f12d9226be44abb1 · prev f124ea991b1be106df4fa36c9f3a834cde7d48e847a7003e33484e3eb201d783 · Master 78 · Fable 5.1 · Main rollback root fixes.
• 3637 · 21.10.2026 02:27:08 MSK · hash 732918d4c6dedd369131f406123be0034e12331f9f7883d1aa5c2cce5b337e8a · prev f34b942b5ec7fa8fb6b5315446e1de0dadfc867eb0adf22dc266b618aa935777 · Agent 166 · Shift transfer logic.
• 3636 · 21.10.2026 02:27:02 MSK · hash f34b942b5ec7fa8fb6b5315446e1de0dadfc867eb0adf22dc266b618aa935777 · prev bb92e86e26cbc4db27b7bd038e0f651bb7a726412fd8fe8a6d4d10da8e10ce9b · Agent 167 · Wire card primitives.
The full source files and core design guidelines are open for evaluation at:
https://github.com/efir369999/montana_messenger

We welcome your cryptanalytic feedback and technical review of these transport queue mechanics.

—
Alejandro

«You can’t parallelize your way out of time.»
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20261021/7877b6e8/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_3577.png
Type: image/png
Size: 194749 bytes
Desc: not available
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20261021/7877b6e8/attachment-0001.png>