За последний год или два было представлено несколько предложений о предложении договорных дополнений к Биткойну, всегда существовало подозрение среди экспертов, что договоры могут быть возможны без каких-либо дополнений. Доказательство этого появилось в двух формах: расширение репертуара ранее считавшихся невозможными вычислений в (выражающееся в проекте BitVM по реализации каждой операции RISC-V) и серия "почти-удачных" случаев, когда разработчики Биткойна нашли способы, которые были бы возможны для договоров, если бы не некая неизвестная историческая особенность .
Итан Хайльман, Авиху Леви, Виктор Коболов и я разработали схему, которая доказывает, что эта подозрительность была оправдана. Наша схема,Collider*, позволяет заключать договоры на Биткойн уже сегодня, при довольно разумных криптографических предположениях и, вероятно, стоимостью около 50 миллионов долларов за транзакцию (плюс некоторые затраты на оборудование и НИОКР).*
Несмотря на экстравагантные затраты на использование Collider, его настройка очень дешева, и, используя обычный механизм расходов, с использованием Taproot для их разделения, вы возможно, сможете сохранить свои монеты в случае появления квантового компьютера, который внезапно появится и взорвется.
Без сомнения, многие читатели, прочитав эти утверждения, поднимают бровь к небу. К моменту, когда вы закончите чтение этой статьи, вторая будет так же высоко.
Завещания
Контекст этого обсуждения, для тех, кто не знаком, заключается в том, что Биткойн имеет встроенный язык программирования, называемый Биткойн, который используется для авторизации расходов монет. В самые ранние дни содержал богатый набор арифметических операций, которые можно было использовать для реализации произвольных вычислений. Но летом 2010 года Сатоши отключил многие из них, чтобы устранить серию серьезных ошибок. (Возвращение к пред-2010 версии - это цель проекта Великого Восстановления; OP_CAT - менее амбициозное предложение в том же направлении.) Идея ковенантов - транзакций, которые используют, чтобы контролировать количество и направление своих монет - появилась только через несколько лет, а осознание того, что эти операции были бы достаточны для реализации ковенантов, пришло еще позже. К тому моменту сообщество было слишком большим и осторожным, чтобы просто «включить» старые операции таким же образом, как они были отключены.
Ковенанты - это гипотетические конструкции, которые позволили бы пользователям контролировать не только условия, при которых монеты тратятся, но и их направление. Это является основой для многих потенциальных конструкций на Биткойн, от хранилищ и кошельков с ограниченной скоростью, до новых механизмов рынка комиссий, таких как платежные пулы, и менее привлекательных конструкций, таких как распределенная финансовая и MEV. Миллионы слов были израсходованы на обсуждение желательности ковенантов и того, что они сделали бы с сущностью Биткойн.
В этой статье я обойду эту дискуссию и просто утвержу, что ковенанты уже возможны на Биткойн; что мы в конечном итоге узнаем как они возможны (без больших вычислительных затрат или сомнительных криптографических предположений); и что наша дискуссия о новых расширениях для Биткойн не должна быть сформулирована так, будто отдельные изменения станут разделительной чертой между будущим Биткойна без ковенантов или с ковенантами.
История
За годы сложилась традиция находить креативные способы сделать нетривиальные вещи даже с ограниченными . Сеть Lightning была одним из примеров этого, как и меньше известные идеи, такие как вероятностные платежи или вознаграждения за хеш-функции при коллизиях. Темные краевые случаи, такие как ошибка SIGHASH_SINGLE или использование восстановления открытого ключа для получения "транзакционного хеша" в интерпретаторе, были замечены и исследованы, но никто так и не нашел способ сделать их полезными. Тем временем сам Биткойн стал более четко определенным, закрыв многие из этих дверей. Например, Segwit устранил ошибку SIGHASH_SINGLE и явно разделил программные данные от данных свидетелей; Taproot избавил от восстановления открытого ключа, которое обеспечивало гибкость за счет потенциального подрыва безопасности для адаптивных подписей или мультисигнатур.
Несмотря на эти изменения, хакерство продолжалось, как и вера среди твердолобых в то, что каким-то образом может быть найден какой-то крайний случай, который позволит поддерживать ковенант в Биткойне. В начале 2020-х годов две разработки произвели фурор. Одним из них было мое собственное открытие, что ковенанты, основанные на подписях, не умерли с восстановлением открытого ключа, и что, в частности, если бы у нас был хотя бы один отключенный код операции - OP_CAT - этого было бы достаточно для довольно эффективной конструкции ковенантов. Другим был BitVM, новый способ выполнения больших вычислений в нескольких транзакциях, который вдохновил огромное количество исследований в области базовых вычислений в рамках одной транзакции.
Эти два события вдохновили множество активности и волнения вокруг заветов, но также кристаллизовали наше мышление относительно фундаментальных ограничений . В частности, казалось, что без новых опкодов заветы могут быть невозможны, поскольку данные транзакций подавались только через 64-байтовые подписи и 32-байтовые открытые ключи, в то время как опкоды, поддерживающие BitVM, могли работать только с 4-байтовыми объектами. Этот разрыв был назван "Маленький " и "Большой ", и поиск моста между ними стал синонимом (по крайней мере, в моем представлении) поиска конструкции завета.
Функциональное шифрование и PIPEs
Также было замечено, что с немного мафии лунного математики, возможно будет осуществлять обеты полностью в пределах самих подписей, ни разу не покидая Big. Эту идею высказал Джереми Рубин в своей статье FE'd Up Covenants, в которой описывается, как реализовать обеты с использованием гипотетического криптографического примитива, называемого функциональное шифрование. Месяцы спустя Миша Коморов предложил конкретную схему под названием PIPEs, которая, кажется, превращает эту гипотетическую идею в реальность.
Это захватывающее развитие, хотя оно страдает от двух основных ограничений: одно из них заключается в том, что в него включается доверенная установка, что означает, что человек, создающий договор, может обойти его правила. (Это нормально для чего-то вроде хранилищ, в котором владелец монет может быть доверенным, чтобы не подорвать свою собственную безопасность; но это не подходит для чего-то вроде платежных пулов, где монеты в договоре не принадлежат создателю договора.) Другое ограничение заключается в том, что в него включается передовая криптография с неясными безопасными свойствами. Это последнее ограничение исчезнет с дополнительными исследованиями, но доверенная установка присуща функциональному подходу 01928374656574839201.
Коллайдер
Этот обзор приводит нас к текущей ситуации: мы хотели бы найти способ реализации кавенантов с использованием существующей формы Биткойна, и мы считаем, что путь к этому заключается в поиске некоего моста между "Большим" сигнатур транзакций и "Маленьким" произвольными вычислениями. Кажется, что никакие опкоды не могут непосредственно образовать этот мост (см. Приложение A в нашей статье для классификации всех опкодов по размеру входных и выходных данных). Мост, если он существует, будет неким сооружением, которое принимает один большой объект и демонстрирует, что он точно равен конкатенации нескольких маленьких объектов. Кажется, на основе нашей классификации опкодов, это невозможно.
Однако в криптографии мы часто ослабляем понятия, такие как "точно равный", вместо этого используем понятия, такие как "вычислительно неотличимый" или "статистически неотличимый", и тем самым избегаем невозможных результатов. Возможно, используя встроенные криптографические конструкции Big -- хеши и эллиптические кривые подписи -- и отражая их с помощью конструкций BitVM в Small, мы можем найти способ показать, что большой объект "вычислительно неотличим" от серии маленьких? С помощью Collider мы точно это сделали.
Что это означает? Ну, вспомним функцию хеш-коллизий награда, о которой мы упоминали ранее. Предпосылка этой награды заключается в том, что любой, кто может "столкнуть" функцию хеширования, предоставив два входных значения, которые имеют одинаковый выход хеша, может доказать в Big, что он это сделал, и таким образом заявить награду. Поскольку пространство входных данных функции хеширования намного больше (все байтовые строки размером до 520 байт) по сравнению с пространством выходных данных (байтовые строки размером ровно 32 байта), математически говоря, должно быть много таких коллизий. И тем не менее, за исключением SHA1, никто не нашел более быстрого способа найти эти коллизии, чем просто вызывать функцию хеширования снова и снова и проверять, совпадает ли результат с результатом предыдущей попытки.
Это означает, что в среднем для 160-битной функции хеширования, такой как SHA1 или RIPEMD160, пользователю потребуется как минимум 2^80 работы, или миллион миллионов миллионов миллионов итераций, чтобы найти коллизию. (В случае SHA1 существует сокращенный вариант, если пользователь способен использовать входные данные определенной формы; но наша конструкция запрещает это, поэтому для наших целей мы можем игнорировать эту атаку.) Это предполагает, что у пользователя есть фактически бесконечное количество памяти для работы; с более реалистичными предположениями нам нужно добавить еще один фактор порядка сто или около того.
Если мы представим, что SHA1 и RIPEMD160 можно вычислить так же эффективно, как Биткойн ASIC-майнеры вычисляют SHA256, то стоимость такого вычисления будет примерно такой же, как 200 блоков, или около 625 BTC (46 миллионов долларов). Это много денег, но у многих людей есть доступ к такой сумме, поэтому это возможно.
Чтобы найти тройное столкновение, или три входа, которые приводят к одному и тому же, потребуется около 2^110 работ, даже при очень щедрых предположениях о доступе к памяти. Чтобы получить это число, нам нужно добавить еще один фактор в 16 миллионов к нашим затратам - что приведет наш общий расход к более чем 700 триллионам долларов. Это также много денег, к которому никто не имеет доступа сегодня.
Суть нашего строительства заключается в следующем: чтобы доказать, что серия маленьких объектов эквивалентна одному большому объекту, мы сначала находим хеш-столкновение между нашим целевым объектом (который, как мы предполагаем, может быть пересоздан каким-то образом, иначе мы бы занимались "поиском второго предобраза" вместо поиска столкновения, что было бы намного сложнее) и "объектом тестирования эквивалентности". Эти объекты тестирования эквивалентности конструируются таким образом, что их легко можно манипулировать как в Big, так и в Small.
Затем наша конструкция проверяет, в Биткойн, что наш большой объект сталкивается с нашим эквивалентным тестером (используя точно такие же методы, как в хеш-столкновении награды) и что наша серия маленьких объектов сталкивается с тестером эквивалентности (используя сложные конструкции, частично заимствованные из проекта BitVM и подробно описанные в статье). Если эти проверки пройдены, то либо наши маленькие и большие объекты были одинаковыми, либо пользователь нашел тройное столкновение: два разных объекта, которые оба сталкиваются с тестером. По нашему рассуждению, это невозможно.
Заключение
Соединение Small и Big - самая сложная часть нашего договора. Чтобы перейти от этого моста к фактическому договору, требуется еще несколько шагов, которые сравнительно легкие. В частности, договор сначала просит пользователя подписать транзакцию с использованием специального "ключа-генератора", который мы можем проверить с помощью операции OP_CHECKSIG. С помощью моста мы разбиваем эту подпись на 4-байтовые фрагменты. Затем мы проверяем, что ее nonce также был равен ключу-генератору, что легко сделать, как только подпись была разделена. Наконец, мы используем техники из трюка Шнорра для извлечения данных транзакции из подписи, которые затем можно ограничить любым способом, который хочет договор.
Есть еще несколько вещей, которые мы можем сделать: Приложение C описывает конструкцию кольцевой подписи, которая позволила бы монетам быть подписанными одним из набора открытых ключей без раскрытия того, который был использован. В этом случае мы используем мост для разбивки открытого ключа, а не подписи. Это дает нам значительное улучшение эффективности по сравнению с конструкцией Covenant по техническим причинам, связанным с Taproot и подробно описанными в статье.
Финальное применение, на которое я хочу привлечь внимание, кратко обсуждается в разделе 7.2 статьи, заключается в том, что мы можем использовать наше строительство завета, чтобы извлечь хеш транзакции из подписи Шнорра, а затем просто повторно подписать хеш с использованием подписи Лампорта.
Зачем бы нам это делать? Как указано в вышеуказанной ссылке, подписание подписи Лампорта таким образом делает ее квантово-стойкой подписью на данных транзакции; если бы этот способ был единственным способом подписываться на некоторые монеты, они были бы защищены от кражи квантовым компьютером.
Конечно, поскольку нашему строительству требуется использовать десятки миллионов долларов, никто не сделал бы это строительство единственным способом подписания своих монет. Но ничто не мешает кому-то добавить это строительство к своим монетам, в дополнение к их существующим не квантово-стойким методам траты.
Затем, если бы мы проснулись завтра и обнаружили, что существуют дешевые квантовые компьютеры, способные взломать подписи Биткойна, мы могли бы предложить экстренный мягкий форк, который отключил бы все эллиптические кривые подписи, включая как использование ключей Taproot, так и операцию OP_CHECKSIG. Это фактически заморозило бы монеты каждого; но если альтернативой было то, что монеты каждого могут быть свободно украдены, то, возможно, это не имело бы никакого значения. Если этот мягкий форк, отключающий подписи, позволял бы операцию OP_CHECKSIG при вызове с ключом генератора (такие подписи все равно не обеспечивают безопасность и полезны только в качестве строительных блоков для сложных конструкций, таких как наша), то пользователи нашей конструкции на основе подписей Лампорта могли бы продолжать свободно тратить свои монеты, не боясь конфискации или кражи.
Конечно, им придется потратить десятки миллионов долларов на это, но это гораздо лучше, чем "невозможно"! Мы ожидаем и надеемся, что эта стоимость Падение значительно, поскольку люди основываются на наших исследованиях.
Это гостевой пост Эндрю Поэлстры. Мнения, выраженные в нем, полностью отражают их собственные взгляды и не обязательно отражают точку зрения BTC Inc или журнала Биткойн.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Collider_: $50M Биткойн Договор без новых опкодов
За последний год или два было представлено несколько предложений о предложении договорных дополнений к Биткойну, всегда существовало подозрение среди экспертов, что договоры могут быть возможны без каких-либо дополнений. Доказательство этого появилось в двух формах: расширение репертуара ранее считавшихся невозможными вычислений в (выражающееся в проекте BitVM по реализации каждой операции RISC-V) и серия "почти-удачных" случаев, когда разработчики Биткойна нашли способы, которые были бы возможны для договоров, если бы не некая неизвестная историческая особенность .
Итан Хайльман, Авиху Леви, Виктор Коболов и я разработали схему, которая доказывает, что эта подозрительность была оправдана. Наша схема, Collider*, позволяет заключать договоры на Биткойн уже сегодня, при довольно разумных криптографических предположениях и, вероятно, стоимостью около 50 миллионов долларов за транзакцию (плюс некоторые затраты на оборудование и НИОКР).*
Несмотря на экстравагантные затраты на использование Collider, его настройка очень дешева, и, используя обычный механизм расходов, с использованием Taproot для их разделения, вы возможно, сможете сохранить свои монеты в случае появления квантового компьютера, который внезапно появится и взорвется.
Без сомнения, многие читатели, прочитав эти утверждения, поднимают бровь к небу. К моменту, когда вы закончите чтение этой статьи, вторая будет так же высоко.
Завещания
Контекст этого обсуждения, для тех, кто не знаком, заключается в том, что Биткойн имеет встроенный язык программирования, называемый Биткойн, который используется для авторизации расходов монет. В самые ранние дни содержал богатый набор арифметических операций, которые можно было использовать для реализации произвольных вычислений. Но летом 2010 года Сатоши отключил многие из них, чтобы устранить серию серьезных ошибок. (Возвращение к пред-2010 версии - это цель проекта Великого Восстановления; OP_CAT - менее амбициозное предложение в том же направлении.) Идея ковенантов - транзакций, которые используют, чтобы контролировать количество и направление своих монет - появилась только через несколько лет, а осознание того, что эти операции были бы достаточны для реализации ковенантов, пришло еще позже. К тому моменту сообщество было слишком большим и осторожным, чтобы просто «включить» старые операции таким же образом, как они были отключены.
Ковенанты - это гипотетические конструкции, которые позволили бы пользователям контролировать не только условия, при которых монеты тратятся, но и их направление. Это является основой для многих потенциальных конструкций на Биткойн, от хранилищ и кошельков с ограниченной скоростью, до новых механизмов рынка комиссий, таких как платежные пулы, и менее привлекательных конструкций, таких как распределенная финансовая и MEV. Миллионы слов были израсходованы на обсуждение желательности ковенантов и того, что они сделали бы с сущностью Биткойн.
В этой статье я обойду эту дискуссию и просто утвержу, что ковенанты уже возможны на Биткойн; что мы в конечном итоге узнаем как они возможны (без больших вычислительных затрат или сомнительных криптографических предположений); и что наша дискуссия о новых расширениях для Биткойн не должна быть сформулирована так, будто отдельные изменения станут разделительной чертой между будущим Биткойна без ковенантов или с ковенантами.
История
За годы сложилась традиция находить креативные способы сделать нетривиальные вещи даже с ограниченными . Сеть Lightning была одним из примеров этого, как и меньше известные идеи, такие как вероятностные платежи или вознаграждения за хеш-функции при коллизиях. Темные краевые случаи, такие как ошибка SIGHASH_SINGLE или использование восстановления открытого ключа для получения "транзакционного хеша" в интерпретаторе, были замечены и исследованы, но никто так и не нашел способ сделать их полезными. Тем временем сам Биткойн стал более четко определенным, закрыв многие из этих дверей. Например, Segwit устранил ошибку SIGHASH_SINGLE и явно разделил программные данные от данных свидетелей; Taproot избавил от восстановления открытого ключа, которое обеспечивало гибкость за счет потенциального подрыва безопасности для адаптивных подписей или мультисигнатур.
Несмотря на эти изменения, хакерство продолжалось, как и вера среди твердолобых в то, что каким-то образом может быть найден какой-то крайний случай, который позволит поддерживать ковенант в Биткойне. В начале 2020-х годов две разработки произвели фурор. Одним из них было мое собственное открытие, что ковенанты, основанные на подписях, не умерли с восстановлением открытого ключа, и что, в частности, если бы у нас был хотя бы один отключенный код операции - OP_CAT - этого было бы достаточно для довольно эффективной конструкции ковенантов. Другим был BitVM, новый способ выполнения больших вычислений в нескольких транзакциях, который вдохновил огромное количество исследований в области базовых вычислений в рамках одной транзакции.
Эти два события вдохновили множество активности и волнения вокруг заветов, но также кристаллизовали наше мышление относительно фундаментальных ограничений . В частности, казалось, что без новых опкодов заветы могут быть невозможны, поскольку данные транзакций подавались только через 64-байтовые подписи и 32-байтовые открытые ключи, в то время как опкоды, поддерживающие BitVM, могли работать только с 4-байтовыми объектами. Этот разрыв был назван "Маленький " и "Большой ", и поиск моста между ними стал синонимом (по крайней мере, в моем представлении) поиска конструкции завета.
Функциональное шифрование и PIPEs
Также было замечено, что с немного мафии лунного математики, возможно будет осуществлять обеты полностью в пределах самих подписей, ни разу не покидая Big. Эту идею высказал Джереми Рубин в своей статье FE'd Up Covenants, в которой описывается, как реализовать обеты с использованием гипотетического криптографического примитива, называемого функциональное шифрование. Месяцы спустя Миша Коморов предложил конкретную схему под названием PIPEs, которая, кажется, превращает эту гипотетическую идею в реальность.
Это захватывающее развитие, хотя оно страдает от двух основных ограничений: одно из них заключается в том, что в него включается доверенная установка, что означает, что человек, создающий договор, может обойти его правила. (Это нормально для чего-то вроде хранилищ, в котором владелец монет может быть доверенным, чтобы не подорвать свою собственную безопасность; но это не подходит для чего-то вроде платежных пулов, где монеты в договоре не принадлежат создателю договора.) Другое ограничение заключается в том, что в него включается передовая криптография с неясными безопасными свойствами. Это последнее ограничение исчезнет с дополнительными исследованиями, но доверенная установка присуща функциональному подходу 01928374656574839201.
Коллайдер
Этот обзор приводит нас к текущей ситуации: мы хотели бы найти способ реализации кавенантов с использованием существующей формы Биткойна, и мы считаем, что путь к этому заключается в поиске некоего моста между "Большим" сигнатур транзакций и "Маленьким" произвольными вычислениями. Кажется, что никакие опкоды не могут непосредственно образовать этот мост (см. Приложение A в нашей статье для классификации всех опкодов по размеру входных и выходных данных). Мост, если он существует, будет неким сооружением, которое принимает один большой объект и демонстрирует, что он точно равен конкатенации нескольких маленьких объектов. Кажется, на основе нашей классификации опкодов, это невозможно.
Однако в криптографии мы часто ослабляем понятия, такие как "точно равный", вместо этого используем понятия, такие как "вычислительно неотличимый" или "статистически неотличимый", и тем самым избегаем невозможных результатов. Возможно, используя встроенные криптографические конструкции Big -- хеши и эллиптические кривые подписи -- и отражая их с помощью конструкций BitVM в Small, мы можем найти способ показать, что большой объект "вычислительно неотличим" от серии маленьких? С помощью Collider мы точно это сделали.
Что это означает? Ну, вспомним функцию хеш-коллизий награда, о которой мы упоминали ранее. Предпосылка этой награды заключается в том, что любой, кто может "столкнуть" функцию хеширования, предоставив два входных значения, которые имеют одинаковый выход хеша, может доказать в Big, что он это сделал, и таким образом заявить награду. Поскольку пространство входных данных функции хеширования намного больше (все байтовые строки размером до 520 байт) по сравнению с пространством выходных данных (байтовые строки размером ровно 32 байта), математически говоря, должно быть много таких коллизий. И тем не менее, за исключением SHA1, никто не нашел более быстрого способа найти эти коллизии, чем просто вызывать функцию хеширования снова и снова и проверять, совпадает ли результат с результатом предыдущей попытки.
Это означает, что в среднем для 160-битной функции хеширования, такой как SHA1 или RIPEMD160, пользователю потребуется как минимум 2^80 работы, или миллион миллионов миллионов миллионов итераций, чтобы найти коллизию. (В случае SHA1 существует сокращенный вариант, если пользователь способен использовать входные данные определенной формы; но наша конструкция запрещает это, поэтому для наших целей мы можем игнорировать эту атаку.) Это предполагает, что у пользователя есть фактически бесконечное количество памяти для работы; с более реалистичными предположениями нам нужно добавить еще один фактор порядка сто или около того.
Если мы представим, что SHA1 и RIPEMD160 можно вычислить так же эффективно, как Биткойн ASIC-майнеры вычисляют SHA256, то стоимость такого вычисления будет примерно такой же, как 200 блоков, или около 625 BTC (46 миллионов долларов). Это много денег, но у многих людей есть доступ к такой сумме, поэтому это возможно.
Чтобы найти тройное столкновение, или три входа, которые приводят к одному и тому же, потребуется около 2^110 работ, даже при очень щедрых предположениях о доступе к памяти. Чтобы получить это число, нам нужно добавить еще один фактор в 16 миллионов к нашим затратам - что приведет наш общий расход к более чем 700 триллионам долларов. Это также много денег, к которому никто не имеет доступа сегодня.
Суть нашего строительства заключается в следующем: чтобы доказать, что серия маленьких объектов эквивалентна одному большому объекту, мы сначала находим хеш-столкновение между нашим целевым объектом (который, как мы предполагаем, может быть пересоздан каким-то образом, иначе мы бы занимались "поиском второго предобраза" вместо поиска столкновения, что было бы намного сложнее) и "объектом тестирования эквивалентности". Эти объекты тестирования эквивалентности конструируются таким образом, что их легко можно манипулировать как в Big, так и в Small.
Затем наша конструкция проверяет, в Биткойн, что наш большой объект сталкивается с нашим эквивалентным тестером (используя точно такие же методы, как в хеш-столкновении награды) и что наша серия маленьких объектов сталкивается с тестером эквивалентности (используя сложные конструкции, частично заимствованные из проекта BitVM и подробно описанные в статье). Если эти проверки пройдены, то либо наши маленькие и большие объекты были одинаковыми, либо пользователь нашел тройное столкновение: два разных объекта, которые оба сталкиваются с тестером. По нашему рассуждению, это невозможно.
Заключение
Соединение Small и Big - самая сложная часть нашего договора. Чтобы перейти от этого моста к фактическому договору, требуется еще несколько шагов, которые сравнительно легкие. В частности, договор сначала просит пользователя подписать транзакцию с использованием специального "ключа-генератора", который мы можем проверить с помощью операции OP_CHECKSIG. С помощью моста мы разбиваем эту подпись на 4-байтовые фрагменты. Затем мы проверяем, что ее nonce также был равен ключу-генератору, что легко сделать, как только подпись была разделена. Наконец, мы используем техники из трюка Шнорра для извлечения данных транзакции из подписи, которые затем можно ограничить любым способом, который хочет договор.
Есть еще несколько вещей, которые мы можем сделать: Приложение C описывает конструкцию кольцевой подписи, которая позволила бы монетам быть подписанными одним из набора открытых ключей без раскрытия того, который был использован. В этом случае мы используем мост для разбивки открытого ключа, а не подписи. Это дает нам значительное улучшение эффективности по сравнению с конструкцией Covenant по техническим причинам, связанным с Taproot и подробно описанными в статье.
Финальное применение, на которое я хочу привлечь внимание, кратко обсуждается в разделе 7.2 статьи, заключается в том, что мы можем использовать наше строительство завета, чтобы извлечь хеш транзакции из подписи Шнорра, а затем просто повторно подписать хеш с использованием подписи Лампорта.
Зачем бы нам это делать? Как указано в вышеуказанной ссылке, подписание подписи Лампорта таким образом делает ее квантово-стойкой подписью на данных транзакции; если бы этот способ был единственным способом подписываться на некоторые монеты, они были бы защищены от кражи квантовым компьютером.
Конечно, поскольку нашему строительству требуется использовать десятки миллионов долларов, никто не сделал бы это строительство единственным способом подписания своих монет. Но ничто не мешает кому-то добавить это строительство к своим монетам, в дополнение к их существующим не квантово-стойким методам траты.
Затем, если бы мы проснулись завтра и обнаружили, что существуют дешевые квантовые компьютеры, способные взломать подписи Биткойна, мы могли бы предложить экстренный мягкий форк, который отключил бы все эллиптические кривые подписи, включая как использование ключей Taproot, так и операцию OP_CHECKSIG. Это фактически заморозило бы монеты каждого; но если альтернативой было то, что монеты каждого могут быть свободно украдены, то, возможно, это не имело бы никакого значения. Если этот мягкий форк, отключающий подписи, позволял бы операцию OP_CHECKSIG при вызове с ключом генератора (такие подписи все равно не обеспечивают безопасность и полезны только в качестве строительных блоков для сложных конструкций, таких как наша), то пользователи нашей конструкции на основе подписей Лампорта могли бы продолжать свободно тратить свои монеты, не боясь конфискации или кражи.
Конечно, им придется потратить десятки миллионов долларов на это, но это гораздо лучше, чем "невозможно"! Мы ожидаем и надеемся, что эта стоимость Падение значительно, поскольку люди основываются на наших исследованиях.
Это гостевой пост Эндрю Поэлстры. Мнения, выраженные в нем, полностью отражают их собственные взгляды и не обязательно отражают точку зрения BTC Inc или журнала Биткойн.