Проверка транзакции Bitcoin: как найти перевод по TxID и понять статус

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

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

В этом руководстве проверка транзакции биткоин рассматривается как последовательная диагностика. Вы узнаете, где взять TxID, чем он отличается от адреса и хэша блока, как читать входы и выходы, почему сумма входов больше платежа, откуда берётся сдача, что означает unconfirmed, когда запись может исчезнуть из mempool и как зафиксировать доказательства перевода без раскрытия секретов кошелька.

Статья посвящена именно сети Bitcoin. У других блокчейнов свои форматы, состояния и правила комиссии, поэтому нельзя механически переносить выводы. Универсальный принцип работы с обозревателями изложен отдельно в материале о blockchain explorer, а здесь каждое поле разбирается применительно к BTC, модели UTXO и очереди Bitcoin.

Главное правило проверки: ориентируйтесь на данные нескольких исправных источников или собственного узла, а не на скриншот отправителя. Публичный реестр позволяет проверить запись независимо. При этом ни обозревателю, ни получателю, ни специалисту не нужны seed-фраза и закрытый ключ. Для поиска достаточно публичного идентификатора или адреса.

Проверка транзакции биткоина: что можно установить и чего она не доказывает

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

Однако блокчейн не хранит привычное назначение платежа, имя покупателя, текст договора или обещание отправителя. Адрес — криптографический реквизит, а не подтверждённая личность. Если операция отправила BTC на определённый адрес, сеть доказывает именно это. Она не доказывает автоматически, что адрес принадлежит Ивану, что товар передан или что стороны правильно поняли условия.

Какие факты можно установить точно

По подтверждённой записи можно проверить TxID, блок, высоту, время блока, список входов, список выходов и значения в сатоши. Большинство обозревателей дополнительно рассчитывает общую комиссию, виртуальный размер и ставку в sat/vB. Эти производные данные проверяемы, если источник корректно распознал предыдущие выходы.

Для каждого выхода виден индекс. Это важно, потому что одна транзакция может платить нескольким адресам и возвращать остаток отправителю. Фраза «в транзакции есть один биткоин» сама по себе ничего не говорит о платеже конкретному получателю. Нужно найти его адрес и значение именно его выхода.

Что означает число подтверждений

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

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

Почему время на странице приблизительное

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

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

Чем сетевой факт отличается от статуса приложения

Кошелёк может показать «отправлено» сразу после создания подписи, хотя передача узлам завершилась ошибкой. Другой интерфейс пишет «в обработке», когда запись уже подтверждена, но локальная синхронизация отстала. Статус сервера — это интерпретация, а TxID и активная цепочка дают проверяемую основу.

При расхождении сначала проверяют правильную сеть и точный TxID, затем сравнивают два независимых обозревателя. Если запись относится к вашему кошельку, дополнительную проверку можно выполнить через Bitcoin Core или другой клиент, подключённый к исправным узлам. Не переустанавливайте программу и не повторяйте платёж, пока не установлено сетевое состояние.

Можно ли по транзакции доказать оплату

TxID подтверждает, что определённые входы создали указанные выходы. Чтобы связать это с обязательством, в договоре или переписке заранее фиксируют адрес получателя, сумму BTC, допустимое отклонение, срок и требуемую глубину подтверждений. Тогда запись можно сопоставить с согласованными условиями.

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

Биткоин: проверка транзакции по TxID, адресу, блоку и vout

Большинство ошибок начинается с неверного реквизита. Пользователь копирует адрес вместо TxID, внутренний номер приложения вместо сетевого идентификатора или строку из другой сети. Хороший обозреватель пытается распознать формат, но сообщение «не найдено» часто означает не отсутствие операции, а неправильный тип данных.

Что такое TxID

