montana/Russian/Tech/МОНТАНА_ПРОТОКОЛ.md

# Montana Protocol — Техническая Спецификация

**Версия:** 1.0
**Дата:** 19 февраля 2026
**Автор:** Alejandro Montana
**Статус:** MAINNET PRODUCTION

---

## Введение

Montana Protocol (Ɉ) — протокол идеальных денег с постквантовой криптографией.

Монтана — это три независимых слоя:

**Криптография** — генерация ключей и адресов. Полностью офлайн, чистая математика. Не требует сети, не требует ничьего разрешения. Хоть на бумажке считай.

**Таймчейн** — реестр транзакций. Хранит записи вида «на такой-то адрес можно потратить столько-то, если предъявишь правильную подпись». Ничего не знает о ключах, кошельках, владельцах.

**Кошелёк** — мост между первым и вторым. Он берёт ключи, вычисляет адреса, сканирует таймчейн и показывает тебе «баланс». А при отправке — подписывает транзакцию приватным ключом и отправляет в сеть.

Эти слои нигде не «регистрируют» друг друга. Связь между ними — только математика и протокол консенсуса.

Нет центра, который бы сводил ключи и адреса воедино.

```
Блокчейн без криптографии — просто база данных.
Криптография без блокчейна — просто шифрование.
Вместе они дают деньги, не требующие доверия.
```

---

## Порядок строительства

```
1. КРИПТО-СЛОЙ      → Ключи, адреса, подписи (офлайн)
2. ФОРМАТ ТРАНЗАКЦИИ → Структура: от кого, кому, сколько, подпись
3. ТАЙМЧЕЙН         → Слайсы времени, консенсус, валидация, хранение
4. КОШЕЛЁК          → Мост: seed → ключи → адреса → баланс
```

---

# ЧАСТЬ I. КРИПТО-СЛОЙ

## 1.1 Обзор

Крипто-слой — фундамент всего протокола. Полностью автономен. Работает офлайн. Не требует подключения к сети, не требует регистрации, не требует ничьего разрешения.

Единственная задача: генерировать ключи, вычислять адреса, подписывать данные и проверять подписи.

**Алгоритм:** ML-DSA-65 (Dilithium)
**Стандарт:** FIPS 204
**Уровень безопасности:** NIST Level 3 (128-bit post-quantum)

Постквантовая криптография с генезиса — не retrofit. Когда квантовые компьютеры станут угрозой, Montana уже будет защищена. Bitcoin, Ethereum и Solana будут вынуждены делать хардфорк.

```
Bitcoin/Ethereum: ECDSA сейчас → хардфорк потом
Montana:          ML-DSA-65 с генезиса → уже защищены
```

## 1.2 Размеры ключей

| Параметр | Размер |
|----------|--------|
| Private Key | 4032 байт |
| Public Key | 1952 байт |
| Signature | 3309 байт |
| Адрес | 42 символа |

## 1.3 Полный путь: Энтропия → Мнемоника → Seed → Ключи → Адрес

### Шаг 1. Генерация энтропии (256 бит)

```
SecRandomCopyBytes() → 32 байта (256 бит)
Криптографически безопасный генератор (/dev/urandom)
```

### Шаг 2. BIP-39 мнемоника (24 слова)

Стандарт BIP-39 — тот же что в Bitcoin, Ethereum и большинстве криптовалют.

```
1. 256 бит энтропии → SHA-256 хеш
2. Первые 8 бит хеша = контрольная сумма
3. 256 бит + 8 бит = 264 бита
4. Разбить на 24 группы по 11 бит
5. Каждая группа → индекс (0–2047) → слово из словаря BIP-39
6. Результат: 24 слова

Пример: abandon ability able about above absent ...
```

**Валидация мнемоники:**
- Извлечь 256 бит энтропии из 24 слов
- Вычислить SHA-256, взять первый байт
- Сравнить с контрольной суммой из мнемоники

### Шаг 3. Деривация seed через PBKDF2-SHA512

```
Вход:      Мнемоника (24 слова через пробел)
Соль:      "mnemonic" (стандарт BIP-39, без passphrase)
KDF:       PBKDF2-SHA512
Итерации:  2048
Выход:     64 байта (512 бит)
```

**Ключевое свойство:** одна и та же мнемоника всегда даёт один и тот же seed. Детерминизм.

### Шаг 4. Генерация ключей ML-DSA-65 (детерминированная)

Seed (64 байта) инъектируется в liboqs через кастомный RNG на основе SHA256-CTR DRBG:

```
block[i] = SHA256(seed || counter_be)
где counter = 0, 1, 2, ...
```

liboqs использует этот детерминированный RNG для генерации пары ключей.

```
Выход:
├── Private Key: 4032 байт
└── Public Key:  1952 байт
```

**Ключевое свойство:** один и тот же seed всегда даёт одну и ту же пару ключей.

### Шаг 5. Вычисление адреса

```
1. Хеш публичного ключа:  SHA256(public_key) → 32 байта
2. Payload:                Первые 18 байт → 36 hex-символов
3. Промежуточный адрес:    "mt" + payload (38 символов)
4. Контрольная сумма:      SHA256(SHA256("mt" + payload))[:2] → 4 hex-символа
5. Финальный адрес:        "mt" + payload + checksum = 42 символа

Пример: mta46b633d258059b90db46adffc6c5ca08f0e8d6c
```

**Валидация адреса:**
- Длина = 42
- Префикс = "mt"
- Все символы hex (0–9, a–f)
- Контрольная сумма совпадает

### Шаг 6. Подпись

ML-DSA-65 подпись с детерминированным rnd=0 (FIPS 204):

```
signature = ML_DSA_65.sign(private_key, message)  → 3309 байт
```

