Raw транзакций bitcoin расшифровка

Модель транзакций и протокола Bitcoin

Bitcoin (от англ. “bit” + ”coin” – двоичные деньги) – один из самых популярных представителей децентрилизованных платежных систем, в качестве денежной еденицы которого выступают биткоины (BTC). Важное свойство подобной системы – вся информация о транзакциях между участниками системы находится в общем доступе и может быть проверена любым участником.

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

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

Contents

Механизм работы Bitcoin

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

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

Таким образом, постоянность и неизменность данных блокчейна основывается на вычислительной мощности «честных» узлов. Если злоумышленник располагает достаточной вычислительной мощностью, он может модифицировать уже принятый узлами блок или разветвить блокчейн в свою пользу. Помимо применения технологий блокчейна в качестве платежной системы, блокчейн Биткоина может рассматриваться как способ постоянного записывания состояния системы в сети по типу p2p, без нужды в доверенном лице. Если система — это валюта, то состояние системы рассматривается как количество денег на каждом аккаунте. Подобная идея может быть использована в случае, когда система – смарт-контракт, другими словами исполняемый компьютерный протокол, который также может применяться при переводе денег.

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

На основе вышесказанного можно определить основные операции, которые проводятся в сети Bitcoin, а именно:

1. Создание транзакции
2. Распространение записи транзакции между всеми узлами сети
3. Проверка корректности транзакции
4. Генерация (майнинг) блока

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

Распространение записи транзакции между всеми узлами сети

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

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

Проверка корректности транзакции

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

1) Корректность формата транзакции (проверка структуры и семантики)

2) Факт принадлежности пользователю тех средств, которые он хочет перевести

Для выяснения принадлежности средств необходимо проверить весь блокчейн на предмет того, не была ли потрачена ранее та транзакция, на которую Алиса ссылается. Из-за того, что «книга бухучета» имеет большой объем, так как в ней хранятся все записи о всех транзакциях с начала существования сети Bitcoin, то для проверки баланса используется так называемый UTXO pool (unspent transaction output) — транзакции, которые были добавлены в блокчейн, но на данные транзакции еще никто не ссылался («потраченные» транзакции хранятся в блокчейне для исторической достоверности). Это обусловлено тем, что на транзакцию можно ссылаться только тогда, когда с нее не переведены средства на другую транзакцию. Тем самым, храня только UTXO pool, можно быстро подсчитать, каким количеством средств может воспользоваться Алиса.

При проверки корректности формата транзакции ведутся следующие проверки:

— Размер транзакции в байтах не должен превышать установленной границы

— Сумма входов >= сумма выходов

— Проверка, что скрипты транзакций, на которые ссылается T, дают значение «истина»

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

Генерация (майнинг) блока

Основной процесс, на котором строится сеть Bitcoin это майнинг (от английского mining — добыча полезных ископаемых). Майнинг состоит в создании блоков транзакций с целью получения вознаграждения, с каждым новым добавленным блоком происходит эмиссия 12.5 BTC (на 2018 год). Однако наиболее важная цель майнинга — обеспечение работы всей сети, так как именно с помощью генерации и занесения блоков в блокчейн происходит подтверждение транзакции.

Основные свойства майнинга блока в сети Bitcoin:

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

Структура блока представлена на рисунке 2:

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

Чтобы блок считался корректным, в него должны входить транзакции из пула неподтвержденных транзакций, а также должно быть подобрано такое значение поля nonce, чтобы хэш блока принимал значение, меньшее чем target (то есть имел в начале определенное количество нулей). Перерасчет target value происходит каждые 2016 блоков на основе времени их генерации, чтобы настроить время генерации блока равным примерно 10 минут. Такая калибровка необходима из-за роста вычислительной мощности сети Bitcoin, которая увеличивается изо дня в день. Так как используется криптографически стойкая хэш функция при вычислении хэша блока, невозможно заранее предсказать хэш, поэтому nonce ищется сугубо перебором всех допустимых значений. Если никакая из nonce не подходит, значит требуется изменить что-то еще в блоке, что повлияет на вычисление хэша. Обычно это метка времени.

Именно показателем target балансируется время генерации блока в сети — если нынешняя мощность сети позволит сгененировать блок за меньшее время, то target уменьшится, таким образом усложняя задачу генерации блоков и наоборот.

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

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

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

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

Структура транзакции

Условно в транзакции присутствуют два поля – input и output. Для наглядности рассмотрим пример, представленный на рисунке 3.

Данная транзакция использует BTC из транзакции f5d8ee3… и пересылает их на адрес 40437170….

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

Input

Поле input ссылается на отдельное поле output другой транзакции (так как транзакция может иметь несколько независимых выходов). Все BTC от транзакций в поле input суммируются и данная сумма должна целиком быть использована в данной транзакции. Поле Previous tx является ссылкой на предыдущую транзакцию, а поле Index указывает, какой именно выход транзакции используется.

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

Output

