Читатели Bitcoin Optech получают информационный бюллетень-уровневая сводка наиболее важных технических новостей, происходящих в Биткойне, а также ресурсы, которые помогают им узнать больше. Чтобы наши читатели были в курсе последних событий в биткойнах, мы переиздаем последний выпуск этого информационного бюллетеня ниже. Не забудьте подписаться, чтобы получать этот контент прямо на свой почтовый ящик.
Информационный бюллетень этой недели включает в себя наши регулярные разделы, описывающие, как вы можете подготовиться к Taproot, резюмируя последние выпуски и кандидаты на выпуск, а также перечисляя заметные изменения в популярной инфраструктуре Биткойн проектов.
Новости
На этой неделе нет важных новостей.
Подготовка к Taproot # 7: мультисигнатуры
Еженедельник серия о том, как разработчики и поставщики услуг могут подготовиться к предстоящей активации Taproot на высоте блока 709 632.
Из 1000 блоков, полученных до этой записи, 11% всех входных транзакций содержали код операции с несколькими подписями. Два самых больших и самых непосредственных преимущества Taproot проявятся, если многие пользователи и службы, создающие эти транзакции, переключатся с кодов операций с несколькими подписями на коды операций без сценариев мультисигнатур .
Первым важным преимуществом будет уменьшение размера транзакции. Мультиподписи на основе скриптов увеличиваются в размере по мере того, как требуется больше ключей и подписей, но мультисигнатуры имеют постоянный небольшой размер. Наименьшая эффективная политика с несколькими подписями (1 из 2) требует больше места, чем политика с несколькими подписями, в которой могут участвовать тысячи подписавших. Уменьшение размера приводит к прямому снижению комиссий для пользователей с несколькими подписями и косвенному снижению комиссий для всех пользователей, поскольку тот же объем требований для подтвержденных транзакций может быть удовлетворен с использованием меньшего количества места для блоков.
Второе важное преимущество-улучшенная конфиденциальность. Каждое использование мультиподписей четко записывается в цепочку блоков, где наблюдатели могут использовать их, чтобы делать обоснованные предположения об истории кошелька и текущем балансе отдельных пользователей. Например, глядя на блок 692039, мы можем отличить не только расходы на мультиподписи от затрат на одиночную подписку, но также различить различные размеры наборов и пороговые значения для мультиподписей.
Для сравнения, сторонняя сторона ищет только в блокчейне данные не могут сказать, что спонсор использовал мультиподпись. Когда мульти-подпись используется для траты ключевого пути, она неотличима от траты одиночной сигнатуры. Если бы все одноподписные и мульти-подписи в приведенном выше блоке были переключены на траты ключевого пути P2TR, только некоторые экзотические траты были бы различимы по их сценариям (и даже они могли бы использовать траты ключевого пути в лучшем случае).
Использование мультисигнатур
Нам известно о трех схемах мультисигнатур на основе Шнорра, разработанных специально для Биткойн, всех участников целевой Семейство MuSig :
MuSig (также называемый MuSig1), который должен быть прост в реализации, но требует трех раундов связи во время процесса подписания. MuSig2 также прост в реализации. Это исключает один раунд связи и позволяет комбинировать другой раунд с обменом ключами. Это позволяет использовать процесс подписи, в чем-то похожий на то, что мы используем сегодня с основанной на сценариях мультиподписью. Это действительно требует хранения дополнительных данных и обеспечения того, чтобы ваше программное обеспечение или оборудование для подписи не могло быть обманутым, чтобы неосознанно повторять часть сеанса подписи. MuSig-DN (Deterministic Nonce) значительно сложнее в реализации. Его общение между участниками нельзя сочетать с обменом ключами, но его преимущество состоит в том, что он не уязвим для повторных сеансовых атак.
Все подписывающие стороны должны согласовать протокол для использования, поэтому может возникнуть сетевой эффект, когда многие реализации предпочитают использовать один и тот же протокол. Авторы предложений MuSig предполагают , что это будет MuSig2 за счет относительной простоты и высокой полезности.
Существует открытый и активно развивающийся PR для libsecp256k1-zkp для добавления поддержки MuSig2. Мы ожидаем, что основной рабочий процесс с множественной подписью будет выглядеть примерно так:
Кошелек для каждого участника генерирует BIP32 xpub, который предоставляется всем остальным участникам через дескриптор сценария вывода или другой метод (тот же, что обычно делается для мультиподписей). Кошелек также генерирует набор одноразовых номеров, которые также используются другими участниками. Кошелек может генерировать эти одноразовые номера, используя усиленную деривацию BIP32. Одноразовые номера-это 32 байта, и вам нужно два из них на подпись. Для редко используемых кошельков все одноразовые номера, необходимые в течение всего срока службы кошелька, могут быть переданы заранее. Для более часто используемых кошельков (например, узлов маршрутизации LN) каждый кошелек может отправить свою подпись для текущей транзакции вместе со своими одноразовыми номерами для следующей транзакции. Любой из кошельков может затем сгенерировать агрегированный открытый ключ, объединив свой pubkey в определенном BIP32. глубина с pubkeys на той же глубине, что и у всех других кошельков в ассоциации с мультиподписью. Агрегированный открытый ключ может использоваться для получения платежей P2TR. Когда один из кошельков хочет потратить средства, он использует Рабочий процесс на основе PSBT , аналогичный тому, который он использовал бы с основанной на сценариях мультиподписью. В отличие от мультиподписи, кошелек использует свои следующие одноразовые номера и следующие одноразовые номера всех других участников для создания общего одноразового номера в соответствии с алгоритмом MuSig2; Затем он создает частичную подпись для этого одноразового номера и транзакции. Когда другие кошельки получают PSBT, они используют ту же процедуру. Затем частичные подписи объединяются для создания окончательной подписи, и транзакция транслируется.
Пороговое подписание
Сами по себе схемы мультиподписи MuSig дают вам только подпись n-of-n-каждая сторона тот, кто вносит ключ в составной открытый ключ, также должен вносить частичную подпись в окончательную подпись. Это отлично работает в качестве прямой замены для некоторых видов использования мультисиг на основе сценариев сегодня, таких как расходование 2 из 2 результатов финансирования LN, но это отход от других популярных политик, таких как скрипт с мультиподписью 2 из 3, используемый множество обменов.
Несколько разработчиков работают над схемами пороговой подписи , которые принесет те же преимущества эффективности и конфиденциальности, что и множественные подписи, для сценариев k-of-n, но есть простой трюк, который можно использовать до тех пор, пока эти схемы не станут доступны.
Во многих пороговых случаях заранее известно, какой участники, скорее всего, подпишутся. Например, в ситуации 2 из 3 может быть известно, что обычно Алиса и Боб подписывают совместно, в то время как Кэрол подписывается только в том случае, если один из других недоступен. Для этого набора обстоятельств первичные ключи могут использовать мультиподпись для траты ключевого пути главного корня (например, между Алисой и Бобом), а дополнительные результаты (Алиса и Кэрол или Боб и Кэрол) могут использовать мультиподписи с кодом операции OP_CHECKSIG в отдельных ветвях в дерево tapscripts .
В нормальном случае в приведенном выше точно такая же эффективность и конфиденциальность, как транзакция с одной подписью или несколькими подписями. В ненормальном случае расходы по-прежнему работают, как ожидалось, и остаются более эффективными и конфиденциальными, чем публикация ваших параметров с несколькими подписями в цепочке.
Хотя пользователи, желающие минимальные сборы и максимальную конфиденциальность, могут в конечном итоге переключиться на схемы чисто пороговой подписи, указанное выше <также может остаться схема href="https://murchandamus.medium.com/2-of-3-multisig-inputs-using-pay-to-taproot-d5faf2312ba3"target="_ blank"> используется, потому что он предоставляет аудитору (если он знает все открытые ключи участников) подтверждение о том, какие соответствующие закрытые ключи использовались для подписи.
Релизы и релизы-кандидаты
Новые выпуски и кандидаты на выпуск для популярных инфраструктурных проектов Биткойн. Рассмотрите возможность обновления до новых выпусков или помощи в тестировании кандидатов на выпуск.
C-Lightning 0.10.1rc2 -это кандидат на выпуск обновления, который содержит ряд новых функций, несколько исправлений ошибок и несколько обновлений для разработки протоколов (включая двойное финансирование и предлагает ).
Заметные изменения в коде и документации
Заметные изменения на этой неделе в Bitcoin Core , C-Lightning , Eclair , LND , Rust-Lightning , libsecp256k1 , Интерфейс аппаратного кошелька (HWI) , Rust Bitcoin , сервер BTCPay , Предложения по улучшению биткойнов (BIP) и Lightning BOLT .
Bitcoin Core # 22006 добавляет документацию для пользовательского пространства, статически определяемой трассировки ( USDT) и первые три точки трассировки-поддержка сборки и макросы, для которых были добавлены в Bitcoin Core № 19866 . Пользователи, которые создают Bitcoin Core с включенной трассировкой eBPF, могут подключаться к точкам трассировки с помощью предоставленных примеров скриптов или написать свои собственные сценарии трассировки для большей наблюдаемости в узле, когда подключается новый блок, принимаются входящие сообщения P2P и отправляются исходящие сообщения P2P. Документация также включает примеры использования и рекомендации по добавлению новых точек трассировки. Eclair № 1893 позволяет отдельная конфигурация ставок для необъявленных каналов , объявленных каналов и минимумы эстафеты батут . Этот PR также устанавливает разные ставки ретрансляции по умолчанию для необъявленных каналов (0,01%) в отличие от объявленных каналов (0,02%). Rust-Lightning # 967 добавляет поддержку для создания спонтанные платежи в стиле keysend с помощью вызова функции thesend_spontaneous_payment. С этим изменением все четыре реализации LN, которые мы рассмотрим, будут поддерживать отправку ключей.
Автор также отправил соответствующая документация (пока еще не объединенная) по платежам с ключами в виде BLIP (предложения по улучшению Bitcoin Lightning), предлагаемый способ документирования функций и передовых практик, которые не входят в состав спецификации LN BOLTs
Найдите исходное сообщение здесь.
Пожалуйста, подпишитесь на информационный бюллетень Bitcoin Optech , чтобы ежемесячно получать этот контент прямо на свой почтовый ящик.