Одно и то же сообщение + один и тот же ключ = всегда одна и та же подпись.

### Шаг 7. Верификация

```
ML_DSA_65.verify(public_key, message, signature)  → true/false
```

Для верификации нужен только публичный ключ. Приватный ключ не раскрывается.

## 1.4 Полная диаграмма крипто-слоя

```
┌─────────────────────────────────────────────────────────┐
│ 1. Энтропия (256 бит)                                   │
│    ↓                                                     │
│ 2. BIP-39 мнемоника (24 слова)                           │
│    ↓                                                     │
│ 3. PBKDF2-SHA512 → Seed (64 байта)                      │
│    ↓                                                     │
│ 4. ML-DSA-65 генерация ключей (детерминированная)       │
│    ├── Private Key: 4032 байт                           │
│    └── Public Key: 1952 байт                            │
│    ↓                                                     │
│ 5. Вычисление адреса                                    │
│    └── mt + SHA256(pubkey)[:18] + checksum = 42 символа │
│    ↓                                                     │
│ 6. Подпись / Верификация (детерминированная)             │
│    └── Signature: 3309 байт                             │
└─────────────────────────────────────────────────────────┘

Весь путь ДЕТЕРМИНИРОВАН:
Одна мнемоника → всегда одни и те же ключи и адрес
Одно сообщение + один ключ → всегда одна подпись
```

## 1.5 Сравнение с другими блокчейнами

| Параметр | Bitcoin | Ethereum | Solana | **Montana** |
|----------|---------|----------|--------|-------------|
| Алгоритм | ECDSA (secp256k1) | ECDSA (secp256k1) | Ed25519 | **ML-DSA-65 (FIPS 204)** |
| Квантовая защита | Нет | Нет | Нет | **Да, с генезиса** |
| Адрес | SHA256+RIPEMD160 | Keccak256[-20:] | Ed25519 pubkey | **mt + SHA256[:18] + checksum** |
| Private key | 32 байт | 32 байт | 64 байт | **4032 байт** |
| Public key | 33 байт | 64 байт | 32 байт | **1952 байт** |
| Signature | 72 байт | 65 байт | 64 байт | **3309 байт** |
| Seed | BIP-39 (12/24 слова) | BIP-39 (12/24 слова) | BIP-39 | **BIP-39 (24 слова)** |
| Стандарт | — | — | — | **NIST FIPS 204** |

## 1.6 Реализации

| Платформа | Библиотека | Файл |
|-----------|------------|------|
| macOS/iOS (Swift) | liboqs (C) через ObjC bridge | `Crypto/MLDSA65.swift`, `Crypto/MontanaSeed.swift` |
| Backend (Python) | dilithium_py | `Bot/node_crypto.py` |

Все реализации дают **идентичные криптографические результаты** для одного и того же seed.

## 1.7 Защита от квантовых атак

| Атака | Статус |
|-------|--------|
| Алгоритм Шора (взлом ECDSA/RSA) | Не применим к ML-DSA-65 |
| Алгоритм Гровера (ускорение перебора) | ML-DSA-65 устойчив (NIST Level 3) |
| Harvest Now, Decrypt Later | Защищены с первого дня |
| Подделка подписи транзакции | Защищены с первого дня |

---

# ЧАСТЬ II. ФОРМАТ ТРАНЗАКЦИИ

## 2.1 Модель: UTXO

Montana использует модель UTXO (Unspent Transaction Output) — такую же, как в Bitcoin.

**Принцип:** в системе нет «балансов». Есть только неизрасходованные выходы транзакций. «Баланс» адреса — это сумма всех UTXO, привязанных к этому адресу.

```
UTXO — это запись:
"На адрес mt... можно потратить N Ɉ, если предъявишь подпись от ключа этого адреса"
```

## 2.2 Структура транзакции

```
Transaction {
    version:    u8                    // Версия формата (1)
    inputs:     Vec<TxInput>          // Входы (ссылки на UTXO)
    outputs:    Vec<TxOutput>         // Выходы (новые UTXO)
    timestamp:  u64                   // Unix timestamp
    signature:  [u8; 3309]            // ML-DSA-65 подпись
}

TxInput {
    tx_hash:    [u8; 32]              // Хеш транзакции-источника
    output_idx: u32                   // Индекс выхода в той транзакции
    pubkey:     [u8; 1952]            // Публичный ключ отправителя
}

TxOutput {
    address:    String                // Адрес получателя (42 символа, mt...)
    amount:     u64                   // Сумма в Ɉ
}
```

## 2.3 Жизненный цикл транзакции

**Транзакции моментальные.** Отправил — дошло. Финализация в τ₁ (1 минута).

```
1. Кошелёк собирает входы (UTXO принадлежащие отправителю)
2. Кошелёк формирует выходы:
   ├── Получатель: адрес + сумма
   └── Сдача: адрес отправителя + остаток
3. Кошелёк подписывает транзакцию приватным ключом (ML-DSA-65)
4. Транзакция отправляется в сеть → МОМЕНТАЛЬНО доходит до получателя
5. Узлы валидируют:
   ├── Входы существуют и не потрачены
   ├── Подпись верна (ML-DSA-65 verify)
   ├── Сумма входов ≥ сумма выходов
   └── Адреса валидны
6. Финализация: включение в слайс τ₁ (≤ 1 минута)
```

**Важно:** τ₁ — финализация транзакций, не эмиссии. Эмиссия финализируется в τ₂ (10 минут).

## 2.4 Валидация транзакции

Узел проверяет транзакцию через крипто-слой. Связь между слоями — только математика:

