37 / 736CONF

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

Подтверждение биткоин-транзакции

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

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

Алиса отправляет другу 20 000 sat — наименьших единиц биткоина. Её кошелёк показывает «Отправлено», а друг уже видит входящий платёж, но с нулём подтверждений. Противоречия нет: информация распространилась между узлами, компьютерами, проверяющими Bitcoin, но ещё не вошла в блок. Mempool — локальное хранилище неподтверждённых транзакций узла, а не единая очередь всей сети. Когда платёж входит в принятый блок, он получает первое подтверждение. Следующий блок даёт второе, ещё один — третье. Алисе не нужно ничего отправлять заново. Распространение транзакции не является подтверждением, и её идентификатор txid тоже его не гарантирует. Неподтверждённую транзакцию можно заменить, например через Replace-by-Fee (RBF) для повышения комиссии. Приём платежа без подтверждений называется zero-conf и означает риск того, что вместо него подтвердится другая трата тех же средств. [4] [8] [11]

Майнер выбирает транзакции для нового блока и ищет действительный Proof of Work — результат затратных вычислений, требуемый правилами Bitcoin. Затем остальные полные узлы сами проверяют блок: верны ли подписи, суммы и условия расходования, не потрачены ли средства раньше? Это не голосование майнеров и не печать одной компании. Майнер не может сделать недействительный платёж действительным, просто включив его в блок. Узел считает его подтверждённым только в принятой цепи. Среди действительных ветвей он выбирает ту, у которой больше всего накопленной работы — chainwork. Каждый блок ссылается на предыдущий, поэтому изменение старой истории требует перестроить и её продолжение. [2] [7]

Bitcoin стремится к среднему интервалу десять минут между блоками, а не к расписанию. Новый блок может появиться через секунды или намного позже. Час ожидания сам по себе не означает шесть подтверждений. Более высокая ставка комиссии может повысить шанс выбора транзакции майнером, но не ускоряет появление блоков. Некоторые кошельки поддерживают RBF — замену неподтверждённой транзакции другой с более высокой комиссией — или CPFP (Child Pays for Parent): зависимая транзакция добавляет достаточно комиссии, чтобы майнеру было выгодно включить её вместе с предыдущей. Возможность зависит от кошелька и транзакции. Низкая комиссия может привести к долгому ожиданию или удалению из Mempool узла. Оценку кошелька воспринимайте как прогноз, а не обещанный срок. [3] [4]

Получатель или сервис определяет, сколько подтверждений требуется для принятия платежа. Для небольшой покупки допустим иной риск, чем при безвозвратной передаче дорогого товара. Если биржа ждёт нескольких подтверждений, транзакция уже может быть в блокчейне, а баланс счёта ещё не пополнен. Это не обязательно ошибка. Проверьте сумму, адрес и состояние в своём кошельке, а также правила зачисления сервиса. Важен и источник сведений. Атакующий может изолировать узел и навязывать ему ограниченную картину сети — это Eclipse Attack. Поэтому разумное ожидание зависит от стоимости, возможности исправить последствия, доверия к другой стороне и способа проверки. Само число подтверждений не защищает от украденного ключа. [11] [13]

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

Короткое разветвление возможно и без атаки, если два майнера находят блок почти одновременно. Переход узла на другую победившую ветвь называется реорганизацией. Выход транзакции записывает сумму и условия расходования; вход последующей транзакции ссылается на него и расходует его. Неизрасходованный выход называется UTXO. Если конкурирующая корректная ветвь накапливает больше работы, то есть chainwork, узел отсоединяет последние блоки исходной цепочки и присоединяет победившую ветвь. Транзакция из отсоединённого блока может вернуться в Mempool, если остаётся корректной, либо подтвердиться на другой высоте. Она также может стать конфликтующей, если новая ветвь потратила тот же выход, на который ссылается её вход. Отрицательное значение confirmations в Bitcoin Core — это способ, которым кошелёк выражает глубину конфликта. Оно не означает отрицательного числа блоков в правилах консенсуса. [5] [7]

Высота блока — его порядковый номер, отсчитываемый от начального блока с номером ноль. Если блок транзакции имеет высоту h, а последний блок активной цепочки узла — высоту H, число подтверждений равно H − h + 1. Сам блок с транзакцией, таким образом, считается первым. Результат зависит от лучшего проверенного блока данного узла, поэтому при поступлении новых блоков он может ненадолго различаться между узлами. Он не является частью транзакции, не растёт просто с течением времени и не может быть надёжно определён по временной метке. Bitcoin Core возвращает данные вроде blockhash, blockheight и confirmations согласно состоянию, известному соответствующему кошельку или представлению набора UTXO. [3] [5] [6]

