Miniscript

Anna chce na co dzień korzystać ze swoich monet za pomocą własnego klucza. Podpis cyfrowy potwierdza autoryzację płatności za pomocą klucza prywatnego, czyli tajnej wartości liczbowej, bez ujawniania tego klucza. Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Anna chce też przygotować ścieżkę dla Piotra: będzie mógł wydać je swoim kluczem po 144 blokach od potwierdzenia tego wyjścia. Taki zamiar nazywa się spending policy, czyli regułami wydawania. Miniscript pomaga nadać mu precyzyjną postać zrozumiałą dla portfela. Piotr nadal potrzebuje klucza; czekanie go nie zastępuje. To prosty przykład alternatywnych dróg dostępu, a nie automatyczny przelew ani wykrywanie utraty klucza przez Annę. [1] [2] [10]

Reguła opisana słowami nie jest jeszcze programem weryfikowanym przez sieć. Kompilator może wybrać dla niej konkretny Miniscript i przekształcić go w Bitcoin Script. Output Descriptor opisuje następnie skrypty wraz z kluczami i ewentualnymi ścieżkami ich wyprowadzania; może też zawierać sumę kontrolną wykrywającą błędy przepisywania. Przy wydawaniu sieć sprawdza rzeczywisty skrypt i dostarczone dane, nie pierwotne zdanie. Miniscript nie dodaje instrukcji ani nie zmienia konsensusu, wspólnych reguł poprawności. Nie da się nim opisać każdego możliwego Bitcoin Script. [1] [3] [6]

Blok grupuje transakcje w pakiet dołączany do wspólnej historii. W przykładzie Piotra 144 bloki liczymy od potwierdzenia wyjścia, czyli konkretnej kwoty z warunkami wydania. Nie oznacza to dokładnie doby ani czasu od utworzenia portfela. Miniscript zapisuje względne oczekiwanie jako older(n), wykorzystując CSV i pole nSequence wejścia wydającego to wyjście. BIP 68 określa znaczenie tego pola przy sprawdzaniu wieku. Natomiast after(n) korzysta z CLTV i bezwzględnego nLockTime, czyli ustalonej wysokości lub granicy czasowej. Portfel musi poprawnie ustawić pola transakcji i spełnić pozostałe warunki. Blokad według wysokości i czasu nie wolno łączyć w niezgodny sposób; samo czekanie niczego nie wysyła. [1] [7] [8] [9] [11]

Pokazanie opisu reguł nie wystarczy. Portfel musi dostarczyć dane spełniające dozwoloną ścieżkę, na przykład podpisy lub sekret odpowiadający wymaganemu hashowi, zwany jego preimage. Hash to cyfrowy odcisk danych; tutaj sprawdza się, czy podany sekret daje wymagany odcisk. Takie spełnienie to satisfaction; potrzebne dane wejściowe są częścią witness transakcji. Łączenie gałęzi może wymagać prawidłowego niespełnienia jednej z podreguł, aby skorzystać z innej ścieżki. To dissatisfaction, a nie nieważność całej płatności. Program może przygotować odpowiednią drogę, ale nie wymyśli brakującego klucza prywatnego ani nieznanego sekretu. [1] [12]

PSBT to format przekazywania przygotowanej transakcji i dodatkowych danych między portfelem a urządzeniami podpisującymi. Sama obsługa PSBT nie wystarcza: program i Hardware Wallet muszą rozumieć descriptor oraz jego warunki. Bitcoin Core dodał obserwowanie Miniscript w P2WSH w wersji 24, podpisywanie w wersji 25, a użycie w descriptorach Taproot w wersji 26. Obserwowanie monet nie oznacza więc możliwości ich wydania. Przy konfiguracji sprawdź na zaufanym ekranie klucze, wymagane podpisy, opóźnienia i wszystkie alternatywne ścieżki, zgodnie z rzeczywistymi możliwościami urządzenia. [3] [4] [5]

Seed Phrase odtwarza klucze, ale przy własnym złożonym warunku może nie ujawnić, jak połączono je z innymi kluczami i skryptem. To kopia zapisana jako ciąg słów, z którego portfel może wyprowadzić swoje klucze. Zachowaj dokładny descriptor z sumą kontrolną, przyporządkowanie kluczy, ścieżki wyprowadzania i rozróżnienie adresów odbiorczych oraz reszty. Osobno zapisz sieć, zakres adresów i punkt rozpoczęcia przeszukiwania historii. Publiczny descriptor nie jest kluczem prywatnym, ale może ujawnić historię płatności. Zanim użyjesz takiego układu, sprawdź odtworzenie portfela obserwacyjnego oraz każdą przewidzianą ścieżkę wydania w środowisku Regtest lub Signet. [5] [6]

pk(), older(), after() i sha256() oznaczają podpisy, oczekiwanie albo wymagany sekret. and_v(), or_d() i thresh() łączą warunki. Opakowania takie jak v: dostosowują sposób wykonania, zachowując znaczenie podwyrażenia. Typy B, V, K i W pilnują, jak części przekazują elementy na stosie, przestrzeni roboczej skryptu; nie każda para do siebie pasuje. Kontrola typów może wykryć niezgodne połączenie. Nie zdecyduje jednak, komu Anna powinna zaufać ani czy dobrze wybrała drogę awaryjną. [1] [2]

Struktura pozwala wcześniej analizować rozmiar skryptu i witness, liczbę operacji, sprawdzeń podpisów oraz elementów stosu. Pomaga to oszacować koszt różnych ścieżek i wykryć przekroczenie dozwolonych granic. Znaczenie ma środowisko: P2WSH umieszcza warunki w SegWit, a Tapscript oznacza skrypty używane w Taproot. Ich limity częściowo się różnią. Obok reguł konsensusu obowiązują zwykłe zasady przekazywania transakcji. Wynik analizy nie jest więc certyfikatem, że każdy portfel poradzi sobie z zaplanowanym sposobem wydawania. [1]

Klucz publiczny służy do sprawdzania podpisów i nie musi być tajny. Analiza malleability sprawdza, czy osoba z zewnątrz może zmienić jedną poprawną satisfaction w inną, nadal poprawną. Gwarancje opierają się na konkretnych założeniach: atakujący nie ma kluczy prywatnych uczestników, nie zna więcej preimages niż uczciwy użytkownik i widzi tylko jedną satisfaction. Zakłada się również brak powtórzonych kluczy publicznych i zwykłe zasady przyjmowania; górnik może mieć możliwości niedostępne zwykłemu węzłowi przekazującemu transakcje. Nie jest to ochrona przed każdym nieuczciwym uczestnikiem, utratą kopii czy złym projektem przechowywania. Te kwestie trzeba ocenić osobno. [1]

Kompilator może wyrazić te same reguły na różne sposoby, uzyskując różne rozmiary skryptu i witness. Wybiera według modelu kosztów. Oznaczenie 9@ przy gałęzi języka polityk wskazuje względne prawdopodobieństwo jej użycia; nie jest liczbą podpisów ani uprawnieniem nadanym przez sieć. Inna kompilacja może stworzyć inny skrypt, a zatem inne adresy. Przy odtwarzaniu nie wystarczy ponownie opisać reguł własnymi słowami i ich skompilować. Potrzebne są dokładnie zapisany opis, sprawdzenie wyprowadzonych adresów i przetestowana ścieżka podpisu. [2] [5]