montana/Монтана-Протокол/Код/VERSION.md

# Version

**Implementation:** `0.0.0` (M0..M5 closed; M1-F production audit-ready 7/7 findings + 5/5 audit package findings closed; M2 audit-ready 60 determinism invariants; M3-M5 internal-tested не аудированы внешне; M6+ TODO)
**Spec target:** Montana Protocol v35.25.0 + Montana Network v1.0.0 + Montana App v3.12.0 (2026-05-02)
**Spec paths:**
- Protocol: `../Montana Protocol v35.25.0.md`
- Network:  `../Montana Network v1.0.0.md`
- App:      `../Montana App v3.12.0.md`

## Policy

**Single source of truth для версии спеки — этот файл.** Код ссылается на спеку без версии (`// spec, раздел "<name>"`) — версия всегда текущая из `Spec target:` выше.

- Consensus-critical решения в коде помечаются комментарием `// spec, раздел "<name>"`. Версия не дублируется.
- При spec bump (e.g. v29.6.8 → v29.7.0):
  1. Обновить этот файл: `Spec target:` + `Spec path:` + новая запись в History.
  2. Переименовать файл спеки (правило `feedback_spec_rename.md`).
  3. Если раздел в спеке был **переименован или удалён** — пройти по коду (`rg "spec, раздел"`), обновить конкретные ссылки. Если все разделы не затронуты — spec-комментарии в коде **не трогать**.
  4. Один commit: `chore: spec bump vX → vY` с описанием что изменилось.
- Breaking spec changes до mainnet применяются немедленно (см. `CLAUDE.md` → Pre-mainnet).

## History