TxID — идентификатор Bitcoin-транзакции, получаемый из её сериализованных данных по правилам протокола. Обычно он выглядит как строка из 64 шестнадцатеричных символов. Одинаковый TxID у отправителя, получателя, обозревателя и узла относится к одной и той же структуре операции. Подробное базовое определение дано в статье что такое TxID транзакции.

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

Где найти TxID

В самостоятельном кошельке откройте историю, выберите конкретную отправку и найдите поле Transaction ID, TxID, ID операции или ссылку на обозреватель. Копируйте значение целиком, а не видимую сокращённую часть. В настольных клиентах подробности могут находиться в контекстном меню или свойствах записи.

Если приложение выдало только собственный номер заявки, это ещё не TxID. Сетевой идентификатор появляется после формирования и передачи конкретной Bitcoin-транзакции. Отдельная инструкция где найти TxID помогает отличить его от номера записи в интерфейсе.

Адрес Bitcoin

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

Если TxID неизвестен, адрес получателя и примерная дата помогают найти нужный выход. Сверяйте точное значение, а не общий итог страницы. Для задачи именно баланса существует отдельное руководство по проверке Bitcoin-кошелька по адресу; не смешивайте его с проверкой одной операции.

Хэш и высота блока

Подтверждённая операция связана с блоком. Хэш блока идентифицирует конкретный блок, а высота показывает его положение от начала цепочки. По блоку можно проверить время, количество операций и глубину. Но ввод хэша блока откроет весь блок, поэтому нужный TxID придётся найти внутри списка.

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

Outpoint: TxID плюс индекс

Каждый выход определяется парой: TxID создающей транзакции и номером выхода, обычно vout. Первый выход имеет индекс 0. Именно эта пара затем указывается входом новой операции. Она нужна при техническом анализе UTXO, проверке расходования и разборе конфликтов.

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

TxID и wtxid

Для операций SegWit существует также wtxid, учитывающий свидетельства. Обычный пользователь почти всегда ищет по TxID, который используется для ссылки на выходы. Некоторые технические инструменты показывают оба значения. Они могут совпадать у операции без witness и различаться у SegWit-транзакции.

Если один источник не распознаёт wtxid, попробуйте TxID из поля transaction id. Не преобразуйте строку случайным сайтом. В собственном узле и подробном декодере названия полей указаны явно. Для доказательства платежа сохраняйте тот идентификатор, по которому запись открывается в распространённых Bitcoin-обозревателях.

Почему идентификатор нельзя угадывать

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

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

Проверка биткоин-транзакции по TxID: пошаговый порядок

Порядок проверки должен быть одинаковым для обычной и проблемной операции. Сначала фиксируют исходные данные, затем выбирают источник, открывают запись, сверяют сеть и только после этого делают вывод о статусе. Если начать с эмоционального вопроса «почему денег нет», легко принять не тот адрес или чужую запись за свою.

Шаг 1. Соберите исходные данные

Запишите TxID, ожидаемый адрес получателя, сумму BTC, примерное время отправки и название кошелька. Если спор касается конкретного обязательства, добавьте счёт или сообщение с согласованными реквизитами. Не просите у отправителя seed-фразу, закрытый ключ или доступ к устройству.

Сверьте TxID в двух каналах, если сумма существенна. Например, отправитель передаёт строку текстом, а последние и средние символы подтверждает голосом. Это защищает от случайной обрезки и подмены сообщения.

Шаг 2. Откройте обозреватель Bitcoin

Используйте известный обозреватель, адрес которого набран вручную или сохранён в закладке. Убедитесь, что он работает с основной сетью Bitcoin, а не testnet, signet или другой монетой с похожим названием. Вставьте TxID в строку поиска.

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

Шаг 3. Проверьте, найдена ли запись

Если страница открылась, заново сравните полный TxID. Если запись не найдена, не переходите сразу к выводу о потере. Возможны опечатка, другая сеть, задержка распространения, локально созданная, но не переданная операция, замена или удаление из mempool. Этому сценарию посвящено руководство что делать, если TxID не найден.

