Биткоин скрипт: Курс Биткоина Скрипт (Bitcoin Scrypt) к доллару на сегодня, курс Биткоина Скрипт к рублю — цена BTCS — график курса Биткоина Скрипт

• 21 июля 2020 г. : переименовано / руководство / в / техническое /

GitHub — openblockchains / программирование-биткойн-скрипт: Программирование транзакций биткойн-скрипта (крипто), шаг за шагом

Дополнительные книги по блокчейнам см. На странице Лучшее из криптографических книг »

Давайте начнем с создания вашей собственной машины стека биткойнов с нуля / с нуля и запустим ваши собственные операции (операции) с биткойнами…

ОСТОРОЖНО: Биткойн — это гигантская схема Понци¹. На Луну!? Новый золотой стандарт !? НЕ «инвестируйте», пытаясь быстро разбогатеть HODLING. Почему нет? Код биткойна архаичен и устарел. Гори детка Гори! Proof-of-Work / Waste — это глобальная энергетическая экологическая катастрофа используя 300 кВтч на транзакцию биткойнов (!), это около 179 килограммов выбросов CO₂². Программируемые деньги (или Интернет ценности) для всех будущих поколений со скриптом (биткойн) без петель и скачков (gotos) и всего «без состояния» !? РЖУНИМАГУ.

¹:

(Источник: Best of Bitcoin Maximalist — Мошенники, дебилы, клоуны, шиллы и багходлеры — Inside The New New Crypto Ponzi Economics)

²: Предположим, 0,596 кг CO₂ на кВтч. (это энергоэффективность в Германии) это около 179 килограммов CO₂ на транзакцию с биткойнами (300 кВт · ч × 0,596 кг). Для получения дополнительной информации см. Индекс потребления энергии биткойнами.

Внутри Биткойн-скрипта

Знаете ли вы? Каждая (да, каждая) биткойн-транзакция (платеж) выполняется сценарий контракта (одна половина поступает из транзакции «вывода» или «блокировки», а другая половина поступает из транзакции «ввод» или «разблокировка»).Язык программирования называется просто (биткойн) скриптом.

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

(Источник: Script @ Bitcoin Wiki)

Первое впечатление. Добавление 2 + 2 в биткойн-скрипт, начиная с нуля / с нуля:

 ## Простой штабелеукладчик
def op_add (стек)
  left = stack.pop
  справа = стек.поп
  stack. push (влево + вправо)
конец

def op_2 (стек)
  stack.push (2)
конец

## Давайте работать!

стек = []
op_2 (стек) # => стек = [2]
op_2 (стек) # => стек = [2,2]
op_add (stack) # => stack = [4] 

(Источник: stackmachine_add.rb )

Да вот и все волшебство! Вы создали свою собственную стековую машину с две операции / операции, то есть op_add и op_2 .

Операция op_2 помещает в стек число 2 .Операция op_add извлекает два верхних числа из стека. и помещает результат в стек.

В сторону — Что такое стек? Push ‘n’ Pop

Стек — это структура данных типа «последний пришел — первый вышел» (LIFO). Используйте push чтобы добавить элемент в верхнюю часть стека и использовать pop чтобы удалить верхний элемент из стека. Пример:

 стек = [] # => []
stack.empty? # => верно

stack.push (1) # => [1]
стек.пустой? # => ложь
stack.push (2) # => [1, 2]
stack. push (3) # => [1, 2, 3]
stack.push ("") # => [1, 2, 3, ""]
stack.push ("") # => [1, 2, 3, "", ""]

stack.pop # => ""
стек # => [1, 2, 3, "<подпись>"]
stack.pop # => "<подпись>"
стек # => [1, 2, 3]

стек.push (4) # => [1, 2, 3, 4]
stack.push (5) # => [1, 2, 3, 4, 5]

stack.pop # => 5
стек # => [1, 2, 3, 4]
stack.pop # => 4
стек # => [1, 2, 3]
stack.pop # => 3
стек # => [1, 2]
stack.pop # => 2
стек # => [1]
stack.empty? # => ложь
stack.pop # => 1
стек # => []
стек.пустой? # => верно
stack.pop # => nil 

(Источник: stack.rb )

Разблокировка + Блокировка / Ввод + Вывод / ScriptSig + ScriptPubKey

В «реальном мире» биткойн скрипт состоит из двух частей / половин в двух транзакциях. которые объединяются. Сценарий «блокировка», «вывод» или «ScriptPubKey» который блокирует «неизрасходованный вывод транзакции (UTXO)», и сценарий «разблокировать», «ввод» или «ScriptSig», который разблокирует биткойны.

Кто угодно может потратить (разблокировать) выходы (биткойны)

Биткойны ваши, если биткойны еще не потрачены — посмотреть блокчейн и как он решает проблему двойных расходов 🙂 — И если сценарий возвращает значение true, то есть 1 находится на вершине стека.

 ## Простой штабелеукладчик
def op_true (стек)
  stack.push (1)
конец

## Давайте работать!

стек = []
## I) Часть ScriptSig (ввод / разблокировка)
op_true (стек) # => стек = [1]

## II) Часть ScriptPubKey (вывод / блокировка)
## <Пусто> 

(Источник: stackmachine_anyone.rb )

Бинго! Да вот и все волшебство! Операция op_true помещает в стек число 1 , то есть true .

«Официальная» нотация сценария биткойнов:

  ScriptSig (ввод): OP_TRUE
ScriptPubKey: (пусто)
  

Теперь давайте разделим сценарий сложения 2 + 2 на головоломку из двух частей: то есть ? + 2 = 4 или в ScriptSig и ScriptPubKey . Если вы знаете ответ, вы можете «разблокировать» награду, то есть биткойны ваши! Вот вызов:

 ## Простой штабелеукладчик
def op_add (стек)
  left = stack.pop
  right = stack.pop
  stack.push (влево + вправо)
конец

def op_2 (стек)
  stack.push (2)
конец

def op_4 (стек)
  stack.push (4)
конец

def op_equal (стек)
  left = stack.pop
  right = stack.pop
  stack.push (слева == справа? 1: 0)
конец

## Давайте работать!

стек = []
## I) Часть ScriptSig (ввод / разблокировка)
## ИСПРАВИТЬ !!! - добавьте сюда свою операцию / операции "разблокировки" стека

## II) Часть ScriptPubKey (вывод / блокировка)
op_2 (стек) # => стек = [?, 2]
op_add (стек) # => стек = [4]
op_4 (стек) # => стек = [4,4]
op_equal (стек) # => стек = [1] 

(Источник: stackmachine_puzzle.руб. )

«Официальная» нотация сценария биткойнов:

  ScriptSig (ввод):?
ScriptPubKey: OP_2 OP_ADD OP_4 OP_EQUAL
  

Если вы проверите все операции сценария Биткойн — следующие операции больше не должны быть загадкой:

Константы

Слово	Код операции	Шестигранник	Вход	Выход	Описание
OP_0, OP_FALSE	0	0x00	Ничего.	(пустое значение)	В стек помещается пустой массив байтов. (Это не бездействие: элемент добавляется в стек.)
OP_1, OP_TRUE	81	0x51	Ничего.	1	Число 1 помещается в стек.
OP_2-OP_16	82-96	0x52-0x60	Ничего.	2-16	Число в слове name (2-16) помещается в стек.

Побитовая логика

Арифметические

Слово	Код операции	Шестигранник	Вход	Выход	Описание
OP_ADD	147	0x93	а б	из	a добавлен к b.
OP_MUL	149	0x95	а б	из	a умножается на b. отключен.
OP_DIV	150	0x96	а б	из	a делится на b. отключен.

Trivia Corner: Знаете ли вы? OP_MUL для умножения (например, 2 * 2 ) был забанен, то есть отключен! Зачем? Из соображений безопасности, то есть из-за боязни переполнения стека.Как насчет OP_DIV для подразделений (например, 4/2 )? Не спрашивайте! Спросите, кто защищает вас от переполнения стека? Итак, что осталось для программирования — не более того, кроме проверки подписи и таймеры :-).

Стандартные сценарии

Необязательно начинать с нуля / с нуля. Биткойн имеет множество стандартных шаблонов сценариев. К наиболее важным относятся:

Стандартные сценарии с SegWit (Segregated Witness)

p2pk — Pay-to-pubkey

Pay-to-pubkey (p2pk) — простейший стандартный скрипт и использовался в первые дни в том числе Сатоши Накамото (псевдоним основателя Биткойна).

Биткойн Общая информация:

Первоначально единственный, а впоследствии и основной горнодобывающий, Накамото был награжден биткойнами при создании и на 10 дней после этого. За исключением тестовых транзакций, они остаются неизрасходованными с середины января 2009 года. Общедоступный журнал транзакций биткойнов показывает, что известные адреса Накамото содержат примерно один миллион биткойнов. На пике биткойнов в декабре 2017 года это стоило более 19 миллиардов долларов США, что сделало Накамото, возможно, 44-м самым богатым человеком в мире в то время.

(Источник: Сатоши Накамото @ Wikipedia)

Один миллион биткойнов — ваш, если скрипт pay-to-pubkey (p2pk) возвращает истину, то есть 1 находится на вершине стека. Единственный вход, который вам нужен, чтобы разблокировать удачу, — это подпись. Вы Сатоши? Попробуем:

 ## Биткойн-крипто-помощник

класс Биткойн
  def self.checksig (сиг, pubkey)
    ## "крипто" магия здесь
    ## для тестирования пока всегда возвращать false; Извините
    ложный
  конец
конец


## Простая стековая машина

def op_checksig (стек)
  pubkey = стек. поп
  sig = stack.pop
  если Bitcoin.checksig (sig, pubkey)
    stack.push (1)
  еще
    stack.push (0)
  конец
конец

## Давайте работать!

стек = []
## I) Часть ScriptSig (ввод / разблокировка)
stack.push ("") # => stack = [""]

