Помогите разобраться с SegWit

[amaclin1]

Мы немного перепрыгнули BIP-16. Ладно.

Да. Это я на радостях))

Как я понял до BIP16 использовались
P2PK и P2PKH

BIP 16 подарил нам
P2SH
Что в свою очередь очен изменило архитектуру и добавило плюшки вроде MUTLISIG.

А сам SegWit уже в
P2WPK, P2WSH

Нет, немного не так.
Были P2PK и P2PKH и m-of-n MSIG - стандартные выходы
Но уже этот зоопарк из трех вариантов был излишним. Хотелось иметь один вариант, для простоты.
И это был BIP-16 то есть P2SH
Теперь по сути scriptPubkey заносился внутрь scriptSig и может быть практически любым.
А в scriptPubkey оставался только хэш этого скрипта.

Использование P2SH на 99% это мультисигнатурные транзакции
Но, повторюсь, там под капотом может лежать любой скрипт и изредка
встречаются редкие экземпляры.

Для совместимости P2PK и P2PKH и m-of-n MSIG оставили стандартными и доступными
к использованию, но m-of-n MSIG - он очень неудобный, чересчур много места занимает
в базе неизрасходованных выходов, поэтому в последних версиях клиента есть даже настройка
"не считать такой выход стандартным и не майнить его" - такое подталкивание юзеров к тому,
чтобы этим не пользовались.

Сегвит (версии v0) добавляет два стандартных выхода (не помню как называются)
и еще может быть завернут в P2SH

[1714116562]

1714116562

[1714116562]

1714116562

[1714116562]

1714116562

[1714116562]

1714116562

[1714116562]

1714116562

[Ninazu]

Сегвит (версии v0) добавляет два стандартных выхода (не помню как называются)
и еще может быть завернут в P2SH

Про завернут внутрь P2SH, это вы про P2WSH реализацию?
Рассмотрим транзакцию.
http://learnmeabitcoin.com/browser/transaction/json.php?txid=06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643

Почему первый элемент txinwitness пустой?
Дальше идут две подписи для каждого из ключей (в данном случае мультиподпись из 2-х ключей)
И вконце и дет pubKeyScript который формируется как MultiSigMOfN

Верно?

[amaclin1]

Про завернут внутрь P2SH, это вы про P2WSH реализацию?
Рассмотрим транзакцию.

Удобнее смотреть тут:
https://www.smartbit.com.au/tx/06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643
там в верхнем-правом углу кнопичка со стрелочками которая разворачивает всё.

Почему первый элемент txinwitness пустой?

О, это "жук в янтаре".
На заре существования биткойна когда реализовывали OP_CHECKMULTISIG
сделали багу, что эта операция брала из стека на один элемент больше чем
того требовалось. Исправлять уже было нельзя, так как это хард-форк и сплит
сети. Поэтому сперва добавляли "что-нибудь любое", потом договорились, что
всегда этот ненужный элемент будет "пусто"

Дальше идут две подписи для каждого из ключей (в данном случае мультиподпись из 2-х ключей)
И вконце и дет pubKeyScript который формируется как MultiSigMOfN
Верно?

Угу. Верно.
Логика проверки такая (я на пальцах объясняю, не особо заморачиваясь):
1) scriptPubKey у транзакции
https://www.smartbit.com.au/tx/d91ed6680ad4cef0201a5019c09eaafaa2091be56a767d7d8015d3f471b505e1
OP_HASH160 90211ae4ccee5a308b2ad45481cded4a011aab96 OP_EQUAL

2) scriptSig у https://www.smartbit.com.au/tx/06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643
0020434ba0752213a5551c8a8f034442076cae04085cda17015eec248017a2c08486

то есть в сумме получается
а) положить на стек 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, но раз транзакция
в блоке - значит все правильно)

[Ninazu]

Тогда берем сегвит-данные, проверяем что хэш (не помню какой - вроде просто SHA256) от последнего
элемента будет именно таким как надо

Да, обычный SHA256. У вас хорошая память, что вы всё это в голове держите.

До OP_CHECKMULTISIG всё заработо с первого раза) Вау!
https://play.golang.org/p/NIjm1yO4YO

Вернусь с коммандировки, будет мне домашнее задание посчитать мультисигну. И разобраться как формируется сам scriptSig.

[amaclin1]

Да, обычный SHA256. У вас хорошая память, что вы всё это в голове держите.

Ну я все-таки анализом блокчейна и транзакций в нем занимаюсь уже больше трех лет.
Можете посмотреть с чего я сам начинал https://bitcointalk.org/index.php?topic=461351