Подвійна витрата

Уявімо, що Томас має раніше отриманий вихід на 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]