## II) Часть ScriptPubKey (вывод / блокировка)
stack.push (" stack = ["", ""]
op_checksig (стек) # => stack = [0] 

(Источник: pay-to-pubkey.rb )

Бинго! Да вот и все волшебство! Операция op_checksig извлекает два элемента из стек, то есть открытый ключ (pubkey) и подпись (подпись) и если криптографическая кривая подтверждает подпись (из транзакции ввода / разблокировки) с использованием открытого ключа (из транзакции вывода / блокировки) тогда удача твоя! Если не число 0 , то есть false помещается в стек и тебе не повезло.Сожалею.

«Официальная» нотация сценария биткойнов:

  ScriptSig (ввод): 
ScriptPubKey:  OP_CHECKSIG
  

Примечание: Можете ли вы угадать, где часть ввода / разблокировки получила свое имя ScriptSig и где часть вывода / блокировки получила свое имя ScriptPubKey? Да, из скрипта pay-to-pubkey.

В сторону — Айви — язык сценариев биткойнов более высокого уровня

Что такое Айви?

Из ридми проекта:

Ivy — это язык более высокого уровня, позволяющий писать (крипто) контракты. для протокола Биткойн.Айви может компилировать коды операций для стековой машины Биткойн, Биткойн-скрипт и может использоваться для создания биткойн-адресов, совместимых с SegWit …

Вы можете попробовать Ivy, используя Ivy Playground для биткойнов, который позволяет вам создавать тестовые контракты и пытаться их потратить, все в изолированной среде.

(Источник: документация по языку Ivy)

Давайте посмотрим на скрипт pay-to-pubkey в Ivy:

  контракт LockWithPublicKey (publicKey: PublicKey, val: Value) {
  статья о расходах (sig: Signature) {
    проверить checkSig (publicKey, sig)
    разблокировать val
  }
}
  

И — сюрприз, сюрприз — скрипт более высокого уровня компилируется в

   OP_CHECKSIG
  

Криптография с эллиптическими кривыми

Так как же выглядит открытый ключ «реального мира» (pubkey)? В первые дни Сатоши Накамото использовался несжатый формат SEC (стандарты эффективной криптографии) для открытого ключа, который приводит в 65 необработанных байтах. Биткойн использует эллиптическую кривую криптография и открытый ключ — точка (x, y) на кривая, где координаты x и y представляют собой 256-битные (32 байтовые) числа.

В несжатом формате разместите координаты x и y рядом друг с другом, затем используйте префикс 04 , чтобы указать, что это несжатый открытый ключ:

  префикс (1 байт): 04
Координата x (32 байта): fe53c78e36b86aae8082484a4007b706d5678cabb92d178fc95020d4d8dc41ef
Координата Y (32 байта): 44cfbb8dfa7a593c7910a5b6f94d079061a7766cbeed73e24ee4f654f1e51904
    =>
04fe53c78e36b86aae8082484a4007b706d5678cabb92d178fc95020d4d8dc41ef44cfbb8dfa7a593c7910a5b6f94d079061a7766cbeed73e24ee4f654f1e51904
  

А в сжатом виде, потому что эллиптическая кривая симметрична вдоль оси x, фокус в том, что каждая координата x будет иметь только одну из двух возможных координат y:

• Если y четно, он соответствует одной из точек.
• Если y нечетное, оно соответствует другому.

Таким образом, в формате сжатого открытого ключа поместите координату x вместе с префиксом ( 02 или 03 ) который сообщает, является ли y четным ( 02 ) или нечетным ( 03 ).

  префикс (1 байт): 03
Координата x (32 байта): df51984d6b8b8b1cc693e239491f77a36c9e9dfe4a486e9972a18e03610a0d22
     =>
03df51984d6b8b8b1cc693e239491f77a36c9e9dfe4a486e9972a18e03610a0d22
  

Создадим публичный ключ из приватного

Примечание. Давайте воспользуемся сторонним алгоритмом цифровой подписи с эллиптической кривой (ECDSA). библиотека / драгоценный камень Дэвида Грейсона.

 требуется 'pp'
require 'ecdsa' # Использовать библиотеку эллиптических кривых

# Этот закрытый ключ - всего лишь пример. Это должно быть намного безопаснее!
privatekey = 1234

# Умножение эллиптических кривых
group = ECDSA :: Group :: Secp256k1 # Выберите кривую, используемую в биткойнах
point = group.generator.multiply_by_scalar (privatekey) # Умножить на целое (не шестнадцатеричное)
# => fc05c2d068ff1d38b304c>  # Несжатый формат (с префиксом 04)
# Преобразовать в 64 символа шестнадцатеричной строки (32 байта) в длину
префикс = '04'
pubkey = prefix + "% 064x"% балл. x + "% 064x"% point.y
# => "04e37648435c60dcd181b3d41d50857ba5b5abebe279429aa76558f6653f1658f26d2ee9a82d4158f164ae653e9c6fa7f982ed8c

(Источник: pubkey.руб. )

p2pkh — Pay-to-pubkey-hash

…

В сторону — что такое Hash260?

Это хеш-функция для хеширования и сокращения открытых ключей. Открытые ключи если без сжатия сократите с 65 до 20 байт (или если сжат из 33 байтов). Пример:

  pubkey = 02b4632d08485ff1df2db55b9dafd23347d1c47a457072a1e87be26896549a8737
hash260 (pubkey) = 93ce48570b55c42c2af816aeaba06cfee1224fae
  

Для вычисления Hash260 запустите открытый ключ с помощью хэш-функций SHA256 и RIPEMD160. Пример:

 require 'digest' # Функции хеширования (дайджеста)

def hash260 (pubkey)
  binary = [pubkey] .pack ("H *") # Сначала преобразовать в двоичный код перед хешированием
  sha256 = Дайджест :: SHA256.digest (двоичный)
  ripemd160 = Дайджест :: RMD160.digest (sha256)
              ripemd160.unpack ("H *") [0] # Преобразовать обратно в шестнадцатеричный формат
конец

pubkey = "02b4632d08485ff1df2db55b9dafd23347d1c47a457072a1e87be26896549a8737"
hash260 (pubkey)
# => "93ce48570b55c42c2af816aeaba06cfee1224fae" 

(Источник: hash260.руб. )

Вопросы безопасности I. Зачем использовать SHA256 и RIPEMD160?

RIPEMD160 используется, потому что приводит к короткий 160-битный (20 байт) дайджест, НО сам по себе не самая сильная хэш-функция, таким образом, SHA256 используется для большей силы. Лучшее из обоих миров.

Security Trivia II: Что такое RIPEMD160?

Дайджест сообщения оценки примитивов целостности RACE¹ 160 бит

¹: Исследования и разработки в области передовых коммуникационных технологий в Европе

 def ripemd160 (сообщение)
  Дайджест :: RMD160. hexdigest (сообщение)
конец

ripemd160 («Быстрая коричневая лисица перепрыгивает через ленивого пса»)
# => "37f332f68db77bd9d7edd4969571ad671cf9dd3b"

ripemd160 («Быстрая коричневая лисица перепрыгивает через ленивую шестеренку»)
# => "132072df6835eb8b6ad0b77e7b6f14acad7"

# Хеш строки нулевой длины:
ripemd160 ("")
# => "9c1185a5c5e9fc54612808977ee8f548b2258d31" 

(Источник: RIPEMD @ Wikipedia)

…

«Официальная» нотация сценария биткойнов:

  ScriptSig (вход):  
ScriptPubKey: OP_DUP OP_HASh260  OP_EQUALVERIFY OP_CHECKSIG
  

И версия более высокого уровня Ivy читает:

  контракт LockWithPublicKeyHash (pubKeyHash: Hash260 (PublicKey), val: Value) {
  статья о расходах (pubKey: PublicKey, sig: Signature) {
    проверить hash260 (pubKey) == pubKeyHash
    проверить checkSig (pubKey, sig)
    разблокировать val
  }
}
  

, который компилируется в

  OP_DUP OP_HASh260  OP_EQUALVERIFY OP_CHECKSIG
  

Продолжение следует…

Приложение

В сторону — Простота — новый контрактный язык биткойнов?

Simplicity — язык программирования блокчейн разработан как альтернатива биткойн-скрипту.

(Источник: Simplicity README)

Почему простота?

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

(Источник: Simplicity: High-Assurance Bitcoin Contract Scripting, Рассел О’Коннор, Эндрю Поелстра, Blockstream Research, ноябрь 2018 г.)

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

Simplicity — это типизированный, основанный на комбинаторах функциональный язык без циклы и рекурсия, предназначенные для использования в криптовалютах и блокчейн-приложения. Он направлен на улучшение существующих языков криптовалюты, такие как скрипт биткойна, твердость эфириума или ликвидность Майкельсона, избегая при этом некоторых проблем, с которыми они сталкиваются.Простота приходит с формальным обозначением семантика, определенная в Coq, популярном помощнике по проверке программного обеспечения общего назначения. Простота также включает операционную семантику, которая определяется с абстрактной машиной, которую мы называем Битовой машиной. Битовая машина используется как инструмент для измерения вычислительного пространства и времени. ресурсы, необходимые для оценки программ Simplicity. Благодаря его Тьюрингу неполнота, простота поддается статическому анализу, который можно использовать для получения верхних границ требуемых вычислительных ресурсов до исполнение.В то время как Тьюринг неполный, простота может выразить любое конечное функции, которой, по нашему мнению, достаточно для создания полезных контрактов для блокчейн-приложения.

(Источник: Технический документ Simplicity (PDF) Рассела О’Коннора, Blockstream, декабрь 2017 г.)

ресурсов

Статьи

Книги / Серия

• Программирование Биткойн с нуля Джимми Сонг
  • Глава 6 — Сценарий — Как работает скрипт • Примеры операций • Анализ полей скрипта • Объединение полей скрипта • Стандартные скрипты • p2pk • Проблемы с p2pk • Решение проблем с p2pkh • Сценарии могут быть созданы произвольно • Заключение
  • Глава 8 — Хеширование Pay-to-Script — Голая мульти-подпись • Кодирование OP_CHECKMULTISIG • Проблемы с Голой Мультиподписной • Pay-to-Script-Hash (p2sh) • Кодирование p2sh • Заключение
  • Глава 13 — Изолированный свидетель — Pay-to-Witness-Pubkey-Hash (p2wpkh) • Транзакции p2wpkh • p2sh-p2wpkh • Кодирование p2wpkh и p2sh-p2wpkh • Pay-to-Witness-Script-Hash (p2wsh) • p2sh-p2wsh • Кодирование p2wsh и p2sh-p2wsh • Другие улучшения • Заключение

Обсуждение

Код

Лицензия

Пошаговая книга / руководство по программированию биткойн-скрипта посвящен общественному достоянию.Используйте его как хотите, без каких-либо ограничений.

5. Транзакции — освоение биткойнов [Книга]

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

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

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

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

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

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

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

Трансляция транзакций в сеть биткойнов

Во-первых, транзакция должна быть доставлена ​​в сеть биткойнов, чтобы ее можно было распространить и включить в цепочку блоков.По сути, биткойн-транзакция — это всего лишь от 300 до 400 байтов данных и должна достигнуть любого из десятков тысяч биткойн-узлов. Отправителям не нужно доверять узлам, которые они используют для широковещательной передачи транзакции, если они используют более одного, чтобы гарантировать ее распространение. Узлам не нужно доверять отправителю или устанавливать «личность» отправителя. Поскольку транзакция подписана и не содержит конфиденциальной информации, закрытых ключей или учетных данных, ее можно публично транслировать с использованием любого удобного базового сетевого транспорта.В отличие, например, от транзакций по кредитным картам, которые содержат конфиденциальную информацию и могут быть переданы только в зашифрованных сетях, транзакция с биткойнами может быть отправлена ​​по любой сети. Пока транзакция может достичь узла биткойнов, который распространит ее в сеть биткойнов, не имеет значения, как она передается на первый узел.

Биткойн-транзакции могут быть переданы в биткойн-сеть через небезопасные сети, такие как Wi-Fi, Bluetooth, NFC, Chirp, штрих-коды или путем копирования и вставки в веб-форму.В крайних случаях транзакция биткойнов может быть передана по пакетной радиосвязи, спутниковой ретрансляции или коротковолновой передаче с использованием пакетной передачи, расширенного спектра или скачкообразной перестройки частоты, чтобы избежать обнаружения и помех. Биткойн-транзакцию можно даже закодировать в виде смайлов (смайликов) и опубликовать на публичном форуме или отправить в виде текстового сообщения или сообщения в чате Skype. Биткойн превратил деньги в структуру данных, что сделало практически невозможным остановить кого-либо от создания и выполнения транзакции с биткойнами.

Распространение транзакций в сети Биткойн

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

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

Биткойн-сеть предназначена для распространения транзакций и блоков на все узлы эффективным и отказоустойчивым способом, устойчивым к атакам.Чтобы предотвратить рассылку спама, атаки типа «отказ в обслуживании» или другие нежелательные атаки на систему биткойнов, каждый узел независимо проверяет каждую транзакцию перед ее дальнейшим распространением. Деформированная транзакция не выйдет за пределы одного узла. Правила проверки транзакций более подробно описаны в разделе «Независимая проверка транзакций».

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

Таблица 5-1. Структура транзакции

1–9 байт (VarInt)

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

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

Наконечник

Нет счетов или остатков в биткойнах; есть только неизрасходованных выходов транзакций (UTXO), разбросанных по блокчейну.

UTXO может иметь произвольное значение, кратное сатоши. Точно так же, как доллары можно разделить до двух знаков после запятой, как центы, биткойны можно разделить до восьми знаков после запятой, как сатоши.Хотя UTXO может иметь любое произвольное значение, однажды созданное оно неделимо, как монета, которую нельзя разрезать пополам. Если UTXO больше, чем желаемое значение транзакции, он все равно должен быть использован полностью, и в транзакции должны быть сгенерированы изменения. Другими словами, если у вас есть 20 биткойнов UTXO и вы хотите заплатить 1 биткойн, ваша транзакция должна потреблять все 20 биткойнов UTXO и давать два результата: один платит 1 биткойн вашему желаемому получателю, а другой платит 19 биткойнов в обмен на ваш бумажник.В результате большинство транзакций с биткойнами вызовут изменения.

Представьте себе покупательницу, которая покупает напиток за 1,50 доллара, залезает в бумажник и пытается найти комбинацию монет и банкнот, чтобы покрыть стоимость за 1,50 доллара. Покупатель выберет точную сдачу, если таковая имеется (долларовая банкнота и две четверти), или комбинацию меньшего достоинства (шесть четвертей), или, если необходимо, более крупную денежную единицу, такую ​​как пятидолларовая банкнота. Если она отдаст владельцу магазина слишком много денег, скажем 5 долларов, она будет ожидать 3 доллара.50 сдачи, которые она вернет в свой кошелек и будет доступна для будущих транзакций.

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

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

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

Исключением из цепочки вывода и ввода является специальный тип транзакции, называемый транзакцией coinbase , которая является первой транзакцией в каждом блоке. Эта транзакция размещается там «выигравшим» майнером и создает совершенно новый биткойн, подлежащий выплате этому майнеру в качестве вознаграждения за майнинг.Вот как создается денежная масса биткойна в процессе майнинга, как мы увидим в главе 8.

Совет

Что первично? Входы или выходы, курица или яйцо? Строго говоря, выходы на первом месте, потому что транзакции на базе монет, которые генерируют новый биткойн, не имеют входных данных и создают выходы из ничего.

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

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

Выходы транзакции состоят из двух частей:

• Количество биткойнов, выраженное в сатоши , наименьшая единица биткойнов.
• Сценарий блокировки , также известный как «обременение», который «блокирует» эту сумму, задавая условия, которые должны быть выполнены, чтобы потратить выходные данные.

Язык сценариев транзакций, используемый в сценарии блокировки, упомянутом ранее, подробно обсуждается в разделе «Сценарии транзакций и язык сценариев».В таблице 5-2 показана структура вывода транзакции.

Таблица 5-2. Структура вывода транзакции

В примере 5-1 мы используем блокчейн.info API для поиска неизрасходованных выходов (UTXO) определенного адреса.

Пример 5-1. Скрипт, который вызывает API blockchain.info для поиска UTXO, связанного с адресом

  # получение неизрасходованных выходных данных из API блокчейна 

  импорт   json 
  импорт   запросов 

  # пример адреса 
  адрес   =   '1Dorian4RoXcnBv9hnQ4Y2C1an6NJ4UrjX' 

  # URL-адрес API: https://blockchain.info/unspent?active= 
 
  # Возвращает объект JSON со списком "unspent_outputs", содержащим UTXO, например: 
  # {"unspent_outputs": [
  # {
  # "tx_hash": "ebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad62167", 
  # "tx_index": 51
7, 
  # "tx_output_n": 1, 
  # "script": "76a9148c7e252f8d64b0b6e3139850fcfefcf4a2d88ac", 
  # "значение": 8000000, 
  # "value_hex": "7a1200", 
  # "подтверждения": 28691 
  #}, 
  #... 
  #]} 

  или   =   запросов  .   получите   (  'https://blockchain.info/unspent?active=  % s  '  %   адрес  ) 
  utxo_set   =   json  .   загружает   (  или  .   текст  ) [  "unspent_outputs"  ] 

  для   utxo   в   utxo_set  : 
      print   " % s  :  % d   -  % ld   Satoshis"  %   (  utxo   ' 919hash41'   ' utxo   [  'tx_output_n'  ],   utxo   [  'value'  ])  

Запустив скрипт, мы видим список идентификаторов транзакций, двоеточие, порядковый номер конкретный неизрасходованный выход транзакции (UTXO) и значение этого UTXO в сатоши.Сценарий блокировки не показан в выходных данных в примере 5-2.

Пример 5-2. Запуск сценария get-utxo.py

  $  python get-utxo.py
ebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad62167: 1 - 8000000 сатоши
6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf: 0 - 16050000 сатоши
74d788804e2aae10891d72753d1520da1206e6f4f20481cc1555b7f2cb44aca0: 0 - 5000000 Сатоши
b2affea89ff82557c60d635a2a3137b8f88f12ecec85082f7d0a1f82ee203ac4: 0 - 10000000 сатоши
... 

Условия расходов (обременения)

Выходы транзакций связывают определенную сумму (в сатоши) с конкретным обременением или сценарием блокировки, который определяет условие, которое должно быть выполнено, чтобы потратить эту сумму. В большинстве случаев сценарий блокировки блокирует вывод на конкретный биткойн-адрес, тем самым передавая право собственности на эту сумму новому владельцу. Когда Алиса заплатила Bob’s Cafe за чашку кофе, ее транзакция привела к выводу 0,015 биткойнов , обремененному или привязанному к биткойн-адресу кафе.Эти 0,015 биткойнов были записаны в блокчейне и стали частью набора неизрасходованных транзакций, то есть отображались в кошельке Боба как часть доступного баланса. Когда Боб решает потратить эту сумму, его транзакция снимает обременение, разблокируя выход, предоставляя сценарий разблокировки, содержащий подпись из закрытого ключа Боба.

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

Когда пользователи производят платеж, их кошелек создает транзакцию, выбирая из доступного UTXO. Например, для совершения платежа в биткойнах 0,015 приложение кошелька может выбрать UTXO 0,01 и UTXO 0,005, используя их оба для добавления к желаемой сумме платежа.

В примере 5-3 мы показываем использование «жадного» алгоритма для выбора из доступных UTXO, чтобы произвести определенную сумму платежа. В этом примере доступный UTXO предоставляется как постоянный массив, но на самом деле доступный UTXO может быть получен с помощью вызова RPC к Bitcoin Core или к стороннему API, как показано в Примере 5-1.

Пример 5-3. Скрипт для расчета общего количества выпущенных биткойнов

  # Выбирает выходные данные из списка UTXO с использованием жадного алгоритма.

  из   sys   импорт   argv 

  класс   OutputInfo  : 

      def   __init__   (  self  ,   tx_hash  ,   tx_index  ,   значение  ): 
          сам  .   tx_hash   =   tx_hash 
          сам  .   tx_index   =   tx_index 
          сам  .  значение   =   значение 

      def   __repr__   (  self  ): 
          возврат   "< % s  :  % s   с  % s   Satoshis>"  %   (  сам  .        self  .  tx_index  , 
                                               сам  .  значение  ) 

  # Выбрать оптимальные выходы для отправки из списка неизрасходованных выходов. 
  # Возвращает список выходных данных и оставшееся изменение для отправки на 
  # изменить адрес. 
  def   select_outputs_greedy   (  неизрасходовано  ,   min_value  ): 
      # Ошибка, если пусто. 
      если   не   неизрасходованные  : 
          возврат   Нет 
      # Разделение на 2 списка.
      lessers   =   [  utxo   для   utxo   in   неизрасходованные   if   utxo  .   значение   <  min_value  ] 
      больше   =   [  utxo   для   utxo   in   неизрасходовано   if   utxo  .   значение  > =   min_value  ] 
      key_func   =   лямбда   utxo  :   utxo  .  значение 
      если   больше  : 
          # Не пусто. Найдите наименьшее большее. 
          min_greater   =   min   (  больше  ) 
          изменить   =   min_greater  .   значение   -   min_value 
          возврат   [  min_greater  ],   изменение 
      # Не встречается в больших.Вместо этого попробуйте несколько лессеров. 
      # Переставьте их в порядке убывания. Мы хотим использовать минимум 
      # Максимальное количество входов. 
      лессеры  .   сортировка   (  ключ   =   key_func  ,   обратный   =   True  ) 
      результат   =   [] 
      накопление   =   0 
      для   utxo   в   lessers  : 
          результат  .  приложение   (  utxo  ) 
          аккумулятор   + =   utxo  .   значение 
          если   накопление  > =   min_value  : 
              изменение   =   накопление   -   min_value 
              возврат   результат  ,   "Изменение:  % d   Сатоши"  %   изменение 
      # Ничего не найдено.
      возврат   Нет  ,   0 

  деф   основной   (): 
      неизрасходованных   =   [
          OutputInfo   (  "ebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad62167"  ,   1  ,    8000000 919)
          OutputInfo   (  "6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf"  ,   0  ,       1601950000 
          OutputInfo   (  "b2affea89ff82557c60d635a2a3137b8f88f12ecec85082f7d0a1f82ee203ac4"  ,   0  ,     10000000)
          OutputInfo   (  "7dbc497969c7475e45d952c4a872e213fb15d45e5cd3473c386a71a1b0c136a1"  ,   0  0000,        
          OutputInfo   (  "55ea01bd7e9afd3d3ab97e777d62a0709cf0725e80a7350fdb22d7b8ec6"  ,   17  , 9701942 919) 9701942 919
          OutputInfo   (  "12b6a7934c1df821945ee9ee3b3326d07ca7a65fd6416ea44ce8c3db0c078c64"  ,   0  ,     000000)
          OutputInfo   (  "7f42eda67921ee92eae5f79bd37c68c9cb859b899ce70dba68c48338857b7818"  ,   0  ,   161
0  
     ] 

      если   лен   (  argv  )  >   1  : 
          целевой   =   длинный   (  argv   [  1  ]) 
      остальное  : 
          цель   =   55000000 

      print   «Для суммы транзакции  % d   Satoshis ( % f   биткойн) используйте:»  %   (  цель  ,   цель  /919.0   **   8  ) 
      печать   select_outputs_greedy   (  неизрасходованные  ,   цель  ) 

 , если   __name__   ==   "__main__"  : 
      main   ()  

Если мы запустим сценарий select-utxo.py без параметра, он попытается создать набор UTXO (и изменений) для выплаты 55000000 сатоши (0.55 биткойн). Если вы укажете целевую сумму платежа в качестве параметра, сценарий выберет UTXO для выполнения этой целевой суммы платежа. В примере 5-4 мы запускаем скрипт, пытаясь произвести платеж в размере 0,5 биткойна или 50 000 000 сатоши.

Пример 5-4. Запуск сценария select-utxo.py

 $ python select-utxo.py 50000000
Для суммы транзакции 50000000 сатоши (0.500000 биткойнов) используйте:
([<7dbc497969c7475e45d952c4a872e213fb15d45e5cd3473c386a71a1b0c136a1: 0 с 25000000 Satoshis>, <7f42eda67921ee92eae5f79bd37c68c9cb859b899ce70dba68c48338857b7818: 0 с 16100000 Satoshis>, <6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf: 0 с 16050000 Satoshis>], 'Изменение: 7150000 Satoshis') девяносто одна тысяча пятьсот девяносто один 
 После того, как UTXO выбран, бумажник затем производит разблокировку сценарии, содержащие сигнатуры для каждого UTXO, что делает их пригодными для использования, удовлетворяя их условиям сценария блокировки.Кошелек добавляет эти ссылки UTXO и скрипты разблокировки в качестве входных данных для транзакции. В таблице 5-3 показана структура ввода транзакции. 
 
 Таблица 5-3. Структура ввода транзакции 
 
      
 
 
 Размер 
 
 Поле 
 
 Описание 
 
 
 
 
 
 
 32 байта 
 
 
 
 Хеш транзакции 
 
 
 
 Указатель на транзакцию, содержащую быть потрачено 
 
 
 
 
 
 4 байта 
 
 
 
 Индекс вывода 
 
 
 
 Номер индекса UTXO, который должен быть потрачен; первый - 0 
 
 
 
 
 
 1-9 байтов (VarInt) 
 
 
 
 Размер сценария разблокировки 
 
 
 
 Длина сценария разблокировки в байтах, чтобы следовать 
 
 
 
 
 
 Переменная 
 
 
 
 Разблокировка -Script 
 
 
 
 Сценарий, который выполняет условия сценария блокировки UTXO.
 
 
 
 
 
 4 байта 
 
 
 
 Порядковый номер 
 
 
 
 В настоящее время отключена функция замены Tx, установлено значение 0xFFFFFFFF 
 
 
 
 
  
 Примечание 
 
 Порядковый номер используется для отмены транзакции до истечения срока ее действия времени блокировки транзакции, которая в настоящее время отключена в биткойнах. Большинство транзакций устанавливают это значение на максимальное целочисленное значение (0xFFFFFFFF), и оно игнорируется сетью биткойнов.Если транзакция имеет ненулевое время блокировки, по крайней мере один из ее входов должен иметь порядковый номер ниже 0xFFFFFFFF, чтобы включить время блокировки. 
 
 Большинство транзакций включают комиссию за транзакцию, которая компенсирует майнерам биткойнов за обеспечение безопасности сети. Майнинг, а также сборы и вознаграждения, собираемые майнерами, более подробно обсуждаются в главе 8. В этом разделе рассматривается, как транзакционные комиссии включаются в типичную транзакцию. Большинство кошельков автоматически рассчитывают и включают комиссию за транзакцию.Однако, если вы создаете транзакции программно или с помощью интерфейса командной строки, вы должны вручную учитывать и включать эти комиссии. 
 
 Комиссионные за транзакции служат стимулом для включения (майнинга) транзакции в следующий блок, а также как сдерживающий фактор против «спамовых» транзакций или любого рода злоупотреблений в системе за счет небольших затрат на каждую транзакцию. Комиссию за транзакцию взимает майнер, который добывает блок, который записывает транзакцию в цепочке блоков.
 
 Комиссия за транзакцию рассчитывается на основе размера транзакции в килобайтах, а не стоимости транзакции в биткойнах. В целом, комиссии за транзакции устанавливаются в зависимости от рыночных сил в сети биткойнов. Майнеры определяют приоритет транзакций на основе множества различных критериев, включая комиссии, и могут даже обрабатывать транзакции бесплатно при определенных обстоятельствах. Комиссия за транзакцию влияет на приоритет обработки, а это означает, что транзакция с достаточной комиссией, вероятно, будет включена в следующий наиболее добываемый блок, в то время как транзакция с недостаточной комиссией или без комиссии может быть отложена и обработана с максимальной эффективностью после нескольких блоки или не обрабатываются совсем.Комиссия за транзакцию не является обязательной, и в конечном итоге транзакция без комиссии может быть обработана; однако включение комиссии за транзакцию способствует приоритетной обработке. 
 
 Со временем способ расчета комиссий за транзакции и их влияние на приоритизацию транзакций изменились. Сначала комиссии за транзакции были фиксированными и постоянными во всей сети. Постепенно структура комиссий была смягчена, так что на нее могут влиять рыночные силы в зависимости от пропускной способности сети и объема транзакций.Текущая минимальная комиссия за транзакцию установлена ​​на уровне 0,0001 биткойн или десятая часть миллибиткойна за килобайт, недавно уменьшенная с одного миллибиткойна. Большинство транзакций составляют менее одного килобайта; однако те, у которых несколько входов или выходов, могут быть больше. Ожидается, что в будущих версиях протокола биткойнов приложения-кошельки будут использовать статистический анализ для расчета наиболее подходящей комиссии для присоединения к транзакции на основе средней комиссии последних транзакций. 
 
 Текущий алгоритм, используемый майнерами для определения приоритетности транзакций для включения в блок на основе их комиссий, подробно рассматривается в главе 8.
 
 
 Добавление комиссий к транзакциям 
  
 
 В структуре данных транзакций нет поля для комиссионных. Вместо этого, сборы подразумеваются как разница между суммой вложений и суммой результатов. Любая лишняя сумма, которая остается после вычета всех выходов из всех входов, является комиссией, взимаемой майнерами. 
 
  Комиссия за транзакцию подразумевается как превышение входов минус выходы: 
 
 
 Сборы = Сумма (входы) - Сумма (выходы) 
 Это несколько сбивающий с толку элемент транзакций и важный момент, который необходимо понять, потому что, если вы строите свои собственные транзакции, вы должны убедиться, что вы случайно не включили очень большую комиссию из-за недостаточного расходования средств.Это означает, что вы должны учитывать все вводимые данные, если необходимо, путем внесения изменений, иначе вы в конечном итоге дадите майнерам очень большой совет!
 Например, если вы потребляете UTXO в 20 биткойнов для совершения платежа в 1 биткойн, вы должны включить вывод сдачи 19 биткойнов обратно в свой кошелек. В противном случае «оставшиеся» 19 биткойнов будут считаться комиссией за транзакцию и будут собраны майнером, который майнит вашу транзакцию в блоке. Хотя вы получите приоритетную обработку и сделаете майнера очень счастливым, это, вероятно, не то, что вы планировали.
 Предупреждение 
 Если вы забудете добавить выход изменения в транзакцию, созданную вручную, вы оплатите это изменение как комиссию за транзакцию. "Сдачи не надо!" может быть не тем, что вы хотели.
 Давайте посмотрим, как это работает на практике, еще раз посмотрев на покупку кофе Алисой. Алиса хочет потратить 0,015 биткойна на оплату кофе. Чтобы обеспечить своевременную обработку этой транзакции, она захочет включить комиссию за транзакцию, скажем, 0,001. Это будет означать, что общая стоимость транзакции будет равна 0.016. Следовательно, ее кошелек должен быть источником набора UTXO, который в сумме составляет 0,016 биткойна или более, и, при необходимости, вносить изменения. Допустим, в ее кошельке есть UTXO на 0,2 биткойна. Следовательно, ему необходимо будет использовать этот UTXO, создать один выход для Bob’s Cafe за 0,015, а второй выход с 0,184 биткойна в обмен на свой собственный кошелек, оставив 0,001 биткойна нераспределенным в качестве неявной комиссии за транзакцию.
 А теперь давайте посмотрим на другой сценарий. Евгения, директор благотворительной организации по работе с детьми на Филиппинах, завершила сбор средств на покупку школьных учебников для детей.Она получила несколько тысяч небольших пожертвований от людей со всего мира на общую сумму 50 биткойнов, поэтому ее кошелек заполнен очень маленькими платежами (UTXO). Теперь она хочет купить сотни школьных учебников у местного издателя, заплатив биткойнами.
 Поскольку приложение кошелька Евгении пытается создать одну большую платежную транзакцию, оно должно исходить из доступного набора UTXO, который состоит из множества меньших сумм. Это означает, что результирующая транзакция будет исходить из более чем сотни мелких UTXO в качестве входных данных и только из одного выхода, оплачиваемого издателем книги.Транзакция с таким количеством входов будет больше одного килобайта, возможно, от 2 до 3 килобайт. В результате потребуется более высокая комиссия, чем минимальная сетевая комиссия в 0,0001 биткойн.
 Приложение кошелька Евгении рассчитает соответствующую комиссию, измерив размер транзакции и умножив ее на комиссию за килобайт. Многие кошельки переплачивают комиссию за более крупные транзакции, чтобы обеспечить своевременную обработку транзакции. Более высокая комиссия объясняется не тем, что Евгения тратит больше денег, а тем, что ее транзакция более сложна и больше по размеру - комиссия не зависит от стоимости транзакции в биткойнах.
 Объединение транзакций в цепочку и потерянные транзакции 
 Как мы видели, транзакции образуют цепочку, при которой одна транзакция расходует выходные данные предыдущей транзакции (известной как родительская) и создает выходные данные для последующей транзакции (известной как дочерняя) . Иногда целая цепочка транзакций, зависящих друг от друга, например, родительская, дочерняя и внучатая транзакции, создается одновременно для выполнения сложного транзакционного рабочего процесса, который требует, чтобы действительные дочерние элементы были подписаны до подписания родительского элемента.Например, это метод, используемый в транзакциях CoinJoin, когда несколько сторон объединяют транзакции вместе, чтобы защитить свою конфиденциальность.
 Когда по сети передается цепочка транзакций, они не всегда поступают в одном и том же порядке. Иногда ребенок может прийти раньше родителя. В этом случае узлы, которые сначала видят дочерний элемент, могут видеть, что он ссылается на родительскую транзакцию, которая еще не известна. Вместо того, чтобы отклонять дочерний элемент, они помещают его во временный пул, чтобы дождаться прибытия его родителя и распространить его на все остальные узлы.Пул транзакций без родителей известен как пул сиротских транзакций  . По прибытии родителя любые сироты, которые ссылаются на UTXO, созданный родителем, освобождаются из пула, рекурсивно проходят повторную валидацию, а затем вся цепочка транзакций может быть включена в пул транзакций, готовая к добыче в блоке. Цепочки транзакций могут быть сколь угодно длинными, с одновременной передачей любого количества поколений. Механизм удержания сирот в пуле сирот гарантирует, что в противном случае действительные транзакции не будут отклонены только потому, что их родительская транзакция была отложена, и что в конечном итоге цепочка, к которой они принадлежат, будет восстановлена ​​в правильном порядке, независимо от порядка поступления.
 Существует ограничение на количество потерянных транзакций, хранящихся в памяти, чтобы предотвратить атаку отказа в обслуживании против узлов биткойнов. Предел определен как  MAX_ORPHAN_TRANSACTIONS  в исходном коде эталонного клиента биткойнов. Если количество потерянных транзакций в пуле превышает  MAX_ORPHAN_TRANSACTIONS , одна или несколько случайно выбранных потерянных транзакций исключаются из пула, пока размер пула не вернется в установленные пределы.
 Сценарии транзакций и язык сценариев 
 Клиенты Биткойн проверяют транзакции, выполняя сценарий, написанный на языке сценариев, подобном Forth.На этом языке сценариев написаны как сценарий блокировки (обременение), помещенный в UTXO, так и сценарий разблокировки, который обычно содержит подпись. Когда транзакция подтверждена, сценарий разблокировки на каждом входе выполняется вместе с соответствующим сценарием блокировки, чтобы увидеть, удовлетворяет ли он условию расходов.
 Сегодня большинство транзакций, обрабатываемых через сеть биткойнов, имеют форму «Алиса платит Бобу» и основаны на том же сценарии, который называется сценарием Pay-to-Public-Key-Hash.Однако использование сценариев для блокировки выходов и разблокировки входов означает, что благодаря использованию языка программирования транзакции могут содержать бесконечное количество условий. Биткойн-транзакции не ограничиваются формой и шаблоном «Алиса платит Бобу».
 Это только верхушка айсберга возможностей, которые могут быть выражены с помощью этого языка сценариев. В этом разделе мы продемонстрируем компоненты языка сценариев транзакций биткойнов и покажем, как его можно использовать для выражения сложных условий расходов и как эти условия могут быть выполнены с помощью сценариев разблокировки.
 Подсказка 
 Проверка транзакции Биткойн не основана на статическом шаблоне, но вместо этого достигается посредством выполнения языка сценариев. Этот язык позволяет выражать почти бесконечное множество условий. Вот как биткойн получает силу «программируемых денег».
 Построение сценария (блокировка + разблокировка) 
 Механизм проверки транзакций Биткойн полагается на два типа сценариев для проверки транзакций: сценарий блокировки и сценарий разблокировки.
 Сценарий блокировки - это обременение, накладываемое на вывод, и он определяет условия, которые должны быть выполнены для использования вывода в будущем. Исторически сценарий блокировки назывался  scriptPubKey , потому что обычно он содержал открытый ключ или биткойн-адрес. В этой книге мы называем это «сценарием блокировки», чтобы признать гораздо более широкий диапазон возможностей этой технологии создания сценариев. В большинстве биткойн-приложений то, что мы называем сценарием блокировки, будет отображаться в исходном коде как  scriptPubKey .
 Сценарий разблокировки - это сценарий, который «решает» или удовлетворяет условиям, налагаемым на выход сценарием блокировки, и позволяет потратить выходные данные. Сценарии разблокировки являются частью каждого ввода транзакции, и в большинстве случаев они содержат цифровую подпись, созданную кошельком пользователя с его или ее закрытого ключа. Исторически скрипт разблокировки называется  scriptSig , потому что обычно он содержит цифровую подпись. В большинстве биткойн-приложений в исходном коде скрипт разблокировки называется  scriptSig .В этой книге мы называем его «сценарием разблокировки», чтобы признать гораздо более широкий диапазон требований к сценариям блокировки, поскольку не все сценарии разблокировки должны содержать подписи.
 Каждый биткойн-клиент проверяет транзакции, выполняя сценарии блокировки и разблокировки вместе. Для каждого входа в транзакции программное обеспечение проверки сначала извлекает UTXO, на который ссылается вход. Этот UTXO содержит сценарий блокировки, определяющий условия, необходимые для его использования. Программное обеспечение проверки затем возьмет сценарий разблокировки, содержащийся во входных данных, который пытается потратить этот UTXO, и выполнит два сценария.
 В исходном биткойн-клиенте скрипты разблокировки и блокировки были объединены и выполнялись последовательно. По соображениям безопасности это было изменено в 2010 году из-за уязвимости, которая позволяла некорректному сценарию разблокировки помещать данные в стек и повредить сценарий блокировки. В текущей реализации сценарии выполняются отдельно со стеком, передаваемым между двумя выполнениями, как описано ниже.
 Сначала выполняется сценарий разблокировки с использованием механизма выполнения стека.Если сценарий разблокировки выполняется без ошибок (например, в нем не осталось «болтающихся» операторов), копируется основной стек (а не альтернативный стек) и выполняется сценарий блокировки. Если результатом выполнения сценария блокировки с данными стека, скопированными из сценария разблокировки, является «ИСТИНА», сценарий разблокировки преуспел в разрешении условий, налагаемых сценарием блокировки, и, следовательно, входные данные являются действительной авторизацией для использования UTXO. . Если после выполнения объединенного сценария остается какой-либо результат, отличный от «ИСТИНА», ввод недействителен, поскольку он не удовлетворяет условиям расходов, установленным для UTXO.Обратите внимание, что UTXO постоянно записывается в цепочку блоков и, следовательно, неизменен, и на него не влияют неудачные попытки потратить его по ссылке в новой транзакции. Только действительная транзакция, которая правильно удовлетворяет условиям UTXO, приводит к тому, что UTXO помечается как «потраченный» и удаляется из набора доступных (неизрасходованных) UTXO.
 Рисунок 5-1 представляет собой пример сценариев разблокировки и блокировки для наиболее распространенного типа транзакции биткойнов (платеж по хешу открытого ключа), показывающий комбинированный сценарий, полученный в результате объединения сценариев разблокировки и блокировки перед сценарием. Проверка.
 Рисунок 5-1. Комбинация scriptSig и scriptPubKey для оценки сценария транзакции
 Язык сценария транзакции биткойнов, называемый  Script , представляет собой язык исполнения на основе стека обратной полировки нотации типа Форта. Если это звучит чепухой, вы, вероятно, не изучали языки программирования 1960-х годов. Сценарий - это очень простой язык, который был разработан с учетом ограничений по объему и выполняемого на широком диапазоне оборудования, возможно, столь же простом, как встроенное устройство, такое как карманный калькулятор.Он требует минимальной обработки и не может делать многие из фантастических вещей, которые могут делать современные языки программирования. В случае программируемых денег это преднамеренная функция безопасности.
 Язык сценариев Биткойна называется стековым языком, потому что он использует структуру данных, называемую стеком  . Стек - это очень простая структура данных, которую можно визуализировать как стопку карточек. Стек позволяет две операции: push и pop. Push добавляет элемент в верхнюю часть стека. Pop удаляет верхний элемент из стека.
 Язык сценариев выполняет сценарий, обрабатывая каждый элемент слева направо. Числа (константы данных) помещаются в стек. Операторы выталкивают или выталкивают один или несколько параметров из стека, воздействуют на них и могут помещать результат в стек. Например,  OP_ADD  вытолкнет два элемента из стека, сложит их и поместит полученную сумму в стек.
 Условные операторы оценивают условие, давая логический результат ИСТИНА или ЛОЖЬ. Например,  OP_EQUAL  выталкивает два элемента из стека и выдвигает ИСТИНА (ИСТИНА представлено числом 1), если они равны, или ЛОЖЬ (представлено нулем), если они не равны.Скрипты биткойн-транзакций обычно содержат условный оператор, поэтому они могут выдавать ИСТИННЫЙ результат, означающий действительную транзакцию.
 На рис. 5-2 сценарий  2 3 OP_ADD 5 OP_EQUAL  демонстрирует оператор арифметического сложения  OP_ADD , складывающий два числа и помещающий результат в стек, за которым следует условный оператор  OP_EQUAL , который проверяет, что Итоговая сумма равна  5 . Для краткости префикс  OP_  опущен в пошаговом примере.
 Ниже приведен немного более сложный сценарий, который вычисляет  2 + 7 - 3 + 1 . Обратите внимание, что, когда сценарий содержит несколько операторов подряд, стек позволяет выполнять действия одного оператора следующему оператору:
 2 7 OP_ADD 3 OP_SUB 1 OP_ADD 7 OP_EQUAL 
 Попробуйте проверить предыдущий сценарий самостоятельно, используя карандаш и бумага. Когда выполнение скрипта завершится, вы должны остаться со значением TRUE в стеке.
 Хотя большинство сценариев блокировки ссылаются на адрес биткойна или открытый ключ, что требует подтверждения права собственности на использование средств, сценарий не должен быть таким сложным.Допустима любая комбинация сценариев блокировки и разблокировки, которая приводит к значению ИСТИНА. Простая арифметика, которую мы использовали в качестве примера языка сценариев, также является допустимым сценарием блокировки, который можно использовать для блокировки вывода транзакции.
 Используйте часть сценария арифметического примера в качестве сценария блокировки:
 3 OP_ADD 5 OP_EQUAL 
, который может быть удовлетворен транзакцией, содержащей ввод со сценарием разблокировки:
 2 
 Программа проверки сочетает блокировку и разблокировку сценарии и результирующий сценарий:
 2 3 OP_ADD 5 OP_EQUAL 
 Как мы видели в пошаговом примере на рисунке 5-2, когда этот сценарий выполняется, результатом является  OP_TRUE , что делает транзакцию действительной. .Мало того, что это действительный сценарий блокировки вывода транзакции, но и получившийся UTXO может быть использован любым, кто обладает арифметическими навыками, чтобы знать, что число 2 удовлетворяет сценарию.
 Рисунок 5-2. Проверка сценария Биткойна с помощью простых вычислений
 Совет 
 Транзакции действительны, если верхний результат в стеке ИСТИНА (обозначен как  {0x01} ), любое другое ненулевое значение или если стек пуст после выполнения сценария. Транзакции недействительны, если верхнее значение в стеке равно FALSE (пустое значение нулевой длины, обозначенное как  {} ) или если выполнение скрипта остановлено явным образом оператором, таким как OP_VERIFY, OP_RETURN, или условным ограничителем, например OP_ENDIF.См. Подробности в Приложении A.
 Язык сценариев транзакций биткойнов содержит множество операторов, но намеренно ограничен одним важным способом - нет никаких циклов или сложных возможностей управления потоком, кроме условного управления потоком. Это гарантирует, что язык не будет  Turing Complete , а это означает, что скрипты имеют ограниченную сложность и предсказуемое время выполнения. Скрипт не является языком общего назначения. Эти ограничения гарантируют, что язык не может быть использован для создания бесконечного цикла или другой формы «логической бомбы», которая может быть встроена в транзакцию таким образом, чтобы вызвать атаку отказа в обслуживании против сети биткойнов.Помните, что каждая транзакция проверяется каждым полным узлом в сети биткойнов. Ограниченный язык не позволяет использовать механизм проверки транзакции в качестве уязвимости.
 Язык сценария транзакции биткойнов не имеет состояния, то есть нет состояния до выполнения сценария или состояния, сохраненного после выполнения сценария. Следовательно, вся информация, необходимая для выполнения сценария, содержится внутри сценария. Как и ожидалось, сценарий будет выполняться одинаково в любой системе.Если ваша система проверяет сценарий, вы можете быть уверены, что каждая другая система в сети биткойнов также проверит сценарий, а это означает, что действительная транзакция действительна для всех, и все это знают. Эта предсказуемость результатов - важное преимущество системы биткойнов.
 В первые несколько лет разработки биткойна разработчики ввели некоторые ограничения в типы скриптов, которые могут обрабатываться эталонным клиентом. Эти ограничения закодированы в функции  isStandard () , которая определяет пять типов «стандартных» транзакций.Эти ограничения являются временными и могут быть сняты к тому времени, когда вы это прочтете. До тех пор пять стандартных типов скриптов транзакций - единственные, которые будут приняты эталонным клиентом и большинством майнеров, запускающих эталонный клиент. Хотя можно создать нестандартную транзакцию, содержащую сценарий, который не является одним из стандартных типов, вы должны найти майнера, который не соблюдает эти ограничения, чтобы превратить эту транзакцию в блок.
 Проверьте исходный код клиента Bitcoin Core (эталонная реализация), чтобы узнать, что в настоящее время разрешено в качестве допустимого сценария транзакции.
 Пять стандартных типов сценариев транзакций: хеш-код с оплатой по общему ключу (P2PKH), с открытым ключом, мультиподпись (до 15 ключей), хеш с оплатой по сценарию (P2SH) и с данными. output (OP_RETURN), которые более подробно описаны в следующих разделах.
 Pay-to-Public-Key-Hash (P2PKH) 
 Подавляющее большинство транзакций, обрабатываемых в сети биткойнов, являются транзакциями P2PKH. Они содержат сценарий блокировки, который обременяет вывод хешем открытого ключа, более известным как адрес биткойна.Транзакции, которые оплачивают биткойн-адрес, содержат скрипты P2PKH. Вывод, заблокированный сценарием P2PKH, может быть разблокирован (потрачен) путем представления открытого ключа и цифровой подписи, созданной соответствующим закрытым ключом.
 Например, давайте еще раз посмотрим на платеж Алисы в адрес Bob’s Cafe. Алиса перевела 0,015 биткойна на биткойн-адрес кафе. Этот вывод транзакции будет иметь сценарий блокировки вида:
 OP_DUP OP_HASh260 <Хеш открытого ключа кафе> OP_EQUAL OP_CHECKSIG 
 Хеш  открытого ключа кафе  эквивалентен биткойн-адресу кафе без кодировки Base58Check.Большинство приложений будут отображать хэш открытого ключа   в шестнадцатеричной кодировке, а не знакомый формат адреса биткойнов Base58Check, который начинается с «1».
 Предыдущий сценарий блокировки может быть удовлетворен сценарием разблокировки в форме:
 <Подпись кафе> <Открытый ключ кафе> 
 Два сценария вместе образуют следующий комбинированный сценарий проверки:
 <Подпись кафе> <Кафе Открытый ключ> OP_DUP OP_HASh260
<Хэш открытого ключа Cafe> OP_EQUAL OP_CHECKSIG 
 При выполнении этот комбинированный сценарий будет оцениваться как TRUE, если и только если сценарий разблокировки соответствует условиям, установленным сценарием блокировки.Другими словами, результат будет ИСТИНА, если скрипт разблокировки имеет действительную подпись из закрытого ключа кафе, которая соответствует хешу открытого ключа, установленному как обременение.
 На рисунках 5-3 и 5-4 показано (в двух частях) пошаговое выполнение комбинированного сценария, который докажет, что это действительная транзакция.
 Рисунок 5-3. Оценка сценария для транзакции P2PKH (Часть 1 из 2)
 Pay-to-public-key - это более простая форма биткойн-платежа, чем pay-to-public-key-hash.В этой форме сценария сам открытый ключ хранится в сценарии блокировки, а не в хеш-коде открытого ключа, как в случае с P2PKH ранее, который намного короче. Pay-to-public-key-hash был изобретен Сатоши, чтобы сделать адреса биткойнов короче для простоты использования. Плата за открытый ключ теперь чаще всего встречается в транзакциях с базой монет, генерируемых старым программным обеспечением для майнинга, которое не было обновлено для использования P2PKH.
 Сценарий блокировки с оплатой по общему ключу выглядит следующим образом:
 <Открытый ключ A> OP_CHECKSIG 
 Соответствующий сценарий разблокировки, который должен быть представлен, чтобы разблокировать этот тип вывода, представляет собой простую подпись, например:
 <Подпись из закрытого ключа A> 
 Комбинированный сценарий, который проверяется программным обеспечением для проверки транзакций:
 <Подпись из закрытого ключа A> <Открытый ключ A> OP_CHECKSIG 
 Этот сценарий представляет собой простой вызов  Оператор CHECKSIG , который проверяет подпись как принадлежащую правильному ключу и возвращает TRUE в стеке.
 Рисунок 5-4. Оценка сценария для транзакции P2PKH (Часть 2 из 2)
 Сценарии с несколькими подписями устанавливают условие, при котором N открытых ключей записываются в сценарий, и по крайней мере M из них должны предоставлять подписи для освобождения от обременения. Это также известно как схема M-of-N, где N - общее количество ключей, а M - порог подписей, необходимых для проверки. Например, мульти-подпись 2-из-3 - это та, в которой три открытых ключа указаны в качестве потенциальных подписывающих лиц, и по крайней мере два из них должны использоваться для создания подписей для действительной транзакции для расходования средств.В настоящее время стандартные сценарии с несколькими подписями ограничены максимум 15 перечисленными открытыми ключами, что означает, что вы можете делать что угодно, от 1-из-1 до мульти-подписи 15-из-15 или любую комбинацию в этом диапазоне. Ограничение до 15 перечисленных ключей может быть снято к моменту публикации этой книги, поэтому проверьте функцию  isStandard () , чтобы узнать, что в настоящее время принимается сетью.
 Общая форма сценария блокировки, устанавливающего условие множественной подписи M-of-N, выглядит следующим образом:
 M <Открытый ключ 1> <Открытый ключ 2>... <Открытый ключ N> N OP_CHECKMULTISIG 
 где N - общее количество перечисленных открытых ключей, а M - порог необходимых подписей для использования вывода.
 Сценарий блокировки, устанавливающий условие множественной подписи 2 из 3, выглядит следующим образом:
 2 <Открытый ключ A> <Открытый ключ B> <Открытый ключ C> 3 OP_CHECKMULTISIG 
 Предыдущий сценарий блокировки может быть удовлетворен с помощью сценарий разблокировки, содержащий пары подписей и открытых ключей:
 OP_0 <Подпись B> <Подпись C> 
 или любую комбинацию двух подписей из закрытых ключей, соответствующих трем перечисленным открытым ключам.
 Примечание 
 Префикс  OP_0  необходим из-за ошибки в исходной реализации  CHECKMULTISIG , когда из стека выскакивает один элемент слишком много. Он игнорируется  CHECKMULTISIG  и является просто заполнителем.
 Два сценария вместе образуют объединенный сценарий проверки:
 OP_0 <Подпись B> <Подпись C> 2 <Открытый ключ A> <Открытый ключ B> <Открытый ключ C> 3 OP_CHECKMULTISIG 
 При выполнении этот объединенный сценарий будет оцениваться как ИСТИНА, если и только если скрипт разблокировки соответствует условиям, установленным скриптом блокировки.В этом случае условием является наличие у сценария разблокировки действительной подписи из двух закрытых ключей, которые соответствуют двум из трех открытых ключей, установленных как обременение.
 Распределенная бухгалтерская книга Биткойна с отметками времени, блокчейн, имеет потенциальное применение далеко за пределами платежей. Многие разработчики пытались использовать язык сценариев транзакций, чтобы воспользоваться преимуществами безопасности и отказоустойчивости системы для таких приложений, как цифровые нотариальные услуги, сертификаты акций и смарт-контракты.Ранние попытки использовать язык сценариев биткойна для этих целей включали создание выходных данных транзакций, которые записывали данные в цепочку блоков; например, чтобы записать цифровой отпечаток файла таким образом, чтобы любой мог установить доказательство существования этого файла на определенную дату, ссылаясь на эту транзакцию.
 Использование цепочки блоков биткойнов для хранения данных, не связанных с платежами в биткойнах, является спорным вопросом. Многие разработчики считают такое использование оскорбительным и хотят воспрепятствовать этому.Другие рассматривают это как демонстрацию мощных возможностей технологии блокчейн и хотят поощрять такие эксперименты. Те, кто возражает против включения данных о неплатежах, утверждают, что это вызывает «раздувание блокчейна», обременяя тех, кто использует полные биткойн-узлы, нести расходы на дисковое хранилище для данных, которые блокчейн не предназначен для передачи. Более того, такие транзакции создают UTXO, которые нельзя потратить, используя биткойн-адрес назначения в виде 20-байтового поля произвольной формы. Поскольку адрес используется для данных, он не соответствует закрытому ключу, и полученный UTXO не может быть потрачен  никогда; это поддельный платеж.Эта практика приводит к увеличению размера установленного в памяти UTXO, и, следовательно, эти транзакции, которые никогда не могут быть потрачены, никогда не удаляются, вынуждая биткойн-узлы постоянно хранить их в ОЗУ, что намного дороже.
 В версии 0.9 клиента Bitcoin Core компромисс был достигнут с введением оператора  OP_RETURN .  OP_RETURN  позволяет разработчикам добавлять 40 байтов данных о неплатежах к выходным данным транзакции. Однако, в отличие от использования «фальшивого» UTXO, оператор  OP_RETURN  создает явно  доказуемо неизрасходованный вывод , который не нужно сохранять в наборе UTXO. OP_RETURN  выходных данных записываются в блокчейн, поэтому они занимают дисковое пространство и способствуют увеличению размера блокчейна, но они не хранятся в наборе UTXO и, следовательно, не раздувают пул памяти UTXO и не обременяют полные узлы затратами. более дорогой оперативной памяти.
  OP_RETURN  скрипты выглядят следующим образом:
 OP_RETURN  
 Часть данных ограничена 40 байтами и чаще всего представляет собой хэш, например, результат алгоритма SHA256 (32 байта).Многие приложения ставят перед данными префикс, чтобы помочь идентифицировать приложение. Например, в службе цифрового нотариального удостоверения «Доказательство существования» используется 8-байтовый префикс «DOCPROOF», который имеет кодировку ASCII как  44f4350524f4f46  в шестнадцатеричном формате.
 Имейте в виду, что не существует «сценария разблокировки», соответствующего  OP_RETURN , который можно было бы использовать для «расходования» вывода  OP_RETURN . Вся суть  OP_RETURN  заключается в том, что вы не можете потратить деньги, заблокированные на этом выходе, и, следовательно, их не нужно держать в UTXO как потенциально пригодные для использования -  OP_RETURN  - это  доказуемо неиспользованный . OP_RETURN  обычно является выходом с нулевым количеством биткойнов, потому что любой биткойн, назначенный такому выходу, фактически теряется навсегда. Если программа проверки подлинности сценария обнаруживает  OP_RETURN , это немедленно приводит к остановке выполнения сценария проверки и пометке транзакции как недействительной. Таким образом, если вы случайно ссылаетесь на выход  OP_RETURN  как на вход транзакции, эта транзакция недействительна.
 Стандартная транзакция (та, которая соответствует проверкам  isStandard () ) может иметь только один выход  OP_RETURN .Однако один выход  OP_RETURN  может быть объединен в транзакции с выходами любого другого типа.
 Pay-to-Script-Hash (P2SH) 
 Pay-to-script-hash (P2SH) был представлен в 2012 году как мощный новый тип транзакции, который значительно упрощает использование сложных сценариев транзакций. Чтобы объяснить необходимость P2SH, давайте рассмотрим практический пример.
 В главе 1 мы представили Мохаммеда, импортера электроники из Дубая. Компания Мохаммеда широко использует функцию мультиподписи биткойнов для своих корпоративных счетов.Скрипты с несколькими подписями - одно из наиболее распространенных применений расширенных возможностей сценариев Биткойна и очень мощная функция. Компания Мохаммеда использует сценарий с несколькими подписями для всех платежей клиентов, известный в бухгалтерском учете как «дебиторская задолженность» или AR. В схеме с несколькими подписями любые платежи, производимые клиентами, блокируются таким образом, что для их выпуска требуется как минимум две подписи, от Мохаммеда и одного из его партнеров или от его поверенного, у которого есть резервный ключ. Подобная схема с несколькими подписями обеспечивает контроль корпоративного управления и защищает от краж, растраты или потери.
 Результирующий сценарий довольно длинный и выглядит следующим образом:
 2 <Открытый ключ Мохаммеда> <Открытый ключ партнера1> <Открытый ключ партнера2> <Открытый ключ партнера3> <Открытый ключ поверенного> 5 OP_CHECKMULTISIG 
 Хотя сценарии с несколькими подписями мощная функция, они громоздки в использовании. Учитывая предыдущий сценарий, Мохаммед должен был бы сообщить этот сценарий каждому покупателю до оплаты. Каждый клиент должен будет использовать специальное программное обеспечение для биткойн-кошелька с возможностью создания пользовательских скриптов транзакций, и каждый клиент должен будет понимать, как создать транзакцию с использованием пользовательских скриптов.Более того, итоговая транзакция будет примерно в пять раз больше, чем простая платежная транзакция, потому что этот сценарий содержит очень длинные открытые ключи. Бремя этой сверхбольшой транзакции будет нести клиент в виде комиссионных. Наконец, такой большой сценарий транзакции будет переноситься в UTXO, установленном в ОЗУ на каждом полном узле, до тех пор, пока он не будет израсходован. Все эти проблемы затрудняют использование сложных сценариев вывода на практике.
 Pay-to-script-hash (P2SH) был разработан для решения этих практических трудностей и для упрощения использования сложных скриптов, как оплата на биткойн-адрес.В платежах P2SH сложный скрипт блокировки заменяется его цифровым отпечатком - криптографическим хешем. Когда транзакция, пытающаяся потратить UTXO, представляется позже, она должна содержать сценарий, соответствующий хэшу, в дополнение к сценарию разблокировки. Проще говоря, P2SH означает «заплатить скрипту, соответствующему этому хешу, скрипту, который будет представлен позже, когда этот вывод будет потрачен».
 В транзакциях P2SH сценарий блокировки, который заменяется хешем, называется сценарием погашения  , поскольку он представляется системе во время погашения, а не как сценарий блокировки.В таблице 5-4 показан сценарий без P2SH, а в таблице 5-5 показан тот же сценарий, закодированный с помощью P2SH.
 Таблица 5-4. Сложный скрипт без P2SH
0
0 Sigma
 -5. Сложный скрипт как P2SH
 Скрипт блокировки
 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG
 Скрипт погашения
 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG
 OP_CHECKMULTISIG
 900 -63
0 
 OP_CHECKMULTISIG OP_EQUAL
 Сценарий разблокировки
 Sig1 Сценарий погашения Sig2
 Как видно из таблиц, с P2SH сложный скрипт, детализирующий условия использования выходных данных (скрипт погашения), не представлен в сценарии блокировки.Вместо этого в сценарии блокировки содержится только его хэш, а сам сценарий погашения будет представлен позже как часть сценария разблокировки, когда выходные данные будут потрачены. Это перекладывает бремя комиссии и сложности с отправителя на получателя (спонсора) транзакции.
 Давайте посмотрим на компанию Мохаммеда, сложный сценарий с несколькими подписями и полученные сценарии P2SH.
 Во-первых, сценарий с несколькими подписями, который компания Мохаммеда использует для всех входящих платежей от клиентов:
 2 <Открытый ключ Мохаммеда> <Открытый ключ партнера1> <Открытый ключ партнера2> <Открытый ключ партнера3> <Открытый ключ поверенного> 5 OP_CHECKMULTISIG 
 Если заполнители заменены фактическими открытыми ключами (показаны здесь как 520-битные числа, начинающиеся с 04), вы увидите, что этот сценарий становится очень длинным:
 2
04C16B8698A9ABF84250A7C3EA7EEDEF9897D1C8C6ADF47F06CF73370D74DCCA01CDCA79DCC5C395D7EEC6984D83F1F50C900A24DD47F569FD4193AF5DE762C58704A21D8655D6A935BEAF2CA23E3FB87A3495E7AF308EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B1D5CE65C97D78D0E34224858008E8B49047E63248B75DB7379BE9CDA8CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1A9162F0279CFC10F1E8E8F3020DECDBC3C0DD389D99779650421D65CBD7149B255382ED7F78E
0657EE6FDA162A187543A9D85BAAA93A4AB3A8F044DADA618D087227440645ABE8A35DA8C5B73997AD343BE5C2AFD94A5043752580AFA1ECED3C68D446BCAB69AC0BA7DF50D56231BE0AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D137AAB59E0B000EB7ED238F4D800 5 OP_CHECKMULTISIG 
 Весь девяносто одна тысяча пятьсот девяносто-один Этот сценарий может вместо этого быть представлена ​​20-байтовой криптографический хэш, сначала путем применения алгоритма хэширования SHA256, а затем применения алгоритма ripemd160 на результат.20-байтовый хэш предыдущего сценария: 
 
 54c557e07dde5bb6cb791c7a540e0a4796f5e97e 
 Транзакция P2SH блокирует вывод для этого хеша вместо более длинного сценария, используя сценарий блокировки:
 OP_HAS7c7c7ec7e07e4e08e08e08e08e6e6e6e6e6e6e намного короче. Вместо «оплата этому сценарию с 5 ключами с несколькими подписями» эквивалентная транзакция P2SH - «оплата сценарию с этим хешем». Клиенту, производящему платеж компании Мохаммеда, нужно только включить этот гораздо более короткий сценарий блокировки в свой платеж.Когда Мохаммед хочет потратить этот UTXO, он должен предоставить исходный скрипт погашения (тот, чей хэш заблокировал UTXO) и подписи, необходимые для его разблокировки, например: 
 
   <2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG> 
 Два сценария объединяются в два этапа. Сначала скрипт погашения сравнивается со скриптом блокировки, чтобы убедиться, что хеш-код совпадает:
 <2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG> OP_HASh260  OP_EQUAL 
 Если хэш скрипта погашения совпадает, запускается скрипт разблокировки сам по себе, чтобы разблокировать скрипт погашения:
   2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG 
 Pay-to-script-hash address 
 Другой важной частью функции P2SH является возможность для кодирования хэша сценария как адреса, как определено в BIP0013.Адреса P2SH представляют собой кодировки Base58Check 20-байтового хеш-кода скрипта, точно так же, как адреса биткойнов представляют собой кодировки Base58Check 20-байтового хеш-кода открытого ключа. Адреса P2SH используют префикс версии «5», в результате чего адреса в кодировке Base58Check начинаются с «3». Например, сложный сценарий Мохаммеда, хешированный и закодированный с помощью Base58Check в качестве адреса P2SH, становится  39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw . Теперь Мохаммед может дать этот «адрес» своим клиентам, и они могут использовать практически любой биткойн-кошелек для простой оплаты, как если бы это был биткойн-адрес.Префикс 3 подсказывает им, что это особый тип адреса, соответствующий сценарию, а не публичному ключу, но в остальном он работает точно так же, как платеж на адрес биткойна.
 P2SH-адреса скрывают всю сложность, поэтому человек, производящий платеж, не видит скрипт.
 Преимущества хеширования pay-to-script 
 Функция pay-to-script-hash предлагает следующие преимущества по сравнению с прямым использованием сложных сценариев для блокировки выходных данных:
 Сложные сценарии заменяются более короткими отпечатками пальцев в выводе транзакции, что делает транзакцию меньше.
 Сценарии могут быть закодированы как адрес, поэтому отправитель и кошелек отправителя не нуждаются в сложной разработке для реализации P2SH.
 P2SH перекладывает бремя создания сценария на получателя, а не на отправителя.
 P2SH перекладывает нагрузку на хранение данных для длинного скрипта с вывода (который находится в наборе UTXO и, следовательно, влияет на память) на ввод (хранящийся только в цепочке блоков).
 P2SH переносит нагрузку на хранение данных для длинного скрипта с настоящего времени (платеж) на будущее (когда оно будет потрачено).
 P2SH перекладывает плату за транзакцию за длинный сценарий с отправителя на получателя, который должен включить длинный сценарий погашения, чтобы потратить его.
 Сценарий погашения и проверка isStandard 
 До версии 0.9.2 клиента Bitcoin Core хеширование pay-to-script было ограничено стандартными типами сценариев транзакций биткойнов функцией  isStandard ()  . Это означает, что сценарий погашения, представленный в транзакции расходования, может быть только одного из стандартных типов: P2PK, P2PKH или с несколькими подписями, за исключением  OP_RETURN  и самого P2SH.
 Начиная с версии 0.9.2 клиента Bitcoin Core, транзакции P2SH могут содержать любой допустимый сценарий, что делает стандарт P2SH гораздо более гибким и позволяет экспериментировать со многими новыми и сложными типами транзакций.
 Обратите внимание, что вы не можете поместить P2SH в сценарий погашения P2SH, потому что спецификация P2SH не рекурсивна. Вы также по-прежнему не можете использовать  OP_RETURN  в сценарии погашения, поскольку  OP_RETURN  не может быть погашен по определению.
 Обратите внимание, что, поскольку сценарий погашения не представлен в сеть, пока вы не попытаетесь потратить вывод P2SH, если вы заблокируете вывод с помощью хэша недопустимой транзакции, он будет обработан независимо. Однако вы не сможете их потратить, потому что транзакция расходов, которая включает сценарий погашения, не будет принята, поскольку это недопустимый сценарий. Это создает риск, потому что вы можете заблокировать биткойны в P2SH, которые нельзя будет потратить позже. Сеть примет обременение P2SH, даже если оно соответствует недопустимому сценарию погашения, поскольку хэш сценария не указывает на сценарий, который он представляет.
 Предупреждение 
 Сценарии блокировки P2SH содержат хэш сценария погашения, который не дает подсказки относительно содержимого самого скрипта погашения. Транзакция P2SH будет считаться действительной и принята, даже если сценарий погашения недействителен. Вы можете случайно заблокировать биткойн таким образом, чтобы его нельзя было потратить позже.
 Биткойн-скрипт завершен по Тьюрингу: «Игра жизни» от sCrypt является доказательством 
 Платформа
 Contracts sCrypt опубликовала код версии Биткойн-скрипта игры Конвея «Игра жизни» в качестве демонстрации того, что этот язык является полным по Тьюрингу и способен поддерживать состояние.Это ставит под сомнение противоречивое мнение противников биткойнов и сторонников платформ блокчейнов «умных контрактов» о том, что биткойн-скрипт не способен выполнять сложные вычисления.
 Игра жизни Конвея (или просто «Жизнь») - известный клеточный автомат, демонстрирующий полноту Тьюринга. Разработанный в 1970 году британским математиком Джоном Хортоном Конвеем, он «проигрывается» пользователем, вводящим начальное состояние, а затем наблюдающим, как набор ячеек развивается (или умирает). «Игрок» больше не может вводить данные после установки начального состояния.
 sCrypt описал, как работает система, в сообщении в блоге и опубликовал код биткойн-скрипта для ее запуска. Это доказывает способность биткойн-скрипта поддерживать состояние между блоками транзакций без необходимости выполнять все вычисления в цепочке.
 Game of Life была одной из первых реализаций полного CA по Тьюрингу, разработанной Джоном Хортоном Конвеем (1970). Он считается универсальным конструктором, что означает, что он может моделировать любую другую машину Тьюринга.
 Теперь это работает на BitCoin (BSV).https://t.co/EIBA6ZK2ws
 - Константинос Сганцос (@CostaSga) 10 декабря 2020 г.
  Почему так важна «полнота по Тьюрингу»? 
 sCrypt ранее публиковал исследовательский материал и код, доказывающие, что биткойн-скрипт является «завершенным по Тьюрингу» и, таким образом, выполняет любые вычислительные задачи, необходимые для создания контрактов.
 Одна из проблем заключается в том, может ли такая система, как Биткойн, которая работает путем широковещательной передачи и обработки транзакций в блоках, которые происходят каждые 10 минут, поддерживать «состояние», которое необходимо для данных из задачи, выполнение которой занимает более 10 минут.
 Создатель sCrypt и Биткойн доктор Крейг С. Райт давно утверждает, что состояние может сохраняться в нескольких блоках Биткойн, передавая выходные данные одного набора транзакций в другие, более поздние. Более новые транзакции должны будут проверять старые выходные данные, иначе функции не будут работать.
 «У sCrypt есть новая игрушка, но она подтверждает мое утверждение о том, что Биткойн - это полная Тьюринга», - сказал д-р Райт.
 Для тех, кто хочет услышать более подробное обсуждение Биткойна и полноты Тьюринга, этому посвящен целый эпизод «Теории Биткойна».
 Ayre Group и основатель CoinGeek Кэлвин Эйр, который часто приводил доводы в пользу Биткойна по этой конкретной теме, приветствовал новое доказательство sCrypt и сказал, что оно доказывает, что доктор Райт имеет гораздо более глубокое понимание Биткойна, чем кто-либо другой - понимание, которое могло прийти только из Биткойн сам изобретатель.
 Крейг снова доказал свою правоту ... его изобретение Биткойна было завершено по Тьюрингу, как и было задумано изначально. https://t.co/LJQjn4wLu0
 - Calvin Ayre (@CalvinAyre) 10 декабря 2020 г.
 «Мы должны кричать об этом с крыш, потому что это« маркер », упавший с неба… неопровержимое математическое доказательство того, что Крейг был прав, как мог быть только тот, кто изобрел Биткойн.”
 Что имеет в виду Эйр, когда говорит: «Крейг был прав»? Нам нужно заглянуть в историю Биткойна, блокчейна и некоторых из его самых известных идентичностей.
  Райт против Сабо, 2015 
 Аргумент о полноте по Тьюрингу используется уже более пяти лет. Это было подчеркнуто во время уже известного обмена мнениями между доктором Крейгом С. Райтом и криптографом Ником Сабо в ноябре 2015 года - одно из первых публичных выступлений доктора Райта в качестве спикера биткойнов, незадолго до его «выхода» в декабре 2015 года в качестве создателя биткойнов Сатоши Накамото. .
 Сабо выглядел ошеломленным и отвергающим предложение Райта в то время, в котором рассматривалось, как циклы могут быть выполнены на платформе, основанной на блокчейне. Доктор Райт сказал, что контуры управления в Forth (языке, на котором основан скрипт Биткойн) могут обрабатывать функцию цикла отдельно от кода Forth.
 Сабо утверждал, что если цикл не может быть выполнен в исходном коде, значит, он не был завершен по Тьюрингу. Райт возразил, что единственный способ написать такой код будет на самой «машине», предполагая, что попытка сделать это, как это сделал Ethereum, сделает систему нефункциональной и не масштабируемой.
 «Это была бы хорошая тема для вас, чтобы написать статью, потому что это определенно нетрадиционный взгляд на вас», - ответил Сабо.
 Доктор Райт действительно опубликовал такие статьи позже (здесь и здесь), хотя спор все еще бушует как в компьютерных науках, так и в общих дебатах.
  Эзотерическая концепция, но важная для понимания 
 Доктор Крейг Райт объясняет, почему сценарий Bitcoin SV на самом деле завершен по Тьюрингу (сентябрь 2018 г.) (https: // t.co / y6b5YePCJx) pic.twitter.com/3lQgZY2WrD
 - Рамон Кесада 🌷🇺🇸 (@RamonQuesadaT) 11 декабря 2020 г.
 Сабо был прав в том, что эта тема является эзотерической, по крайней мере, в том, что касается концепций информатики, которые посторонние могут с трудом понять. Однако это стало однострочным аргументом, отвергающим Биткойн в пользу блокчейнов, таких как Ethereum, которые были разработаны специально (по крайней мере, теоретически) для выполнения любых вычислений в цепочке.
 Проблема в том, что Ethereum долгое время изо всех сил пытался масштабироваться до уровней, которые потребовались бы для выполнения этих задач.Попытки решения этих проблем привели к тому, что Ethereum столкнулся с такими предложениями, как радикальные изменения протокола и экономических стимулов, такие как переход от Proof-of-Work к Proof-of-Stake.
 Биткойн, с другой стороны, может обрабатывать любой контракт в любом масштабе и имеет протокол, разработанный так, чтобы быть «высеченным в камне», неизменным, чтобы предотвратить нарушение стимулов процессоров, которые защищают сеть, и гарантировать, что любая транзакция транслируется сегодня ( и в последние 10 лет) будет действовать еще далеко в будущем.
 Все эти моменты важны для предприятий, правительств и разработчиков, которые хотят запускать крупномасштабные и сложные приложения. Дебаты о полноте Тьюринга могут быть эзотерическими, но в то же время их нельзя и не следует использовать в качестве аргумента против Биткойна. Поэтому понимание этого, по крайней мере на базовом уровне, важно для лиц, принимающих решения.
 Там, где альткойны и «конкурирующие» блокчейны технически не могут соответствовать BSV, они часто заменяются упрощенными аргументами, отвергающими технологию BSV, или «играют человеком, а не мячом» в форме убийств персонажей на Dr.Райт.
 Такие аргументы легко приводить на коротких форумах с непродолжительным сроком действия, таких как Twitter и другие социальные сети. Настоящая дискуссия ведется вокруг исследовательских работ, которые большинство не читают или не имеют подготовки для понимания.
 Опубликовав код для Игры Жизни в Биткойн-скрипте, sCrypt продемонстрировал простое, но технически обоснованное опровержение вопроса «Является ли биткойн по Тьюрингу завершенным? вопрос, и доказал то, о чем доктор Райт говорил за годы до того, как кто-либо даже задумался над этим.
 Несомненно, аргументы в стиле социальных сетей против Bitcoin BSV и его разработчиков будут продолжаться, но важно иметь возможность доказать свою неправоту, где бы они ни появлялись. И похоже, что Ник Сабо и другие должны извиниться перед доктором Райтом и должны публично признать, что он был прав. Мы не будем задерживать дыхание в ожидании.
   Впервые в Биткойн? Ознакомьтесь с разделом CoinGeek     Биткойн для начинающих    , полным справочником по ресурсам, чтобы узнать больше о Биткойне, как первоначально задумал Сатоши Накамото, и о блокчейне. 
 Bitcoin Script Engineer? Теперь есть карьера на будущее 
 Вы хотите, чтобы карьера разработчика программного обеспечения приносила много пользы в отрасли, которая делает вас пионером, просто присоединившись к ней? Независимо от того, являетесь ли вы опытным программистом, ищущим новые возможности, или новичком, пытающимся выбрать лучший язык программирования для изучения, стать разработчиком сценариев биткойнов может быть ответом.
 «Самая большая проблема, с которой я сталкиваюсь, - это найти инженеров с навыками работы с биткойнами», - сказал технический директор nChain Стив Шаддерс.«Мы тратим много времени и ресурсов внутри компании, чтобы помочь развить навыки разработчиков биткойнов, и не только нам приходится решать эту проблему. Спрос намного выше, чем может удовлетворить имеющийся пул разработчиков, обладающих навыками биткойнов ».
 Learning Bitcoin Script не только позволяет вам исследовать новый мир - это означает, что вы можете сыграть свою роль в его построении. Насколько велика эта часть, решать вам.
 Есть много ресурсов, доступных для тех, кто хочет вмешаться, и растущая сеть поддержки экспертов и мероприятий, которые помогут на этом пути.Читайте дальше, чтобы узнать, что доступно.
 Биткойн-скрипт
 - это не только обучение построению транзакций. Блокчейн может обрабатывать любые данные для проекта любого размера, поэтому возможности практически безграничны. Протокол Биткойна был восстановлен, «высечен в камне» и опубликован только в феврале 2020 года. С этим восстановлением был внесен ряд улучшений в его родной язык сценариев, значительно расширивший его возможности.
 Сам язык основан на Forth, стековом языке, распространенном во встроенных системах, который существует уже много лет.Выучить основы можно за день, но дальше все становится сложнее. Но даже этот день может поставить вас впереди большинства других разработчиков. Сегодня это редкость в индустрии разработки программного обеспечения, но на самом деле существует нехватка способных разработчиков.
  С чего начать 
 Лучшее место для поиска онлайн-ресурсов по сценарию Биткойн - это Bitcoin Association, BitcoinSV.com или официальная страница Bitcoin Wiki. Здесь есть все для начинающих и опытных, включая лекции и вебинары по этой теме.
 Также есть много информации от партнеров и третьих лиц по другим проектам.
 Помимо информационных ресурсов и руководств, Bitcoin Association также поддерживает ряд мероприятий, таких как Bitcoin SV DevCon и Hackathon. Хакатон проводится несколько раз в год, как личное мероприятие в обычное время и онлайн-мероприятие в 2020 году. Социальные сети Bitcoin BSV и онлайн-форумы также дают возможность пообщаться с другими. Биткойн-ассоциация, компании-разработчики, такие как nChain, местные представители и представители более широкой отрасли так же стремятся распространить информацию о биткойнах, как и помочь, поэтому легко найти то, что вам нужно.
 По данным Бюро труда и статистики США, средняя заработная плата разработчика программного обеспечения в 2018 году составляла около 50 долларов США в час или 105 500 долларов США в год. Разработчики системного программного обеспечения зарабатывают немного больше, чем разработчики приложений. Прогнозируемый рост составил 21% в период с 2018 по 2028 год, что намного выше, чем в других профессиях.
 Ситуация в мире могла измениться с тех пор, как были сделаны эти прогнозы, но биткойн также является уникальной отраслью. Он может даже выиграть в те времена, когда люди ищут новые решения.
 В Биткойне статус новичка является меньшим недостатком, чем в других позициях разработчиков. По их собственному признанию, даже самые опытные разработчики биткойнов все еще изучают весь потенциал биткойна. Есть все возможности открыть для себя что-то новое, о чем никто раньше не думал, или стать авторитетом в теме, которую мало кто понимает.
  Качество, а не количество 
 При выборе нового языка программисты часто сталкиваются с одной дилеммой: выбираете ли вы тот, который популярен и появляется в большинстве списков вакансий? Или вы выбираете что-то более специализированное, возможно, даже нишевое, с меньшим количеством доступных рабочих мест? Биткойн-скрипт может предложить лучшее из обоих миров.
 Проблема с первым вариантом - конкуренция - не только в вашем районе, но и во всем мире. Это означает конкуренцию и с зарплатой, и не в том направлении. Текущая статистика - это одно из указаний, но вы также должны думать о будущем.
 Также важно учитывать, насколько интересными будут проекты, над которыми вы работаете. Чем крупнее проект, тем меньшую роль вы в нем будете играть.
 Кроме того, биткойн-скрипт - это только «ниша» в относительном и временном смысле.Конечно, в сфере разработки биткойнов работает меньше людей по сравнению с теми, кто работает с Python, JavaScript или C ++. Но Биткойн - это не угасающая или малоизвестная индустрия. Он быстро растет, а это означает, что каждый месяц в отрасли появляется больше инвестиций и возможностей. Возможно, в будущем он станет одним из самых популярных языков в мире, но если вы начнете учить сейчас, вы станете экспертом - или лидером - когда придет время.
   Впервые в Биткойн? Ознакомьтесь с разделом CoinGeek     Биткойн для начинающих    , полным справочником по ресурсам, чтобы узнать больше о Биткойне, как первоначально задумал Сатоши Накамото, и о блокчейне. 
 Руководство по
 Bcoin | Биткойн-транзакции с привязкой по времени с CLTV 
 Блокированные по времени транзакции с биткойнами с CLTV 
 Что такое «CLTV»? 
 CLTV - это код операции на языке сценариев Биткойн, который позволяет
чтобы заблокировать UTXO (неизрасходованный вывод транзакции) по времени. то есть монета
не могут быть потрачены до тех пор, пока не пройдет определенное время или высота блокчейна.
В этом руководстве у нас будет функция, которая создает сценарий, который
блокирует UTXO на заданное время с помощью кода операции CLTV
а также отдельно узнайте, как подписывать эти типы специальных входов.
 Разблокировка неизрасходованного вывода TX (UTXO) 
 Отправка средств в биткойнах на самом деле просто указывает на вывод
предыдущей транзакции, что делает ее вводом для новой транзакции,
а затем выполнение некоторого условия блокировки для этого предыдущего вывода.
«Сценарии» - это условия, которые должны выполняться при выводе на
доказать право собственности. У вас может быть биткойн-скрипт, заблокированный
математическая задача «Что такое 2 + 5», и любой, кто знает, как ответить на «7», может «доказать»
право собственности на этот вывод (ознакомьтесь с этим руководством, Введение в создание сценариев
чтобы узнать, как написать и активировать этот простой скрипт в bcoin, и этот раздел в Mastering Bitcoin для полезного пошагового руководства).
 В подавляющем большинстве транзакций с биткойнами и другими криптовалютами
вы подтверждаете право собственности, подписывая ввод транзакции закрытым ключом
(в основном пароль, который хранится в вашем кошельке), который соответствует
адрес, на который был отправлен исходный вывод. Т.е. UTXO заблокирован
требованием, чтобы некоторая подпись соответствовала публичному ключу или публичному ключу
хэш, который находится в стеке выполнения.
 Выход, заблокированный с помощью CLTV, работает более или менее так же, но добавляет еще один
условие, что до того, как подпись даже будет принята, определенное количество
время должно быть прошло.
 В псевдокоде сценарий будет выглядеть так:
  Locktime (в блоках или время эпохи Unix)
Проверить, меньше ли время блокировки, чем nLocktime транзакции; выполнение не удается, если нет
Проверить совпадения хэша открытого ключа
Проверьте, подтверждает ли подпись  
 В биткойнах этот сценарий блокировки будет выглядеть примерно так:
  <некоторое время> CHECKLOCKTIMEVERIFY DROP DUP HASh260
<Погашение хэша открытого ключа> EQUALVERIFY CHECKSIG  
 Чтобы узнать больше о CLTV и о том, как он работает в биткойнах, ознакомьтесь с главой 07 в
Освоение биткойнов.См. Главу 06
для получения дополнительной информации о том, как работает стек и скрипты.
 Это руководство будет разбито на две части. Сначала мы пройдем через
создание и погашение фиктивной транзакции без реальных монет. Далее мы сделаем
То же самое в сети live regtest с использованием кошелька Bcoin и API.
 (Если вы хотите увидеть полный код, проверьте репо здесь)
 The Guide - Mock Transaction 
 Перед тем, как перейти к транзакции, есть некоторые настройки, которые будут полезны
для обоих подходов.Обратите внимание, что это руководство предполагает использование транзакций Segwit, поэтому
входные данные и скрипты погашения хранятся в поле свидетеля.
 Настройка 
 Давайте сначала настроим константы и импортируем модули, которые нам понадобятся для создания
и проводим наши транзакции.
 
const {
  Количество,
  Монета,
  Брелок для ключей,
  MTX,
  Сеть,
  Outpoint,
  Скрипт,
  ScriptNum,
  Стек
} = требуется ('bcoin');


const fs = require ('fs');
const assert = require ('assert');



const network = Network.get ('regtest');  
 Создание сценария 
 Давайте создадим функцию, которая принимает время блокировки и publicKeyHash
который соответствует закрытому ключу, который может погасить транзакцию
и возвращает объект типа  Script .Этот скрипт будет
в конечном итоге будет использоваться для блокировки нашего UTXO, то есть сценария блокировки.
 Обратите внимание, что для CLTV время блокировки может быть высотой блока  или  Временная метка Unix Epoch (секунды с 1 января 1970 г.), если выше 500 миллионов (
См. Спецификации BIP-065).
 
function createScript (locktime, publicKeyHash) {
  пусть пх;
  если (typeof publicKeyHash === 'строка')
    pkh = Buffer.from (publicKeyHash);
  иначе pkh = publicKeyHash;
  assert (Buffer.isBuffer (pkh), 'publicKey должен быть буфером');
  утверждать (
    время блокировки
    'Должен передать аргумент времени блокировки: высоту блока или время эпохи UNIX'
  );

  const script = new Script ();
  
  
  сценарий.pushNum (ScriptNum.fromString (locktime.toString (), 10));
  
  script.pushSym ('CHECKLOCKTIMEVERIFY');
  
  script.pushSym ('падение');
  
  
  script.pushSym ('дублировать');
  
  script.pushSym ('hash260')
  
  script.pushData (пкх);
  
  script.pushSym ('equalverify');
  
  script.pushSym ('контрольная цифра');
  
  
  script.compile ();
  сценарий возврата;
}  
 Этот сценарий довольно длинный и может быть дорогостоящим для отправки в транзакции.
Подобно тому, как обычно обрабатываются транзакции с множественной подписью,
давайте создадим метод для встраивания скрипта в P2WSH (Pay to Witness
Script Hash) адрес.
 
function getAddress (скрипт, сеть) {
  
  
  const p2wsh = script.forWitness ();
  const segwitAddress = p2wsh.getAddress (). toBech42 (сеть);
  return segwitAddress;
}  
 Выполнение транзакции 
 Вот шаги, которые мы пройдем:
 1) Настройка связок ключей - чтобы имитировать траты и получение из кошелька,
мы собираемся создать несколько связок ключей, которые будут управлять публично-частным
пары ключей, необходимые для генерации адресов и погашения UTXO.Обычно эти
управляются кошельком, но в демонстрационных целях
мы сделаем это вручную.
 2) Сделайте скрипт и сохраните его в связке ключей.  Примечание:  при изготовлении P2SH или
P2WSH скрипты, вам необходимо отслеживать скрипт, чтобы выкупить его позже.
 3) Создайте адрес P2WSH для получения (и блокировки) средств на
 4) Создайте наш фальшивый tx, который отправляет вывод на наш адрес блокировки
 5) Настройте наш выкуп tx с заблокированной монетой в качестве входа, потратив на
другой адрес и правильное время блокировки
 6) Подпишите и проверьте ввод
 

