Серийный номер сертификата ключа подписи как посмотреть продление ЭЦП

Pay-to-public-key-hash сценарии

Большинство транзакций, наполняющих сегодня сеть Биткоин, используют один и тот же сценарий проверки валидности – Pay-to-Public-Key-Hash (P2PKH, платеж на хеш открытого ключа), проецирующий на криптовалютную платформу простейшую операцию перевода денежных средств от одного лица другому, но только в обезличенной форме.

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

Вернемся к рассмотренному ранее примеру с Мариной, оплатившей биткоинами чашку кофе, выпитую в кофейне Сергея. Выход соответствующей транзакции будет заблокирован скриптом scriptPubKey следующей конструкции:

“Public-Key-Hash Сергея” представляет собой биткоин-адрес кошелька владельца кофейни в шестнадцатеричном формате (т.е., без перевода в кодировку Base58Check с характерной для этого случая “1” вначале). Это вполне естественно, если вспомнить, что формат Base58Check придуман для лучшего восприятия больших чисел людьми. А компьютеры легко разберутся и с шестнадцатеричным представлением данных.

Когда Сергею понадобятся эти средства, он легко сможет снять с них обременение с помощью следующего разблокирующего скрипта (scriptSig), входящего в состав новой транзакции (в качестве одного из ее входов):

Здесь под термом Signature понимается электронная подпись владельца криптопары.

Если объединить оба скрипта в один сценарий, мы получим уже отчасти знакомый нам программный код на языке Script:

После выполнения этого комбинированного сценария, мы получим на вершине стека единственное значение “ИСТИНА” тогда и только тогда, когда разблокирующий скрипт подойдет условиям, закодированным в блокирующем скрипте. Воспользоваться средствами может только обладатель закрытого ключа Сергея, представив для снятия обременения свою электронную подпись. В штатной ситуации это и есть сам Сергей.

Ход выполнения сценария в случае P2PKH-транзакции проиллюстрирован рисунком 3.5 (в целях улучшения восприятия у операторов языка Script на рисунке опущены префиксы OP_). Причину разделения процесса на две части Вы уже знаете. Скрипты объединенного сценария выполняются последовательно, а результат первого передается во второй посредством стека.

Выполнение сценария начинается с разблокирующего скрипта scriptSig, включающего всего два шага. Сначала на вершину стека добавляется электронная подпись владельца биткоин-адреса, на хеш которого был совершен платеж. Затем – на вершину стека добавляется соответствующий открытый ключ.

В самом начале второй части комбинированного сценария – скрипта обременения scriptPubKey выполняется дублирование указателя стека, т.е., самого верхнего значения – открытого ключа. Инструкция OP_HASH160 на самом деле вычисляет двойной хеш, применяя последовательно хеш-функции SHA-256 и RIPEMD-160 к указателю стека (значению на вершине), а полученный результат вновь добавляется в стек. Т.е., на вершине стека окажется величина, равная RIPEMD-160(SHA-256(<отрытый ключ>)).

Мы с Вами помним, что это формула вычисления биткоин-адреса. Аналогичная по смыслу величина у нас вшита в самом скрипте обременения – биткоин-адрес, на который собственно и были в свое время отправлены средства. Это следующий операнд скрипта, появление которого в нем означает, что биткоин-адрес получателя платежа размещается на вершине стека.

Осталось их сравнить. Что и делает инструкция OP_EQUALVERIFY. С ее помощью из стека выбираются два верхних значения (биткоин-адрес действительного получателя средств и биткоин-адрес претендента на эти средства) и осуществляется их сравнение.

Результат сравнения добавляется к стеку. На самом деле команда OP_EQUALVERIFY немного мощнее, чем простой оператор сравнения, который также в синтаксисе языка Script присутствует – OP_EQUAL.

Инструкция OP_EQUALVERIFY подразумевает также в конце исполнения вызов команды OP_VERIFY, отмечающую транзакцию как недействительную, если на вершине стека оказывается значение не равное TRUE.