Сравните результат второго обозревателя. Один сервер может быть недоступен или отставать. Если оба не видят запись, проверьте детали кошелька отправителя и наличие настоящего TxID, а не номера заявки.

Шаг 4. Сверьте выход получателя

Найдите раздел Outputs. Он может содержать два и более выхода: платёж, сдачу, несколько получателей. Найдите точный адрес и значение рядом с ним. Общая сумма выходов не равна сумме, которую должен получить один адрес.

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

Шаг 5. Прочитайте статус и подтверждения

Confirmed означает включение в блок активной цепочки на момент проверки. Запишите высоту и число подтверждений. Unconfirmed или pending означает, что источник видит запись в mempool, но блока ещё нет. Дата первого появления не заменяет подтверждение.

Если получатель требует определённую глубину, дождитесь её и проверьте заново. Счётчик растёт после новых блоков. Не ориентируйтесь на таймер интерфейса, который может быть приблизительной оценкой.

Шаг 6. Оцените комиссию и позицию в очереди

Смотрите общую комиссию, virtual size или weight и fee rate в sat/vB. Для вероятности подтверждения важнее ставка относительно других ожидающих операций, а не только абсолютная сумма. Большая транзакция может платить больше сатоши суммарно, но иметь низкую ставку на единицу размера.

Сравните ставку с текущими диапазонами mempool. Это оценка, а не гарантия. Майнер формирует блок по собственной политике, а очередь меняется с каждой новой операцией. Подробное чтение ставки описано в статье о комиссии Bitcoin в sat/vByte.

Шаг 7. Сохраните результат

Для обычного контроля достаточно TxID и заметки. Для спора сохраните адрес, индекс выхода, сумму, статус, число подтверждений, хэш и высоту блока, дату проверки и адрес обозревателя. Лучше выгрузить текстовые данные или PDF вместе со скриншотом, потому что интерфейс сайта может измениться.

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

Почему нельзя ограничиваться зелёной галочкой

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

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

Как читать поля Bitcoin-транзакции: входы, выходы, сдача и комиссия

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

Входы не равны отправителям

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

Каждый вход ссылается на прежний TxID и индекс выхода. Проверяя цепочку назад, можно увидеть происхождение конкретного UTXO. Это публичная техническая связь, но не готовая юридическая атрибуция. Адрес мог сменить владельца, использоваться общей системой или входить в совместную схему.

Выходы показывают новые условия расходования

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

Если нужный адрес отсутствует, операция не заплатила на него, даже если общая сумма совпадает. Проверьте, не был ли согласован другой формат адреса. Если адрес присутствует, зафиксируйте индекс и сумму. Это точное указание результата.

Откуда берётся адрес сдачи

Представьте UTXO на 0,01 BTC и платёж 0,003 BTC. Кошелёк не отрезает часть исходного выхода. Он расходует 0,01 BTC, создаёт платёжный выход, вычитает комиссию и возвращает остаток на новый адрес владельца. Поэтому внешний наблюдатель видит два выхода и может ошибочно решить, что отправитель заплатил обоим получателям.

Адрес сдачи обычно автоматически создаётся тем же кошельком и входит в резервную схему. Он может не появляться в списке привычных адресов получения. Если программа восстановлена по правильной seed-фразе и параметрам, сдача должна учитываться. При ручном импорте отдельных ключей возможна потеря контроля над неимпортированным адресом, поэтому старые неиерархические резервные схемы требуют особой осторожности.

Как рассчитывается комиссия

Комиссия равна сумме значений входов минус сумма значений выходов. Отдельного «выхода майнеру» нет. Если входы дают 100 000 сатоши, а выходы суммарно 98 500, комиссия составляет 1 500 сатоши. Обозреватель выполняет этот расчёт автоматически.

