Implementacja Bitcoin Unlimited – opozycja dla Bitcoin Core

W ostatnich dniach tematem numer jeden, znów jest maksymalna wielkość bloku Bitcoina. Po nieudanej inicjatywie implementacji Bitcoin Classic, tym razem przyszedł czas na Bitcoin Unlimited.

 

 

W ostatnich dniach tematem numer jeden, znów jest maksymalna wielkość bloku Bitcoina. Po nieudanej inicjatywie implementacji Bitcoin Classic, tym razem przyszedł czas na Bitcoin Unlimited.

 

Czym jest Bitcoin Unlimited?

 

BU powstało na fali zeszłorocznych dyskusji na temat konieczności powiększenia przepustowości sieci Bitcoin w najprostszy sposób: przez powiększenie maksymalnej wielkości bloku transakcji. Powstało kilka implementacji, ale na „placu boju” pozostał już tylko BU. Logika działania klienta BU kieruje go (identycznie jak robią to „zwykłe” węzły Core) na najdłuższy łańcuch bloków. Daje nam to informację, ile mocy sieci musieli by zdobyć popierający BU: ponad 51%. Generowanie większych bloków jest możliwe nawet teraz (przy 20%+ poparcia), ale ponieważ większość mocy sieci nie akceptuje większych bloków, klienci BU również przełączą się na „zwykły” łańcuch i praca włożona w zbudowanie większego bloku poszłaby na marne.

 

W przypadku klienta Core i załączenia SegWit sprawa wygląda zgoła inaczej. Włączenie funkcjonalności SegWit nastąpi dopiero po przekroczeniu 95% mocy sieci. Aż tak wysoki limit jest konieczny, ponieważ sposób wprowadzenia SegWit jako softfork powoduje, że transakcje w formacie segwit są przez „stare” klienty widziane jako monety „nie wymagające podpisu” czyli może je wydać każdy. Gdybyśmy już teraz chcieli używać SegWit, najprawdopodobnie nie moglibyśmy odzyskać wysłanych w tym formacie monet, bo zgodnie z obecnym konsensusem ktoś mógłby je po prostu przelać na swoje konto.

 

Kod BU dopuszcza możliwość ustawienia przez operatora węzła, jak duże bloki chce on budować, oraz jak duże bloki chce on akceptować. Dodatkowo, możliwe jest ustawienie po ilu kolejnych blokach zostanie zaakceptowany blok, który nie spełnia naszych wymagań/ustawień. Domyślnym ustawieniem budowania jest 1MB (zgodnie z Core), domyślnym limitem akceptowania jest 16MB a domyślną głębokością „zakopania” większego bloku, aby go zaakceptować jest 4.

 

W zależności od tego, czy węzły w kopalniach pozostawią te parametry na ustawieniach domyślnych czy nie oraz od mocy kopalni na różnych ustawieniach, po przekroczeniu 51% mocy i uruchomieniu kopania większych bloków może dojść do niespotykanych dotąd sytuacji. Węzeł kopalni zawsze podąża za najdłuższym łańcuchem, ale w przypadku posiadania „własnego” nowego bloku oraz otrzymaniu z innego węzła bloku o tej samej wysokości, zawsze buduje kolejny blok na bazie swojego, a nie obcego. Jeżeli więc węzeł (lub grupa węzłów z takimi samymi ustawieniami) otrzyma blok nie spełniający ustawień (będzie większy niż ustawienia danej kopalni), nie będzie go brać pod uwagę przy budowaniu kolejnych swoich bloków aż do czasu, gdy pojawią się zbudowane na nim kolejne bloki (domyślnie: 4). Rozwiązanie takie likwiduje praktycznie możliwość akceptacji płatności jako „pewnej” po mniej niż 4 blokach, bo może się okazać, że nasz transakcja jest szybko zatwierdzona w kopalni z ustawionym większym blokiem niż większość kopalni BU, i po kilku kolejnych blokach, gdy „nasz” blok zostanie osierocony, wróci do kolejki transakcji niezatwierdzonych, lub co gorsza, w międzyczasie do powstałego kilkublokowego forka zostanie zatwierdzona inna transakcja, wydająca monety które mieliśmy otrzymać na inny adres (atak podwójnego wydania).

 

Kod BU nie zakłada żadnej komunikacji pomiędzy węzłami, która pomogłaby w „optymalnym” ustawieniu tych parametrów. Z jednej strony kopalnia chcąc przyjąć więcej transakcji naraz, aby zarobić więcej z opłat, poprawia szybkość sieci, ale jednocześnie z drugiej strony ryzykuje, że jej bloki zostaną odrzucone. Może dojść do sytuacji, gdzie kopalnie BU mając duża przewagę i tak będą generować bloki o wielkości 1MB, aby nie narażać się na straty.

 