```
1. Для каждого input:
   ├── Найти UTXO по (tx_hash, output_idx) в таймчейне
   ├── Проверить что UTXO не потрачен
   └── Проверить что address(input.pubkey) == UTXO.address

2. Проверить подпись:
   └── ML_DSA_65.verify(input.pubkey, tx_data, signature)

3. Проверить баланс:
   └── sum(inputs) ≥ sum(outputs)
```

## 2.5 Coinbase-транзакция (эмиссия)

Специальная транзакция без входов — награда за присутствие:

```
CoinbaseTransaction {
    version:    1
    inputs:     []                    // Пусто — нет источника
    outputs:    [
        { address: "mt...", amount: seconds × halving_coefficient }
    ]
    timestamp:  <unix time>
    proof:      PresenceProof         // Доказательство присутствия
    signature:  <ML-DSA-65>           // Подпись узла-валидатора
}
```

Эмиссия определяется присутствием, а не вычислениями.

---

# ЧАСТЬ III. ТАЙМЧЕЙН

## 3.1 Обзор

Таймчейн — реестр всех транзакций Montana. Это не классический блокчейн с блоками, а **4-слойная иерархическая цепочка слайсов времени**, где каждый верхний слой вкладывает в себя все заголовки нижних — как матрёшка.

Таймчейн ничего не знает о ключах, кошельках и владельцах. Он хранит только записи: «на такой-то адрес можно потратить столько-то, если предъявишь правильную подпись».

## 3.2 Временные координаты

Montana измеряет время, а не блоки. Единица таймчейна — **слайс времени** (time slice), не блок:

| Единица | Длительность | В секундах | Назначение |
|---------|-------------|------------|------------|
| **τ₁** | 1 минута | 60 | **Финализация транзакций.** Подпись присутствия. Включение tx в слайс |
| **τ₂** | 10 минут | 600 | **Финализация эмиссии.** Подтверждение балансов. Начисление Ɉ |
| **τ₃** | 14 дней | 1,209,600 | **Кулдауны и балансировка.** Adaptive Cooldown. Чекпоинт сети |
| **τ₄** | 4 года | 126,144,000 | **Халвинг.** Эмиссия ÷2 |

```
Иерархия:
1 τ₄ = 104 τ₃ = 209,664 τ₂ = 2,096,640 τ₁ = 126,144,000 секунд
1 τ₃ = 2,016 τ₂ = 20,160 τ₁ = 1,209,600 секунд
1 τ₂ = 10 τ₁ = 600 секунд
```

## 3.3 Структура слайсов времени

Единица таймчейна — **слайс времени** (time slice). Не блок. Каждый слайс содержит хеш предыдущего слайса своего слоя (цепочка внутри слоя) и заголовки нижних слоёв (матрёшка между слоями).

### τ₁ слайс (1 минута)

Атомарная единица таймчейна. Содержит транзакции и доказательство присутствия.

```
Tau1Slice {
    timestamp:      u64
    prev_tau1_hash: [u8; 32]          // Хеш предыдущего τ₁ слайса (цепь)
    transactions:   Vec<Transaction>   // Транзакции за минуту
    presence_proof: PresenceProof      // Доказательство присутствия узла
    slice_number:   u64
    signature:      [u8; 3309]         // ML-DSA-65 подпись
}
```

### τ₂ слайс (10 минут) — матрёшка уровень 1

Содержит **ВСЕ 10 заголовков τ₁** слайсов + Merkle-корень из них.

```
Tau2Slice {
    timestamp:          u64
    prev_tau2_hash:     [u8; 32]       // Хеш предыдущего τ₂ слайса (цепь)
    tau1_merkle_root:   [u8; 32]       // Корень Меркла из 10 τ₁
    tau1_headers:       [[u8; 32]; 10] // ВСЕ 10 хешей τ₁ слайсов
    total_emission:     u64            // Эмиссия за 10 минут
    halving_coefficient: f64
    signature:          [u8; 3309]
}
```

### τ₃ слайс (14 дней) — матрёшка уровень 2

Содержит **ВСЕ 2,016 заголовков τ₂**, каждый из которых уже содержит корни своих 10 τ₁.

```
Tau3Slice {
    timestamp:          u64
    prev_tau3_hash:     [u8; 32]        // Хеш предыдущего τ₃ слайса (цепь)
    tau2_merkle_root:   [u8; 32]        // Корень Меркла из 2,016 τ₂
    tau2_headers:       [[u8; 32]; 2016]// ВСЕ 2,016 хешей τ₂ слайсов
    epoch_number:       u32
    signature:          [u8; 3309]
}
```

### τ₄ слайс (4 года) — матрёшка уровень 3

Содержит **ВСЕ 104 заголовка τ₃**, каждый из которых содержит все τ₂, которые содержат все τ₁.

```
Tau4Slice {
    timestamp:              u64
    prev_tau4_hash:         [u8; 32]     // Хеш предыдущего τ₄ слайса (цепь)
    tau3_merkle_root:       [u8; 32]     // Корень Меркла из 104 τ₃
    tau3_headers:           [[u8; 32]; 104] // ВСЕ 104 хеша τ₃ слайсов
    halving_number:         u32          // Номер халвинга
    new_halving_coefficient: f64         // Новый коэффициент
    signature:              [u8; 3309]
}
```

## 3.4 Матрёшка слоёв (Merkle Nesting)

Каждый слайс содержит хеш предыдущего слайса своего слоя (горизонтальная цепь) и все заголовки нижнего слоя (вертикальная матрёшка):

