37 / 736CONF

Potwierdzenie

Potwierdzenie transakcji Bitcoin

Potwierdzenie oznacza, że płatność trafiła do przyjętego bloku. Kolejne bloki umieszczają ją głębiej w historii i zwykle utrudniają jej zmianę. Samo naciśnięcie Wyślij nie tworzy potwierdzenia.

Confirmation oznacza umieszczenie transakcji w prawidłowym bloku łańcucha, który śledzi twój portfel. Ten blok daje pierwsze potwierdzenie. Każdy następny dodaje kolejne, choć nie zawiera płatności ponownie. Liczba określa głębokość w historii, a nie liczbę osób, które zatwierdziły przelew.

Alicja wysyła znajomemu 20 000 sat, najmniejszych jednostek bitcoina. Jej portfel pokazuje Wysłano, a znajomy widzi już płatność przychodzącą, ale z zerem potwierdzeń. Nie ma tu sprzeczności: informacja dotarła do węzłów, czyli komputerów weryfikujących Bitcoin, lecz jeszcze nie do bloku. Mempool to lokalny zbiór niepotwierdzonych transakcji danego węzła, nie jedna kolejka całej sieci. Gdy płatność trafi do przyjętego bloku, uzyska pierwsze potwierdzenie. Następny blok da drugie, a kolejny trzecie. Alicja nie musi wysyłać nic ponownie. Rozgłoszenie transakcji nie jest potwierdzeniem, a jej identyfikator txid też go nie gwarantuje. Niepotwierdzoną transakcję można zastąpić, na przykład przez Replace-by-Fee (RBF), aby podnieść opłatę. Przyjęcie płatności bez potwierdzenia nazywa się zero-conf i oznacza ryzyko, że ostatecznie potwierdzi się inne wydanie tych samych środków. [4] [8] [11]

Górnik wybiera transakcje do nowego bloku i szuka prawidłowego Proof of Work — wyniku kosztownych obliczeń wymaganego przez reguły Bitcoina. Pozostałe pełne węzły samodzielnie sprawdzają blok: czy zgadzają się podpisy, kwoty i warunki wydania oraz czy środki nie zostały już wydane? Nie jest to głosowanie górników ani pieczątka jednej firmy. Górnik nie uczyni nieprawidłowej płatności prawidłową przez samo włączenie jej do bloku. Węzeł uznaje ją za potwierdzoną tylko w przyjętym łańcuchu. Spośród prawidłowych gałęzi wybiera tę z największą zgromadzoną pracą, zwaną chainwork. Każdy blok odwołuje się do poprzedniego, więc zmiana wcześniejszej historii wymaga przebudowy także jej dalszej części. [2] [7]

Bitcoin dąży do średnio dziesięciu minut między blokami, a nie do rozkładu jazdy. Nowy blok może pojawić się po sekundach albo znacznie później. Godzina czekania sama w sobie nie oznacza sześciu potwierdzeń. Wyższa stawka opłaty może zwiększyć szansę wyboru transakcji przez górnika, ale nie przyspiesza powstawania bloków. Niektóre portfele oferują RBF, zastąpienie niepotwierdzonej transakcji inną z wyższą opłatą, lub CPFP (Child Pays for Parent): zależna transakcja dodaje dość opłat, aby opłacało się włączyć ją razem z poprzednią. Dostępność zależy od portfela i transakcji. Niska opłata może oznaczać długie czekanie lub usunięcie z Mempoolu węzła. Szacunek portfela traktuj więc jako szacunek, nie przyrzeczony termin. [3] [4]

Odbiorca lub usługa decyduje, ilu potwierdzeń wymaga przed uznaniem płatności. Mały zakup może uzasadniać inne ryzyko niż nieodwracalne przekazanie drogiego towaru. Jeżeli giełda czeka na kilka potwierdzeń, transakcja może już być w blockchainie, choć saldo konta nie zostało jeszcze uznane. Nie musi to oznaczać błędu. Sprawdź kwotę, adres i stan we własnym portfelu, a także zasady księgowania wpłat przez usługę. Ważne jest też źródło informacji. Napastnik może odizolować węzeł i przekazywać mu ograniczony obraz sieci; to Eclipse Attack. Rozsądna długość oczekiwania zależy więc od wartości, możliwości naprawienia skutków, zaufania do drugiej strony i sposobu weryfikacji. Sama liczba potwierdzeń nie chroni przed kradzieżą klucza. [11] [13]