Для сравнения приоритета используют fee rate: комиссию делят на виртуальный размер. Две операции с одинаковой абсолютной платой могут иметь разный приоритет, если одна занимает больше места. Weight и vsize отражают структуру данных с учётом SegWit; пользователю достаточно понимать, что более сложная или много входная операция обычно крупнее.

Почему сумма на входах пугающе большая

Если вы отправили 0,001 BTC, а обозреватель показывает вход 0,5 BTC, это не означает списание всех средств получателю. Найдите выход сдачи. Итоговый расход владельца равен платежу плюс комиссии, если сдача действительно контролируется его кошельком. Без знания принадлежности выходов наблюдатель не может с абсолютной уверенностью разметить роли.

Кошелёк может выбрать несколько мелких UTXO, поэтому сумма входов складывается. При режиме coin control владелец выбирает их вручную. Эта структура влияет на комиссию и приватность: объединение входов создаёт публичную связь между ранее раздельными поступлениями.

Locktime и sequence

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

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

Coinbase-транзакция

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

Пользователь встречает такую запись при анализе блока или происхождения UTXO. Не путайте термин coinbase-транзакция с названием стороннего продукта. В контексте протокола это техническая операция майнера.

Статусы unconfirmed, pending, confirmed, replaced и dropped

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

Unconfirmed и pending

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

Проверяйте время первого обнаружения, fee rate, наличие неподтверждённых предков и флаг заменяемости. Если запись только что передана, различия нормальны. Если прошло много времени, нужна диагностика очереди, а не повторная отправка без проверки.

Confirmed

Статус confirmed должен сопровождаться хэшем и высотой блока. Убедитесь, что блок находится в активной цепочке источника. После первого подтверждения новый блок увеличивает глубину. Получатель выбирает момент окончательного признания платежа по собственной политике риска.

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

Replaced или conflicted

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

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

Dropped, evicted или not in mempool

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

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

Invalid или rejected

Узел отклоняет запись, нарушающую правила консенсуса или политику распространения: неверная подпись, уже потраченный вход, слишком низкая плата относительно минимума, нестандартная структура. Кошелёк может показать текст причины, но разные узлы формулируют его по-разному.

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

Reorg и временное уменьшение подтверждений

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

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

Почему два обозревателя спорят

Источники подключены к разным узлам, обновляются с разной скоростью и имеют собственную mempool-политику. Один показывает предполагаемую замену, другой сохраняет старую страницу. При подтверждённых данных расхождение обычно исчезает после синхронизации, но в момент конфликта нужен более надёжный арбитр.

Собственный Bitcoin Core проверяет блоки самостоятельно и показывает состояние своего mempool. Он тоже имеет локальную политику, но позволяет видеть источник вывода и не раскрывать запрос внешнему сайту. О возможностях клиента рассказывает руководство как пользоваться Bitcoin Core.

Что делать отправителю после проверки транзакции

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

TxID есть и подтверждения растут

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

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

Запись в mempool и ставка достаточна

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

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

Ставка слишком низкая

Проверьте, поддерживает ли исходный кошелёк RBF. Штатная функция Increase fee или Bump fee создаёт новую версию с более высокой платой. Перед подписью сверяйте адрес и значение получателю. Сохраните новый TxID и сообщите его стороне.

Если RBF недоступен, иногда помогает CPFP: владелец подходящего неподтверждённого выхода создаёт дочернюю операцию с достаточной суммарной ставкой для пакета. Это требует понимания UTXO и поддержки кошелька. Подробные условия и риски разобраны в статье как ускорить зависшую Bitcoin-транзакцию.

TxID не виден ни одному источнику

Откройте детали исходного кошелька. Возможно, операция создана локально, но не передана из-за соединения. Проверьте, не показывает ли приложение другой TxID после повторной передачи. Если входы уже потрачены, найдите фактическую операцию по адресу или outpoint.

Не отправляйте ту же сумму заново простым нажатием, пока не знаете состояние входов. Кошелёк может корректно предотвратить двойное расходование, но ошибка пользователя способна создать второй отдельный платёж из других UTXO.

