MuSig2 pozwala kilku osobom razem utworzyć jeden podpis Schnorra, potwierdzający zgodę na konkretną wiadomość bez ujawniania ich kluczy prywatnych. Procedura BIP327 ma dwie rundy komunikacji. Łączy klucze publiczne we wspólny klucz, a wkłady w jeden podpis zgodny z BIP340. Podstawowy model to n-of-n: wszyscy podpisujący muszą wnieść swój wkład.
Wyobraź sobie wspólną kasę, z której każdą płatność muszą zatwierdzić Alicja i Bob. Podpis cyfrowy potwierdza autoryzację płatności za pomocą klucza prywatnego, czyli tajnej wartości liczbowej, bez ujawniania tego klucza. Tradycyjny Multisig oparty na skrypcie może ujawnić w transakcji kilka kluczy i podpisów. W MuSig2 każdy zachowuje swój klucz prywatny i wnosi wkład we wspólny podpis. Sieć sprawdza jeden wynik. Oszczędność dotyczy zapisu i weryfikacji w blockchainie; potrzeba uzgodnień między uczestnikami pozostaje. Jonas Nick, Tim Ruffing i Yannick Seurin przedstawili protokół w pracy opublikowanej w październiku 2020 roku. [3] [2] [10]
Sam MuSig2 nie jest układem 2-of-3, w którym dowolna para zastępuje nieobecnego trzeciego podpisującego. W modelu n-of-n musi uczestniczyć każdy członek grupy. Osoba niedostępna lub odmawiająca podpisu może zatrzymać współpracę. Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Jeśli portfel ma działać również wtedy, potrzebuje innej, wcześniej zaprojektowanej ścieżki wydania lub mechanizmu podpisu; sama nazwa MuSig2 tego nie zapewnia. [1] [8]
Przed podpisywaniem uczestnicy tworzą wspólny klucz publiczny. Klucz publiczny służy do sprawdzania podpisów i nie musi być tajny. W pierwszej rundzie wymieniają publiczne nonce, czyli jednorazowe dane przygotowujące podpis. W drugiej tworzą i przekazują podpisy częściowe dla tej samej wiadomości i kontekstu, po czym łączą je w wynik końcowy. Pierwszą rundę można przygotować wcześniej, zanim płatność będzie znana, zgodnie z warunkami protokołu. Jednak przed utworzeniem podpisu częściowego każdy musi sprawdzić konkretną transakcję, zwłaszcza odbiorcę, kwotę i opłatę. Przygotowanie nie jest zgodą na nieznaną płatność; sprawdzanie po podpisaniu to za późno. [1] [3]
Przy naiwnym sumowaniu napastnik mógłby dobrać swój klucz publiczny tak, aby wykorzystać klucze innych. MuSig2 stosuje więc wagi liczbowe, zwane współczynnikami, wyprowadzone z listy kluczy. KeyAgg uwzględnia również kolejność; aplikacja może użyć KeySort, aby ją ujednolicić. Wszyscy muszą przyjąć tę samą listę i zasady, inaczej nie obliczą tego samego wspólnego klucza. [1] [5]
Nonce nie oznacza tu licznika kopania, lecz jednorazowe dane do podpisu: pubnonce przekazuje się innym, a secnonce pozostaje u podpisującego. Tajnej nonce nigdy nie wolno ponownie użyć w kolejnym wywołaniu Sign. Dwa powstałe w ten sposób podpisy częściowe mogą ujawnić klucz prywatny. Zmiana wiadomości lub powtórzenie pozornie identycznej płatności nie stanowi bezpiecznego wyjątku. [1] [7]
Poprawna kryptografia nie wystarczy, jeśli po restarcie aplikacja odtworzy zużytą secnonce z kopii lub przekaże ją dwóm równoległym zadaniom. Libsecp256k1 unieważnia tajną nonce przez nadpisanie podczas podpisywania, ale kopia poza kontrolą biblioteki może obejść ochronę. Zarządzanie stanem musi zapobiegać ponownemu użyciu przy błędach, odtwarzaniu i współbieżności. Prywatnego klucza podpisu można używać wielokrotnie; jednorazowa jest nonce. [7]
Koordynator może zbierać publiczne nonce i podpisy częściowe oraz pośredniczyć w wymianie. Przy poprawnym użyciu protokołu nie pozwala mu to podpisywać zamiast uczciwego uczestnika, choć może udaremnić proces. Każdy musi sprawdzić, co podpisuje. Weryfikacja podpisów częściowych pomaga wykryć problem, ale wymaga pierwotnych publicznych wkładów i właściwego kontekstu; sama zagregowana nonce nie pozwala wskazać sprawcy. [1] [7]
Wynikiem jest 64-bajtowy podpis BIP340. Taproot key path to sposób wydawania, w którym sieć sprawdza podpis dla klucza zapisanego w wyjściu, bez ujawniania zapasowego skryptu. Gdy nie używa się trybu domyślnego, po podpisie pojawia się bajt typu sighash. Określa on, które części transakcji są objęte podpisem: ich zmiana unieważniłaby podpis. Sam podpis nie zdradza liczby uczestników ani ich osobnych kluczy. MuSig2 nie ukrywa jednak kwot, wszystkich powiązań płatności czy komunikacji między stronami. Nie łączy też automatycznie podpisów różnych wejść, wskazujących wcześniej otrzymane wyjścia wydawane w tej transakcji. [5] [6]
Obok wspólnej key path Taproot może zawierać warunki skryptowe, na przykład inną kombinację kluczy lub blokadę czasową. Taka blokada udostępnia konkretną ścieżkę dopiero po określonym czasie lub wysokości bloku; nie zastępuje wymaganych podpisów. Blok grupuje transakcje w pakiet dołączany do wspólnej historii. Wysokość bloku oznacza jego pozycję w łańcuchu. Warunki trzeba kryptograficznie ustalić przy tworzeniu wyjścia, czyli konkretnej kwoty z regułami wydawania. Po utracie podpisującego nie można ich dopisać. Script path oznacza wydanie przez taki skrypt: ujawnia odpowiednie warunki i może kosztować więcej. Odtworzenie wymaga więc danych o wybranym układzie, a nie samych tajnych kluczy. [6] [1] [9]
BIP327 opisuje protokół, a biblioteka i portfel określają rzeczywisty interfejs, kopie zapasowe i obsługiwane procedury. Sprawdź wersję, wektory testowe, obsługę nonce i kontrolę podpisywanej transakcji. Obsługa podpisów Schnorra nie oznacza automatycznie pełnej obsługi MuSig2 w każdym portfelu. Wspólny podpis korzysta z istniejących reguł BIP340 i Taproot; samo MuSig2 nie wymaga nowego kodu operacji konsensusu. [4] [7] [2]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Schnorr Signature, Taproot, Multisig, PSBT. Do tego hasła prowadzą również odsyłacze z Schnorr Signature, Submarine Swap, FROST, PTLC.