Про завернут внутрь P2SH, это вы про P2WSH реализацию?
Рассмотрим транзакцию.
Удобнее смотреть тут:
https://www.smartbit.com.au/tx/06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643там в верхнем-правом углу кнопичка со стрелочками которая разворачивает всё.
Почему первый элемент txinwitness пустой?
О, это "жук в янтаре".
На заре существования биткойна когда реализовывали OP_CHECKMULTISIG
сделали багу, что эта операция брала из стека на один элемент больше чем
того требовалось. Исправлять уже было нельзя, так как это хард-форк и сплит
сети. Поэтому сперва добавляли "что-нибудь любое", потом договорились, что
всегда этот ненужный элемент будет "пусто"
Дальше идут две подписи для каждого из ключей (в данном случае мультиподпись из 2-х ключей)
И вконце и дет pubKeyScript который формируется как MultiSigMOfN
Верно?
Угу. Верно.
Логика проверки такая (я на пальцах объясняю, не особо заморачиваясь):
1) scriptPubKey у транзакции
https://www.smartbit.com.au/tx/d91ed6680ad4cef0201a5019c09eaafaa2091be56a767d7d8015d3f471b505e1OP_HASH160 90211ae4ccee5a308b2ad45481cded4a011aab96 OP_EQUAL2) scriptSig у
https://www.smartbit.com.au/tx/06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c6430020434ba0752213a5551c8a8f034442076cae04085cda17015eec248017a2c08486
то есть в сумме получается
а) положить на стек 0020434ba0752...
б) взять со стека и проделать хэш-функцию, результат потожить в стек
в) положить в стек 90211ae4cce...
г) взять два элемента со стека, сравнить их, в случае успеха положить 1, иначе 0
Это мы оригинальный концепт рассмотрели. Там всё стыкуется и транзакция валидна
Но. Согласно BIP-16 надо теперь полученную 1 из стека убрать, и исполнить
последний элемент scriptSig
OP_0 434ba0752213a5551c8a8f034442076cae04085cda17015eec248017a2c08486После его исполнения на стеке два элемента: ноль и вот эта херотень 434ba0752213a5...
По правилам BIP-16 транзакция тоже валидна
Но. Если на стеке два элемента, один из которых ноль, а второй (хотя он первый считая с вершины)
это 32-байтовое число - это сегвит v0.
Тогда берем сегвит-данные, проверяем что хэш (не помню какой - вроде просто SHA256) от последнего
элемента будет именно таким как надо. Все элементы сегвит кроме последнего кладем по порядку на стек
а последний исполняем
Последний элемент это скрипт
OP_2 03b4d8d05ac62e0427357286b412793da1d3e5f731a6251beaa7983de3cf56dbc8 022401777940919353fc3c586799807fc5baddd591fcf6c6629c35a4e354357466 02ec3ffe1bd397fae6c74b1c366a8f3d750a8b1e86c0822dea495820b32447333e OP_3 OP_CHECKMULTISIGИ к моменту его выполнения на стеке лежит элемент-пустышка и две сигнатуры
ну дальше все как обычно
а) кладем 2
б) кладем три публичных ключа
в) кладем 3
г) CHECKMULTISIG вытаскивает из стека "3", потом вытаскивает три публичных ключа, потом
вытаскивает "2", потом вытаскивае две сигнатуры, потом из-за ошибки вытаскивает (но не использует
в дальнейшем) пустышку, потом проверяет чтобы две сигнатуры подходили бы к каким-то
из трех пубкеев и в случае успеха кладет в стек "1" (ну а в случае неуспеха 0, но раз транзакция
в блоке - значит все правильно)