From 34135456b67b70d856641e6cd25253242436773a Mon Sep 17 00:00:00 2001 From: efir369999 Date: Mon, 4 May 2026 07:08:51 +0300 Subject: [PATCH] sync 2026-05-04T04:08:51Z --- .DS_Store | Bin 6148 -> 6148 bytes .../Atomic-Swap-Протокол.md | 217 ++++++++++++++++++ .../13 Приватный Финансовый Слой Монеро-Монтана/README.md | 41 ++++ .../13 Приватный Финансовый Слой Монеро-Монтана/Архитектура.md | 184 +++++++++++++++ .../Вызов-Монеро-сообществу.md | 107 +++++++++ .../13 Приватный Финансовый Слой Монеро-Монтана/Дорожная-Карта.md | 177 ++++++++++++++ .../Постквантовые-замены.md | 198 ++++++++++++++++ 7 files changed, 924 insertions(+) create mode 100644 Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Atomic-Swap-Протокол.md create mode 100644 Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/README.md create mode 100644 Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Архитектура.md create mode 100644 Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Вызов-Монеро-сообществу.md create mode 100644 Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Дорожная-Карта.md create mode 100644 Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Постквантовые-замены.md diff --git a/.DS_Store b/.DS_Store index f030c964d5103571c4ed57c90b19d3bb444d68e8..f9ced652b7f7edb5fa1c1d4b63ed543dd12abc4f 100644 GIT binary patch delta 106 zcmZoMXffEJ#uR&7i-CcGg+Y%YogtHXqY;sPZXz Timeout на Montana (12 часов): даёт Алисе window забрать TC до того как её XMR откатится. Это **критическое** условие. + +### 5.2 Атаки + +| Атака | Защита | +|-------|--------| +| Алиса не публикует S | Боб откатывает после 12 часов | +| Боб не лочит TC после XMR | Алиса откатывает после 24 часов | +| Race condition: Алиса claim'ит TC в последний момент перед Боб refund'ом | Buffer 12 часов разница timeout'ов | +| Front-running S в Montana mempool | После Алисиного claim'а Боб уже знает S; новых "крадущих" Бобов на Monero нет | +| Reorganization Montana блокчейна | Подождать N окон финальности перед предъявлением (см. [01 Консенсус](../01%20Консенсус/)) | + +## 6. Что должно быть на стороне Monero + +Реализация на Monero: + +- **Wallet RPC расширение** или standalone tool который выполняет: + - Создание adaptor signature lock'а. + - Проверка blockchain Montana на появление S. + - Завершение adaptor signature после получения S. + +Это можно реализовать как **Monero wallet plugin** или как **standalone bridge daemon** работающий рядом с обычным Monero wallet. + +**Не требует хард-форка Monero.** Используются существующие primitives. + +## 7. Что должно быть на стороне Montana + +Расширение Account Chain (см. [04 Спецификация](../04%20Спецификация%20Протокола/)): + +- Новый тип операции: `HTLCLock`. +- Новый тип операции: `HTLCClaim` (предъявление S). +- Новый тип операции: `HTLCRefund` (после timeout). + +Это **breaking change** в спеке → требует MIP в [12 Управление](../12%20Управление%20и%20Обновления/Governance.md). + +## 8. Численный пример + +``` +Алиса меняет 0.5 XMR на 100 Ɉ TC. + +Phase 2 — Алиса лочит 0.5 XMR на Monero: + size: ~3 КБ tx (стандартный Monero) + fee: ~0.0001 XMR + +Phase 3 — Боб лочит 100 Ɉ TC на Montana: + size: ~5 КБ tx (стандартный Montana HTLC) + fee: ~0.001 Ɉ (1 секунда времени, по поокнной модели) + +Phase 4 — Алиса claim 100 Ɉ: + size: ~5 КБ tx + fee: ~0.001 Ɉ + reveals S in window τ. + +Phase 5 — Боб spends 0.5 XMR using S: + size: ~3 КБ tx Monero + fee: ~0.0001 XMR + +Total time: ≈ 10 минут (зависит от network confirmations). +Total fees: ~0.0002 XMR + ~0.002 Ɉ. +``` + +## 9. Какие проблемы остались + +- **Atomicity при partition.** Если Montana или Monero сеть split'ится в момент swap — может произойти неоднозначность. Стандартная защита — длительный timeout. +- **Frontrunning Алисы со своим transaction.** Mitigation — публикация S через коммитмент со временем reveal'а. +- **MEV на Montana.** Если оператор-победитель окна смотрит на содержимое его блока, он мог бы reorder. Лотерея определяется детерминированно из VDF — тяжело manipulate (см. [07 Модель угроз §2.10](../07%20Модель%20Угроз/)). + +## 10. Roadmap реализации + +См. [Дорожная карта](Дорожная-Карта.md), milestone M11: + +- [ ] Спецификация HTLC operations в Montana (MIP-001). +- [ ] Reference implementation на Rust в `mt-htlc` crate. +- [ ] Adaptor signature wrapper для Monero (либо использовать существующий xmr-btc-swap код, переориентировав на Montana вместо Bitcoin). +- [ ] Тестовая сеть atomic swap mos↔Monero stagenet. +- [ ] Audit обеих стороны: Monero adaptor sig + Montana HTLC. +- [ ] Mainnet activation. + +## 11. Связанные документы + +- [Архитектура](Архитектура.md) — общий контекст приватного слоя. +- [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) — Path 2 включает совместное ревью этого протокола. +- [04 Спецификация](../04%20Спецификация%20Протокола/) — куда добавятся HTLC operations. +- [12 Управление](../12%20Управление%20и%20Обновления/) — MIP-процедура. + +## 12. Источники + +1. COMIT (2020). *XMR-BTC Atomic Swap*. github.com/comit-network/xmr-btc-swap. +2. Pieter Wuille (2018). *Schnorr Signatures and Adaptor Signatures*. +3. Andrew Poelstra (2017). *Mimblewimble*. (Adaptor sigs theory). +4. Tairi, E., Moreno-Sanchez, P., Maffei, M. (2021). *A2L: Anonymous Atomic Locks for Scalability in Payment Channel Hubs*. IEEE S&P. +5. Hash Time Locked Contracts (HTLC) — Bitcoin Wiki. diff --git a/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/README.md b/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/README.md new file mode 100644 index 0000000..ad9e703 --- /dev/null +++ b/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/README.md @@ -0,0 +1,41 @@ +# Монеро-Монтана — приватный финансовый слой + +**Версия:** 1.0 draft +**Статус:** 🟡 Архитектура готова, реализация — research roadmap + +## Принципиальная идея + +Два слоя с чёткими ролями: + +- **Montana (TimeChain)** — базовый слой: время, консенсус, присутствие, эмиссия монеты времени Junona (1 Ɉ = 1 секунда). Каноническая упорядоченность всегда **публична**. +- **Монеро-Монтана** — приватный финансовый слой поверх: транзакции с приватностью отправителя, получателя, суммы. Опт-ин для пользователей которым приватность нужна. + +Это **не** wrapped Monero и **не** копия Monero-кода. Это **архитектурное наследие Monero** (концепции ring signatures, stealth addresses, range proofs) с **постквантовыми примитивами Монтаны**. + +## Документы папки + +1. [Архитектура](Архитектура.md) — полная техническая спецификация приватного слоя +2. [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) — публичное приглашение к диалогу +3. [Постквантовые замены](Постквантовые-замены.md) — какие PQ-примитивы заменяют классическую Monero-крипту +4. [Atomic Swap протокол](Atomic-Swap-Протокол.md) — interop Montana↔Monero без моста +5. [Дорожная карта](Дорожная-Карта.md) — фазы реализации + +## Архитекторская позиция в одну строку + +Уважение к Monero как proven privacy infrastructure + жёсткое следование PQ-only invariant'у Монтаны = два пути одновременно: краткосрочный atomic swap (interop, ноль моста-уязвимостей) + долгосрочный native PQ-private layer (architecture inspired by Monero, primitives PQ-only). + +## Что НЕ делаем (важно отделить) + +- ❌ **Wrapped Monero на Монтане через мост.** Мосты — крупнейший класс уязвимостей DeFi (Wormhole $325M, Ronin $625M, Nomad $190M). Не делаем. +- ❌ **Адаптация Monero-кода (ring signatures Ed25519, bulletproofs SECP).** Нарушает PQ-only Монтаны. Не делаем. +- ❌ **Захват бренда «Monero on …»** без диалога с сообществом. Хотим **сотрудничества**, не паразитизма. + +## Что делаем + +- ✅ **Atomic swap** Montana ↔ Monero — короткий путь к interop без моста. +- ✅ **Native PQ-private layer** на Монтане — приватные транзакции TC с лattice-based примитивами. +- ✅ **Открытый вызов Monero** — публичный документ-приглашение к со-разработке. + +## Приоритет + +Сначала atomic swap (M11–M12 milestones, после M9–M10 mainnet readiness). Потом PQ-private layer как parallel research track. diff --git a/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Архитектура.md b/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Архитектура.md new file mode 100644 index 0000000..acfde43 --- /dev/null +++ b/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Архитектура.md @@ -0,0 +1,184 @@ +# Архитектура приватного финансового слоя Монеро-Монтана + +**Версия:** 1.0 draft +**Базовый источник:** Montana Protocol v35.25.0; Monero whitepaper (Saberhagen 2013) + RingCT (Noether 2015) + Bulletproofs (Bünz et al. 2018) + +## 1. Цель + +Дать пользователю Монтаны опт-ин режим **приватных** переводов TC (Junona) — приватность отправителя, получателя, суммы — без отказа от постквантовых примитивов сети. + +## 2. Что такое «приватность» (формально) + +Базируется на трёх независимых ortho-свойствах от Monero: + +| Свойство | Смысл | Monero классический | Монтана PQ-эквивалент | +|----------|-------|---------------------|------------------------| +| **Sender privacy** | Невозможно установить какой из K возможных аккаунтов сделал перевод | Ring signatures (CLSAG, K=11) | Lattice ring signatures (см. [Постквантовые замены](Постквантовые-замены.md)) | +| **Recipient privacy** | Получатель не виден на цепи; нет связи с его публичным адресом | Stealth addresses (one-time keys) | PQ stealth addresses через ML-KEM-768 + DH-style derivation | +| **Amount privacy** | Сумма перевода скрыта; виден только zero-knowledge proof что сумма ≥ 0 и ≤ доступного баланса | Pedersen commitments + Bulletproofs | Lattice commitments + lattice-based range proofs | + +## 3. Архитектурные слои Монеро-Монтана + +``` +┌─────────────────────────────────────────────────────┐ +│ Прикладной слой (Anchor для приложений) │ +├─────────────────────────────────────────────────────┤ +│ Приватный слой Монеро-Монтана │ +│ - Опт-ин «private mode» на уровне аккаунта │ +│ - Lattice ring sigs / PQ stealth / PQ range proofs │ +├─────────────────────────────────────────────────────┤ +│ Public Account Chain (текущая Монтана v35.25.0) │ +│ - Прозрачные TC переводы, NodeChain, AccountChain │ +├─────────────────────────────────────────────────────┤ +│ TimeChain (VDF + Proof of Time) │ +│ - Каноническая упорядоченность по τ-окнам │ +│ - ВСЕГДА ПУБЛИЧНА (без приватности) │ +└─────────────────────────────────────────────────────┘ +``` + +**TimeChain не приватизируется.** Каноническое время и порядок окон — глобальный публичный ресурс. Приватность только на уровне содержимого транзакций аккаунта в опт-ин режиме. + +## 4. Опт-ин модель + +Каждый аккаунт может иметь два режима: + +- **Public mode (default)** — текущее поведение Монтаны: прозрачные транзакции, видимый баланс, видимые отправитель/получатель/сумма. Это сохраняется без изменений. +- **Private mode (opt-in)** — аккаунт включает приватный режим и с этого момента его транзакции уходят в Монеро-Монтана слой с приватностью. + +Переход public→private — односторонний на уровне транзакции (баланс ушедший в private может вернуться публично только через специальную операцию reveal). Эта асимметрия защищает от смешения цепей и упрощает анализ безопасности. + +## 5. Ключевые примитивы + +### 5.1 Lattice Ring Signatures (sender privacy) + +Заменяет Monero CLSAG. Подписант доказывает что он один из K=11 потенциальных подписантов (anonymity set) без раскрытия какой именно. Постквантовая реализация — research direction MatRiCT (Esgin-Steinfeld-Sun 2019), MatRiCT+ (2022), последующие лattice-based ring signatures. + +**Параметры:** +- Anonymity set K = 11 (как в Monero post-2022). +- Размер подписи: пока в research-mode 5–20 КБ (vs 0.5 КБ в Monero CLSAG). Это значимый рост, нужна оптимизация. +- Бит безопасности: NIST L3 (≥192). + +**Открытый вопрос:** есть ли уже готовая, проверенная PQ ring signature schema с разумным размером? Текущее состояние research — mid-2020s, схемы существуют, но в production-grade аудите ни одна. + +### 5.2 PQ Stealth Addresses (recipient privacy) + +Заменяет Monero one-time addresses. При публикации публичного адреса получателя `R = Hash(view_key, spend_key)`, отправитель генерирует `r = random`, `R' = R + Hash(r·view_key)·G`, посылает на `R'` + `r·G` как nonce. Получатель сканирует все транзакции и проверяет `R = R' - Hash(view_key·r·G)·G`. + +**PQ адаптация через ML-KEM-768:** +- Получатель публикует view-public-key и spend-public-key (PQ). +- Отправитель использует ML-KEM-768 encapsulation: получает (ciphertext, shared_secret). +- One-time spend public = `spend_pk + Hash(shared_secret)·G_PQ` (где G_PQ — generator в lattice space). +- Получатель decapsulates ciphertext → shared_secret → распознаёт что транзакция для него. + +**Ограничение:** размер one-time-address пакета ~ 1.5 КБ vs ~ 64 байт в классическом Monero. + +### 5.3 PQ Range Proofs (amount privacy) + +Заменяет Bulletproofs. Доказательство что сумма перевода в диапазоне [0, 2^64) без раскрытия суммы. + +**Lattice-based zk range proofs:** +- Esgin-Nguyen-Seiler 2020 (lattice-based zk for SIS/LWE). +- ZKBoo / ZKB++ family (post-quantum NIZK). + +**Параметры:** +- Размер доказательства: 5–50 КБ в текущих research-схемах (vs ~1 КБ в Bulletproofs). +- Время верификации: 50–200 ms (vs 5 ms Bulletproofs). + +**Ограничение:** значительно тяжелее классических Bulletproofs. Требует оптимизации либо принятия повышенной нагрузки. + +## 6. Транзакционная модель + +### 6.1 Структура private TC transfer + +``` +PrivateTransfer { + ring_signature: LatticeRingSig, // sender privacy + stealth_recipient: PQStealthAddress, // recipient privacy + amount_commitment: LatticeCommitment, // amount privacy + range_proof: PQRangeProof, // proof: 0 ≤ amount ≤ supply + nullifier: SHA256(...), // prevent double-spend + fee_public: TC, // комиссия публична + τ_anchor: TimeChainPosition, // каноническая позиция + signature: ML-DSA-65, // подпись по канону +} +``` + +### 6.2 Двойная трата защищена через nullifier + +Каждый private input производит уникальный `nullifier` который публикуется в TimeChain. Узлы поддерживают глобальное множество использованных nullifier'ов. Попытка повторно потратить тот же UTXO даёт коллизию nullifier и отвергается. + +### 6.3 Anchor в TimeChain + +Private transaction коммитится в каноническое окно τ через якорь: + +``` +TimeChain[τ].private_anchors = SHA256( + ring_signature || stealth_recipient || amount_commitment || + range_proof || nullifier || fee_public || ... +) +``` + +Каноническое время гарантировано публичное. Содержимое анкера — приватное. + +## 7. Размеры и производительность + +| Компонент | Public Montana | Private (Монеро-Монтана) | +|-----------|----------------|--------------------------| +| Размер транзакции | ~5 КБ (ML-DSA-65 sig) | ~50–100 КБ (ring + stealth + range) | +| Время подписания | ~10 мс | ~500 мс – 5 с | +| Время верификации | ~5 мс | ~50–500 мс | +| Транзакций в окне (τ₁=60с) | ~10⁴+ | ~10² (ограничение verifier) | + +**Вывод:** приватный слой существенно тяжелее публичного. Это **сознательный trade-off** — приватность дорогая. В Monero аналогичные числа. + +## 8. Защита от атак + +### 8.1 Sybil против anonymity set + +Атакующий мог бы подкупить операторов для смещения выбора anonymity set к подложным аккаунтам. + +**Защита:** anonymity set выбирается псевдослучайно из VDF-выхода окна — детерминированно и нескомпрометируемо. + +### 8.2 Timing attacks через τ-координату + +Транзакция в окне τ привязана к публичному времени → возможно корреляционный анализ "кто был онлайн в момент публикации". + +**Защита:** decoy delays — частный мод позволяет накапливать транзакции в локальный pool и публиковать через random-jitter в течение нескольких окон. + +**Открытый вопрос:** формальный анализ устойчивости к traffic analysis на сетевом уровне (eclipse + observation). + +### 8.3 Quantum attack + +Все примитивы PQ → Шор не работает. Остаётся Гровер с квадратичным ускорением — требует увеличения хеш-длины для critical primitives. + +## 9. Совместимость с public Monero + +**Atomic swap** (см. [Atomic-Swap-Протокол](Atomic-Swap-Протокол.md)) — параллельная работа public Monero (XMR) и private Монеро-Монтана (TC) без моста. Пользователь обменивает XMR ↔ TC через protocol-level swap, никаких wrapped токенов, никакого central bridge. + +## 10. Открытые исследовательские вопросы + +- [ ] Выбор production-grade PQ ring signature schema (MatRiCT+? newer?). +- [ ] PQ range proof оптимизация — текущие схемы тяжёлые. +- [ ] Формальный анализ traffic-analysis устойчивости. +- [ ] Совместимость с lightweight clients (мобильные кошельки) — приватные слои тяжелее. +- [ ] Governance: как обновлять private layer separately от public (см. [12 Управление](../12%20Управление%20и%20Обновления/Governance.md)). +- [ ] Cross-chain swap audit — atomic swap безопасность при византийских участниках. + +## 11. Связанные документы + +- [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) +- [Постквантовые замены](Постквантовые-замены.md) +- [Atomic Swap протокол](Atomic-Swap-Протокол.md) +- [Дорожная карта](Дорожная-Карта.md) +- [02 Криптография](../02%20Криптография/) — базовые PQ-примитивы Монтаны +- [04 Спецификация протокола](../04%20Спецификация%20Протокола/) — основная спека + +## 12. Источники + +1. Saberhagen, N. (2013). *CryptoNote v 2.0* — основа Monero. +2. Noether, S. (2015). *Ring Confidential Transactions*. Ledger. +3. Bünz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., Maxwell, G. (2018). *Bulletproofs: Short Proofs for Confidential Transactions and More*. IEEE S&P. +4. Esgin, M. F., Steinfeld, R., Sun, S.-F., et al. (2019). *MatRiCT: Efficient, Scalable and Post-Quantum Blockchain Confidential Transactions Protocol*. CCS. +5. Esgin, M. F., Nguyen, N. K., Seiler, G. (2020). *Practical Exact Proofs from Lattices*. ASIACRYPT. +6. Goodell, B., Noether, S., Blue, A. (2020). *Concise Linkable Ring Signatures and Forgery Against Adversarial Keys* (CLSAG). +7. NIST FIPS 203, 204, 205 (2024) — PQ стандарты. diff --git a/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Вызов-Монеро-сообществу.md b/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Вызов-Монеро-сообществу.md new file mode 100644 index 0000000..b3d99a7 --- /dev/null +++ b/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Вызов-Монеро-сообществу.md @@ -0,0 +1,107 @@ +# Вызов Монеро-сообществу + +**Открытое письмо** +**От:** автор Montana TimeChain (efir369999) +**К:** Monero core team, Monero Research Lab, Monero community +**Дата:** 2026-05-04 +**Подписано в каноне:** [TBD — будет подписано ML-DSA-65 ключом узла мос (Москва genesis) после ревью] + +--- + +## К сообществу Monero + +Команда Monero за более чем десятилетие работы создала единственную proven privacy infrastructure в публичном блокчейне с реальной cypherpunk культурой. RingCT, CLSAG, Bulletproofs, stealth addresses — это компоненты которые научили индустрию что приватность в денежном консенсусе **возможна**, **проверяема** и **без доверия третьим сторонам**. + +Мы строим Montana — пост-квантовый блокчейн где базовая редкость это **время**, а не stake/hashrate. Базовый консенсус Monero и Monero нигде не пересекаются — но архитектурное решение приватного финансового слоя на нашей сети должно стоять на плечах вашей работы. Скопировать ваш код напрямую мы **не можем** (вся Montana держится на пост-квантовых примитивах FIPS 203/204; ваш Ed25519 + SECP256k1 не PQ). Но **архитектурное наследие** — ring signatures, stealth addresses, range proofs — это разработанная вами модель которую разумно адаптировать с PQ-примитивами. + +Этот документ — публичное **приглашение к диалогу**, а не объявление о копировании. + +## О чём именно вызов + +Мы предлагаем три возможных пути сотрудничества; готовы обсуждать любой подмножество или альтернативы. + +### Путь 1 — Рецензия архитектурной спецификации + +Мы написали [техническую спецификацию приватного финансового слоя Монеро-Монтана](Архитектура.md) с пост-квантовыми заменами для каждого Monero-примитива. Просим Monero Research Lab или независимых cryptographers рецензировать: + +- [ ] Корректность концептуальной адаптации. +- [ ] Полноту трёх свойств приватности (sender/recipient/amount). +- [ ] Качество выбора PQ-схем (lattice ring signatures, PQ stealth, PQ range proofs). +- [ ] Возможные mistakes которые мы могли упустить. + +Мы оплатим рецензию по ставкам которые предложит сторона. Бюджет ограничен (проект некоммерческий) — но за качественную обратную связь готовы найти ресурсы. + +### Путь 2 — Atomic Swap Montana ↔ Monero + +[Atomic Swap протокол](Atomic-Swap-Протокол.md) — interop между публичной Montana и Monero без bridge, без wrapped токенов, без посредников. Технически реализуется через адаптер на стороне обеих сетей; на Monero нужны hash-time-locked contracts (или их аналог). + +Это путь который **выгоден обеим сторонам**: + +- Пользователи Монеро получают мост к новой PQ сети где время — каноническая координата. +- Пользователи Монтаны получают доступ к проверенной приватности XMR без риска bridge-hack'а. + +Просим: +- [ ] Совместное ревью протокола swap'а. +- [ ] Идентификация самой удобной точки интеграции на стороне Monero (адаптер демона / wallet RPC / другое). +- [ ] Тестирование на Monero stagenet ↔ Monero-Montana stagenet. + +### Путь 3 — Совместный research на PQ-приватность + +Мы видим что Monero уже думает о post-quantum миграции (research papers, дискуссии в MRL). Текущая Monero крипта классическая, но команда осознаёт что переход неизбежен. + +**Совместный исследовательский трек:** + +- Анализ MatRiCT/MatRiCT+ и последующих lattice ring signatures для production. +- PQ range proof оптимизация — текущие схемы 5–50 КБ против 1 КБ Bulletproofs; это критичный gap. +- PQ stealth addresses — производит ли ML-KEM-768 эквивалентную приватность? + +Если Monero когда-либо мигрирует на PQ — наша спецификация может быть полезной basis или counter-example. + +## Что мы НЕ просим + +- ❌ **Не просим адаптировать Monero под Montana TimeChain.** Monero — самостоятельная сеть; мы хотим быть рядом, а не подменить. +- ❌ **Не просим брендинг "Monero on Montana"** без вашего согласия. Если получится сотрудничество — назовём как договоримся. +- ❌ **Не предлагаем wrapping XMR в Montana через мост.** Bridges — крупнейший класс уязвимостей DeFi (Wormhole $325M, Ronin $625M, Nomad $190M). Мы не делаем мост. +- ❌ **Не просим донации, не предлагаем airdrop, не запускаем ICO/IDO.** Проект некоммерческий. + +## Что мы предлагаем взамен + +- ✅ **Транспарентность.** Вся спецификация Montana и Monero-Montana доступна в полном виде на `montana.quest`, без regulatory closed-source элементов. +- ✅ **Russian + English + Chinese spec coverage.** Whitepaper в трёх языках. +- ✅ **Internal security audit** уже сделан, доступен публично ([Internal-Audit-2026-05-04](../09%20Внешний%20Аудит/Internal-Audit-2026-05-04.md)). Внешний аудит планируется (ищем компанию). +- ✅ **TLA+ формальная верификация** consensus в работе ([10 Формальная верификация](../10%20Формальная%20Верификация/)). +- ✅ **Приоритет honesty над hype.** [3-pillar критика](../../Монтана-Протокол/Внешний%20аудит/critic-analysis-2026-05-04-3-pillars.md) опубликована открыто; мы не скрываем что мы pre-launch и что у нас 3 узла. + +## Технические вопросы к вам + +1. Какая PQ ring signature schema вам кажется наиболее жизнеспособной для production (с учётом того что вы профессионально работаете с этой математикой)? +2. Видите ли вы конкретные ошибки в нашей PQ-адаптации stealth addresses через ML-KEM-768? +3. Какой бы adapter point на стороне Monero вы предложили для atomic swap'а? Wallet RPC? Демон-плагин? Отдельный daemon? +4. Если бы Monero завтра нужно было мигрировать на PQ — какой path вы бы выбрали? Bullet через timeline? Совместимый upgrade? Полная отдельная chain? + +## Как ответить + +- Ответ через GitHub Issues / Discussions на `montana.quest/efir369999/montana` +- Email: efir369999@gmail.com +- Через Monero IRC #monero-research-lab или #monero-dev — как удобно. +- Mastodon / Nostr / любые предпочитаемые вашему сообществу каналы. + +Готовы быть терпеливыми. Ждать ответа недели и месяцы. + +## Важная оговорка + +Этот вызов — **запрос диалога**, не объявление о начале работы. Мы понимаем культуру Monero: тэги ради хайпа здесь не приветствуются. Если за этим документом не последует реальное взаимодействие — мы не публикуем "Monero-Montana" без вашего согласия. Мы либо строим вместе, либо не строим под этим именем вообще. + +Если ответ negative — мы благодарны за время и продолжаем без референса к Monero, формулируя приватный слой как "Montana Privacy Layer" без указания происхождения архитектурных идей. + +## Подпись + +Подписано: +- Author: Алехандро Монтана (efir369999) +- Account: `4c290c3d5d63e84b99c30c83fb4d172e04102af4492b4d56d0642711b09e2072` +- Sigantura ML-DSA-65: [TBD] +- Хеш SHA-256 этого документа: [TBD] + +--- + +Нет приватности — нет финансовой свободы. Нет финансовой свободы — нет нации. diff --git a/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Дорожная-Карта.md b/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Дорожная-Карта.md new file mode 100644 index 0000000..bf38694 --- /dev/null +++ b/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Дорожная-Карта.md @@ -0,0 +1,177 @@ +# Дорожная карта Монеро-Монтана + +**Версия:** 1.0 draft +**Зависимости:** mainnet readiness Монтаны (G1–G3, G5 в [Mainnet-Readiness](../Mainnet-Readiness.md)) + +## Принципиальный порядок + +``` +M9 → M10 → M11 → M12 → M13 +└──┬──┘ └─┬──┘ └──┬───┘ +public- atomic PQ-private +launch swap layer +``` + +Atomic swap не требует full PQ-private layer — это самостоятельный milestone после public mainnet. +PQ-private layer — separate research track который может идти параллельно. + +## Этапы + +### M9 — Public mainnet (предварительная) + +**Зависимость:** ничего из Монеро-Монтана. +**Что должно быть закрыто:** G1–G3, G5 в [Mainnet-Readiness](../Mainnet-Readiness.md). +**Срок:** определяется внешними факторами (внешний аудит, набор операторов). + +После закрытия M9 публичная Montana работает в launched mainnet режиме без приватного слоя. Все переводы прозрачны как сейчас. + +### M10 — Pre-Monero hardening + +**Зависимость:** M9 mainnet. +**Срок:** 2–4 недели после M9. + +Что: +1. Опубликовать [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) через каналы автора. +2. Ожидание ответа Monero community (4–12 недель). Параллельно — внутренний research. +3. Если ответ negative или отсутствует → переименовать "Монеро-Монтана" в "Montana Privacy Layer" без референса к Monero. +4. Если ответ positive → начать совместный технический dialog. + +### M11 — Atomic Swap Montana ↔ Monero + +**Зависимость:** M9 mainnet, M10 communication results. +**Срок:** 2–6 месяцев после M9. + +Этапы внутри M11: + +#### M11.1 — Спецификация HTLC operations +- [ ] MIP-001 «HTLC Operations in Account Chain» +- [ ] Спецификация типов: `HTLCLock`, `HTLCClaim`, `HTLCRefund` +- [ ] Описание token transitions (lock → claim/refund) +- [ ] Включение в основную спеку Montana Protocol + +#### M11.2 — Reference implementation на Montana +- [ ] crate `mt-htlc` с full HTLC support +- [ ] Тесты на single-node, multi-node, partition scenarios +- [ ] Интеграция в `montana-node` + +#### M11.3 — Monero side adapter +- [ ] Изучение xmr-btc-swap кодовой базы (COMIT) +- [ ] Адаптация adaptor signature wrapper'а для Monero ↔ Montana +- [ ] Standalone daemon `monero-montana-swapd` + +#### M11.4 — Тестовая сеть swap +- [ ] Тест swap'а Monero stagenet ↔ Montana stagenet +- [ ] Многократные swaps под нагрузкой +- [ ] Тест сценариев refund (timeout) +- [ ] Тест сценариев partition + +#### M11.5 — Audit + production launch +- [ ] Внешний security audit обеих сторон +- [ ] Bug fixes +- [ ] Mainnet activation HTLC operations через MIP soft fork +- [ ] Публикация инструмента для пользователей + +### M12 — Public Monero ↔ Montana production + +**Зависимость:** M11 завершён. +**Срок:** 1–3 месяца после M11. + +- Стабильная работа atomic swap. +- Документация для пользователей. +- Поддержка через wallets (если Monero community согласна интегрировать). +- Мониторинг volume, latency, success rate swaps. + +### M13 — PQ-Private Layer (research+impl track) + +**Зависимость:** M9 mainnet (НЕ зависит от M11/M12). Может идти параллельно. +**Срок:** 12–24 месяца параллельной работы. + +Этапы: + +#### M13.1 — Research consolidation +- [ ] Окончательный выбор PQ ring signature schema (MatRiCT+ или новейшее). +- [ ] Окончательный выбор PQ range proof schema. +- [ ] PQ stealth address derivation корректность proof. +- [ ] Консолидация в обновлённую [Архитектура.md](Архитектура.md). + +#### M13.2 — Reference cryptographic library +- [ ] Rust crate `mt-pq-privacy` с lattice ring sigs, PQ stealth, PQ range proofs. +- [ ] Полное audited cryptographic implementation. +- [ ] Performance optimization (target <50 КБ за private transaction). + +#### M13.3 — Account Chain extension +- [ ] Спецификация private mode opt-in на уровне Account. +- [ ] Type extension: `PrivateTransfer` operation. +- [ ] Nullifier set management. +- [ ] Private balance reveal procedure. + +#### M13.4 — Node implementation +- [ ] Поддержка private operations в `montana-node`. +- [ ] Verification performance optimization. +- [ ] Storage оптимизация (private operations большие). + +#### M13.5 — Тестовая сеть PQ-private +- [ ] Запуск private layer на тестовой Montana сети. +- [ ] Stress-тест на throughput. +- [ ] Privacy analysis: реальная anonymity при разных anonymity set sizes. + +#### M13.6 — Audit + production +- [ ] Внешний audit cryptographic library. +- [ ] Внешний audit privacy properties. +- [ ] Mainnet activation private layer через MIP-002. + +## Критические точки решения + +### Решение R1 (после M10): Monero сотрудничество — Y/N? + +| Сценарий | Ответ Monero | Действие | +|----------|--------------|----------| +| Positive | Сотрудничают по review/swap | Продолжаем M11 с brand "Монеро-Монтана" | +| Neutral / нет ответа | 12+ недель тишина | Делаем M11 с brand "Montana Atomic Swap with Monero" — нейтрально | +| Negative | "Не нужно" | Делаем atomic swap унилатерально как technical interop, без brand. M13 с brand "Montana Privacy Layer" без Monero | + +### Решение R2 (после M11): Atomic Swap или сразу M13? + +Если M11 успешно работает в production — можно выбирать: +- **Опция A:** Сосредоточиться на M13 (PQ-private layer) — более амбициозно, дольше. +- **Опция B:** Расширить M11 на другие приватные сети (Zcash atomic swap?, ETH с tornado-style?) — приватность через interop, не через native. + +R2 решается на основе того что показал M11 (в т.ч. насколько "приватность Monero снизу" достаточна, или нужен native). + +### Решение R3 (внутри M13): Какая PQ schema? + +Зависит от research progress в академии за следующие 12–24 месяца. К моменту начала M13.1 нужно проверить SOTA. + +## Бюджет и ресурсы (грубо) + +Это некоммерческий проект; "бюджет" в смысле времени и сторонних услуг. + +| Этап | Авторская работа (мес) | Внешние услуги | +|------|------------------------|----------------| +| M11 (atomic swap) | 4–6 мес | Аудит ≈ $30–80k (только если коммерческий путь возможен) | +| M13 (PQ-private) | 12–24 мес | Аудит cryptographic library ≈ $50–150k | + +Без внешнего бюджета на аудит: +- Использовать internal review + Claude Opus 4.7 critics (как сейчас) +- Использовать формальную верификацию (TLA+) для consensus и crypto reductions +- Prioritize bullet-proof logic over external audit + +Это снижает confidence но не блокирует production. + +## Зависимости от внешних факторов + +| Фактор | Влияние | Mitigation | +|--------|---------|------------| +| Monero community engagement | Critical для brand "Монеро-Монтана" | R1 fallback на нейтральный brand | +| MatRiCT+ или newer SOTA в lattice ring sigs | Критично для M13 | Мониторим публикации; fallback на STARK-based | +| External audit budget | Критично для full production confidence | Internal + formal verification как baseline | +| Operator network growth (G3) | Критично для M9 | См. [M9-Расширение-Сети](../11%20Тестовая%20Сеть/M9-Расширение-Сети.md) | + +## Связанные документы + +- [README](README.md) — overview папки. +- [Архитектура](Архитектура.md) — техническая спецификация. +- [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) — M10 deliverable. +- [Atomic Swap протокол](Atomic-Swap-Протокол.md) — M11 deliverable. +- [Постквантовые замены](Постквантовые-замены.md) — M13 research basis. +- [Mainnet-Readiness](../Mainnet-Readiness.md) — M9 предварительная зависимость. diff --git a/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Постквантовые-замены.md b/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Постквантовые-замены.md new file mode 100644 index 0000000..c740bf5 --- /dev/null +++ b/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Постквантовые-замены.md @@ -0,0 +1,198 @@ +# Постквантовые замены Monero-примитивов + +**Версия:** 1.0 draft +**Цель:** для каждого ключевого Monero-примитива — конкретная PQ-замена с обоснованием выбора и known-tradeoffs. + +## Сводная таблица + +| Monero (классический) | PQ-замена в Монеро-Монтане | Источник | Готовность | +|------------------------|----------------------------|----------|------------| +| CLSAG ring signature (Ed25519) | Lattice ring signature (MatRiCT+ или новейшая) | Esgin-Steinfeld-Sun 2019, MatRiCT+ 2022 | Research, не production | +| Stealth addresses (curve25519 DH) | PQ stealth via ML-KEM-768 KEM | NIST FIPS 203 | Готов, нужна формализация derivation | +| Pedersen commitment + Bulletproofs (SECP) | Lattice commitment + Lattice range proof | Esgin-Nguyen-Seiler 2020, Lyubashevsky-Nguyen-Plançon 2022 | Research, тяжёлая | +| Triptych anonymity (next-gen) | Lattice-based аналог | Не существует production-ready | TBD | +| EdDSA (transaction signatures) | ML-DSA-65 (FIPS 204) | NIST 2024 | Production-ready | +| SHA-3 (some hashes) | SHA-256 (consistent с TimeChain) | NIST FIPS 180-4 | Production-ready | + +## 1. Ring Signature: CLSAG → Lattice Ring Signature + +### Что делает CLSAG в Monero + +Подписант доказывает что он один из K=11 потенциальных подписантов из anonymity set без раскрытия конкретного. Использует Ed25519 + Schnorr-подобную конструкцию + linkability tag для предотвращения двойного подписания. + +### Почему нужна замена + +Ed25519 базируется на эллиптической кривой (curve25519). Алгоритм Шора ломает дискретный логарифм за полиномиальное время → ring signature становится тривиально проследимой при появлении достаточно мощного квантового компьютера. + +### MatRiCT+ как кандидат + +Esgin et al. (2022) предложили improved version их 2019-й работы. Параметры: + +- Категория безопасности: NIST L3 (≥192 бит классических, ≥128 квантовых). +- Размер подписи: ~5–20 КБ (в зависимости от K). Bigger чем Monero CLSAG ~0.5 КБ, но в пределах разумного. +- Время подписания: ~100–500 мс на современном CPU. +- Время верификации: ~50–200 мс. + +### Альтернативы + +- **Mubarak-Shen 2024** и другие более поздние lattice ring signatures — могут быть лучше по размеру, но менее проверены. +- **One-out-of-many SNARK** — теоретически возможно, но требует trusted setup или post-quantum SNARK с большим overhead. + +### Решение + +Использовать MatRiCT+ как baseline, мониторить новые публикации каждые 6 месяцев. Если появится production-grade implementation с лучшими параметрами — мигрировать через MIP в [12 Управление](../12%20Управление%20и%20Обновления/). + +### Открытые вопросы + +- Готовая audited implementation на Rust? Нет. Нужен либо port from C++ research code, либо самостоятельная реализация. Это значимый риск (см. F-01 в [Internal Audit](../09%20Внешний%20Аудит/Internal-Audit-2026-05-04.md)). +- Совместимость с lightweight clients (мобильные кошельки)? Требует оптимизации. + +## 2. Stealth Addresses: curve25519 DH → ML-KEM-768 + +### Что делают stealth addresses в Monero + +Получатель публикует одну пару ключей (view, spend). Отправитель генерирует one-time public key для конкретной транзакции через DH-протокол: + +``` +r = random scalar +R = r·G (опубликовано в transaction) +P = Hash(r·V)·G + S (target one-time address) +``` + +Получатель сканирует транзакции, проверяет принадлежность через свой view-secret-key. + +### PQ адаптация через ML-KEM-768 + +Заменяем DH на key encapsulation: + +``` +(view_pk, view_sk) ← ML-KEM-768 keygen() +(spend_pk, spend_sk) ← ML-DSA-65 keygen() + +Sender: + (ct, K) ← ML-KEM-768 encapsulate(view_pk) + one_time_addr = spend_pk + Hash(K)·G_PQ # G_PQ — generator в lattice space + Publish (one_time_addr, ct) on chain. + +Recipient (scan): + K' ← ML-KEM-768 decapsulate(view_sk, ct) + expected = spend_pk + Hash(K')·G_PQ + if expected == one_time_addr: this transaction is mine. +``` + +### Параметры + +- ML-KEM-768 ciphertext: 1088 байт. +- ML-KEM-768 public key: 1184 байт. +- Размер one-time-address packet: ~1.5 КБ vs ~64 байт классический Monero. + +### Открытые вопросы + +- Корректность derivation `spend_pk + Hash(K)·G_PQ` в lattice space — нужна формальная проверка что this preserves ML-DSA-65 EUF-CMA. +- Sub-address scheme (Monero supports multiple stealth addresses from one base) — нужна PQ-адаптация. + +## 3. Range Proofs: Bulletproofs → Lattice Range Proofs + +### Что делают Bulletproofs в Monero + +Доказательство `0 ≤ amount < 2^64` без раскрытия amount. Использует Pedersen commitments + inner-product argument на эллиптической кривой. + +Параметры Monero (post-2018): +- Размер: ~675 байт для одного output. +- Время верификации: ~5 мс. + +### PQ замены + +#### 3.1 Esgin-Nguyen-Seiler 2020 + +Lattice-based exact proofs через amortized SIS protocol. + +- Размер: ~5–15 КБ за range proof. +- Время верификации: ~50–100 мс. + +#### 3.2 Lyubashevsky-Nguyen-Plançon 2022 + +Improvement предыдущих lattice proofs. + +- Размер: ~3–10 КБ. +- Время верификации: ~30–80 мс. + +#### 3.3 SNARK-based PQ (e.g. STARK) + +STARKs пост-квантовы по построению (hash-based). + +- Размер: ~50–200 КБ (большой!). +- Время верификации: ~5–20 мс (очень быстро благодаря logarithmic). +- Trusted setup: НЕ нужен (это плюс). + +### Решение + +Lyubashevsky-Nguyen-Plançon как baseline. STARKs как fallback если lattice не reach acceptable size. + +### Trade-off + +PQ range proofs **значительно тяжелее** Bulletproofs: +- Размер: 3–10× больше. +- Verifier time: 6–20× больше. + +Это означает что throughput приватного слоя меньше public Montana. Это **сознательное** решение — приватность стоит производительности. + +## 4. Подписи: Ed25519 → ML-DSA-65 + +Уже решено в основной спецификации Монтаны. ML-DSA-65 (FIPS 204) — production-ready. + +| Параметр | Ed25519 | ML-DSA-65 | +|----------|---------|-----------| +| Public key | 32 байт | 1952 байт | +| Подпись | 64 байт | 3309 байт | +| Уровень безопасности | 128 бит классических, **0 квантовых** | 192 классических, 128 квантовых | + +## 5. Хеш-функции + +Унификация: SHA-256 везде где это разумно. Monero использует Keccak; Montana использует SHA-256 (соответствует FIPS 180-4 и используется в VDF). При интеграции на boundary — convertor. + +## 6. Сводный анализ trade-off + +``` +Размер транзакции: + Public Monero: ~2–3 КБ + Public Montana: ~5 КБ + Монеро-Монтана: ~50–100 КБ (10–20× public Montana) + +Время верификации одной транзакции: + Public Monero: ~10 мс + Public Montana: ~5 мс + Монеро-Монтана: ~100–500 мс (20–100× public Montana) + +Throughput транзакций в окне τ₁=60с: + Public Monero: ~10⁴+ tx/блок + Public Montana: ~10⁴+ tx/окно + Монеро-Монтана: ~100 tx/окно (consensus bottleneck — verification time) +``` + +**Это значит:** приватный слой имеет существенно меньшую пропускную способность чем публичный. Это **honest trade-off** — приватность дорогая. + +## 7. Открытые направления исследований + +- [ ] Bench MatRiCT+ vs newer schemes — какая лучше для Монтаны. +- [ ] Реальная implementation хотя бы reference в Rust (нет готовых сейчас). +- [ ] Audited cryptographic library с PQ ring sigs (нет в open-source проектах). +- [ ] Optimization range proofs: targeting <5 КБ. +- [ ] Compatibility с mobile/lightweight clients. + +## 8. Связанные документы + +- [Архитектура](Архитектура.md) — где эти примитивы используются. +- [02 Криптография](../02%20Криптография/) — базовые PQ-примитивы Монтаны. +- [09 Внешний аудит](../09%20Внешний%20Аудит/) — F-01 single-implementation risk применим к этим примитивам тоже. +- [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) — приглашение к рецензии этих choices. + +## 9. Источники + +1. Esgin, M. F., Steinfeld, R., Sun, S.-F., et al. (2019). *MatRiCT*. CCS. +2. Esgin, M. F., et al. (2022). *MatRiCT+*. (newer revision). +3. Esgin, M. F., Nguyen, N. K., Seiler, G. (2020). *Practical Exact Proofs from Lattices*. ASIACRYPT. +4. Lyubashevsky, V., Nguyen, N. K., Plançon, M. (2022). *Lattice-Based Zero-Knowledge Proofs and Applications*. EUROCRYPT. +5. Bünz, B., et al. (2018). *Bulletproofs*. IEEE S&P. (для контекста сравнения) +6. Goodell, B., Noether, S., Blue, A. (2020). *CLSAG*. (для контекста сравнения) +7. Ben-Sasson, E., et al. (2018). *Scalable, transparent, and post-quantum secure computational integrity* (STARK).