W przypadku załączenia SegWit przy 95%, niebezpieczeństwa utraty środków nie będzie, ponieważ jeżeli aż taka moc poprze nowe rozwiązanie, ewentualne transakcje „kradnące” środki z SegWit będą po prostu odrzucane przez węzły kopalni. A nawet jeżeli któraś z 5% kopalni będzie akceptować takie transakcje, to wystarczy wziąć pod uwagę, że kopalnie takie będą mogły wygenerować 1 blok co około 3,5 godziny, a kolejna zmiana trudności która przyspieszy bloki tak powstałego forka nadejdzie dopiero po 220 dniach i zwiększy szybkość do 1 bloku na 50 minut. Raczej żadna kopalnia nie przyciągnie do siebie górników taką perspektywą, i po „załączeniu” SegWit niezgodne szybko będą aktualizować swoje węzły do nowego obowiązującego standardu.

 

 

Najgorszy możliwy scenariusz: hardfork sieci przy około 50% po obu stronach. Co będzie się działo?

 

Grupa giełd, między innymi: Bitfinex, Bitstamp, BTCC, Bitso, Bitsquare, Bitonic, Bitbank, Coinfloor, Coincheck, itBit, QuadrigaCX, Bitt, Bittrex, Kraken, Ripio, ShapeShift, The Rock Trading i Zaif już zapowiedziały, że w takiej sytuacji łańcuch BU będzie traktowany jako „altcoin” (alternatywna kryptowaluta) a łańcuch Core jako obowiązujący Bitcoin. Pamiętając bowiem zamieszanie, jakie powstało przy hardforku ETH/ETC giełdy chcą być przygotowane na taką ewentualność w BTC. Po powstaniu równoległych łańcuchów, wszystkie monety jakie mamy przed forkiem istnieją w nich obu. Wysyłając monety w jednej sieci, nasza transakcja jest poprawna również w drugiej. Może to być powodem wielu nieprzyjemności, gdzie chcąc zapłacić „bitcoinem unlimited” jednocześnie płacimy „zwykłym bitcoinem”. Dopiero zmieszanie naszych monet z monetami wydobytymi po forku w danym łańcuchu daje pewność, że wysyłamy transakcję poprawną tylko w konkretnym forku.

 

Zagadką pozostaje, dlaczego deweloperzy BU, mając nieco ponad 30% poparcia mocy, nie przyjmą rozwiązania SegWit z Core. Obecny wynik „głosowania blokami” pokazuje bowiem, że około 35% mocy obliczeniowej nie opowiada się po żadnej z tych stron.

 

Być może potrzeba kompromisu łączącego dobrodziejstwa jakie niesie SegWit oraz proste zwiększenie wielkości bloku. Tu pojawił się pomysł jeszcze jednej implementacji BitcoinEC, który jest praktycznie klonem Core z minimalną ilością poprawek zwiększającą rozmiar bloku. Ta implementacja wydaje się najbardziej rozsądna i zdobywa już zwolenników BU. natomiast idealnym rozwiązaniem byłoby wprowadzenie SegWit razem z adaptacyjną zmianą wielkości bloków zaproponowaną przez BitPay.

 

Co całe zamieszanie oznacza dla użytkowników Bitcoina?

 

Strach przed Hard Forkiem odbija się w kursie oraz ucieczką do innych alternatywnych kryptowalut i jest to zjawisko czysto psychologiczne, ryzyko samozwańczego HF jest minimalne. Po pierwsze kopalniom popierającym BU, bardzo ciężko byłoby uzyskać odpowiednią moc. Po drugie, dla kopalni, które poparłyby BU poprzez bunt przy małej mocy (niewiele większej niż 50%), byłoby to zupełnie nieopłacalne ekonomicznie, gdyż takie posunięcie wprowadziłoby zamęt oraz spowodowało prawdopodobnie duży spadek kursu a co za tym idzie możliwe bankructwo. Na zakończenie warto dodać również, że kod Unlimited wydaje się być niestabilny oraz jak się okazało zawierał błędy krytyczne.

 

Działania BU mają więc charakter bardziej edukacyjno-psychologiczny, wywierają słuszną zresztą presję na Bitcoin Core do zmiany polityki nad wielkością bloku.

 

Zdjęcie: Flickr.com