SPV означает упрощённую проверку платежей, а RPC — программный интерфейс для запросов к узлу. Разница методов важна, даже если два приложения показывают одно и то же число. Полный узел проверяет цепочку и отвечает в соответствии с текущим концом своей проверенной цепочки. Клиент SPV проверяет Proof of Work в заголовках блоков и доказательство Меркла о включении транзакции, но сам не проверяет все правила консенсуса. Доказательство Меркла использует небольшой набор криптографических отпечатков данных, чтобы подтвердить включение транзакции в блок без загрузки всех его транзакций. Сервис, который хранит средства пользователей, дополнительно применяет собственные правила зачисления платежей и управления риском. Даже результат RPC от полного узла отражает состояние в определённый момент, которое может измениться из-за реорганизации. Поэтому помимо числа подтверждений важно, чьему представлению о цепочке, проверке и хранению средств доверяет пользователь. [1] [2] [8]

Coinbase Transaction — особая первая транзакция блока, выплачивающая награду майнеру; она не связана с биржей Coinbase. Временная блокировка ограничивает момент расходования средств. BIP обозначает техническое предложение или стандарт. Подтверждение также запускает некоторые сроки протокола. Выход coinbase-транзакции подчиняется правилу COINBASE_MATURITY = 100: его можно потратить не раньше чем в блоке, высота которого на 100 больше высоты блока с этой coinbase-транзакцией. Это обязательный период ожидания перед расходованием награды за блок, а не выбор получателя обычного платежа. Относительные временные блокировки BIP68 отсчитываются от подтверждения расходуемого выхода и оценивают его возраст по правилам для блоков или времени. Скрипт — короткая программа, определяющая условия расходования выхода. Команда CHECKSEQUENCEVERIFY (CSV) из BIP112 позволяет обеспечить выполнение этого относительного условия в скрипте. Транзакция, расходующая неподтверждённый выход, по-прежнему зависит от транзакции, которая его создала. Чтобы последующая транзакция могла подтвердиться, её предшественники должны быть включены в тот же или более ранний блок. [9] [10]

Lightning Network позволяет платить через каналы, финансируемые биткоин-транзакциями. BOLT — название её технических спецификаций; здесь речь об открытии канала, а не об ожидании блока при каждом платеже внутри него. BOLT 2 позволяет стороне, принимающей канал Lightning, задать в поле minimum_depth требуемое число подтверждений транзакции финансирования до отправки сообщения channel_ready. Этим требованием учитывается риск двойной траты средств, которыми финансируется канал. Канал, открытый без подтверждения, то есть zero-conf channel, устанавливает minimum_depth в ноль и сознательно полагается на доверие к финансирующей стороне и ограничения протокола. Это не даёт ему немедленного необратимого расчёта. Если сама транзакция финансирования является coinbase-транзакцией, BOLT 2 требует от стороны, которая не открывает канал, подождать не менее 100 блоков. Оператор должен отслеживать конкретный выход финансирования, то есть funding outpoint, его глубину в активной цепочке и реорганизации. Сам разосланный txid ещё не означает открытого канала. [12] [14]

Для полной картины прочитайте эту статью вместе с Block, Транзакция, Reorg, Двойная трата, Proof of Work, Bitcoin. На эту статью также ссылаются Двойная трата, Coinbase-транзакция, Reorg, Stale Block.

DOC · 001Bitcoin whitepaper — Proof-of-Work and CalculationsДокументация DOC · 002Bitcoin Core — ValidationДокументация DOC · 003Bitcoin Developer Guide — Block ChainДокументация DOC · 004Bitcoin Developer Guide — TransactionsДокументация DOC · 005Bitcoin Core RPC — gettransactionДокументация DOC · 006Bitcoin Core RPC — getbestblockhashДокументация DOC · 007Bitcoin Core — validation.cppДокументация DOC · 008Bitcoin Core — JSON-RPC consistencyДокументация DOC · 009Bitcoin Core — consensus.hДокументация DOC · 010BIP 112 — CHECKSEQUENCEVERIFYСпецификация DOC · 011BIP 125 — Opt-in Full Replace-by-FeeСпецификация DOC · 012BOLT 2 — Peer ProtocolСпецификация DOC · 013Rosenfeld — Analysis of Hashrate-Based Double SpendingДокументация DOC · 014Bitcoin Optech — Zero-conf channelsДокументация
Обновлено: Сначала источники · Не является инвестиционной рекомендацией