38 / 6912X

Podwójne wydanie

Próba podwójnego wydania wykorzystuje dwie lub więcej sprzecznych transakcji Bitcoin, które wydają co najmniej jedną z tego samego UTXO na wzajemnie niezgodne historie. Węzły nie odczytują żadnego salda dwukrotnie: sprawdzają dane wejściowe pod kątem swojego UTXO, a widok puli pamięci i dowód pracy decydują, która ważna historia przetrwa.

Konflikt można zaobserwować jeszcze przed rozliczeniem, jednak do udanego podwójnego wydania dochodzi dopiero wtedy, gdy ofiara wyda wartość na jedną transakcję, a druga wygrywa w otrzymanym łańcuchu. Dlatego wymieniona płatność z portfela, niezamierzona podwyżka opłaty lub nieudany konflikt nie są automatycznie oszustwem. Wyścig o zerowej konfiguracji i nadpisywanie zatwierdzonych bloków mają zasadniczo różne koszty i ryzyko.

Każde wejście odnosi się do poprzedniego wyjścia za pomocą txid i indeksu. Dwie transakcje są w konflikcie, gdy co najmniej jedno wejście odnosi się do tego samego niewydanego punktu końcowego, ale nie mogą one zapłacić w tym samym czasie. Podczas walidacji bloku węzeł sprawdza, czy dane wejściowe istnieją i nie zostały wykorzystane wcześniej w danej historii lub w innym miejscu tego samego bloku. Tylko jedna gałąź przetrwa w prawidłowym zestawie UTXO; atak nie tworzy kopii satoshi, próbuje zmusić odbiorcę do działania zgodnie z gałęzią, która przegrywa. [Opracowanie dotyczące Bitcoina – Transakcje, serwer znaczników czasu i obliczenia] [Przewodnik programisty Bitcoin – Transakcje] [Bitcoin Core – validation.cpp]

Nie ma globalnej puli pamięci ani kolejności konsensusu w zakresie niezatwierdzonych transakcji przed wydobyciem. Uczestnicy mogą najpierw zobaczyć różne konflikty związane z promocją, topologią, polityką opłat, statusem pakietu lub izolacją Eclipse. Po raz pierwszy widać politykę przekaźnikową, a nie obowiązek górników potwierdzania pierwszej opcji. Txid na zapleczu sprzedawcy potwierdza jedynie, że przybył jeden podpisany kandydat, a nie, że widziała go cała sieć lub wygrała blok. [Przewodnik programisty Bitcoin – Przetwarzanie płatności] [Rdzeń Bitcoin – Zamienniki Mempool]

Zamień na opłatę umożliwia węzłowi zastąpienie konfliktów puli pamięci, które spełniają zasady dotyczące opłat i ochrony przed DoS; full-RBF jest domyślną polityką w Bitcoin Core od wersji 28. Nadawca może zgodnie z prawem zwiększyć opłatę za zablokowaną płatność i zachować dane wyjściowe odbiorcy lub przekierować wartość. W obu przypadkach konsensus widzi wspólnych kandydatów i akceptuje wariant z ważnej historii wydobycia. Sam sygnał RBF, wymiana lub podbicie nie dowodzą oszustwa; transakcja bez sygnału ponownie nie jest bezpieczna dla konfiguracji zerowej. [Bitcoin Core – Zamienniki Mempool] [BIP 125 – Pełna wymiana poprzez opłatę za zgodę]

W przypadku ataku rasistowskiego płatnik wysyła jedną transakcję do kupca, a konflikt do górników lub innych partnerów, tak że kupiec wydaje towary bezzwrotne, zanim blok wybierze jedną opcję. Wynik zależy od promocji, widoku sieci sprzedawcy, wyboru górników i czasu transferu. Bardziej niezależni słuchacze poprawią wykrywanie, ale nie stworzą deterministycznej ostateczności. Nazwy race, Finney i Vector76 to modele scenariuszy, a nie tablice transakcji lub różne reguły konsensusu. [Przewodnik programisty Bitcoin – Przetwarzanie płatności] [Karam i in. — Niewłaściwe zachowanie w Bitcoinie]

Atakujący w stylu Finneya z możliwością wydobywania najpierw prywatnie znajduje blok zawierający konflikt, zwracając mu wartość, następnie płaci sprzedawcy zero-conf z tym samym UTXO i publikuje ukryty blok po otrzymaniu towaru. Plan zakończy się sukcesem tylko wtedy, gdy blok będzie nadal nadawał się do użytku i zostanie zaakceptowany przez sieć, zanim uczciwy blok rywala udaremni przygotowania; atakujący ryzykuje zarówno nagrodę za blok, jak i koszty wydobycia. Oczekiwanie na ujęcie transakcji handlowca w zweryfikowanym bloku kończy klasyczną sekwencję, ale nie eliminuje ryzyka późniejszej reorg. [Opracowanie dotyczące Bitcoina – Transakcje, serwer znaczników czasu i obliczenia] [Karame i in. — Niewłaściwe zachowanie w Bitcoinie]

