133 / 736MuSig2

MuSig2

Совместное одобрение платежа без передачи приватных ключей

Два человека могут совместно одобрить платёж в биткоине, не передавая друг другу приватных ключей. MuSig2 превращает их сотрудничество в одну подпись. В блокчейне она может выглядеть как обычный платёж Taproot, хотя решение приняли несколько участников.

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.

DOC · 001BIP 327 — MuSig2 for BIP340-compatible Multi-SignaturesСпецификация DOC · 002Bitcoin Optech — MuSigДокументация DOC · 003MuSig2 paperПервичный источник DOC · 004Bitcoin Core — secp256k1 libraryДокументация DOC · 005BIP 340 — Schnorr SignaturesСпецификация DOC · 006BIP 341 — TaprootСпецификация DOC · 007libsecp256k1 — MuSig2 API and nonce safetyДокументация DOC · 008Bitcoin Developer Guide — WalletsДокументация DOC · 009Bitcoin Developer Guide — Block ChainДокументация DOC · 010Bitcoin Developer Reference — TransactionsДокументация
Обновлено: Сначала источники · Не является инвестиционной рекомендацией