Подписи Schnorr в Bitcoin: возможности и ограничения
Taproot использует подписи Schnorr по BIP 340. Их математическая структура поддерживает полезные способы совместного подписания, но фраза «сложить ключи» скрывает отдельные протоколы и требования безопасности. В уроке отделим одиночную подпись, агрегированный ключ и совместную процедуру, не реализуя криптографию самостоятельно.
Для библиотеки сохраняем трёх сотрудников из прошлого урока. Пример относится к политике организации; реальные ключи и подписи не вычисляются. Результат — правильный словарь для выбора совместимого инструмента.
Один алгоритм подписи
BIP 340 определяет конкретную подпись, её кодирование и проверку на выбранной кривой. Это не любое математическое семейство с названием Schnorr. У совместимости есть точные правила входов и ограничений. Подпись стандартной формы занимает 64 байта; использование в Taproot дополнительно связано с режимом подписываемых данных по соответствующей спецификации.
Открытый ключ в этом профиле имеет x-only-представление. Это сокращённая форма с установленными правилами интерпретации, а не разрешение удалить произвольную половину любого ключа и продолжить проверку. Извлечение и обработка должны выполняться совместимой реализацией.
Как и для прежних подписей, правильная проверка отвечает на вопрос о разрешении определённого сообщения. Она не доказывает имя человека, правильность заказа или доступность архива курса. Эти свойства требуют других данных и правил.
Агрегированный ключ
Несколько публичных участников могут образовать общий ключ по специальному протоколу. Совместное разрешение тогда может выглядеть как одна подходящая подпись для общего назначения. Для внешнего наблюдателя такая форма способна раскрывать меньше структуры, чем некоторые явные многоподписные условия.
Однако нельзя просто сложить произвольные публичные ключи и считать защиту готовой. Протокол должен учитывать злонамеренный выбор ключей, взаимодействие участников и используемые значения подписи. MuSig2 задаётся отдельной спецификацией BIP 327 и требует совместимых правил на каждом этапе.
Для библиотеки сначала проверяем поддержку выбранного протокола подписантами. Наличие поддержки обычного Taproot-адреса не означает поддержку совместного MuSig2. Устройство может получать и расходовать одиночный путь, но не иметь нужной процедуры обмена между сотрудниками.
Совместная процедура
В одиночной подписи один участник располагает всем требуемым секретом. В совместной процедуре участники обмениваются определёнными данными и выпускают частичные результаты, которые затем объединяются. Без готовности необходимого набора сотрудников итог не появляется автоматически.
Особенно важны одноразовые значения протокола. Повторное или неправильное использование вспомогательных секретов может раскрыть ключевой материал. Поэтому практическую реализацию не стоит строить из короткого собственного скрипта после чтения математической формулы.
| Утверждение | Требуемое уточнение |
|---|---|
| «Адрес поддерживает Schnorr» | Какой путь и какой подписант? |
| «Ключи объединены» | По какому протоколу и с какой защитой? |
| «Нужны два сотрудника» | Это пороговая схема или иной набор условий? |
| «В цепочке одна подпись» | Как согласуется сообщение вне цепочки? |
Управление с порогом «2 из 3» не следует автоматически из базового MuSig2 для произвольного набора всех участников. Пороговые схемы и альтернативные скриптовые пути имеют собственную конструкцию. Поэтому предыдущую политику нельзя переносить словесным переименованием.
Сообщение и согласование
Сотрудники должны согласовать один и тот же транзакционный контекст. Если подготовитель показывает одному получателя читателя, а другому другую версию, процедура не должна молча собрать разрешение непонятного содержания. Независимый разбор заявки сохраняет смысл даже при одной итоговой подписи.
Для возврата по счёту library-17-001 по-прежнему проверяются сеть, 10 000 получателю, собственная сдача и предел комиссии. Агрегация не отменяет ни одного коммерческого условия. Она меняет способ выражения криптографического разрешения.
Также нужно определить поведение при отказе участника, потере соединения и повторе сессии. Промежуточные данные не следует бездумно использовать повторно. Приложение хранит идентичность сессии согласования и её завершение по выбранному протоколу, а не только номер возврата.
Приватность имеет границы
Одна внешняя подпись может скрыть число участников конкретного успешного пути. Однако сообщения вне цепочки, адреса сетевого взаимодействия, журналы и опубликованные досье способны раскрыть организацию. Публичный граф транзакций и размеры также продолжают существовать.
Если расход происходит по раскрытому резервному скриптовому пути Taproot, наблюдатель получает сведения об этом пути. Неиспользованные ветви не обязательно раскрываются целиком, но это не равнозначно полному скрытию всех условий. Следующий урок разберёт путь ключа и путь скрипта.
Библиотека выбирает форму после оценки инструментов, восстановления и доступности сотрудников. Технологически компактная запись может усложнить оперативный процесс. Если никто не умеет безопасно восстановить совместную процедуру, уменьшение размера подписи не делает систему качественнее.
Как записать профиль
В досье сохраняем стандарт одиночной подписи, протокол совместного подписания, набор участников, правила идентификации сообщения и процедуру восстановления. Для учебного курса пока достаточно сравнения: явная политика нескольких подписей отличается от совместного формирования одной подписи.
Что архивировать вне цепочки
Совместное согласование может требовать журнал идентичности участников, выбранного сообщения и завершения сессии. При этом не следует сохранять секретные одноразовые значения в обычный лог ради удобства отладки. Архив определяет достаточные публичные сведения для объяснения решения и отдельную защищённую процедуру состояния подписантов. Если инструмент управляет такими данными самостоятельно, оператор должен знать правила резервирования именно этого инструмента. Один окончательный txid объясняет сетевой объект, но не восстанавливает весь процесс совместной подписи. Поэтому досье связывает операцию и согласование, сохраняя разные границы доступа.
Окончательная форма в цепочке не показывает всю организационную процедуру. Её воспроизводимость обеспечивается отдельным досье совместного согласования и поддерживаемым состоянием участников.
Допустим, сотрудник сменил рабочий компьютер после согласования выплаты. Наличие уже опубликованной подписи не определяет, какое состояние понадобится для следующей совместной сессии. В досье различаем завершённую операцию и готовность участников к новой. Так восстановление рабочего места не выдаётся за автоматическое восстановление всей процедуры согласования.
Спецификации приведены в BIP 340 и BIP 327. В этой работе алгоритмы не запускались и совместимость устройств не проверялась. Результат урока — отказ от опасного сокращения «Schnorr автоматически даёт любую мультиподпись» и точный набор вопросов к выбранной реализации.