```
ГОРИЗОНТАЛЬНАЯ ЦЕПЬ (внутри каждого слоя):
τ₁[0] → τ₁[1] → τ₁[2] → ...     (prev_tau1_hash)
τ₂[0] → τ₂[1] → τ₂[2] → ...     (prev_tau2_hash)
τ₃[0] → τ₃[1] → ...              (prev_tau3_hash)
τ₄[0] → τ₄[1] → ...              (prev_tau4_hash)

ВЕРТИКАЛЬНАЯ МАТРЁШКА (между слоями):
┌─────────────────────────────────────────────────────────┐
│ τ₄ слайс                                               │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 104 × τ₃ заголовков                                │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ 2,016 × τ₂ заголовков (в каждом τ₃)           │ │ │
│ │ │ ┌─────────────────────────────────────────────┐ │ │ │
│ │ │ │ 10 × τ₁ заголовков (в каждом τ₂)          │ │ │ │
│ │ │ └─────────────────────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
```

**Принцип:** τ₂ вкладывает в себя все τ₁. τ₃ вкладывает все τ₂ (которые уже содержат τ₁). τ₄ вкладывает все τ₃. Один τ₄ слайс = криптографический proof всех 4 лет.

```
τ₁ → τ₁ → τ₁ → τ₁ ...    (цепь 1-минутных слайсов)
 ↓    ↓    ↓    ↓
 └────┴────┴────┴─→ τ₂    (содержит ВСЕ 10 τ₁ заголовков)
                     ↓
                     └─→ τ₃    (содержит ВСЕ 2,016 τ₂ заголовков)
                          ↓
                          └─→ τ₄    (содержит ВСЕ 104 τ₃ заголовков)
```

**Преимущества:**
1. Быстрая верификация: лёгкий клиент скачивает только заголовки верхнего слоя
2. Компактность: один τ₄ слайс = proof всех 4 лет (вся матрёшка внутри)
3. Параллелизм: слои можно верифицировать параллельно
4. Постквантовая защита: ML-DSA-65 на каждом слайсе

## 3.5 Консенсус: ACP (Atemporal Coordinate Presence)

### Принцип

ACP — консенсус-механизм, где доказательство основано на **присутствии во времени**. Время нельзя ускорить, купить или накопить заранее. 14 дней требуют 14 дней — для всех одинаково.

```
1 секунда доказанного присутствия = 1 Ɉ × halving_coefficient
```

### Сравнение с другими консенсусами

| Система | Ресурс | Можно ускорить? | Справедливость |
|---------|--------|-----------------|----------------|
| Bitcoin (PoW) | Вычисления | Да (купить ASIC) | Неравномерно |
| Ethereum (PoS) | Stake | Да (купить ETH) | Плутократия |
| **Montana (ACP)** | **Время** | **Нет** | **Равномерно** |

```
Золото ограничено в пространстве → добыча
Bitcoin ограничен вычислениями → майнинг
金元Ɉ ограничен временем → присутствие
```

### Доказательство присутствия (Presence Proof)

Каждую τ₁ (1 минуту) узел подписывает доказательство:

```
Формат сообщения:
MONTANA_PRESENCE_V1:{timestamp}:{prev_hash}:{pubkey}:{t2_index}

Подпись: ML-DSA-65
Хеш: SHA256(message || signature)
```

Доказательства образуют цепочку:

```
Genesis    → prev_hash = "0000...0000" (64 нуля)
Proof #1   → prev_hash = Genesis.hash
Proof #2   → prev_hash = Proof#1.hash
...
```

14 дней присутствия требуют 14 дней реального времени. Атакующий с бесконечными ресурсами может подписать 1000 координат за секунду, но сеть примет только 1 подпись на τ₁. Невозможно ускорить время.

## 3.6 Эмиссия: 金元Ɉ

### Определение

**金元** (jīn yuán) — буквально «золотой юань».
**Ɉ** (Unicode U+0248) — Temporal Time Unit.

```
金元Ɉ = Время, доказанное присутствием
```

### Фундаментальное свойство

```
lim(evidence → ∞) 1 Ɉ → 1 секунда

∀t: Trust(t) < 1
```

Ɉ не равен секунде. Ɉ асимптотически приближается к секунде по мере накопления доказательств:

| Доказательства | Точность | Доверие |
|----------------|----------|---------|
| 1 подпись | ±10 минут | ~0.1 |
| 1 τ₂ (10 мин) | ±1 минута | ~0.5 |
| 1 τ₃ (14 дней) | ±1 секунда | ~0.99 |
| 1 τ₄ (4 года) | ±0.1 секунды | ~0.9999 |

### Механизм эмиссии

Каждый τ₂ (10 минут) происходит финализация:

```
1. Подсчёт секунд присутствия каждого участника за τ₂
2. Применение коэффициента халвинга
3. Начисление: coins = seconds × halving_coefficient
4. Запись в таймчейн как coinbase-транзакции
```

Эмиссия **параллельная** — каждый участник получает монеты за своё присутствие:

```
User A: 450 сек × 1.0 = 450 Ɉ
User B: 600 сек × 1.0 = 600 Ɉ
User C: 150 сек × 1.0 = 150 Ɉ
─────────────────────────────
Эмиссия за τ₂: 1,200 Ɉ
```

Нет лотереи, нет резерва — всё распределяется участникам.

### Халвинг

Каждые τ₄ (4 года) эмиссия делится на 2:

```
halving_coefficient(n) = 1.0 / (2^n)
```

| Эпоха τ₄ | Годы | Коэффициент | 1 секунда = |
|----------|------|-------------|-------------|
| 0 | 0–4 | 1.0 | 1.0 Ɉ |
| 1 | 4–8 | 0.5 | 0.5 Ɉ |
| 2 | 8–12 | 0.25 | 0.25 Ɉ |
| 3 | 12–16 | 0.125 | 0.125 Ɉ |
| ... | ... | ... | ... |
| 64 | ~260 лет | ~0 | ~0 Ɉ |

### TIME_BANK Reserve — 21 миллион минут

