MuSig2 дає змогу кільком людям разом створити один підпис Шнорра, що засвідчує згоду з конкретним повідомленням без розкриття приватних ключів. Процедура BIP327 має два раунди обміну. Відкриті ключі об’єднуються в спільний ключ, а внески — у підпис, сумісний із BIP340. Базова модель n-of-n: свій внесок мають зробити всі підписувачі.
Уявіть спільну скарбницю, де платіж мають схвалити і Аліса, і Боб. Цифровий підпис підтверджує дозвіл на платіж за допомогою приватного ключа — секретного числового значення, яке при цьому не розкривається. Звичайний скриптовий Multisig може розкрити в транзакції кілька ключів і підписів. З MuSig2 кожен зберігає свій приватний ключ і робить внесок у спільний підпис. Мережа перевіряє один результат. Економія стосується запису й перевірки в блокчейні; потреба домовлятися між собою не зникає. Jonas Nick, Tim Ruffing і Yannick Seurin представили протокол у роботі, оприлюдненій у жовтні 2020 року. [3] [2] [10]
Сам MuSig2 не є схемою 2-of-3, де будь-яка пара може замінити відсутнього третього підписувача. У його моделі n-of-n потрібен внесок кожного члена групи. Недоступний учасник або той, хто відмовляється підписувати, може зупинити співпрацю. Гаманець — це застосунок або пристрій для отримання й надсилання біткоїнів. Якщо гаманець має працювати й тоді, потрібен заздалегідь продуманий інший шлях витрачання чи механізм підпису; назва MuSig2 не забезпечує його автоматично. [1] [8]
Перед підписанням учасники формують спільний відкритий ключ. Відкритий ключ використовують для перевірки підписів; його не потрібно тримати в таємниці. У першому раунді обмінюються відкритими nonce — одноразовими даними для підготовки підпису. У другому створюють і передають часткові підписи для того самого повідомлення й контексту, а потім об’єднують їх. За умовами протоколу перший раунд можна підготувати до того, як платіж стане відомим. Але перед створенням свого часткового підпису кожен має перевірити конкретну транзакцію, зокрема одержувача, суму й комісію. Підготовка не означає згоди на невідомий платіж; перевіряти після підписання вже запізно. [1] [3]
За наївного додавання зловмисник міг би підібрати свій відкритий ключ так, щоб скористатися ключами інших. Тому MuSig2 застосовує числові ваги — коефіцієнти, виведені зі списку ключів. KeyAgg враховує і порядок; для його уніфікації застосунок може використати KeySort. Усі мають брати той самий список і правила, інакше спільні ключі не збігатимуться. [1] [5]
Тут nonce — не лічильник для майнінгу, а одноразові дані для підписання: pubnonce передають іншим, а secnonce залишається у підписувача. Таємну nonce ніколи не можна повторно використовувати для іншого виклику Sign. Два отримані так часткові підписи можуть розкрити приватний ключ. Зміна повідомлення чи повторення начебто однакового платежу не є безпечним винятком. [1] [7]
Правильних криптографічних обчислень недостатньо, якщо після перезапуску застосунок відновлює використану secnonce з копії або передає її двом одночасним завданням. Libsecp256k1 під час підписання знешкоджує таємну nonce перезаписом, але копія поза контролем бібліотеки обходить цей захист. Керування станом має запобігати повторному використанню за помилок, відновлення та паралельної роботи. Сам приватний ключ підпису можна використовувати багато разів; одноразовою є nonce. [7]
Координатор може збирати відкриті nonce та часткові підписи й організовувати обмін. За правильного застосування протоколу це не дає йому змоги підписати замість чесного учасника, хоча він може зірвати процес. Кожен має перевіряти, що підписує. Перевірка часткових підписів допомагає знайти проблему, але потребує початкових відкритих внесків і правильного контексту; самої агрегованої nonce недостатньо, щоб визначити винуватця. [1] [7]
Результат — 64-байтовий підпис BIP340. Taproot key path — спосіб витрачання, за якого мережа перевіряє підпис для ключа у виході, не розкриваючи запасного скрипту. Якщо використовується не типовий режим, після підпису додається байт типу sighash. Він визначає, які частини транзакції підпис закріплює: їхня зміна зробила б його недійсним. Сам підпис не розкриває кількості учасників чи їхніх окремих ключів. MuSig2, однак, не приховує сум, усіх зв’язків платежу чи спілкування сторін. Він також не об’єднує автоматично підписи різних входів, які посилаються на раніше отримані виходи, що витрачаються цією транзакцією. [5] [6]
Поряд зі спільним key path Taproot може містити скриптові умови, наприклад іншу комбінацію ключів або часовий замок. Часовий замок відкриває певний шлях лише після заданого часу чи висоти блоку; потрібні підписи він не замінює. Блок об’єднує транзакції в пакет, який додають до спільної історії. Висота блоку — це його позиція в ланцюзі. Умови слід криптографічно закріпити під час створення виходу — конкретної суми з правилами витрачання. Після втрати підписувача їх не можна дописати. Script path — витрачання через такий скрипт: він розкриває відповідні умови й може коштувати дорожче. Тому відновлення потребує відомостей про обрану схему, а не лише окремих таємних ключів. [6] [1] [9]
BIP327 описує протокол, а бібліотека й гаманець визначають фактичний інтерфейс, резервні копії та підтримувані процедури. Перевіряйте версію, тестові вектори, роботу з nonce та перевірку транзакції перед підписом. Підтримка підписів Шнорра ще не означає повної підтримки MuSig2 в кожному гаманці. Спільний підпис використовує чинні правила BIP340 і Taproot; саме застосування MuSig2 не потребує нового консенсусного opcode. [4] [7] [2]
Для повної картини прочитайте також Schnorr Signature, Taproot, Multisig, PSBT. На цю статтю також посилаються Schnorr Signature, Submarine Swap, FROST, PTLC.