Выпущено Bitcoin Core 24.0: вот что нового

Новая версия оригинального программного обеспечения Биткойн, запущенная Сатоши Накамото в 2009 году был выпущен.

Над Bitcoin Core 24.0 работали 112 разработчиков в течение примерно семи месяцев, чтобы внести ощутимые улучшения в кошелек Bitcoin Core, одноранговые (P2P) коммуникации, графический пользовательский интерфейс (GUI) и многое другое.

В этой статье рассматриваются некоторые из основных изменений.

Обновления кошелька

Начальная поддержка мини-скриптов

Bitcoin Core 24.0 представляет поддержку Miniscript, расширяя шш() выходной дескриптор. Хотя это первоначальная и рудиментарная интеграция, этот шаг прокладывает путь для развертывания более сложных сценариев в Биткойн более простым и безопасным способом.

Miniscript можно рассматривать как основу (или шаблон) для Биткойн-скрипт, родной язык программирования Биткойн. Биткойн-скрипт отвечает за включение всех функций программирования, доступных для Биткойн, включая, например, возможно, самую простую из них: определение того, кому разрешено тратить данную монету. Для каждой биткойн-транзакции отправитель запрашивает адрес получателя и с помощью этой информации создает сценарий, который блокирует отправляемые биткойны таким образом, чтобы только получатель мог их потратить. Хотя с помощью Bitcoin Script довольно легко создавать простые сценарии, такие как приведенные выше, чем сложнее сценарий, тем выше вероятность человеческой ошибки. Здесь в игру вступает Miniscript.

Miniscript позволяет писать подмножество биткойн-скриптов в структурированный путь. Помимо прочего, он позволяет выполнять анализ, компоновку и общую подпись, что позволяет разработчикам более безопасно писать расширенные сценарии. Другими словами, Miniscript «содержит» некоторые функциональные возможности предварительно настроенных биткойн-скриптов для ожидаемого шаблона поведения, ограничивая возможные риски, поскольку неожиданное поведение сводится к минимуму. На практике он предоставляет разработчикам «инструментарий», с которым они могут возиться и создавать продвинутые и сложные сценарии для биткойнов, вместо того, чтобы делать все это вручную с помощью биткойн-скриптов.

Начиная с Bitcoin Core 24.0, пользователи теперь могут создавать кошелек, содержащий скрипт Miniscript, создавать адреса для этого кошелька и пополнять их биткойнами. Однако расходы с этих адресов пока не поддерживаются кошельком Bitcoin Core, а это означает, что кошельки с поддержкой Miniscript в Bitcoin Core пока доступны только для просмотра.

Неизменяемые транзакции

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

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

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

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

Измените рандомизацию вывода, чтобы избежать отпечатков пальцев

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

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

Чтобы снизить вероятность того, что наблюдатель сможет выделить выходные данные сдачи и адреса пользователей кластера, Bitcoin Core теперь рандомизирует выходные значения сдачи.

Начиная с версии 24.0, кошелек Bitcoin Core будет выбирать случайное число между размером платежа и трехкратным размером платежа. Этот номер сообщит о выборе UTXO для расходов. Фактически это означает, что иногда алгоритм выбирает UTXO, значение которого ближе к платежу, а в других случаях он выбирает UTXO, значение которого ближе к этой верхней границе, равной трехкратной сумме платежа. Первый сценарий приведет к типичному сценарию сдачи сдачи ниже платежа, тогда как второй приведет к обратному результату — сдаче сдачи больше, чем оплата. Учитывая, что наблюдатель за блокчейном не может сказать, когда каждый сценарий происходит в данный момент времени, пользователь должен иметь возможность пользоваться более высокими гарантиями конфиденциальности.

Обновления для замены за плату

RBF предоставляет пользователям Биткойн дополнительные возможности всякий раз, когда они отправляют транзакцию в сеть. Часто пользователь не хочет переплачивать за комиссию майнера и поэтому может выбрать «золотую середину» между уплачиваемой комиссией и скоростью включения транзакции в блок. Но если значение комиссии, выбранное пользователем, слишком низкое или мемпул перегружен, для включения транзакции в блок может потребоваться слишком много времени (или она может вообще застрять в мемпуле). В таком случае RBF позволяет пользователю «увеличить» комиссию за транзакцию, что чаще всего позволяет ускорить расчет.

Однако на самом деле RBF не увеличивает комиссию. Что происходит в фоновом режиме, так это то, что программный клиент будет транслировать new транзакция с одинаковыми входами и большинством одинаковых выходов. (Некоторые выходные значения меняются; значение комиссии естественным образом изменится, чтобы отразить новый номер, и обычно эта разница вычитается из суммы, отправляемой на адрес для изменения.)

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