Адрес получателя оказался неверным

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

Не платите человеку, который утверждает, что «взломает адрес» или вернёт перевод по seed-фразе. Если адрес не ваш, раскрытие собственного секрета только создаст новую потерю. Методы профилактики собраны в инструкции по проверке адреса до отправки.

Когда обращаться к разработчику кошелька

Поддержка полезна, если интерфейс неправильно отображает собственную операцию, не передаёт подписанные данные или не показывает штатную функцию замены. Передайте версию приложения, ОС, TxID и текст ошибки. Удалите лишние сведения о полном балансе.

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

Как получателю проверить оплату и не поверить поддельному чеку

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

Сверьте собственный адрес

Откройте исходный счёт, заказ или переписку и скопируйте адрес, который был передан отправителю. Не используйте адрес с его скриншота как эталон. В обозревателе найдите этот адрес среди выходов. Совпадение только первых и последних символов недостаточно для крупной суммы.

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

Проверьте конкретный выход и сумму

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

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

Не принимайте 0 подтверждений как окончательный результат

Неподтверждённая операция может быть заменена или конфликтовать с другой. Даже если адрес и сумма правильны, получатель несёт риск до включения. Для товара или доступа, которые невозможно вернуть, разумно ждать заранее установленную глубину. Чем выше стоимость необратимого встречного исполнения, тем строже политика.

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

Распознайте поддельный скриншот

Поддельное изображение часто содержит несуществующий TxID, чужую подтверждённую запись, изменённую сумму или статус приложения без блока. Скопируйте идентификатор как текст. Если отправитель прислал только картинку, попросите полную строку. Найдите запись самостоятельно и сравните адрес.

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

Что делать, если TxID принадлежит другой оплате

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

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

Если кошелёк не показывает подтверждённое поступление

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

Не импортируйте seed в случайное приложение ради ускорения отображения. Используйте официальный клиент, повторное сканирование или собственный узел по документации. Если публичный выход существует, время есть для аккуратной диагностики.

Как оформить политику приёма

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

Для крупной суммы полезна проверка вторым сотрудником. Один сопоставляет заказ и адрес, другой независимо открывает TxID и значение выхода. Такая процедура уменьшает риск как технической ошибки, так и социальной манипуляции.

Безопасность, конфиденциальность и доказательства при проверке

Публичность Bitcoin помогает независимой проверке, но создаёт информационный след. Вводя адрес во внешний обозреватель, пользователь сообщает его серверу вместе со своим сетевым адресом и временем интереса. Если последовательно искать несколько собственных адресов, сервис способен связать их одним посетителем. Для небольших разовых проверок риск может быть приемлем, для чувствительной истории нужен более приватный маршрут.

Какие данные безопасно передавать

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

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

Поддельные обозреватели

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

Не устанавливайте расширение для простого поиска TxID. Не платите за «разблокировку хэша» и не вводите код восстановления. Если сайт утверждает, что транзакция зашифрована и её можно увидеть только после пополнения, закройте его.

Можно ли узнать владельца входов и выходов

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

Не обвиняйте человека только по автоматической метке. Для юридического вывода нужны дополнительные доказательства: договор, переписка, контроль адреса и источник атрибуции. Границы метода подробно объясняет материал можно ли узнать владельца криптокошелька.

Как сохранить пакет доказательств

Запишите TxID, адрес, индекс выхода, сумму в сатоши, комиссию, блок, высоту, время проверки и число подтверждений. Сохраните страницу в PDF, текстовую выгрузку или JSON, если источник предоставляет её. Добавьте хэш сохранённого файла, чтобы позднее показать неизменность копии.

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

Почему один скриншот слабее воспроизводимой проверки