Po potwierdzeniu konflikt nie może już po prostu wypchnąć płatności z puli pamięci: alternatywny ważny oddział musi pominąć płatność, uwzględnić drugi wydatek i zyskać więcej pracy łańcuchowej niż aktywny łańcuch odbiorcy. Reorganizacja może nastąpić nawet bez oszustwa w postaci niemal równoczesnych bloków lub incydentu związanego z oprogramowaniem lub siecią; udane podwójne wydanie przeciwko ofierze może jedynie zyskać na wartości poprzez wygranie konfliktu. Bitcoin Core może wyświetlać negatywne potwierdzenia i konflikty portfela w przypadku utraconej transakcji portfelowej. [Bitcoin Core – Walidacja] [Bitcoin Core – validation.cpp] [Bitcoin Core RPC – gettransaction]

Udział hashrateu atakującego, głębokość potwierdzenia i możliwa do uzyskania wartość determinują stochastyczny wyścig prywatnej i uczciwej pracy. Poniżej 50% nie oznacza to zerowej szansy; stała większość znacznie zwiększa możliwość nadrobienia zaległości, ale nie pozwala górnikom na fałszowanie podpisów, wydawanie zagranicznych UTXO, przekraczanie emisji lub zmuszanie pełnych węzłów do akceptowania nieprawidłowego bloku. Koszty obejmują moc obliczeniową, energię, utracone uczciwe nagrody, ryzyko straty, płynność i ekspozycję; do dochodu mogą należeć także pozycje rynkowe, dlatego sama cena wynajmu maszyn nie wystarczy. [Biała księga Bitcoina – Transakcje, serwer znaczników czasu i obliczenia] [Rosenfeld – Analiza podwójnych wydatków opartych na hashrate] [Garay, Kiayias i Leonardos – Protokół szkieletowy Bitcoin]

Każde dodatkowe zatwierdzenie zmusza alternatywną gałąź do ponownego wykonania większej części zaległości i, biorąc pod uwagę założenia, zmniejsza prawdopodobieństwo sukcesu. Nie ma uniwersalnego bezpiecznego numeru: kawa, samochód, depozyt giełdowy i bezzwrotna wypłata mają różną wartość, motywację i możliwość korekty. Często cytowane sześć afirmacji stanowi konwencję, a nie konsensus. Polityka powinna również monitorować dystrybucję hashrate, nietypowe reorganizacje, zaufanie do backendu, ryzyko zaćmienia i odwracalność przejęć. [Przewodnik programisty Bitcoin – Przetwarzanie płatności] [Rosenfeld – Analiza podwójnych wydatków opartych na hashrate]

Backend może monitorować sprzeczne wydatki mempool na swoim własnym pełnym węźle, wywoływać gettxspendingprevout, czytać konflikty portfela, porównywać aktywne wskazówki i ostrzegać o utracie potwierdzenia. Więcej równorzędnych węzłów lub niezależnych węzłów zmniejsza martwe punkty, ale brak wykrytego konfliktu jest słabym dowodem: osoba atakująca może go przechwycić lub wysłać w inne miejsce. Eksplorator wyświetla niestandardowy widok węzła i może być opóźniony. Wykrycie pozwala na zatrzymanie dozowania; nie może nakazać górnikom wygrania ani zamienić zerowej konfiguracji w potwierdzenie. [Bitcoin Core RPC — gettransaction] [Bitcoin Core RPC — gettxspendingprevout] [Karame i in. — Niewłaściwe zachowanie w Bitcoinie]

W przypadku rozliczenia onchain zatwierdź za pomocą własnego pełnego węzła, powiąż zamówienie z dokładnym identyfikatorem txid, wynikami i kwotą, ustaw głębokość zgodnie z możliwą stratą, w przypadku reorganizacji lub konfliktu, zatrzymaj realizację i oddziel zaksięgowane saldo od kwoty do wypłaty. Nie traktuj niepotwierdzonego potomka zmiany jako niezależnego od rodzica. Lightning inaczej obsługuje szybko powtarzające się płatności: potwierdzony punkt końcowy zakotwicza kanał, a reguły zaangażowania/odwołania kontrolują stan offchain; Kanał zeroconf świadomie ufa fundatorowi i nie eliminuje ryzyka podwójnych wydatków w finansowaniu. [BOLT 2 — Protokół Peer] [Bitcoin Optech — Kanały o zerowej konfiguracji]

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).

DOC · 001Bitcoin whitepaper — Transactions, Timestamp Server and CalculationsDokumentacja ↗DOC · 002Bitcoin Developer Guide — Payment ProcessingDokumentacja ↗DOC · 003Bitcoin Developer Guide — TransactionsDokumentacja ↗DOC · 004Bitcoin Core — ValidationDokumentacja ↗DOC · 005Bitcoin Core — Mempool ReplacementsDokumentacja ↗DOC · 006BIP 125 — Opt-in Full Replace-by-FeeSpecyfikacja ↗DOC · 007Bitcoin Core — validation.cppDokumentacja ↗DOC · 008Bitcoin Core RPC — gettransactionDokumentacja ↗DOC · 009Bitcoin Core RPC — gettxspendingprevoutDokumentacja ↗DOC · 010Rosenfeld — Analysis of Hashrate-Based Double SpendingDokumentacja ↗DOC · 011Karame et al. — Misbehavior in BitcoinDokumentacja ↗DOC · 012Garay, Kiayias and Leonardos — The Bitcoin Backbone ProtocolDokumentacja ↗DOC · 013BOLT 2 — Peer ProtocolSpecyfikacja ↗DOC · 014Bitcoin Optech — Zero-conf channelsDokumentacja ↗
Sprawdzono 1 sierpnia 2026Najpierw źródła · To nie jest porada inwestycyjna