134 / 736SCHNORR

Schnorr Signature

Podpis Schnorra

Gdy portfel podpisuje płatność, nie tworzy obrazka podpisu ani nie wysyła twojego klucza prywatnego. Tworzy dowód, który sieć może zweryfikować. Schnorr Signature pozwala zrobić to w zwartej formie i umożliwia kilku osobom wspólne podpisywanie. W Bitcoinie ten mechanizm jest używany z Taproot.

Schnorr Signature pozwala cyfrowo zatwierdzić konkretną wiadomość bez ujawniania klucza prywatnego. Portfel tworzy podpis tym tajnym kluczem; innym do sprawdzenia wystarcza odpowiadający mu klucz publiczny. W Bitcoinie podpis pomaga wykazać uprawnienie do wydania monet, ale nie zastępuje pozostałych kontroli transakcji. Wariant Bitcoina określa BIP340; jest używany z Taproot.

Alicja chce wysłać bitcoiny do Boba. Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Portfel buduje transakcję i podpisuje kluczem prywatnym dane wymagane przez wybrany tryb podpisu. Następnie węzeł sprawdza podpis i pozostałe warunki wydania środków. Węzeł to program, który sprawdza transakcje i bloki oraz wymienia dane z innymi uczestnikami sieci. Poprawny podpis sam w sobie nie potwierdza urzędowej tożsamości Alicji, właściwego odbiorcy ani dostatecznej ilości niewydanych środków; to osobne kwestie. Podpisana płatność nadal może być niezamierzonym błędem. [5] [3] [10] [11]

BIP340 autorstwa Pietera Wuillego, Jonasa Nicka i Tima Ruffinga dokładnie określa bitcoinowy podpis Schnorra. BIP341 włącza go do reguł wydawania Taproot, aktywowanych w głównej sieci Bitcoina (Mainnet) przy bloku 709632 w 2021 roku. Blok grupuje transakcje w pakiet dołączany do wspólnej historii. To dwa poziomy: algorytm podpisu i warunki wydania środków. Starsze wyjścia oraz SegWit v0 nadal używają ECDSA, wcześniejszego algorytmu podpisu; aktualizacja nie zastąpiła ich podpisów wstecznie. [1] [2] [11]

Bajt jest standardową jednostką ilości danych. Wariant Bitcoina wykorzystuje krzywą eliptyczną secp256k1, matematyczną strukturę służącą do pracy z kluczami i podpisami. BIP340 ustala stały format podpisu o długości 64 bajtów. Klucz publiczny zapisuje się jako 32 bajty współrzędnej x; x-only nie oznacza pominięcia kontroli bezpieczeństwa. Reguły jednoznacznie wskazują też, który wariant punktu krzywej ma wykorzystać weryfikujący. Mniejszy, ściśle określony format ułatwia pracę programom, ale z tych dwóch liczb nie da się wywnioskować rozmiaru całej transakcji. [1] [12]

Portfel nie podpisuje nieokreślonego „zgadzam się”. Tryb sighash określa, które dane transakcji tworzą podpisywaną wiadomość. SIGHASH_DEFAULT chroni informacje o wszystkich wejściach i wyjściach, podobnie jak SIGHASH_ALL: jakie otrzymane wcześniej monety są wydawane i jakie nowe kwoty z warunkami wydania powstają. Zmiana objętych danych unieważnia podpis. Nie oznacza to jednak podpisania każdego bajtu, na przykład innych podpisów. Pozostałe dozwolone tryby mają inny zakres. Sam podpis zajmuje 64 bajty; przy trybie innym niż domyślny dodaje się bajt typu, więc ten element ma 65 bajtów. Wciąż nie jest to rozmiar całego wejścia ani transakcji. [2]

Podczas podpisywania powstaje tajna wartość nonce. Jej ponowne użycie z tym samym kluczem do różnych wiadomości może ujawnić klucz prywatny. BIP340 dokładnie opisuje więc wyprowadzanie nonce i zaleca pomocnicze dane losowe jako dodatkową ochronę implementacji. Użytkownik nie wymyśla nonce i nie zapisuje jej w kopii zapasowej. Zarządza nią sprawdzona biblioteka podpisu; improwizacja może tu zniweczyć skądinąd poprawną kryptografię. [1] [9]

