Aerofestival 2016

Protokół Bitcoina od środka: Budowa wiadomości „tx”

Wiadomość typu „tx” zawiera informacje na temat konkretnej transakcji w sieci Bitcoin. Z punktu widzenia złożoności, pakiet „tx” jest najbardziej skomplikowanym ze wszystkich używanych w protokole. Zapraszam do zapoznania się z jego budową 🙂

Czym jest wiadomość typu „tx”?

W jednym z poprzednich wpisów z cyklu o protokole Bitcoina opisywałem jak wygląda koncepcja transakcji. Wiadomość „tx” dokładnie odzwierciedla tę koncepcję w przełożeniu na konkretny zestaw danych. Pakiet z informacjami na temat danej transakcji przesyłany jest od węzła do węzła. I jest to ten sam pakiet w przypadku ogłaszania wykonania transakcji, jak i w przypadku propagowania jej dalej w sieci. Do wykonania konkretnej transakcji wystarczy jedynie połączyć się z siecią, a następnie zbudować odpowiedni zestaw bajtów reprezentujących transakcję, aby dalej rozesłać go do dowolnego węzła. Cała reszta magicznie zadzieje się sama i jeżeli transakcja została poprawnie zbudowana, sieć rozpropaguje ją dalej i wkrótce możemy doczekać się jej potwierdzenia przez którąś z kopalń. W następnych wpisach z cyklu o protokole koncepcję wprowadzimy w życie, a tabelkę opakujemy w konkretny kod 🙂

A jak jest zbudowana?

W poniższych tabelach opisałem dokładnie każde pole, które napotkamy przy implementacji wiadomości „tx”. Jeżeli któryś z komentarzy niewystarczająco wyjaśnia ideę konkretnego pola – śmiało pytaj w komentarzu do wpisu!

Numer pola 1
Nazwa pola version
Liczba bajtów 4
Wersja protokołu wiadomości „tx”. W chwili obecnej jest to ciąg bajtów o wartości 1. Pole to zostało wprowadzone na wypadek, gdyby ustalono w przyszłości nową budowę pakietu – wtedy klient Bitcoina potrafiłby rozróżnić sposób w jaki ma zinterpretować przychodzącą wiadomość o płatności

Numer pola 2
Nazwa pola tx_in count
Liczba bajtów 1-9
Wartość określająca liczbę kont, z których wychodzą środki, aby wykonać bieżącą transakcję

Numer pola 3
Nazwa pola tx_in
Liczba bajtów różna
Struktura zawierająca informacje o kontach, z których środki są przekazywane w ramach bieżącej transakcji. Szczegółową budowę struktury „tx_in” przedstawiam w dalszej części wpisu

Numer pola 4
Nazwa pola tx_out count
Liczba bajtów 1-9
Wartość określająca liczbę kont, do których wychodzą środki, aby wykonać bieżącą transakcję

Numer pola 5
Nazwa pola tx_out
Liczba bajtów różna
Struktura zawierająca informacje o kontach, na które trafiają środki w ramach bieżącej transakcji. Tak jak w przypadku „tx_in”, opisowi tej struktury poświęcę osobną tabelę

Numer pola 6
Nazwa pola lock_time
Liczba bajtów 4
Wartość określająca, czy dana transakcja ma zostać potwierdzona w najbliższym możliwym czasie, dopiero po wskazanym, czy może po powstaniu konkretnego numeru bloku transakcji. Jeżeli wartość wynosi 0, wtedy transakcja nie jest zablokowana i może zostać potwierdzona w najbliższym możliwym momencie. Jeżeli wartość ta jest mniejsza od 500 000 000, to wyznacza numer bloku, przed którym transakcja nie może zostać potwierdzona, zaś jeżeli jest ona większa lub jej równa, oznacza konkretną datę w formacie UNIX, przed którą transakcja nie może znaleźć się w bloku. Umożliwia to zaplanowanie przelewu w przyszłości, a nawet ogłoszenie serii przelewów. Jak w klasycznym banku 🙂

Tak z grubsza wygląda budowa wiadomości reprezentującej transakcję w sieci Bitcoin. Zaczyna się prosto. Pozostaje nam tylko zanurkować w szczegóły struktur „tx_in” i „tx_out” – tutaj zaczyna się jazda bez trzymanki 😉

„tx_in”

