Signet służy do wspólnych testów oprogramowania Bitcoin. Ma własny łańcuch i monety testowe. Oprócz zwykłych reguł i Proof of Work nowe bloki muszą spełniać szczególny warunek sieci, oparty na podpisie w domyślnym Signet. Ułatwia to testy, ale oznacza inny model zaufania niż w sieci głównej.
Anna chce zobaczyć, co nowy portfel wyświetli po wysłaniu płatności i po jej potwierdzeniu w bloku. Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Blok grupuje transakcje w pakiet dołączany do wspólnej historii. Na Signet Anna może użyć monet testowych, choćby z usługi faucet, która rozdaje je do eksperymentów. Nie są to BTC z mainnetu, czyli głównej sieci, a protokół nie wymienia ich na prawdziwe bitcoiny. Uwaga także na adresy: Signet dzieli część formatów testowych z Testnet. Sam wygląd adresu nie wystarcza więc do rozpoznania właściwej sieci. [1] [2] [8]
BIP 325 (dokument techniczny opisujący Signet) opracowali Karl-Johan Alm i Anthony Towns; obsługę Signet wprowadził Bitcoin Core v0.21.0. Program oferuje domyślną sieć publiczną, ale zespół może ustalić własny warunek tworzenia bloków i własnych uczestników. Stwierdzenie „używamy Signet” nie wystarczy: obie strony muszą korzystać z tej samej sieci. Identyfikator wiadomości sieciowych wynika z tego warunku, a nie z nazwy projektu. [1] [3] [4]
Full Node, węzeł samodzielnie sprawdzający reguły, nadal weryfikuje transakcje i Proof of Work, czyli wynik pracy obliczeniowej potrzebnej do utworzenia bloku. Sprawdza też dodatkowy warunek Signet. W sieci domyślnej samo wydobywanie nie wystarczy — potrzebny jest odpowiedni podpis. Nagłówek, skrócony opis bloku, nie zastępuje tej kontroli: wymagane dane znajdują się wewnątrz bloku. [1] [9]
Podpis cyfrowy pozwala sprawdzić, czy wiadomość zatwierdził posiadacz odpowiedniego klucza prywatnego, czyli tajnej wartości liczbowej, bez ujawniania tego klucza. Osoba mogąca spełnić warunek podpisu wpływa na powstawanie bloków. Może zwlekać z podpisaniem albo ograniczać dobór transakcji. Nie otrzymuje jednak kluczy prywatnych Anny ani prawa do zmuszenia jej węzła do przyjęcia dowolnej nieprawidłowej transakcji. Pozostałe reguły nadal obowiązują. Ta kontrolowana możliwość uczestnictwa przydaje się w testach i zarazem wyjaśnia, dlaczego Signet nie jest kopią modelu bezpieczeństwa mainnetu. [1] [9]
Przy tworzeniu aplikacji nie wystarczy jedna udana płatność. Zespół musi wiedzieć, co stanie się przy braku nowych bloków albo reorganizacji, gdy węzeł zastępuje ostatnie bloki inną prawidłową gałęzią. Uzgodniony test pozwala wywołać taką sytuację i sprawdzić, czy portfel poprawnie aktualizuje potwierdzenia. Signet nie obiecuje działania bez przerw; pozwala bardziej przewidywalnie testować także błędy. [1] [5] [6]
W Testnet tworzenie bloków jest otwarte, a jego wahania mogą utrudniać wspólny eksperyment. Regtest pozwala natomiast łatwo tworzyć bloki na żądanie, co pasuje do własnych testów automatycznych. Może łączyć wiele komputerów; nie musi działać w izolacji na jednym komputerze. Signet odpowiada na inną potrzebę: dłuższą współpracę niezależnych uczestników przy uzgodnionych warunkach tworzenia bloków. Żaden z tych trybów nie zastępuje wszystkich innych prób. [1] [2]
Challenge to skrypt, krótki program określający, co blok ma wykazać. Może wymagać jednego podpisu albo Multisig, czyli ustalonej liczby podpisów z kilku kluczy. Własny Signet może jednak używać OP_TRUE, warunku spełnionego bez podpisu. Wystarczy wtedy puste rozwiązanie. Precyzyjniej mówić o dodatkowym warunku skryptowym niż twierdzić, że każdy Signet zawsze potrzebuje podpisującego. [1] [9]
BIP 325 umieszcza niepuste rozwiązanie w specjalnych danych Coinbase Transaction, pierwszej transakcji bloku. Nazwa nie ma tu związku z giełdą. Dane rozszerzają zobowiązanie kryptograficzne (commitment) według BIP 141, które wiąże blok z jego danymi witness, obejmującymi między innymi podpisy, i mają znacznik 0xecc7daa2. Nie są kolejną zwykłą płatnością dla podpisującego. Warunek spełniany w sposób trywialny pozwala pominąć dodatkowe rozwiązanie, lecz nie automatycznie pozostałe reguły bloku. [1] [9] [10]
Gdyby podpisywana wiadomość zawierała ten sam podpis, powstałaby zależność kołowa. Weryfikacja używa więc zmodyfikowanego odcisku transakcji z opróżnionym rozwiązaniem oraz dwóch transakcji wirtualnych. Służą one obliczeniom i nie są wysyłane jako dodatkowe płatności. Podpis nie obejmuje również nonce nagłówka, liczby zmienianej podczas szukania Proof of Work. Jej zmiana nie wymaga nowego podpisu, ale nie oznacza to dowolności w zmienianiu reszty bloku. [1] [9]
Anna najpierw upewnia się, że portfel, węzeł i eksplorator bloków używają tej samej sieci testowej. Eksplorator bloków to aplikacja do wyszukiwania transakcji i bloków w danej sieci. W Bitcoin Core pomaga getblockchaininfo i pole signet_challenge, pokazujące ustawiony warunek. Następnie obserwuje rzeczywiste potwierdzenie, nie tylko komunikat o wysłaniu, i korzysta z osobnego portfela testowego. Udana próba pokazuje zachowanie aplikacji w danych warunkach. Nie gwarantuje bezpieczeństwa środków ani odporności na atakującego w mainnecie. [7] [8]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Nakamoto Consensus, Block Propagation, Initial Block Download, Block Weight, Bitcoin, Bitcoin Core. Do tego hasła prowadzą również odsyłacze z Testnet, Miniscript, Dead Man’s Switch.