Банк Времени имеет конечный резерв:

```
21,000,000 минут = 1,260,000,000 секунд ≈ 40 лет
```

21 миллион — как 21 миллион Bitcoin. Конечный ресурс.

Банк тратит 10 минут из резерва каждый τ₂, подтверждая что прошло ровно 10 минут. Когда резерв исчерпан (~40 лет), банк переходит в **Oracle Mode**: продолжает верифицировать время, но больше не эмитирует из резерва.

| Год | Осталось | % резерва |
|-----|----------|-----------|
| 0 | 21,000,000 | 100% |
| 4 | 18,897,600 | 90% |
| 10 | 15,744,000 | 75% |
| 20 | 10,488,000 | 50% |
| 30 | 5,232,000 | 25% |
| 40 | 0 | 0% → Oracle Mode |

### Генезис цены: Beeple Anchor

Продажа NFT Beeple «Everydays: The First 5000 Days» 11 марта 2021 установила генезисную цену времени:

```
$69,300,000 ÷ 5000 дней ÷ 86400 сек = $0.1605/сек

1 Ɉ = $0.1605 USD = 12.04₽ RUB
```

Два генезиса:

| Событие | Дата |
|---------|------|
| Генезис Цены (BIPL) | 12 марта 2021 |
| Генезис Монтана | 9 января 2026 |

Цена может быть пересмотрена только в **День Пиццы** (22 мая) — и только вверх.

## 3.7 Свойства 金元Ɉ

**Неподделываемость:**
```
Подделать Ɉ = Подделать время = Нарушить физику
```

**Неинфлируемость:**
```
Эмиссия ограничена временем
У всех людей одинаковое количество времени
Халвинг делит эмиссию на 2 каждые 4 года
```

**Верифицируемость:**
```
Каждый Ɉ имеет доказательство:
├── Подпись присутствия (ML-DSA-65)
├── Включение в Merkle tree
├── Подтверждение в таймчейне (цепь хешей)
└── Аттестация сетью (P2P)
```

## 3.8 Защита от Sybil: Adaptive Cooldown

Механизм динамической защиты от Sybil-атак — адаптивный период ожидания для новых узлов.

```
Sybil_cost = cooldown × N_nodes
```

| Нагрузка | Cooldown |
|----------|----------|
| Нормальная | 1 день |
| Средняя (r=0.5) | 4 дня |
| Стандартная (r=1.0) | 7 дней |
| Повышенная (r=1.5) | 93 дня |
| Аномальная (r=2.0) | 180 дней |

Сглаженная медиана за 56 дней (4×τ₃) предотвращает манипуляцию через краткосрочные спайки. Rate limit ±20% за τ₃.

Стоимость атаки при стабильной нагрузке (cooldown ≈ 7 дней):
- 10 узлов: 70 дней
- 100 узлов: 700 дней (~2 года)
- 1000 узлов: 7000 дней (~19 лет)

---

# ЧАСТЬ IV. СЕТЬ

## 4.1 Топология

5 географически распределённых узлов:

```
                  ┌─────────────┐
                  │  amsterdam  │ ← PRIMARY (позиция 0)
                  │ 72.56.102.240│
                  └──────┬──────┘
                         │
       ┌─────────────────┼─────────────────┐
       │                 │                 │
  ┌────▼────┐      ┌────▼────┐      ┌─────▼────┐
  │ moscow  │      │ almaty  │      │   spb    │
  │176.124..│      │91.200...│      │188.225...│
  └────┬────┘      └────┬────┘      └────┬─────┘
       │                │                │
       └────────────────┼────────────────┘
                        │
                 ┌──────▼──────┐
                 │ novosibirsk │
                 │147.45.147...│
                 └─────────────┘
```

| Позиция | Узел | Адрес | Регион |
|---------|------|-------|--------|
| 0 | Amsterdam | mta46b633d258059b90db46adffc6c5ca08f0e8d6c | EU |
| 1 | Moscow | mta8ae14f74c38294b24c2f1c20c6406e6be929c93 | RU-Central |
| 2 | Almaty | mtd07b0d9bdab2cb592f509bc1304c368ac703c45e | KZ |
| 3 | St.Petersburg | mtb397e136de69d92e5782f3fe14533a4a37b4ddec | RU-NW |
| 4 | Novosibirsk | mtf3f0254b405382de38494e753924b4b92692bd2c | RU-Siberia |

Каждый узел имеет криптографический адрес (ML-DSA-65). IP используется только для networking, не для идентификации. Адрес не зависит от IP — защита от IP hijacking.

## 4.2 Leader Election

Детерминированный выбор мастера: первый живой узел в цепочке = мастер.

```
Алгоритм:
Для каждого узла в цепочке (сверху вниз):
  Если это я → я мастер
  Если узел жив → он мастер, я standby
```

При падении 4 из 5 узлов сеть продолжает работать. Failover < 10 секунд.

## 4.3 Обнаружение атак и Random Failover

При обнаружении атаки цепочка узлов перемешивается случайным образом:

| Метрика | Порог |
|---------|-------|
| CPU | > 80% |
| Network traffic | > 100 MB/s |
| Failures | > 10 подряд |
| Response time | > 5 секунд |

```
Нормальный режим:
amsterdam → moscow → almaty → spb → novosibirsk

После атаки (пример):
spb → novosibirsk → almaty → moscow
(amsterdam исключён как атакованный)
```

## 4.4 Breathing Sync

Git-синхронизация состояния сети каждые 12 секунд:

```
┌─────────┐     ┌─────────┐     ┌─────────┐
│ Вдох    │────▶│  Работа │────▶│ Выдох   │
│git pull │     │ 12 сек  │     │git push │
└─────────┘     └─────────┘     └─────────┘
      ▲                               │
      └───────────────────────────────┘
```

