Конфлікт можна спостерігати ще до врегулювання, але успішне подвійне витрачання відбувається лише тоді, коли жертва витрачає вартість однієї транзакції, а інша виграє в отриманому ланцюжку. Таким чином, заміна платежу гаманця, ненавмисне підвищення комісії або невдалий конфлікт не є автоматично шахрайством. Змагання з нульовою конфігурацією та перезапис зареєстрованих блоків мають принципово різні витрати та ризики.
Кожен вхід посилається на попередній вихід за допомогою txid та індексу. Дві транзакції конфліктують, коли принаймні один вхід відноситься до того самого невитраченого балу, але вони не можуть оплатити одночасно. Під час перевірки блоку вузол перевіряє, чи вхідні дані існують і не були витрачені раніше в даній історії або в іншому місці того самого блоку. Тільки одна гілка виживає в дійсному наборі UTXO; атака не створює копію сатоші, вона намагається змусити одержувача діяти на гілці, яка програє. [Офіційний документ щодо біткойнів — Транзакції, сервер міток часу та обчислення] [Посібник розробника біткойнів — Транзакції] [Ядро біткойнів — validation.cpp]
Немає глобального mempool або консенсусного порядку незафіксованих транзакцій перед майнінгом. Однорангові користувачі спочатку можуть побачити різноманітні конфлікти через просування, топологію, політику комісії, статус пакета або ізоляцію затемнення. First-seen – це політика ретрансляції, а не зобов’язання майнерів підтверджувати перший варіант. txid на сервері торговця лише доводить, що прийшов один підписаний кандидат, а не те, що вся мережа його побачила або виграла блок. [Посібник розробника біткойнів — Обробка платежів] [Ядро біткойнів — заміни Mempool]
Заміна за плату дозволяє вузлу замінювати конфлікти mempool, які відповідають правилам плати та анти-DoS; full-RBF є політикою за замовчуванням у Bitcoin Core з версії 28. Відправник може законно збільшити комісію за застряглий платіж і зберегти вихідні дані одержувача або перенаправити значення. В обох випадках консенсус бачить загальних кандидатів і приймає варіант у дійсній історії видобутку. Сигнал RBF, заміна чи удар самі по собі не є доказом шахрайства; транзакція без сигналу знову не безпечна для zero-conf. [Bitcoin Core — Mempool Replacements] [BIP 125 — Opt-in Full Replace-by-Fee]
Під час атаки змагання платник надсилає одну транзакцію продавцю, а конфлікт — майнерам або іншим аналогам, так що торговець видає товари, що не підлягають поверненню, перш ніж блок вибере один варіант. Результат залежить від акції, погляду мережі торговця, вибору майнерів і часу передачі. Більше незалежних слухачів покращить виявлення, але не створить детермінованої остаточності. Назви race, Finney і Vector76 є моделями сценаріїв, а не масивами транзакцій чи різноманітними правилами консенсусу. [Посібник розробника біткойнів — Обробка платежів] [Карам та ін. — Неправильна поведінка в Bitcoin]
Зловмисник у стилі Фінні з можливістю майнінгу спочатку приватно знаходить блок, що містить конфлікт, повертаючи йому значення, потім платить продавцю нульову конфігурацію тим самим UTXO та публікує прихований блок після отримання товару. План успішний, лише якщо блок залишається придатним для використання та приймається мережею до того, як блок чесного суперника завадить підготовці; зловмисник ризикує як винагородою за блок, так і витратами на майнінг. Очікування, поки транзакцію продавця буде включено до перевіреного блоку, завершує класичну послідовність, але не усуває пізніший ризик повторної організації. [Офіційний документ щодо біткойнів — транзакції, сервер часових позначок і обчислення] [Karame et al. — Неправильна поведінка в Bitcoin]
Після підтвердження конфлікт більше не може просто виштовхнути платіж із пам’ятного пулу: альтернативна дійсна гілка має пропустити платіж, включити другу витрату та отримати більше ланцюжка, ніж активний ланцюжок одержувача. Реорганізація може статися навіть без шахрайства в майже одночасних блоках або програмного або мережевого інциденту; успішне подвійне витрачання проти жертви лише для того, щоб отримати цінність, вигравши конфлікт. Bitcoin Core може показувати негативні підтвердження та конфлікти гаманців для втраченої транзакції гаманця. [Bitcoin Core — Перевірка] [Bitcoin Core — validation.cpp] [Bitcoin Core RPC — gettransaction]
Частка хешрейту зловмисника, глибина підтвердження та доступна вартість визначають стохастичну гонку приватної та чесної роботи. Нижче 50% не означає нульовий шанс; постійна більшість значно збільшує можливість наздоганяти, але це не дозволяє майнерам підробляти підписи, витрачати іноземні UTXO, перевищувати емісію або змушувати повні вузли приймати недійсний блок. Витрати включають хеш-потужність, енергію, втрачені чесні винагороди, ризик втрати, ліквідність і ризик; дохід також може включати ринкові позиції, тому просто ціни на оренду машин недостатньо. [Офіційний документ щодо біткойнів — транзакції, сервер відміток часу та обчислення] [Розенфельд — аналіз подвійних витрат на основі хешрейту] [Ґарай, Кіайас і Леонардос — магістральний протокол біткойнів]
Кожна додаткова фіксація змушує альтернативну гілку переробляти більше невиконаних завдань і, враховуючи припущення, зменшує ймовірність успіху. Універсального безпечного номера немає: кава, автомобіль, біржовий депозит і безповоротне зняття мають різну цінність, мотивацію та можливість виправлення. Шість часто цитованих афірмацій є умовністю, а не консенсусом. Політика також повинна контролювати розподіл хешрейту, незвичайні реорганізації, довіру до серверної частини, ризик затемнення та оборотність передач. [Посібник розробника біткойнів — Обробка платежів] [Розенфельд — Аналіз подвійних витрат на основі хешрейту]
Сервер може стежити за витратами конфліктуючого mempool на власному повному вузлі, викликати gettxspendingprevout, читати конфлікти гаманців, порівнювати активну підказку та попереджати про втрату підтвердження. Більше однорангових або незалежних вузлів зменшує сліпі плями, але відсутність виявленого конфлікту є слабким доказом: зловмисник може його перехопити або відправити в інше місце. Провідник показує настроюване подання вузла і може бути затримано. Виявлення дозволяє припинити видачу; він не може сказати майнерам виграти або перетворити нульову конфігурацію на підтвердження. [Bitcoin Core RPC — gettransaction] [Bitcoin Core RPC — gettxspendingprevout] [Karame et al. — Неправильна поведінка в Bitcoin]
Для розрахунку в ланцюжку перевірте за допомогою власного повного вузла, зв’яжіть замовлення з точним txid, виходами та сумою, встановіть глибину відповідно до можливої втрати, у разі повторної організації або конфлікту зупиніть виконання та відокремте зарахований баланс від суми, що знімається. Не розглядайте непідтвердженого нащадка зміни як незалежного від батька. Lightning по-іншому обробляє швидкі повторювані платежі: підтверджена точка фінансування закріплює канал, а правила зобов’язань/відкликання контролюють стан поза мережею; Канал zero-conf свідомо довіряє спонсору та не усуває ризик подвійного витрачання коштів. [BOLT 2 — Peer Protocol] [Bitcoin Optech — Zero-conf channels]
Для повної картини прочитайте також Транзакція, Підтвердження, Mempool, Proof of Work, Replace-by-Fee (RBF), Bitcoin. На цю статтю також посилаються Підтвердження, Reorg, Stale Block, Replace-by-Fee (RBF).