357 / 691FINAL

Finality

Вероятностная окончательность расчётов

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

Finality определяет, когда расчёт можно считать окончательным. В Bitcoin она вероятностная: более глубокую действительную историю труднее заменить, но никакое универсальное число подтверждений само не гарантирует невозможности реорганизации или юридического исполнения сделки.

Дополнительные блоки над транзакцией увеличивают работу для замены её истории. Безопасность зависит также от ресурсов атакующего и состояния сети. Finality не является фиксированным моментом, после которого протокол выдаёт математический сертификат необратимости. [Bitcoin Developer Guide — Block Chain][Bitcoin Developer Guide — Payment Processing]

Узел сначала проверяет правила, затем выбирает действительную цепь с наибольшей накопленной работой. Число блоков, подключённых узлов или голоса держателей монет не заменяют этот выбор. Большая работа не делает недействительную транзакцию действительной. [Bitcoin Developer Guide — Block Chain]

Собственный пример: блок транзакции на высоте 800000, вершина той же активной цепи — 800005. Подтверждения: 800005 − 800000 + 1 = 6, включая сам блок транзакции. Только присутствие в mempool означает 0 подтверждений, не первое. [Bitcoin Developer Guide — Payment Processing][Bitcoin Core 28.0 — getblockheader]

Реорганизация может удалить прежний блок из активной ветви. Bitcoin Core 28.0 getblockheader сообщает для него confirmations = -1. Это не означает потери всех платежей: транзакция может быть и в новой ветви, оставаться неподтверждённой либо конфликтовать; проверьте состояние снова. [Bitcoin Developer Guide — Block Chain][Bitcoin Core 28.0 — getblockheader]

Руководство разработчика приводит 6 подтверждений как обычный порог ценных платежей и также предусматривает анализ риска. Это решение получателя, не изменение консенсуса. Примерно час в среднем не означает, что шесть блоков всегда появляются за час. [Bitcoin Developer Guide — Payment Processing]

PFMI требуют ясно определять окончательный расчёт и границу отзыва инструкций. Число подтверждений само не определяет юридический эффект договора, банковского платежа или перехода собственности. Техническое принятие BTC не исполняет все обязательства сделки. [BIS — PFMI principle 8]

В Bitcoin нет обычной кнопки провайдера для отзыва подтверждённого платежа. Добровольный возврат — новая транзакция получателя, не стирающая исходный перевод. Получателя и сумму проверяют до отправки, не только после порога подтверждений. [Bitcoin.org — Some things you need to know]

Записывайте транзакцию, блок и источник проверки; следите за актуальностью узла и изменениями активной ветви. confirmations — состояние при запросе, не постоянный сертификат. Правила должны учитывать падение подтверждений или конфликт, чтобы старый снимок не считался новым доказательством. [Bitcoin Developer Guide — Payment Processing][Bitcoin Core 28.0 — getblockheader]

Для полной картины прочитайте эту статью вместе с Подтверждение, Proof of Work, Settlement risk, Delivery versus payment. На эту статью также ссылаются Byzantine Generals Problem, Nakamoto consensus, Delivery versus payment.

DOC · 001Bitcoin Developer Guide — Block ChainДокументация ↗DOC · 002Bitcoin Developer Guide — Payment ProcessingДокументация ↗DOC · 003Bitcoin Core 28.0 — getblockheaderДокументация ↗DOC · 004BIS — PFMI principle 8Документация ↗DOC · 005Bitcoin.org — Some things you need to knowДокументация ↗
Сначала источники · Не является инвестиционной рекомендацией