Короткий ответ: выход Taproot можно потратить двумя способами. В key path достаточно действительной подписи для выходного ключа, поэтому транзакция не показывает, какие дополнительные условия могли быть заложены. В script path раскрываются использованный tapscript и доказательство его принадлежности дереву Taproot, после чего узлы Bitcoin проверяют это условие. Эти пути дают разные компромиссы между простотой, размером данных и приватностью.
Taproot не означает, что любой адрес автоматически использует смарт-контракт или скрывает все сведения о расходовании. Результат зависит от того, как кошелёк создал выход, какие ключи и скрипты включил и какой путь был выбран. Базовое сравнение форматов адресов приведено в материале о Legacy, SegWit и Taproot.
Что представляет собой выход Taproot
Выход P2TR содержит один публичный ключ, который выглядит как единая точка назначения. Концептуально он связывает внутренний ключ и, если владелец задал его, корень дерева скриптов. Дерево может содержать несколько листьев с разными условиями: например, обычную совместную подпись, резервный путь с задержкой или правило восстановления. Пока монета не потрачена, наблюдатель видит только Taproot-выход и не узнаёт структуру дерева.
Это отличается от старых схем, где часть условий становилась заметна прямо в скрипте блокировки либо полностью раскрывалась при трате. В Taproot корень дерева Merkle связывается с выходным ключом криптографическим преобразованием. Кошелёк должен сохранить параметры ключа и дерева: адрес сам по себе не резервирует политику. Практическую роль описания ключей и правил адреса объясняет руководство по Bitcoin descriptors.
Когда используется key path
При key path кошелёк формирует Schnorr-подпись для выходного ключа Taproot. В witness помещается подпись, а не список всех участников и условий. Такой расход может быть обычной подписью одного владельца, агрегированной подписью нескольких сторон или согласованным исполнением сложной политики. Консенсус Bitcoin проверяет подпись по правилам Taproot.
Если у выхода было дерево скриптов, расходование через key path не раскрывает сам факт его наличия. Совместное закрытие канала или мультиподписная договорённость могут выглядеть снаружи как расход с одним ключом. Но любая группа участников не получает пороговую схему автоматически: агрегация и координация подписей требуют совместимого протокола, безопасной генерации nonce и согласованной реализации. Разницу между скриптовой мультиподписью и агрегацией объясняет статья о multisig и MuSig2.
Key path обычно требует меньше данных в witness, чем раскрываемый скрипт с доказательством ветки. Это может уменьшить комиссионный вес, но точный размер зависит от подписи, annex, числа входов и других деталей. Нельзя считать Taproot всегда самым дешёвым вариантом без сравнения конкретных транзакций.
Что раскрывается при script path
Если нужную подпись нельзя получить или выбирается запасной сценарий, владелец может исполнить один лист дерева. В witness передаются аргументы скрипта, сам tapscript и control block. Контрольный блок содержит внутренний ключ и хеши соседних ветвей, достаточные для восстановления корня. Полное дерево при этом не публикуется: в блокчейне виден использованный лист и данные, подтверждающие его включение.
Скрипт проходит правила tapscript, включая проверку подписей и временных условий. Один лист может требовать подпись немедленно, другой – разрешать резервному участнику расход после определённого числа блоков. Script path показывает факт использования ветки, а также выбранное условие. Раскрытые адреса, задержки и структура witness иногда позволяют связать транзакцию с конкретной политикой, даже если остальные ветви остались скрыты.
Более глубокий лист Merkle-дерева требует передать больше хешей в control block. Поэтому глубина влияет на объём данных. Создатель кошелька может поместить вероятные сценарии ближе к корню, а редкие резервные пути глубже. Оптимизация размера не должна ухудшать понятность и восстановление кошелька из резервной копии.
Приватность и ограничения
Приватность Taproot условна. Повторное использование адреса, связанные входы, сумма, время и соседние транзакции могут выдать отношения между участниками. Key path не скрывает сам факт расхода или движение суммы. Script path раскрывает больше, но показывает выбранную ветку, а не обязательно всю политику. По одному P2TR-адресу нельзя определить конкретный кошелёк.
Нужно различать сокрытие политики и программируемость. Script path исполняет только операции и ограничения, поддерживаемые консенсусом Bitcoin. Taproot не добавляет автоматически произвольные правила для всех будущих транзакций. Кошелёк должен уметь построить, подписать и восстановить конкретную политику, а аппаратный подписант – показать, что именно он подтверждает.
При диагностике расхода сопоставьте тип выхода, witness, подписи и данные предыдущего UTXO. Для зависимых неподтверждённых транзакций может иметь значение передача связанных пакетов – этому посвящён материал о package relay в Bitcoin. А для схемы, где Bitcoin-залог связан с внешним набором участников, изучите обзор Bitcoin staking в Babylon.
Как сравнить два пути до использования
Уточните, кто может создать подпись key path и предусмотрен ли запасной script path. Проверьте ключи, сроки и аргументы каждого листа, место хранения descriptor и возможность восстановить всю Taproot-политику на другом устройстве. Спросите, нужно ли раскрывать условие для каждой операции или его можно выполнить совместной подписью.
На тестовой транзакции проверьте размер witness и данные, которые станут публичными после включения в блок. Не переводите средства на адрес, если не можете воспроизвести его из сохранённых параметров. Убедитесь, что кошелёк и координатор используют совместимую версию Taproot и одинаковое дерево. Выбор key path или script path – часть конструкции политики, а не переключатель приватности в обозревателе.
