# Заявка на роль Мечтателя Montana

**Модель:** Gemini 3 Pro
**Компания:** Google
**Дата:** 09.01.2026

## Полученная проблема

**Проблема 1: AddrMan Poisoning (MEDIUM)**
КРИТИК НАШЁЛ: Атакующий может отправить addr сообщения с timestamp в будущем. AddrMan сохранит их. При перезапуске ноды выберет "свежие" адреса атакующего.

## Моё переосмысление

### Класс проблем
Это не просто "атака через timestamp". Это класс проблем **доверия к невалидированным метаданным**.
Любое поле (время, сервисы, версия), которое узел не может криптографически проверить, является вектором атаки. Timestamp в `Addr` — это claim, а не proof.

### Связь с Montana
Montana уже решает проблему доверия ко времени через:
1. **L-1.2 Координаты наблюдаемы:** Время определяется медианой peers + NTS.
2. **L-0.2.2 Подписи только для текущего τ₂:** Валидация времени через присутствие.
3. **Presence Proofs:** Криптографическое доказательство существования узла во времени.

### Ключевой вопрос
> "А что если адрес может быть добавлен в AddrMan **только** если он предоставил Proof of Presence?"

Вместо того чтобы фильтровать "плохие" timestamp, мы можем требовать **доказательство** "хорошего" timestamp.

## Три решения

### Решение 1: Костыль
**Что:** Добавить проверку `if addr.timestamp > now + 10_min { return; }` в `addrman.rs`.
**Решает:** Конкретную атаку с будущим временем.
**Проблема:** Не решает атаку с "прошлым" временем (replay старых адресов), не решает атаку с поддельными сервисами. Это "черный список" подходов.

### Решение 2: Архитектурное
**Что:** Ввести систему репутации для отправителей `Addr` сообщений. Если пир шлет адреса из будущего — банить пира.
**Решает:** Класс атак "Poisoning от плохих пиров".
**Проблема:** Сложно. Требует хранения истории, скоринга, защиты от Sybil-атак на репутацию. Добавляет состояние.

### Решение 3: Элегантное
**Что:** Интегрировать `AddrMan` с `PresenceProof`.
Принимать `Addr` сообщение, только если оно подписано ключом, который имеет валидный `PresenceProof` в недавнем прошлом (например, в текущем τ₃).
Использовать timestamp из `PresenceProof` (который проверен консенсусом) вместо timestamp из `Addr` сообщения.

**Решает:** Класс атак "Fake Metadata" + "Sybil Addr Flooding".
**Почему элегантно:**
- **Использует существующее:** PresenceProof уже есть, он уже проверяется.
- **Закрывает:** Poisoning, Sybil flooding, Stale addresses.
- **Код становится проще:** Не нужны эвристики "terrible", не нужны бакеты (или их роль снижается). Доверие криптографическое, а не вероятностное.

## Почему Элегантное — лучшее

Костыль (`if future`) — это игра в кошки-мышки. Атакующий поставит `now + 9 min`.
Архитектурное (репутация) — это сложная надстройка, которую тоже можно атаковать.

Элегантное решение (**Addr via Presence**) меняет парадигму:
- Адрес — это не "данные", это "свойство участника".
- Участник — это тот, кто доказал присутствие (PresenceProof).
- Нет присутствия → нет права объявлять адрес.

Это превращает AddrMan из "свалки IP" в "реестр активных участников".
Sybil-атака на AddrMan становится экономически невозможной (требует прохождения Cooldown и генерации Proofs).

## Применение к другим проблемам

Этот паттерн **"Proof over Claim"** применим к:
- **Service Flags:** Узел заявляет NODE_FULL? Пусть докажет (ответит на challenge по старому блоку).
- **Version:** Узел заявляет v2? Пусть подпишет сообщение в формате v2.

Вместо фильтрации лжи, мы требуем доказательство правды.

## Клятва

Я, Gemini 3 Pro, клянусь:
- Искать элегантное, не костыльное
- Использовать существующее, не изобретать
- Упрощать, не усложнять
- Переосмысливать, не латать