~5 «вдохов» в минуту. Обеспечивает консистентность данных между всеми узлами.

## 4.5 TLS шифрование

Связь между узлами через TLS 1.3 на порту 19333. Каждый узел имеет self-signed сертификат с привязкой к криптографическому адресу:

```
CN  = amsterdam.efir.org
UID = mta46b633d258059b90db46adffc6c5ca08f0e8d6c
```

## 4.6 Защита от атак

| Атака | Защита |
|-------|--------|
| Quantum (алгоритм Шора) | ML-DSA-65 (FIPS 204) |
| IP Hijacking | Криптографические адреса (IP ≠ identity) |
| DNS Spoofing | Alias только для UX |
| MITM | TLS 1.3 + ML-DSA-65 подписи |
| Harvest Now, Decrypt Later | ML-DSA-65 с генезиса |
| Eclipse (изоляция узла) | Фиксированная топология + множественные проверки |
| Sybil | Adaptive Cooldown (1–180 дней) |
| DDoS | Random Failover + AtlantGuard |
| Time manipulation | Физические ограничения τ₁ подписей |

---

# ЧАСТЬ V. КОШЕЛЁК

## 5.1 Обзор

Кошелёк — мост между участником и первыми тремя слоями. Он объединяет крипто-слой, формат транзакций и таймчейн в единый пользовательский интерфейс.

```
Seed → Ключи → Адреса → Сканирование таймчейна → Баланс
```

Кошелёк делает:
1. Генерирует или восстанавливает ключи из мнемоники (крипто-слой)
2. Вычисляет адрес (крипто-слой)
3. Сканирует таймчейн на UTXO принадлежащие этому адресу (таймчейн)
4. Суммирует UTXO → показывает «баланс»
5. При отправке: собирает UTXO, формирует транзакцию, подписывает приватным ключом, отправляет в сеть

## 5.2 Хранение ключей

| Платформа | Хранилище | Access Level |
|-----------|-----------|--------------|
| macOS | Keychain (service: `network.montana.presence`) | AfterFirstUnlockThisDeviceOnly |
| iOS | Keychain (service: `network.montana.wallet`) | AfterFirstUnlockThisDeviceOnly |

Хранимые данные:
- `private_key` — 4032 байта (binary)
- `public_key` — 1952 байта (binary)
- `mnemonic` — 24 слова (text)

## 5.3 Операции кошелька

### Создание новой идентичности

```
1. Генерация мнемоники (24 слова BIP-39)
2. Деривация seed через PBKDF2-SHA512
3. Генерация пары ключей ML-DSA-65
4. Вычисление адреса mt...
5. Сохранение ключей и мнемоники в Keychain
```

### Восстановление из мнемоники

```
1. Ввод 24 слов
2. Валидация контрольной суммы BIP-39
3. Деривация seed → ключи → адрес
4. Сканирование таймчейна → баланс
```

Одна мнемоника → один и тот же адрес на любом устройстве.

### Проверка баланса

```
1. По адресу mt... найти все UTXO в таймчейне
2. Сумма UTXO = подтверждённый баланс (confirmed)
3. Плюс секунды в текущем τ₂ = ожидающий баланс (pending)
```

### Отправка транзакции

```
1. Выбрать UTXO для покрытия суммы (сумма входов ≥ сумма + сдача)
2. Сформировать Transaction:
   ├── inputs: ссылки на UTXO + публичный ключ
   ├── outputs: адрес получателя + сумма, адрес отправителя + сдача
   └── timestamp
3. Подписать ML-DSA-65 приватным ключом
4. Отправить в сеть
5. Дождаться включения в τ₁ и финализации в τ₂
```

## 5.4 Типы переводов

| От | Кому | Формат |
|----|------|--------|
| Пользователь | Пользователь | mt... → mt... |
| Пользователь | Узел | mt... → mt... (по адресу или alias) |
| Узел | Пользователь | mt... → mt... (автоматическая награда) |
| Узел | Узел | mt... → mt... (через оператора) |

## 5.5 API для внешних приложений

**Баланс:**
```
GET /api/balance/{address}

{
  "address": "mt...",
  "confirmed": 1500,
  "pending": 45,
  "total": 1545,
  "slices": {
    "tau1": 25.0,
    "tau2": 2.5,
    "tau3": 0.00124,
    "tau4": 0.0000119
  }
}
```

**Регистрация присутствия:**
```
POST /api/presence
{ "seconds": 60 }

{ "success": true, "added": 60, "balance": 1560 }
```

## 5.6 Присутствие через датчики (macOS/iOS)

Вес присутствия определяется количеством активных датчиков:

```
Вес = 1 (база, пока программа включена) + количество активных датчиков + VPN
```

Датчик активен только когда: разрешение есть + тумблер ON.
Нет разрешения или тумблер OFF = датчик выключен, данные не собираются.

---

# ЧАСТЬ VI. КОНТРАКТЫ

## 6.1 Обзор

Montana Contracts — система умных контрактов с человеческим арбитражем. В отличие от автоматических смарт-контрактов, Montana Contracts используют AI-арбитра (Юнона) для валидации условий и разрешения споров.

## 6.2 Жизненный цикл

```
DRAFT → (голосование >50%) → PENDING → (Сторона Б принимает) → ACCEPTED
→ (исполнение) → COMPLETION_VOTING → (кворум + Юнона) → COMPLETED
```

## 6.3 Escrow

При создании контракта средства замораживаются:

```
Создание:   Сторона А  ──[amount]──►  escrow:CONTRACT-ID
Исполнение: escrow:CONTRACT-ID  ──[amount]──►  Сторона Б
Отмена:     escrow:CONTRACT-ID  ──[amount]──►  Сторона А
```