Numer pola 1
Nazwa pola previous_output
Liczba bajtów 36
Struktura o nazwie „outpoint” zawierająca informacje na temat transakcji, z której pochodzą środki wydawane w bieżącej transakcji. Szczegółową budowę struktury „outpoint” opiszę w kolejnej tabeli

Numer pola 2
Nazwa pola script_length
Liczba bajtów 1-9
Wartość określająca długość skryptu autoryzującego transakcję

Numer pola 3
Nazwa pola signature_script
Liczba bajtów różna
Treść skryptu autoryzującego transakcję. Skrypt ten stanowi potwierdzenie własności konta, z którego środki są wyprowadzane w ramach bieżącej transakcji

Numer pola 4
Nazwa pola sequence
Liczba bajtów 4
W przypadku skonstruowania transakcji z ustawioną datą lub numerem bloku w polu „lock_time”, istnieje możliwość wprowadzenia do niej poprawek przed upłynięciem wskazanego terminu. W takim przypadku wartość pola „sequence” powinna być z każdą wersją zwiększana, licząc od zera. W obecnej wersji protokołu struktura ta nie jest używana i jest ustawiana domyślnie na wartość maksymalną, co oznacza, że transakcja została skonstruowana w ostatecznej wersji i nie będzie zmieniana w przyszłości

„outpoint”

Numer pola 1
Nazwa pola hash
Liczba bajtów 32
Hash transakcji opisywanej przez strukturę. Dla urozmaicenia – ciąg bajtów go reprezentujący zapisywany jest od tyłu

Numer pola 2
Nazwa pola index
Liczba bajtów 4
Każda transakcja może mieć kilka wejść i kilka wyjść. To pole określa dzięki któremu z kolei wyjściu odpowiada przelew środków, z których właśnie korzystamy

„tx_out”

Numer pola 1
Nazwa pola value
Liczba bajtów 8
Kwota przelewana na opisywane konto. Jest to liczba całkowita reprezentująca tzw. grosze w świecie Bitcoina nazywane „satoshi” od pseudonimu twórcy Bitcoina. Aby wyrazić taką kwotę w Bitcoinach (BTC), należy ją podzielić przez 10 milionów

Numer pola 2
Nazwa pola pk_script_length
Liczba bajtów różna
Długość poniższego skryptu

Numer pola 3
Nazwa pola pk_script
Liczba bajtów różna
Treść skryptu, który musi zostać uruchomiony w przypadku przyszłej chęci wydania środków z reprezentowanego przez tę strukturę konta. Co ciekawe, można skonstruować taki skrypt, który umożliwia wypłatę środków z adresu bez konieczności posiadania do niego klucza prywatnego. Zakładam, że takie środki długo by nie przetrwały 🙂

Co z „signature_script” i „pk_script”?

Pola o nazwach „signature_script” i „pk_script” zasługują na szczególną uwagę. Są to bowiem pola zawierające skrypty napisane w specjalnym języku, które uruchamiane w momencie potwierdzania transakcji. W dużym uproszczeniu – wynik uruchomienia tych skryptów wyznacza, czy osoba, która ogłasza w sieci daną transakcję ma do tego prawo. Skrypty zawarte w opisach kont wychodzących określają, jakie warunki musi spełnić kolejna transakcja, która używa środków z danego konta. Temat jest na tyle obszerny, że zasługuje na osobny wpis, dlatego pozwolę sobie opowiedzieć o nim przy następnej okazji. Do następnego!


Źródła, z których korzystałem przygotowując wpis:
1. https://bitcoin.org/en/developer-documentation
2. https://en.bitcoin.it/wiki/Protocol_documentation

Niniejszy post jest częścią cyklu „Protokół Bitcoina od środka”. Jeżeli zainteresowała Ciebie ta tematyka, zachęcam do zapoznania się również z pozostałymi wpisami:

  1. Zanim powiemy Hello World
  2. Budujemy nagłówek
  3. Łączymy się z siecią
  4. Generujemy adresy kont
  5. Koncepcja transakcji
  6. Jak zdobyć Bitcoiny?
  7. Budowa wiadomości „tx”
  8. Jak autoryzowane są transakcje?
  9. Ogłaszamy transakcję
  • Darek

    Z niecierpliwością czekam na odcinek o skryptach ponieważ nigdzie nie mogę znaleźć przykładowych obliczeń które wyjaśniłyby wszelkie niejasności. Pozdrawiam.

    • Wpis jest w trakcie przygotowywania i już niedługo pojawi się na blogu. Stay tuned!