Дизайн обозревателя меняется, а изображение не позволяет машинно проверить поля. Текстовый TxID остаётся указателем на запись. Даже если выбранный сайт исчезнет, другой источник или полный узел сможет извлечь данные из активной цепочки.

Скриншот полезен для фиксации интерфейса и времени, но дополняет, а не заменяет реквизиты. На нём должны быть видны домен, TxID, адрес, значение выхода, статус и дата снятия. Скрывайте другие личные данные.

Ведение журнала для регулярных платежей

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

Не редактируйте прошлую строку без следа. Исправление оформляйте отдельной отметкой с датой и причиной. Если операция заменена, храните старый и новый TxID, связывая их между собой. Это позволяет объяснить, почему первоначальная запись не подтвердилась.

Проверка через сеть Tor или собственный узел

Для снижения утечки запросов можно использовать собственный Bitcoin Core и при необходимости настроенное сетевое соединение. Но приватность зависит от всей конфигурации: DNS, браузера, удалённого RPC и журналов. Один переключатель не гарантирует анонимность.

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

Проверка через Bitcoin Core и разбор сложных случаев

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

Проверка своей операции

Bitcoin Core хранит сведения о транзакциях загруженного кошелька и способен показать подтверждения, детали, комиссию и конфликты. Для операции, относящейся к кошельку, используют соответствующую функцию просмотра. Интерфейс или RPC должен выполняться локально человеком, который понимает команду.

Если запись не относится к загруженному кошельку, возможности зависят от mempool, указанного блока и настройки индекса транзакций. Полный txindex позволяет находить подтверждённые операции по всей цепочке без заранее известного блока, но требует дополнительного места и построения индекса.

Почему getrawtransaction иногда «не видит» известный TxID

Без txindex и без хэша блока узел обычно возвращает произвольную операцию, если она находится в его mempool. Для подтверждённой чужой записи нужно указать блок или включить индекс. Ошибка поиска в такой конфигурации не означает отсутствия транзакции в блокчейне.

Сначала проверьте синхронизацию и высоту узла. Затем получите хэш блока из известного источника или собственного индекса. Не включайте тяжёлую переиндексацию на рабочем сервере без оценки места и времени.

getmempoolentry и локальная очередь

Запрос к mempool показывает данные, которые видит именно ваш узел: virtual size, fee, время, высоту принятия, зависимости и признаки заменяемости. Другой узел может иметь отличающийся набор. Сравнение помогает понять, распространилась ли запись и от каких неподтверждённых предков зависит.

Если функция не находит TxID, операция могла быть подтверждена, удалена, заменена или никогда не достигнуть этого узла. Проверяйте блоки и расходование входов. Локальная очередь — источник данных, но не глобальный судья.

Проверка с лёгким кошельком

Electrum и подобные клиенты получают сведения от серверов и показывают историю адресов, подтверждения и комиссию. Они удобнее полного узла, но модель доверия и приватности отличается. Можно выбрать собственный сервер, чтобы связать лёгкий интерфейс с проверяемой инфраструктурой.

Если история не совпадает, проверьте подключение, высоту и сервер. Не импортируйте seed на новый случайный клиент только ради просмотра TxID. Обзор функций находится в материале про кошелёк Electrum.

Транзакция имеет неподтверждённых предков

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

Получатель должен видеть не только ставку последней операции, но и пакетную ситуацию. CPFP работает именно через повышение совокупной привлекательности родителя и потомка. Нельзя оценивать срок по одной строке fee rate без зависимостей.

Одна версия видна, другая подтверждена

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

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

Транзакция подтверждена, затем снова стала неподтверждённой

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

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

Как найти операцию, если TxID потерян

Начните с адреса получателя, ожидаемой суммы и временного диапазона. Откройте историю адреса и просматривайте выходы, созданные рядом с предполагаемой датой. Сумма должна совпасть именно в конкретном выходе. Учитывайте, что время сайта может показываться в UTC, локальном часовом поясе браузера или как время блока. Разница в несколько часов не исключает операцию.

