Как настроить уведомления о движении средств перед крупным переводом

Настроить уведомления о движении средств перед крупным переводом значит подписаться на события в неподтверждённом состоянии, а не на зачисления в блок. Порядок такой: отдайте службе наблюдения дескриптор кошелька, включите событие «транзакция увидена в мемпуле», выберите транспорт с доставкой за секунды и проверьте канал малой суммой. Сообщение, пришедшее до первого подтверждения, оставляет время на замену транзакции.

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

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

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

Механика замены описана в стандарте. BIP-125 «Opt-in Full Replace-by-Fee Signaling» держит статус Deployed и задаёт признак заменяемости: достаточно, чтобы хотя бы у одного входа значение nSequence было меньше 0xffffffff минус единица. Пять правил того же документа ограничивают замену: новая транзакция платит абсолютную комиссию не ниже суммы прежних, оплачивает собственную полосу по минимальной ставке передачи и вытесняет из мемпула не более ста транзакций вместе с потомками.

Сравнение событий: на что подписываться

Разница между первой и второй строкой таблицы — это разница между управлением и уведомлением, между возможностью вмешаться в исход операции и возможностью узнать о нём. Первая даёт действие. Вторая даёт запись в журнале.

Порядок настройки шаг за шагом

1. Соберите дескриптор кошелька или список адресов наблюдения. Приватные ключи и слова восстановления службе не передаются никогда.
2. Включите в настройках событие по неподтверждённым транзакциям — в интерфейсах оно называется «mempool», «pending» или «0 confirmations».
3. Выставьте порог по сумме так, чтобы мелкие поступления не создавали фон. Крупный перевод должен выделяться в ленте.
4. Выберите транспорт с доставкой за секунды и назначьте получателем аппарат, который не участвует в подписании транзакций.
5. Убедитесь, что кошелёк, которым вы отправляете, помечает транзакции как заменяемые. Без признака замена обойдётся дороже.
6. Прогоните контрольную операцию малой суммой, засеките время до сообщения и запишите результат рядом с инструкцией.

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

Проверка канала и сохранение конфигурации

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

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

Типовые ошибки, которые стоят денег

• Подписка только на подтверждённые события. Сообщение приходит, когда менять нечего.
• Медленный транспорт. Задержка в десять минут съедает окно замены целиком.
• Передача службе расширенного приватного ключа вместо дескриптора наблюдения — необратимая утрата контроля над деревом адресов.
• Крупный перевод одной транзакцией без пробного платежа на тот же адрес.
• Порог по сумме не выставлен, и перед важной операцией лента забита мелочью.

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

Что делать, если оповещение пришло, а перевод вы не отправляли

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

Долгое хранение требует иных порогов, чем активные расчёты: там полезно оповещение на любое исходящее событие без порога вообще. Как это встраивается в общую схему, мы описывали в материале о том, как организовать хранение криптовалюты, если держите активы годами.

Чек-лист

• Служба наблюдения получила дескриптор или список адресов, но не приватные ключи.
• Событие по неподтверждённым транзакциям включено.
• Порог по сумме отсекает пылевые поступления.
• Транспорт доставляет сообщение за секунды, задержка замерена.
• Получатель оповещений — отдельный аппарат, не участвующий в подписании.
• Отправляющий кошелёк помечает транзакции как заменяемые.
• Конфигурация наблюдения записана и лежит рядом с копией ключей.

Частые вопросы