В ходе обсуждений разработчики Биткоина договорились о дате выпуска и графике активации для обновления и подписей Шнорра. Однако заинтересованные стороны все еще обсуждают лучший метод координации для активации крупнейшего обновления Биткоина со времен SegWit.
Согласно общедоступной дискуссии в IRC, код для полностью подготовленного обновления Taproot будет развернут в период с 17 марта по 31 марта или, в случае возникновения проблем, в апреле. Но фактическая активация не начнется до июля.
Если все пойдет по плану, то «экономическое большинство» Биткоина, майнеры и операторы узлов, смогут обновиться в течение двух недель после начала сигнального периода. В августе 2022 года период активации Taproot истечет. Если майнинговые пулы, представляющие более 90% хешрейта Биткоина, поддержат Taproot до истечения этого срока, то обновление Taproot будет активировано. Оставшееся «экономическое меньшинство» сможет обновиться позднее.
Однако разработчики продолжают обсуждать вариант развития событий, при котором большинство пулов не сигнализируют о поддержке обновления.
Механизмы активации
В отличие от централизованных сетей, где операторы могут запускать обновления в любое время и по своему усмотрению, сеть Биткоина децентрализована — обновления могут быть активированы только после достижения консенсуса между разработчиками, майнерами, компаниями и опытными пользователями Биткоина.
Обновления в области конфиденциальности и масштабирования Taproot и подписи Шнорра были добавлены в Bitcoin Core в октябре 2020 года. Taproot дополняет подписи Шнорра и предлагает новую версию выходов транзакций и новые возможности определения условий траты BTC пользователями.
В некоторых случаях Taproot даже может помочь восстановить доступ к потерянным монетам. Подписи Шнорра и Taproot полезны для пользователей со сложной политикой расходов, которые обычно контролируют крупные суммы, например, криптовалютных бирж. Taproot — это софтфорк, то есть изменение, совместимое с предыдущими версиями протокола, в отличие от хардфорка, где новые и старые наборы правил несовместимы.
Главный вопрос в активации Taproot заключается в том, следует ли предоставить операторам узлов возможность принудительно активировать обновление, если подавляющее большинство майнеров не поддержит его до истечения установленного срока. Это позволит операторам узлов отклонять блоки от майнеров, которые не поддерживают обновление.
Другой вариант - вообще не включать эту функцию. Эти варианты предложения по улучшению Биткоина (BIP) для принудительного или не принудительного обновления называются соответственно BIP8 (true) и BIP8 (false), также известные как LOT = true и LOT = false.
LOT - это сокращение от lockinontime, функции, которая определяет, будет ли Taproot заблокирован, если общесетевая активация не будет достигнута при достижении timeoutheight. Параметр (true) автоматически требует обновления по истечении периода активации, а параметр (false) позволяет полностью отказаться от него.
Противники BIP8 (true) говорят, что эта агрессивная мера не оправдана, потому что Taproot вряд ли будет отвергнут сообществом. По словам разработчика Bitcoin Core Эндрю Чоу (Andrew Chow) и опросу майнеров относительно активации Taproot, «сообщество уже решило активировать обновление, так что нет необходимости в LOT = true. Майнеры - часть сообщества». Напомним, что еще в прошлом ноябре поддержка обновления Taproot майнинговыми пулами достигла 54%.
Taproot и разветвление цепочки
Сторонники BIP8 (true) считают, что это необходимая функция для координации обновления, которое в случае проблем во время активации может разделить Биткоин на несовместимые версии.
«LOT = true не разветвляет цепочку. Оно снижает вероятность этого», - сказал в чате главный сторонник BIP8 (true) Люк Дашир (Luke Dashjr).
Точку зрения Дашира поддерживают и другие разработчики, например, hsjoberg, который отметил: «LOT = true гарантирует, что обновленные узлы поддерживают работу конкретной цепочки». Значит операторы узлов потребуют, чтобы версия Биткоина с Taproot была «реальной» цепочкой. Теоретически это поможет избежать разветвления и способствует достижению консенсуса между участниками.
Разработчик brg444 написал, что «если сработает LOT = true, произойдет разделение сети». Но это возможно только в том случае, если бы прошла принудительная активация. Brg444 отмечает, что это маловероятно, поскольку угрозы разветвления сети было бы достаточно, чтобы напугать майнеров и заставить их активировать обновление до того, как произойдет принудительная активация.
Призрак SegWit
Другие разработчики считают, что применение тактики запугивания – не лучший вариант.
«Мне кажется, майнеры до сих пор страдают от посттравматического стрессового расстройства, вызванного активацией SegWit... Они превентивно занимают оборонительную позицию, казалось бы, без всякой причины. Возможно, они боятся повторения прошлых событий, которые сейчас имеют низкую вероятность», - написал технический директор Lightning Labs Олаолува Осунтокун (Olaoluwa Osuntokun), имея в виду майнеров, изначально выступавших против активации SegWit.
Если примерно через полгода после начала активации майнеры не сигнализируют поддержку Taproot, то LOT=true может быть закодировано постфактум для принудительного обновления. Тем не менее, это добавило бы еще один шаг к процессу, и внесение этого изменения постфактум было бы более обременительным, чем просто его включение в первоначальную версию кода. Однако некоторые разработчики считают, что это более разумное решение.
«LOT = true создает впечатление, будто разработчики навязывают сообществу изменения. Хотя это и не так, выглядит это не очень хорошо. Учитывая, что вряд ли возникнут какие-либо проблемы с активацией, я бы предпочел LOT = false, чтобы избежать этой ситуации», - написал Чоу.
Последняя встреча для обсуждения Taproot показала, что большинство разработчиков поддерживают LOT = false. В дискуссии участвовало всего около 100 человек, и многие по-прежнему высказывались за LOT = true. Однако, как отметил разработчик Darosoir, «мы не можем реально измерить «консенсус сообщества».
Согласно плану активации Taproot, 26 участников последней встречи высказались за LOT = false, а 19 - за LOT = true. Остальные сохранили нейтралитет и указали, что их устроит любой вариант. При этом некоторые разработчики заявили о необходимости свести к минимуму сложность процесса, чтобы получить более полное мнение от других участников сообщества.
По сути, перед началом развертывания кода в марте разработчиком осталось ответить только на один вопрос – включать ли параметр принудительной активации в первоначальный код.
