Глава 01 - OP_CHECKCRYPTOCONDITION

Глава 1 - OP_CHECKCRYPTOCONDITION
В предыдущей главе были объяснены UTXO. Однако конкретный механизм, используемый для отправки платежа, не объяснялся. Вопреки тому, что, думает большинство людей, на блокчейне нет записей в духе "заплати сумму X на такой-то адрес". Вместо этого существует биткоин-скрипт (https://en.bitcoin.it/wiki/Script), который должен быть удовлетворен для того, чтобы средства могли быть потрачены.

Первоначально в нем была оплата на pubkey (публичный ключ) скрипт:
EN: <pubkey> <checksig>
RU: <публичный ключ> <проверка валидности подписи транзакции>

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

Однако это общепринято и текущий скрипт:
EN: <hash the pubkey> <pubkey> <verify hash matches> <checksig>
RU: <хэш публичного ключа> <публичный ключ> <подтверждение совпадение хэшей> <проверка валидности подписи транзакции>

При этом блокчейн имеет то, что образует пару с "платежом на адрес", а имеено то, что адрес на самом деле закодирован в варианте Base58 (prefix + pubkeyhash, https://ru.wikipedia.org/wiki/Base58). Эй, если бы это было не сложно - это было бы легко!

Чтобы потратить p2pkh (pay to pubkey hash, хэш платежа на публичный ключ) UTXO, вам нужно разгласить публичный ключ в дополнение к валидной подписи. После первой траты с адреса его безопасность деградирует до p2pk (pay to pubkey, платеж на публичный ключ) так как теперь ее публичный ключ известен. Конечным результатом является то, что каждый повторно используемый адрес занимает 25 дополнительных байт в блокчейне, и это причина по которой для адресов с ожидаемым повторным использованием я просто использую p2pk скрипт.

Изначально биткоин позволял любой тип скриптов кодов операций (opcodes) для прямого использования. Трудность была в том, что некоторые из них вызывали проблемы и Сатоши решил отключить их и разрешить только стандартные формы платежей. Так p2pk и p2pkh стали 99%+ транзакций Bitcoin. Однако, переход от наличия полностью скритового языка который может создавать бесчисленные платежные скрипты (и баги!), чтобы иметь всего 2 (скрипта)... ну, это было "краткосрочное" ограничение. Это продолжалось в течение нескольких лет, но в конечном итоге компромиссный p2sh скрипт был признан стандартом. Это платеж хэшу скрипта (script hash), то есть он может обладать стандартным форматом как нормальный p2pkh, но иметь бесконечно больше гибкости.
EN: <hash the script> <script> <verify hash matches>
RU: <хэш скрипта> <скрипт> <подтверждение совпадения хэша>

Подождите, что-то не так! Если бы все было бы действительно так, тогда любой кто нашел требуемый скрипт (называемый redeemscript, скрипт высвобождения платежа) мог бы просто потратить транзакцию. Я забыл сказать что redeemscript затем используется чтобы оопределить был ли потрачен платеж или нет. Таким образом вы можете иметь нормальный p2pk либо p2pkh redeemscript внутри p2sh скрипта.

Окей, я знаю что это реально запутанно. Давайте посмотрим на более понятный пример:

redeemscript <- pay to pubkey

p2sh становится хэшом высвобождающего скрипта + сравнения

Поэтому, чтобы потратить его, вам нужно разгласить reedemscript, который, в свою очередь, требует от вас разглашения pubkey. Смешайте это все вместе и p2sh механизм  не только подтверждает сравнением хэша то, что у вас есть корректный reeedemscript, но и то, что когда reedemsctipt запущен он удовлетворен.  В этом случае подпись публичного ключа валидна.
Если вы все еще следите за нитью рассуждений - есть хорошие новости! OP_CHECKCRYPTOCONDITION скрипты на самом деле в некотором смысле проще чем p2sh скрипты, поскольку не имеют дополнительного уровня скриптов внутри scripthash. @libscott реализовал добавление OP_CHECKCRYPTOCONDITION в набор функций (opcodes) Bitcoin и что он делает, так это убеждается в том, что CryptoConditions скрипт правильно подписан.

Что дает нам спецификацию CryptoConditions, монстр от проекта IETF (Internet standards) с сотнями страниц спецификации. Я уверен что вы будете рады узнать что вам не требуется знать о ней много! Просто знайте, что вы можете создавать всевозможные cryptoconditions а его двоичное представление может быть использовано в UTXO Bitcoin. Если стандартные CC контракты не обладают необходимой вам мощностью, всегда возможно их всегда можно расширить. Пока что большинству CC контрактов требуется мощщность только 1из1 CC скрипта, в котором 1 подпись сочетается с заданными ограничениями. CC каналов оплаты в режиме реального времени  - единственный из стандартных CC контрактов, который не вписывался в эту модель, для него нужен 1из2 CC скрипт.

Самое приятное это то, что все эти вещи на уровне opcodes вообще не требуются. Я просто хотел объяснить это тем, кто хочет знать все в деталях.