Podwójne wydanie nie tworzy nowych bitcoinów. Nadawca przygotowuje dwie transakcje, które próbują wykorzystać co najmniej jedno wspólne źródło wcześniej otrzymanych środków. Obie mogą krążyć w sieci, ale nie mogą być prawidłowe w jednej historii. Przyjęcie płatności bez potwierdzenia, czyli zero-conf, oznacza działanie, zanim będzie wiadomo, który wariant zwycięży.
Załóżmy, że Tomasz ma wcześniej otrzymane wyjście o wartości 100 000 sat, najmniejszych jednostek bitcoina. Takie niewydane wyjście nazywa się UTXO. Przygotowuje płatność 99 000 sat dla Alicji, zostawiając 1 000 sat opłaty. Mógłby jednak podpisać także inną transakcję, która wydaje to samo UTXO i wysyła pieniądze gdzie indziej. Obie sięgają po te same środki, więc są ze sobą sprzeczne. To nie kopiowanie pliku: węzeł Bitcoin, komputer sprawdzający reguły, nie pozwoli wydać tego samego wyjścia dwa razy w prawidłowym łańcuchu. Oszustwo powiodłoby się, gdyby Alicja wydała towar za pierwszą płatność, ale w przyjętej historii ostatecznie znalazła się druga. Nowe monety nie powstały; Alicja zaufała przegranemu wariantowi. Technicznie każde wejście wskazuje wcześniejsze wyjście przez identyfikator jego transakcji, txid, oraz numer wyjścia. Ta para to outpoint. [1] [3] [7]
Alicja może zobaczyć przychodzącą płatność po kilku sekundach. Nie oznacza to jeszcze zapisu w bloku. Mempool jest lokalnym zbiorem niepotwierdzonych transakcji węzła. Nie istnieje jeden globalny Mempool ani wspólna dla całego Bitcoina kolejność nadejścia. Inny węzeł mógł najpierw otrzymać sprzeczny wariant albo jeszcze nie widzieć płatności Alicji. Polityka first-seen preferuje przy przekazywaniu transakcji wariant otrzymany jako pierwszy. Nie obiecuje, że górnik umieści go w bloku. Zrzut ekranu portfela ani sam txid nie dowodzą zatem rozliczenia. Liczy się stan konkretnej płatności w wiarygodnie zweryfikowanym łańcuchu. [2] [5]
Alicja może też sama wysyłać uczciwą płatność, która długo czeka. Replace-by-Fee (RBF) pozwala zastąpić niepotwierdzoną transakcję inną, zwykle oferującą wyższą opłatę. Odbiorca może dostać tę samą kwotę mimo zmiany txid. Zamiennik wykorzystuje przynajmniej część tych samych środków, więc technicznie koliduje z oryginałem, choć nikt nie próbuje oszukać odbiorcy. Ważna jest treść nowej płatności i okoliczności, nie sam napis RBF. Ten mechanizm może jednak również przekierować środki. Full-RBF jest domyślną polityką Bitcoin Core od wersji 28 i nie wymaga sygnalizowania zastępowalności przez pierwotną transakcję. Zamiennik nadal musi spełniać reguły opłat i ochrony węzła przed nadużyciami. Brak sygnału RBF również nie czyni więc niepotwierdzonej płatności nieodwracalną. [5] [6] [15]
Płatność otrzymuje potwierdzenie, gdy trafia do prawidłowego bloku przyjętego przez węzeł. Kolejne bloki zwykle utrudniają zastąpienie tej historii i zmniejszają ryzyko oszustwa. Nie ma jednak bezpiecznej liczby dla każdej sytuacji. Utrata zapłaty za kawę różni się od oddania samochodu albo zatwierdzenia dużej wypłaty z giełdy. Często wymieniane sześć potwierdzeń to zwyczaj, nie reguła Bitcoina. Trzeba uwzględnić kwotę, możliwość naprawienia szkody, nietypowe zachowanie łańcucha i jakość informacji. Izolacja węzła, znana jako Eclipse Attack, może zniekształcić jego obraz sieci. Czekanie powinno więc towarzyszyć weryfikacji, a nie ją zastępować. [2] [10]
Przejście węzła na inną prawidłową gałąź nazywa się reorganizacją. Proof of Work poświadcza pracę potrzebną do tworzenia bloków; skumulowana praca gałęzi to chainwork. Po potwierdzeniu sprzeczna transakcja nie może już po prostu wyprzeć płatności z Mempoolu. Alternatywna prawidłowa gałąź musi pominąć pierwotną płatność, uwzględnić drugie wydanie i zgromadzić więcej pracy, czyli chainwork, niż aktywny łańcuch odbiorcy. Reorganizacja łańcucha może wystąpić także bez oszustwa, na przykład przy niemal równoczesnym wydobyciu bloków albo błędzie oprogramowania lub sieci. Podwójne wydanie przeciwko ofierze udaje się dopiero wtedy, gdy napastnik zyskuje wartość dzięki zwycięstwu sprzecznej transakcji. Dla przegranej transakcji portfela Bitcoin Core może pokazać ujemną liczbę potwierdzeń w polu confirmations oraz powiązane konflikty w polu walletconflicts. [4] [7] [8]
Hashrate to szybkość obliczeń przy wydobywaniu. Większy udział pomaga w wyścigu o historię, lecz nie zwalnia z pozostałych reguł. Szansa, że potajemnie wydobywana gałąź dogoni uczciwy łańcuch, zależy między innymi od udziału napastnika w mocy obliczeniowej sieci i liczby potwierdzeń. Wartość możliwego łupu wpływa przede wszystkim na to, czy atak się opłaca. Udział poniżej 50 % nie oznacza zerowej szansy; utrzymywana większość znacznie zwiększa możliwość dogonienia drugiej gałęzi. Nawet większość nie pozwala jednak górnikom fałszować podpisów, wydawać cudzych UTXO, naruszać reguł emisji ani zmusić pełnych węzłów do przyjęcia nieprawidłowego bloku. Przy ocenie ataku trzeba uwzględnić moc obliczeniową, energię i nagrody utracone przez rezygnację z uczciwego wydobywania. Znaczenie mają też dostępny kapitał, ryzyko niepowodzenia i możliwość wykrycia. Zysk może również pochodzić z pozycji na rynkach finansowych, dlatego sama cena wynajmu sprzętu wydobywczego nie wystarcza do oszacowania. [1] [10] [12]
Race oznacza tu wyścig w czasie: odbiorca i górnicy mogą najpierw zobaczyć różne transakcje. W ataku typu race attack płatnik wysyła jedną transakcję do sprzedawcy, a transakcję z nią sprzeczną do górników lub innych węzłów. Chce skłonić sprzedawcę do nieodwracalnego przekazania towaru, zanim blok wybierze jeden z wariantów. Wynik zależy od rozchodzenia się transakcji, obrazu sieci dostępnego sprzedawcy, wyboru górników oraz chwili przekazania towaru. Więcej niezależnych węzłów obserwujących sieć usprawnia wykrywanie konfliktów, ale nie gwarantuje nieodwracalnego rozliczenia. Nazwy race, Finney i Vector76 opisują scenariusze ataków, a nie pola danych transakcji ani różne reguły konsensusu. [2] [11]
Finney attack to nazwa scenariusza, w którym napastnik ma również możliwość wydobywania. Nie chodzi o zwykłe podniesienie opłaty w portfelu. W ataku typu Finney attack napastnik zdolny do wydobywania najpierw wydobywa w tajemnicy blok ze sprzeczną transakcją, która zwraca wartość jemu. Następnie tym samym UTXO płaci sprzedawcy przyjmującemu płatności bez potwierdzenia i po otrzymaniu towaru publikuje ukryty blok. Plan uda się tylko wtedy, gdy blok nadal nadaje się do użycia, a sieć przyjmie go, zanim uczciwy konkurencyjny blok udaremni przygotowania. Napastnik ryzykuje więc nagrodę za blok oraz koszty wydobycia. Oczekiwanie na włączenie transakcji sprzedawcy do zweryfikowanego bloku przerywa ten klasyczny schemat, lecz nie usuwa ryzyka późniejszej reorganizacji łańcucha. [1] [11]
RPC jest interfejsem programistycznym węzła. Poniższe nazwy to polecenia i pola dla twórców systemów płatności, a nie kolejny rodzaj potwierdzenia. System sprzedawcy może na własnym pełnym węźle śledzić sprzeczne wydania w Mempoolu, wywoływać gettxspendingprevout, odczytywać pole walletconflicts, porównywać ostatni blok aktywnego łańcucha i ostrzegać o utracie potwierdzeń. Więcej połączonych lub niezależnych węzłów ogranicza martwe pola, ale brak wykrytego konfliktu jest słabym dowodem bezpieczeństwa: napastnik może wstrzymać sprzeczną transakcję lub wysłać ją inną drogą. Eksplorator bloków pokazuje obraz dostępny jego własnemu węzłowi i może mieć opóźnienie. Wykrycie konfliktu pozwala zatrzymać przekazanie towaru. Nie może jednak nakazać górnikom wyboru określonej transakcji ani zrównać płatności niepotwierdzonej z potwierdzoną. [8] [9] [11]
Sprawdzaj rzeczywistą przychodzącą płatność, jej adres, kwotę i potwierdzenia. Dowód dostarczony przez nadawcę tego nie zastąpi. Własny pełny węzeł pozwala bezpośrednio weryfikować reguły. Korzystając z cudzej usługi, warto wiedzieć, komu ufasz w kwestii informacji i, jeśli to dotyczy tej usługi, przechowywania środków. System sklepu powinien łączyć zamówienie z konkretnymi wyjściami oraz śledzić zamiany transakcji. Konflikt lub utrata potwierdzeń powinny wstrzymywać nieodwracalne wydanie towaru. Kolejna płatność wydająca niepotwierdzoną resztę zależy od pierwszej transakcji; nie jest niezależnym dowodem jej bezpieczeństwa. Lightning Network umożliwia szybkie płatności w kanałach finansowanych transakcją Bitcoin. Uczestnicy kanału wymieniają podpisane transakcje commitment, które określają podział środków. Przy aktualizacji przekazują drugiej stronie tajne dane pozwalające zastosować karę, gdyby później opublikowali nieaktualny stan; takie unieważnienie starego stanu nazywa się revocation. Ochrona wymaga wykrycia takiej próby i reakcji na czas. To inny mechanizm niż wydanie towaru za niepotwierdzony przelew w łańcuchu. Kanał otwarty bez potwierdzenia, zero-conf channel, świadomie ufa stronie finansującej i nie usuwa ryzyka podwójnego wydania tego finansowania. [13] [14]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Transakcja, Potwierdzenie, Mempool, Proof of Work, Replace-by-Fee (RBF), Bitcoin. Do tego hasła prowadzą również odsyłacze z Potwierdzenie, Reorg, Stale Block, Replace-by-Fee (RBF).