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

[Ninazu]

Оговорюсь сразу с С++ я не дружу. Поэтому курить исходники не посылайте. Но представление о информации, и технологиях применимых в программировании имеется, также как и принцип работы биткоина по старой схеме.

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

[1714995595]

1714995595

[1714995595]

1714995595

[1714995595]

1714995595

[1714995595]

1714995595

[amaclin1]

Оговорюсь сразу с С++ я не дружу. Поэтому курить исходники не посылайте. Но представление о информации, и технологиях применимых в программировании имеется, также как и принцип работы биткоина по старой схеме.

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

Понимаешь неправильно.
Подпись не выносится в отдельный тип блока. И даже из транзакции она не выносится.
Просто подпись не учитывается при формировании txid, но при определении валидна транзакция или нет подпись учитывается.

[Ninazu]

То что информации в блоке стало больше я уже понял, и что она считаться стало иначе. И теперь TXID статическая.  Если раньше vsize =  size, то сейчас vsize <= size  и это размер который учитывается в контейнере блока.

А что за дичь txinwitness? Как они формируются?

http://learnmeabitcoin.com/browser/transaction/json.php?txid=06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643

Теперь в scriptSig находится merkle tree хеш этих txinwitness?

Что за вес блока?

[amaclin1]

То что информации в блоке стало больше я уже понял, и что она считаться стало иначе. И теперь TXID статическая.  Если раньше vsize =  size, то сейчас vsize <= size  и это размер который учитывается в контейнере блока.
А что за дичь txinwitness? Как они формируются?
http://learnmeabitcoin.com/browser/transaction/json.php?txid=06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643
Теперь в scriptSig находится merkle tree хеш этих txinwitness?
Что за вес блока?

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

[Ninazu]

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

Посмотрел BIP16

у входа scriptSig это результат подписи публичного ключа с опкодом подписи, приватным ключом подтверждающим владение кошельком
Я это увидел где-то так

Code:

scriptSig = sign(pubkey + OP_CHECKSIG, privKey), 

А у выхода scriptPubKey это (в самом простом случае без мультиподписи)

Code:

scriptPubKey =  OP_HASH160 + hash(pubkey + OP_CHECKSIG) + OP_EQUAL

Хотя я вижу и другие сценарии у выхода вроде

Code:

scriptPubKey =  OP_DUP + OP_HASH160 + hash(pubkey + OP_CHECKSIG) + OP_EQUALVERIFY + OP_CHECKSIG

Если правильно понял суть, то подпись рассчитывается не сразу

Как пример старой транзакции брал эту
http://learnmeabitcoin.com/browser/transaction/json.php?txid=7a160081db721c1f915d9d5bec8a66fb4b52583188d2dab91ef37264d3534b12

Как еще более старая транзакция до BIP16
http://learnmeabitcoin.com/browser/transaction/json.php?txid=d52e6e7fbc1b5d5bc9177947c0ab276f261a761266aeba69eae413e80055dc57

Преобразование адреса в хеш проверял тут
http://bitcoinvalued.com/tools.php

3QVitrqkY1ddvWqVhCwAZteERFfv2MZ2hz -> FA281A32566066CC8BCA5E9FCD4051C66C690279 -> 1PohyKMJz7KFqM94a7Ga9GHJGjPCWD6FyP
1pGcRWf6XVg3z7susY1nGMMfnhv3M3Zsf -> 08F094D5EAF2F1C52E572F17828EFE12E4C52398 -> 1pGcRWf6XVg3z7susY1nGMMfnhv3M3Zsf

[amaclin1]

у входа scriptSig это результат подписи публичного ключа с опкодом подписи, приватным ключом подтверждающим владение кошельком
Я это увидел где-то так

Code:

scriptSig = sign(pubkey + OP_CHECKSIG, privKey), 

Не в этом суть.
есть scriptPubKey - это некоторая функция
есть scriptSig - по сути дела это параметры передающиеся в функцию
валидация проходит если scriptPubKey ( scriptSig ) = 1
Это оригинальный концепт.

