RBF - nowy kontrowersyjny protokół od developera Bitcoin Core - Bitcoin.pl - Bitcoin, kryptowaluty i technologia blockchain

Dyskusja na tak ważny temat jak zwiększenie rozmiarów bloków wciąż trwa, jednak developerzy skupiają się również na innych problemach.... a można nawet rzec, że tworzą nowe. Ostatnia propozycja developera Bitcoin Core - Petera Todda wywołała w społeczności bitcoinowej nową "burzę". Dyskusja na tak ważny temat jak zwiększenie rozmiarów bloków wciąż trwa, jednak developerzy skupiają się również na innych problemach.... a można nawet rzec, że tworzą nowe. Ostatnia propozycja developera Bitcoin Core - Petera Todda wywołała w społeczności bitcoinowej nową "burzę". W drzewie developerskim Bitcoin Core pojawiły się zmiany (zostały dołączone do kodu), które radykalnie i potencjalnie niebezpiecznie zmieniają sposób gromadzenia transakcji w nowe bloki przez węzły kopalni. Obecnie domyślną logiką Core jest odrzucenie kolejnych transakcji wydających wyjścia użyte w którejkolwiek z transakcji jaką dany węzeł posiada w pamięci (reguła „first seen” - pierwsza zobaczona/otrzymana). Dzięki temu, utrudnione jest wysłanie drugiej transakcji wydającej te same wyjścia (podwójne wydanie - „double spend”), ponieważ transakcja taka zostaje odrzucona przez wszystkie węzły do których dotarła już pierwsza transakcja. Regułę tą łamie już BitcoinXT który przechowuje i przekazuje dalej obie transakcje, usuwając z pamięci zdublowane dopiero po zatwierdzeniu w bloku jednej z dublujących wejścia transakcji. Zmiany wprowadzane przez Petera Todda pod nazwą RBF („Replace By Fee” - zamiana przez opłatę) całkowicie zmieniają tą logikę. Wdrażany sposób oblicza, która z transakcji jest bardziej „opłacalna” - ma lepszy stosunek wielkość/opłata lub opłata całkowita. Transakcja bardziej opłacalna zostaje w pamięci a mniej opłacalna jest odrzucana. Rozwiązanie takie otwiera drogę oszustom, którzy mogą praktycznie bezproblemowo oszukiwać serwisy/punkty akceptujące zapłatę w BTC bez potwierdzeń. Przy działającym RBF atakujący musi tylko (po zaakceptowaniu zapłaty przez serwis) wysłać kolejną transakcję wydającą te same wyjścia ale skierowaną z powrotem na jego adres zwiększając opłatę transakcyjną np. dwukrotnie. Zgodnie z nową logiką druga transakcja zastępuje pierwszą ze względu na znacznie większą opłacalność i sprzedający zostaje z niczym. Równolegle z RBF wprowadzane są zmiany, które zwiększają priorytet transakcji z niską (nawet zerową) opłatą gdy wydawana jest ona w kolejnej transakcji, która już zawiera „normalną” lub powiększoną opłatę. Miałoby to pomóc przeciwdziałać powyższemu atakowi, jeżeli punkt akceptujący BTC natychmiast wyda otrzymaną zapłatę, płacąc jednocześnie opłatę za „poprzednią” transakcję. Niestety, złośliwy atakujący może wysyłać kolejne „swoje” transakcje z jeszcze większą opłatą, lub tworząc łańcuch kolejnych transakcji aby uzyskać większy priorytet, doprowadzając do karuzeli/wyścigu z serwisem czyja transakcja będzie bardziej opłacalna dla górników, aż do absurdu wydającego całość transakcji jako opłatę transakcyjną. Tak czy inaczej, punkt akceptujący BTC zostałby z niczym lub jego przychód byłby w pewnym (nawet znacznym) stopniu zmniejszony. Pierwsze wzmianki o tej propozycji pojawiały się już w 2013 roku, ale nie były one wdrażane poza testnetem (siecią testową Bitcoin). Nie pojawiło się żadne opracowanie wyników przez developerów testujących te zmiany, a pojawienie się zmian w głównym drzewie kodu Core wywołało burzę protestów w środowisku. Z założenia RBF miał pomóc użytkownikom, którzy chcieli „przyspieszyć” swoją transakcję (zwiększenie opłaty zwiększa priorytet transakcji, a domyślnie transakcje są przyjmowane zgodnie z kolejnością priorytetu), lub też ją „cofnąć” zanim zostanie ona zatwierdzona w bloku. Nie ma jednak żadnego zabezpieczenia przez użyciem tego sposobu jako ataku na punkt/serwis akceptujący BTC bez zatwierdzeń. Można sobie np. wyobrazić sytuację, w której jeden serwis wykańcza konkurencję przez wielokrotne zamawianie towarów/usług i „cofanie” zapłat. Na szczęście, zmiany które są obecnie wdrożone nie spowodują jeszcze tragedii. Nie są one jeszcze włączone do oficjalnej kompilacji Core (planowane od wersji 0.12). Miejmy nadzieję, że wprowadzony zostanie mechanizm który umożliwi funkcjonowanie serwisów akceptujących zapłaty bez potwierdzeń lub zmiany w kodzie związane z RBF zostaną po prostu cofnięte lub zmodyfikowane. W innym przypadku idea błyskawicznych płatności z użyciem BTC online czy sklepach/kawiarniach stanie pod znakiem zapytania. Wiemy jednak, że niektóre kopalnie nie używają bezpośrednio oryginalnej logiki Core przy tworzeniu bloków, a właśnie „wybierają” transakcje bardziej opłacalne. Tak więc pomimo że zmiany RBF nie są wdrożone, pomysł w pewnym stopniu już działa w sieci Bitcoin. Warto też dodać, że samo RBF istnieje w trzech wersjach:

RBF
Opt-In RBF - Dodanie flagi do transakcji dzięki której odbiorca może wykryć próbę double spendu
First-Seen-Safe RBF - Bezpieczniejsza wersja RBF umożliwiająca podniesienie opłat za transakcję jeśli ta okazała się niewystarczająca (utknięcie transakcji).

Pozostałe wersję są już dużo bezpieczniejsze. Sama dyskusja na temat nowego protokołu pozostaje otwarta i nic nie zostało postanowione. Trzeba pochwalić też czujność samej społeczności bitcoinowej gdyż to głównie od niej zależy przyszłość jak i sama zasada funkcjonowania Bitcoina. Pamiętajmy, że na propozycję developerów, społeczność nie musi się godzić i może nie aktualizować portfeli do nowej wersji Bitcoin Core. Trzeba też brać pod uwagę, że początkowa koncepcja developerów ostatecznie może wyglądać i działać zupełnie inaczej, w sposób pożądany.

Indeks Strachu i Chciwości

RBF - nowy kontrowersyjny protokół od developera Bitcoin Core

O autorze

Newsletter Bitcoin.pl