Глоссарий / Справочник разработчика
MSG_WITNESS_TX
- Что такое MSG_WITNESS_TX?
- Запрос транзакции с данными свидетеля, отправляемый как getdata, предписывает пиру вернуть указанную транзакцию с приложенными данными подписи, а не без них.
Определено в BIP-144.
Если запросить транзакцию по ее txid с MSG_WITNESS_TX, вернется версия с приложенными подписями. Bitcoin Core 0.21.0, выпущенный 14 января 2021 года, добавил трансляцию по wtxid и в основном заменил этот запрос на MSG_WTX, который запрашивает по хешу свидетеля. Для тех, кто отправляет биткоины, выигрыш в том, что измененная подпись больше не заставляет платеж исчезать из трансляции.
Как это работает
У каждой segwit-транзакции две идентичности, и MSG_WITNESS_TX существует потому, что пиру нужно сообщить, какую из них от него требуют.
Txid представляет собой двойной SHA-256 транзакции без ее свидетеля: версия, входы, выходы, locktime. Wtxid представляет собой тот же хеш, взятый по полной сериализации, включая байт маркера, байт флага и стеки свидетеля. Для транзакции, у которой свидетеля нет вовсе, эти два значения равны. Для coinbase-транзакции BIP141 определяет wtxid как 32 байта нуля, особый случай, который существует, чтобы корень дерева Меркла свидетелей имел что-то четко определенное, от чего можно отталкиваться.
Код запроса равен 0x40000001: тип транзакции 1 с добавленным сверху флагом свидетеля 0x40000000. Если отправить getdata с одним лишь типом 1, пир ответит байтами без данных свидетеля, которых достаточно, чтобы увидеть, куда ушли деньги, и которые бесполезны для проверки того, была ли трата разрешена.
Это разделение и покончило со старой проблемой пластичности. До segwit третья сторона могла перекодировать подпись, изменить txid и оставить отправителя в ожидании транзакции, которой под этим именем больше не существовало. Вынесение подписей за пределы txid закрыло эту дверь, и именно это сделало предварительно подписанные транзакции каналов Lightning надежными.
Затем BIP339 сделал следующий шаг. Пиры, которые отправляют сообщение wtxidrelay до verack, объявляют транзакции по wtxid с типом инвентаря 5, и Bitcoin Core делает это с версии 0.21.0. Выигрыш в кеше отклонений: узел, отказавший одному искаженному свидетелю, больше не отказывает честной копии той же транзакции, потому что у них разные wtxid. MSG_WITNESS_TX сохраняется для пиров, которые так и не согласовали трансляцию по wtxid, а на практике это означает программное обеспечение старше той версии.
Где это видно
Яснее всего увидеть txid и wtxid рядом можно в выводе собственных RPC-вызовов транзакций в Bitcoin Core.
Вызовите getrawtransaction с подробным выводом для любой segwit-траты и получите поле txid и поле hash. Они различаются. Hash является wtxid, и это различие представляет собой единственный видимый след данных свидетеля в остальном обычном объекте JSON. Обозреватели блоков индексируют по txid, поэтому именно это число нужно вставлять в строку поиска, проверяя, пришел ли ваш вывод.
На уровне сети getpeerinfo подсчитывает сообщения по типу, и запросы транзакций в этой разбивке на любом хорошо подключенном узле будут смешанными: MSG_WTX для современных пиров, MSG_WITNESS_TX для отстающих.
Ничего из этого покупатель не настраивает. Это важно косвенно. Когда биржа сообщает вам, что вывод был транслирован, а ваш кошелек не может его найти, полезный вопрос в том, достиг ли когда-либо пула памяти txid, который вам дали, а не в том, какую сериализацию обменивали пиры.
MSG_WITNESS_TX vs MSG_TX
MSG_TX называет ту же транзакцию и возвращает ее со всеми вырезанными подписями. Эту форму понимали узлы до segwit, и она по-прежнему циркулирует к пирам, которые никогда не объявляли NODE_WITNESS. Различие не косметическое: узел, получивший версию без данных свидетеля, может подтвердить структуру транзакции, но не может ее проверить, поэтому не может безопасно поместить ее в пул памяти или транслировать дальше как проверенную. Bitcoin Core не будет отправлять segwit-транзакцию пиру, который говорит только на старой форме.