Двойная трата не создаёт новых биткоинов. Отправитель готовит две транзакции, пытающиеся потратить хотя бы одну и ту же ранее полученную сумму. Обе могут распространяться по сети, но не могут быть корректными в одной истории. Принимая платёж без подтверждения, то есть zero-conf, получатель действует до того, как станет ясно, какой вариант победит.
Представим, что у Томаса есть ранее полученный выход на 100 000 sat — наименьших единиц биткоина. Такой ещё не потраченный выход называется UTXO. Он готовит платёж Алисе на 99 000 sat, оставляя 1 000 sat в качестве комиссии. Но он мог бы подписать и другую транзакцию, которая тратит тот же UTXO, отправляя деньги в другое место. Обе используют один источник средств, поэтому конфликтуют. Это не копирование файла: узел Bitcoin, компьютер, проверяющий правила, не разрешит дважды потратить один выход в одной корректной цепочке. Мошенничество удалось бы, если бы Алиса отдала товар за первый платёж, а в принятой истории остался второй. Новых монет не появилось; Алиса доверилась проигравшему варианту. Технически каждый вход указывает на предыдущий выход через идентификатор его транзакции txid и номер выхода. Эта пара называется outpoint. [1] [3] [7]
Алиса может увидеть входящий платёж за несколько секунд. Но это ещё не означает, что он записан в блок. Mempool — местное хранилище неподтверждённых транзакций узла. Единого глобального Mempool или общего для всего Bitcoin порядка получения нет. Другой узел мог сначала получить конфликтующий вариант или ещё не видеть вариант Алисы. Политика first-seen отдаёт приоритет первой полученной версии при пересылке транзакций. Она не обещает, что майнер включит её в блок. Поэтому снимок экрана кошелька или сам txid не доказывают завершение расчёта. Важен статус конкретного платежа в надёжно проверенной цепочке. [2] [5]
Алиса может сама отправлять честный платёж, который долго ждёт. Replace-by-Fee (RBF) позволяет заменить неподтверждённую транзакцию другой, обычно с более высокой комиссией. Получатель может получить прежнюю сумму, хотя txid изменится. Замена использует хотя бы часть тех же средств, поэтому технически конфликтует с оригиналом, даже если никто не пытается обмануть получателя. Важны содержание новой оплаты и обстоятельства, а не сама отметка RBF. Однако тот же механизм позволяет направить деньги в другое место. Full-RBF является политикой Bitcoin Core по умолчанию с версии 28 и не требует, чтобы исходная транзакция сигнализировала о возможности замены. Замена всё равно должна выполнять правила узла о комиссиях и защите от злоупотреблений. Поэтому отсутствие сигнала RBF тоже не делает неподтверждённый платёж необратимым. [5] [6] [15]
Платёж получает подтверждение, когда попадает в корректный блок, принятый узлом. Последующие блоки обычно усложняют замену этой истории и снижают риск успешного мошенничества. Но единого безопасного числа для всех случаев нет. Потерять оплату кофе — не то же самое, что отдать автомобиль или разрешить крупный вывод с биржи. Часто упоминаемые шесть подтверждений — обычай, а не правило Bitcoin. Стоит учитывать сумму, возможность возмещения, необычное поведение цепочки и качество информации. Изоляция узла, известная как Eclipse Attack, может исказить его представление о сети. Поэтому ожидание должно дополнять проверку, а не заменять её. [2] [10]
Переход узла на другую корректную ветвь называется реорганизацией. Proof of Work подтверждает работу для создания блоков; накопленная работа ветви называется chainwork. После подтверждения конфликтующая транзакция уже не может просто вытеснить платёж из Mempool. Альтернативная корректная ветвь должна исключить исходный платёж, включить вторую трату и накопить больше работы, то есть chainwork, чем активная цепочка получателя. Реорганизация цепочки может произойти и без мошенничества, например при почти одновременно добытых блоках или сбое программного обеспечения либо сети. Двойная трата против жертвы успешна лишь тогда, когда злоумышленник получает ценность благодаря победе конфликтующей транзакции. Для проигравшей транзакции кошелька Bitcoin Core может показать отрицательное число подтверждений в поле confirmations и связанные конфликты в поле walletconflicts. [4] [7] [8]
Hashrate — скорость вычислений при майнинге. Большая доля помогает в гонке за историю, но не освобождает от остальных правил. Вероятность того, что скрытно добываемая ветвь догонит честную цепочку, зависит, в частности, от доли злоумышленника в вычислительной мощности сети и числа подтверждений. Возможная выгода прежде всего влияет на то, окупится ли атака. Доля ниже 50 % не означает нулевого шанса; устойчивое большинство значительно повышает возможность догнать другую ветвь. Но даже большинство не позволяет майнерам подделывать подписи, тратить чужие UTXO, нарушать правила эмиссии или заставлять полные узлы принимать некорректный блок. При оценке атаки нужно учитывать вычислительную мощность, энергию и награды, упущенные из-за отказа от честного майнинга. Важны также доступный капитал, риск неудачи и вероятность обнаружения. Доход может включать и прибыль от позиций на финансовых рынках, поэтому одной цены аренды оборудования для майнинга недостаточно для оценки. [1] [10] [12]
Race здесь означает состязание во времени: получатель и майнеры могут первыми увидеть разные транзакции. При race attack плательщик отправляет одну транзакцию продавцу, а конфликтующую с ней — майнерам или другим узлам. Он стремится добиться того, чтобы продавец безвозвратно передал товар раньше, чем блок выберет один из вариантов. Результат зависит от распространения транзакций, доступного продавцу представления о сети, выбора майнеров и момента передачи товара. Большее число независимых узлов, наблюдающих за сетью, улучшает обнаружение конфликтов, но не гарантирует необратимого расчёта. Названия race, Finney и Vector76 описывают сценарии атак, а не поля данных транзакции или разные правила консенсуса. [2] [11]
Finney attack — название сценария, в котором злоумышленник контролирует также майнинг. Это не обычное повышение комиссии в кошельке. При Finney attack злоумышленник, способный майнить, сначала скрытно добывает блок с конфликтующей транзакцией, которая возвращает средства ему. Затем тем же UTXO платит продавцу, принимающему платежи без подтверждения, и после получения товара публикует скрытый блок. План сработает только в том случае, если блок останется пригодным и сеть примет его раньше, чем честный конкурирующий блок сорвёт подготовку. Злоумышленник рискует наградой за блок и затратами на майнинг. Ожидание включения транзакции продавца в проверенный блок прерывает эту классическую последовательность, но не устраняет риск последующей реорганизации цепочки. [1] [11]
RPC — программный интерфейс узла. Ниже приведены команды и поля для разработчиков платёжных систем, а не другой вид подтверждения. Система продавца может на собственном полном узле отслеживать конфликтующие траты в Mempool, вызывать gettxspendingprevout, читать поле walletconflicts, сравнивать последний блок активной цепочки и предупреждать о потере подтверждений. Большее число подключённых или независимых узлов уменьшает слепые зоны, но отсутствие обнаруженного конфликта — слабое свидетельство безопасности: злоумышленник может придержать конфликтующую транзакцию или отправить её другим путём. Обозреватель блоков показывает представление собственного узла и может отставать. Обнаружение конфликта позволяет остановить передачу товара. Оно не может приказать майнерам, какую транзакцию выбрать, или сделать неподтверждённый платёж равноценным подтверждённому. [8] [9] [11]
Проверяйте фактически поступивший платёж, его адрес, сумму и подтверждения. Квитанция от отправителя этого не заменяет. Собственный полный узел позволяет проверять правила напрямую. Пользуясь сторонним сервисом, выясните, кому вы доверяете предоставление информации и, если сервис хранит ваши средства, их хранение. Система продавца должна связывать заказ с конкретными выходами и отслеживать замены. Конфликт или потеря подтверждений должны приостанавливать необратимую передачу товара. Следующая оплата, тратящая неподтверждённую сдачу, зависит от исходной транзакции, а не служит независимым доказательством её безопасности. Lightning Network позволяет быстро платить через каналы, профинансированные транзакцией Bitcoin. Участники канала обмениваются подписанными commitment-транзакциями, которые фиксируют распределение средств. При обновлении они передают другой стороне секретные данные, позволяющие применить штраф, если впоследствии будет опубликовано устаревшее состояние; такая отмена старого состояния называется revocation. Для защиты нужно вовремя обнаружить эту попытку и отреагировать на неё. Это другой механизм, чем передача товара за неподтверждённый перевод в цепочке. Открытый без подтверждения zero-conf channel сознательно доверяет финансирующей стороне и не устраняет риск двойной траты этого финансирования. [13] [14]
Для полной картины прочитайте эту статью вместе с Транзакция, Подтверждение, Mempool, Proof of Work, Replace-by-Fee (RBF), Bitcoin. На эту статью также ссылаются Подтверждение, Reorg, Stale Block, Replace-by-Fee (RBF).