const amountToFund = Сумма.fromBTC ('. 5');


const flags = Script.flags.STANDARD_VERIFY_FLAGS;


const keyring = KeyRing.generate (истина);
const keyring2 = KeyRing.generate (истина);

const locktime = '100';
keyring.witness = true;
keyring2.witness = true;


const pkh = keyring.getKeyHash ();
const script = createScript (время блокировки, pkh);
keyring.script = скрипт;


const lockAddr = getAddress (скрипт, сеть);



const cb = новый MTX ();

cb.addInput ({
  prevout: новый Outpoint (),
  скрипт: новый скрипт (),
  последовательность: 0xffffffff
});




cb.addOutput (lockAddr, amountToFund.toValue ());






const coin = Coin.fromTX (cb, 0, -1);



let mtx = new MTX ();


mtx.addCoin (монета);


const receiveAddr = keyring2.getAddress ('строка', сеть);




const receiveValue = coin.value - 1000;
mtx.addOutput (receiveAddr, receiveValue);



console.log ('mtx:', mtx);  
 Сценарий и подпись входных данных 
 Мы собираемся создать два специальных метода для обработки этой части
поскольку мы можем использовать его и для живых транзакций. Модель  MTX  примитив в Bcoin имеет свою собственную версию (см. код
Вот)
но по умолчанию они могут обрабатывать только стандартные типы транзакций.
 scriptInput 
 Грубо говоря,  scriptInput  принимает индекс ввода
