Potwierdzenie

Wysłanie nie jest potwierdzeniem. Każdy węzeł niezależnie stosuje zasady dostępu do swojej puli pamięci, a różne węzły mogą widzieć inny zestaw ze względu na czas, opłaty, konflikty, limity pakietów lub ustawienia. RBF może zastąpić niepotwierdzoną transakcję, a płatność widziana przez sprzedawcę może zniknąć bez dostania się do blokady. Zatem zero-conf zamienia prędkość na ryzyko podwójnych wydatków i niekompletnego widoku sieci; Ani strona txid, ani strona eksploratora nie są osadami. [Przewodnik programisty Bitcoin – Transakcje] [Bitcoin Core – Spójność JSON-RPC] [BIP 125 – Pełna wymiana przez opłatę za zgodę]

Górnik może wybrać transakcję do bloku kandydującego, ale pierwsze potwierdzenie następuje dopiero wtedy, gdy węzeł walidujący zaakceptuje blok, a blok leży w swoim aktywnym łańcuchu z największą siecią. Pełny węzeł sprawdza dowód pracy, skryptów, istnienia i niewydawania danych wejściowych, kwot i innych zasad konsensusu; górnik nie może zrealizować nieprawidłowych wydatków po prostu poprzez wystawienie oferty. Korzeń Merkle zatwierdza transakcję w bloku, a odniesienie do poprzedniego bloku umieszcza ją w historii pracy dowodu. [Bitcoin Core – Walidacja] [Bitcoin Core – validation.cpp]

Jeśli blok transakcji znajduje się na wysokości h, a bieżący wierzchołek węzła to H, licznik wynosi H - h + 1: sam blok jest liczony jako pierwszy. Wartość jest generowana na podstawie najlepiej zweryfikowanego bloku tego węzła, więc końcówka może się nieznacznie różnić w zależności od węzła. Nie jest zapisywany w transakcji, nie rośnie z biegiem czasu i nie można go wiarygodnie określić na podstawie znacznika czasu. Bitcoin Core zwraca blokhash, wysokość bloku i potwierdzenia jako stan portfela lub widok UTXO. [Przewodnik programisty Bitcoin – Łańcuch bloków] [Bitcoin Core RPC – gettransaction] [Bitcoin Core RPC – getbestblockhash]

Jeśli konkurencyjna, ważna gałąź zostanie wzmocniona, węzeł odłączy bloki starej końcówki i dołączy zwycięską gałąź. Transakcja z odłączonego bloku może powrócić do puli pamięci, jeśli pozostaje ważna, zostać zatwierdzona na innej wysokości lub wywołać konflikt, ponieważ nowa gałąź wydała te same dane wejściowe. Negatywne potwierdzenia w Bitcoin Core to konwencja portfela dotycząca głębokości konfliktu, a nie negatywne bloki w konsensusie. [Bitcoin Core RPC — gettransaction] [Bitcoin Core — validation.cpp]

Dodatkowe potwierdzenia dodają dowód wykonania transakcji, zazwyczaj czyniąc ją droższą i mało prawdopodobne, aby zapisała się na nowo historia. Nie tworzą deterministycznej ostateczności. Zarówno obliczenia nadrobienia zaległości zawarte w białej księdze, jak i późniejsze modele zależą od udziału hashrate'u atakującego, zachowania uczciwej sieci i obserwacji odbiorcy. „Sześć potwierdzeń” to narzędzie historyczne, a nie stała konsensusu lub uniwersalny bezpieczny limit; w zasadzie głęboka reorganizacja jest nadal możliwa. [Opracowanie Bitcoina – Dowód pracy i obliczenia] [Rosenfeld – Analiza podwójnych wydatków opartych na hashrate]

Liczenie jest wymagane przez odbiorcę, wymianę lub protokół końcowy, a nie samą transakcję. Kawa, bezzwrotna emisja drogich towarów, depozyt giełdowy i otwarcie kanału mają różne wskaźniki strat i oczekiwania. Polityka powinna uwzględniać wartość, odwracalność wyników, motywację i hashrate atakującego, konflikty lub RBF, opiekę i backend, ryzyko zaćmienia i nietypowy stan łańcucha. Potwierdzenie zmniejsza ryzyko nadpisania łańcucha; nie naprawi skradzionego klucza, złego adresu ani oszustwa ze strony kontrahenta. [BIP 125 – Pełna wymiana na opłatę za zgodę] [Rosenfeld – Analiza podwójnych wydatków w oparciu o hashrate]

Bitcoin dąży do średnio około dziesięciu minut pomiędzy blokami, ale dowody pracy pojawiają się losowo: następny blok może dotrzeć w ciągu kilku sekund lub godzin. Wyższa stawka może poprawić kolejność wyboru górników i ekonomikę pakietu RBF lub CPFP, ale brak opłaty oznacza zakup stałego czasu i nie przyspiesza tworzenia bloków. Tania transakcja może poczekać wiele bloków lub zostać usunięta z pamięci; oszacowanie jest prawdopodobieństwem, a nie ostatecznym terminem. [Przewodnik programisty Bitcoin – Łańcuch bloków] [Przewodnik programisty Bitcoin – Transakcje]

Pełny węzeł sprawdza ciąg i odpowiada zgodnie z własną aktywną końcówką. Klient SPV sprawdza dowód pracy w nagłówkach i włączenie dowodu Merkle, ale sam nie uruchamia wszystkich reguł konsensusu; usługa powiernicza dodaje również własną politykę kredytowania i ryzyka. Nawet wynik RPC pełnego węzła jest migawką, którą można zmienić poprzez reorganizację. Pytanie brzmi więc nie tylko „ile potwierdzeń”, ale także czyim widokom łańcucha, walidacji i opiece użytkownik ufa. [Opracowanie dotyczące Bitcoina – Dowód pracy i obliczenia] [Bitcoin Core – Walidacja] [Bitcoin Core – Spójność JSON-RPC]

Pozostałe zajęcia również rozpoczynają się od bierzmowania. Produkcja Coinbase podlega COINBASE_MATURITY = 100 i można ją wydać dopiero po 100 nowych blokach; jest to inna zasada niż zwykła polityka płatnicza. Względne blokady czasowe BIP68, wymuszane przez skrypt BIP112 CHECKSEQUENCEVERIFY (CSV), mierzą wiek z wyjściowego bloku zatwierdzania. Niepotwierdzony rodzic utrzymuje potomków na utrzymaniu; aby dziecko mogło zostać stwierdzone, jego przodkowie muszą znajdować się w tym samym lub starszym bloku. [Bitcoin Core – konsensus.h] [BIP 112 – CHECKSEQUENCEVERIFY]

BOLT 2 pozwala odbiornikowi kanału Lightning wybrać transakcje finansowania o minimalnej głębokości przed channel_ready; wartości liczbowe polegają na podwójnym wydatkowaniu finansowania ryzyka. Kanał o zerowej konfiguracji ustawia minimalną głębokość na zero i świadomie opiera się na zaufaniu do funduszu i ograniczeniach protokołu, a nie na natychmiastowej ostateczności. Finansowanie Coinbase oczekuje na immatrykulację. Operator powinien monitorować punkt końcowy finansowania, głębokość aktywnego łańcucha i reorganizacje, a nie uważać wysłanego TxID za kanał otwarty. [BOLT 2 — Protokół Peer] [Bitcoin Optech — Kanały o zerowej konfiguracji]