Finality

Спершу Павло бачить лише те, що гаманець дізнався про транзакцію. Це ще не означає її включення до блоку. Коли блок з’являється і до нього додаються наступні, для заміни цієї історії потрібно перевершити дедалі більше роботи. Так на практиці посилюється Finality. Але значення мають також ресурси можливого нападника та стан мережі. Протокол не видає математичного сертифіката незворотності: одержувач оцінює, наскільки надійні підстави має для прийняття конкретного платежу. [1] [2]

Full Node самостійно перевіряє правила Bitcoin. Він не приймає історію лише тому, що вона довга. Спочатку перевіряє її дійсність, а серед дійсних гілок обирає ту, що має найбільшу накопичену роботу. Йдеться про роботу, засвідчену блоками, а не голосування за кількістю людей чи монет. Більше роботи не робить недійсну транзакцію дійсною. Павлові важливо перевірити обидві речі: чи відповідає платіж правилам і наскільки глибоко він міститься в дійсній історії, яку зараз використовує вузол. [1]

У нашому прикладі транзакція Павла міститься в блоці висоти 800000, а поточна вершина тієї самої гілки має висоту 800005. Висота — це позиція блоку, а не час. Розрахунок: 800005 − 800000 + 1 = 6 підтверджень; враховується й сам блок із транзакцією. Тобто рахують не лише блоки, додані після нього. Якщо платіж є тільки в mempool, наборі непідтверджених транзакцій цього вузла, він має 0 підтверджень. Саме очікування не збільшує їхню кількість. [2] [3]

Мережа може ненадовго знати про конкурентні блоки, а згодом продовжити іншу дійсну гілку з більшою роботою. Таку зміну активної історії називають реорганізацією. У документації Bitcoin Core 28.0 запит заголовка блоку getblockheader повертає confirmations = -1, якщо блок не належить до активного ланцюга. Це описує блок, а не автоматичну втрату всіх його платежів. Транзакція Павла може бути й у новій гілці, чекати без підтвердження або конфліктувати з іншою транзакцією. Її конкретний стан потрібно перевірити знову. [1] [3]

Посібник для розробників згадує 6 підтверджень як поширений поріг для платежів великої вартості, але водночас пояснює необхідність оцінки ризику. Це правило одержувача, а не момент зміни консенсусу Bitcoin. Павло має врахувати вартість велосипеда, можливу втрату та надійність перевірки; сама цифра за нього не вирішить. Середній час близько години теж не означає, що шість блоків завжди з’являються за годину. Майнінг не має сталого розкладу, а давня загальна рекомендація не є гарантією для кожної ситуації. [2]

Павло може мати підтверджені BTC і водночас сперечатися щодо передачі чи стану велосипеда. PFMI, міжнародні принципи для інфраструктур фінансових ринків, вимагають чітко визначеного моменту остаточного розрахунку та межі, після якої учасник не може відкликати інструкцію. Це інша система правил, ніж підрахунок блоків Bitcoin. Підтвердження саме собою не визначає юридичних наслідків договору, остаточності банківського платежу чи переходу права власності. Перевірка платежу важлива, але не замінює решти умов угоди. [4]

Якщо Павло й покупець домовляться про повернення коштів, зазвичай його здійснюють новою транзакцією від одержувача початкового платежу. Первинний переказ не зникає з історії. У Bitcoin немає центральної служби підтримки з кнопкою скасування підтверджених платежів на прохання клієнта. Реорганізація змінює активну історію мережі; це не сервіс для виправлення помилок користувача. Тому одержувача й суму потрібно перевіряти до відправлення. Додаткові підтвердження не виправлять помилково заданого платежу. [5]

Для оператора платіжного застосунку прийняття платежу не завершує роботу. Потрібно записувати транзакцію, її блок і джерело перевірки та помічати, чи не відстав вузол від мережі. Значення confirmations — це стан на момент запиту, а не постійний сертифікат. Якщо кількість зменшиться або з’явиться конфлікт, застосунок має діяти за заздалегідь визначеними правилами й знову перевірити активну гілку. Старий знімок екрана не є новим доказом. Павлові слід вирішувати за поточним станом платежу, а не лише за тим, що колись показав гаманець. [2] [3]