Если сравнение подтвердило совпадение биткоин-адресов, осталось убедиться в реальности прав пользователя на фигурирующий в сценарии биткоин-адрес. Поскольку последний рассчитывался через открытый ключ, достаточно проверить действительно ли предъявитель данного открытого ключа является его владельцем.

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

Если проверка пройдет успешно, на вершине опустевшего к моменту завершения сценария стека окажется значение 1 (TRUE). В противном случае указатель стека будет возвращать значение 0 – транзакция недействительная.

Хотя относительно реализации последнего шага и был употреблен эпитет “традиционно”, это утверждение не является справедливым. Традиционной можно назвать процедуру использования открытого ключа для проверки электронной подписи. А вот идея проверки принадлежности публичного ключа на основе электронной подписи является весьма оригинальной. Впрочем, так можно охарактеризовать практически любой компонент платформы Биткоин.

Осталось рассмотреть всего один вопрос. Подпись всегда ставится под документом. Электронная подпись не исключение. На основании какого электронного документа создается электронная подпись в скрипте scriptSig? Электронная подпись генерируется на основе дайджеста (результата хеширования) некоторых полей данной транзакции.

Pay-to-script-hash (p2sh) сценарии

Модель Pay-to-script-hash (P2SH) была введена в 2021 году в качестве нового типа транзакций, существенно расширяющего спектр поддерживаемых платформой финансовых схем. Появилась возможность использовать сложные сценарий транзакций. Эту модель часто путают с мульти-подписью, однако сфера применения P2SH-скриптов гораздо шире.

Если отталкиваться только от скриптов обременения, так вариабельность условий обременения вообще становится практически безграничной. Достичь это позволило весьма элегантное решение. Средства отправляются на адрес скрипта. При этом что из себя представляет скрипт заранее никак не оговаривается – он может быть любым.

Еще одна особенность этой модели – в поле транзакции scriptPubKey (где у нас обычно размещаются условия обременения) ограничения в виде скрипта больше не фигурируют. Акцент смещается в сторону пользователя, который впоследствии осуществит трату средств.

Именно ему придется представить скрипт в качестве доказательства своего права на заблокированные в выходе P2SH-транзакции средства. Согласитесь, логика проверки по сравнению с предыдущими моделями иная. Очень мощное с точки зрения масштабируемости функционала платформы решение.

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

Однако, имея на руках исходный скрипт, можно легко получить точно такой же дайджест путем повторного хеширования скрипта. Хеш сценария — это и есть та информация, которая включается в выход транзакции (в поле scriptPubKey). Для того, чтобы такой выход в следующей транзакции, недостаточно просто выполнить условия, определенные в сценарии, так как ноды сети Биткоин видят только дайджест хеша скрипта и поэтому о самом скрипте им ничего не известно.

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

В этом случае ноды сети Биткоин, вычислив хеш приложенного сценарий, могут сравнить его с хешем, размещенным в выходе предыдущей транзакции. В случае совпадения нодам остается только проверить правильность выполнения условий, определенных в сценарии, после чего транзакция признается действительной. Рисунок 3.6 иллюстрирует изложенный процесс.

Таким образом, P2SH-модель по сути реализует следующее финансовое предписание “заплатить при предъявлении скрипта, соответствующего данному хешу”.

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

Комбинированный сценарий траты средств в этом случае выглядит следующим образом:

Недостаток такого сценария очевиден – он слишком длинный. Мы помним, что в распределенных системах следует экономить на каждом байте блокчейна. К тому же вторая часть сценария (скрипт scriptPubKey) должен предварительно быть доведен до каждого клиента, чтобы они смогли его использовать в своих платежных транзакциях.

Организационно это не самое удобное решение. Клиенты должны пользоваться специальными кошельками, быть в курсе процедуры создания мульти-подписных транзакций и платить повышенную комиссию майнерам за обработку огромных транзакций (из-за большой длины открытых ключей, которых в блокирующем скрипте стало намного больше, чем в традиционном P2PKH-выходе).

