Подтверждение

Отправка не является подтверждением. Каждый узел независимо применяет политику доступа к своему мемпулу, и разные узлы могут видеть разные наборы из-за времени, комиссий, конфликтов, ограничений пакета или настроек. RBF может подменить неподтвержденную транзакцию и увиденный мерчантом платеж может исчезнуть, не попав в блок. Таким образом, нулевая конфигурация меняет скорость на риск двойных расходов и неполного представления сети; Ни txid, ни страница проводника не являются поселениями. [Руководство разработчика Bitcoin — Транзакции] [Bitcoin Core — согласованность JSON-RPC] [BIP 125 — полная замена по комиссии]

Майнер может выбрать транзакцию в блок-кандидат, но первое подтверждение происходит только тогда, когда проверяющий узел принимает блок и блок находится в его активной цепочке с наибольшей цепочкой. Полный узел проверяет подтверждение работы, скрипты, наличие и неиспользование входных данных, сумм и других правил консенсуса; майнер не может компенсировать недействительную трату просто путем листинга. Корень Меркла фиксирует транзакцию в блоке, а ссылка на предыдущий блок помещает ее в историю подтверждения работы. [Bitcoin Core — проверка] [Bitcoin Core — validation.cpp]

Если блок транзакции находится на высоте h и текущая вершина узла равна H, счет равен H − h + 1: сначала подсчитывается сам блок. Значение генерируется на основе наиболее проверенного блока этого узла, поэтому подсказка может незначительно отличаться между узлами. Он не записывается в транзакцию, не увеличивается с течением времени и не может быть достоверно определен по временной метке. Bitcoin Core возвращает хэш блока, высоту блока и подтверждения в качестве состояния кошелька или представления UTXO. [Руководство разработчика Bitcoin — цепочка блоков] [Bitcoin Core RPC — gettransaction] [Bitcoin Core RPC — getbestblockhash]

Если конкурирующая действительная ветвь получит больше цепочки, узел отделит блоки старой вершины и прикрепит победившую ветвь. Транзакция из отдельного блока может вернуться в мемпул, если она остается действительной, зафиксироваться на другой высоте или стать конфликтной, поскольку новая ветвь потратила тот же ввод. Отрицательные подтверждения в Bitcoin Core — это соглашение кошелька о глубине конфликта, а не отрицательные блоки в консенсусе. [Bitcoin Core RPC — gettransaction] [Bitcoin Core — validation.cpp]

Дополнительные подтверждения добавляют доказательство работы транзакции, что обычно делает ее более дорогой и вряд ли перепишет историю. Они не создают детерминистской окончательности. Как расчет наверстывания, приведенный в официальном документе, так и более поздние модели зависят от доли хешрейта злоумышленника, поведения честной сети и наблюдений получателя. «Шесть подтверждений» — это исторический прием, а не консенсусная константа или универсальный безопасный предел; глубокая реорганизация в принципе еще возможна. [Информационный документ о биткойне — Доказательство работы и расчеты] [Розенфельд — Анализ двойных расходов на основе хешрейта]

Счет требуется получателю, обмену или нисходящему протоколу, а не самой транзакции. Кофе, безвозвратный выпуск дорогих товаров, биржевой депозит и открытие канала имеют разные коэффициенты потерь и ожидания. Политика должна учитывать ценность, обратимость производительности, мотивацию и хешрейт злоумышленника, конфликты или RBF, хранение и бэкэнд, риск затмения и необычное состояние цепочки. Подтверждение снижает риск перезаписи цепочки; не исправит украденный ключ, неверный адрес или мошенничество с контрагентом. [BIP 125 — полная замена комиссией] [Розенфельд — анализ двойных расходов на основе хешрейта]

Биткойн стремится поддерживать в среднем около десяти минут между блоками, но прибытия доказательства работы случайны: следующий блок может прийти через секунды или часы. Более высокая комиссия может улучшить порядок выбора майнеров и экономичность пакетов RBF или CPFP, но отсутствие комиссии дает фиксированное время и не ускоряет создание блоков. Дешевая транзакция может ожидать много блоков или быть удалена из мемпула; оценка — это вероятность, а не крайний срок. [Руководство разработчика Биткойн — Блокчейн] [Руководство разработчика Биткойн — Транзакции]

Полный узел проверяет строку и отвечает в соответствии со своим активным советом. Клиент SPV проверяет подтверждение работы в заголовках и включение доказательства Меркла, но не выполняет все правила консенсуса самостоятельно; кастодиальная служба также добавляет свою собственную политику кредитования и рисков. Даже результат RPC полного узла представляет собой снимок, который можно изменить при реорганизации. Так что вопрос не только в том, «сколько подтверждений», но и в том, чьей цепочке, проверке и хранению доверяет пользователь. [Информационный документ о биткойне — доказательство работы и расчеты] [Bitcoin Core — проверка] [Bitcoin Core — согласованность JSON-RPC]

Другие занятия также начинаются с подтверждения. На вывод Coinbase распространяется COINBASE_MATURITY = 100 и его можно потратить только после 100 новых блоков; это другое правило, чем политика обычных платежей. Относительные временные блокировки BIP68, реализуемые сценарием BIP112 CHECKSEQUENCEVERIFY (CSV), измеряют возраст выходного блока фиксации. Неподтвержденный родитель держит потомков в зависимости; чтобы дочерний элемент был утвержден, его предки должны находиться в том же или более старом блоке. [Bitcoin Core — консенсус.h] [BIP 112 — CHECKSEQUENCEVERIFY]

BOLT 2 позволяет приемнику канала Lightning выбирать транзакции финансирования с минимальной глубиной перед Channel_ready; числовые значения финансирования риска двойного расходования. Канал с нулевым разрешением устанавливает минимум_глубины равным нулю и сознательно полагается на доверие к фонду и ограничения протокола, а не на немедленную завершенность. Финансирование Coinbase ожидает поступления. Оператору следует следить за расходом финансирования, глубиной активной цепочки и реорганизациями, а не рассматривать отправленный txid как открытый канал. [БОЛТ 2 — Одноранговый протокол] [Bitcoin Optech — Каналы с нулевой конфигурацией]