PSBT v2

Анна и Ян хотят вместе оплатить один счёт. Каждый вносит часть средств и добавляет подпись на своём устройстве. Им нужно обменяться согласованным проектом, а не приватными ключами. Приватный ключ — это секретное число, с помощью которого кошелёк создаёт цифровую подпись, разрешающую расходование средств. PSBT служит рабочим конвертом с транзакцией и сопроводительными данными. Входы указывают на прежние суммы, которые тратятся; выходы определяют новые суммы и условия их последующего расходования. Исходный PSBT v0 хранит эту структуру в фиксированной глобальной неподписанной транзакции. В v2 входы и выходы можно добавлять постепенно по соответствующим правилам. Преимущество — совместная сборка, а не возможность произвольно переписать уже подписанное. [1] [2]

Анне не нужно читать каждое техническое поле. Но на доверенном подписывающем устройстве ей следует проверить настоящего получателя, сумму, комиссию и возможную сдачу, возвращаемую в её кошелёк. Последнюю деталь легко упустить: чужой выход нельзя принять за собственную сдачу. Устройство должно проверить сведения об UTXO, то есть ещё не потраченных выходах, и соответствие их условий тому, что подписывается. Путь выведения ключа описывает шаги, с помощью которых кошелёк получает конкретный ключ из своего главного ключа. Само указание этого пути не доказывает принадлежность средств. Подписывающее устройство также должно правильно обрабатывать SIGHASH — настройку, определяющую, какие части транзакции защищает подпись. Для подписания не требуется добавлять в передаваемый файл приватный ключ или Seed Phrase — слова резервной копии кошелька. [2] [4]

Заявленная поддержка PSBT в приложении или устройстве ещё не означает поддержки v2. Проверять нужно весь путь: создание, импорт, подписание и возврат результата между конкретными программами и устройствами. PSBT v0 и v2 не взаимозаменяемы напрямую. Преобразование в v0 требует собрать неподписанную транзакцию и привести поля к правилам этой версии; заменить число недостаточно. Taproot, более новый способ задания условий расходования выходов Bitcoin, тоже не тождественен v2. BIP 371 описывает соответствующие данные для подписи в обеих версиях PSBT. Небольшая проверка всего процесса подтверждает совместимость данной связки, а не правильность всех будущих платежей. [1] [3]

Версия файлового формата и версия транзакции Bitcoin означают разные вещи. В v2 поле PSBT_GLOBAL_VERSION должно содержать 2, а старое поле PSBT_GLOBAL_UNSIGNED_TX должно отсутствовать. Отдельное обязательное поле PSBT_GLOBAL_TX_VERSION задаёт версию самой транзакции. Количества входов и выходов также обязательны. Благодаря этому разделению данные находятся рядом с соответствующими элементами, и программе не нужно дополнительно искать их в общей структуре. Если создатель передаёт дальнейшую сборку другим участникам, BIP 370 требует подходящих флагов изменений и версии транзакции не ниже 2. Это рабочий формат, а не новые правила консенсуса сети. [1]

Каждому входу нужны TXID — идентификатор предыдущей транзакции — и индекс конкретного выхода, который из неё тратится. Одного TXID недостаточно: у транзакции может быть несколько выходов. Каждый новый выход содержит сумму в satoshi, наименьших единицах Bitcoin, и scriptPubKey — скрипт с условиями расходования. Добавление элемента должно также менять соответствующее глобальное количество. Необязательное поле sequence содержит ещё одно управляющее значение входа; если поля нет, используется 0xffffffff. Эти данные описывают сборку транзакции. Они не заменяют сведений о суммах и условиях расходования UTXO, необходимых устройству для безопасной оценки подписи и комиссии. [1]

Допустим, Яну нужно добавить ещё один вход. Программа не может считать это допустимым лишь потому, что у неё есть файл. В PSBT_GLOBAL_TX_MODIFIABLE бит 0 обозначает возможность изменения входов, а бит 1 — выходов. Бит 2 сигнализирует о подписи SIGHASH_SINGLE, связывающей вход с выходом на соответствующей позиции. Эта пара должна сохраняться и при вставке дополнительных элементов. Поэтому сборщик проверяет имеющиеся подписи и их ограничения. Флаги сообщают информацию взаимодействующим программам; они не обходят криптографическую подпись и не превращают недопустимое изменение в допустимое. [1]

Некоторые входы требуют дождаться определённой высоты блока или временной границы, прежде чем транзакцию можно будет использовать. Блок — это группа транзакций, записанная в общую историю сети; его высота указывает на положение в цепочке. Общее поле nLockTime должно соответствовать типу требований, совместимому со всеми входами. Берётся наибольшее требуемое значение этого типа; если возможны оба типа, предпочтение получает высота блока. Высоту и время нельзя просто сравнить как два обычных числа. Если ни у одного входа нет требований, используется глобальное запасное значение, а при его отсутствии — 0. Вход с несовместимым требованием добавлять нельзя. Если подписи уже существуют, новый вход также не должен менять рассчитанный nLockTime. Сами эти поля не гарантируют соблюдения всех правил временных блокировок. [1]

Каждая подпись ограничивает дальнейшие изменения. BIP 370 требует отключить изменения входов без SIGHASH_ANYONECANPAY и изменения выходов без SIGHASH_NONE; при SIGHASH_SINGLE отмечается пара, которую нужно сохранить. Эти названия обозначают разные области защиты подписью, а не переключатели для случайных экспериментов новичка. Когда все входы готовы, финализация собирает необходимые данные подписей, а экстрактор формирует из полей транзакцию в сетевом формате. Лишь её отправка позволяет узлам оценить транзакцию, а майнеру — включить её в блок. Поэтому Анна и Ян различают проект, подписанный результат и подтверждённый платёж: сама передача PSBT не является ни подписанием, ни подтверждением. [1] [2] [4]