вы пишете сценарий, монету, из которой вы создаете ввод, и
брелок, использованный для его выкупа. Затем он шаблонизирует ввод (или свидетель
в этом случае), добавив полный скрипт погашения, необходимый для проверки хэша скрипта
и поставив OP_0 вместо подписи.
 В реальном методе есть больше проверок, чтобы увидеть, какой ввод,
(P2PKH, P2PK, P2SH и т. Д.), Для которых он написан.
 
function scriptInput (mtx, index, coin, ring) {
  const input = mtx.inputs [индекс];
  const prev = coin.script;
  const wsh = prev.getWitnessScripthash ();
  assert (кольцо instanceof KeyRing, 'Необходимо передать KeyRing в scriptInput');
  
  wredeem = кольцо.getRedeem (wsh);

  assert (wredeem, 'в связке ключей нет сценария погашения');

  константный вектор = новый стек ();

  
  vector.pushInt (0);
  vector.pushInt (0);

  
  vector.push (wredeem.toRaw ());

  input.witness.fromStack (вектор);
  mtx.inputs [индекс] = вход;
  вернуть mtx;
}  
 signInput 
  signInput  принимает те же параметры, просто проверяет ввод / свидетель,
заменяет OP_0 подписью, чтобы удовлетворить сценарий.
 Это упрощенная версия версии  signInput , которая находится на