Wyobraź sobie płatność jako zapis, nad którym przybywają kolejne strony historii. Zmiana jednej starej strony nie wystarczy: napastnik musiałby stworzyć konkurencyjną prawidłową kontynuację z odpowiednią ilością pracy. Przy zwykłych założeniach kolejne potwierdzenia to utrudniają. Wynik zależy jednak także od mocy obliczeniowej napastnika i stanu sieci. Często przywoływane sześć potwierdzeń to historyczna wskazówka, nie reguła konsensusu ani magiczna granica pełnego bezpieczeństwa. Nie ma jednej stałej wartości prawdopodobieństwa przepisania historii, która uczciwie opisywałaby każdą sytuację. Więcej potwierdzeń nie naprawi też błędnego adresu ani płatności oszustowi. [1] [13]

Krótkie rozgałęzienie może powstać bez ataku, gdy dwóch górników znajdzie blok niemal jednocześnie. Przejście węzła na inną zwycięską gałąź nazywa się reorganizacją. Wyjście transakcji zapisuje kwotę i warunki jej wydania; wejście późniejszej transakcji wskazuje to wyjście i je wydaje. Niewydane wyjście nazywa się UTXO. Jeśli konkurencyjna prawidłowa gałąź zgromadzi więcej pracy, czyli chainwork, węzeł odłącza końcowe bloki pierwotnego łańcucha i dołącza zwycięską gałąź. Transakcja z odłączonego bloku może wrócić do Mempoolu, jeżeli nadal jest prawidłowa, albo zostać potwierdzona na innej wysokości. Może też wejść w konflikt, jeśli nowa gałąź wydała to samo wyjście, na które wskazuje jej wejście. Ujemna wartość confirmations w Bitcoin Core jest sposobem, w jaki portfel przedstawia głębokość konfliktu. Nie oznacza ujemnej liczby bloków w regułach konsensusu. [5] [7]

Wysokość bloku to jego pozycja w kolejności, liczona od początkowego bloku o numerze zero. Jeśli blok transakcji ma wysokość h, a ostatni blok aktywnego łańcucha węzła wysokość H, liczba potwierdzeń wynosi H − h + 1. Sam blok zawierający transakcję liczy się zatem jako pierwszy. Wynik zależy od najlepszego zweryfikowanego bloku danego węzła, więc przy nadejściu nowych bloków może chwilowo różnić się między węzłami. Nie jest częścią transakcji, nie rośnie przez sam upływ czasu i nie można go wiarygodnie wyznaczyć ze znacznika czasu. Bitcoin Core zwraca dane takie jak blockhash, blockheight i confirmations zgodnie ze stanem znanym danemu portfelowi lub dostępnemu obrazowi zbioru UTXO. [3] [5] [6]

SPV oznacza uproszczoną weryfikację płatności, a RPC jest interfejsem programistycznym do odpytywania węzła. Różnica metod ma znaczenie nawet wtedy, gdy dwie aplikacje pokazują tę samą liczbę. Pełny węzeł weryfikuje łańcuch i odpowiada zgodnie z aktualnym końcem swojego zweryfikowanego łańcucha. Klient SPV sprawdza Proof of Work w nagłówkach bloków oraz dowód Merkle’a na włączenie transakcji, ale sam nie sprawdza wszystkich reguł konsensusu. Dowód Merkle’a wykorzystuje niewielki zestaw kryptograficznych odcisków danych, aby wykazać obecność transakcji w bloku bez pobierania wszystkich jego transakcji. Usługa, która przechowuje środki za użytkowników, dodatkowo stosuje własne zasady księgowania płatności i zarządzania ryzykiem. Nawet wynik RPC z pełnego węzła przedstawia stan w określonym momencie, który może zmienić reorganizacja. Oprócz liczby potwierdzeń znaczenie ma więc także to, czyjemu obrazowi łańcucha, weryfikacji i przechowywaniu środków ufa użytkownik. [1] [2] [8]