Даже не будем вспоминать о дополнительной нагрузке на оперативную память каждой полной ноды, в которой должны храниться все подобные нерастраченные выходы (в пуле UTXO). Все перечисленные проблемы серьезно осложняют применение сложных скриптов обременения на практике.

Pay-to-script-hash модель как раз и была разработана для решения указанных проблем.

В P2SH-транзакциях, блокирующий скрипт заменяется процедурой проверки хеша скрипта, называемого погашающим, поскольку его код будет представлен системе в момент траты выхода (погашения), а отнюдь не в качестве предварительно записанных условий обременения. В таблице 3.4 представлены форматы скриптов для сценария с мульти-подписью и P2SH-схемы.

Биктоин-адрес формата P2SH всегда начинается с 3, а не 1, как в P2PKH-адресах. Это связано с тем, что P2SH-адреса перед кодированием по стандарту base58check дополняются префиксом байта версии, равным 0x05 (в шестнадцатеричном формате), а не 0x00 (в шестнадцатеричном формате), характерным для P2PKH-адресов.

А теперь вместо мнемонических обозначений в блокирующий скрипт подставим реальные открытые ключи (520-разрядные двоичные числа, начинающиеся с 0х04):

Пугает, правда? Зато в P2SH-сценарии весь этот ужас представляется 20-ти байтным дайджестом – результатом хеширования блокирующего скрипта с помощью последовательного применения алгоритмов SHA-256 и RIPEMD-160, т.е., RIPEMD-160(SHA-256(<код блокирующего скрипта>)). Для нашего конкретного случая это всего-то:

Выход P2SH-транзакция будет обременен с помощью следующего блокирующего скрипта:

Это все, что нужно знать клиенту для проведения платежа в адрес рассматриваемой в примере компании. Размер такой транзакции не будет превышать размеров обычных транзакций (по крайней мере по причине раздутого скрипта scriptPubKey) и проведение платежа не потребует от клиента затрат на повышенную комиссию майнерам.

Как же можно снять обременение с такого нерастраченного выхода? Ведь биткоин-адреса получателя средств, в привычном для нас с Вами понимании, в P2SH-сценарии больше нет. Необходимо создать вход, в котором представлен оригинальный код погашающего скрипта (того самого, хеш которого использовался при обременении средств) и подписи двух или более владельцев компании – в качестве удовлетворения условий обременения выхода – погашающего скрипта. Например:

Комбинированный сценарий проверки притязаний на заблокированные средства, выраженных приведенным выше входом транзакции, выполняется в два этапа. Во-первых, погашающий сценарий проверяется разблокирующим скриптом на предмет совпадения хеша:

Если проверочный сценарий заканчивается успешно (в стеке окажется единственное значение ИСТИНА), переходим ко второму этапу, на котором мы фактически имеем дело с обычной процедурой проверки комбинированного сценария, включающего модифицированный разблокирующий скрипт (<Условия снятия обременения> <Погашающий скрипт>):

Далее все происходит точно также как и в случае проверки обычной транзакции.

Входы и выходы транзакции

Цель: Сформировать комплекс знаний о строении входов и выходов транзакции, составе, функциях и взаимосвязи их структурных компонентов.

Безусловно, это самые интересные и важные части транзакции. Концептуальным элементом схемы являются неизрасходованные выходы транзакций (Unspent TransactionOutput) или UTXO.

Биткоин был первой валютой, реализующей модель UTXO для отслеживания состояния реестра. Каждая очередная транзакция расходует выходы предыдущих и создает новые выходы, которые в свою очередь будут израсходованы последующими транзакциями.

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

Основная причина успеха UTXO – это присущий ей естественный параллелизм в виду того, что каждая транзакция может обрабатываться параллельно, так как все они относятся к независимым неконфликтующим выходам (поскольку у каждого выхода ровно один владелец). С точки зрения теоретической информатики, UTXO – очень элегантная и легко доказуемая схема.