Если адрес использовался много раз, одного совпадения суммы недостаточно. Сопоставьте переписку, последовательность блоков и другие реквизиты. Найдя кандидата, сохраните его TxID и индекс. Для отправки из собственного кошелька можно искать по истории, сумме и адресу, но не удаляйте локальные данные до восстановления идентификатора.

Пакетная транзакция с множеством получателей

Один отправитель может объединить десятки платежей в одну транзакцию. Каждый получатель видит общий TxID, но имеет собственный vout. Общая комиссия относится ко всей операции и не показывает, какую часть фактически отнёс на расходы каждый участник по внутреннему учёту отправителя. Нельзя делить комиссию поровну без договорённости.

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

Перевод между собственными адресами

Владелец может перемещать BTC между своими кошельками, консолидировать UTXO или менять схему хранения. В реестре это выглядит как обычная транзакция. Наблюдатель не знает, является ли выход платежом другому лицу или сдачей владельцу. Для учёта нужно сохранить внутреннее назначение сразу.

Если после такого перемещения старый адрес показывает ноль, средства не обязательно ушли постороннему. Найдите выходы и проверьте, контролирует ли новый адрес ваш кошелёк. Выполните проверку средствами watch-only или подпишите безопасное тестовое действие. Не делайте вывод о краже только по изменению одного адресного баланса.

Консолидация мелких UTXO

Консолидация объединяет множество прежних выходов в один или несколько новых. Она может иметь большую виртуальную величину из-за числа входов, поэтому абсолютная комиссия выглядит высокой. Целью бывает снижение размера будущих операций, но публичное объединение связывает источники и уменьшает приватность.

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

CoinJoin и совместное построение

Некоторые транзакции имеют входы нескольких участников и набор выходов с одинаковыми значениями. Простая эвристика «все входы принадлежат одному владельцу» здесь неверна. Обозреватель показывает структуру, но не раскрывает надёжно соответствие каждого входа выходу. Такие записи нельзя использовать для уверенного вывода о полном балансе одного участника.

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

SegWit, Taproot и разные форматы адресов

Адреса могут начинаться по-разному из-за используемого типа скрипта. Наличие старого Base58, SegWit или Taproot-адреса не меняет базовую проверку: найдите соответствующий выход, значение, блок и глубину. Комиссионная эффективность и структура подписи различаются, но получатель не обязан декодировать скрипт вручную.

Если обозреватель показывает scriptPubKey вместо привычного адреса, убедитесь, что он поддерживает современный формат. Сравните второй актуальный источник или декодируйте средствами узла. Не переводите строку через неизвестный «конвертер адресов»: это может подменить реквизит или привести к неверной сети.

Выход OP_RETURN и нулевое значение

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

Не пытайтесь извлечь из произвольных данных секретный комментарий без контекста. Для доказательства оплаты по-прежнему нужен обычный выход на согласованный адрес. Если значение OP_RETURN нулевое, оно не участвует в передаче BTC получателю, хотя присутствует в сериализованной транзакции и влияет на её идентификаторы.

Когда комиссия вычтена из суммы получателя

Кошелёк может предложить режим, в котором комиссия уменьшается за счёт указанного получателю значения. Тогда адрес верный, но выход меньше введённой пользователем исходной суммы. В другом режиме комиссия добавляется сверху, а получатель получает ровно указанное. Обозреватель не знает, какая кнопка была нажата; он показывает итоговые выходы.

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

Dust и очень маленькие выходы

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

Не отправляйте дополнительные средства на незнакомый адрес только ради «активации» такого поступления. Пылевые операции иногда используются для анализа связей: владелец затем объединяет выход с другими UTXO. Кошелёк с coin control позволяет не выбирать нежелательный мелкий выход без осознанной причины.

Разница между first seen и временем блока

