SegWit w Bitcoin Core

Aktywacja SegWit

Już ponad 2 miesiące minęły od aktywacji Segregated Witness (SegWit) w łańcuchu Bitcoina, jak również hard-forka sieci (od bloku z numerem 478558), w wyniku którego powstała nowa kryptowaluta - Bitcoin Cash. Bitcoin Cash (BCH) jest kontynuacją pierwotnej wizji Satoshiego Nakamoto. Reguły sieci BCH odrzucają wsparcie SegWit, w zamian zwiększając rozmiar bloku do 8MB i pragnąc skalować sieć on-chain. Programiści Bitcoin Core, czyli referencyjnego klienta Bitcoin, nie wierzą w skalowalność sieci poprzez zwiększanie rozmiaru bloków. Z ich argumentacją ciężko się nie zgodzić. Bitcoin z 1MB rozmiarem bloków jest w stanie obłużyć ok. 3 transakcji na sekundę, podczas gdy VISA wg dostępnych danych obsługuje średnio 2000 transakcji na sekundę, a w testach wydajnościowych udało się osiągnąć wydajność ponad 50 000 transakcji/s. Nietrudno policzyć, że gdyby Bitcoin miał zastąpić w tej chwili VISĘ, każdy blok musiałby mieć rozmiar ponad 600MB. Bloki pojawiają się średnio co ok. 10 minut. Jest to ogromna liczba danych, które muszą zostać przesłane poprzez sieć Internet i być przechowywane na twardym dysku.

Programiści Bitcoin Core postanowili pójść inną drogą. Pragną część transakcji przesyłać "poza" głównym łańcuchem bloków, opierając się na koncepcjach "łańcuchów bocznych", "Lightning Network", "kanałach płatności", etc. Jednak aby móc zacząć korzystać z tychże rozwiązań, w pierwszej kolejności wymagana była właśnie aktywacja SegWit.

Co daje SegWit obecnie?

Co SegWit oferuje w tej chwili, zanim jeszcze zostaną wprowadzone rozwiązania typu "Lightning Network"? Przede wszystkim, niejako w efekcie ubocznym, został zwiększony realny rozmiar bloku*. Dzięki temu wzrosła liczba transakcji, które mogą zostać dołączone do blockchaina, zmniejszając tym samym kolejkę transferów oczekujących, a idąc dalej zmniejszają się prowizje, które należy zapłacić za przelew BTC. Ponadto prowizje zmniejszyły się jeszcze bardziej przy przelewach "segwitowych", jako że są one preferowane przez kopalnie. Poniższe zestawienie pokazuje, kiedy możemy wykorzystać SegWit, aby zapłacić niższą prowizję od transakcji:

Adres segwit -> Adres starego typu = obniżka prowizji :)

Adres segwit -> Adres segwit = obniżka prowizji :)