Отметим, что модель UTXO подвергается определенной критике. Оппоненты утверждают, что технические решения, основанные на подобной схеме, подходят только для тех предметных областей, где каждый выход имеет строго одного владельца.

Данное обстоятельство хорошо стыкуется с моделью валюты, и поэтому работает в случае с платформой Биткоин. А вот для приложений общего назначения, допускающих притязание на один выход нескольких владельцев (конфликтующие выходы), использование UTXO может привести к неуправляемому шторму неподтвержденных транзакций, и даже к комбинаторному взрыву блокчейна.

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

Итак, платформа Биткоин отслеживает все доступные (неизрасходованные) выходы UTXO (на февраль 2021 года общая масса выпущенной криптовалюты превысила 16 840 000 BTC). Каждый раз, когда пользователь так или иначе получает биткоин, эта сумма учитывается в платформе как нерастраченный выход.

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

Впрочем, для удобства пользователей программное обеспечение кошельков эмулирует балансы счетов пользователя, которые прекрасно отражаются в интерфейсной части приложения. Для этого кошельки сканируют блокчейн и суммируют все нерастраченные выходы, принадлежащие данному пользователю.

Неизрасходованный выход транзакции может блокировать любую произвольную сумму в биткоинах (или сатоши). При этом он является неделимым (не станете же Вы отрывать кусочки от пятитысячной купюры для оплаты покупки в 500 рублей). Аналогия тут совершенно полная.

Это означает, что для осуществления сделки требующей купюры меньшего номинала, чем имеющийся в Вашем распоряжении неизрасходованный выход, Вам все равно придется потратить его целиком. На самом деле все не так печально. Сдачу самому себе никто не отменял. Т.е., транзакция кроме одного выхода, отправляющего требуемую сумму по адресу получателя платежа, будет содержать еще один выход – сдачу самому себе (аналогичным образом, если средств в одном нерастраченном выходе недостаточно, следует аккумулировать несколько UTXO, т.е., транзакция может включать несколько входов). Ну и о вознаграждении майнерам не стоит забывать. Все ровно так как показано на рисунке 4.

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

Почему модель UTXO называют симметричной? Нерастраченные выходы в блокчейне, которые транзакция потребляет являются ее входами. Одновременно с этим создаются новые нерастраченные выходы, которые становятся выходами данной транзакции. Фраза конечно звучит не очень благозвучно, но по сути здесь все верно.

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

А теперь попробуйте ответить на вопрос: что является первичным вход или выход транзакции?

Есть только одно исключение из сформулированного правила в модели UTXO. Речь идет о так называемых coinbase-транзакциях, являющихся источником эмиссии криптовалюты Биткоин. Эти токены отправляются майнеру, которому удалось сформировать очередной валидный блок, включенный в блокчейн.

Первой транзакцией любого блока является такая coinbase-транзакция, фиксирующая факт перевода майнеру, сгенерировавшему этот блок, гонорара за его труды. Разумеется, майнер сам эту транзакцию и формирует в процессе создания блока.

Он даже может в качестве получателя новеньких биткоинов указать любого другого участника сети (не думаю, что на практике майнеры часто поступают таким образом). Особенностью этой цифровой записи является отсутствие входов. Ее выход создается из воздуха.

Признаться, в блокчейне Биткоина есть еще одна особая, единственная транзакция, входящая в его генезис-блок. Первые 50 BTC были отправлены Сатоши Накамото по адресу 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa.

Никаких входов у этой транзакции конечно же нет. Но поскольку блок генезиса жестко зашит в программном обеспечении всех приложений (кстати это типичная ситуация для генезис-блоков практически всех криптовадют) непонятно каким образом эти монеты вообще можно потратить.

Как мы уже знаем, передача биткоинов – это создание неизрасходованного выхода транзакции (UTXO), зарегистрированного на получателя платежа. Каждая полная нода в сети Биткоин отслеживает множество (пул) нерастраченных выходов (UTXO).