First seen — локальное наблюдение конкретного источника. Один обозреватель мог увидеть запись до другого, а после перезапуска часть истории наблюдений утрачивается. Время блока относится к включению и определяется заголовком блока. Ни одно поле не является точным доказательством момента, когда человек нажал кнопку подписи.

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

Проверка суммы в BTC и сатоши

Обозреватели округляют отображение по-разному. Для точного сравнения переводите значение в сатоши — целое число. Например, 0,00010000 BTC равно 10 000 сатоши. Не удаляйте нули без понимания десятичной позиции и не копируйте фиатную оценку вместо сетевого значения.

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

Child pays for parent и пакетная ставка

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

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

Замена с сохранением платежа и отменяющая замена

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

Получатель должен открыть новый TxID и заново проверить адрес и значение. Метка «replacement» у старой страницы не гарантирует сохранение платежа. Окончательным сетевым результатом является подтверждённая версия. Старую и новую записи сохраняют для хронологии спора.

Неверный обозреватель для похожей монеты

Строка TxID может иметь одинаковую длину в нескольких системах, а название монеты — содержать слово Bitcoin. Поиск в обозревателе другой цепочки способен не дать результата или открыть случайно совпавший объект. Всегда проверяйте заголовок сети, единицы BTC и формат блоков.

Bitcoin Cash, Bitcoin SV, testnet и основная сеть Bitcoin — разные реестры. Операция в одном не подтверждает платёж в другом. Согласовывайте не только тикер, но и сеть. Если отправитель выбрал не ту цепочку, диагностика и возможность восстановления зависят от контроля ключей и адресного формата.

Повторное использование адреса

Один адрес может получить несколько платежей. При проверке нельзя брать общий received total за сумму конкретной транзакции. Найдите нужный TxID и выход. Повторное использование упрощает публичное связывание истории и повышает вероятность путаницы в учёте.

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

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

Восстановленный кошелёк может показать только часть истории, если выбран иной тип адреса, путь получения или gap limit. Публичная проверка известного TxID помогает установить, что выход всё ещё существует. Затем нужно доказать, что восстановленная конфигурация контролирует соответствующий скрипт.

Не вводите seed в обозреватель. Используйте официальный кошелёк, корректные параметры и при необходимости повторное сканирование. Если watch-only видит выход, а подписывающий кошелёк нет, сравните descriptor и адреса. Ошибка отображения не изменяет UTXO, но неправильный секрет не сможет его потратить.

Как провести полную проверку за пять минут

1. Скопируйте полный TxID из деталей исходного кошелька.
2. Откройте известный Bitcoin-обозреватель и подтвердите основную сеть.
3. Найдите адрес получателя, индекс выхода и точную сумму в сатоши.
4. Проверьте статус, блок, подтверждения и возможную заменяемость.
5. Для ожидания оцените fee rate, нагрузку mempool и неподтверждённых предков.
6. При расхождении сравните второй источник или синхронизированный собственный узел.
7. Сохраните TxID и воспроизводимые данные без seed-фразы и закрытого ключа.

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

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

Для отправителя достаточный результат — увидеть правильный адрес и значение, убедиться в включении и передать получателю TxID. Для получателя — независимо найти собственный выход и дождаться глубины по своей политике. Для спора — сохранить пару TxID и vout, сетевые поля и договорный контекст.

Неподтверждённая запись является намерением, уже распространённым в сети, но не окончательным результатом. Подтверждённая запись показывает фактический выход в активной цепочке. Чем выше риск встречного исполнения, тем меньше оснований полагаться на нулевой статус и чужой интерфейс.

Проверка Bitcoin-транзакции не требует доступа к кошельку. Любая просьба раскрыть seed-фразу ради просмотра, ускорения или доказательства — опасна. Используйте TxID, адрес и собственный источник. Если запись задержалась, сначала поставьте диагноз, затем применяйте предусмотренную кошельком функцию, а не платите неизвестному посреднику.

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