Эта инструкция потребляет те два элемента данных, которые находятся в верхней части стека.
И теперь стек содержит два элемента подпись и публичный ключ, который использовался для этой подписи.
Мы уже проверили, что этот публичный ключ является публичным ключом, который требуется, и теперь мы должны проверить, действительна ли подпись.
Это отличный пример того, как язык скриптов Bitcoin построен с учетом криптографии.
Несмотря на то, что это довольно простой язык с точки зрения логики, в нем есть некоторые довольно сильные инструкции, такие как инструкция «OP_CHECKSIG».
Эта инструкция выталкивает эти два значения из стека и выполняет всю проверку подписи за один раз.
Но чего это подпись?
Какой был вход функции подписи?
Оказывается, есть только одна вещь, которую вы можете подписать в биткойн это целая транзакция.
Таким образом, инструкция «CHECKSIG» выталкивает из стека два значения, открытый ключ и подпись, и проверяет, является ли эта подпись валидной для всей транзакции, используя этот публичный ключ.
Теперь мы выполнили каждую инструкцию в скрипте, и в стеке ничего не осталось.
Если ошибок не было, выход этого скрипта будет просто true, указывая, что транзакция действительна.
Теоретически, скрипт позволяет нам в каком-то смысле указать произвольные условия, которые должны быть выполнены для того, чтобы потратить монеты.
Но на сегодняшний день эта гибкость практически не используется.
Если мы посмотрим на скрипты, которые на самом деле были использованы в истории Биткойна, подавляющее большинство, 99,9 %, это точно такой же скрипт pay-to-public-key-hash, который мы использовали в нашем примере.
Как мы видели, этот скрипт pay-to-public-key-hash просто указывает один публичный ключ, вернее его хэш, и требует подписи для этого публичного ключа, чтобы потратить монеты.
Однако существуют несколько других инструкций, которые действительно полезны.
Иногда используется специальный тип скрипта под названием «Pay-to-Script-Hash», который обрабатывает мультиподписи MULTISIG и который мы обсудим позже.
Вообще говоря, не существует большого разнообразия используемых скриптов.
Это связано с тем, что узлы биткойнов по умолчанию имеют белый список стандартных скриптов, и они отказываются принимать скрипты, отсутствующие в списке.
Это не означает, что эти другие скрипты нельзя использовать вообще; это просто усложняет их использование.
На самом деле это различие это очень тонкая вещь, к которой мы вернемся, когда мы будем говорить об одноранговой сети Bitcoin.
Далее рассмотрим несколько видов стандартных скриптов.
Proof of burn доказательство сжигания это скрипт, в котором биткойны никогда не могут быть потрачены.
Отправка монет в скрипт с доказательством сжигания устанавливает, что они уничтожены, так как нет никакой возможности для их расходования.
Одно из использований доказательства сжигания заключается в том, чтобы загрузить альтернативу биткойну, заставив людей уничтожить биткойн, чтобы получить монеты в новой системе.
Мы обсудим это более подробно позже.
Доказательство сжигания довольно просто реализовать: опкод OP_RETURN выбрасывает ошибку и маркирует транзакцию как недействительную.
Таким образом, любая новая транзакция, которая попытается использовать выход с OP_RETURN, будет недействительной и не будет учитываться в блокчейне.
Независимо от того, какие значения вы ставите перед OP_RETURN, эта инструкция будет выполнена и скрипт вернет false.
Так как выбрасывается ошибка, данные в скрипте, которые появляются после OP_RETURN, не будут обрабатываться.
Таким образом, это также возможность помещать произвольные данные в скрипт и, следовательно, в цепочку блоков.
Если по какой-то причине вы хотите написать свое имя или хотите установить отметку времени и доказать, что знаете определенные данные в определенное время, тем самым, например, внести доказательство авторских прав на документ, вы можете создать транзакцию биткойнов с очень малой суммой и инструкцией OP_RETURN.
Вы можете уничтожить очень маленькую сумму валюты, но вы можете написать все, что захотите, в цепочку блоков, которая будет храниться всегда.
Теперь о скрипте Pay-to-script-hash.
Механизм работы скриптов Биткойна подразумевает, что отправитель монет должен точно указать скрипт.
Но это иногда становится затруднительным.
Скажем, например, вы являетесь покупателем интернет-магазина, и вы собираетесь что-то заказать.
И вы говорите: «Хорошо, я готов заплатить. Скажите мне адрес, на который я должен отправить свои монеты».
Теперь предположим, что компания, в которой вы заказываете товар, использует адрес MULTISIG с несколькими приватными ключами, то есть для их подписи используются несколько приватных ключей для дополнительной защиты.
Затем, так как вы должны указать это, продавец должен будет сказать вам: «Мы используем MULTISIG, и мы попросим вас отправить монеты с использованием сложного скрипта».
На что вы могли бы сказать: «Я не знаю, как это сделать. Это слишком сложно. Как потребитель, я просто хочу отправить монеты на простой адрес».
Для решения этой проблемы, в биткойне есть умный хак.
Вместо того, чтобы отправитель указывал весь скрипт, отправитель может указать только хэш скрипта, который понадобится для последующей траты этих монет.
Поэтому отправителю нужно просто указать очень простой скрипт, который просто хэширует верхнее значение в стеке и проверяет, соответствует ли оно требуемому скрипту траты монет.
Получателю этих монет необходимо указать в качестве значения данных, сам скрипт, чей хэш указан отправителем.
После этого произойдет второй этап проверки.
То есть, верхнее значение данных из стека будет переинтерпретировано в качестве инструкций, а затем оно будет выполняться во второй раз уже как скрипт.
Итак, мы видим, что здесь выполняются два этапа.
Сначала это был традиционный скрипт, который проверял, что скрипт потребления монет имеет правильный хеш.
И после этого скрипт потребления монет де-сериализуется и запускается как скрипт.
Сначала это был традиционный скрипт, который проверял, что скрипт потребления монет имеет правильный хеш.
И после этого скрипт потребления монет де-сериализуется и запускается как скрипт.
И вот где будет происходить фактическая проверка подписи.
Создание поддержки для этого типа скриптов P2SH было довольно сложным, поскольку этот тип скриптов не был частью первоначальной спецификации Bitcoin.
Он был добавлен позже.
Это, вероятно, самая известная функция, добавленная в биткойн, которой не было в исходной спецификации.
И она решает несколько важных проблем.
Она облегчает жизнь отправителю, так как получатель может просто указать хэш, на который отправитель отправляет деньги.
В нашем примере, Алисе не нужно беспокоиться о том, что Боб использует multisig, она просто отправляет деньги на адрес P2SH Боба, и ответственность Боба заключается в том, чтобы указать этот сложный скрипт, когда он хочет потратить монеты.
P2SH также ускоряет обработку.
Так, майнерам нужно отслеживать набор выходных скриптов, которые еще не были потрачены, а с P2SH выходные скрипты намного меньше, так как они указывают только хеш.
Вся сложность переносится на входные скрипты.
Теперь, когда мы понимаем, как работают скрипты Bitcoin, давайте взглянем на некоторые из применений, которые могут быть реализованы с помощью этого языка сценариев.
Оказывается, что мы можем делать много полезных вещей, которые оправдывают использование языка сценариев вместо того, чтобы просто указывать публичные ключи.
Рассмотрим транзакцию условного депонирования это депонирование определенной суммы покупателем у третьего лица под определенные условия при сомнениях в добросовестности продавца.
Скажем, Алиса и Боб хотят вести дела друг с другом Алиса хочет заплатить Бобу в Биткойнах, чтобы Боб отправил некоторый физический товар Алисе.
Проблема в том, что Алиса не хочет платить до тех пор, пока она не получит товар, а Боб не хочет отправлять товар до тех пор, пока он не будет оплачен.
Что мы можем с этим поделать?
Хорошим решением в биткойне, которое можно было бы использовать на практике, является введение третьей стороны и транзакция с депонированием.
Транзакция с депонированием может быть реализована достаточно просто с использованием мультиподписи MULTISIG.
Алиса не отправляет деньги непосредственно Бобу, а вместо этого создает транзакцию MULTISIG, для которой требуется два из трех человек, чтобы потратить монеты.
И эти три человека будут Алисой, Бобом, и некоторым сторонним арбитром Джуди, который вступит в игру, если возникнут какие-либо споры.
Поэтому, Алиса создает 2-из-3 транзакцию MULTISIG, которая отправляет некоторое количество монет, которыми она владеет, и указывает, что они могут быть потрачены, если будут две подписи из трех Алисы, Боба и Джуди.
Эта транзакция включена в цепочку блоков, и на данный момент эти монеты хранятся в депонировании между Алисой, Бобом и Джуди, так что любые два из них могут указать, куда должны уйти монеты.
В этот момент Боб убежден, что безопасно отправить товар Алисе, поэтому он отправит его по почте или каким-то другим способом.
Теперь, предположим, Алиса и Боб оба честны.
Поэтому Боб отправит товар, который ожидает Алиса, и когда Алиса получит товар, Алиса и Боб подпишут транзакцию, потратив средства из депонирования и отправив их Бобу.
Обратите внимание, что в этом случае, когда Алиса и Боб честны, Джуди не нужно вмешиваться.
Не было никакого спора, и подписи Алисы и Боба соответствовали требованию 2-из-3 транзакции MULTISIG.
Так что в нормальном случае это ничем не отличается, как если бы Алиса просто отправила бы Бобу деньги, но это требует одной дополнительной транзакции.
Но что могло бы произойти, если бы Боб не отправил товар или товар потерялся бы на почте?
Или, может быть, товар отличался бы от того, который заказывала Алиса?
Алиса теперь не хочет платить Бобу, потому что думает, что ее обманули, и она хочет вернуть свои деньги.
Поэтому Алиса определенно не собирается подписывать транзакцию, которая передает деньги Бобу.
Но Боб также может отрицать любые нарушения и отказываться подписывать транзакцию, которая возвращает деньги Алисе.
Здесь необходимо принять участие Джуди.
Джуди придется решить, кто из этих двух людей заслуживает денег.
Если Джуди решит, что Боб обманул, Джуди подпишет сделку вместе с Алисой, отправив деньги с эсквота обратно Алисе.