SegWit w fazie "lock in"

SegWit dla Bitcoina wszedł w fazę „lock-in”. Oznacza to, że wprowadzenie tego usprawnienia nie jest już kwestią decyzji a czasu. Stanie się to za około 2 tygodne.

SegWit dla Bitcoina wszedł w fazę „lock-in”. Oznacza to, że wprowadzenie tego usprawnienia nie jest już kwestią decyzji a czasu. Stanie się to za około 2 tygodne.

Segregated witness (oddzielone podpisy) to propozycja developerów Bitcoin Core, która ma między innymi rozwiązać problem przepustowości sieci. Dodatkowo SegWit wprowadza szereg zmian, zwiększających funkcjonalność Bitcoina. Przypomnijmy:

1. Usunięcie problemu z modyfikacją podpisanej transakcji („transaction malleability”)

Obecny sposób zapisu i podpisywania transakcji umożliwia atakującemu drobne modyfikacje w transakcji, które nie wpływają na samą transakcję (nie zmieniają wejść ani wyjść), ale zmieniają identyfikator transakcji (hasz transakcji, txid).

Proponowany w segwit sposób oddzielenia podpisów transakcji od jej treści uniemożliwia takie modyfikacje, ponieważ txid liczone będzie tylko z zawartości transakcji a jej prawdziwość będą potwierdzać oddzielone podpisy. Ewentualne „zewnętrzne” zmiany w podpisach nie będą miały żadnego wpływu na samą transakcję ani jej hasz.

Kto na tym skorzysta?

autorzy portfeli śledzących transakcje – poszukiwanie transakcji po samym txid jest dużo prostsze niż analiza wejść/wyjść transakcji;
każdy kto wydaje niepotwierdzone wyjścia – jeżeli pierwsza z łańcucha kilku niepotwierdzony transakcji padnie ofiarą modyfikacji i zmodyfikowana transakcja zostanie zatwierdzona, to cały łańcuch kolejnych transakcji staje się nieprawidłowy;
sieć Lighting – dzięki naprawie problemów z modyfikacją podpisów sieć Lighting jest prostsza w implementacji i jej obsługa zajmie mniej miejsca w łańcuchu bloków. Będzie również można używać klientów SPV Lighting zamiast pełnych węzłów Core.
każdy kto używa łańcucha bloków – możliwy będzie szybki rozwój „smart contracts” takich jak kanały mikropłatności

UWAGA: 100% zabezpieczenie jest możliwe TYLKO, jeżeli wszystkie wejścia transakcji segwit są wyjściami transakcji segwit.

2. Liniowe skalowanie operacji haszowania podpisów (sighash)

Obecny sposób podpisywania wymaga coraz większej ilości operacji wraz ze zwiększeniem ich skomplikowania – i jest to wzrost logarytmiczny (np. transakcja 2x bardziej skomplikowana potrzebuje 4x więcej mocy obliczeniowej do jej weryfikacji). Na przykład „normalny” blok może być zweryfikowany w ciągu 25 sekund, a można stworzyć pojedynczą transakcję która na tym samym sprzęcie będzie wymagać 3 minut na zweryfikowanie.

Sposób zapisu podpisów w segwit likwiduje ten problem, bowiem każdy bajt transakcji musi być haszowany maksymalnie dwa razy, niezależnie od stopnia skomplikowana transakcji.

Kto na tym skorzysta?

Wszyscy użytkownicy sieci. Rozwiązanie to pozwala na bezpieczne zwiększanie wielkości bloku bez obawy, że czas potrzebny na weryfikację kolejnych (co raz większych) bloków nie będzie znacznie się zwiększał. Ma to znaczenie zwłaszcza w stosunku do powstających skomplikowanych transakcji croudfundingowych oraz rozbudowach transakcji mikropłatności.

3. Podpisywanie wartości wejścia transakcji

Gdy portfel sprzętowy podpisuje transakcję ma możliwość łatwego policzenia jaka ilość BTC jest wysyłana, ale bez analizy transakcji wejściowych nie ma możliwości stwierdzenia ile BTC jest wydawane i ile wynosi opłata transakcyjna. Bez analizy tych danych można by oszukać portfel co do ilości pobieranych monet.

Sposób zapisu segwit daje prostszy mechanizm, bo wejściem jest txid, numer wyjścia i wartość wejścia. Dzięki temu weryfikacja transakcji wejściowych nie jest konieczna.

Kto skorzysta?

Użytkownicy i twórcy portfeli sprzętowych. Dzięki temu uproszczeniu moc obliczeniowa wymagana do obsługi transakcji jest znacznie zredukowana, możliwe więc będzie również włączenie protokołu Bitcoin do aplikacji „internet of things” (internet rzeczy).

UWAGA: Zadziała to tylko jeżeli wysyłamy środki na adres typu segwit.

4. Zwiększenie bezpieczeństwa transakcji multisig P2SH (pay-to-scritpt-hash)

Obecne transakcje multisig haszowane są do 160-bitowego hasza (RIPEMD z SHA256). Jeżeli jeden z podpisujących chciałby przejąć wysłane środki musiałby znaleźć kolizję dla 80-bitowego hasza. Jest to obecnie możliwe przy dostępie do wielkich mocy obliczeniowych (obecna moc sieci Bitcoin 1exahasz/s wykonuje podobną pracę jaka jest potrzebna do znalezienia kolizji w ciągu 2 tygodni).

Segwit podpisuje 160-bitowym haszem tylko „zwykłe” transakcje, transakcje multisig podpisywane są haszem 256-bitowym (SHA256).

