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.