класс  MTX  в bcoin.
 
function signInput (mtx, index, coin, ring) {
  const input = mtx.inputs [индекс];
  пусть свидетель, версия;

  const redeem = input.witness.getRedeem ();

  утверждать (
    выкупать,
    "Свидетель не был создан по шаблону"
  );

  свидетель = input.witness;
  
  
  версия = 1;

  константный стек = witness.toStack ();
  
  
  const sig =
    mtx.signature (
      показатель,
      wredeem
      монета.ценность,
      ring.privateKey,
      значение NULL,
      версия
    );
  stack.setData (0, сигн);

  stack.setData (1, кольцо.getPublicKey ());
  witness.fromStack (стек);
  вернуть mtx;
}  
 Теперь, когда мы можем написать сценарий и подписать, давайте завершим транзакцию!
Помимо подписи нам также необходимо установить параметр nLocktime
сделки. В реальной среде блокчейна это будет
проверяется на текущее состояние цепочки в мемпуле. Так,
транзакция с nLocktime позже, чем текущая высота блока
или время будут отклонены как недействительные.
  mtx = scriptInput (mtx, 0, монета, брелок);
mtx = signInput (mtx, 0, монета, брелок);





mtx.setLocktime (parseInt (время блокировки));




console.log ('подписанный mtx:', mtx);
assert (mtx.verify (флаги), «mtx не проверял»);


