Finality oznacza ostateczność rozrachunku: na ile można polegać na tym, że zakończony transfer pozostanie w mocy. Bitcoin daje pewność probabilistyczną, wzmacnianą przez dalszą prawidłową pracę. Żadna uniwersalna liczba potwierdzeń sama nie wyklucza zmiany gałęzi łańcucha ani nie rozstrzyga prawnego wykonania całej umowy.
Na początku Paweł widzi tylko, że jego portfel dowiedział się o transakcji. To jeszcze nie oznacza umieszczenia jej w bloku. Gdy blok powstanie i dołączą do niego następne, zastąpienie tej historii wymaga pokonania coraz większej ilości pracy. Tak rośnie praktyczna Finality. Znaczenie mają też zasoby ewentualnego atakującego i stan sieci. Protokół nie wydaje matematycznego certyfikatu nieodwracalności. Odbiorca ocenia, jak mocne podstawy ma do przyjęcia konkretnej płatności. [1] [2]
Full Node samodzielnie sprawdza reguły Bitcoina. Nie przyjmuje historii tylko dlatego, że jest długa. Najpierw bada jej poprawność, a spośród prawidłowych gałęzi wybiera tę o największej skumulowanej pracy. Chodzi o pracę wykazaną przez bloki, nie głosowanie liczbą osób czy monet. Więcej pracy nie czyni nieprawidłowej transakcji prawidłową. Dla Pawła ważne są oba pytania: czy płatność spełnia reguły oraz jak głęboko znajduje się w aktualnie używanej prawidłowej historii. [1]
W naszym przykładzie transakcja Pawła znajduje się w bloku o wysokości 800000, a obecny koniec tej samej gałęzi ma wysokość 800005. Wysokość oznacza pozycję bloku, nie godzinę. Liczymy 800005 − 800000 + 1 = 6 potwierdzeń; uwzględniamy także blok zawierający samą transakcję. Nie chodzi więc wyłącznie o bloki dodane później. Jeśli płatność jest tylko w mempool, czyli zbiorze niepotwierdzonych transakcji danego węzła, ma 0 potwierdzeń. Samo czekanie nie zwiększa tej liczby. [2] [3]
Sieć może przez krótki czas znać konkurencyjne bloki, a później kontynuować inną prawidłową gałąź o większej pracy. Taka zmiana aktywnej historii to reorganizacja. W dokumentacji Bitcoin Core 28.0 zapytanie o nagłówek bloku getblockheader zwraca confirmations = -1, jeśli blok nie należy do aktywnego łańcucha. Opisuje to blok, a nie automatyczną utratę wszystkich zawartych w nim płatności. Transakcja Pawła może być także w nowej gałęzi, czekać bez potwierdzenia lub kolidować z inną transakcją. Jej konkretny stan trzeba sprawdzić ponownie. [1] [3]
Przewodnik dla programistów wymienia 6 potwierdzeń jako często stosowany próg przy płatnościach o dużej wartości, ale wyjaśnia również potrzebę oceny ryzyka. Jest to reguła odbiorcy, nie moment zmiany konsensusu Bitcoina. Paweł powinien rozważyć wartość roweru, możliwą stratę i wiarygodność weryfikacji; liczba nie zdecyduje za niego. Średnio około godziny nie oznacza też, że sześć bloków zawsze pojawi się w godzinę. Wydobycie nie ma stałego rozkładu, a dawna ogólna rekomendacja nie gwarantuje bezpieczeństwa w każdej sytuacji. [2]
Paweł może otrzymać potwierdzone BTC i nadal spierać się o wydanie lub stan roweru. PFMI, międzynarodowe zasady dla infrastruktur rynku finansowego, wymagają jasno określonego momentu ostatecznego rozrachunku oraz granicy, po której uczestnik nie może odwołać instrukcji. To inne ramy niż liczenie bloków Bitcoina. Same potwierdzenia nie określają skutków prawnych umowy, ostateczności płatności bankowej ani przeniesienia własności przedmiotu. Kontrola płatności jest ważna, ale nie zastępuje pozostałych warunków transakcji. [4]
Jeśli Paweł uzgodni z kupującym zwrot, zwykle nastąpi on przez nową transakcję wysłaną przez odbiorcę pierwotnej płatności. Pierwotny transfer nie znika z historii. Bitcoin nie ma centralnej pomocy technicznej z przyciskiem anulowania potwierdzonej płatności na życzenie. Reorganizacja zmienia aktywną historię sieci; nie jest obsługą klienta do naprawiania pomyłek. Dlatego odbiorcę i kwotę trzeba sprawdzić przed wysłaniem. Dalsze potwierdzenia nie poprawią błędnie zleconego przelewu. [5]
Dla operatora aplikacji płatniczej przyjęcie zapłaty nie kończy pracy. Powinien zapisać transakcję, jej blok i źródło weryfikacji oraz rozpoznawać, czy węzeł nie pozostał w tyle za siecią. confirmations to stan w chwili zapytania, nie trwały certyfikat. Gdy liczba spadnie lub pojawi się konflikt, aplikacja potrzebuje wcześniej ustalonych zasad działania i ponownego sprawdzenia aktywnej gałęzi. Stary zrzut ekranu nie jest nowym dowodem. Paweł powinien kierować się obecnym stanem płatności, a nie tylko tym, co kiedyś pokazał portfel. [2] [3]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Potwierdzenie, Proof of Work, Settlement risk, Delivery versus payment. Do tego hasła prowadzą również odsyłacze z Byzantine Generals Problem, Delivery versus payment.