Bitcoin Core 24.0 представляет два обновления функциональности RBF.

Во-первых, теперь пользователи могут настраивать свои узлы для ретрансляции заменяемых транзакций. без применение флага RBF. Это можно сделать с помощью нового мемпулфуллрбф вариант. Он будет установлен на от по умолчанию, но те, кто заинтересован в его включении, могут включить его.

Во-вторых, RBF теперь установлен в качестве стандарта в кошельке Bitcoin Core. Транзакции теперь включаются в RBF по умолчанию, а -walletrbf Параметр запуска по умолчанию имеет значение true. Пользователи могут отказаться от RBF, изменив данную транзакцию в процессе ее построения или установив -walletrbf параметр запуска в false.

Миграция дескрипторного кошелька

Биткойн-ядро 23.0 сделал дескрипторные кошельки стандартом. Дескрипторы облегчают жизнь пользователя в резервном копировании своего кошелька и последующем восстановлении этой резервной копии в стандартном формате.

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

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

Теперь в Bitcoin Core 24.0 представлен новый инструмент для переноса устаревших кошельков в формат дескрипторного кошелька, позволяющий пользователям воспользоваться преимуществами этого нового стандарта для лучшей защиты своих драгоценных биткойнов. Хотя все еще экспериментальный, новый RPC (миграционный кошелек) был введен. Этот документ предоставляет более подробную информацию о его функциональности.

Изменения графического интерфейса

Графический интерфейс Bitcoin Core известен тем, что не обеспечивает того же уровня функциональности, которого могут достичь удаленные вызовы процедур (RPC) и инструменты командной строки. Биткойн 24.0 предпринимает некоторые шаги, чтобы немного изменить это.

В новейшей версии Bitcoin Core появился новый пункт меню в графическом интерфейсе, который позволяет пользователям восстанавливать кошелек из резервной копии, что упрощает восстановление резервных копий для нетехнических специалистов. Раньше эта опция существовала только в командной строке.

Еще один недостаток графического интерфейса по сравнению с интерфейсом RPC был связан с настройками клиента Bitcoin Core. Известный биткойн.conf файл является святым Граалем конфигурации Bitcoin Core, но опять же его можно было настроить в основном через командную строку. Существовала возможность настройки параметров в графическом интерфейсе, но предупреждение дало понять, что биткойн.conf имел приоритет над графическим интерфейсом в случае, если и файл, и графический интерфейс пытались установить данные для одной и той же конфигурации. Таким образом, хотя графический интерфейс предоставлял простую возможность изменения настроек, файл конфигурации по-прежнему оставался самым надежным способом настройки клиента Bitcoin Core.

Bitcoin Core 24.0 меняет это. Новое обновление объединяет страницу настроек графического интерфейса с биткойн.conf файл. Теперь, когда пользователь открывает настройки клиента в графическом интерфейсе, отображаемые настройки извлекаются из файла конфигурации. Точно так же изменения конфигурации, сделанные в графическом интерфейсе, теперь отражаются в биткойн.conf. (Стоит отметить, что связь здесь косвенная, потому что изменения в графическом интерфейсе на самом деле настроены на settings.json, файл, который имеет приоритет над биткойн.conf.)

Изменения в P2P-коммуникациях

Новая логика загрузки заголовков

Bitcoin Core 24.0 вносит изменения в то, как одноранговые узлы в сети догоняют вершину цепочки, либо потому, что они загружаются в первый раз, либо долгое время не подключались к сети Биткойн.

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

Хотя загрузка заголовков помогает сэкономить время и ресурсы, все же может произойти атака с исчерпанием ресурсов, когда злоумышленник рассылает спам партнеру миллионами поддельных заголовков блоков. Поскольку клиенту необходимо загрузить и сохранить заголовки на диске, достаточно большой объем данных может нанести вред оборудованию партнера.

Чтобы смягчить эту угрозу, Bitcoin Core представил концепцию контрольно-пропускные пункты много лет назад. Контрольные точки определяют, какие блоки должен присутствовать в цепочке, чтобы она была действительной. Однако это решение также представляет собой проблему, поскольку контрольные точки могут использоваться для эффективного отката самой длинной цепочки. Такая возможность в Биткойне нежелательна, поэтому пришлось придумать другое решение. Введите это новое обновление.

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

Спасибо Аарону ван Вирдуму за обратную связь.

Для получения более подробной информации и других изменений см. Bitcoin Core 24.0. выпуск. Чтобы загрузить Bitcoin Core 24.0, перейдите здесь. Подробности о Bitcoin Core 24.0 также объясняются в аудиозаписи в подкасте «Биткойн, объяснение». эпизод 65.