Bitcoin Whitepaper

Whitepaper przedstawia problem i proponuje rozwiązanie. Ten bitcoinowy zaczyna od codziennego pytania: czy gdy wysyłam pieniądze przez Internet, zawsze musi między nami stać bank albo inny zarządca? Satoshi wysłał propozycję na kryptograficzną listę dyskusyjną 31 października 2008 roku i podał odnośnik do tekstu. Nie obiecywał ceny bitcoina ani zysku inwestora. Wyjaśniał, jak przyjmować płatności bez powierzania jednej firmie decyzji o ich historii. Ten problem spaja cały dokument. [2] [1]

Wyobraź sobie nadawcę podpisującego dwie różne płatności wydające te same pieniądze. Jeden odbiorca widzi pierwszą, drugi drugą. Obaj mogą sprawdzić prawidłowy podpis cyfrowy, czyli dowód uprawnienia do płatności, ale obaj nie mogą dostać zapłaty. Kopiowanie danych w Internecie jest łatwe; sam podpis tego problemu nie usuwa. Rozdział 2 oddziela więc uprawnienie do wydania środków od pytania, która płatność znajdzie się we wspólnej historii. Bitcoin dodaje do podpisów publiczny zapis pozwalający rozpoznać już wydane środki. [1]

Rozdziały 3–5 opisują łączenie płatności w bloki. Każdy kolejny blok odsyła do poprzedniego przez hash, krótki cyfrowy odcisk danych. Zmiana starszego zapisu zmieniłaby odcisk i zerwała powiązania. Proof of Work dodaje kosztowną pracę obliczeniową: znalezienie dopuszczalnego bloku wymaga wielu prób, a sprawdzenie wyniku jest łatwe. W sporze gałęzi liczy się więc skumulowana praca w historii zgodnej z regułami, nie liczba utworzonych kont lub adresów IP. Dokument nazywa ją najdłuższym łańcuchem. Nawet ogrom pracy nie uczyni nieprawidłowej transakcji prawidłową. Łańcuch wyznacza też kolejność zdarzeń, nie dokładny czas każdej płatności. [1] [3]

Komputery i prąd kosztują. Rozdział 6 dodaje więc zachętę ekonomiczną: twórca przyjętego bloku może otrzymać nowo wyemitowane monety oraz opłaty z jego płatności. Opłata to różnica między wartością zużywaną przez transakcję a wartością nowych wyjść. Nie są to dodatkowe monety powstające z niczego. Tekst rozważa przyszłość, w której wynagrodzenie pochodzi wyłącznie z opłat. Trzeba jednak wiedzieć, gdzie kończy się propozycja: whitepaper nie podaje dokładnego limitu 21 milionów ani zmniejszania emisji o połowę co 210 000 bloków. Te reguły wymagają innych źródeł o Bitcoinie. [1] [3]

Nie każdy chce pobierać i sprawdzać wszystkie transakcje. Rozdział 8 proponuje więc SPV, uproszczoną weryfikację płatności. Klient uzyskuje nagłówki z podstawowymi danymi bloków oraz dowód Merkle’a: połączenie hashów potwierdzające umieszczenie transakcji w bloku. To różnica między sprawdzeniem, czy wpis jest w konkretnej księdze, a kontrolą poprawności całej księgi. Samo umieszczenie nie potwierdza wszystkich reguł ani całej historii wydawania. Whitepaper nie ukrywa tego ograniczenia: uproszczony klient jest bardziej podatny na pewne ataki niż Full Node samodzielnie sprawdzający transakcje. [1]

W bankowości duża część zapisów płatności nie jest publiczna. Bitcoin potrzebuje wspólnej historii, więc musi chronić prywatność inaczej. Rozdział 10 wyjaśnia oddzielenie płatności od tożsamości posiadaczy kluczy i zaleca nowe pary kluczy dla kolejnych transakcji. Przyznaje też słabość: płatności można łączyć. Przypisanie człowieka do jednego zapisu może ujawnić kolejne płatności. Nowy adres nie jest więc magicznym przebraniem. Ogranicza niektóre powiązania, ale sam nie usuwa informacji publicznych ani wiedzy drugiej strony. [1]

Rozdział 11 pyta o szanse napastnika na dogonienie łańcucha tworzonego przez uczciwych uczestników. Wyobraź sobie wyścig: jedna strona ma przewagę, ale obie dalej pracują. Im mniejszy udział napastnika w mocy obliczeniowej i większa przewaga, tym niższa szansa dogonienia w opisanym modelu. Obliczenie korzysta z założeń i przybliżenia Poissona, matematycznego uproszczenia szacującego liczbę zdarzeń w danym okresie. Nie przewiduje każdego rzeczywistego ataku. Jednej liczby z tabeli nie można więc uznać za bezpieczną liczbę potwierdzeń dla dowolnej płatności. [1]

Dokument wyjaśnia pierwotny projekt. Sieć i oprogramowanie się rozwijały; nie ma w nim choćby SegWit, zmiany opisanej we wniosku BIP 141. BIP jest dokumentem proponującym ulepszenie, nie decyzją automatycznie stającą się regułą sieci po publikacji. Przy dzisiejszych pytaniach trzeba odróżniać propozycję, program, faktycznie stosowane wspólne reguły i lokalne decyzje węzła o przekazywaniu transakcji. Węzeł może nie przekazać transakcji, a później przyjąć ją w prawidłowym bloku. Te sytuacje nie są sprzeczne. [4] [3]

Zacznij od streszczenia i pytania, jak zapobiec podwójnemu wydaniu bez zarządcy. Potem śledź wkład podpisów, wspólnej historii i pracy potrzebnej do tworzenia bloków. Jeśli zatrzyma cię matematyka, nie musisz od razu rozumieć każdego wzoru: najpierw ustal, jaki atak modelują obliczenia i jakie robią założenia. Do szczegółów możesz wrócić później. Pierwotny e-mail dokumentuje moment przedstawienia propozycji; PDF zawiera argumentację. Zdanie wyrwane z tego kontekstu nie dowodzi, że konkretny portfel lub usługa musi być bezpieczna. [2] [1]

Najważniejsze nie są tytuły rozdziałów, lecz zrozumienie, dlaczego żadna część nie wystarcza sama: podpis potwierdza uprawnienie, publiczna historia pomaga wykryć podwójne wydanie, a Proof of Work utrudnia przepisanie kolejności. Części miały poprzedników, których Satoshi cytuje w źródłach. Wkładem jest sposób połączenia. Whitepaper pozostaje dobrym wprowadzeniem do myślenia o Bitcoinie, jeśli czytamy go jako przemyślaną propozycję z konkretnymi założeniami. Nie jest cennikiem, poradnikiem inwestycyjnym ani pełną specyfikacją wszystkich reguł i narzędzi noszących dziś nazwę Bitcoin. [1]