Topic: Эксперименты со скриптами биткоина где? (Read 342 times)

Уже разобрался.
Симуляторы косячно ищут хэши.

В результате работы этого скрипта остается 0x1


OP_IF убирает 0x1 из стека и делает OP_RIPEMD160 от пустой строки, в итоге получается 0xE63C7DC57882262676E009478111E6AE5C6C5198 и затем OP_EQUALVERIFY сравнивает его с 0x388756DC41F4EEADCB3FC5064535D1121A49D3F4

В симуляторе OP_RIPEMD160 от пустой строки срабатывает, а в реальном биткоине видимо нет.

Черт с ним со сложным скриптом. Решил с простыми поэкспериментировать. Тоже не работает нифига.

Делаю скрипт
OP_IF OP_RIPEMD160 388756dc41f4eeadcb3fc5064535d1121a49d3f4 OP_EQUALVERIFY OP_ELSE 2 OP_EQUALVERIFY OP_ENDIF

Вот его адрес
2MwGFm13NMXNcv3yTKHWTJ3wFBfxDWhVbpS

Послал туда сатошей.

Теперь хочу забрать сатоши. Пишу транзакцию
 
Там в транзакции получается скрипт

И что имеем?
Тут скрипт работает без ошибок https://siminchen.github.io/bitcoinIDE/build/editor.html
А когда засылаю в сеть, пишет

Спрашивается: чего я опять делаю не так?

Что-то не проканывает.

Задумал вот такой скрипт написать

Написал, получил адрес, послал туда тестовых битков.
адрес: 2N77oVk5k8MWE33hWS5QeS5bM2zVkgHcido
транзакция: 3a59dcef30879ebda1ffdaff4c1c46f06691d231b974acdc6f90907a973c658f

Пробую потратить такой транзакцией