Потом подумали - а нахер нам иметь разные функции? давайте сделаем одну
но будем выполнять её хитро. То есть выполнение такое
return scriptPubKey ( scriptSig ) == 1  && executeLast ( scriptSig ) == 1
условно говоря, сперва выполняется по-старому алгоритму завещанному сатоши,
а потом еще выполняется сам последний операнд
при этом выполняются всякие проверки подписей.
Это BIP-16

А потом еще подумали и решили, а давайте если последний операнд имеет определенный формат,
то будем еще одну проверку делать, а сам код этой проверки вынесем в другое место?

Ладно, смысл в том, что пока вы не поймете в чем суть BIP-16 вы о сегвите не поймёте
Я вас только запутаю

[Ninazu]

Ладно, смысл в том, что пока вы не поймете в чем суть BIP-16 вы о сегвите не поймёте
Я вас только запутаю

К сожалению мой уровень английского крайне плох также как и знание С++.  Поэтому я больше путаюсь в переводах. А все что вы мне говорите мне понятно. Спасибо вам за это. Пробовал разобраться самостоятельно в исходниках, но там черт ногу сломит. Вся логика размазана по абстрактным слоям

[amaclin1]

К сожалению мой уровень английского крайне плох также как и знание С++.  Поэтому
я больше путаюсь в переводах. А все что вы мне говорите мне понятно. Спасибо вам
за это. Пробовал разобраться самостоятельно в исходниках, но там черт ногу сломит.
Вся логика размазана по абстрактным слоям

А не надо читать чужие исходники.
Сделайте свои. Конечно, надо хоть один язык программирования знать.
Бейсик и Паскаль тоже подойдут кстати.
Возьмите простую задачу, допустим в файл распечатать все адреса из блокчейна.
(будем считать что блокчейн уже скачан)
Пока будете разбираться - как раз и поймете как выглядят транзакции и
что такое bip16 и segwit

[Ninazu]

Пока будете разбираться - как раз и поймете как выглядят транзакции и
что такое bip16 и segwit

Хорошо знаю PHP и PureBasic
Немного хуже Go

Все адреса из блокчейна вытащил) Вначале пробовал в MySQL на PHP, но получилось сильно долго и много места. Более компактно и быстро получилось с levelDb и хранением адресов в бинарном виде.

Да именно такую задачу я перед собой и ставлю. Разобраться и попробовать реализовать segWit самому. Но для того чтоб сделать, нужно вначале понять как это сделать)

Я ведь правильно понимаю? Что раньше скрипт разблокировки включался в выход транзакции. Сейчас там содержится только хеш Меркля (P2SH), само дерево представляет из себя возможные вариации скрипта (для мультиподписи или блокировки по времени к примеру). Дальше в следующей транзакции на вход добавляется cамо тело скрипта который сработал, и используя рутовый хеш из предыдущего выхода, можно проверить находился ли этот скрипт где-то в хешируемом дереве. Но это всё в теории из того что я смог понять. И тут у меня ступор, ведь на практике если взять segWit транзакцию

http://learnmeabitcoin.com/browser/transaction/json.php?txid=06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643

То scriptSig - это тело скрипта, или очередной хеш? И что такое txinwitness

P.S.
Как оно работает брал отсюда
https://bits.media/news/sleduyushchiy-etap-po-uluchsheniyu-bitkoina-nazyvaetsya-mast/

[amaclin1]

Все адреса из блокчейна вытащил) Вначале пробовал в MySQL на PHP, но получилось сильно долго и
много места. Более компактно и быстро получилось с levelDb и хранением адресов в бинарном виде.

Прекрасно. Половина дела сделана. Базу вы как парсите? Дергаете клиент за API
или самостоятельно открываете  читаете blk-файлы?

Я ведь правильно понимаю? Что раньше скрипт разблокировки включался в выход транзакции.
Сейчас там содержится только хеш Меркля (P2SH), само дерево представляет из себя возможные

Ой-вей. Всё смешалось в доме Облонских.
Меркля забудьте. И не вспоминайте. Этот хэш вообще из другой оперы.

Есть несколько "разновидностей" использования сегвита.
Два (по-моему) нативных и два завернутых в P2SH

Начнем с нативных.
А, не, давайте вспомним сперва как работает самый популярный p2pkh

