Finality означает окончательность расчёта: насколько можно рассчитывать, что завершённый перевод сохранится. Bitcoin даёт вероятностную уверенность, которая усиливается с дополнительной действительной работой. Никакое универсальное число подтверждений само по себе не исключает смену ветви и не определяет юридическое исполнение всего соглашения.
Сначала Павел видит лишь то, что кошелёк узнал о транзакции. Это ещё не означает её включения в блок. Когда блок появляется и за ним следуют новые, для замены этой истории нужно превзойти всё больший объём работы. Так на практике усиливается Finality. Но имеют значение и ресурсы возможного атакующего, и состояние сети. Протокол не выдаёт математического сертификата необратимости: получатель оценивает, насколько весомы основания для принятия конкретного платежа. [1] [2]
Full Node самостоятельно проверяет правила Bitcoin. Он не принимает историю лишь потому, что она длинная. Сначала проверяется её действительность, а среди действительных ветвей выбирается ветвь с наибольшей накопленной работой. Речь о работе, подтверждённой блоками, а не о голосовании по числу людей или монет. Больший объём работы не делает недействительную транзакцию действительной. Павлу важно проверить обе стороны: соответствует ли платёж правилам и насколько глубоко он находится в действительной истории, которой сейчас следует узел. [1]
В нашем примере транзакция Павла находится в блоке высоты 800000, а текущая вершина той же ветви имеет высоту 800005. Высота обозначает позицию блока, а не время. Расчёт: 800005 − 800000 + 1 = 6 подтверждений; учитывается и сам блок с транзакцией. Считаются не только блоки, добавленные после него. Если платёж есть лишь в mempool, наборе неподтверждённых транзакций этого узла, у него 0 подтверждений. Само ожидание не увеличивает их число. [2] [3]
Сеть может ненадолго знать о конкурирующих блоках, а затем продолжить другую действительную ветвь с большей работой. Такая смена активной истории называется реорганизацией. В документации Bitcoin Core 28.0 запрос заголовка блока getblockheader возвращает confirmations = -1, если блок не принадлежит активной цепи. Это характеристика блока, а не автоматическая потеря всех включённых в него платежей. Транзакция Павла может находиться и в новой ветви, ждать без подтверждения либо конфликтовать с другой транзакцией. Её конкретное состояние нужно проверить заново. [1] [3]
Руководство для разработчиков называет 6 подтверждений распространённым порогом для платежей большой стоимости, одновременно объясняя необходимость оценки риска. Это правило принятия платежа у получателя, а не момент изменения консенсуса Bitcoin. Павел должен учитывать стоимость велосипеда, возможную потерю и надёжность проверки; цифра не решит за него. Среднее время около часа также не означает, что шесть блоков всегда появляются за час. У майнинга нет фиксированного расписания, а старая общая рекомендация не гарантирует результат в любой ситуации. [2]
Павел может получить подтверждённые BTC и всё ещё спорить о передаче или состоянии велосипеда. PFMI, международные принципы для инфраструктур финансового рынка, требуют чётко определить момент окончательного расчёта и границу, после которой участник не может отозвать инструкцию. Это иная система требований, чем подсчёт блоков Bitcoin. Сами подтверждения не определяют правовые последствия договора, окончательность банковского платежа или переход собственности на вещь. Проверять платёж важно, но это не заменяет остальных условий сделки. [4]
Если Павел и покупатель договорятся вернуть деньги, обычный возврат выполняется новой транзакцией от получателя первоначального платежа. Исходный перевод остаётся в истории. У Bitcoin нет центральной службы поддержки с кнопкой отмены подтверждённого платежа по просьбе клиента. Реорганизация меняет активную историю сети; это не сервис исправления пользовательских ошибок. Поэтому получателя и сумму нужно проверять до отправки. Дополнительные подтверждения не исправят ошибочно заданный платёж. [5]
Для оператора платёжного приложения работа не заканчивается принятием платежа. Нужно учитывать транзакцию, её блок и источник проверки, а также замечать, не отстал ли узел от сети. confirmations показывает состояние на момент запроса, а не служит постоянным сертификатом. Если число уменьшается или возникает конфликт, приложению нужны заранее определённые действия и новая проверка активной ветви. Старый снимок экрана — не новое доказательство. Павлу следует решать по текущему состоянию платежа, а не только по тому, что когда-то показал кошелёк. [2] [3]
Для полной картины прочитайте эту статью вместе с Подтверждение, Proof of Work, Settlement risk, Delivery versus payment. На эту статью также ссылаются Byzantine Generals Problem, Delivery versus payment.