Инструкция по генерации ключа электронной подписи

Обновление segregated witness

Цель: Сформировать представление о сути и задачах, выполняемых обновлением Segregated Witness (SegWit).

В 2021 году был активирован протокол Segregated Witness (SegWit) – самый крупный на сегодняшний день софтварный апгрейд в сети Биткоин, целью которого было дальнейшее масштабирование, снижение транзакционных комиссий и увеличение лимита блоков.

Для понимания проблемы, которую решает SegWit, необходимо внимательнее рассмотреть, как устроены биткоин-транзакции. Состоят они из двух главных частей: основных данных о транзакции, к которым, например, относится информация о том, какие именно перемещаются монеты и в каком направлении, и, так называемого, “свидетеля” (witness).

Речь идет о части кода (которую называют scriptSig, witness или же разблокирующий скрипт) с данными электронной подписи, служащей доказательством того, что владелец монет действительно хочет их потратить.

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

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

Разберемся в этих проблемах более основательно. Напомним, что идентификатор транзакции (он же хеш транзакции – txid) – это 64-разрядное шестнадцатеричное число (256 бит), которое представляет собой идентификационный номер, уникальный для каждой транзакции в блокчейне Биткоин. Такие же идентификаторы используются и в других платформах.

Например, идентификатор транзакции в сети Биткоин выглядит так:

Идентификатор транзакции в платформе Ethereum выглядит практически также:

Дискуссии о решении проблемы пластичности транзакций посредством “отделения” данных о подписи от остальных данных транзакции начались еще в январе 2021 года. Среди прочих в них принимали участие разработчики Bitcoin Core Расселл О’Коннор, Мэтт Коралло, Люк Дэш-младший и Грегори Максвелл, а также модератор форума Bitcointalk Theymos. Однако подходящего решения тогда так найдено и не было.

Segregated Witness (сокращенно SegWit) — обновление платформы Биткоин, призванное решить две основных проблемы данной криптовалюты. Речь идет об обеспечении пластичности транзакций блокчейна Биткоин, а также об увеличении пропускной способности системы.

Аналогичное по сути техническое решение реализовано и для целого ряда альткоинов, таких как Litecoin, DigiByte, Groestlcoin и Vertcoin. Обновление позволяет уменьшить размер транзакций, делая блоки более вместительными, а также снимает проблему пластичности (“изменчивости” transaction malleability), что очень важно для технологий наподобие платежных каналов или лайтнинга, полагающихся на строение транзакции сети Биткоин.

SegWit является “софт форком” (т.е. изменения сделаны на уровне программного обеспечения клиентов и не затронули сам блокчейн) и позволяет сети функционировать в прежнем режиме. При этом, он предусматривает изменение структуры, используемой для хранения информации в блоке и механизма валидации транзакций полными нодами.

https://www.youtube.com/watch?v=3LhSrA0wBrU

Для достижения цели данные, инкапсулирующие электронные подписи и блокирующие скрипты выделены в обособленную структуру под названием “отдельный свидетель” (англ. segregated witness). Поскольку размеры каждой транзакции стали существенно меньше, основные блоки способны вместить большее число транзакций.

Форк (от англ. Fork – вилка) – процесс, в результета которого создается альтернативная успешная версия блокчейна. Подобное может произойти умышленно – в случае сосредоточения под контролем группы майнеров вычислительных мощностей, достаточных для влияния на консенсус сети (атака 51%), случайно (когда нескольким майнерам одновременно удается записать новые блоки, что приведет к ветвлению блокчейна, или в результате ошибки системы), а также целенаправленно при решении команды разработчиков расширить функционал системы (или исправить ранее допущенные ошибки) в новых версиях клиентского программного обеспечения.

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

Также форком называют изменения протокола криптовалюты, приводящие к созданию двух различных версий блокчейна с единой историей.