scriptPubKey = OP_DUP OP_HASH160 <address> OP_EQUALVERIFY OP_CHECKSIG
такой скрипт в обычных условиях вернет в стеке "1" если в scriptSig будет два пуш-элемента:
сигнатура и публичный ключ. Причем хэш публичного ключа (не Меркль, а посчитанный
по-биткойновски) должен быть равным адресу (иначе OP_EQUALVERIFY бросит исключение),
а сигнатура должна правильно подписывать подписывать дайджест (иначе OP_CHECKSIG вернет
"0" или вообще бросит исключение)

Задание на проверку навыков. Что если scriptSig состоит не из двух, а из трех и более элементов?
последний - это публичный ключ, предпоследний - валидная сигнатура, а остальные - какие-либо
другие? Что будет в стеке после выполнения? Будет ли транзакция валидной? Подтвердят ли её майнеры?

И второе задание на проверку навыков: а если в scriptSig  будет одна или ноль пуш-операций?
На какой команде произойдет сбой выполнения?

Теперь переходим к нативным.
Я по памяти буду писать. Идею изложу, но могу где-то напутать.
Нативный pubkeyScript имеет вид OP_0 <scripthash>
Про сегвит пока забыли. Давайте проверим навыки. Каким должен быть scriptSig
чтобы после последовательного выполнения scriptSig и scriptPubkey наверху стека
оказалось бы ненулевое значение. (ответ на этот вопрос можно высказать одним словом)

[Ninazu]

Прекрасно. Половина дела сделана. Базу вы как парсите? Дергаете клиент за API
или самостоятельно открываете  читаете blk-файлы?

За API, до blk формата файлов я еще не дошел. Но предположу что там тоже levelDb и на выходе будет просто сырые данные, которые после преобразования приймут структуру подобную json дереву из примеров.
http://learnmeabitcoin.com/browser/transaction/06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643

Задание на проверку навыков. Что если scriptSig состоит не из двух, а из трех и более элементов?
последний - это публичный ключ, предпоследний - валидная сигнатура, а остальные - какие-либо
другие? Что будет в стеке после выполнения? Будет ли транзакция валидной? Подтвердят ли её майнеры?

Так как значения забираются из стека в обратной последовательности, и функция почистит два элемента сигнатуру и публичный ключ, то в стеке останутся остальные элементы. А первый операнд будет заменён на результат функции. Предположу что да, транзакция будет валидной при условии соответсвия адреса и сигнатуры

И второе задание на проверку навыков: а если в scriptSig  будет одна или ноль пуш-операций?
На какой команде произойдет сбой выполнения?

По идее на первом обращении к функции, так как количество аргументов отличается от задекларированного. Ну или как вариант если аргументы динамические то OP_EQUALVERIFY так как до OP_CHECKSIG  не дойдёт очередь.

Каким должен быть scriptSig
чтобы после последовательного выполнения scriptSig и scriptPubkey наверху стека
оказалось бы ненулевое значение.

OP_0 - добавляет пустой массив в стек.
Значит scripthash любой отличный от нуля. Ненулевое значение в стеке будет если scriptPubkey вернёт не ноль.

[amaclin1]

Так как значения забираются из стека в обратной последовательности, и функция почистит два элемента сигнатуру и публичный ключ,
то в стеке останутся остальные элементы. А первый операнд будет заменён на результат функции.
Предположу что да, транзакция будет валидной при условии соответсвия адреса и сигнатуры

Да. Лучше конечно называть "элемент на вершине стека", а то непонятно откуда мы считаем.
Транзакция валидна, но майнеры её не включат, так как по полиси-правилам (это нестрогое правило)
на стеке должен остаться только один ненулевой элемент.

По идее на первом обращении к функции, так как количество аргументов отличается от задекларированного.
Ну или как вариант если аргументы динамические то OP_EQUALVERIFY так как до OP_CHECKSIG  не дойдёт очередь.

Почему не дойдет? Проверка необходимого числа элементов в стеке происходит при выполнении каждой команды
Если в scriptSig только публичный ключ - то OP_EQUALVERIFY сработает, а OP_CHECKSIG сломается - ему
надо два аргумента, а в стеке только один
Если в scriptSig вообще пусто - то сломается на OP_DUP