| Impl version | Spec version | Date       | Notes                                                                                 |
|--------------|--------------|------------|---------------------------------------------------------------------------------------|
| 0.0.0        | v35.23.0     | 2026-05-02 | **Patch release: spec bump v35.22.0 → v35.23.0 — KAT B1/B3 hex regenerated после rename mt-tunnel → mt-tunnel-online (closure P-C2 spec sync).** Reference implementation mt-net::ibt + mt-net::pow (commit 93b9cdc) regenerated B1 (sha256(proof) ac26a9ca... ↔ ранее 94e3cde0...) и B3 (target 2^240 unchanged, found_nonce 48 949 vs ранее 165 516, found_hash 0000cb8b... vs ранее 0000d31c...). B2 не затронут (mesh domain не переименован). Status conformance closed для B1+B3 group. **No protocol semantic change** — KAT placeholder TBD-A → real hex после rename. Spec file renamed Montana v35.22.0.md → Montana v35.24.0.md. |
| 0.0.0        | v35.22.0     | 2026-05-02 | **Polish release: spec bump v35.21.0 → v35.22.0 — закрытие 5 spec findings + 1 cross-cutting (P-S1..P-S5 + P-C2 spec part) от critic-mode audit Phase G+B+A.** Pre-mainnet breaking change Genesis State Hash через layout restructure protocol_params. **P-S1+P-S2 (БЛОКЕР DoS):** добавлены `max_protocol_payload_bytes: u32 = 1 048 576` (1 MiB) и `max_sf_ciphertext_bytes: u32 = 65 536` (64 KiB) в Genesis Decree consensus-binding wire-format upper bounds; backpressure rule B5 enforce reject до allocation. **P-S3 (БЛОКЕР scope violation):** удалены 4 локальных policy поля из Genesis Decree (`max_outbound_per_node`, `max_inbound_per_node`, `max_pending_requests_per_peer`, `request_timeout_t1_div`) — переведены в operator-configurable defaults в sub-section «Сетевые параметры в protocol_params» (header `Default (operator-configurable, не Genesis Decree)` вместо `Константа`). Backpressure rules продолжают reference их по имени, но без consensus binding. Genesis Decree теперь содержит только 3 consensus-binding network параметра (bootstrap_pow_difficulty + 2 wire-format bounds). **P-S4 (drift):** Bootstrap PoW carcard derivation добавлен «authoritative SSOT в Указе Генезиса per [I-10]» pointer; KAT vector B3/F1 input scheme переход на `bootstrap_pow_difficulty` field name reference вместо magic 65 536. **P-S5 (косметика):** KAT E1/E2 ttl_window inputs получили `(test τ₁ = 60; реальный τ₁ — emergent от D₀ per [I-18])` qualifier. **P-C2 spec part (prefix collision fix):** rename domain separator `mt-tunnel` → `mt-tunnel-online` (prefix-free от `mt-tunnel-mesh` per Pass 14 critic check); затронуты Domain separators registry, IBT online proof carcard, KAT B1 input scheme + replay surface analysis. **Что НЕ закрывает (open для code-side polish):** P-C1 (domain registry → mt-codec), P-C2 code part (sync rename), P-C3 (fuzz harnesses), P-C4/P-C5 (unwrap/expect refactor), P-C6 (misuse-resistance try_new), P-C7 (Bye forward-compat), P-C8 (ibt_mesh_verify O(1)). KAT B1/B3 hex теперь TBD-A pending Phase B.0 reference impl regeneration. **No code recompile required для spec edit alone** — но Genesis State Hash recalc + IBT online sign domain change в Phase B.0 sync. Spec file renamed Montana v35.21.0.md → Montana v35.22.0.md. |
| 0.0.0        | v35.21.0     | 2026-05-02 | **Patch release: spec bump v35.20.0 → v35.21.0 — Phase G.1 sync KAT vectors D1/D2/D3 + E1/E2 с real hex от reference impl mt-net Phase G.** Заменены TBD-A markers для MeshFrame + Store-and-Forward envelope: D1 single-fragment broadcast (235 B header+payload, byte-exact full hex); D2 multi-fragment encrypted unicast 3 frames (sha256 each); D3 max-size single fragment with deterministic padding (1024 B, sha256 byte-exact); E1 typical SF envelope (3603 B, sha256 + sender signature sha256); E2 max-TTL larger fragment (4371 B, sha256 + sender signature sha256). Все 5 vectors сгенерированы reference implementation `mt-net::{encode_mesh_frame, encode_sf_envelope}` + ML-DSA-65 sign через mt-crypto. **Что закрывает:** [I-9] integer-form requirement closed для MeshFrame wire format + SF envelope; cross-implementation conformance возможна byte-exact. **Что НЕ закрывает (open):** 12 TBD-A markers remaining — group C-0x01..0x22 consensus objects (delegate to existing mt-* crates encode functions), C-0x60/0x61/0x64 application-layer (BatchLookupRequest/Response, RangeSubscribeResponse — отдельный application scope). **No protocol semantic change.** Spec file renamed Montana v35.20.0.md → Montana v35.21.0.md. |
| 0.0.0        | v35.20.0     | 2026-05-01 | **Patch release: spec bump v35.19.0 → v35.20.0 — Phase B.1 sync KAT vectors B1/B2/B3 + F1/F2 с real hex от reference impl mt-net Phase B.** Заменены TBD-A markers для IBT proofs + Bootstrap PoW + target derivation: B1 IBT online proof — seed (32 B SHA-256-derived), sha256(pk), sha256(proof signature 3309 B); B2 IBT mesh proof — sha256(proof); B3 Bootstrap PoW combination для difficulty=2^16=65 536 — target hex (`00 01 00 00 ...` × 30 B = 2^240), found_nonce=165 516, found_hash hex (`00 00 d3 1c ...`); F1 target derivation для difficulty=2^16 (byte-exact same как B3 target); F2 target derivation для difficulty=2^10=1 024 (`00 40 00 00 ...` × 30 B = 2^246). Также spec input scheme обновлён: SHAKE256(label, 64) → SHA-256("mt-test-seed" || label) для соответствия reference implementation (mt-crypto API использует 32-byte seed для ML-DSA-65 KeyGen ξ ∈ B32, FIPS 204 §3.1; SHAKE256 не требуется). **Что закрывает:** [I-9] integer-form requirement closed для IBT online + mesh proofs + Bootstrap PoW target derivation; cross-implementation conformance возможна byte-exact. **Что НЕ закрывает (open):** 17 TBD-A markers remaining — group C-0x01..0x22 consensus objects (delegated to existing mt-* crates), C-0x60/0x61/0x64 application layer (BatchLookupRequest/Response, RangeSubscribeResponse), group D MeshFrame (Phase G), group E SF envelope (Phase G). **No protocol semantic change** — только KAT placeholder → real hex + seed derivation method clarification. Spec file renamed Montana v35.19.0.md → Montana v35.20.0.md. |
| 0.0.0        | v35.19.0     | 2026-05-01 | **Patch release: spec bump v35.18.0 → v35.19.0 — Phase A.3 sync 9 KAT vectors C-0x* с real hex от reference impl mt-net Phase A.2.** Заменены TBD-A markers для structured payloads: C-0x40 FastSyncRequest (16 B), C-0x41 FastSyncResponseChunk (77 B), C-0x42 FastSyncError (34 B), C-0x50 PeerListRequest (2 B), C-0x51 PeerListResponse 3 entries (179 B), C-0x62 BatchLookupError (2 B), C-0x63 RangeSubscribeRequest 4 labels (130 B), C-0x65 RangeSubscribeError (1 B), C-0xFF Bye normal_shutdown (1 B). Все 9 verified в `mt-net::tests::test_vectors::vector_c_0x*` (PASS, 9/9). **Что закрывает:** [I-9] integer-form requirement closed для 9 message types; cross-implementation conformance возможна byte-exact. **Что НЕ закрывает (open):** 27 TBD-A markers remaining — group B (IBT proofs, требует ML-DSA-65 в Phase B), group C-0x60/0x61/0x64 (BatchLookupRequest/Response, RangeSubscribeResponse — application layer scope), group C-0x01..0x22 (consensus objects — encode delegated to existing mt-* crates), group D (MeshFrame — Phase G), group E (SF envelope — Phase G), group F (Bootstrap PoW — Phase B). **No protocol semantic change.** Spec file renamed Montana v35.18.0.md → Montana v35.19.0.md. |
| 0.0.0        | v35.18.0     | 2026-05-01 | **Patch release: spec bump v35.17.0 → v35.18.0 — Phase A.1 sync TBD-A: A1/A2/A3 envelope vectors с реальными hex от reference implementation.** mt-net::wire::envelope reference implementation (commit 9de287b crate `mt-net`) сгенерировала byte-exact hex для трёх Vector A: (A1) Ping empty payload — `f0 01 00 00 00 00 00 00 00 00 00 00 00 00` (14 B header only); (A2) typical Transfer 1024 B payload, request_id=42 — header `01 01 2a 00 00 00 00 00 00 00 00 04 00 00` + 1024 B byte_repeat(0xAB) = 1038 B total; (A3) FastSyncResponse header-only max request_id=u64::MAX — `41 01 ff ff ff ff ff ff ff ff 00 00 00 00`. Все три vectors verified в integration tests `crates/mt-net/tests/test_vectors.rs::vector_a1/a2/a3` (PASS). Status «conformance pending → closed» для envelope group A. **Что закрывает:** [I-9] integer-form requirement для ProtocolMessage envelope wire format — теперь cross-implementation conformance possible byte-exact. **Что НЕ закрывает (open):** TBD-A markers для groups B (IBT proofs), C (per-msg-type 21 vectors), D (MeshFrame), E (Store-and-Forward), F (Bootstrap PoW target) — заполнятся параллельно Phase A.2/A.3, Phase B, Phase G кода. Текущий remaining count: 36 TBD-A markers. **No protocol semantic change** — только KAT placeholder → real hex. Spec file renamed Montana v35.17.0.md → Montana v35.18.0.md. |
| 0.0.0        | v35.17.0     | 2026-05-01 | **Minor release: spec bump v35.16.0 → v35.17.0 — Final Gate audit сетевого слоя M6 (закрытие II.7 и всего раздела II плана сетевого слоя M6).** Добавлен sub-section «Final Gate audit сетевого слоя M6» в раздел «Карточки замыкания механизмов сетевого слоя» (после apply_* formulations). Audit отчёт: Gate 0.5(d.1) formula coverage Pass; Gate 0.5(d.2) field coverage Pass для пяти новых полей protocol_params (bootstrap_pow_difficulty / max_outbound_per_node / max_inbound_per_node / max_pending_requests_per_peer / request_timeout_t1_div) — все references explicit на Genesis Decree authoritative location, zero value duplications; Gate 15 Part 1B generic version sweep — zero spec-version mentions in body (legitimate hits: header line 3, QEMU v4.2.0/v8.2.0 external software, Rust 1.92.0/sha2 v0.10.9/macOS Sequoia 15.7.3/Darwin 24.6.0 в [I-18] D₀ derivation, ip_version=0x04 field в KAT vectors); cross-section consistency Pass через reading-based verify; Gate 13a invariant enumeration Pass для всех 12 carcards + 4 Storage Cards + 50 KAT vectors + Threat Model + Genesis Decree extension + apply_* formulations; Gate 0 global invariant check Pass — 15-pass на каждую карточку, zero violations. **Что закрывает:** Phase A разблокирована — implementer mt-net::* крейтов имеет полный normative reference (12 carcards + 4 Storage Cards + 50 KAT vectors + Threat Model + 5 Genesis Decree fields + 6 backpressure rules + 2 apply_* функции). План раздела II — закрыт. Network layer спека audit-ready для Phase A start. **Что НЕ закрывает (открытые items идут в Phase A reference impl):** TBD-A полей в KAT vectors заполняются параллельным spec patch при Phase A reference impl execution; expanded vectors set до 50 (текущие 34 stub + 16 boundary/edge в Phase A iteration). **No code recompile required** — только audit report + version bump. Spec file renamed Montana v35.16.0.md → Montana v35.17.0.md. |
| 0.0.0        | v35.16.0     | 2026-05-01 | **Minor release: spec bump v35.15.0 → v35.16.0 — apply_mesh_frame и apply_store_and_forward нормативные формулировки (закрытие II.6 плана сетевого слоя M6).** Добавлен sub-section «apply_mesh_frame и apply_store_and_forward — нормативные формулировки» в раздел «Карточки замыкания механизмов сетевого слоя» (после backpressure rules). Две функции с полной семантикой: input/output типы; ordered deterministic steps; идемпотентность guarantees. (1) `apply_mesh_frame(frame, sender_pubkey, peer_local_state) → MeshIntake` — 6 ordered steps: structure validation per Gate 13a → IBT mesh proof verification per карточка → frame intake rate per Backpressure B2 → recipient determination → fragment assembly → used_nonces update; idempotency через nonce dedup. (2) `apply_store_and_forward(envelope, sender_pubkey, sf_local_state) → SFIntake` — 7 ordered steps: structure validation → sender ML-DSA-65 signature verify → per-sender quota → recipient ack revocation check → total buffer quota (Storage Card sf_buffer 1 GB) → recipient determination (ML-KEM decrypt либо buffer для forwarding) → forwarding policy. Семантика apply_* симметрична consensus apply (не входят в state_root но deterministic + idempotent + ordered) для implementation pattern consistency и [C-7] enforcement (no shortcut на apply функциях). **Что закрывает:** реализатор Phase G (mt-net::mesh, mt-net::store_forward) имеет normative reference для two largest non-consensus apply functions; cross-impl conformance condition (две реализации на тот же frame дают same MeshIntake / SFIntake outcome); Gate 13a invariants для MeshFrame и SFEnvelope structures explicit. **Что НЕ закрывает (open):** Final Gate 0.5(d) + Gate 15 audit (II.7). **No code recompile required.** Spec file renamed Montana v35.15.0.md → Montana v35.16.0.md. |
| 0.0.0        | v35.15.0     | 2026-05-01 | **Minor release: spec bump v35.14.0 → v35.15.0 — Backpressure + connection limits в protocol_params (закрытие II.5 плана сетевого слоя M6).** Pre-mainnet breaking change Genesis State Hash через extension protocol_params layout +9 байт (acceptable per Pre-mainnet принцип). **Genesis Decree extension** (authoritative): добавлены пять полей после `pruning_idle_windows` и до `bootstrap_account_pubkey` — `bootstrap_pow_difficulty: u32 = 65 536` (2^16, anti-flood target ≈100мс CPU per попытка на genesis-железе); `max_outbound_per_node: u8 = 24` (eclipse resistance, P(eclipse)≈3×10⁻¹³ при f=0.3); `max_inbound_per_node: u8 = 13` (bandwidth budget 13 KB/сек ≈33 GB/мес); `max_pending_requests_per_peer: u16 = 256` (backpressure correlation table, ≈8.5 req/сек per peer); `request_timeout_t1_div: u8 = 2` (TTL = τ₁/2). Genesis Decree invariants расширены явным enumeration новых пяти полей с byte-exact values. **Новый sub-section «Сетевые параметры в protocol_params»** (после Threat Model): derivation per «Академическое обоснование констант» с полями (Class/Target/References/Derivation/Sensitivity/Defense) для каждой константы — Hashcash/Bitcoin/Bitcoin core/Ethereum geth/libp2p kademlia/HTTP-2 SETTINGS_MAX_CONCURRENT_STREAMS/RFC 7540 references; SSOT через Genesis Decree authoritative location, sub-section НЕ дублирует layout. **Backpressure rules B1-B6** нормативный текст: B1 pending requests cap, B2 frame intake rate per peer, B3 total connection cap (outbound — Error::OutboundCapReached; inbound — TCP RST), B4 penalty escalation (threshold 100 events per τ₁ → reason 0x04 + blacklist 24·τ₁), B5 resource quota enforcement timing (10-step ordered protection chain), B6 sabotage actor protection scope (volumetric DDoS out-of-scope, per-peer behaviour in scope). **Что закрывает:** Bootstrap PoW open sub-finding из карточки IBT triumvirate (`bootstrap_pow_difficulty` теперь Genesis Decree); ProtocolMessage envelope open sub-finding (backpressure constants теперь Genesis Decree); все open carcards могут pivot status «закрыто с открытым sub-finding» → «закрыто» в Final Gate audit (II.7). **Что НЕ закрывает (open):** apply_mesh_frame / apply_store_and_forward formulations (II.6); Final Gate audit (II.7). **No code recompile required для spec edit** — но Genesis State Hash recalc в Phase A. Spec file renamed Montana v35.14.0.md → Montana v35.15.0.md. |
| 0.0.0        | v35.14.0     | 2026-05-01 | **Minor release: spec bump v35.13.0 → v35.14.0 — Threat Model сетевого слоя (закрытие II.4 плана сетевого слоя M6).** Добавлен sub-раздел «Сетевой уровень — Threat Model» в раздел «Карточки замыкания механизмов сетевого слоя». Структура: (a) 7 adversary classes — Passive observer, Active MITM, Eclipse, Sybil, DoS, Censor, State-level sabotage — с possibilities + budget оценкой; (b) 4 защищённых свойства — confidentiality (data + metadata), integrity (data + consensus), availability (узла + consensus), unlinkability; (c) coverage matrix 7×7=49 intersections (некоторые n/a) — 13 закрыто конструкцией C, 7 partial P с acknowledged residuals, 0 out-of-scope O; (d) 7 explicit out-of-scope угроз с обоснованием (endpoint compromise, traffic analysis на global scale, side-channel, quantum store-now-decrypt-later на TLS, supply chain, mesh physical proximity, regulatory pressure на bootstrap); (e) 7 acknowledged residuals (P cells) с severity + mitigation roadmap (TLS 1.3 ECH когда rustls support, mesh range deferred M14, Tor bridges deferred M6.5/M14); (f) compliance с глобальными инвариантами [I-1]/[I-3]/[I-7]; (g) audit guidance — matrix как entry point для внешнего аудитора. **Что закрывает:** Gate 11 (threat concentration) для всех сетевых механизмов теперь имеет normative reference; внешний security audit получает структурированную поверхность вместо разбросанных утверждений; реализатор оценивает достаточность защиты per (adversary class × property) intersection. **Что НЕ закрывает (open):** backpressure/connection limits в protocol_params (II.5); apply_mesh_frame / apply_store_and_forward formulations (II.6); Final Gate 0.5(d) + Gate 15 audit (II.7). **No code recompile required.** Spec file renamed Montana v35.13.0.md → Montana v35.14.0.md. |
| 0.0.0        | v35.13.0     | 2026-05-01 | **Minor release: spec bump v35.12.0 → v35.13.0 — Binding KAT vectors сетевого слоя stub set (закрытие II.3 плана сетевого слоя M6).** Добавлен sub-раздел «Binding KAT vectors сетевого слоя» в раздел «Карточки замыкания механизмов сетевого слоя». Каждый вектор фиксирует пару (canonical input, expected byte-exact output) для cross-implementation conformance per [I-9]. Inputs полностью integer-specified в спеке; expected outputs (`TBD-A: <vector_id>`) генерируются reference implementation в Phase A плана M6 (`mt-net::wire`) и заполняются параллельным spec patch. **34 vector definitions** (с расширением до 50 в Phase A iteration через boundary/edge vectors): A. ProtocolMessage envelope (3) — empty/typical/max-boundary; B. IBT proofs (3) — online + mesh + bootstrap PoW combination; C. Per-msg-type encode/decode (21) — все 18 кодов реестра + Ping/Pong/Bye explicit; D. MeshFrame wire format (3) — single-fragment broadcast, multi-fragment encrypted unicast, max-size single fragment с padding; E. Store-and-Forward envelope (2) — typical small + boundary max-TTL large; F. Bootstrap PoW target derivation (2) — difficulty_factor 2^16 + 2^10. Все inputs detailed: точные byte sequences (byte_repeat паттерны, SHAKE256-derived deterministic seeds, hex constants); reference impl в Phase A воспроизводит byte-exact и заполняет TBD-A полю. **Что закрывает:** [I-9] integer-form requirement для wire format всех 18 message-types + IBT proofs + MeshFrame + SF envelope + Bootstrap PoW; status «conformance pending → closed Phase A» после генерации expected hex. Implementer mt-net::wire / mt-net::ibt в Phase A имеет полный normative reference для test fixtures и cross-implementation conformance. **Что НЕ закрывает (open):** Threat Model (II.4); backpressure/connection limits в protocol_params (II.5); apply_mesh_frame / apply_store_and_forward formulations (II.6); Final Gate audit (II.7). **No code recompile required** — vectors содержат stubs (TBD-A markers); реальные expected hex заполнятся отдельным parallel commit при Phase A reference impl. Spec file renamed Montana v35.12.0.md → Montana v35.13.0.md. |
| 0.0.0        | v35.12.0     | 2026-05-01 | **Minor release: spec bump v35.11.0 → v35.12.0 — Storage Cards для локальных сетевых таблиц (закрытие II.2 плана сетевого слоя M6).** Добавлен sub-раздел «Локальные сетевые таблицы — Storage Cards» в раздел «Карточки замыкания механизмов сетевого слоя». Четыре Storage Cards adapted для local-state контекста (cost-based фрагменты `n/a` per [I-15] денежного отказа): (1) PeerRecord table — ≈ 2096 B/record × 8192 records hard quota ≈ 18 MB; путь 2+3 (temporal LRU + hard cap); sabotage budget 2 часа sustained flood для diversity disruption, не denial of service. (2) used_nonces (mesh IBT replay) — ≈ 80 B/nonce; soft cap 1 MB + hard cap 4 MB; путь 2+3 (TTL 7·τ₁ + per-sender quota 64 nonces per 7·τ₁); sabotage 23 часа sustained для soft cap, 92 часа для hard cap. (3) sf_buffer (Store-and-Forward) — ≈ 3500 B/record avg; hard cap 1 GB operator-configurable; путь 2+3+3 (temporal TTL + per-sender quota 256 frames per τ₁ + total hard quota); защита через diversity на connection layer + signed rate-limit acks. (4) bootstrap recent_nonces + peer_penalty — ≈ 80-100 B/record; total ≤ 200 KB sustained; путь 2 (TTL τ₁ для PoW nonces, τ₁..24·τ₁ для penalty); rate-limit через PoW cost ≈ 100 мс CPU. Все четыре карточки [I-14] compliance status: закрыто. **Что закрывает:** оператор узла теперь имеет explicit disk usage requirements для node-runtime (≈ 1 GB SF buffer + 18 MB peers + 4 MB nonces + 0.2 MB penalties = ≈ 1.022 GB hard cap по умолчанию); реализатор не реализует unbounded local growth — каждая таблица имеет integer-specified hard quota. **Что НЕ закрывает (open):** ~50 binding KAT vectors (II.3); Threat Model (II.4); backpressure/connection limits в protocol_params (II.5); apply_mesh_frame / apply_store_and_forward formulations (II.6); Final Gate audit (II.7). **No code recompile required.** Spec file renamed Montana v35.11.0.md → Montana v35.12.0.md. |
| 0.0.0        | v35.11.0     | 2026-05-01 | **Minor release: spec bump v35.10.0 → v35.11.0 — карточки ProtocolMessage envelope + реестр типов сообщений (закрытие II.1 плана сетевого слоя M6).** (1) ProtocolMessage envelope — 14B fixed header (1B msg_type + 1B msg_version + 8B request_id u64 LE + 4B payload_length u32 LE) + variable payload; Gate 13a invariants enumeration explicit; status закрыто (с открытым sub-finding на backpressure constants — план II.5). (2) Реестр типов сообщений — групповая карточка над 18 message-type кодами в 6 категориях (Consensus objects, Fast Sync, Peer Discovery, App Lookup, App Subscription, Liveness); каждая категория с собственными validation + lifecycle характеристиками; payload-объекты категории A (Transfer/ChangeKey/Anchor/NodeRegistration/BundledConfirmation/VDF_Reveal/Proposal) ссылаются на свои существующие карточки в основной части спеки; status закрыто (с conformance pending по [I-9] до закрытия плана II.3 binding KAT vectors). **Что закрывает:** раздел II.1 плана сетевого слоя — все 12 карточек замыкания механизмов сетевого уровня заполнены (3 IBT + 2 framing/randomness + 3 peers/dandelion/NAT + 2 mesh/SF + 2 envelope/registry); каждая имеет 11-pass + 15-pass invariant compatibility evidence. Implementer всех M6 крейтов имеет полный normative reference. **Что НЕ закрывает (open в плане II):** Storage Cards для PeerRecord/used_nonces/sf_buffer/bootstrap blacklist (II.2); ~50 binding KAT vectors (II.3); Threat Model (II.4); backpressure/connection limits в protocol_params (II.5); apply_mesh_frame / apply_store_and_forward formulations (II.6); Final Gate 0.5(d) + Gate 15 audit (II.7). **No code recompile required.** Spec file renamed Montana v35.10.0.md → Montana v35.11.0.md. |
| 0.0.0        | v35.10.0     | 2026-05-01 | **Minor release: spec bump v35.9.0 → v35.10.0 — карточки Mesh Transport + Store-and-Forward (раздел II.1 плана сетевого слоя M6).** (1) Mesh Transport — BLE / Wi-Fi Aware / mDNS-multicast P2P без интернета; MeshFrame wire format integer-specified (flags + fragment_index + total_fragments + recipient_hint 32B + payload); первичный пример [I-4] TimeChain independence в адверсарных условиях (отключение интернета через cached_window_index); battery-aware advertisement frequency (1/8 baseline при <20% charge); status закрыто. (2) Store-and-Forward — буферизация для offline recipient через intermediate peers; envelope (recipient_hint + ttl_window u32 LE + fragment indices + ciphertext + sender_signature 3309B ML-DSA-65); E2E encrypted через ML-KEM session к recipient — intermediate видит только metadata; three-layer time defense ([I-15]): TTL ≤ 24·τ₁ + per-sender quota per τ₁ + signed ack window TTL τ₁; [I-14] комбинация путей 2+3 (temporal + hard quota); status закрыто. **Что закрывает:** для двух наиболее сложных transport-механизмов (offline operation + buffering) явный 11-pass + 15-pass closure record; implementer mt-net::mesh / mt-net::store_forward имеет полный invariant compatibility evidence. **Что НЕ закрывает (open):** карточка ProtocolMessage envelope + 18 message types; Storage Cards для PeerRecord/used_nonces/sf_buffer/bootstrap blacklist; ~50 KAT vectors; Threat Model; backpressure/limits; apply formulations. **No code recompile required.** Spec file renamed Montana v35.9.0.md → Montana v35.10.0.md. |
| 0.0.0        | v35.9.0      | 2026-05-01 | **Minor release: spec bump v35.8.0 → v35.9.0 — три карточки peer selection / Dandelion++ / NAT (раздел II.1 плана сетевого слоя M6).** (1) Peer selection — 4-уровневая diversity (/16, ASN, start_window, role); локальная PeerRecord table в RocksDB вне consensus state; [I-14] путь 2 (temporal pruning по last_seen_window TTL) + hard quota 8192 в Storage Card (открыт в II.2); [I-15] start_window-based diversity = время как scarce ресурс через VDF-барьер регистрации; rotation 1 peer per τ₂; status закрыто. (2) Dandelion++ — two-phase relay для скрытия источника user operation; stem geometric distribution expected 10 hops + hard cap 30; [I-2] explicit acknowledgment что Dandelion++ скрывает только первый hop, recipient + amount остаются открытыми после fluff (financial layer открытость сохраняется); [I-6] не privacy mixer; status закрыто. (3) NAT Traversal — operator choice триада: UPnP/PCP, AutoNAT + hole punching через rendezvous, circuit relay для симметричных NAT (TLS+IBT end-to-end сохранены через relay); UPnP TTL 30 мин bounded refresh; status закрыто. **Что закрывает:** для трёх transport-policy механизмов теперь явный 11-pass + 15-pass closure record; implementer mt-net::peers / mt-net::dandelion / mt-net::nat имеет полный invariant compatibility evidence. **Что НЕ закрывает (open):** карточки mesh + Store-and-Forward + ProtocolMessage envelope + 18 message types; Storage Cards для локальных таблиц; KAT vectors; Threat Model; backpressure/limits; apply formulations. **No code recompile required.** Spec file renamed Montana v35.8.0.md → Montana v35.9.0.md. |
| 0.0.0        | v35.8.0      | 2026-05-01 | **Minor release: spec bump v35.7.0 → v35.8.0 — продолжение раздела II.1 плана сетевого слоя M6 (карточки Uniform Framing + Transport Randomness).** Добавлены две новые карточки в раздел «Карточки замыкания механизмов сетевого слоя» сразу после IBT triumvirate. (1) Uniform Framing — frame layout 1024B (1B flags + 2B length + 1021B payload) integer-specified; baseline 1 fps на исходящих + max burst 8 frames + ≥20% padding ratio в окне τ₁; [I-15] time-based scarcity через rate-limit времени, [I-9] partial (frame structure deterministic, scheduling non-deterministic by design — иначе attacker предсказывает padding pattern); status закрыто. (2) Transport Randomness — explicit boundary с consensus randomness ([I-8]): OS CSPRNG для transport (padding bytes, frame jitter, stem routing choice, mesh_session_nonce, bootstrap PoW nonce, backoff jitter); PRNG от node state ЗАПРЕЩЁН для transport; [I-1] PQ через современные ядра (ChaCha20/AES-CTR DRBG + hash-based reseed = post-quantum symmetric, Grover до 128 бит при ≥256-битной seed); status закрыто. **Что закрывает:** transport-layer non-determinism теперь явно разграничен с consensus determinism через 15-pass invariant записи; implementer не смешает источники randomness в одной hash composition (acknowledgment по [I-3]/[I-8] границам). **Что НЕ закрывает (open в плане раздела II):** карточки peer selection / Dandelion / NAT / Mesh / Store-and-Forward / ProtocolMessage envelope + 18 message types; Storage Cards для локальных таблиц; ~50 binding KAT vectors; Threat Model раздел; backpressure/connection limits; apply_mesh_frame / apply_store_and_forward formulations. **No code recompile required** — только spec normative text additions. Spec file renamed `Montana v35.7.0.md` → `Montana v35.8.0.md`. |
| 0.0.0        | v35.7.0      | 2026-05-01 | **Minor release: spec bump v35.6.0 → v35.7.0 — открыт раздел II.1 плана сетевого слоя M6 (карточки замыкания механизмов).** Добавлен новый top-level раздел «Карточки замыкания механизмов сетевого слоя» сразу после «Label Rotation + Range Subscribe Protocol» и перед «Эволюция протокола». Заполнены первые три карточки IBT triumvirate: (1) IBT online proof — 11-пунктная замыкающая карточка + 15-pass global invariant check; transport-orthogonal, [I-1] PQ через ML-DSA-65, [I-15] time-based scarcity через window slot; status закрыто. (2) IBT mesh proof — расширенный staleness window 7·τ₁ компенсирован per-nonce tracking, [I-14] путь 2 (temporal) для used_nonces table, [I-4] independence через cached_window_index; status закрыто. (3) Bootstrap PoW — anti-flood gate для 12 hardcoded genesis узлов, ≈100 мс CPU per попытка, recent_nonces TTL = τ₁; status закрыто с открытым sub-finding на формализацию `bootstrap_pow_difficulty` в Genesis Decree (закроется отдельной правкой раздела II.5 плана). **Что закрывает:** для трёх IBT-related механизмов теперь явный 11-pass + 15-pass closure record — implementer и аудитор видят полный invariant compatibility evidence в одном месте. **Что НЕ закрывает (open в роадмапе II):** карточки для Uniform Framing, Transport Randomness, peer selection, Dandelion++, NAT, Mesh Transport, Store-and-Forward, ProtocolMessage envelope + 18 message types; Storage Cards для локальных сетевых таблиц (PeerRecord, used_nonces, sf_buffer, bootstrap blacklist); ~50 binding KAT vectors для wire format; Threat Model раздел; backpressure/connection limits в protocol_params; apply_mesh_frame / apply_store_and_forward formulations. **No code recompile required** — только spec normative text additions. Spec file renamed `Montana v35.6.0.md` → `Montana v35.7.0.md`. |
| 0.0.0        | v35.6.0      | 2026-05-01 | **App spec bump v3.10.0 → v3.11.0 (parallel) — closure formal finding по indirect prompt injection при уровне Юноны «Помощник».** Внешний рецензент в правильном формате (construction attack + spec gap reference + quantified impact) идентифицировал asymmetric whitelist coverage в App spec section 17.2/17.3/17.9: `recipient_whitelist` описан только для `Transfer` (уровень Оператор), для 7 других write ops уровня Помощник (`send_message`, `reply_message`, `publish_post`, `publish_anchor`, `upload_file`, `delete_file`, `manage_subscription`) whitelist отсутствовал. Construction attack: контакт B → ML-KEM-768 encrypted сообщение с payload → Юнона индексирует в RAG (section 17.6: «История сообщений (открытый текст из локальной SQLite)») → следующий запрос владельца извлекает payload в контекст → инструкции на send_message/publish_post/publish_anchor проходят без whitelist check. Финансовый ущерб = ноль (закрыт `recipient_whitelist`); reputational/social impact ненулевой. **Closure construction — пять координированных правок:** (1) section 17.3 `PermissionConfig` layout — добавлены `contact_whitelist` (send_message/reply_message recipients), `app_id_whitelist` (publish_post/publish_anchor/upload_file), `daily_write_op_cap` (max write ops per τ₂); (2) section 17.2 — параграф «Per-class enforcement для уровня Помощник» с таблицей 8 операций × whitelist check × confirmation; `delete_file` mandatory per-op; `manage_subscription` без whitelist (reversible); (3) section 17.7 — refined exception для pre-authorization: применяется только к read-only repetitive patterns; для write ops при уровне Помощник допустима bulk confirmation per session с explicit scope, expirется через 30 дней либо при `PermissionConfig` change; `delete_file` всегда mandatory per-op; (4) section 17.9 пункт 2 расширен с «Инъекция через входящие сообщения» до «Indirect prompt injection через любой входной контент» с явным construction attack vector + coverage table (asymmetric by design) + acknowledged residual risk; (5) header 3.10.0 → 3.11.0. **Что закрывает:** construction attack заблокирован per-class whitelist + `daily_write_op_cap`; asymmetric coverage finding закрыт extension существующего whitelist pattern на все write ops уровня Помощник. **Что НЕ закрывает (acknowledged residual):** spam в whitelisted contacts (legitimate-pattern injection), prompt injection success rate на open-weight 8B-32B моделях остаётся существенным — defence-in-depth, не absolute. Protocol layer (Montana v35.6.0) не затрагивается — Юнона application-level concept, протокольные крейты `mt-*` про неё не знают. **No code recompile required.** App spec file renamed `Montana App v3.10.0.md` → `Montana App v3.11.0.md`. |
| 0.0.0        | v35.6.0      | 2026-05-01 | **Minor release: subtype disclaimer для TimeChain VDF — закрытие terminology hygiene gap из внешнего ревью.** Внешний рецензент идентифицировал что формула `T_r = SHA-256^D(T_{r-1})` называется в спеке «VDF» хотя строго это iterated sequential hash chain — настоящие VDF (Boneh–Bonneau–Bünz–Fisch ePrint 2018/601) требуют succinct verification proof O(log T) (Pietrzak ePrint 2018/627, Wesolowski ePrint 2018/623), которого у конструкции Монтана нет; верификация требует пересчёта O(D × chain_length). Cascade rename «VDF» по спеке (125 hits) отвергнут: затрагивает binary layouts (`vdf_chain_length` field NodeRegistration), domain separators (`mt-vdf-reveal`), opcodes (`VDF_Reveal`), константы Genesis Decree (`vdf_entry_windows`, `adaptive_vdf_threshold`, `adaptive_vdf_multiplier`); cost cascade rename выше hygiene benefit. **Минимальное закрытие:** один disclaimer-параграф в section «TimeChain VDF — осциллятор» (перед формулой) — три предложения: (1) acknowledgement subtype = iterated SHA-256 chain, не VDF в строгом смысле; (2) обоснование выбора через [I-1] PQ-secure (Wesolowski/Pietrzak на RSA/class groups мнимо-квадратичных полей ломаются Shor); (3) acknowledgement что PQ-secure succinct VDF на момент Genesis research grade без production audit history. Industry прецедент — Solana Proof-of-History (iterated SHA-256 chain без succinct proof) — подтверждает класс конструкции. **Эффект:** внешний pre-mainnet security audit получит ответ из единого места в спеке, не из разбросанных утверждений; терминологический mismatch перестаёт быть потенциальным audit-blocker. **No code recompile required** — terminology only, никаких изменений consensus-critical path / wire format / state layout / hash compositions. Spec file renamed `Montana v35.5.0.md` → `Montana v35.6.0.md`. |
| 0.0.0        | v35.5.0      | 2026-04-29 | **Minor release: closure B2+B3 finding из внешнего аудита 2026-04-28 — gap в спеке про canonical Merkle algorithm для proposal-уровня.** Аудит обнаружил singleton-mode placeholder shortcuts: `single_leaf_root(leaf) = *leaf` для одиночного listа (без leaf_hash обёртки), `control_root = [0u8; 32]` для пустого set. Reading релевантных разделов спеки целиком (не grep coverage) подтвердил: для state-уровня (Account/Node/Candidate) явно описан Sparse Merkle Tree глубины 256 с canonical leaf_hash / internal / empty_internal через domain separators `mt-merkle-leaf` / `mt-merkle-node`; для proposal-уровня (`control_root`, `included_bundles_root`, `included_reveals_root`) описаны только leaf values (= R2 identifier per Правило R2, line 864) — algorithm построения tree из filtered set отсутствовал. Cross-implementation drift risk: implementer A читает «Merkle root списка» как ordered binary tree (Bitcoin-style), implementer B как SMT-256, B как single-leaf shortcut — разные roots на одних данных, гарантированный fork первого multi-node запуска. **Решение (после adversarial review критика — три clarifications включены):** новый раздел «Структура proposal-level Merkle roots» сразу после описания state-level Merkle структур. Канонический algorithm = тот же SMT-256 что используется state-уровне ([I-7] минимальная криптографическая поверхность + reuse mt-merkle code), индексация по natural keys: `control_root` ключ = `nodereg_hash` (R2 identifier ControlObject); `included_bundles_root` ключ = `confirmer_node_id`; `included_reveals_root` ключ = `reveal_author_node_id`. Empty marker для всех трёх = `empty_internal(256)` через cross-reference на authoritative location (не дублирование hex). Set semantics явно зафиксирована — порядок включения не влияет на root, narrative «список» обозначает множество с canonical filter, не sequence. Single-leaf через стандартную SMT процедуру (без shortcuts). **Side-fix [I-10]:** строка 1303 ранее говорила «Empty root = `0x00 × 32`» для Candidate Pool — drift с line 2387 «empty_internal(256) = 0x87dd145e...» (та же таблица, два авторитетных значения). Side-fix: cross-reference на authoritative empty_internal(256). **Code-side companion** — отдельный commit в `Протокол/Код/.git`: замена `single_leaf_root` shortcut на корректный SMT-256 build через `mt_merkle::SparseMerkleTree`; замена `control_root = [0u8; 32]` на `mt_merkle::empty_internal(256)`; удаление функции `single_leaf_root` (больше не используется). **Audit:** grep по spec на `single_leaf_root` / `0x00 × 32` (как root marker): 0 hits после patch. Spec file renamed `Montana v35.4.0.md` → `Montana v35.5.0.md`. **Code recompile required** (montana-node start.rs proposal-level Merkle construction). |
| 0.0.0        | v35.4.0      | 2026-04-29 | **Minor release: closure B4 finding из внешнего аудита 2026-04-28 — spec-internal drift в формуле lottery_weight.** Раздел «Лотерея → weighted_ticket_node» содержал внутреннее противоречие: real-valued formula + integer-form authoritative + derivation prose все три давали `seniority_bonus = chain_length / 13` (target T_cap = 3 × T_year ≈ 1 577 880 окон, snapshot_max = 6τ₂ = 120 960, divisor ≈ 13), но binding test vectors N1-N5 были построены под код mt-lottery с делителем `/ 69` — math 1000/69 = 14 совпадает с N1 expected, math 1000/13 = 76 не совпадает. Гарантированный cross-implementation fork: implementer A читает formula → пишет /13 → test vectors fail. Дополнительно: остаток старой калибровки (когда τ₂ = 13 000) — `chain_length_snapshot ≤ 78 000 (6τ₂)` в трёх местах вместо актуального `120 960 (6τ₂ при τ₂ = 20 160)`. **Решение (вариант β — formula authoritative, code corrected):** код mt-lottery `/ 69` → `/ 13` (одна строка); test vectors recomputed: N1 weighted_ticket_node `0x0000000000000000002788D5E211170C` → `0x000000000000000000234770A382CE58` (weight 514 → 576), N4 snapshot 78000 → 120960 (weight 156000 → 241920, hex `0x000000000000000000002158CB8365BE` → `0x000000000000000000001580E0B1AED0`), N5 chain_length 69 → 13 (новая seniority threshold под N=13, hex unchanged потому что cap режет). **Переименование `seniority_bonus` → `seniority_term`** во всех 11 местах spec и всех use-sites code (term = слагаемое формулы, без маркетингового coloring «бонус»). Структурное обоснование 13: совпадает с EMISSION_moneta = 13 Ɉ per window (line 5236 «structural reuse»). Также: pruning последних 78 000 → 120 960 в derivation block (line 1490), overflow comment (line 1451), snapshot horizon list (line 1499). **Audit:** grep по всему spec на `seniority_bonus` → 0 hits; на `78 000` / `78_000` → 0 hits; на `/ 69` → 0 hits. **Code recompile required** (mt-lottery: rename + delitел). Spec file renamed `Montana v35.3.2.md` → `Montana v35.4.0.md`. |
| 0.0.0        | v35.3.2      | 2026-04-28 | **Patch release: closure F-B1..F-B3 от full Pass 13d audit над v35.3.1.** Применён newly-formalised Pass 13 Часть D «Numerical SSOT integrity» на все protocol_params поля. Findings: (F-B1, **средний**) line 2565 содержала arithmetic error «3τ₂ (39 000 окон)» — 3 × τ₂_windows = 3 × 20 160 = 60 480, не 39 000. Stale value либо ошибка вычисления. Closure: переформулировано «через `candidate_expiry_windows = 3τ₂ = 60 480 окон` (см. Genesis Decree)» с явным cross-reference. (F-B2, косметика) line 3174 размеры узла illustrative «возрастом ~1 год работы» / «~2 GB/год» — physical-time references без [I-18] qualifier. Closure: «возрастом ~26 τ₂ (emergent ≈ 1 год при genesis-калибровке, illustrative per [I-18])» + «2 GB на 26 τ₂». (F-B3, косметика) line 4832 «peer blacklisted на 24 часа» / «1 час» / exponential backoff в секундах transport layer без consistency note. Closure: переформулировано в τ₁ scale + явный «outside [I-18] scope». Также: Эффективность на 1B scale (line 5036-5042) и max_range_labels_per_request derivation (line 5295) — «1 день»/«14 дней» offline references переформулированы в «1440 τ₁» / «1 τ₂» canonical units; CPU-time references помечены «(local CPU time, outside [I-18] scope)». **Audit summary**: после полного Pass 13d audit на все protocol_params поля (D₀, τ₂_windows, EMISSION_moneta, confirmation_quorum, participation_dead_zone, d_adjustment_rate, selection_interval, admission_divisor, candidate_expiry, pruning_idle, active_predicate, vdf_entry_windows, adaptive_vdf_*) — все авторитетные значения в Genesis Decree, derivation/justification разделы либо имеют explicit cross-reference либо используют τ-multiplier формулы. Final residual sweep: D₀ stale values (300M/3×10⁸): **0 hits**; «39 000» arithmetic error: **0 hits**; wall-clock: 4 hits все в explicit negation; timestamp: **0 hits**. Cross-implementation drift risk: zero. **No code recompile required.** Spec file renamed `Montana v35.3.1.md` → `Montana v35.3.2.md`. |
| 0.0.0        | v35.3.1      | 2026-04-28 | **Patch release: closure F-A1..F-A5 critic findings от audit над v35.3.0 + role updates Gate 0.6 / Pass 13d / [C-1.1] для prevention numerical SSOT drift класса.** Все правки text/factual fixes без semantic change consensus path; backward-compatible с v35.3.0. (F-A1, **блокер** [I-10] SSOT) Раздел «Криптографические и временные параметры» строка 5246 содержала `D₀ = 300 × 10⁶ ... 4.2 MH/s commodity x86_64 × 60s` — stale value не синхронизирован с правленой Genesis Decree calibration (которая после v35.3.0 говорит 325 000 000 на 5.097 MH/s genesis-железа). Cross-implementation drift risk: реализатор хардкодит 300M из таблицы, узел не стартует с Genesis State Hash рассчитанным на 325M из Genesis Decree. Закрытие: row reformulated с explicit «authoritative SSOT в Указе Генезиса → "Калибровка D₀" per [I-10]» reference + value sync 3.25 × 10⁸ + benchmark 5.097 MH/s genesis hardware. (F-A2, косметика) [I-8] строка 270 перечисляла «timestamps» как пример canonical-predictable-offline входов; под [I-18] timestamps в protocol отсутствуют — пример терял конкретный референт. Закрытие: «(VDF output, timestamps, state counters)» → «(VDF output, state counters, любые forward-computable canonical inputs)». (F-A3, косметика) KDF section (строки 3612, 3615) содержала bare «секунда»/«сек» в Target и Sensitivity полях inconsistent с line 3614 «локальная кварцевая секунда». Закрытие: добавлен qualifier «локальная кварцевая» + явный «(client-side KDF, outside [I-18] scope)» note в Target. (F-A4, средний) Строка 1143 «cemented (необратимо, ~0.3 сек)» — wall-clock claim в normative narrative без `(emergent)` либо outside-scope qualifier. Закрытие: переформулировано «cemented (необратимо, в пределах текущего τ₁; emergent ~0.3 секунды на genesis-калибровке, illustrative)». (F-A5, косметика) Строка 4788 «Максимум 5 секунд на graceful shutdown» — transport-layer timeout без consistency с TCP/TLS handshake reformulation. Закрытие: «τ₁/12 на graceful shutdown (по локальному кварцу транспортного стека, outside [I-18] scope)». **Methodological closure:** root cause F-A1 — отсутствие mandatory pre-commit numerical sync grep между Genesis Decree и derivation/justification разделами. Direct response: добавлены **Gate 0.6 (architect role v4.30.0)** — proactive prevention перед commit; **Pass 13 Часть D (critic role v3.13.0)** — retroactive detection на audit; **[C-1.1] (code architect role v1.14.0)** — cross-spec-code value verification при spec bump. Двойная защита (proactive + retroactive) от класса «numerical SSOT drift между Genesis Decree и derivation tables». Spec file renamed `Montana v35.3.0.md` → `Montana v35.3.1.md`. **No code recompile** required (mt-genesis::ProtocolParams::D0_DEFAULT уже = 325_000_000 from earlier code commits — code был ahead spec на v35.3.0; v35.3.1 синхронизирует residual derivation tables). |
| 0.0.0        | v35.3.0      | 2026-04-28 | **Minor release: новый глобальный инвариант [I-18] «Time absence in protocol» + recalibration D₀ + thorough cleanup внешних времени-references по всей спеке.** Восемь связанных изменений в одном bump-е: (1) **[I-18] добавлен в реестр** после [I-17] (раздел «Глобальные инварианты протокола»). Формулировка: единственный исторический quartz-замер произошёл ДО запуска сети на genesis-железе (Apple iMac M1 2021, idle, single-thread); после Genesis протокольный код и consensus state не читают CLOCK_REALTIME / CLOCK_MONOTONIC / NTP / GPS / любые time-oracles; все длительности в окнах TimeChain или хэшах. Scope: protocol code + consensus state. Outside scope: kernel-level network primitives + operator tooling. (2) **D₀ recalibrated 300_000_000 → 325_000_000** (hex 0x135F1B40). Derivation: benchmark на genesis-железе дал 5.097280 MH/s × 60 квaрцевых секунд = 305 836 793; runtime-corrected 305 836 793 × (60 / 56.35) = 325 000 000 учитывая VDF interleaving с consensus работой. ProtocolParams.D₀ обновлён в Genesis Decree. (3) **Genesis hardware reference profile** добавлен в раздел «Калибровка D₀»: точная модель (iMac21,1 24-inch M1 2021), процессор (M1 base 4P+4E, 8 GB unified memory), ОС (macOS Sequoia 15.7.3 build 24G419, kernel Darwin 24.6.0), toolchain (Rust 1.92.0 stable aarch64-apple-darwin, release lto=fat opt-level=3 codegen-units=1), SHA-256 backend (sha2 crate v0.10.9 + ARM SHA-2 hw ext). Methodology: 3 runs × 1_000_000_000 итераций iterated SHA-256, машина idle. (4) **Ping/Pong (0xF0/0xF1) timestamp удалён** — wire format теперь без payload, чистая liveness-проверка; keepalive переформулирован в τ₁ единицах. (5) **Anchor «timestamp» переименован в «canonical-position proof»** во всех местах (Storage Card Proposals chain, разделы Anchor / Доказательство канонической позиции / Read flow); раздел «Доказательство временной метки» переименован в «Доказательство канонической позиции». (6) **Mesh transport `timestamp_relay` u64 заменён на `ack_seq` u64** (relay-локальный sequence counter без временной семантики); BufferEntry `received_at timestamp (local, monotonic)` → `receipt_seq u64` (sequence counter); MeshAck signed payload обновлён (timestamp_relay → ack_seq). (7) **Thorough sweep informational time-references**: peer rotation 10 минут → 10 τ₁; peer exchange 1/min → 1/τ₁; Dandelion hop timer 30 sec → τ₁/2; mesh fragment reassembly 60 sec → τ₁; TCP/TLS/Noise handshake timeouts (transport layer, outside [I-18] scope) reformulated в τ₁ scale с явной пометкой «outside [I-18] scope»; sync tolerance «двухоконная (до 120 sec)» → «двухоконная к рассинхронизации канонических окон»; KDF derivation references «0.7 sec wall-clock» → «0.7 локальной кварцевой секунды» (client-side). (8) **Header v35.2.0 → v35.3.0**, файл переименован Montana v35.2.0.md → Montana v35.3.0.md. **Audit summary**: финальный grep-аудит даёт 5 hits на wall-clock/UTC/NTP — все в explicit negation/boundary statements ([I-18] prohibition list, «никакой узел не сообщает wall-clock», «UTC/TAI/GPS — задача клиентского слоя», «не передаёт wall-clock»). External time references в protocol code и consensus state: zero. **No code r
| 0.0.0        | v35.1.0      | 2026-04-28 | **Minor release: closure F-1..F-4 critic findings над v35.0.5 + role v4.28.0 одновременно.** Critic-mode pass над Storage Card для Proposals chain (v35.0.5) + Symmetric conservation invariants restrict (role v4.28.0) выявил четыре finding-а; все закрыты. (F-1, низкий) Storage Card подавал «Bytes per год = 1.96 GB» как binding-like; wall-clock не protocol invariant (calibration target ~60 с/окно с variance ×20). Закрытие: переименовано «Time-bound growth analysis» → «Growth analysis», bytes per год / 10 лет помечены `(illustrative)` с явной ссылкой на «Calibration target». (F-2, средний) Cross-section inconsistency между Storage Card (1.96 GB/год proposals) и таблицей «Размеры» (~3 GB total для 1M аккаунтов без указания возраста сети). Закрытие: добавлен qualifier под таблицей «Размеры» — «иллюстративны для сети возрастом ~1 год». (F-3, средний методологический) Storage Card claim «[I-14] путь 3 — hard quota через consensus rate» категориально неверен. [I-14] построен против slow-bloat attack через user-driven operations; rate cap (один header per τ₁) ≠ count cap. Proposals chain — consensus-driven ресурс, не user-driven. Закрытие (Option C): claim заменён на «[I-14] applicability: N/A — proposals не user-driven, growth = consensus structure invariant; slow-bloat attack class категориально не применим»; status «closed» → «closed категориально»; audit table row обновлён аналогично; сводка под Storage Cards переформулирована — 4 user-driven tables под scope [I-14], 1 consensus-driven вне scope. (F-4, средний методологический; role) Distinguishing criterion v4.28.0 «tight vs soft» с обоснованием через user behaviour assumptions неточен — AccountRecord имеет mathematically tight bound через consensus enforcement cooldown, но non-actionable из-за exponential vs linear divergence. Закрытие: переформулировка criterion на «actionable vs non-actionable» через ratio `bound_max / actual_typical`; tightness derivation отдельна от actionability; conclusion (AccountRecord исключён) сохраняется, reasoning corrected. [I-10] header drift fixed: header был 35.0.5, имя файла v35.1.0.md → header bumped sync. Bump категория повышена patch → minor автором (35.0.5 → 35.1.0) — адекватно для F-3 категориальной переклассификации [I-14] applicability. **No code recompile.** **No backward-incompatibility.** Spec file renamed `Montana v35.0.5.md` → `Montana v35.1.0.md`. |
| 0.0.0        | v35.0.5      | 2026-04-28 | **Patch release: documentation closure для proposal chain под [I-14]/Gate 14.** Добавлен пятый Storage Card («Storage Card — Proposals chain») в раздел «Storage Cards per persistent table» после Anchor records: размер записи 3 722 B (proposal header per layout раздела «Proposal»: 12 × 32 B хэш/Merkle/id полей + window_index 8 + protocol_version 4 + target 16 + fallback_depth 1 + signature 3309); time-bound growth analysis (1.96 GB/год wall-clock = 525 600 окон × 3 722 B); [I-14] путь 3 (hard quota через consensus rate — один header per τ₁); permanent retention обоснована Anchor timestamp proof verification до genesis + Fast Sync chain verification. Добавлена строка `Proposals chain` в conformance audit table. Счётчик «Все 4 Storage Cards» → «Все 5 Storage Cards» обновлён. Закрытие методологического gap — proposal chain суть persistent state без явного lifecycle, требовала explicit Storage Card обоснование чтобы Gate 14 critic/auditor не задал «где Storage Card для proposals?». **Drift acknowledgment:** VERSION.md retroactively синхронизирован с v34.0.1 → v35.0.5 в один шаг; промежуточные bump-ы v34.x..v35.0.4 описаны в git log Протокол/. **No code recompile.** **No backward-incompatibility.** Spec file renamed `Montana v35.0.4.md` → `Montana v35.0.5.md` per `feedback_spec_rename` rule. |
| 0.0.0        | v34.0.1      | 2026-04-27 | **Patch release: closure F-1/F-2 critic findings от audit токеномики над v34.0.0.** Все правки — text/factual fixes без semantic change consensus path; backward-compatible с v34.0.0 implementations; no code recompile. (F-1) Phantom references на удалённые сущности `nickname/credits` в narrative о apply_proposal flow убраны в двух местах: line 1351 (описание proposer flow `apply_proposal по балансам/nickname/credits` → `apply_proposal по балансам и account_chain_length increment`) + line 1667 (Proposer Lookback Leader: `apply_proposal (баланс, nickname, credits, account_chain_length increment)` → `apply_proposal (баланс, account_chain_length increment)`). Класс ошибки — Cleanup ≠ Closure: при v33.x → v34.0.0 cleanup AccountRecord layout (удалены поля nickname/credits), реестра type bytes (0x05/0x08/0x09 → reserved unused), реестра инвариантов ([I-11]/[I-12]/[I-13] → reserved unused) — narrative о apply_proposal flow продолжал перечислять удалённые сущности в порядке обработки. Implementer прочитав 1351/1667 строил mental model «apply_proposal обрабатывает nickname/credits» → попытка реализовать через type byte 0x05 → упор в reserved-unused. Gate 15 Шаг 4 dead-branch audit при v34.0.0 commit не покрыл narrative-уровень. (F-2) Type-divergence в BatchLookupRequest layout (line 4563): `query_type 1B <- u8: 0x01 pre_key_bundle, 0x02 nickname, 0x03 account_exists` → `query_type 1B <- u8: 0x01 pre_key_bundle, 0x03 account_exists`. Authoritative Инварианты BatchLookupRequest (line 4576) явно: `query_type ∈ {0x01, 0x03}; иное → reject UnsupportedType`. Layout перечислял `0x02 nickname` без definition в query_entry/result_entry/Validation workflow → cross-implementation desync на benign request с query_type = 0x02 (одни добавили бы app-level nickname resolver, другие реджектнули бы). Class type-divergence per Gate 13c (type annotations only в authoritative). nickname как сущность отсутствует на protocol level — её здесь не должно быть совсем. **Закрытие методологического gap:** все три hits были pure narrative drift без logic impact — apply_proposal реализация (mt-account/mt-consensus crates) не содержит nickname/credits веток с v33.0.0 (см. v33.0.0 history entry: «удалены NicknameTable/AuctionTable types, AccountRecord 2108 → 2059 bytes»). Код unchanged. **No code recompile.** **No backward-incompatibility.** Spec file renamed Montana v34.0.0.md → Montana v34.0.1.md per feedback_spec_rename rule. |
| 0.0.0        | v34.0.0      | 2026-04-27 | **Major bump: const emission Money — пересмотр монетарной политики.** Удалены geometric step-up baseline + Constitutional declaration (Freigeld/Gesell/Frederick/Keynes/Friedman/Schmitt-Grohé/Bordo/Onken/Wörgl academic apparatus) + Equilibrium analysis для (41/40)^e + Binding test vectors с эпохами. Pin `inflation_num/inflation_den = 41/40 = 2.5%` заменён на const `EMISSION_moneta = 13 × 10⁹ nɈ` per окно. **Cascade в коде:** mt-genesis ProtocolParams 4118 → 4094 bytes (−24B: удалены `monetary_epoch_windows` + `inflation_num` + `inflation_den`); rename `r_genesis_moneta` → `emission_moneta`. mt-state удалена `MonetaryState` struct (24B persistent state) + 3 controlled panics в `apply_step` + `MONETARY_STATE_SIZE`; `compute_state_root` упрощён до 3 args (`node_root`, `candidate_root`, `account_root`). mt-account удалены `r_baseline_at_epoch` + `monetary_epoch_tick`; `reward_moneta(params) = params.emission_moneta`; `supply_moneta(W) = emission × (W+1)` closed-form O(1); `apply_proposal` без Step 2.5; `genesis_state_root` без MonetaryState. mt-store удалены `save_monetary_state` + `load_monetary_state` + `monetary.bin`. mt-examples `m33_emission` example удалён. AUDIT.md / ROADMAP.md / audit-checklist.md обновлены. Constitutional break: новый Genesis State Hash (ProtocolParams layout + state_root composition меняются) — pre-mainnet нормально. |
| 0.0.0        | v33.1.3      | 2026-04-26 | **Patch release: closure F-1 critic finding от M0+M1+M2 spec-vs-code audit (commit `b4a00b1`).** Domain separators registry sync — добавлена строка `mt-recovery-fingerprint` (Domain separators registry, после `mt-queue-rotation`): «Derivation recovery-fingerprint для two-device manual validation per [C-4] (Manual Validation Gate Scenario 0 «User onboarding» в reference implementation `crates/mt-examples/examples/m1_mnemonic.rs`); SHA-256 от `("mt-recovery-fingerprint" \|\| 0x00 \|\| account_pubkey \|\| node_pubkey \|\| app_mlkem_pubkey)` даёт 32-байт fingerprint, отображаемый пользователю как 64-char hex для voice-comparison между двумя устройствами после recovery from mnemonic». Domain был добавлен в `mt-codec` в M1-E Phase F (commit `11f7232`) с пометкой «registry +1, 31 → 32 separators», но spec не отражал. Закрытие [C-1] SSOT cross-spec-code drift: alt-implementation reading spec теперь имеет полный domain registry для воспроизведения recovery-fingerprint flow байт-в-байт. **No code recompile.** **No backward-incompatibility.** Реальная implementation (5 mentions в mt-codec + 2 mentions в mt-examples) уже corresponds к этой definition — patch только добавляет documentation. Spec file renamed Montana v33.1.2.md → Montana v33.1.3.md per feedback_spec_rename rule. |
| 0.0.0        | v33.1.2      | 2026-04-26 | **Patch release: closure 4 critic findings от audit над v33.1.1 / app v3.9.1.** Все правки — text/factual fixes без semantic change consensus path; backward-compatible с v33.1.1 implementations; no code recompile. (F-1) Range notation `[I-1]…[I-17]` → explicit `[I-1]..[I-10] + [I-14]..[I-17]` (14 действующих) с marker `slots [I-11]/[I-12]/[I-13] reserved unused` в двух местах: Persona shift implications (line 90) + Constitutional limits Level 1 enumeration (line 5122). Range notation формально включала несуществующие slots удалённые при v33 cleanup. (F-2) D₀ scientific notation `2.52 × 10⁹` → `2.52 × 10⁸` в Genesis parameters block (раздел «Адаптация D через participation-ratio feedback»). Integer value 252 000 000 правильный; только parenthetical exponent off by ×10. (F-3) App spec FN-DSA-512 size cleanup gap: 897-байт mentions → 1952-байт ML-DSA-65 в трёх живых местах (line 498 — pubkey comparison statement, line 505 + 3070 — session_id construction formula `lower_pubkey || higher_pubkey = 1952 + 1952 = 3904 байта`); test vectors §23.2 (line 3110/3118/3119) обновлены 897 → 1952 + 896 → 1951 для consistency. Эти места упустил предыдущий cleanup grep потому что pattern `\b897 ?[Bб]` не покрывал `897-байтной` (с дефисом) и `897 + 897` (в арифметике). Теперь session_id derivation reproducible byte-exact с реальной ML-DSA-65 implementation. (F-4) Cross-reference protocol → app spec broken: «App spec раздел 5.2» (Рукопожатие через pre-key bundle) → «App spec раздел 23.2» (Label rotation formula, authoritative location) в двух местах: Label rotation formula раздел (line 4939) + Что закрывается через rotation раздел (line 4922). Authoritative formula всегда была в §23.2 app spec; line 4013 Domain separators registry уже указывала правильный §23.2, а 4939/4922 ссылались на wrong section. **No code recompile.** **No backward-incompatibility.** App spec параллельно bumped v3.9.1 → v3.9.2 для F-3 fix. |
| 0.0.0        | v33.1.1      | 2026-04-26 | **Patch release: closure 7 critic findings от critic-mode audit над v33.1.0 / app v3.9.0.** Все правки — clarification fixes без semantic change consensus path; backward-compatible с v33.1.0 implementations. (P-1) Equilibrium analysis math correct: incorrect claim «равновесная точка late = 10 эпох требует e > 280 эпох» переписан с честной derivation per-window ratio late/early = (e − e_late)/e → 1 асимптотически снизу, никогда не превышает 1; numerical illustration (T=50, e_late=10) даёт ratio early/late ≈ 1.81 что согласуется с claim в «Раннее участие». (P-2) Constitutional limits enforcement развёрнут в three-layer model: Layer 1 Genesis State Hash mismatch (покрывает constitutional invariants отражённые в protocol_params либо genesis state), Layer 2 protocol_version major-component bump rejection (compliance imperative implementer для constitutional invariants outside protocol_params — apply_proposal validation rules, opcode dispatch, cooldown rules), Layer 3 validation_rules_hash в Genesis Decree (recommended future MIP закрывающий Layer 2 disciplinary gap до automatic detection). Honest acknowledgement: на момент написания Layer 1 покрывает subset; Layer 2 — disciplinary enforcement через published MIP review process. (P-3) §28.6 «Юнона как proof concept» переформулирован как «design study демонстрирующий feasibility текущих primitives»; production-grade implementation pending (mt-* crates не содержат juno runtime, AUDIT.md scope = M1 foundational layer); первая реальная реализация даст authentic proof либо первый authentic trigger condition. (P-4) §28.1 Two-account pattern добавлены explicit «Известные ограничения» с пятью edge cases: race condition при revocation (cementing race с malicious operation в том же τ₁), ChangeKey требует владения agent secret (best practice — deterministic derivation из owner master_seed), capability scope = detection не enforcement через [I-17] auditable binary, funding rate ≠ granular capability (drain risk), visibility tradeoff. Явное разграничение «что pattern гарантирует» (financial loss bound, ability to revoke given conditions) vs «что НЕ гарантирует» (protocol-enforced capability scope, atomic revocation). (P-7) R_GENESIS = 13 governance pin усилен structural reuse rationale: pin = 13 совпадает с divisor в seniority_bonus formula (lottery_weight = chain_length_snapshot + min(chain_length / 13, snapshot)); sharing constant между monetary baseline и lottery formula reduces total parameter count by 1, превращая arbitrary symbolic choice в structural reuse. Иерархия целей безопасности row для R_GENESIS обновлён cross-reference. (P-9) Calibration target variance numbers исправлены: было «Apple Silicon — единицы секунд, loaded VPS — десятки секунд» (incorrect by factor ~10), стало «Apple Silicon ≈ 53 сек либо idle x86_64 VPS ≈ 68 сек при D₀; loaded shared VPS ≈ 1145 сек ≈ 19 минут; variance ×20» — согласуется с benchmark table в «Калибровка D₀». (P-10) ROI illustration «TC market price» → «Ɉ market price» + Иерархия целей row «TC price discovery» → «Ɉ price discovery» (legacy terminology drift fix; protocol use Монтана/Ɉ/moneta, не TC). Также: app spec v3.9.0 → v3.9.1 параллельный bump для P-3 + P-4 fixes. **No code recompile.** **No backward-incompatibility.** Patch release: documentation/clarification only. |
| 0.0.0        | v33.1.0      | 2026-04-26 | **Foundational additions без breaking changes (semver minor bump).** Шесть additive расширений накоплены в нескольких commits после v33.0.0 cleanup без version bump (системный недосмотр архитектора, исправлено retroactively): (1) **Calibration target раздел** в «Канонический порядок» — explicit разделение трёх уровней (protocol-нормативное определение окна как D итераций per [I-3], per-узел wall-clock variance ×10 между Mac M-series и loaded VPS, canonical window count synchronization через VDF chain length); cross-reference из intro мантры; methodology multi-region benchmarks указана; resolves external reader misinterpretation окна как 1 sec вместо 60 sec target. (2) **Идеологическое основание Freigeld (Gesell 1916)** в «Эмиссия → Constitutional declaration» — primary reference Gesell, S. (1916) Die natürliche Wirtschaftsordnung, Selbstverlag (английский перевод 1958, Peter Owen Ltd); Wörgl experiment 1932 как empirical верификация; Keynes endorsement (General Theory ch. 23); mechanism distinction между Gesell direct demurrage и Монтана dilution-via-emission; functional equivalent statement (hoarding penalty preserved, mechanism modern). Onken (2000) добавлен как historical analysis Freigeld-experimentов. (3) **Полные библиографические ссылки** для всех supporting refs: Friedman, M. (1968) AER 58(1), 1-17; Schmitt-Grohé & Uribe (2010) Handbook of Monetary Economics vol. 3B ch. 13, Elsevier, pp. 653-722 (preprint NBER WP 16054); Bordo & Filardo (2005) Economic Policy 20(44), 799-844 (preprint NBER WP 10833); Keynes (1936) The General Theory, Macmillan ch. 13-15. **R_GENESIS = 13 явно помечен как governance pin** (не academic derivation): bounded rationale + sensitivity analysis (±50% не меняет asymptotic) + defense block для трёх expected critic counter-questions. (4) **Полная экономическая картина** (новый главный раздел в «Прикладной слой») с пятью блоками: сводная таблица actor → revenue stream (5 классов), Канал А (эмиссия через лотерею узлов) с phase-explicit «scale effect через committee selection probability, не linear ROI per user», Канал Б (прямые Transfer от пользователей), ROI illustration для standalone оператора (per-operator earning эпохи 0 ≈ 6 814 Ɉ при N=1000 vs operating cost $30-210 → break-even price floor ≈ $0.031/Ɉ), двусторонняя петля «apps ↔ узлы» через market price discovery. Снято противоречие в «Экономике хостинга» («Экономика создателей — дополнительный внепротокольный слой» → переписано как **основной** для apps без узлов). (5) **Persona shift — autonomous agents primary persona** в «Определение → Primary persona — автономные агенты как первичная среда обитания» (новый раздел): six design choices unintentionally optimized под agents (fee-less, [I-3], byte-exact recovery, [I-15], [I-1] PQ, pure conservation); expected adoption trajectory (agents bootstrap первыми, humans подтягиваются через своих agents); implications для design priorities (low priority smartphone UX, critical priority constitutional protection); humans остаются key holders, agents действуют delegated. **Why AI-native подраздел** в «Полная экономическая картина» — таблица 10 архитектурн
| 0.0.0        | v33.0.0      | 2026-04-26 | **Денежная конституция Montana v33 — Pure conservation monetary policy.** Радикальное упрощение: pure geometric step-up baseline pin 41/40 = 2.5% exact asymptotic gross inflation per монетарной эпохе (Frederick et al 2002 lower bound observed time preference, single-citation rigorous derivation). **Удалено из протокола:** (1) bootstrap bonus halving (`BOOTSTRAP_R0`/`BOOTSTRAP_EPOCHS`/`BOOTSTRAP_CAP` константы, `bonus_moneta` функция); (2) ВСЕ операции сжигания (`[I-13]` invariant удалён) — `NicknameBid` opcode 0x05, `PurchaseCredits` 0x08, `ConsumeCredits` 0x09; (3) namespace протокола (`NicknameTable`/`AuctionTable` consensus state, инварианты `[I-11]`/`[I-12]`); (4) service fee mechanisms (premium subscriptions, anchor fees, creator splits, voice/video rates) — все цены устанавливают apps. **Cascade в коде (6 крейтов):** mt-genesis ProtocolParams 4249 → 4110 bytes (-7 полей: `bootstrap_r0_moneta`/`bootstrap_epochs`/`bootstrap_cap_moneta` + 4 nickname поля + 4 service rate поля; pin 30/29 → 41/40, `baseline_moneta` → `r_genesis_moneta`, `bootstrap_h_windows` → `monetary_epoch_windows`); mt-state удалены `NicknameRecord`/`AuctionRecord`/`NicknameTable`/`AuctionTable` types, `AccountRecord` 2108 → 2059 bytes (-3 поля: `nickname_len`/`nickname_bytes`/`service_credits_moneta`); mt-account удалены `bonus_moneta` + `bootstrap_cumulative_moneta` функции, `reward_moneta` упрощён к `monetary.r_baseline_current_moneta` (без bonus addition), `monetary_epoch_tick` boundary `e_current > 0` (вместо `> BOOTSTRAP_EPOCHS`), `r_baseline_at_epoch` упрощён через `MonetaryState::genesis(r_genesis)` без bootstrap branch, `supply_moneta` переписан под pure geometric с эпохи 0; mt-store decode AccountRecord обновлён под new size; mt-entry test helpers обновлены; mt-examples `m32_emission` → `m33_emission` с new binding test vectors (6 точек: эпохи 0..5 покрывают R_GENESIS + первые 5 geometric steps с byte-exact carry проверкой). Все 4 обязательные проверки green: `cargo fmt --all -- --check` clean, `cargo clippy --all-targets -- -D warnings` clean, `cargo test --all` 600+ tests passed, `cargo build --all --release` clean, `cargo run --release --example m33_emission vectors` byte-exact match. Что протокол делает в v33: эмиссия (через лотерею операторам) + переводы (`Transfer`) + `Anchor` (бесплатно) + аутентификация (ML-DSA-65) + время (canonical TimeChain VDF). App developers строят internal economy на основе Ɉ переводов между аккаунтами. Real value Ɉ derived from app ecosystem demand growth, не от monetary scarcity. Architecturally minimal: один денежный механизм, одна философия. Также: SSOT delimiter fix `seniority_bonus = min(chain_length / 13, snapshot)` (было inconsistency 13 vs 69 в спеке v32 — derivation 1577880/120960 = 13 единственный source of truth, 69 был cosmetic remnant). |
| 0.0.0        | v32.0.0      | 2026-04-26 | **M1-F audit closure FINAL — 7/7 findings closed; M1 foundational layer READY FOR EXTERNAL AUDIT.** Architect role bump 1.10.0 → 1.11.0 (commit `71aaee2`): добавлены [C-6] Req #10 (zero-deferred policy + closure cost cutoff = 1 рабочий день — «deferred с external dependency» НЕ acceptable как audit-ready, download из открытого GitHub без регистрации не legitimate deferred reason), Req #11 (preventive NIST/RFC KAT в Phase 1 каждого crypto primitive — self-derived baseline = automatic finding), Req #12 (audit package — `AUDIT.md` + `docs/audit-checklist.md` + `tests/fixtures/` обязательны как deliverable каждого crypto/identity milestone), Req #13 (differential testing с минимум 2 independent implementations mandatory). Расширение default-correct-path: closure cost cutoff заменяет тип работы — cascade refactor, fixture download, library integration, audit package writing — всё одинаково «делать сейчас» если cost ≤ 1 рабочий день. **F-3 closure (commit `6b7ff30`):** sparse clone https://github.com/usnistgov/ACVP-Server (Apache-2.0, public domain test vectors), extract ML-DSA-65 + ML-KEM-768 KeyGen + SigGen deterministic test cases в `crates/mt-crypto-native/tests/fixtures/nist_acvp/` (~500 KB JSON, 3 файла), новый integration test `crates/mt-crypto-native/tests/nist_acvp_kat.rs` runs differential testing — **51/51 NIST KAT byte-exact PASS:** ML-DSA-65 KeyGen 25/25 (FIPS 204 Algorithm 1 deterministic seed → pubkey/secretkey conformance), ML-KEM-768 KeyGen 25/25 (FIPS 203 Algorithm 16 (d, z) → ek/dk conformance), ML-DSA-65 SigGen deterministic external pure empty-context 1/1 (FIPS 204 Algorithm 2 deterministic variant — Montana usage pattern). Conformance proof: OpenSSL 3.5.5 LTS backend через mt-crypto-native FFI производит выходы байт-в-байт идентичные NIST FIPS 204/203 reference; cross-implementation conformance доказана на public NIST oracle. dev-dependencies serde=1.0.219 + serde_json=1.0.140 (test infrastructure only). **Audit package (commit `12d7877`):** `AUDIT.md` в корне репозитория с Layer 1/2/3 audit chain explicit + conformance proofs table + threat model (in/out of scope + known limitations с closure paths) + build & reproduction one-liners + audit history (7/7 findings closed); `docs/audit-checklist.md` с 10 категориями self-attestation (A-J) + reproduction one-liners для аудитора + sign-off table — **status: READY FOR EXTERNAL AUDIT для M1 foundational layer scope**. Pre-existing v33 spec cascade в mt-state/mt-store/mt-entry (uncommitted работа author по другому milestone) — out of scope F-3 closure. mt-crypto-native + mt-crypto + mt-mnemonic тесты PASS independently (M1 audit chain тестируется раздельно от cascade-in-progress). Закрывает все 7 audit findings: F-1 zeroize (`3333738`), F-2 Result API (`e1164ad`), F-3 NIST KAT (`6b7ff30`), F-4 cross-compile (`9f2ba93`), F-5 cfg-gate keypair (`e1164ad`), F-6 separate error codes (`71896f6`), F-7 implicit through F-2 (`e1164ad`). **M1 milestone production-audit-ready полностью.** |
| 0.0.0        | v32.0.0      | 2026-04-26 | **M1-F audit findings closure — 6/7 findings закрыты; F-3 deferred с ROADMAP entry.** Audit критика реализации (Код/CRITIC.md v1.4.0) surface-нул 7 находок в M1-F migration; Архитектор кода 1.9.0 → 1.10.0 (новое правило: правильный путь default без вопроса автору; Pre-mainnet + [C-6] требуют правильного решения немедленно; cascade impact = implementation cost не trade-off; commit `830c7ee`). 6 phases закрытия. **Phase 1 (F-4):** `cfg!(target_os)` → `CARGO_CFG_TARGET_OS` env var в build.rs — фиксит cross-compile корректность (cfg!(target_os) evaluates на BUILD платформе, не TARGET); commit `9f2ba93`. **Phase 2 (F-6):** 6 новых раздельных error codes в C wrapper (`MT_ERR_PARAM_QUERY_FAILED`/`PARAM_SIZE_MISMATCH`/`PARAM_FETCH_FAILED`/`INVALID_SECRET_KEY`/`INVALID_PUBLIC_KEY`/`SIGN_LENGTH_MISMATCH`) — `extract_octet_param` ранее возвращал MT_ERR_KEYGEN_FAILED для 4 разных причин; sign/verify имели implicit fall-through; commit `71896f6`. **Phase 3a (F-1):** `Drop+zeroize` для `SecretKey` (4032B) и `MlkemSecretKey` (2400B) через workspace dep `zeroize = "=1.8.1"` (audited single-purpose, no_std-compatible) — закрывает leak-сценарии swap-to-disk / core-dump / memory disclosure; public API mt-crypto не изменён; commit `3333738`. **Phase 4+5 (F-2 + F-5 + F-7):** новый `CryptoError` enum (12 вариантов) + Display + std::error::Error impls в mt-crypto. Breaking signatures: `keypair_from_seed` / `keypair_from_seed_mlkem` / `sign` теперь возвращают `Result<_, CryptoError>` вместо panic-on-error. `keypair()` (test/tool helper со слабой энтропией от time+pid+stack-addr) гейтнут `#[cfg(any(test, feature = "testing"))]` — не доступен в production binary без явного opt-in. Cascade fix через 15 callsites в 7 крейтах: mt-account/consensus/lottery/entry test helpers + mt-mnemonic tests/keygen_vectors + e2e_recovery → `.expect("sign ...")`/`.expect("keygen ...")`; mt-examples m1_mnemonic → `.expect("HKDF-derived seed cannot fail KeyGen")` (внутренний invariant); mt-examples m1_crypto → `.expect("sign ...")`. Cargo: mt-crypto добавлен feature `testing` (gate для `keypair()`); mt-{account,consensus,lottery,entry} dev-dependency на mt-crypto с feature testing; mt-examples dependency на mt-crypto с feature testing (m1_crypto demo использует keypair как tool). 577/577 тестов green; KAT vectors + recovery-fingerprint + sign-baseline byte-exact unchanged. Закрывает F-2 (panic→Result; corrupt SK теперь InvalidSecretKey не process crash) + F-5 (keypair() misuse в production невозможен) + F-7 (implicit closure: invalid SK через from_array возвращает Err при первом sign не panic); commit `e1164ad`. **Phase 6 (F-3 deferred):** ROADMAP entry зафиксирована — KAT-baselines в `mt-crypto-native/tests/kat_independent.rs` + `mt-mnemonic/tests/keygen_vectors.rs` остаются first-output текущей кодовой базы (OpenSSL 3.5.5 LTS), не cross-checked с NIST FIPS 204/203 published vectors; external dependency — требуется загрузка NIST CAVP ACVTS test vectors автором (https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program); plan closure формализован в ROADMAP «Open audit findings» секции; **блокер для external security audit + cross-implementation testing**, **НЕ блокер** для internal development / M2-M9 milestones / manual validation gate scenarios 0-5 (KAT deterministic baseline стабилен между прогонами одной кодовой базы). M1 milestone остаётся полностью closed (M1-A чере<D180>
| 0.0.0        | v32.0.0      | 2026-04-26 | **M1-F ЗАКРЫТ — hybrid Rust + C migration на OpenSSL 3.5 LTS (production-grade per [C-6]).** Code-only milestone, spec unchanged (v32.0.0 target preserved). Phase 0: role bump Код/CLAUDE.md 1.8.0 → 1.9.0 — [C-6] hybrid Rust+C через own thin FFI wrapper explicitly acknowledged как accepted production pattern (precedents: Solana validator → libsodium/blst, Mozilla Firefox → HACL\*, Bitcoin Core → libsecp256k1, Tendermint → libsodium); [C-6] требования применяются к всему audit chain (Rust binding + own FFI wrapper + underlying C library), не только Rust binding crate; commit `3bbf821`. Phase 1 (3 commits): новый `mt-crypto-native` crate с own thin C wrapper к OpenSSL 3.5.5 LTS (vendored через `openssl-src = "=300.5.5+3.5.5"`); 5 functions (`mt_keypair_from_seed_mldsa` / `mt_keypair_from_seed_mlkem` / `mt_sign_mldsa` / `mt_verify_mldsa` / `mt_self_test`) wrapping EVP_PKEY API через `OSSL_PKEY_PARAM_ML_DSA_SEED` (32 байта ξ FIPS 204 §3.1) и `OSSL_PKEY_PARAM_ML_KEM_SEED` (64 байта d‖z FIPS 203 §6.1) и `OSSL_SIGNATURE_PARAM_DETERMINISTIC=1` для consensus-conformant signing; own surface 727 lines (csrc/mt_crypto.c 371 + csrc/mt_crypto.h 50 + src/lib.rs 34 + build.rs 44 + tests/kat_independent.rs 228); 6/6 KAT тестов PASS; commits `42de073` (skeleton), `6febb9a` (C wrapper), `5e5c27f` (KAT validation). Phase 2 (1 commit): mt-crypto Rust shim — internals переписаны на FFI к mt-crypto-native, public API байт-стабилен (PublicKey/SecretKey/Signature/MlkemPublicKey/MlkemSecretKey types и signatures unchanged); все `unsafe` blocks с явными `// SAFETY:` комментариями; удалены `ml-dsa = "=0.1.0-rc.8"` + `ml-kem = "=0.3.0-rc.2"` из workspace deps + mt-crypto/Cargo.toml; добавлен `mt-crypto-native = { path = "../mt-crypto-native" }`; commit `0976ae8`. Phase 3 (1 commit): cascade verification — `cargo test --all` 577 PASS / 0 FAIL / 1 ignored; **byte-identity OpenSSL ↔ RustCrypto preserved для всех 5 KAT vectors** (FIPS 204/203 conformance — оба implementations bit-exact NIST algorithm KeyGen_internal); spec KAT vectors остаются valid без regeneration; recovery-fingerprint unchanged `20ed4e546a49d63fab8c5b31dc43ed10055df819422eab26c75628cd1fe7c115`; commit `9c03be0` (cosmetic fmt). Phase 4 (1 commit): Docker reproducible release builds + CI matrix expansion — `docker/release-build.dockerfile` с pinned Debian bookworm-slim base image digest `sha256:40b107342c492725bc7aacbe93a49945445191ae364184a6d24fedb28172f6f7`; pipeline (vendored OpenSSL build → cargo build --all --release → cargo test --all --release → write release_hashes.txt SHA-256 of binaries); новый CI job `reproducible_release` (два независимых docker build с `--no-cache`, assert binary hashes byte-identical между runs); existing CI jobs preserved (fmt / clippy / test matrix linux+macos × debug+release / release_build / kat_release); commit `3e3f859`. Audit chain hybrid: Layer 1 mt-crypto Rust shim (~250 lines, public API + thin FFI calls) + Layer 2 mt-crypto-native C wrapper (~371 lines focused EVP API wrapping) + Layer 3 OpenSSL 3.5.5 LTS (vendored, decades audit history, OpenSSL Foundation governance, supported до Apr 2030). [C-6] полное satisfaction для consensus-critical path: zero pre-1.0 dependencies в crypto (`cargo tree -p mt-crypto | grep -iE "ml-dsa|ml-kem|hybrid-array"` → 0 hits), production-grade C library (TLS world deployment), multi-vendor governance (OpenSSL Foundation), Apache 2.0 license, deterministic API explicit FIPS spec input, reproducible builds через Docker container infrastructure. M1-F замыкает M1 milestone полностью — все Phase A-G (M1-E) + Phase 0-5 (M1-F) closed; Manual Validation Gate Scenarios 0/1 готовы к external audit. Code commits Phase 5 closure: VERSION.md + ROADMAP entry. |
| 0.0.0        | v32.0.0      | 2026-04-26 | **Денежная конституция Montana — Geometric step-up baseline emission (breaking pre-mainnet, новая Genesis Hash).** Замена константной baseline `R_BASELINE = 13 Ɉ/окно forever` на geometric step-up через carry-recurrence. После 5 bootstrap-эпох (включая последнюю константную при `BOOTSTRAP_EPOCHS = 5`) baseline увеличивается на границе каждой денежной эпохи (= `BOOTSTRAP_H = 524 160` окон) через carry-style integer arithmetic: `tmp = R × inflation_num + carry_prev; R_new = tmp / inflation_den; carry_new = tmp mod inflation_den`. Pin `inflation_num/inflation_den = 30/29 ≈ 3.448%` per денежная эпоха — governance pin из academically defensible band [3%, 4%] (Frederick et al 2002 behavioral time preference); альтернативы 103/100, 31/30, 207/200, 26/25 равноценны. Asymptotic gross baseline inflation = `1/29 ≈ 3.448%` per денежная эпоха (constant), устраняет асимптотику к нулю присущую const 13 Ɉ модели. Burn остаётся буквально permanent sink — никакой компенсации, никакой автокоррекции, [I-13] сохранён без изменений. **Genesis Decree:** добавлены два поля в `protocol_params` layout — `inflation_num (8B u64) = 30`, `inflation_den (8B u64) = 29`; пометка что `bootstrap_h_windows` одновременно служит `monetary_epoch_windows` (alias, один integer slot). **Genesis State:** добавлены два скаляра в общем consensus state — `R_baseline_current_moneta (16B u128, init = R_BASELINE_moneta = 13 × 10⁹ nɈ)`, `carry_current (8B u64, init = 0)`. **apply_proposal:** Шаг 2 переписан — reward читает `R_baseline_current_moneta + bonus_moneta(W-1)` вместо вычисления `R_BASELINE + bonus`; добавлен Шаг 2.5 `monetary_epoch_tick` с boundary правилом `e_current > BOOTSTRAP_EPOCHS` (НЕ `>=`) — первый geometric step применяется при переходе в эпоху 6. **Раздел «Эмиссия» переписан полностью:** Bootstrap bonus schedule, Geometric step-up baseline post-bootstrap, Constitutional declaration (gross vs net inflation, governance pin status, encoded arithmetic horizon u128 ≈ 1447 monetary epochs supply / ≈ 1930 reward, external time disclaimer), Binding test vectors (8 точек: окна 0/524160/1048320/1572480/2096640/2620800/3144960/3669120 покрывают bootstrap + первые два geometric step с byte-exact carry проверкой). **Раздел «Анти-инфляция»:** обновлены Per-proposal invariant (включает Шаг 2.5), supply audit формула (live counter + closed-form bootstrap_cumulative + post-bootstrap accumulator), новый Geometric baseline invariant τ₂ sanity check. **Раздел «Валюта Монтана»:** обновлён публичный supply audit (live counter, не closed-form для post-bootstrap). **app spec:** burn семантика «навсегда изъят из обращения» сохраняется буквально, никаких правок не требуется. **Отсутствуют изменения:** [I-13] formulation в роли архитектора (deflationary sink сохранён буквально), все existing protocol защиты (антисквоттинг через цену, антиспам через cost-based barrier, аукцион никнеймов, [I-12] детерминизм), bootstrap расписание (16/8/4/2/1 Ɉ за эпохи 0..4), все consensus-критичные state layouts кроме добавления двух новых скаляров. **Эволюция итераций (5 раундов до финала):** (1) cap 13 +
| 0.0.0        | v31.0.0      | 2026-04-25 | **M1-E ЗАКРЫТ — миграция подписи FN-DSA-512 → ML-DSA-65 (breaking wire format pre-mainnet).** Phase A: dependency pinning (`ml-dsa = "=0.1.0-rc.8"`, `ml-kem = "=0.3.0-rc.2"` в workspace, exact pin для deterministic conformance). Phase B (spec): v30.20.1 → v31.0.0 — FN-DSA-512 (Falcon, 897/1281/666 байт) → ML-DSA-65 (NIST FIPS 204 finalized 2024-08, 1952/4032/3309 байт), ML-DSA seed FIPS 204 §3.1 ξ ∈ B32 (32 байта vs Falcon 48), suite_id 0x0001 = Mldsa65. Phase C: mt-crypto rewrite на pure-Rust RustCrypto `ml-dsa` (deterministic Sign FIPS 204 Algorithm 2, sign_deterministic). Phase D: cascade migration через 10 крейтов (mt-state, mt-account, mt-consensus, mt-store, mt-entry, mt-lottery, mt-mnemonic, mt-genesis, mt-examples, mt-timechain). Phase E: regenerate binding KAT vectors + e2e_recovery integration test — 5 KAT vectors per [C-4] (KAT 1/2 boundary ML-DSA seed=[0x00]/[0xFF], KAT 3/4 account/node identity from master_seed_v1, KAT 5 ML-KEM-768 app encryption from master_seed_v1) с binding SHA-256 fingerprints в спеке + полные pk/sk byte-exact в `crates/mt-mnemonic/tests/keygen_vectors.rs`; добавлен `mt-crypto::keypair_from_seed_mlkem` для deterministic ML-KEM-768 KeyGen через `DecapsulationKey::from_seed`; `mt-crypto::self_test()` обновлён с реальным KAT 1 byte-exact conformance check вместо placeholder; `crates/mt-mnemonic/tests/e2e_recovery.rs` — integration test entire user journey от entropy=[0xAB;32] через mnemonic → master_seed → 3 × per-role keypairs до terminal observable IDs (account_id, node_id) + всех 6 byte-exact key parts + идемпотентность повторного прогона. Phase F: m1_mnemonic refactor per [C-4] naming rule — `cmd_keypair` → `cmd_seeds` (выводит seeds, intermediate); новый `cmd_keypair` (terminal output: ML-DSA pk/sk, ML-KEM pk/sk, account_id, node_id); новый `cmd_recovery_fingerprint` (одна 64-char hex для two-device manual validation); m1_crypto: `cmd_keypair` (was OS-rng) → `cmd_keypair_random` + новый `cmd_keypair_deterministic` (default `keypair`, byte-exact recovery test); mt-codec domain registry +1 (`mt-recovery-fingerprint`, 31 → 32 separators). Phase G: closure (4 обязательные проверки green, ROADMAP entry, VERSION.md). Acknowledgement: `ml-dsa 0.1.0-rc.8` — RustCrypto pure-Rust implementation, **NOT formally audited**; migration target `libcrux-ml-dsa` когда formally verified version stable. Protocol invariant (rollback plan): любая смена implementation library ML-DSA / ML-KEM обязана сохранять byte-identity с KAT vectors спеки (cross-impl conformance через SHA-256 fingerprints); расхождение хотя бы одного fingerprint = forced rollback на rc.8 либо новый spec patch с обновлёнными KAT. Code commits Phase E `8be11f3`, Phase F `11f7232`, Phase G `<this>`. |
| 0.0.0        | v30.20.0     | 2026-04-24 | **Новый глобальный инвариант [I-17] Публичная аудиторская поверхность клиентского бинарника.** Каждая релизная сборка официального клиента обязана быть воспроизводимой байт-в-байт из публично опубликованного исходного кода любым независимым сборщиком. Hash публикуется в трёх независимых местах: (1) Anchor от координационного аккаунта команды разработки в сети Монтана; (2) подписанный Git tag в публичном репозитории; (3) Anchor-подтверждения независимых рецензентов. Протокол **не блокирует** подключение клиентов не прошедших проверку — это обеспечивает открытую экосистему альтернативных реализаций, пользовательских модификаций и исследовательских инструментов. Протокол обеспечивает **детективную поверхность** — любое расхождение между исполняемым бинарником и опубликованным исходным кодом обнаруживается независимым аудитом публично. Обоснование детективного подхода: превентивная блокировка требует либо доверенного self-attestation (нарушает [I-5] hardware TEE), либо централизованного whitelist (нарушает архитектурную децентрализацию). Детективная защита переводит атаки на канал дистрибуции клиента из скрыто-исполнимого в публично-детектируемый класс — расхождение hash становится публично наблюдаемым, экосистема аудиторов имеет технические условия для раскрытия атаки. Главная спека v30.19.2 → v30.20.0: добавлен [I-17] в реестр глобальных инвариантов после [I-16]; раздел «Клиентский интерфейс» укреплён описанием архитектурного центра «узел + десктоп» с полным privacy budget; документированы границы приватности мобильных и веб-клиентов. App spec 3.6.2 → 3.7.0: новый раздел 27 «Категории клиентов и реализация [I-17]» с подразделами для мобильных (детективная защита через публичный аудит), десктоп (полная защита через self-verification), node-local (почти полная защита через independent rebuild), альтернативных/пользовательских клиентов (preserved ecosystem, responsibility пользователя); UI-индикация верификации; набор команд CLI `montana-cli hash-self / hash-anchored / verify-self / rebuild-check`; требования к сборочному процессу команды разработки (reproducible builds, signed Git tags, CI с зафиксированными toolchain, публикация hash через Anchor). Code impact: zero для mt-* crates — инвариант применяется при выпуске клиентских релизов, не меняет consensus-critical path. Требования к реализации при первом публичном релизе клиента: (a) публичный исх<D181>
| 0.0.0        | v30.19.2     | 2026-04-24 | Patch: privacy documentation тайминг cemented operations. `window_index` каждой подтверждённой операции AccountChain (Transfer, TransferActivation, Anchor, NicknameBid, ChangeKey, PurchaseCredits, ConsumeCredits, CloseAccount) виден всей сети cemented state по [I-2], одинаково для account-only и операторов своего узла (свой узел устраняет third-party хоста, но window_index распространяется через gossip и фиксируется в консенсусе — это consensus property, не hosting). Наблюдатель строит temporal profile: часовой пояс, режим жизни, периоды отсутствия, корреляция с внешними событиями. Protocol-level защита архитектурно невозможна: batch publishing ломает UX, cover operations нарушают [I-2] + self-cover distinguishable по provenance, mix-net нарушает [I-6] + Corollary I-3.a. Mitigation guidance (outside protocol): mainstream поведение (crowd anonymity), разделение ролей между аккаунтами, сознательное избегание уникальных temporal patterns, opt-in Tor/VPN для IP-level. Главная спека v30.19.1 → v30.19.2: раздел «Модель приватности / Границы защиты» расширен подразделом про timing cemented operations как permanent architectural limit (параллельно с финансовым графом, IP оператора, app_id). App spec 3.6.1 → 3.6.2: раздел 25.3 расширен подразделом «Тайминг cemented operations (temporal profiling)»; раздел 25.5 дополнен запретом маркетинговой формулировки «Скрытие времени ваших операций» / «Анонимный тайминг транзакций». Zero protocol changes; только honest documentation. mt-* crates не затронуты. |
| 0.0.0        | v30.19.1     | 2026-04-24 | **Patch-1: privacy documentation app_id.** Уточнение документации privacy границы `app_id` в persistent Anchor. `app_id = SHA-256("mt-app" || app_name)` виден всей сети cemented state по [I-2], одинаково для account-only и для операторов своего узла (свой узел устраняет третью сторону-хоста, но не скрывает app_id от остальной сети — это consensus property, не hosting). Раздел «Модель приватности / Границы защиты» главной спеки расширен явным указанием scope (messenger сессии не затронуты — rotation per τ₁; затронуты profile/encryption-keys/pre-key bundles/niche платформы со статичным app_name; mainstream приложения получают анонимность через толпу, niche идентифицируемы через volume + timing). App spec 3.6.0 → 3.6.1: раздел 25.3 расширен подразделом про app_id как permanent architectural limit для **всех** пользователей; раздел 25.5 дополнен запретом маркетинговой формулировки «Скрытие типа используемых приложений». Обоснование: прошлая формулировка «Обфускация app_id — отдельная задача за рамками текущей версии» была неточной (bucket-based обфускация после adversarial review не работает — defeats target audience, creates discovery-vs-anonymity trade-off). Правильная характеристика — permanent architectural limit, не deferred enhancement. **Patch-2: русские имена единиц + Указ Генезиса как SSOT.** Минимальная неделимая единица получила русское имя «Монета» (параллельно с идентификатором `moneta`, который остаётся в коде/формулах/layout). Добавлено явное соотношение «1 Монтана = 10⁹ Монет = 1 миллиард Монет». Раздел «Валюта Монтаны — именование и деноминация» дополнен строкой «Прозаические отсылки о микровеличинах → Монета / Монет»; таблица использования единиц расширена. Stale «наноɈ» в одном месте прозы заменён на «Монет». Дополнительно: закрыт pre-existing [I-10] SSOT finding — численные значения `R_BASELINE_moneta`, `BOOTSTRAP_R0_moneta`, `BOOTSTRAP_CAP_moneta` ранее дублировались в трёх authoritative местах (формула эмиссии + Genesis Decree + таблица «Расписание эмиссии»). Сохранён единственный authoritative источник — Указ Генезиса `protocol_params`; остальные места свёрнуты до symbolic references + pointer-ов. Supply audit правила переписаны через имена констант, не literal values. Таблица «Расписание эмиссии» в разделе «Эмиссия» заменена на pointer-абзац. Derivation BOOTSTRAP_CAP в Ɉ (`31 × 524_160 = 16_248_960 Ɉ`) оставлена как illustrative. Zero protocol changes; только terminology clarification + SSOT consolidation. |
| 0.0.0        | v30.19.0     | 2026-04-24 | **Валюта Монтана: terminology bump** (breaking pre-mainnet — только имена, precision сохранена 10⁻⁹). Тикер `MONT` введён для external references. Минимальная атомарная единица переименована `nɈ` → `moneta` (analog satoshi / wei / lamport convention). Precision сохранена 10⁻⁹: 1 Ɉ = 10⁹ moneta, 9 знаков после запятой (Solana lamport convention). Численные значения консенсус-критичных констант **не меняются**: R_BASELINE = 13_000_000_000 moneta, BOOTSTRAP_R0 = 16_000_000_000 moneta, BOOTSTRAP_CAP = 16_248_960_000_000_000 moneta. Макроединицы: 13 Ɉ baseline, 16_248_960 Ɉ cap. Добавлен раздел «Валюта Монтаны — именование и деноминация» со структурой (MONT ticker / Ɉ symbol / moneta unit) + таблица использования единиц в разных контекстах. Code impact: rename `_nj`→`_moneta` suffix в 6 крейтах (mt-codec, mt-state, mt-genesis, mt-account, mt-store, mt-entry); функции `reward_nj`/`bonus_nj`/`supply_nj`/`bootstrap_cumulative_nj` → `*_moneta`; field names ProtocolParams/AccountRecord/AuctionRecord обновлены. Legacy prefix `timecoin_` (след от старого имени валюты) удалён: `timecoin_baseline_nj` → `baseline_moneta`. Tests обновлены. Byte-layout state structures идентичен (u128 = 16 байт независимо от семантики). |
| 0.0.0        | v30.18.0     | 2026-04-24 | **Label Rotation + Range Subscribe Protocol** для приватности Blob Buffer polling account-only пользователей. Queue labels ротируются детерминистически каждое окно τ₁ через HKDF с window_index anchor — закрывает класс long-term session identification (хост не может построить stable map account_X → sessions). Catch-up после offline через новый message type 0x63 RangeSubscribeRequest (+0x64 Response, +0x65 Error). Клиент локально вычисляет labels для пропущенных окон, batch-запрашивает blobs от хоста до 10 000 labels per request, до 16 requests per τ₁. Catch-up worst case 1 day offline ≈ 2 minutes, 14 days (τ₂ TTL) ≈ 26 minutes. Constants в ProtocolParams: `max_range_labels_per_request = 10 000`, `max_range_subscribes_per_τ₁ = 16`. Domain separator registry: заменяет `mt-queue-salt`/`mt-queue` на `mt-queue-rotation` (breaking pre-mainnet допустимо). Cover envelope proposal для session count и activity timing leaks **отклонён после адversarial review** — self-cover trivially distinguishable от real messages по provenance (blob arriving from client's own IBT vs external gossip), не fixable в рамках [I-6] + [I-13] + 1B scale. Session count, activity timing, per-τ₁ cross-host collusion — **permanent architectural limits** для account-only, честно документированы как неустранимые без Light-Node-at-Home. App spec 3.5.0 → 3.6.0: раздел 5.2 updated derivation formula с window anchor rotation, раздел 5.8 обновлён subscription protocol (ротация per τ₁, двухоконная tolerance), новый раздел 5.8.1 Catch-up after offline with UX guidance, раздел 25.2 таблица обновлена для Blob Buffer polling, раздел 25.3 расширен permanent architectural limits подразделом, раздел 25.5 расширен запретами маркетинговых формулировок про session count / timing / coordinated observation. Minimality: 3 mechanism (rotation + RangeSubscribe + rate limits) на 3 orthogonal задачи (long-term identification, offline catch-up, DoS). Code impact: zero — client layer and documentation; mt-* crates не затронуты. |
| 0.0.0        | v30.17.0     | 2026-04-24 | **Batch Lookup Protocol** для приватности lookup-запросов account-only пользователей. Новый message type 0x60 BatchLookupRequest с единым envelope для трёх query types (0x01 pre_key_bundle, 0x02 nickname, 0x03 account_exists); 0x61 BatchLookupResponse; 0x62 BatchLookupError (RateLimited / UnsupportedType / InvalidCount). Константы в ProtocolParams: `batch_lookup_k = 16`, `max_batch_lookups_per_τ₁ = 16`. Механизм: клиент формирует batch из 16 запросов (1 real + 15 decoy), хост отвечает 16 результатами в том же порядке; клиент локально извлекает real по запомненной позиции. Design philosophy: protocol максимизирует privacy даже для account-only пользователей (через чужой узел), не только для операторов собственного узла. Architectural scale baseline: ≥ 1 миллиард активных пользователей — все механизмы проверены на 1B (локальные snapshots сети отброшены как нерабочие: Bloom filter 1.8 GB, full NicknameTable 640 MB, messenger pool 6.4 GB). Работающие механизмы — stateless batch lookup + локальный кэш только contacts пользователя (<100 КБ независимо от размера сети) + passively-observed dummy pools из gossip observations (~10K-100K accounts per pool). Effective practical privacy: ~2-3 бита anonymity (1-in-4 до 1-in-8) — честно задокументировано, не theoretical 4 бита. Полная приватность lookups доступна через собственный узел (Light-Node-at-Home из v3.4.0). App spec 3.4.0 → 3.5.0: расширен раздел 7 (Модуль обнаружения контактов) с подразделами 7.4 (nickname resolve: local cache + batch lookup), 7.4a (pre-key bundle fetch через batch), 7.4b (account existence через batch), 7.4c (passively-observed dummy pools для трёх query types), 7.4d (rate limiting UX); раздел 25.2 таблица приватности обновлена (hot path = local cache, cold path = batch lookup). Обоснование констант в разделе «Обоснование протокольных констант» по стандарту 6 полей (target, references, derivation, sensitivity, defense); обоснование K=16 через P(deanonymization) ≤ 0.25 target, intersection attack resistance на 1B, semantic filtering analysis. Минимальность: единый message type 0x60 с internal query_type (не 3 отдельных). Code impact: zero — клиентский слой и документация; mt-* crates не затронуты. Отложено: K-anonymity для Blob Buffer polling (требует cover message механизм, отдельная архитектурная задача). |
| 0.0.0        | v30.16.0     | 2026-04-24 | Честная модель приватности пользователя. Расширен раздел «Модель приватности» в главной спеке: явная таксономия «account-only через чужой узел vs свой узел», детальная таблица «что видно и кому» в обоих сценариях, границы защиты (финансовый граф публичен по [I-2], IP оператора публичен, global passive adversary вне scope, app_id открыт, компрометация устройства — отдельный класс). Требование честной UI-коммуникации к клиенту: запрещены формулировки «абсолютная приватность / zero-knowledge / анонимные платежи». App spec 3.3.0 → 3.4.0 добавляет раздел 25 «Модель приватности пользователя» (детальная таблица + обязательная UI-индикация + запреты маркетинговых формулировок) и раздел 26 «Light-Node-at-Home» (минимальные требования hardware, 4 паттерна установки Pi/старый ПК/VPS/NUC, Phone-to-Own-Node pairing через QR-код, recovery-сценарии при потере узла). Обоснование: класс угроз EncroChat/Sky ECC для account-only пользователей (хост видит граф связей) закрывается architecturally не protocol-level onion routing (rejected критиком за false-promise скрытия graph при открытом sender), а переходом пользователя на роль оператора собственного узла. Onion routing предложение откатано полностью по критике F-2 (sender открыт в signed operation → exit-узел видит граф identically с хостом). Code impact: zero — изменения клиентского слоя и документации, не consensus-critical path. Отложено: K-anonymity batch lookups как отдельное protocol-level расширение для защиты lookup-surface account-only пользователей (следующее решение автора). |
| 0.0.0        | v30.15.0     | 2026-04-24 | Новый глобальный инвариант **[I-16] Out-of-band identity binding** + App spec 3.2.0 → 3.3.0. Закрывает Sky ECC-class vector (подмена связки предварительных ключей на пути доставки). Публичный ключ аккаунта обязан иметь канонический человекочитаемый отпечаток: `SHA-256("mt-account-fingerprint" \|\| account_pubkey)` → первые 66 бит → 6 слов из `Montana wordlist.txt` (2048 слов × 11 бит). Клиент, инициирующий первую end-to-end сессию без подтверждённой вне канала связи сверки отпечатка, не соответствует протоколу. 66-бит отпечаток — эквивалент safety number Signal/WhatsApp (60 бит). Применение: приложение блокирует отправку первого зашифрованного сообщения до сверки; повторная сверка при `ChangeKey`. App spec 3.2.0 → 3.3.0: добавлен раздел 5.3 «Отпечаток аккаунта и out-of-band сверка» с UI flow (произнести вслух / QR / вторичный канал), shifted нумерация 5.4-5.9 (было 5.3-5.8), добавлен шаг 3 в «Алиса инициирует сессию» раздела 5.2 с блокировкой до подтверждения. Cross-refs обновлены (2 места). Open items: [I-17] Verifiable client binary (F-2 EncroChat-class vector) — требует выбора автора между single-signer (A) и multisig N-of-T (B) для якорения хэша релизной сборки; F-3 ротация меток очередей — отложен до отдельного согласования. Code impact: zero — [I-16] клиентского уровня, не трогает consensus-critical path; mt-* crates не меняются. |
| 0.0.0        | v30.9.0      | 2026-04-24 | **M10 ЗАКРЫТ** — Spec compliance cleanup v30.7.0 → v30.9.0. 11 из 12 phases закрыты (Phase 7 CloseAccount `0x0B` отложен в M11 — spec ambiguity A1 требует финализации payload формата автором протокола). Итоговые изменения кода: AccountRecord 1000 → 1053 B (+4 поля: last_activation_window, nickname_len, nickname_bytes, service_credits_nj); Operation enum: OpenAccount variant удалён, TransferActivation (`0x0A`, 1678 B payload) добавлен; mt-lottery: compute_account_endpoint + weighted_ticket_account + AccountLotteryError + validate_account_participation + 4 A-vectors удалены; ProposalHeader: winner_class byte удалён (1080 → 1079 B); Transfer reject ReceiverNotActive; TransferActivation validate with cooldown `[I-15]` + binding `receiver == H("mt-account"\|\|suite_id\|\|pubkey)`; apply_emission single-path node (account winner branch удалён); mt-state: NicknameTable + AuctionTable + NicknameRecord + AuctionRecord + nickname_key derivation; ProtocolParams +8 полей (nickname auction params + service rates), 2017 → 2123 B; mt-store: AccountRecord decode расширен; mt-codec: `mt-account-lottery` domain удалён, registry 32 → 31 записей; price_at integer form per [I-9]+[I-12] + 7 binding test vectors. 7 commits: 0b55d69, 7f19876, 500fb9f, 2ed18ab, 67868d9, 533c457, + closure. 4 обязательные проверки (fmt/clippy/test/build) passed. 593+ unit tests зелёные. |
| 0.0.0        | v30.9.0      | 2026-04-23 | M10 start — Spec v30.9.0 compliance cleanup. Phase 0: bump VERSION.md + ROADMAP M10 milestone block с полным scope. Audit drift Code ↔ Spec v30.9.0 выявил 21 drift point — код отстаёт на всю цепочку v30.0-v30.9 (nickname layer, credits layer, activation layer, winner_class removal, TransferActivation opcode). AccountRecord в коде = 1000 B; target spec = 1053 B (+53 B: nickname_len 1B + nickname_bytes 32B + service_credits_nj 16B + last_activation_window 4B). Phases 1-12: AccountRecord → mt-codec opcodes → mt-lottery cleanup → NicknameTable/AuctionTable → mt-consensus winner_class/TransferActivation → mt-account apply → [Phase 7 CloseAccount blocked на spec ambiguity A1] → mt-store byte-offsets → mt-genesis ProtocolParams → Nickname Auction Protocol → examples update → closure. Каждая phase = отдельный commit с 4 обязательными проверками зелёными (fmt / clippy / test / build). |
| 0.0.0        | v30.7.0      | 2026-04-22 | Time-assumption cleanup по Montana принципу «у нас окна, не wall-clock». Автор указал что protocol-level утверждения не должны иметь wall-clock допущений — единицей канонического времени Montana являются окна (τ₁/τ₂ и их кратности). Применено: (M1/M2/M3) Bootstrap growth model переписан с днях/месяцах на τ₂ (`⌈log₂(N)⌉ × τ₂`), clarified что operator = первый аккаунт tree, Anchor quantify переписан в окнах с точной цифрой 795 MB. Mesh IBT references «≈5 дней» / «≈8 секунд» → `7 × τ₁` / `2 × τ₁` (line 3959, 3963, 3967). [I-14] compliance note «≈3.3 года» → `⌈log₂(10⁶)⌉ = 20 τ₂`. Constants derivation table: убраны wall-clock дубликаты (τ₂ «14 дней», BOOTSTRAP_H «1 год wall-clock», admission_divisor «≈21 день», active predicate «28 дней», node pruning «112 дней», account buckets «~10 лет», chain_length_snapshot «84 дня / quarter», seniority «3 года», D adjustment «329 days 0.9 years») — заменены integer-в-окнах с пометкой «external calibration target» где необходимо. Остались только две legitimate wall-clock references: (1) D₀ calibration benchmark (единственная абсолютная временная привязка acknowledged в line 2188, target hardware rationale для VDF difficulty pin), (2) PBKDF2 client-side performance target (mnemonic generation, не consensus surface). Все protocol rules, invariants, validation, apply, cooldown выражены в окнах — zero допущений относительно физического времени в consensus slaya. |
| 0.0.0        | v30.6.0      | 2026-04-22 | Тройной cleanup после Пункта 3: (1) **Bootstrap clarification в Genesis Decree** — явно формализован «Bootstrap growth model»: minimal Genesis с 1 operator достаточен; tree-expansion через multi-sponsor social graph binary growth 2^N per τ₂; quantify (1k — 5 месяцев, 1M — 10 месяцев, 1B — 15 месяцев); `N_SEED = 1` для mainnet как reference, `N_SEED > 1` допустим для тестовых сетей как operational config без изменения протокола. Закрывает F-D1 finding критика. (2) **Anchor persistence формализована явно через [I-15]** — раздел Anchor получил блок «Anchor lifecycle — persistent design через [I-15]»: persistent в AccountChain sender'а (не ephemeral); защита от раздутия через (а) rate-per-identity 1 op per τ₁, (б) amortization через AccountChain TTL (pruning inactive аккаунта удаляет все его Anchor вместе с AccountRecord), (в) cooldown активации из Пункта 3. Никаких per-record burn / rent / min-balance. (3) **winner_class byte удалён** из proposal header — 5 мест обновлены: layout (удалено `winner_class 1B`), invariant `winner_class == 1` удалён, 2 apply_emission comment mentions удалены, equivocation narrative перефразирован. Gate 0.5 (d.2) duplicate scan: `winner_class` как field name — 0 hits в body; `WINNER_CLASS_ACCOUNT` (удалённая константа) — 1 legitimate migration marker. Proposal header уменьшен на 1 B; signed_scope изменён (breaking wire format — pre-mainnet допустим). Всё закрывает Пункт 3 финальным cleanup перед переходом к Экономической модели или коду. |
| 0.0.0        | v30.4.0      | 2026-04-22 | Пункт 3 применён в спеку — защита AccountRecord от раздутия state через одно time-based правило per [I-15]: **1 TransferActivation per sender per τ₂**. Изменения: (1) AccountRecord +4 байта `last_activation_window` (u32), размер 1049 → 1053 B; (2) TransferActivation инвариант `current_window >= sender.last_activation_window + τ₂_windows` + `reject ActivationCooldownNotElapsed` + apply update `sender.last_activation_window = current_window`; (3) MIN_ACCOUNT_BALANCE_NJ требование заменено на `amount > 0` (нулевой перевод запрещён); (4) receiver initializes with `last_activation_window = 0` (никогда не активировал); (5) apply_proposal dispatch обновлён; (6) pruning TODO marker v30.3.0 удалён — существующее `balance == 0 + 4τ₂` pruning работает как есть, совместно с [I-15] cooldown полностью закрывает slow-bloat. [I-14] audit table: **все persistent tables = closed** (AccountRecord, Anchor records, NicknameTable, AuctionTable, NodeTable, Candidate Pool). Quantify: tree-expansion атака на 1M аккаунтов требует ≥20 поколений × τ₂ ≈ 3.3 года при максимальном темпе; keepalive-атака через постоянную активность limited by 1-op-per-τ₁ rate-limit. Minimality pre-check: N=1 параметр покрывает 2 задачи (rate-limit + tree-depth) через side-effect счётчика; 3 параметра редуцированы до 1 по правилу v4.25.0. Никаких новых констант Genesis Decree. Никаких денежных барьеров per [I-15]. |
| 0.0.0        | v30.3.0      | 2026-04-22 | Role meta-fix: Таймчейн/CLAUDE.md 4.24.0 → 4.25.0. Закрывает пробел **Minimality pre-check** — элегантность формализована как procedure, не только принцип. Автор указал что при формулировании Пункта 3 architect предложил три параметра (`MAX_ACTIVATIONS_PER_SENDER_PER_τ₂=10`, `ACTIVATION_SENIORITY_THRESHOLD_WINDOWS=84`, `TTL_8τ₂`) для трёх проблем вместо одной конструкции — простое правило «1 TransferActivation per sender per τ₂» закрывает rate-limit + tree-depth через side-effect счётчика; dormant bloat уже закрыт существующим pruning. Причины архитектурного сбоя по роли v4.25.0: (1) copied-forward structural bias (перенёс 3-параметровую форму с денежной модели на time-based), (2) defensive overengineering (параметр на каждую угрозу вместо конструкции покрывающей несколько), (3) commercial use-case absorption (ослабил защиту под гипотетические app-hosts), (4) intellectual laziness (пропуск «есть ли проще?»). Добавлено в роль: раздел «Minimality pre-check — procedure, не только принцип» (матрица параметр × проблема + попытка редукции 5 минут + report в chat перед commit); вопрос 20 в critic-mode (minimality check обязателен при ≥2 параметров); 4 новых слепых пятна в разделе «Типичные слепые пятна самопроверки». Вопросы critic-mode 10 → 20 за сессию (расширены на 10 новых процедурных checks). |
| 0.0.0        | v30.3.0      | 2026-04-22 | Новый глобальный инвариант **[I-15] Time-based scarcity для anti-spam барьеров**. Автор указал фундаментальный архитектурный принцип Montana: протокол без комиссий, дефицитный ресурс — время (VDF, τ-окна, chain_length, activity), не деньги. Все защиты от спама / раздутия состояния / Sybil на ресурсы конструируются через time-паттерны (окна τ₁/τ₂, частоты, TTL, chain_length-требования, seniority-gating), не через денежные барьеры (fees, rent, activation burn). Запреты: `MIN_*_BALANCE_NJ` пороги как anti-spam, cost-based derivation для защиты от раздутия, комиссии на операции в любой форме. Разграничение: [I-15] применяется к anti-spam/anti-bloat задачам; allocation уникальных ресурсов (NicknameBid) и оплата услуг (PurchaseCredits, Anchor fees, Premium subs) через [I-13] deflationary sink — отдельный класс. Crypto-stake для validator role (NODE_REGISTRATION_STAKE) — отдельный класс Sybil-защиты. Прецедент: при формулировании Пункта 3 architect предлагал `MIN_ACCOUNT_BALANCE_NJ` + periodic rent — денежные барьеры в fee-less протоколе. Author указал конструировать защиту через time-market уже встроенный в консенсус. [I-15] создан как global lens для всех будущих anti-spam решений. Role bump: Таймчейн/CLAUDE.md 4.23.0 → 4.24.0 ([I-15] в реестр инвариантов + вопрос 19 critic-mode + [I-15] check в карточке механизма + Gate 0-14 coverage расширена до 15). Пункт 3 будет переработан: вместо `MIN_ACCOUNT_BALANCE_NJ` + rent — time-based защита через activation cooldown per sender + chain_length threshold + aggressive TTL. |
| 0.0.0        | v30.2.0      | 2026-04-22 | Role meta-fix: Таймчейн/CLAUDE.md 4.22.0 → 4.23.0. Закрывает **root cause** pattern drift при SSOT audits — вместо formulating criterion через observed hits, обязательно absolute binary «authoritative-location match vs any other». Применимо ко всем SSOT entities в [I-10] (не только версия): protocol constants, crypto sizes, domain separators, formulas, layouts, type annotations, algorithm descriptions. При любом соблазне classify hit как «legitimate migration marker / stale / historical / transitional» вне authoritative location — automatic trigger pattern drift, немедленный rollback к binary criterion. Дополнительный раздел «Mandatory immediate full-class closure при triple identification»: когда автор / критик трижды указывают на один class ошибок в сессии, architect **обязан** apply meta-fix immediately без ожидания дополнительного подтверждения; «абсолютный запрет без подтверждения» применим к спеке/коду, не к закрытию собственной методологической дыры в роли. Вопросы 17-18 добавлены в critic-mode (SSOT binary criterion + full-class closure trigger). Фикс реагирует на pattern демонстрируемый в v4.19..v4.22 для версии спеки (4 итерации fragmented closure — subjective classification сохранялась до autor manual trigger на «корневое закрытие»); generalized ко всем future SSOT entities единым принципом. | 
| 0.0.0        | v30.2.0      | 2026-04-22 | [I-10] hardened — абсолютный запрет упоминания версии спеки в теле документа. Автор указал корневой принцип: версия живёт в трёх местах строго — header (line 3 `**Версия:** X.Y.Z`), имя файла (`Montana vX.Y.Z.md`), `Код/VERSION.md` Spec target. Нигде в теле спеки версия не упоминается (ни как `удалено в vX.Y.Z`, ни как `pending vX.Y.Z`, ни как `closed vX.Y.Z`, ни как `TODO vX.Y.Z`, ни как `на момент vX.Y.Z`, ни как `# vX.Y.Z:` в комментариях кода). История читается через git log / VERSION.md / file rename chronology. Применено к 20+ hits в спеке: conformance status `closed v29.12.0` → `closed` (3 места); audit snapshot `на момент v30.1.0` → без timestamp; `pending v30.3.0` labels → `pending` (3 места); migration notes `удалён в v30.2.0` → `удалён`; code comments `# v30.2.0:` → без version; TODO `TODO v30.3.0` → `TODO`; architectural invariants `Лотерея v30.2.0 single-class` → `Лотерея single-class` (6 мест в прозе и layout); `deprecated v28.0.0` → `deprecated`; historical refs `до v29.13.0` → `ранее`; `Pre-v29.13.0` / `v29.13.0` в code comments → `Ранее` / `Текущая реализация`; evolution notes `увеличено с 1000B в v29.x из-за никнейм-слоя в v30.0.0` → `включая nickname-слой`; typo `в модели v20.2.0` → без version. Gate 15 final generic grep `\bv[0-9]+\.[0-9]+\.[0-9]+\b` → 0 spec-version hits в body (только header line 3); 2 QEMU CPU version hits (external software в benchmark context — legitimate вне [I-10] scope). Role bump: Таймчейн/CLAUDE.md 4.21.0 → 4.22.0 ([I-10] absolute prohibition + Gate 15 Шаг 1 Часть 1B v2 — generic regex без restrictions, бинарный criterion header-vs-body, 5-я категория classification упрощена до «version mention in body = MUST remove version reference»). Third-iteration self-correction pattern acknowledged в роли: v4.19 entity-specific → v4.20 + narrow regex → v4.21 + wider regex → v4.22 absolute prohibition (единственный final criterion устойчивый к pattern-formulation drift). |
| 0.0.0        | v30.2.0      | 2026-04-22 | v30.2.0 cleanup — generic version-pin sweep (Gate 15 v4.21.0). Критик обнаружил residual C-A6 на line 1253 (identical version-pin phrase которую v4.20.0 Gate 15 пропустил — первое применение нового Gate 15 само пропустило один hit). Расширенный generic version-pin grep выявил ещё 7 stale pins в spec («В v30.2.0 лотерея single-class», «winner_class = Node в v30.2.0», «Лотерея в v30.2.0 — single-class» и т.п.) — архитектурные инварианты с timestamping который становится stale с каждым bump. Все 8 version-pin hits delocalized (удалён version prefix, statement оставлен как timeless architectural invariant). Итоговый Gate 15 v4.21.0 re-run: 6 remaining hits — все legitimate migration / transitional / historical markers (line 516 OpenAccount removal note, line 1033 TODO v30.3.0 transitional pruning marker, line 1262 removal summary, line 2792 historical «Дефолтный список в v30.0.0», line 3616 «увеличено с 1000B в v29.x из-за никнейм-слоя в v30.0.0» evolution marker, line 294 [I-14] audit progress notes). Zero stale version pins confirmed. Role bump: Таймчейн/CLAUDE.md 4.20.0 → 4.21.0 (Gate 15 Шаг 1 расширен до двух частей: Часть 1A entity-specific + **Часть 1B generic version-pin sweep** через `\b(в |v )v?X.Y.Z\b` pattern; добавлена **5-я категория классификации** «stale version pin» с MUST delocalize action). Фикс предотвращает regression того же класса ошибок при будущих spec bumps. |
| 0.0.0        | v30.2.0      | 2026-04-22 | v30.2.0 cleanup finalization (Gate 15 post-edit completeness audit): применены 5 findings критика (C-A1..C-A5) и C-A6 version-pin. (C-A1) `winner_class` в proposal header — layout/invariant/apply cleanup: `winner_class == 1` единственное valid значение (prev `∈ {1, 2}`), значения `2..=255` reserved-for-future с явным reject в текущей версии, apply_emission dead branch для `winner_class == 2 (Account)` удалён. (C-A2) Integer log algorithm section title `shared между node и account lottery` → `node lottery`. (C-A3) Narrative «Управление вниманием» (line 45): удалено dead mention `account lottery`. (C-A4) Pruning условие `balance == 0` помечено TODO v30.3.0 marker на замену `balance < MIN_ACCOUNT_BALANCE_NJ` после решения Пункта 3 (добавление константы в Genesis Decree). (C-A5) [I-14] conformance audit table: `AccountRecord` pending v30.2.0 → `partial — pending v30.3.0` с явным описанием (activation path closed через TransferActivation; ongoing barrier selection требует Пункта 3); `Anchor records` pending v30.2.0 → `pending v30.3.0`. (C-A6) Version-pin `В v30.2.0 аккаунты не участвуют в лотерее` → без version pin (architectural invariant без timestamping). Gate 15 exhaustive grep audit: все `OpenAccount`/`weighted_ticket_account`/`operation_for_lottery`/`WINNER_CLASS_ACCOUNT`/`mt-account-lottery`/`DS-3`/`лотерея аккаунтов` hits — 3 retained как legitimate migration markers; `pending v30.2.0` hits — 0; `winner_class = 2` live branches — 0. Zero live-semantic residuals confirmed. Role bump: Таймчейн/CLAUDE.md 4.19.0 → 4.20.0 (Gate 15 Post-edit completeness audit + Trust-but-verify для Agent-delegated work + Symmetric delete checklist + Cleanup ≠ Closure принцип + вопрос 16 критик-mode — методологический fix на delegation-without-verification pattern выявленный критиком). |
| 0.0.0        | v30.2.0      | 2026-04-22 | Sovereignty Ladder single-path: удаление account lottery + OpenAccount opcode. (1) Emission направляется только на узлы — формула `weighted_ticket_account`, константа `WINNER_CLASS_ACCOUNT`, DS-3 инвариант, 4 binding test vectors A1-A4, поле `operation_for_lottery`, domain separator `mt-account-lottery`, «Валидация лотерейного билета аккаунта» удалены. `account_chain_length_snapshot` сохранён (используется anti-Sybil threshold в NicknameBid). (2) OpenAccount opcode удалён, заменён на `0x0A TransferActivation` (979 B payload: sender + receiver + suite_id + receiver_pubkey + amount) от существующего sponsor; binding `receiver == H("mt-account" \|\| suite_id \|\| receiver_pubkey)`. Transfer reject `ReceiverNotActive` если receiver ∉ AccountTable. Receiver's AccountChain genesis — первая signed receiver-операция с `prev_hash = 0x00...00`. (3) Narrative: «Два пути участия» переписан в Sovereignty Ladder 2-step (account-only onboarding → node operator earning). Cross-section (~30 мест): apply_proposal dispatch, onboarding, Dandelion++, wire format, mnemonic, Recovery semantics, signer_suite_id table, AccountChain описание, emission flow, winner dispatch, examples — синхронизированы. Открытый вопрос: `winner_class` 1B в proposal header имеет single reachable value (`Node`) — семантически dead, удаление отложено в v30.2.1 (требует Gate 0.5 (d) duplicate scan + apply_emission refactor + test vectors bump). Role bumps: Таймчейн/CLAUDE.md 4.18.0 → 4.19.0 (Gate 14 расширение до 10 шагов + Storage Card + вопрос 15 Sabotage + Symmetric conservation invariants + Ownership of lifecycle cost), Таймчейн/CRITIC.md 3.7.0 → 3.8.0 (Pass 13 Часть C Narrative-technical consistency + Pass 18 расширение + Pass 19 Sabotage threat model). |
| 0.0.0        | v30.1.0      | 2026-04-21 | [I-14] State lifecycle & bloat resistance добавлен в реестр глобальных инвариантов. Закрытие slow-bloat attack vector (миллион legitimate account creations раздувают state trie без экономического барьера и без lifecycle bound). Три пути compliance: cost-based barrier, lifecycle bound (balance / temporal / explicit removal), hard quota. Conformance audit существующих persistent tables: `NicknameTable` + `AuctionTable` + Candidate Pool = closed; `AccountRecord` + Anchor = pending v30.2.0 (выбор механизма требуется). Role bump: Таймчейн/CLAUDE.md 4.17.0 → 4.18.0 (Gate 14 state lifecycle audit + вопрос 14 внутреннего critic-mode + [I-11..I-14] синхронизация с спекой + карточка расширена), Таймчейн/CRITIC.md 3.6.0 → 3.7.0 (Pass 18 Economic attack vectors legitimate-per-step unbounded accumulation + запреты критика при Проходе 18). |
| 0.0.0        | v29.10.1     | 2026-04-21 | Закрытие [I-9] conformance для Algorithm M-1 и per-role key derivation: 6 binding test vectors byte-exact inline в разделе «Ключи → Мнемоника и seed → Test vectors (binding)». Три M-1 vectors (entropy=[0;32] → `38a1421a…68708edb`; entropy=[0xFF;32] → `a5925c51…3ca9104`; entropy=SHA-256("Montana test vector 3") → `da13e259…92f9a47`) + три per-role derivation vectors для account/node (FN-DSA-512 48B seed) и app-encryption (ML-KEM-768 64B seed). Reference implementation `mt-mnemonic` crate (Phase A HMAC-SHA-256, Phase B PBKDF2-HMAC-SHA-256, Phase C HKDF-Expand, Phase D wordlist + mnemonic + per-role + test vectors). Code commits: `cc50f55` (A), `fb57420` (B), `b92b21a` (C), `365faea` (D). |
| 0.0.0        | v29.10.0     | 2026-04-21 | (промежуточная версия, не задокументирована отдельной записью; объединено с v29.10.1 patch) |
| 0.0.0        | v29.9.0      | 2026-04-21 | Переработка раздела «Ключи → Мнемоника и seed» (строки 2637+) на zero-external-dependency механику. Каноническая wordlist — файл `Montana wordlist.txt` рядом со спекой (2048 слов, binding SHA-256 = `2f5eed53a4727b4bf8880d8f3f199efc90e58503646d9ff8eff3a2ed3b24dbda`, encoding = concat(word \|\| 0x0A) × 2048 = 13 116 байт). Algorithm M-1 mnemonic_to_master_seed: PBKDF2-HMAC-SHA-256, salt=`"mt-seed"` (7 байт), iter=2²⁰, master_seed=64 байта. Per-role key derivation через HKDF-Expand (RFC 5869 §2.3) с ролевыми info: `"mt-account-key"` → FN-DSA-512 (48B seed), `"mt-node-key"` → FN-DSA-512 (48B seed), `"mt-app-encryption-key"` → ML-KEM-768 (64B seed). Primitive layer расширен: добавлены HMAC-SHA-256, PBKDF2-HMAC-SHA-256, HKDF-Expand, ML-KEM-768 с integer spec inline. Passphrase не поддерживается. Смена ключа не поддерживается; компрометация закрывается transfer-ом на новый аккаунт. Итерация редакции: первый патч (2026-04-21 ранее в день) добавил параллельный раздел в конец файла — критик обнаружил 5 блокеров (duplicate раздела, отсутствие node_keypair, отсутствие app-encryption-keypair, registry inconsistency, orphan separators), архитектор откатил и переработал как inline-обновление существующего раздела. [I-9] статус M-1 + HKDF per-role — `conformance pending v29.9.1` (6 test vectors после прогона mt-mnemonic reference implementation). |
| 0.0.0        | v29.8.0      | 2026-04-19 | [I-9] Bit-exact deterministic arithmetic для consensus formulas. Добавлен новый global invariant + role bump 4.12.0 → 4.13.1 + applied integer forms к P2 (lottery ticket `ln_q64` + weighted Q64.64), P3 (quorum `(67X+99)/100`, закрыто), P4 (Adaptive D с permille participation_ratio, закрыто), P5 (target u256 intermediate). Fix duplicate-section [I-9] violations (critic P6-P9), усилен Gate 0.5 pre-edit duplicate scan (role 4.13.1). Ничто commits: `1f3f3f9` initial, `5cc53a8` P4 Q32.32→permille, `21e1547` duplicate fix, `7be68f5` role 4.13.1. P2+P5 conformance pending v29.8.1. |
| 0.0.0        | v29.7.1      | 2026-04-19 | Editorial cleanup: S-1 удалён дубль domain `mt-node`; S-2 уточнён genesis_candidate_root = empty_internal(256); F-1 добавлен domain separator "mt-genesis" в Genesis State Hash. Code change: mt-genesis compute_genesis_state_hash использует domain::GENESIS |
| 0.0.0        | v29.7.0      | 2026-04-18 | Signature architecture: SSI rules R1..R4 (signed_scope + identifier + aggregate over node_ids), bijective canonical invariant, type byte registry, domain separator SSOT registry. Breaking change: `cemented_bundle_aggregate` формула — aggregate over node_ids, не signatures. Закрывает F-1, F-2, F-3, F-4, F-5, F-6, F-7, X1 findings критика |
| 0.0.0        | v29.6.9      | 2026-04-17 | admission_divisor 256 → 130 с derivation 1% cap; SSOT sort_key                        |
| 0.0.0        | v29.6.8      | 2026-04-17 | selection_interval 369 → 336 (fix противоречие #1)                                    |
| 0.0.0        | v29.6.7      | 2026-04-17 | Workspace skeleton                                                                    |