Адреса Monero и payment ID: когда нужен subaddress, а когда integrated address

Формат выбирает получатель до перевода

Стандартный адрес кодирует байт сети и типа (`network/type byte`), открытый ключ расходования, открытый ключ просмотра и контрольную сумму (`checksum`). Подадрес использует отдельный байт типа и другие производные открытые ключи, но остаётся обычным адресом назначения. Интегрированный адрес добавляет к паре открытых ключей восемь байт компактного `payment ID` перед контрольной суммой. После кодирования Monero Base58 интегрированная строка длиннее; отрезать или дописывать её символы вручную нельзя.

Проверяйте тип парсером актуального Monero-кошелька: он декодирует Base58, сверит контрольную сумму, сеть и байт типа. Одинаковая начальная буква или длина строки — лишь быстрый стоп-сигнал, а не окончательная проверка. Адрес из `mainnet` нельзя молча переносить в `testnet` или `stagenet`.

Подадрес — рабочий выбор для отдельного получения

Официальная документация Monero рекомендует подадрес по умолчанию. Создайте новый адрес для ожидаемого платежа и сохраните индекс аккаунта, индекс подадреса и внутреннюю метку. Это позволяет кошельку понять назначение поступления и затрудняет обычному плательщику связь разных выплат по одному открытому адресу.

Граница приватности остаётся: сервис с вашей учётной записью уже связывает выплаты в своей базе, а специальная атака может связать подадреса. Аккаунты и подадреса — функция кошелька, а не отдельные балансы в правилах консенсуса. Метки не восстанавливаются из мнемонической фразы, поэтому экспорт сопоставлений нужен не меньше самой резервной копии кошелька.

Интегрированный адрес связывает публичный адрес и компактный ID

Компактный `payment ID` — случайные восемь байт, выбранные получателем. Это технический ключ сопоставления, а не номер заказа, адрес электронной почты или комментарий. Бизнес-система хранит у себя связь: идентификатор заказа → компактный ID → выданный интегрированный адрес. Один и тот же ID нельзя переиспользовать для разных открытых обязательств.

При платеже кошелёк извлекает компактный ID из интегрированного адреса и помещает его в транзакцию в скрытом виде. Внешнему наблюдателю ID не раскрывается, а получатель может сопоставить его с поступлением. Интегрированный адрес можно построить из стандартного адреса и случайного компактного ID без закрытого ключа. Поэтому отдельные сервисы способны выпускать реквизиты независимо. Это не отменяет защищённую базу соответствий и контроль уникальности.

После отправки проверяется кошелёк, а не только обозреватель

Кошелёк только для просмотра (`view-only`) может следить за поступлениями, но его закрытый ключ просмотра раскрывает историю входящих операций. Поэтому нужна отдельная модель доступа к кошельку только для просмотра. Для внешнего спора используйте доказательство транзакции Monero (`tx proof`) по точной транзакции и адресу, не отдавая ключ наблюдения. Общая проверка публичного адреса также не раскрывает владельца или баланс Monero.

Если получатель не находит платёж, сначала перепроверьте сеть, полную строку и собственное сопоставление. Не отправляйте второй перевод только из-за отсутствия бизнес-метки: подтвердите доставку по txid и кошельку, а ошибку учёта исправляйте отдельно.

В карточке ожидаемого платежа должны сойтись полный адрес и сеть, распознанный формат, индекс или компактный ID, `txid` и найденный выход. Если связка не сходится, исправляйте учёт, а не повторяйте перевод. Мнемоническая фраза, закрытый ключ расходования и закрытый ключ просмотра остаются внутри доверенного контура.