const tx = mtx.toTX ();


assert (tx.verify (mtx.view), 'tx не проверял');
console.log («Транзакция подтверждена!»);  
 Живая транзакция CLTV 
 Давайте протестируем это в сети regtest, чтобы мы могли легко
майнить наши собственные блоки, чтобы проверить, все ли работает.
 Некоторые из ключевых отличий в живом исполнении:
 1) Нам нужно использовать настоящие UTXO / монеты
 2) Нам нужно вручную отслеживать скрипт выкупа
 3) Будем взаимодействовать с REST API для подписи
нашей сделки
 4) Нам нужно будет сверить с реальной высотой
блокчейн для выкупа
 Сначала нам нужно настроить наших клиентов Bcoin, чтобы мы могли поговорить
в наш узел и кошелек. Убедитесь, что у вас есть
bclient установлен.
 

const {WalletClient, NodeClient} = require ('bclient');
const network = Network.get ('regtest');



const apiKey = fs.readFileSync ('./ secrets.env');
const clientOptions = {
  сеть: network.type,
  apiKey: apiKey.toString ()
}
const walletClient = новый WalletClient ({... clientOptions, порт: network.walletPort});
const nodeClient = новый NodeClient ({... clientOptions, порт: network.rpcPort});  
 Поскольку кошелек Bcoin изначально не поддерживает монеты CLTV,