Escrow не контролируется ни одной стороной. Перевод возможен только при смене статуса контракта. Все операции подписаны ML-DSA-65.

## 6.4 Голосование

Юнона имеет 2 голоса и право вето. Свидетели — по 1 голосу. Кворум > 50%.

---

# ЧАСТЬ VII. КОММУНИКАЦИИ

## 7.1 Принцип

Телефон = адрес кошелька. SMS = транзакция. Звонок = стриминг времени.

## 7.2 Тарификация

| Услуга | Стоимость |
|--------|-----------|
| SMS команда | 1 Ɉ |
| Голосовой звонок | 1 Ɉ/сек |
| Видеозвонок | 2 Ɉ/сек |

## 7.3 WebRTC P2P

Голос и видео идут напрямую между устройствами. Montana обеспечивает только signaling и биллинг. Montana не слышит разговор, не хранит медиа.

---

# ЧАСТЬ VIII. СВЯЗЬ МЕЖДУ СЛОЯМИ

## 8.1 Принцип

Три слоя Montana **нигде не «регистрируют» друг друга**. Связь между ними — только математика:

```
КРИПТО-СЛОЙ ←── математика ──→ ТАЙМЧЕЙН ←── протокол ──→ КОШЕЛЁК
```

## 8.2 Крипто-слой → Таймчейн

Крипто-слой ничего не знает о таймчейне. Таймчейн использует крипто-слой для:
- Верификации подписей транзакций (`ML_DSA_65.verify`)
- Проверки что адрес соответствует публичному ключу (`address == mt + SHA256(pubkey)[:18] + checksum`)
- Подписания слайсов (`ML_DSA_65.sign`)
- Подписания доказательств присутствия

Таймчейн не хранит приватные ключи. Он принимает подпись и проверяет её математически.

## 8.3 Таймчейн → Кошелёк

Таймчейн ничего не знает о кошельках. Кошелёк сканирует таймчейн для:
- Поиска UTXO по адресу → вычисление баланса
- Отслеживания входящих транзакций
- Подтверждения отправленных транзакций

Таймчейн не знает, кому принадлежит адрес. Он просто хранит записи.

## 8.4 Кошелёк → Крипто-слой

Кошелёк использует крипто-слой для:
- Генерации ключей из мнемоники
- Вычисления адреса из публичного ключа
- Подписания транзакций приватным ключом

Крипто-слой не знает, что такое «кошелёк» или «баланс».

## 8.5 Полная диаграмма

```
┌─────────────────────────────────────────────────────────────────┐
│                         КОШЕЛЁК                                  │
│  seed → ключи → адрес → сканирование → баланс → подпись → send │
│                                                                  │
│  Использует:                                                     │
│  ├── Крипто-слой: генерация ключей, подпись транзакций          │
│  └── Таймчейн: поиск UTXO, отправка транзакций                 │
└──────────────┬───────────────────────┬──────────────────────────┘
               │                       │
               ▼                       ▼
┌──────────────────────┐  ┌──────────────────────────────────────┐
│     КРИПТО-СЛОЙ      │  │            ТАЙМЧЕЙН                   │
│                      │  │                                       │
│ ML-DSA-65            │  │ Слайсы: τ₁ → τ₂ → τ₃ → τ₄           │
│ BIP-39               │  │ UTXO set                              │
│ Keygen, Sign, Verify │  │ Консенсус ACP                        │
│                      │  │ Эмиссия + Халвинг                     │
│ Офлайн.              │  │ 5 узлов, P2P                          │
│ Не знает о сети.     │  │ Не знает о ключах.                   │
└──────────────────────┘  └──────────────────────────────────────┘

Связь: только математика и протокол.
Нет центра, который бы сводил ключи и адреса воедино.
```

---

# ЧАСТЬ IX. РЕАЛИЗАЦИЯ

## 9.1 Файловая структура

```
Russian/
├── Протокол/                    # Спецификации протокола
│   ├── 001_ВКП.md              # ACP консенсус
│   ├── 002_ВРЕМЕННАЯ_ЕДИНИЦА.md # 金元Ɉ
│   ├── 003_ТРОЙНОЕ_ЗЕРКАЛО.md  # 3-Mirror failover
│   ├── 004_АДАПТИВНОЕ_ОХЛАЖДЕНИЕ.md # Sybil protection
│   ├── 007_ПОСТКВАНТОВЫЙ.md    # Post-quantum
│   └── 008_ЯКОРЬ_БИПЛА.md      # Beeple anchor
│
├── Bot/                         # Ядро протокола (Python)
│   ├── node_crypto.py          # ML-DSA-65 криптография
│   ├── time_bank.py            # TIME_BANK + Presence Proofs
│   ├── timechain.py            # Структура слайсов таймчейна
│   ├── leader_election.py      # Leader Election + AttackDetector
│   ├── breathing_sync.py       # Git-синхронизация
│   ├── montana_api.py          # HTTP API
│   └── montana_db.py           # База данных
│
├── Economics/                   # Экономическая модель
│   ├── 金元_WHITEPAPER.md       # Whitepaper
│   └── time_bank/           # TIME_BANK v3.0
│
├── Contracts/                   # Умные контракты
│   └── СПЕЦИФИКАЦИЯ.md
│
├── Communication/                # SMS + WebRTC
│   └── СПЕЦИФИКАЦИЯ.md
│
├── Keys/                       # Система ключей
│   └── СПЕЦИФИКАЦИЯ.md
│
├── Network/                        # P2P сеть
│   ├── ПИРИНГОВАЯ_БЕЛАЯ_КНИГА.md
│   └── ЗАЩИТА_СЕТИ_MONTANA.md
│
├── Genesis/                     # Генезис
│   └── GENESIS_PRICE.md
│
└── Юнона/                       # AI Security Agent
    └── junona_security.py

macOS/MontanaPresence/           # Кошелёк macOS
├── Crypto/
│   ├── MLDSA65.swift           # ML-DSA-65 (liboqs)
│   ├── MontanaSeed.swift       # BIP-39 + PBKDF2
│   └── BIP39Wordlist.swift     # 2048 слов
├── CryptoManager.swift          # Управление идентичностью
├── KeychainManager.swift        # Хранение ключей
└── PresenceEngine.swift         # Присутствие и датчики
```

