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 100 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
Related