мы собираемся реализовать собственное наивное постоянное хранилище, чтобы
мы можем сохранить ссылку на скрипт погашения, адрес блокировки (адрес P2WSH),
время блокировки и адрес погашения.Мы сделаем это, сохранив эту информацию
в объект json в отдельный текстовый файл.
 Для этой части кода у нас будет две ветки оценки.
Сначала мы проверим, есть ли у нас этот файл с сохраненной в нем информацией. Если мы этого не сделаем,
тогда нам нужно выполнить транзакцию блокировки. Если да, то проверяем,
высота блока соответствует требованиям времени блокировки (сохранено в нашем документе) и
создать, подписать и транслировать нашу транзакцию погашения
  асинхронная функция lockAndRedeemCLTV (walletId) {
  пытаться {
    const txInfoPath = './tx-info.json ';
    const wallet = walletClient.wallet (walletId);

    пусть redeemScript, lockAddr, locktime;

    
    пусть txInfo = fs.existsSync (txInfoPath)? fs.readFileSync (txInfoPath): '';
    if (! txInfo.length) {
      
      

      
      const {баланс} = ждать wallet.getInfo ();
      assert (balance.confirmed> amountToFund.toValue (), 'Недостаточно средств!');

      
      
      const {publicKey, address} = ожидание wallet.createAddress ('по умолчанию');

      
      
      const keyring = Кольцо ключей.fromKey (Buffer.from (publicKey, 'hex'), true);
      keyring.witness = true;
      const pkh = keyring.getKeyHash ();

      
      const {цепочка: {высота}} = ждать nodeClient.getInfo ();
      время блокировки = высота + 10;

      
      redeemScript = createScript (locktime.toString (), pkh);
      lockAddr = getAddress (redeemScript, сеть);

      
      const output = {
        значение: amountToFund.toValue (),
        адрес: lockAddr
      };

      const lockedTx = ожидание wallet.send ({выходы: [выход], скорость: 7000});
      консоль.log ('транзакция отправлена ​​в мемпул');

      
      txInfo = {lockedTx, lockAddr, redeemScript, locktime, redeemAddress: address};
      fs.writeFileSync (txInfoPath, JSON.stringify (txInfo, null, 2));

      
      
      
      
      
      
      
      const minedBlock = ожидание nodeClient.execute ('генерировать', [1]);
      console.log ('Блок заминирован', minedBlock);
    } else {
      
      
      const {
        lockTx,
        lockAddr,
        redeemScript
        время блокировки
        redeemAddress
      } = JSON.синтаксический анализ (txInfo);

      
      const {цепочка: {высота}} = ждать nodeClient.getInfo ();

      
      assert (locktime <= height, `Слишком рано для погашения UTXO. Подождите, пока блок $ {locktime}`);

      

      

      
      const index = lockedTx.outputs.findIndex (
        output => output.address === lockAddr
      );

      
      
      const coinJSON = ждать nodeClient.getCoin (lockedTx.hash, index);

      
      
      const coin = Coin.fromJSON (coinJSON);
      let mtx = new MTX ();
      mtx.addCoin (монета);

      
      
      
      const {адрес} = ожидание wallet.createAddress («по умолчанию»);
      
      mtx.addOutput (адрес, coin.value - 1500);

      
      
      
      mtx.setLocktime (высота);

      

      
      const script = Script.fromRaw (redeemScript, 'шестнадцатеричный');

      
      
      
      
      
      const {privateKey} = ждать кошелек.getWIF (redeemAddress);
      const ring = KeyRing.fromSecret (privateKey, сеть);
      ring.witness = true;
      ring.script = скрипт;

      
      
      mtx = scriptInput (mtx, индекс, монета, кольцо);
      mtx = signInput (mtx, индекс, монета, кольцо);

      
      
      
      
      
      утверждать (mtx.verify (), 'MTX не проверял');
      const tx = mtx.toTX ();
      assert (tx.verify (mtx.view), 'TX не проверял');
      const raw = tx.toRaw (). toString ('шестнадцатеричный');

      
      const результат = ждать nodeClient.broadcast (необработанный);
      assert (result.success, 'Проблема с передачей tx');

      
      
      
      
      
      const txFromHash = ждать nodeClient.getTX (tx.rhash ());
      assert (txFromHash, 'Кажется, что tx не находится в пуле памяти или цепочке');
      console.log («Успех!»);
      консоль.журнал ('Tx:', tx);

      
      
      fs.writeFileSync (txInfoPath, '');
    }

  } catch (e) {
    console.error ('При работающем решении произошла ошибка:', e);
  }
};  
 Теперь вы можете запустить  lockAndRedeemCLTV  один раз, чтобы отправить транзакцию CLTV, и еще раз, чтобы погасить ее.
в живой сети Regtest! Не стесняйтесь экспериментировать с различными значениями, чтобы увидеть, как это работает.
Вы можете использовать разные кошельки, изменить время блокировки или изменить сумму выкупа. Взглянем
в файле JSON, который сохраняется после создания транзакции, чтобы увидеть, как выглядит необработанная информация
подобное необходимо для искупления.
 Дальнейшие действия 
 То, что мы создали в этом руководстве, по сути, представляет собой очень простой смарт-контракт, который блокирует средства для
определенное количество времени. Этот пример может служить строительным блоком для гораздо более сложных
скрипты и контракты. Вот несколько идей, которые можно создать с помощью транзакций CLTV:
  Контракты с временной блокировкой хеширования  -
Также известные как HTLC. Это ключевая часть обеспечения надежных платежных каналов в Lightning Network и
есть скрипт с временной привязкой, который мы создали здесь, в его основе.
  Kill Switch Transaction  - Вы можете создать приложение, которое использует CLTV для обеспечения выполнения условия
где, если каждые 6 месяцев не предпринимаются какие-либо действия (например, нажатие кнопки или отправка электронного письма),
транзакция отправит все ваши средства на адрес с несколькими подписями, контролируемый вашим имуществом.