MuSig2

Агрегация ключей и есть весь фокус: у нескольких участников есть по приватному ключу, и математика складывает их публичные ключи в один агрегированный ключ, которым никто из них не распоряжается в одиночку. BIP-327 закрепил схему с двумя раундами связи вместо трех в первоначальном MuSig. Для совместного кошелька это означает более низкие комиссии и отсутствие публичных свидетельств того, что кошелек был совместным.

Как это работает

MuSig2 выполняется в два прохода по группе, и только второму проходу нужно знать, что именно подписывается.

В первом проходе каждый подписант создает два секретных одноразовых числа (нонса) и публикует соответствующую пару точек. Координатор складывает эти пары в один объединенный нонс с помощью коэффициента, полученного хешированием всего набора. Этот коэффициент и есть та конкретная инженерная деталь, которая позволила схеме убрать раунд, не открывая заново атаки, сломавшие более ранние двухраундовые проекты.

Во втором проходе каждый подписант создает частичную подпись по хешу подписи транзакции и возвращает одно число. В сумме эти числа образуют подпись размером 64 байта, которая проверяется по агрегированному ключу размером 32 байта по обычным правилам BIP-340. Узел, проверяющий блок, не может определить, сколько человек участвовало, или что в этом участвовал кто-либо.

Стоит прямо назвать два свойства безопасности. Агрегация ключей применяет коэффициент к каждому ключу, чтобы участник не мог сконструировать публичный ключ, который обнуляет ключи всех остальных: это атака вредоносного ключа, которую допускает простое сложение ключей. И нонсы строго одноразовые: подпись двух разных сообщений одним и тем же нонсом сразу раскрывает ваш приватный ключ, поэтому корректные реализации стирают секретный нонс в момент его использования и отказывают во второй подписи в рамках той же сессии.

Где это встречается

MuSig2 лежит в основе расхода через путь ключа Taproot, так что фактически вы видите адрес bc1p, который ведет себя как любой другой.

Аргумент о размере конкретен. Вход Taproot через путь ключа занимает 57,5 vbytes независимо от того, подписал его один человек или пятеро, тогда как расход по скрипту-свидетелю два из трех должен раскрыть три публичных ключа и две подписи и занимает больше чем вдвое. Выходы Taproot стали доступны для расхода в блоке 709 632 14 ноября 2021 года, так что эта возможность уже годы существует в цепи, а узким местом было программное обеспечение кошельков.

BIP-373 обеспечивает инфраструктуру: добавляет поля PSBT для публичных нонсов, ключей участников и частичных подписей, чтобы аппаратное устройство могло присоединиться к сессии подписи без того, чтобы каждый производитель изобретал свой формат сообщений. В потребительских кошельках применение пока невелико. Самое конкретное внедрение представляет собой работу над простыми каналами Taproot в Lightning, где два участника финансируют канал в один выход MuSig2.

MuSig2 vs мультиподпись

MuSig2 по своей конструкции требует участия всех n; классическая мультиподпись может иметь любой порог.

Это различие решает, стоит ли вообще держать его рядом со своими сбережениями. Конфигурация два из трех на основе скрипта продолжает работать при потере одного ключа, потому что скрипт называет три ключа и требует два из них. Агрегированный ключ требует присутствия всех участников, и исчезнувший подписант уносит с собой средства, если только тот же адрес не фиксирует также путь скрипта с ветвью восстановления. Настоящие пороги под одним агрегированным ключом требуют другого протокола, например FROST, а BIP-327 определяет не его.

Второй компромисс сознателен. Мультиподпись на основе скрипта может проверить любой человек с обозревателем блоков, а MuSig2 нет: это выигрыш в приватности для семьи и препятствие для распорядителя, которому нужно доказать, что платеж требовал двух должностных лиц.