Bitcoin Script to język warunków wydawania środków. Każde wyjście transakcji, czyli kwota z warunkami jej następnego użycia, zawiera te warunki. Kto chce je wydać, musi je spełnić. Script pomaga odpowiedzieć na proste pytanie: czy ta transakcja może wykorzystać właśnie te środki?
Alicja otrzymuje 20 000 sat, czyli dwadzieścia tysięcy najmniejszych jednostek bitcoina. Sieć nie otwiera konta na jej nazwisko. Powstaje wyjście transakcji: kwota i warunek jej późniejszego wydania. Dopóki wyjście nie zostanie wydane, nazywa się UTXO. Przy zwykłej płatności warunek wymaga podpisu odpowiednim kluczem. Kiedy Alicja później płaci, jej portfel wybiera to wyjście, wskazuje je nowym wejściem transakcji i tworzy podpis cyfrowy. Używa do tego klucza prywatnego, którego nigdzie nie wysyła; inni sprawdzają podpis kluczem publicznym. Znajomość adresu Alicji do odbioru płatności nie wystarczy. Warunki pierwotnego wyjścia zapisano w polu scriptPubKey, a Bitcoin Script określa sposób sprawdzania ich spełnienia. Węzeł nie jest urzędnikiem rozpoznającym Alicję, lecz komputerem sprawdzającym reguły. Oprócz podpisu musi sprawdzić na przykład, czy to samo wyjście nie zostało już wydane. Transakcja jest ważna dopiero po spełnieniu wszystkich właściwych reguł. [4] [2]
Przy zwykłych płatnościach warunki tworzy portfel. Wykonuj kopię zapasową zgodnie z jego instrukcją: normalne odtworzenie ze słów w zgodnym portfelu nie wymaga automatycznie ręcznego zapisywania każdego skryptu. W bardziej złożonej konfiguracji, takiej jak Multisig wymagający kilku podpisów, słowa jednego uczestnika mogą jednak nie opisywać całego sposobu wydawania środków. Do codziennego użytku lepiej wybrać portfel ze sprawdzonymi procedurami niż ręcznie składać skrypty w zapisie szesnastkowym. Deskryptory wyjść opisują typ skryptu, klucze i ich wyprowadzanie; pomagają więc ustalić, czego ma szukać odtworzony portfel. Sam klucz prywatny może nie wystarczyć do odtworzenia bardziej złożonej konfiguracji. Zachowaj także potrzebne skrypty i informacje o pochodzeniu kluczy, czyli skąd i jak je wyprowadzono, oraz sprawdź zamierzone ścieżki wydawania. [11]
Kolejne rozdziały pokazują zapis warunków wewnątrz transakcji; nie trzeba go znać, żeby płacić na co dzień. Pole scriptSig i część zwana witness dostarczają dane do weryfikacji. Hash jest odciskiem danych, a blokada czasowa uniemożliwia wydanie środków przed określoną granicą. Stos można wyobrazić sobie jako ułożone jeden na drugim elementy, którymi operuje się od góry. Script przetwarza dane za pomocą stosu: umieszcza na nim wartości, a instrukcje zwane kodami operacji zdejmują je, porównują lub przetwarzają w inny sposób. Instrukcje podpisu weryfikują podpisy; klucze prywatne i tworzenie podpisów nie są częścią tej weryfikacji. Język pozwala łączyć podpisy, warunki oparte na skrótach i blokady czasowe. Nie ma pętli ogólnego przeznaczenia i nie jest zupełny w sensie Turinga: nie da się w nim wyrazić wszystkich obliczeń możliwych w uniwersalnym języku programowania. Węzeł musi stosować dokładne reguły właściwe dla danego typu wyjścia i wersji skryptu. [1] [3]
Wyjście P2PKH (Pay to Public Key Hash) ma zwykle postać OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. Wejście dostarcza podpis i klucz publiczny w swoim scriptSig. Weryfikacja sprawdza, czy skrót klucza publicznego odpowiada wartości zapisanej w wyjściu, a następnie weryfikuje podpis. Sama znajomość adresu lub klucza publicznego nie wystarcza więc do takiego wydania środków. Klucza prywatnego używa portfel podpisujący, a nie węzeł sprawdzający transakcję. [1]
P2SH zgodnie z BIP16 zapisuje w wyjściu skrót skryptu. Wejście wydające to wyjście dostarcza odpowiadający mu redeemScript, czyli skrypt ujawniany przy wydawaniu, wraz z potrzebnymi danymi. Jego scriptSig może zawierać wyłącznie instrukcje umieszczające dane na stosie. Węzeł najpierw sprawdza zgodność skrótu, a następnie wykonuje redeemScript z pozostałymi elementami stosu. Sam poprawny skrót nie wystarcza do wydania środków: trzeba również spełnić warunki tego skryptu. [5]
W SegWit w wersji 0 dane do weryfikacji przeniesiono do części transakcji zwanej witness. Jest to lista elementów danych, a nie samodzielny skrypt. P2WPKH używa podpisu i klucza publicznego; P2WSH zawiera również witnessScript, którego skrót SHA256 musi odpowiadać wyjściu. W natywnym SegWit scriptSig jest pusty. Po opakowaniu w P2SH zawiera tylko instrukcję umieszczającą odpowiedni program witness na stosie; właściwe dane do weryfikacji pozostają w witness. [6]
Weryfikacja podpisu wykorzystuje wiadomość wyprowadzoną z transakcji według określonej procedury. Tryb SIGHASH określa, które jej części podpis chroni przed zmianą. Nie można więc automatycznie zakładać, że każdy podpis obejmuje całą transakcję. BIP143 dla operacji podpisu w SegWit w wersji 0 zawsze uwzględnia również kwotę wydawanego wyjścia. Portfel musi znać poprawne dane i wybrany tryb; Script podczas weryfikacji nie ocenia ludzkiego zamiaru podpisującego. [7]
Taproot zgodnie z BIP341 pozwala wydać wyjście P2TR (Pay to Taproot) na dwa sposoby. Ścieżka klucza weryfikuje podpis Schnorra względem klucza publicznego wyjścia bez ujawniania skryptu. Ścieżka skryptu ujawnia natomiast wybrany skrypt i blok kontrolny, określany jako control block, który dowodzi jego powiązania z wyjściem. Pozostałe skrypty w drzewie nie muszą być ujawniane. Reguły dla ujawnionego skryptu zależą także od wersji odpowiedniego liścia. [8]
BIP342 definiuje Tapscript dla liści Taproot w wersji 0xc0. Instrukcje podpisu używają tu podpisów Schnorra, a OP_CHECKSIGADD pozwala zbudować warunek wymagający wielu podpisów. Stare OP_CHECKMULTISIG jest zabronione przy wykonaniu. Nie obowiązuje wcześniejszy limit długości skryptu wynoszący 10 000 bajtów ani limit 201 kodów operacji liczonych według starszych reguł. Liczbę operacji podpisu ogranicza budżet wyprowadzony z rozmiaru witness; nadal istnieją limity stosu. Ograniczeń jednej wersji nie należy więc przedstawiać jako ogólnych właściwości całego języka Script. [9]
Reguły konsensusu określają ważność wydania środków w bloku. Standardowość oznacza dodatkowe lokalne reguły węzła dotyczące przyjmowania niepotwierdzonych transakcji do lokalnego zbioru Mempool i ich rozgłaszania; nie jest procesem standaryzacji. Transakcja ważna według konsensusu nie musi więc być powszechnie rozgłaszana. Szczególnej uwagi wymaga OP_SUCCESSx w Tapscript: po pomyślnym przejściu wcześniejszych kontroli jego rozpoznanie podczas dekodowania kończy weryfikację skryptu sukcesem, jeszcze przed zwykłym wykonaniem i kontrolami stosu. Jest to miejsce na przyszłe rozszerzenia, a nie zwykły bezpieczny warunek wydania środków. [10] [9]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Transakcja, Multisig, Timelock, Taproot. Do tego hasła prowadzą również odsyłacze z Hash, SHA-256, Reguły konsensusu, Timelock.