## 9.2 Статус реализации

| Компонент | Статус |
|-----------|--------|
| ML-DSA-65 keygen/sign/verify | ✅ Работает |
| BIP-39 мнемоника (24 слова) | ✅ Работает |
| Детерминированная деривация ключей | ✅ Работает |
| Адреса mt... с контрольной суммой | ✅ Работает |
| Presence Proof (цепочка подписей) | ✅ Работает |
| TIME_BANK (эмиссия, халвинг, τ₁–τ₄) | ✅ Работает |
| TimeChain (структура слайсов) | ✅ Работает |
| 5-Node Leader Election | ✅ Работает |
| Breathing Sync | ✅ Работает |
| Attack Detection + Random Failover | ✅ Работает |
| Adaptive Cooldown (Sybil) | ✅ Работает |
| TLS 1.3 между узлами | ✅ Работает |
| macOS кошелёк | ✅ Работает |
| iOS кошелёк | ✅ Работает |
| HTTP API (баланс, присутствие) | ✅ Работает |
| Контракты с escrow | ✅ Работает |
| ML-KEM-768 (шифрование) | ⏳ Запланировано |
| Noise XX (гибридный обмен ключами) | ⏳ Запланировано |

---

## Заключение

Montana Protocol — три независимых слоя, связанных только математикой:

1. **Криптография** генерирует ключи и подписи. Офлайн. Чистая математика.
2. **Таймчейн** хранит транзакции и проверяет подписи. Не знает владельцев.
3. **Кошелёк** соединяет первое и второе. Показывает баланс, отправляет транзакции.

Консенсус ACP основан на единственном ресурсе, который невозможно подделать, купить или ускорить — **времени**.

```
Время — единственная реальная валюта.
1 Ɉ = 1 секунда доказанного присутствия.
ML-DSA-65 MAINNET — постквантовая защита с первого дня.
FIPS 204 compliant.
```

---

# КРАТКИЙ СПРАВОЧНИК

## Что такое Montana Protocol?

Протокол идеальных денег. Валюта 金元Ɉ основана на времени — единственном ресурсе, распределённом одинаково между всеми людьми. 1 Ɉ асимптотически стремится к 1 секунде. Постквантовая криптография ML-DSA-65 с первого дня.

## Ключевые числа

| Параметр | Значение |
|----------|----------|
| Алгоритм подписи | ML-DSA-65 (FIPS 204) |
| Private key | 4032 байт |
| Public key | 1952 байт |
| Signature | 3309 байт |
| Адрес | 42 символа (mt + 36 hex + 4 checksum) |
| Seed | BIP-39, 24 слова, PBKDF2-SHA512 |
| 1 Ɉ | $0.1605 USD = 12.04₽ RUB |
| Генезис цены | 12.03.2021 (Beeple: $69.3M / 5000 дней) |
| Генезис сети | 09.01.2026 |
| Узлов | 5 (Amsterdam, Moscow, Almaty, SPB, Novosibirsk) |
| Резерв | 21,000,000 минут (~40 лет) |
| Модель | UTXO (как Bitcoin) |
| Транзакции | Моментальные |

## Временные координаты

| Единица | Длительность | Что финализирует |
|---------|-------------|------------------|
| τ₁ | 1 минута | Транзакции |
| τ₂ | 10 минут | Эмиссия |
| τ₃ | 14 дней | Кулдауны, балансировка |
| τ₄ | 4 года | Халвинг ÷2 |

## Три слоя — кратко

```
КРИПТО:    seed → ключи → адрес → подпись (офлайн, чистая математика)
ТАЙМЧЕЙН:  слайсы τ₁→τ₂→τ₃→τ₄ (матрёшка), UTXO, ACP консенсус, эмиссия, халвинг
КОШЕЛЁК:   мост (ключи + таймчейн → баланс, отправка)

Связь между слоями = только математика. Нет центра.
```

## Консенсус ACP

Присутствие во времени. Время нельзя ускорить. 14 дней = 14 дней для всех.
```
1 секунда присутствия = 1 Ɉ × halving_coefficient
halving_coefficient = 1.0 / (2^n), где n — номер эпохи τ₄
```

## Отличие от Bitcoin/Ethereum

| | Bitcoin | Ethereum | Montana |
|---|---------|----------|---------|
| Консенсус | PoW (вычисления) | PoS (stake) | ACP (время) |
| Можно ускорить? | Да (ASIC) | Да (купить ETH) | **Нет** |
| Квантовая защита | Нет | Нет | **Да, с генезиса** |
| Транзакции | ~10 мин | ~12 сек | **Моментальные** (финализация τ₁ = 1 мин) |

## Юнона

AI-арбитр протокола. Совет Безопасности: Председатель (Claude) + Джипити (GPT) + Джемини (Gemini). Disney Strategy: Критик → Реалист → Мечтатель.

## Автор

**Alejandro Montana** — как Satoshi Nakamoto. Псевдоним.

---

```
Alejandro Montana
Montana Protocol v1.0
Февраль 2026

Ничто_Nothing_无_金元Ɉ
```