Kto skorzysta?

Wszyscy użytkownicy transakcji multisig.

5. Wersje języka skryptowego

Obecnie jakakolwiek zmiana w języku skryptowym transakcji wymaga utrzymania wstecznej kompatybilności. Zmiana działania istniejących komend wymaga znacznego skomplikowania budowanych skryptów, a dołożenie jakichkolwiek nowych komend (np. wykonujących łączenie ciągów znaków) wymaga hardforka.

Segwit rozwiązuje ten problem przez możliwość zapisu wersji języka skryptowego użytego w transakcji i bezbolesne wprowadzanie nowych funkcjonalności przez softfork.

Kto skorzysta?

Łatwiejsze modyfikowanie języka skryptowego da większe pole do popisu dla zaawansowanego programowania działania transakcji. Wprowadzenie podpisów Schnorra, odzyskiwanie klucza publicznego (w celu nieumniejszenia transakcji), włączanie łańcuchów bocznych czy „smart constracts” na bazie drzewa składniowego (MAST – Merklized Abstract Syntax Trees) będzie możliwe bez większych komplikacji.

6. Zmniejszenie przyrostu bazy niewydanych wyjść (UTXO)

Baza UTXO jest budowana i weryfikowana przy ładowaniu łańcucha bloków. Zawiera ona wszystkie transakcje które mają niewydane wyjścia oraz oznaczenia „wolnych” wyjść. W idealnym przypadku powinna być ona dostępna w RAM w celu szybkiej weryfikacji poprawności nowych transakcji i bloków. Wraz z wzrostem ilości transakcji rośnie również ilość transakcji z niewydanymi wyjściami i baza UTXO rośnie co raz bardziej.

Segwit pozwala nie zapisywać podpisów do bazy UTXO, co może zmniejszyć przyrost bazy aż o 75%.

Kto skorzysta?

Każdy kto używa pełnego węzła Core – zasoby potrzebne do jego działania nie będą rosły tak szybko jak dzieje się to dotychczas.

7. Kompaktowe potwierdzenia transakcji (“Compact fraud proofs”)

Wraz ze wzrostem sieci Bitcoin weryfikacja całego łańcucha bloków staje się co raz bardziej kosztowne (w kwestii potrzebnych zasobów). Aby utrzymać zdecentralizowaną naturę Bitcoin musimy umożliwić wszystkim weryfikację takiej części łańcucha, jaką mają możliwość wykonać.

Segwit wprowadza mechanizmy, pozwalające nawet „lekkim” klientom SPV na weryfikowanie i przekazywanie transakcji pomiędzy węzłami oraz innymi klientami SPV w celu utrzymania konsensusu sieci.

Kto skorzysta?

Dzięki umożliwieniu weryfikacji przez klientów SPV cała sieć staje się bezpieczniejsza, bo więcej maszyn weryfikuje poprawność transakcji.

8. Zwiększona efektywność przez brak weryfikacji podpisów.

Wszystkie obecne transakcje zawierają podpisy, pomimo że większość klientów SPV ich nie weryfikuje (wierząc że zrobiły to węzły Core i górnicy). Tak więc, każdy klient musi pobrać całą transakcję w celu weryfikacji jej identyfikatora (txid) nawet, jeżeli jej całej „nie potrzebuje”.

Segwit oddziela transakcję od podpisów i „lekkie” portfele nie będą musiały przesyłać niepotrzebnych im transakcji w celu weryfikacji txid.

Kto skorzysta?

Wszyscy użytkownicy lekkich portfeli ze względu na mniejsze zapotrzebowanie na przesyłane dane i miejsce potrzebne do składowania transakcji. Również węzły podające dane do klientów SPV będą mogły wysyłać mniej danych.

9. Otrzymanie jednolitego limitu wielkości bloku

Obecnie obowiązują dwa niezależne limity wielkości bloku: wielkość zawartych transakcji nie może przekroczyć 1MB oraz ilość podpisów wymagających weryfikacji w bloku nie może być większa niż 20`000. Znalezienie najbardziej dochodowych transakcji do dołączenia do bloku może więc być trudne, ze względu na różny sposób budowy transakcji, i czasem proste przeliczenie wielkości do opłaty nie jest najlepsze. Może to być wykorzystane do ataku przez produkowanie małych transakcji z dużą ilością podpisów i zablokowanie sporej części miejsca w bloku.

Nawet wprowadzenie segwit nie rozwiąże tego problemu, bo zmiana konsensusu wymaga hardforka. Wprowadzenie segwit może ten problem pogłębić, bo podpisy nie są liczone do wielkości transakcji i można budować jeszcze większe „złe” transakcje mniejszym kosztem.

Kto skorzysta?

Ostatecznie górnicy zyskają przy hardforku, gdzie konieczna będzie zmiana pojemności bloku do jednego równania, na przykład:

50*sigops + 4*basedata + 1*witnessdata < 10M

Dzięki temu górnicy będą mogli łatwiej wybierać transakcje jakie „powinny” znaleźć się w najbliższym bloku.

Po wprowadzeniu SegWit zgodnie z zawartym konsensusem, w ciągu 6 miesięcy planowane jest wprowadzenie hard forka zwiększającego wielkość bloku do 2MB. Pomysł ten jednak nie podoba się deweloperom Core (nic nowego) i jak można się domyślać, będzie on sabotowany.

SegWit w fazie “lock in”

Newsletter Bitcoin.pl