Расход по ключевому пути

Выход Taproot можно опустошить, подписав его ключом или раскрыв зафиксированный скрипт, и ключевой путь представляет собой тихий вариант. BIP-341 устанавливает, что этот свидетель состоит ровно из одного элемента, 64-байтовой подписи Schnorr при sighash по умолчанию, поэтому весь вход занимает 230 единиц веса, или 57,5 vbytes. Для владельца общее хранилище и одиночный платеж тогда выглядят ончейн одинаково.

Как это работает

Расход по ключевому пути подписывается для ключа выхода, который не является ничьим выбранным ключом: BIP-341 строит его как Q = P + int(t)G, где P является внутренним публичным ключом, а t представляет собой хеш с тегом от P вместе с корнем Меркла дерева скриптов.

Поэтому подпись означает применение того же сдвига к приватной стороне. Эталонная процедура сначала меняет знак секретного ключа, если внутренняя точка имеет нечетную координату y, поскольку подстройки taproot применяются к ключам только с координатой x длиной 32 байта, затем прибавляет t по модулю порядка кривой. Результат подписывается по BIP-340 и попадает в стек свидетеля сам по себе.

Проверка сначала сводится к подсчету элементов и только потом становится криптографической. Узел читает 32 байта программы свидетеля, сразу отклоняет, если стек свидетеля пуст, и отбрасывает последний элемент как annex, когда элементов два или больше и этот элемент начинается с 0x50. Если остается ровно один элемент, расход является расходом по ключевому пути, и этот элемент должен проверяться как подпись BIP-340 относительно ключа выхода. Ничто в этой процедуре не говорит узлу, фиксировалось ли когда-либо дерево скриптов.

Подпись занимает 64 байта, когда подразумевается SIGHASH_DEFAULT со значением 0x00, что покрывает всю транзакцию. Она вырастает до 65 байт, когда добавляется другой байт sighash, и подпись длиной 65 байт с 0x00 в этой последней позиции отклоняется намеренно: разрешить ее означало бы позволить майнеру или любому ретранслирующему узлу дополнить подпись в 64 байта до 65, изменив wtxid и ставку комиссии, которую рассчитывал отправитель.

Подпись покрывает не более 206 байт сообщения. Она фиксирует версию транзакции и locktime, хеши outpoint, суммы, предыдущего scriptPubKey и порядкового номера каждого входа, а также выходы.

Из этого следует арифметика размера. Согласно BIP-141, вес транзакции равен базовому размеру, умноженному на три, плюс полный размер, а виртуальный размер является этим весом, деленным на четыре, с округлением вверх для целой транзакции. Вход Taproot добавляет 41 байт базы (outpoint длиной 36 байт, один байт длины для пустого scriptSig, четырехбайтовый порядковый номер) и 66 байт свидетеля (счетчик стека, префикс длины, подпись), что дает 41 умножить на 3 плюс 107, или 230 единиц веса, и значит 57,5 vbytes.

Одна рекомендация в BIP-341 застает авторов кошельков врасплох. Выход вообще без скриптов все равно должен фиксировать подстройку, вычисленную как хеш с тегом от одного внутреннего ключа, а не публиковать внутренний ключ без изменений. Спецификация объясняет почему: когда две стороны складывают свои ключи в общий ключ выхода, одна из них может тихо добавить подстройку, скрывающую путь скрипта, который доступен для расходования только ей, а другая никак не может это заметить.

Почему это важно при покупке биткоина

Сообщение подписи Taproot является причиной, по которой аппаратный кошелек может вычислить вашу комиссию, не доверяя компьютеру, к которому он подключен.

По BIP-143, правилам версии 0 SegWit, сообщение фиксировало сумму, которую расходует подписываемый вход, и ничего больше. Устройство, подписывающее один вход транзакции с тремя входами, должно было получать две другие суммы и не могло их проверить, и это та лазейка, которой пользуется скомпрометированный хост, чтобы вы подписали гораздо большие комиссии, чем показывал экран. BIP-341 фиксирует суммы всех входов, которые расходует транзакция, и все их предыдущие scriptPubKey, поэтому подписывающее устройство может просуммировать их само. Это обновление охватывает и расходы по пути скрипта, но ключевой путь является тем, где с ним встретится большинство владельцев устройств из наших 41 обзора кошельков.

Ваш кошелек должен уметь выводить ключи, прежде чем что-либо из этого применится, и в этих обзорах картина неравномерна. KeepKey добавил поддержку выходов Taproot в прошивке 7.10.0 в феврале 2025 года. Собственное объявление MetaMask по-прежнему указывает Taproot как то, что появится позже, поэтому он не может дать вам адрес bc1p для получения, что бы ни делала остальная часть его поддержки биткоина.

Ключевой путь выигрывает по комиссии на небольшую величину на каждый вход, который накапливается в направлении, в котором покупает большинство читателей. Подписанный вход P2WPKH из собственного тестового вектора BIP-143 несет подпись длиной 71 байт и ключ длиной 33 байта, 107 байт свидетеля после учета счетчика стека и префиксов длины, что составляет 271 единица веса, или 67,75 vbytes. Вход по ключевому пути экономит 10,25 vbytes по сравнению с этим, поэтому тот, кто накопил 30 отдельных небольших покупок и позже объединяет их, срезает около 307 vbytes с этой одной транзакции.

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

Разбор taproot_sign_key

taproot_sign_key является эталонной процедурой, которую BIP-341 публикует для создания именно этого свидетеля, и вся она занимает девять строк Python.

Она принимает дерево скриптов, внутренний секретный ключ, тип sighash и вспомогательную случайность, которую требует BIP-340. Когда дерево скриптов пусто, она задает вход подстройки как пустую строку байтов; в противном случае этот вход является корнем Меркла, который возвращает вспомогательная функция дерева. Она подстраивает внутренний секретный ключ этим значением, подписывает sighash, добавляет байт типа хеша только когда тип не равен нулю и возвращает список из одного элемента. Этот элемент является всем свидетелем.

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

Расход по ключевому пути vs P2TR

P2TR является типом выхода, а расход по ключевому пути представляет собой один из двух способов опустошить его. Выход остается выходом P2TR независимо от того, какой путь позже его опустошит. Различие важно, когда кто-то говорит вам, что адреса Taproot приватны: получение на один публикует ключ длиной 32 байта и ничего больше в любом случае, тогда как приватность, которую имеют в виду люди, наступает в момент расходования, и только если выбран ключевой путь.

Расход по ключевому пути vs MuSig2

MuSig2 является одним из способов создать подпись, которая нужна расходу по ключевому пути, а не требованием его. Единственный владелец, подписывающий одним ключом, совершает расход по ключевому пути каждый раз, когда платит, без какого-либо протокола агрегации. Эти два понятия путают, потому что агрегация представляет собой интересный случай: MuSig2 позволяет нескольким сторонам прийти к одному ключу и одной подписи, поэтому их расчет проходит по тому же пути и занимает те же 57,5 vbytes, что и у кого-то, кто платит за обед. Бывает и наоборот, поскольку агрегированный ключ может находиться внутри листа скрипта, где расходование его является расходом по пути скрипта, который случайно использует MuSig2.