ОБЛОМ ((

Декодирую, вижу

В asm то, что я хочу видеть, в hex вижу пару лишних байтов


Лишние тут OP_PUSHDATA1 OP_PUSHDATA4
Понятно откуда они взялись: это пушится мой скрипт.
Непонятно - какого хрена они учитываются как данные, когда скрипт исполняется

Получается в моем начальном скрипте надо делать как-то так:


?

Ну молодцы, сами разобрались?
Отлично, мне работы меньше.
Я просто думал, что не только вам объяснить, но и другим полезно было бы понять,
почему ушли от p2pk к p2pkh, потом к p2sh (это было радикальное изменение,
уже без Сатоши, пришлось софт-форком улучшать то, до чего Сатоши не допер)

И поняв это, достаточно легко уже понять сегвит - тоже софт-форк, который исправляет
другие неучтенные проблемы.

Спасибо огромное, я четвертый час это вот все нагуглить никак не могу. Теперь спать спокойно могу пойти 

Вы неправильно написали:
vin.scriptSig = PUSH правильная_подпись1 [PUSH правильная_подпись2] [правильная_подпись3] [...] ЛЮБОЙ_ВАЛИДНЫЙ_СКРИПТ

Правильно так:
vin.scriptSig = PUSH правильная_подпись1 PUSH правильная_подпись2 ... PUSH ЛЮБОЙ_ВАЛИДНЫЙ_СКРИПТ

Понятно, в чём разница? PUSH ЛЮБОЙ_ВАЛИДНЫЙ_СКРИПТ - это уже не скрипт, а данные (сериализованный скрипт), над которыми должен выполнить действия другой скрипт - scriptPubKey.

Как-то так:
PUSH ЛЮБОЙ_ВАЛИДНЫЙ_СКРИПТ OP_HASH160 PUSH хэш_скрипта OP_EQUAL

Сериализованный скрипт стоит последним в scriptSig, тем он и выделяется среди впереди стоящих подписей.

В случае успешного выполнения PUSH ЛЮБОЙ_ВАЛИДНЫЙ_СКРИПТ OP_HASH160 PUSH хэш_скрипта OP_EQUAL
дальше уже выполняется PUSH sig1 PUSH sig2 ... ЛЮБОЙ_ВАЛИДНЫЙ_СКРИПТ

Обратите внимание: ЛЮБОЙ_ВАЛИДНЫЙ_СКРИПТ стоит уже без PUSH. Это уже не данные, а скрипт - последовательность опкодов к исполнению.

Но вот это все целиком тоже валидный скрипт:
vin.scriptSig = PUSH правильная_подпись1 [PUSH правильная_подпись2] [правильная_подпись3] [...] ЛЮБОЙ_ВАЛИДНЫЙ_СКРИПТ

Как узнать: где кончаются подписи и начинается скрипт?

А работает оно в два этапа.
Сначала выполняется вот этот скрипт: <ЛЮБОЙ_ВАЛИДНЫЙ_СКРИПТ> OP_HASH160 <хэш_скрипта> OP_EQUAL
Тем самым, проверяется соответствие скрипта и его хеша, подтверждая право владельца скрипта на его выполнение.

А потом выполняется сам скрипт, тратящий выход: ... <ЛЮБОЙ_ВАЛИДНЫЙ_СКРИПТ>.

Ну можно было короче:

В первых версиях биткоина было так (pay-to-pubkey transaction):

кто хочет потратить, в своей транзакции на входе писал
vin.scriptSig = PUSH правильная_подпись
vin.txid = ид транзакции которую надо потратить.

На выходе транзакции которую собираются тратить стояло
vout.scriptPubKey = PUSH публичный_ключ CHECKSIG

Итого полный скрипт получался

Соответственно если подпись для публичного ключа действительно правильная, то предыдущая транзакция считалась потраченной.

В следующих версиях скрипты слегка усложнили.
(pay-to-pubkey-hash)

кто хочет потратить, в своей транзакции на входе пишет
vin.scriptSig = PUSH правильная_подпись PUSH публичный_ключ
vin.txid = ид транзакции которую надо потратить.

На выходе транзакции которую собираются тратить стоит
vout.scriptPubKey = DUPLICATE HASH160 хэш_публичного_ключа EQUALVERIFY CHECKSIG

Итого полный скрипт получается

Потом появилась еще одна разновидность
Pay-To-Script Hash

кто хочет потратить, в своей транзакции на входе пишет
vin.scriptSig = PUSH правильная_подпись1 [PUSH правильная_подпись2] [правильная_подпись3] [...] ЛЮБОЙ_ВАЛИДНЫЙ_СКРИПТ
vin.txid = ид транзакции которую надо потратить.

На выходе транзакции которую собираются тратить стоит
vout.scriptPubKey = OP_HASH160 хэш_скрипта OP_EQUAL

Итого полный скрипт получается.


В этом месте у меня уже нет полного понимания, как оно на самом деле работает. Походу дела как-то так:
1. Сначала исполняется скрипт vin.scriptSig
2. Потом берется хэш от vin.scriptSig (или берется хэш только от скрипта, а подписи не хэшируются ?)
3. Полученный хэш засовывается в стек и дальше начинает исполняться OP_HASH160 хэш_скрипта OP_EQUAL
4. Если на выходе стека получится не ноль, значит предыдущая транзакция считается потраченной.

Наконец самое последнее веяние:
SegWit транзакции.
Тут я как раз хотел у знатоков поинтересоваться - как они работают.

Давай с самого начала начнем.

Можно начать с самой первой транзакции
https://www.blockchain.com/btc/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

Скрипт выхода (scriptPub) этой транзакции из двух операндов состоит
PUSH ( 04678afdb0fe5... ) CHECKSIG

Чтобы потратить эту транзакцию надо придумать такой входной скрипт (scriptSig)
чтобы последовательное выполнение scriptSig + scriptPub над одним и тем же стеком
давало бы в конце ненулевое значение на вершине стека. Обращаю внимание: сперва выполняется
scriptSig, а потом scriptPub!

Тут надо понимать как работает операция CHECKSIG - она что-то крутит-вертит с транзакцией
(той в которой мы будем тратить) и еще берет scriptPub из первой транзакции - получает некоторый
дайджест. Потом надо сигнатуру, публичный ключ и дайджест скормить функции проверки правильности
подписи и в стек записать нолик или единичку в зависимости от того прошло или не прокатило.

Значит самый простой вариант scriptSig - это просто PUSH ( тутправильнаяподпись )

Можно изъебнуться. Например NOP NOP NOP PUSH ( чтонибудь ) DROP PUSH ( тутправильнаяподпись )
тоже будет приводить к тому же результату. Это достаточно давно заметили и решили
что клиент должен делать дополнительные проверки, например в scriptSig нельзя(?)
использовать ничего кроме PUSH-операций.

Потом Сатоши Накамото почесал репу, и решил - надо по-другому делать.
Он таки башковитый был, решил что предложенный вариант несколько кривоват.
Вернее даже не кривоват, наоборот, он слишком прямой. Надо бы изъебнуться так,
что владелец средств не показывает никому свой публичный ключ до того, как он
тратит бабки.

И стали все использовать другой вариант scriptPub который называется p2pkh

Об этом в следующей главе. Мне лениво много печатать, а если я не начну с самого начала,
то вы мысль не уловите - нахера было от p2pk переходить к p2pkh, потом к p2sh, а потом к сегвитам

Прошу консультации: кто может объяснить работу со скриптами биткоина?

Вот мое понимание.

Обычно желающий потратить биткоины, в своей тратящей транзакции в vin.scriptSig пишет некий скрипт, а в vin.txid пишет транзакцию куда этот скрипт подставить.

Правило такое: если vin.scriptSig тратящей транзакции (currentTX) поставить перед (prevTX) vout.scriptPubKey из той транзакции которую тратят, то получившийся скрипт (currentTX.vin.scriptSig prevTX.vout.scriptPubKey) должен после выполнения, в стеке давать не ноль. Если в стеке не ноль, то транзакция prevTX считается израсходованной...

Вроде с этим все понятно.
Однако с некоторых пор, в сети биткоина появился новый тип транзакций, связанный с SegWit. В SegWit транзакциях помимо vin.scriptSig присутствует поле vin.txinwitness

Насколько я понял, в этом новом поле тоже пишется скрипт, и он тоже подставляется вперед prevTX.vout.scriptPubKey и тоже должен получиться не ноль. Но вот есть загвоздка в моем понимании:
1. vin.txinwitness это массив.
2. Каждый элемент массива что-то не очень похож на скрипт. Вот пример http://chainquery.com/bitcoin-api/getrawtransaction/e6511db40a71ca407965e011ad76a7711acc5cfccf51586aa71a78dc535e6a4b/1

3. Если это поле все-таки скрипты, тогда еще вопрос: если в одной транзакции есть и непустое vin.scriptSig и vin.txinwitness, то кто подставляется первым?

Спасибо.
По первой ссылке ничего правда не понятно, но вторая - вещь!

http://www.crmarsh.com/script-playground/
https://siminchen.github.io/bitcoinIDE/build/editor.html

Привет. Где-то давно попадался сайт, где можно было потренироваться в написании биткоин скриптов. Вводишь команды, смотришь стек и что возвращается в результате. Сейчас что-то сходу не могу рабочую версию нагуглить. Никто не в курсе случайно где?