OP_0 - добавляет пустой массив в стек.
Значит scripthash любой отличный от нуля. Ненулевое значение в стеке будет если scriptPubkey вернёт не ноль.

Не-не-не
Вы неправильно поняли мою запись.
OP_DUP OP_HASH160 <address> OP_EQUALVERIFY OP_CHECKSIG - в этом скрипте <address> значит
"положить 20 байтов в стек" то есть здесь пять операций делается

OP_0 <scripthash> - тут две операции - положить в стек пустой массив
и положить в стек 20 байт (или 32 байта - я ведь не указал сколько разрядов у scripthash)
(Вероятность того, что результат хэш-функции нулевой настолько мала, что это можно не упоминать специально)
Но это scriptPubkey
Повторяю вопрос. Каким должен быть scriptSig чтобы после выполнения сперва scriptSig а потом этого scriptPubKey
на вершине стека было бы ненулевое число? Ответ - одним словом.

[Ninazu]

Не-не-не
Вы неправильно поняли мою запись.
OP_DUP OP_HASH160 <address> OP_EQUALVERIFY OP_CHECKSIG - в этом скрипте <address> значит
"положить 20 байтов в стек" то есть здесь пять операций делается

Разберу оптимистический сценарий

1. Заносим scriptSig в стэк
pubKey->signature

2. Дублируем верхний элемент стека
pubKey->pubKey->signature

3. Находим хеш публичного ключа
pubKeyHash->pubKey->signature

4. Помещаем хеш адреса в стек
addressHash->pubKeyHash->pubKey->signature

5. Сравниваем addressHash и pubKeyHash (функция OP_EQUAL)
true->pubKey->signature

6. Если валидация не прошла помечаем транзакцию как невалидную (процедура OP_VERIFY)
pubKey->signature

7. Проверяем подпись OP_CHECKSIG
true

Повторяю вопрос. Каким должен быть scriptSig чтобы после выполнения сперва scriptSig а потом этого scriptPubKey
на вершине стека было бы ненулевое число? Ответ - одним словом.

Что-то тут неясно. Во первых scriptSig - это ж набор параметров, почему он должен выполнятся? Во вторых чтоб на выходе scriptPubKey было ненулевое число, сценарий должен дойти до конца и вернуть true. А это значит:

1. scriptSig должен состоять из публичного ключа и сигнатуры
2. сигнатура должна соответсвовать дайджесту
3. еще и полиси правило про один ненулевой элемент не мешало бы соблюсти.

Как на это ответить одним словом?

Причем тут OP_0 и scripthash?

[amaclin1]

Разберу оптимистический сценарий
1. Заносим scriptSig в стэк
pubKey->signature

Всё правильно. Только что значит "заносим в стек"? Кто его заносит?
Поймите: scriptSig - это тоже скрипт и его просто выполняют
Когда-то раньше не было ограничений на этот скрипт - можно было любые
конанды использовать. Потом решили что достаточно только пуш-операций.
Остальное тоже можно (вроде софт-форк ограничивающий множество
доступных в scriptSig операций не вводили), но нестандартно.

Повторяю вопрос. Каким должен быть scriptSig чтобы после выполнения сперва scriptSig а потом этого scriptPubKey
на вершине стека было бы ненулевое число? Ответ - одним словом.

Что-то тут неясно. Во первых scriptSig - это ж набор параметров, почему он должен выполнятся?
Во вторых чтоб на выходе scriptPubKey было ненулевое число, сценарий должен дойти до конца и вернуть
true. А это значит:

Каждый отдельный скрипт не обязан, чтобы на стеке после его выполнения было ненулевой значение на вершине.
Транзакция считается валидной если после последовательного выполнения scriptSig и scriptPubKey
на вершине стека ненулевое значение. Вам надо понять, что проверка транзакции - это именно что выполнение
scriptSig и scriptPubKey над одним объектом стека. scriptSig туда кладет, scriptPubKey - забирает и проверяет.

В первых версиях биткойна вообще проверка транзакции проходила так, что scriptSig и scriptPubKey склеивались
в один байтовый массив и выполнялись как один скрипт. Потом Сатоши допёр почему так нельзя делать.

