Доказательство связано с адресом и челленджем
- Tx proof связывает конкретные transaction ID, адрес и message; перепроверяйте все три поля вне чата с доказательством.
- Получателю передают proof string, а не seed-фразу, private spend/view key или файл кошелька.
- Положительный результат подтверждает выходы этой транзакции для адреса, но не текущую spendability и не личность отправителя.
| Механизм | Что проверяет | Главная граница |
|---|---|---|
| Tx proof | Получил ли точный адрес выходы указанной транзакции | Не доказывает личность и текущую spendability |
| Spend proof | Создал ли кошелёк расходующую транзакцию | Не заменяет tx proof конкретному получателю |
| Transaction key check | Раскрывает данные выбранного платежа по tx key | Сам ключ даёт больше приватной информации, чем proof string |
| Txid в explorer | Существование транзакции и публичные chain-данные | Не раскрывает скрытого получателя и сумму ему |
- Механизм
- Tx proof
- Что проверяет
- Получил ли точный адрес выходы указанной транзакции
- Главная граница
- Не доказывает личность и текущую spendability
- Механизм
- Spend proof
- Что проверяет
- Создал ли кошелёк расходующую транзакцию
- Главная граница
- Не заменяет tx proof конкретному получателю
- Механизм
- Transaction key check
- Что проверяет
- Раскрывает данные выбранного платежа по tx key
- Главная граница
- Сам ключ даёт больше приватной информации, чем proof string
- Механизм
- Txid в explorer
- Что проверяет
- Существование транзакции и публичные chain-данные
- Главная граница
- Не раскрывает скрытого получателя и сумму ему
Сначала согласовать точный челлендж
Получатель формирует уникальное message: номер заказа, случайный nonce и назначение проверки. Канал отдельно фиксирует transaction ID, полный Monero address или subaddress и точную строку message с регистром и пробелами. Старый proof без свежего челленджа можно повторно показать в другом споре, поэтому дата или nonce важнее красивого скриншота.
Здесь доказывается конкретный платёж, а не общий контроль адреса. Подпись произвольного сообщения в других сетях решает другую задачу и тоже не превращает криптографический результат в удостоверение личности.
Создание и независимая проверка
Workflow tx proof
- 1Проверить локальную запись
Отправитель открывает тот кошелёк, который создал транзакцию, и сверяет txid, адрес получателя и сумму по своей истории.
- 2Создать proof
В Wallet RPC вызовите get_tx_proof с txid, address и согласованным message; в CLI используйте эквивалентную команду текущей версии.
- 3Передать минимальный набор
Получателю нужны txid, точный address, message и signature/proof. Не прикладывайте tx key или ключи кошелька без отдельной осознанной причины.
- 4Проверить независимо
Получатель запускает check_tx_proof с теми же полями и фиксирует good, received, in_pool и confirmations.
- 5Сопоставить платёж
Сравните атомарную received-сумму, ожидаемую XMR-сумму, mempool/confirmation state и собственный баланс/инвойс.
Проверяйте proof в локальном официальном кошельке или в доверенном окружении. Сторонний веб-проверяющий видит ваш txid, адрес, message и proof, связывая ранее раздельные данные. Общий принцип минимизации раскрытия начинается с понимания того, что вообще видно по публичному адресу.
Как читать результат и где остановиться
| Результат | Что означает | Следующий шаг |
|---|---|---|
| good=false | Proof не согласован хотя бы с одним входным полем | Повторно сверить txid/address/message и версию кошелька; не менять поля молча |
| good=true, in_pool=true | Платёж распознан, но ещё не подтверждён блоком | Подождать и перепроверить confirmations |
| good=true, received совпадает | Адрес получил указанную сумму в этой транзакции | Сохранить proof и результат с временем проверки |
| received меньше инвойса | Доказан только фактический объём | Не считать заказ оплаченным полностью |
| Доказательство старое или message чужой | Контекст спора не связан | Запросить новый уникальный челлендж |
- Результат
- good=false
- Что означает
- Proof не согласован хотя бы с одним входным полем
- Следующий шаг
- Повторно сверить txid/address/message и версию кошелька; не менять поля молча
- Результат
- good=true, in_pool=true
- Что означает
- Платёж распознан, но ещё не подтверждён блоком
- Следующий шаг
- Подождать и перепроверить confirmations
- Результат
- good=true, received совпадает
- Что означает
- Адрес получил указанную сумму в этой транзакции
- Следующий шаг
- Сохранить proof и результат с временем проверки
- Результат
- received меньше инвойса
- Что означает
- Доказан только фактический объём
- Следующий шаг
- Не считать заказ оплаченным полностью
- Результат
- Доказательство старое или message чужой
- Что означает
- Контекст спора не связан
- Следующий шаг
- Запросить новый уникальный челлендж
Даже good=true не гарантирует spendability: официальный RPC отдельно предупреждает о timelock, уже потраченных выходах и иных состояниях. Proof не доказывает, что отправитель владеет всеми входами кошелька сейчас, что адрес принадлежит названной компании или что средства имеют определённое происхождение. Для бухгалтерского результата храните txid, address, message, proof, raw received, block height/confirmations и время проверки.
Если задача лишь подтвердить доставку криптоперевода, сначала согласуйте актив, сеть, сумму и получателя, а затем добавляйте специфичный Monero proof как доказательство скрытого выхода. Модель публичных и приватных ключей полезна для границ: proof создаёт кошелёк, но получателю не нужен ваш приватный ключ.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Monero Docs — Wallet RPC Monero Project · Проверено 23 августа 2026 г. в 15:43 GMT+5
- Monero Docs — wallet CLI reference Monero Project · Проверено 23 августа 2026 г. в 15:43 GMT+5
- Monero User Guide — monero-wallet-cli Monero Project · Проверено 23 августа 2026 г. в 15:43 GMT+5
- Monero source — Wallet RPC command definitions Monero Project · Проверено 23 августа 2026 г. в 15:43 GMT+5