Coinbase Transaction jest szczególną pierwszą transakcją bloku wypłacającą nagrodę górnikowi; nie ma związku z giełdą Coinbase. Blokada czasowa ogranicza moment wydania środków. BIP oznacza propozycję techniczną lub standard. Potwierdzenie uruchamia też niektóre okresy oczekiwania określone przez protokół. Wyjście transakcji coinbase podlega regule COINBASE_MATURITY = 100: można je wydać najwcześniej w bloku o wysokości większej o 100 od wysokości bloku zawierającego tę transakcję coinbase. To obowiązkowy okres oczekiwania przed wydaniem nagrody za blok, a nie wybór odbiorcy zwykłej płatności. Względne blokady czasowe BIP68 opierają się na potwierdzeniu wydawanego wyjścia i oceniają jego wiek według reguł dotyczących bloków lub czasu. Skrypt to krótki program określający warunki wydania wyjścia. Polecenie CHECKSEQUENCEVERIFY (CSV) z BIP112 pozwala wymusić ten względny warunek w skrypcie. Transakcja wydająca niepotwierdzone wyjście nadal zależy od transakcji, która je utworzyła. Aby transakcja zależna mogła zostać potwierdzona, transakcje, od których ona zależy, muszą znaleźć się w tym samym lub wcześniejszym bloku. [9] [10]

Lightning Network umożliwia płatności kanałami finansowanymi transakcjami Bitcoin. BOLT to nazwa jej specyfikacji technicznych; tutaj chodzi o otwarcie kanału, nie o czekanie na blok przy każdej płatności w nim. BOLT 2 pozwala stronie przyjmującej kanał Lightning określić w polu minimum_depth wymaganą liczbę potwierdzeń transakcji finansującej przed wysłaniem wiadomości channel_ready. W ten sposób uwzględnia ryzyko podwójnego wydania środków finansujących kanał. Kanał otwarty bez potwierdzenia, czyli zero-conf channel, ustawia minimum_depth na zero i świadomie polega na zaufaniu do podmiotu finansującego oraz ograniczeniach protokołu. Nie uzyskuje przez to natychmiastowego nieodwracalnego rozliczenia. Jeśli sama transakcja finansująca jest transakcją coinbase, BOLT 2 nakazuje stronie, która nie otwiera kanału, odczekać co najmniej 100 bloków. Operator powinien śledzić konkretne wyjście finansujące, czyli funding outpoint, jego głębokość w aktywnym łańcuchu i reorganizacje. Sam rozgłoszony txid nie oznacza jeszcze otwartego kanału. [12] [14]

Pełniejszy obraz uzyskasz, czytając to hasło razem z Block, Transakcja, Reorg, Podwójne wydanie, Proof of Work, Bitcoin. Do tego hasła prowadzą również odsyłacze z Podwójne wydanie, Transakcja coinbase, Reorg, Stale Block.

DOC · 001Bitcoin whitepaper — Proof-of-Work and CalculationsDokumentacja DOC · 002Bitcoin Core — ValidationDokumentacja DOC · 003Bitcoin Developer Guide — Block ChainDokumentacja DOC · 004Bitcoin Developer Guide — TransactionsDokumentacja DOC · 005Bitcoin Core RPC — gettransactionDokumentacja DOC · 006Bitcoin Core RPC — getbestblockhashDokumentacja DOC · 007Bitcoin Core — validation.cppDokumentacja DOC · 008Bitcoin Core — JSON-RPC consistencyDokumentacja DOC · 009Bitcoin Core — consensus.hDokumentacja DOC · 010BIP 112 — CHECKSEQUENCEVERIFYSpecyfikacja DOC · 011BIP 125 — Opt-in Full Replace-by-FeeSpecyfikacja DOC · 012BOLT 2 — Peer ProtocolSpecyfikacja DOC · 013Rosenfeld — Analysis of Hashrate-Based Double SpendingDokumentacja DOC · 014Bitcoin Optech — Zero-conf channelsDokumentacja
Zaktualizowano: Najpierw źródła · To nie jest porada inwestycyjna