1. scriptSig должен состоять из публичного ключа и сигнатуры
2. сигнатура должна соответсвовать дайджесту

Это только для расходования p2pkh-выходов.
Есть же еще другие типы выходов например pay-to-public-key
в этом случае scriptPubkey <publickey> OP_CHECKSIG
(когда я пишу в угловых скобках - это значит операция:положить в стек)
и scriptSig соответствующий этому scriptPubkey - это просто <signature>

3. еще и полиси правило про один ненулевой элемент не мешало бы соблюсти.
Как на это ответить одним словом?
Причем тут OP_0 и scripthash?

Мы к сегвиту уже перешли. Рассматриваем как видит сегвит-транзакции обычная старая нода.

[Ninazu]

Спасибо. Так более ясная картинка становится с каждым сообщением.

Потом Сатоши допёр почему так нельзя делать.

Минусы в избыточности данных? Или что-то с безопасностью?

Мы к сегвиту уже перешли. Рассматриваем как видит сегвит-транзакции обычная старая нода.

Ура. Но все равно у меня вопрос.

Если для новой транзакции
scriptSig что-то делает(главное чтоб не исключение бросал), а после этого scriptPubkey добавляет в стек пустой массив и хеш скрипта, и после этого нет больше никакого опкода. То верхним элементом стека будет хеш скрипта.

scriptHash -> [] -> scriptSigResult(если он есть)

Транзакция будет считаться валидной, но майнеры её не включат из-за полиси по размеру стека

[amaclin1]

Транзакция будет считаться валидной, но майнеры её не включат из-за полиси по размеру стека

Ну да.
Именно этот финт я пытался использовать вот тут: https://bitcointalk.org/index.php?topic=1759350.0
Ответ на мой вопрос я хотел получить одним словом: scriptSig может быть любой
в том числе и пустой. После выполнения scriptSig и scriptPubkey на вершине стека остается ненулевой
элемент и транзакция с точки зрения старых клиентов валидна, то есть имеет право жить в блоке.

А новые клиенты имеют костыль - они видят что scriptSig пустой а scriptPubkey имеет определенный формат
и вытаскивают из witness-данных транзакции код и начинают исполнять его тоже.

[amaclin1]

Потом Сатоши допёр почему так нельзя делать.

Минусы в избыточности данных? Или что-то с безопасностью?

С безопасностью. Если scriptPubkey состоит из N байтов (что внутри неважно, 0 < N < 72), то я scriptSig
сделаю из одного байта со значением N и после конкатенации результирующий скрипт будет
в стек класть сам scriptPubKey - то есть я таким образом могу потратить любой чужой выход

Вот тут есть наша с theymos (это владелец этого форума) дискуссия
https://bitcoin.stackexchange.com/questions/29754/history-behind-the-scripting-language-in-bitcoin

[Ninazu]

Да я уже понял что опкоды
01-4B отвечают за копирование данных, указанной длины в стек.

Ура наконец добрались до txinwitness данных. Как они загружаются в стек и выполняются предположу что по той же схеме что и скрипты. Но зачем они, какова их суть?

[amaclin1]

Да я уже понял что опкоды
01-4B отвечают за копирование данных, указанной длины в стек.

Мне пора брать бабло за репетиторство

Ура наконец добрались до txinwitness данных. Как они загружаются в стек и выполняются
предположу что по той же схеме что и скрипты. Но зачем они, какова их суть?

Мы немного перепрыгнули BIP-16. Ладно.
Сегвит решает несколько задач.
1. Он обратно совместим со старым биткойном. То есть не надо пересаживать 100500 юзеров
на новый клиент, что в децентрализованном мире нелегко или даже невозможно. Достаточно
чтобы проголосовали хэш-мощности.
2. Он уменьшает размер транзакции, если считать "по старым правилам". Вкупе с пунктом 1
это дает большую пропускную способность сети.
3. Он устраняет проблемы с пластичностью транзакций, то есть если вы посылаете транзакцию
с каким-то txid то она не сможет подтвердиться с другим txid
4. Самое главное - это позволяет узнать txid до подписывания транзакции.

[Ninazu]

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

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

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

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

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