Поле output содержит инструкции для отправки BTC. Поле value показывает количество Satoshi (1 BTC=100 000 000 Satoshi), которые этот output будет содержать, когда на него будут ссылаться.

scriptPubKey является скриптом, который должен давать значение «истина» для того, чтобы перевести BTC с этой транзакции на другую. Для проверки скрипта поле scriptSig и scriptPubKey конкатенируются, затем скрипт выполняется. Стоит отметить, что скрипт представляет собой стек команд, где выходные данные одной команды поступают на вход другой команды. Благодаря такой системе скриптов, отправитель может создавать очень разнотипные условия выдачи BTC. Например, можно создать output таким образом, чтобы BTC этой транзакции мог получить любой пользователь. Также возможно создать скрипт, для выполнения которого требуется указывать пароль вместо ключа.

Связь транзакций

Для примера, рассмотрим две абстрактные транзакции Т0 и Т1, представленных на рисунке 4, где транзакция Т0 содержит u0 биткоинов, которые могут быть «выплачены», то есть присвоены другому пользователю, с помощью попадания в блокчейн записи Т1, чье поле input (источник) ссылается на транзакцию Т0.

Чтобы получить деньги из транзакции Т0, получатель должен сгенерировать такие данные, чтобы скрипт, указанный в транзакции Т0 дал значение «истина». Когда данное условие выполняется, деньги из транзакции Т0 теперь содержатся в новой транзакции Т1, а транзакция Т0 больше не может использоваться как входная транзакция в будущем, то есть обналичена повторно.

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

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

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

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

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

Оплата с помощью адреса (Pay to address)

Такой тип транзакций является самым встречаемым в блокчейне. В данном случае в качестве адреса выступает не сам публичный ключ пользователя, а хэш от него. Таким образом идет уменьшение адреса получателя до 20 бит. Также повышается безопасность проведения такого рода транзакции, так как только владелец публичного ключа может предъявить строку, хэш от которой будет равен заявленному в скрипте. Когда происходит перевод BTC с одной транзакции на другую, получатель предоставляет подпись и свой публичный ключ. Скрипт проверяет, что хэш от предоставленного публичного ключа совпадает с указанныв в поле output хэшем, а затем проверяет подпись с помощью публичного ключа.

scriptPubkey: OP_DUP OP_HASH160

Оплата с помощью публичного ключа (Pay to Public Key)

Является самым первым типом скриптов на заре зарождения Bitcoin, где в скрипте в качестве адреса изначально указывался ip адрес получателя, а в последствии уже публичный ключ. Минус такого типа скрипта состоит в том, что адрес платежа имеет больший размер и представлен в явном виде, что может использоваться для подделки подписи.

Множественная подпись (Multi Signature)

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

Яркий пример использования – у крупной компании есть адрес в сети Bitcoin с некоторым количеством BTC, которыми можно воспользоваться с этого адреса. Конечно, иррационально доверять только одному сотруднику пароль и возникает задача спроектировать скрипт таким образом, чтобы BTC с транзакции можно было перевести только при одобрении более, чем одним пользователем.

На примере подписания 2 из 3 – любые комбинации подписи на двух ключах могут разблокировать данную транзакцию.

scriptSig: или любые другие сочетания из 1, 2, 3 по два

Оплата с помощью хэша скрипта (Pay to Script Hash)

Данный тип скрипта используется для того, чтобы переложить ответственность за напсание скрипта для выполнения с отправителя средств на получателя. Таким образом отправитель может «проспонсировать» сколь угодно сложную транзакцию, используя scriptPubKey.

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

Скрипт будет выглядеть так:

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

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

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

После стандартной комбинации scriptSig||scriptPubKey получается:

Теперь проверка идет таким образом:

1) Сначала сравнивается указанный хэш с получаемым от скрипта хэшом

2) Если условие выполнено, выполняется погашающий скрипт

Основные преимущества PayToScriptHash:

1) Сложный скрипт заменяется хэшем этого скрипта, делая транзакцию короче

2) Хэш скрипта можно воспринимать как его «адрес», поэтому не нужно использовать специализированный клиент для создания транзакции со сложным скриптом

3) PayToScriptHash перекладывает ответственность за создание скрипта с отправителя на получается

4) PayToScriptHash перекладывает хранение длинного скрипта с настоящего времени на будущее (когда этот сложный скрипт будет предоставлен при получении средств)

5) PayToScriptHash перекладывает назначение вознаграждения за обработку большой транзакции с отправителя на получателя.

Скрипт для хранения данных в блокчейне (OP_RETURN)

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

OP_RETURN ‘cryptowiki 4ever’

Транзакция, которую может присвоить любой (Anyone Can Spend)

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

Пример выполнения скрипта

scriptPubkey: OP_DUP OP_HASH160

Для проверки выполнимости скрипта сначала идет конкатенация значений scriptSig и ScriptPubKey:

Затем данные заносятся в стек и происходит выполнение скрипта. Пример выполнения скрипта представлен на рисунке 5.

Источник