Matematyczna budowa podpisów Schnorra pozwala tworzyć protokoły, w których kilka osób uzgadnia wiadomość i generuje wspólny podpis. Przykładem jest MuSig2 według BIP327. W podstawowej wersji tego protokołu musi uczestniczyć każdy członek wybranej grupy. Wymaga koordynacji, właściwej obsługi kluczy i własnej bezpiecznej procedury dla nonce. Zwykłe dodanie dowolnych gotowych podpisów nie wystarcza. Sama obsługa Schnorr Signature nie oznacza też, że portfel umożliwia taką współpracę. [8]

Taproot oferuje różne ścieżki wydawania. W key path sieć sprawdza podpis względem klucza publicznego zapisanego w wyjściu. Może za nim stać jedna osoba albo współpracująca grupa. W script path ujawniany jest wybrany skrypt — program z warunkami, które płatność musi spełnić. Tapscript to wersja tego języka skryptowego dla Taproot. Jego instrukcja OP_CHECKSIGADD sprawdza jeden podpis i przy powodzeniu dodaje jeden do bieżącego licznika. Powtarzając ją, można ocenić kilka odrębnych podpisów i sprawdzić wymaganą liczbę. Taki skryptowy Multisig to inne rozwiązanie niż jeden zagregowany podpis. Dla konkretnego portfela ustal, kto musi współpracować, co będzie publiczne i jaka możliwość odzyskania środków pozostaje po utracie klucza. [7] [2]

W sieci bez centralnego arbitra jeden węzeł nie może przyjmować podpisu, który drugi odrzuca z powodu innej interpretacji bajtów. BIP340 szczegółowo określa zatem poprawne klucze, podpisy i procedurę weryfikacji. Pozwala też na batch verification, czyli wspólne sprawdzanie wielu podpisów dla oszczędności obliczeń. Nie przepisuje to ich zapisów w łańcuchu ani nie łączy podpisów różnych wejść transakcji. [1]

Wspólny podpis key-path może wyglądać jak podpis jednego klucza. Z samego podpisu nie musi więc wynikać, ile osób się porozumiało. Kwoty, powiązania między wejściami i wyjściami oraz czas transakcji zwykle pozostają jednak widoczne. Schnorr Signature nie szyfruje płatności. Prywatność zależy również od sposobu użycia Taproot, zachowania portfela i okoliczności płatności. [2] [3]

Dla zwykłego użytkownika liczy się portfel, który poprawnie pokazuje odbiorcę, kwotę i opłatę oraz umożliwia niezawodne odtworzenie. Programista sprawdza ponadto dokładną obsługę BIP340, wektory testowe, zarządzanie nonce i zachowanie przy błędach. Nazwa algorytmu nie gwarantuje jakości całego produktu. Dobra biblioteka, taka jak libsecp256k1, wykonuje obliczenia kryptograficzne; nie podejmuje za człowieka decyzji, czy zatwierdzić wyświetloną płatność. [4] [9] [6]

Pełniejszy obraz uzyskasz, czytając to hasło razem z Taproot, MuSig2, Multisig, Bitcoin Script. Do tego hasła prowadzą również odsyłacze z SHA-256, Opcode, MuSig2, Nostr.

DOC · 001BIP 340 — Schnorr SignaturesSpecyfikacja DOC · 002BIP 341 — TaprootSpecyfikacja DOC · 003Bitcoin Optech — Schnorr signaturesDokumentacja DOC · 004Bitcoin Core — secp256k1 verificationDokumentacja DOC · 005Bitcoin Core — Script interpreterDokumentacja DOC · 006BIP 340 rendered specificationSpecyfikacja DOC · 007BIP342 — Validation of Taproot ScriptsSpecyfikacja DOC · 008BIP327 — MuSig2Specyfikacja DOC · 009libsecp256k1 — Schnorr signature APIDokumentacja DOC · 010Bitcoin Developer Guide — WalletsDokumentacja DOC · 011Bitcoin Developer Guide — Block ChainDokumentacja DOC · 012Bitcoin Developer Reference — TransactionsDokumentacja
Zaktualizowano: Najpierw źródła · To nie jest porada inwestycyjna