Adres starego typu -> Adres segwit = bez obniżki :(

Adres starego typu -> Adres starego typu = bez obniżki :(

SegWit w BitcoinCore

Wspomnieliśmy już, że programiści Bitcoin Core są zwolennikami SegWit i to przede wszystkim oni dążyli do wprowadzenia soft-forka aktywującego zmiany w strukturze bloku. A jak wygląda obsługa SegWit w portfelu Bitcoin Core? Niestety kiepsko. Widać, że skoncentrowano się przede wszystkim na zmianach dotyczących samego protokołu sieci i struktury bloków, praktycznie nie dając możliwości użycia SegWit z poziomu portfela. To bardzo dziwi.

23 sierpnia 2016, gdy wydano wersję 0.13.0 portfela Bitcoin Core, dodano komendę addwitnessaddress, która umożliwia utworzenie adresu typu SegWit na bazie istniejącego w portfelu klucza publicznego. Mechanizm użycia wygląda w ten sposób, że najpierw generujemy "standardowy" (tzw. legacy) adres BTC, a z niego adres SegWit. Jest to operacja deterministyczna, tzn. dla danego "standardowego" adresu wejściowego otrzymujemy zawsze ten sam adres SegWit.

Przykład

Zobaczmy jak wygląda wykorzystanie operacji addwitnessaddress w praktyce, na przykładzie konsolowej wersji aplikacji bitcoin-cli uruchomionej w lokalnej sieci testowej regtest. Dla potrzeb testu utworzono dwa nody Bitcoin Core, niech będą nosiły oznaczenia Alice i Bob.

Najpierw tworzymy adres typu legacy:

(alice)$ bitcoin-cli getnewaddress

w odpowiedzi otrzymujemy przykładowy adres mjvH4pEDPDNySTJjUYzoLFBBvoMoDdvwBA i tenże adres wykorzystujemy do utworzenia adresu SegWit:

(alice)$ bitcoin-cli addwitnessaddress mjvH4pEDPDNySTJjUYzoLFBBvoMoDdvwBA

Z konsoli jako odpowiedź otrzymujemy nasz adres typu SegWit: 2N1d99MesBTWPSkbHrR2qKkixMpLbxUX3b8

Niby pięknie, ale hola hola! Nie wszystko działa jednak tak, jak można by tego oczekiwać. Załóżmy, że ktoś przeleje nam bitcoiny na nasz SegWitowy adres. W typ przypadku Bob przesyła Alice 0,666 BTC, która już szaleje z radości, ponieważ myśli, że będzie mogła wysyłać bitcoiny z mniejszymi prowizjami, korzystając ze swojego segwitowego adresu...

(bob)$ bitcoin-cli sendtoaddress "2N1d99MesBTWPSkbHrR2qKkixMpLbxUX3b8" 0.666 

Alice sprawdza środki na koncie i faktycznie posiada 0,666 BTC na adresie typu SegWit:

(alice)$ bitcoin-cli listreceivedbyaddress 0 true                        

[

  {

    "address": "mjvH4pEDPDNySTJjUYzoLFBBvoMoDdvwBA",

    "account": "",

    "amount": 0.00000000,

    "confirmations": 0,

    "label": "",

    "txids": [

    ]

  }, 

  {

    "address": "2N1d99MesBTWPSkbHrR2qKkixMpLbxUX3b8",

    "account": "",

    "amount": 0.66600000,

    "confirmations": 0,

    "label": "",

    "txids": [

      "9bfa4f407a8bab892721c807a05d4c287fbcd15fc62469810a0fc64557e88495"

    ]

  }

]

Teraz Alice odsyła Bobowi 0,333 BTC:

(alice)$ bitcoin-cli sendtoaddress "mhDS7bxSFHYcp2EB43DcXoVWzhpZm3kDzi" 0.333

fe9802d1ab912effbfb6a0bc2991a6f1db19aaf7418b63c067c6060ebc60509c

I jeszcze raz sprawdza stan środków na swoim koncie, tym razem korzystając z komendy listaddressgrouping, która uwzględnia adresy reszt:

(alice)$ bitcoin-cli listaddressgroupings                                    

[

  [

    [

      "n1p5Brri1nSsMFapQgCxQXp1JksGY9v4PG", 

      0.33296600

    ], 

    [

      "2N1d99MesBTWPSkbHrR2qKkixMpLbxUX3b8", 

      0.00000000, 

      ""

    ]

  ]

]

I co się tutaj wydarzyło? Klient BTC (Bitcoin Core) Alice przesłał 0,333 BTC Bobowi z adresu SegWit (2N1d99MesBTWPSkbHrR2qKkixMpLbxUX3b8) i wygenerował "standardowy" (legacy) adres reszty (ang. change address) - n1p5Brri1nSsMFapQgCxQXp1JksGY9v4PG), na który została przesłana reszta środków. Efekt tego jest taki, że przy następnym przelewie Alice nie będzie już wykorzystywała adresu SegWit, tylko dobrze już znany adres legacy, tracąc wszystkie zalety technologii SegWit. Jak widać wykorzystanie SegWit jest jednorazowe. Można problem w pewien sposób obejść, tworząc każdą transakcję manualnie z wykorzystaniem komendy createrawtransaction, również manualnie tworząc za każdym razem adres legacy, a później z niego adres segwit i podając tak utworzony adres jako adres reszty, będący parametrem  wywołania funkcji createrwawtransaction... Dodatkowego "smaczku" dodaje opis aktualizacji najnowszej obecnie wersji Bitcoin Core, w którym napisano, że komenda addwitnessaddress służy wyłącznie do testów i  programiści nie dają gwarancji prawidłowego odtworzenia kluczy z backupu.Tak działa Bitcoin Core obecnie. Ale czy zwykły użytkownik ma ochotę na wykonywanie tego rodzaju zabiegów?

Niedaleka przyszłość

Najbliższa przyszłość klienta Bitcoin Core w zakresie wsparcia SegWit przedstawia się w ten sposób, że kolejna wersja klienta, tzn. 0.15.1, powinna zawierać wsparcie portfela dla generowania adresów/adresów reszt i backupów SegWit. Nad zmianami w kodzie pracuje Pieter Wuille, który wystawił tzw. pull request swoich modyfikacji kodu źródłowego.

Prawdopodobnie zostaną dodane dwie opcje konfiguracyjne: addressstyle, changestyle, dzięki którym będzie można wybrać typ generowanych adresów oraz adresów reszt. Ponadto komendy getnewaddress oraz getrawchangeaddress mają otrzymać nowy parametr style, za pomocą którego będzie można przedefiniować typ generowanego adresu. 

Więcej zmian można śledzić w samym Pull Requeście. Szkoda jednak, że programiści nie przygotowali w pełni portfela wraz z wprowadzeniem SegWit, lecz każą nam czekać już ponad 2 miesiące na wsparcie SegWit w Bitcoin Core. W końcu to przecież oni od samego początku pragnęli przeforsować SegWit w Bitcoinie...

* Poprzez wydzielenie podpisów transakcji do odrębnej struktury, która nie jest brana pod uwagę w obliczaniu rozmiarów bloku, liczba transakcji mogła zostać zwiększona prawie dwukrotnie, a w pewnych przypadkach nawet czterokrotnie. 

Related Items bitcoin bitcoin core featured segwit technikalia