Часто форком называют новую криптовалюту, основанную на протоколе действующей платежной платформы. Например, большинство известных криптовалют являются форками сети Биткоин.

Язык сценариев транзакций

Цель: Сформировать представление о языке сценариев транзакций Script в необходимом объеме.

Проверка валидности транзакции в сети Биткоин осуществляется на основе выполнения скрипта, записанного на специальном языке сценариев, называемым Script. Это Форт (Forth) – подобный стековый язык программирования с обратной польской нотацией, позволяющей избежать присутствия скобок и приоритетов в выражениях, что чрезвычайно удобно для вычисления формул в ЭВМ на основе стеков.

Важная особенность таких языков – использование стека для передачи параметров между термами, что позволяет очень гибко и просто реализовывать достаточно сложные конструкции. Отличительная особенность обратной польской нотации заключается в том, что аргументы располагаются перед знаком операции. Стек – это коллекция, элементы которой доступны согласно принципа “последний вошел, первый вышел” (“Last-In-First-Out”, LIFO). Т.е., в любой момент времени мы будем иметь дело только с элементом, добавленным последним (лежащим на вершине стека).

Неполнота по Тьюрингу для языка Script в первую очередь означает отсутствие циклов и сложных инструментов управления ходом выполнения кода. Для сети Биткоин данное свойство означает ограничение сложности сценариев и предсказуемое время их выполнения.

Это решение принято, исходя из соображений безопасности системы. Ограничения языка Script гарантируют отсутствие бесконечных циклов или других форм так называемых “логических бомб”, способных привести к атакам на отказ в обслуживании.

Почему в данном случае речь не идет о SMART-контрактах? Хотя некоторые принципы умных контрактов впервые были заложены именно в протоколе Биткоин, его платформа не может реализовать их в клиентском программном обеспечении по соображениям безопасности.

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

Он не является Тьюринг-полным, а сама платформа не имеет маркеров состояния, чтобы на их основе можно было проектировать приложения. К тому же пропускная способность сети Биткоин сильно ограничена, что также не позволяет создать систему многофункциональных контрактов.

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

Инструкции языка (всего их порядка 80) подразделяются на категории (управляющие, для работы со стеком, для работы со строковыми фрагментами, побитовые логические операции, арифметические, криптографические).

Например, оператор OP_ADD извлечет два операнда из стека, вычислит их сумму, и поместит полученный результат на вершину стека. А оператор OP_EQUAL извлекает два операнда из стека, сравнивает их и добавляет в стек результат сравнения (ИСТИНА (кодируется как цифра 1) – если операнды равны и ЛОЖЬ (кодируется как цифра 0) – в противном случае).

Рассмотрим пример скрипта для решения следующей задачи: проверить равна или нет числу 5 сумма двух чисел 2 и 3.

Сценарий решения этой простой задачи будет выглядеть следующим образом:

Логика выполнения сценария биткоин-клиентом демонстрируется на рисунке 3.2.

Транзакция признается действительной, если указатель стека принимает в итоге значениеTRUE (OP_TRUE), т.е. равен 1, или после выполнения скрипта, стек окажется пустым, или на его вершине окажется любое другое ненулевое значение.

Транзакция признается недействительными, если после выполнения скрипта на вершине стека окажется значениеFALSE (OP_FALSE), или выполнение сценария будет прервано оператором (например, OP_VERIFY, OP_RETURN), операторной скобкой (например, OP_ENDIF) и др.

https://www.youtube.com/watch?v=Ff2hcINdCzg

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

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

Разблокировать такой выход можно с помощью транзакции, вход которой содержит следующий скрипт разблокировки:

Программное обеспечение клиента объединяет блокирующий и разблокирующий сценарии, в результате чего получается уже знакомый нам скрипт:

Результат исполнения этого сценария равен OP_TRUE, следовательно, транзакцию следует считать действительной. Наверное, это не совсем надежная защита для заблокированных средств, поскольку выход с таким обременением может потратить любой, кто знает, что 2 3=5.