Что такое rss в подписи биткоин
Шифрование в блокчейне: зачем нужна цифровая подпись
В материале расскажем о том, какие инструменты позволяют подтверждать личность при использовании блокчейна. Вы узнаете как при совершении транзакций удается проверять данные и оставлять их в тайне.
Вспоминаем основные понятия
Симметричное и асимметричное шифрование
Рассказать секрет так, чтобы о нем никто не узнал, проще всего лично. Когда такой возможности нет, используют шифрование. Существует два криптографических метода: симметричный и асимметричный. Описание методов понадобится для понимания работы публичных и приватных ключей в блокчейне.
До изобретения интернета все известные методы шифрования были симметричными. Это значит, что ключ для шифрования и расшифровки информации использовался один и тот же. Все как с обычными дверными замками: один ключ открывает и закрывает дверь.
При таком подходе всегда остается вероятность того, что к сообщению получат доступ третьи лица. Нет смысла отправлять зашифрованное сообщение, если получатель не сможет его расшифровать. А отправлять ключ для расшифровки небезопасно, так как курьер может оказаться злоумышленником или подвергнуться нападению. В этом главная проблема — невозможно безопасно передать получателю ключ для расшифровки.
Ключ для расшифровки отправляется. Поэтому злоумышленник может им воспользоваться, чтобы расшифровать сообщение
В 70-ых годах были придуманы асимметричные методы. С помощью них шифрование и расшифровка информации производится двумя разными ключами. Похоже на то, что дверь закрывают одним ключом, а открывают другим.
Получатель раздает ключи шифрования всем, кто желает отправлять ему сообщения. По-другому ключи называются публичными, так как их может увидеть или узнать любой. А ключ для расшифровки он оставляет у себя. Еще его называют приватным, так как его знает только получатель.
Асимметричное шифрование с помощью парных ключей решает проблему безопасности симметричных шифров. Ключ для расшифровки больше не нужно отправлять и подвергать опасности, он уже есть у каждого получателя. Любой отправитель может зашифровать информацию так, что расшифровать ее сможет только получатель.
Отправляется только ключ для шифрования. Даже если злоумышленник его получит, расшифровать сообщение не удастся.
Асимметричное шифрование делает интернет безопасным. Каждый пользователь использует приватные и публичные ключи, когда отправляет сообщение в мессенджере, совершает онлайн-покупку или посещает сайт, адрес которого начинается с «https». Благодаря этому, никто не может прочитать сообщения, увидеть пароли или скопировать данные банковской карты.
При использовании приватных и публичных ключей вытекают два важных элемента блокчейна: адрес и цифровая подпись. С помощью них удается пользоваться блокчейном, не раскрывая свою личность. Рассмотрим каждое из этих понятий подробнее.
Публичный ключ и адрес в блокчейне
С помощью публичных ключей создаются адреса пользователей блокчейна. Это данные, которые указывают на получателя транзакции. В жизни для этой цели мы используем номер телефона, адрес дома или счет в банке. Особенность адресов в блокчейне в том, что они могут постоянно меняться. Рассмотрим их использование на примере блокчейна Биткоина.
Прежде чем купить биткоины, необходимо создать кошелек, на котором они будут храниться. Кошельком называют программу, с помощью которой можно получить как приватные, так и публичные ключи от блокчейна. Для биткоинов есть много таких программ: Bitcoin Core, Electrum, Samurai Wallet.
При открытии кошелька будут математически сгенерированы пары ключей. Публичные ключи состоят из 66-ти знаков, поэтому их неудобно указывать при получении средств. Для удобства с помощью математических преобразований из них создаются адреса. Каждый адрес представляет собой более короткую последовательность из цифр и букв, либо QR-код.
С помощью публичного ключа создается адрес или QR-код адреса
Наличие сразу нескольких пар публичных и приватных ключей делает использование кошелька безопасным. Можно каждый раз получать и отправлять биткоины с помощью разных адресов. В таком случае, отследить кому принадлежат эти адреса будет почти невозможно.
Если вы хотите получить биткоины, то любой из адресов нужно сообщить отправителю. Когда биткоины придут, воспользоваться ими можно будет с помощью приватного ключа.
Приватный ключ и цифровая подпись в блокчейне
Адрес в блокчейне принадлежит тому, кто знает от него приватный ключ. Чтобы доказать, что он у вас есть и при этом не раскрыть его никому, используют цифровую подпись.
Цифровая подпись — это хеш, созданный на основе приватного ключа и самих подписываемых данных. То есть это набор символов, который получен с помощью шифрования. В Биткоине для создания такого хеша используют Алгоритм Цифровой Подписи Эллиптической Кривой (ECDSA).
Рассмотрим как создается и подписывается транзакция в блкочейне:
Теперь, когда в транзакции есть подпись, другие пользователи блокчейна должны подтвердить ее. Подтверждение необходимо, чтобы убедиться, что злоумышленник не пытается украсть биткоины со счета. Для этого подпись расшифровывается с помощью публичного ключа. Если расшифрованная информация совпадает с хешем, то транзакция признается достоверной.
Пользователи блокчейна проверяют достоверность транзакции, сравнивая хеш данных с расшифровкой открытого ключа
Цифровая подпись транзакции по сути является шифрованием с использованием приватного ключа. А проверка подписи это расшифровка с использованием публичного ключа. Это похоже на конструктор, который разбирается по одной инструкции, а собирается по другой. Если вам удалось его собрать по инструкции сборки, значит у того, кто его разбирал, была инструкция по разборке. Если удалось правильно расшифровать подпись, значит тот, кто ее создал действительно владеет приватным ключом.
Таким образом, достоверной транзакция будет признана только в том случае, если оба ключа составляют одну пару. Такая система проверки цифровой подписи гарантирует, что только лицо, у которого есть оба ключа сможет распоряжаться биткоинами.
Заключение
Пользователи блокчейна взаимодействуют друг с другом используя асимметричное шифрование. Оно заключается в использовании двух ключей. Публичный ключ нужен, чтобы пользователя можно было найти в сети и отправить ему зашифрованное сообщение. Приватный ключ нужен, чтобы расшифровать полученное сообщение.
Кроме того, с помощью приватных и публичных ключей подтверждается личность пользователей блокчейна. Криптографические алгоритмы позволяют создавать и проверять цифровые подписи.
«Криптография в блокчейнах»: о хеш-функциях, ключах и цифровых подписях
Криптография — это сердце блокчейна, которое обеспечивает работу системы. Архитектура блокчейна предполагает, что доверие между участниками сети базируется на принципах математики и экономики, то есть является формализованным. Криптография также гарантирует безопасность, причем основанную на прозрачности и проверяемости всех операций, а не на традиционном для индустрии ограничении видимости системы (perimeter security).
Различные криптографические техники гарантируют неизменность журнала транзакций блокчейна, решают задачу аутентификации и контролируют доступ к сети и данным в блокчейне в целом. В сегодняшнем материале мы поговорим о хеш-функциях, ключах и цифровых подписях.
Хеш-функции
Хеширование — это процесс преобразования массива входных данных произвольной длины в (выходную) битовую строку фиксированной длины. Например, хеш-функция может принимать строку с любым количеством знаков (одна буква или целое литературное произведение), а на выходе получать строку со строго определенным числом символов (дайджест).
Хеш-функции имеются практически в любом языке программирования. Например, они используются для реализации хеш-таблиц и множеств (HashMap/HashSet в Java, dict и set в Python, Map, Set и объекты в JavaScript и так далее). Отдельная категория хеш-функций — криптографические хеш-функции. К ним предъявляются существенно более строгие требования, чем к функциям, обычно используемым в хеш-таблицах. Поэтому и применяются они в более «серьезных» случаях, например для хранения паролей. Криптографические хеш-функции вырабатываются и тщательно проверяются исследователями по всему миру.
Поэкспериментировать с хеш-функциями можно, написав простую программу на Python:
Функция hash_hex() рассчитывает представление хеша в шестнадцатеричной записи для строки. В приведенном примере используется функция SHA-256 — та же, что и в биткойне.
Хорошая хеш-функция обеспечивает защиту от коллизий (невозможно получить два одинаковых хеша при разных начальных данных) и обладает так называемым эффектом лавины, когда малейшее изменение входных данных значительно преобразует выходное значение. Эффект лавины в хеш-функции SHA-256 выглядит следующим образом:
Хеш-функции в блокчейнах гарантируют «необратимость» всей цепочки транзакций. Дело в том, что каждый новый блок транзакций ссылается на хеш предыдущего блока в реестре. Хеш самого блока зависит от всех транзакций в блоке, но вместо того, чтобы последовательно передавать транзакции хеш-функции, они собираются в одно хеш-значение при помощи двоичного дерева с хешами (дерево Меркла). Таким образом, хеши используются как замена указателям в обычных структурах данных: связанных списках и двоичных деревьях.
За счет использования хешей общее состояние блокчейна — все когда-либо выполненные транзакции и их последовательность — можно выразить одним-единственным числом: хешем самого нового блока. Поэтому свойство неизменности хеша одного блока гарантирует неизменность всего блокчейна.
Ниже приведена рекурсивная реализация дерева Меркла, используемая в биткойне, на языке Python (по ссылке вы найдете примеры работы). На вход функции подается список хешей транзакций. На каждом этапе вычисления последовательные пары хешей склеиваются при помощи хеш-функции; если хешей нечетное число, то последний дублируется. В результате остается единственный хеш, который и является конечным хеш-значением для всего списка.
Хеш-деревья имеют много применений помимо блокчейнов. Они используются в файловых системах для проверки целостности файлов, распределенных БД для быстрой синхронизации копий и в управлении ключами для надежного журналирования выдачи сертификатов. Git использует обобщение хеш-деревьев — направленные ациклические графы на основе хешей. В блокчейне использование хеш-деревьев продиктовано соображениями производительности, так как они делают возможным существование «легких клиентов», которые обрабатывают лишь малую часть транзакций из блокчейна.
Цифровые подписи
Цифровые подписи в блокчейнах базируются на криптографии с открытым ключом. В ней используются два ключа. Первый — закрытый ключ — нужен для формирования цифровых подписей и хранится в секрете. Второй — открытый ключ — используется для проверки электронной подписи. Открытый ключ реально вычислить на основе закрытого ключа, а вот обратное преобразование требует невозможного на практике объема вычислений, сравнимого с брут-форсом.
Существует множество различных схем криптографии с открытым ключом. Две самые популярные из них — это схемы на основе разложения на множители (RSA) и схемы на основе эллиптических кривых. Последние более популярны в блокчейнах из-за меньшего размера ключей и подписей. Например, в биткойне используется стандарт эллиптической криптографии ECDSA вместе с эллиптической кривой secp256k1. В ней закрытый ключ имеет длину 32 байта, открытый — 33 байта, а подпись — около 70 байт.
Общая идея подписей с открытым ключом выглядит следующим образом. Предположим, что Алиса хочет перевести Бобу один биткойн. Для этого она формирует транзакцию, где записывает, откуда его следует брать (указание на предыдущую транзакцию, в которой Алиса получила биткойн от кого-то еще) и кому отправить (открытый ключ Боба). Алиса знает открытый ключ Боба из сторонних источников — Боб может послать его Алисе через мессенджер или даже опубликовать его на сайте.
Затем Алиса подписывает транзакцию, используя свой секретный ключ. Любой узел в биткойн-сети может проверить, что транзакция подписана определенным открытым ключом (аутентификация), с которым до выполнения транзакции был ассоциирован один биткойн (авторизация). Если эти условия выполнены, то переведенный биткойн начинает ассоциироваться с открытым ключом Боба.
Поскольку в блокчейне нет центрального узла, который может авторизовать произвольные транзакции, безопасность системы становится децентрализованной, а вероятность успешного вмешательства в работу блокчейна снижается практически до нуля.
Таким образом, блокчейн использует цифровые подписи для аутентификации и обеспечения целостности транзакций (и иногда блоков). В случае криптовалюты процесс аутентификации означает, что потратить средства может только тот человек, которому они были посланы другой, более ранней, транзакцией. Особенность блокчейна состоит в том, что информация об аутентификации «вшита» в каждую транзакцию, а не отделена от бизнес-логики, поэтому блокчейн считается более защищенным. В обычной системе можно взломать или административно обойти механизм аутентификации и провести манипуляции с бэкэндом, а в блокчейне сделать этого не получится по определению.
Схема Шнорра и её роль в Биткоине
Содержание
Суть протокола Шнорра
Схема подписи Шнорра
Почему подписи Шнорра считаются лучше ECDSA?
Комментарий от автора
Данная статья рассчитана на людей, уже знакомых с основами защиты информации. Если слова «Протокол доказательства знания», «Криптосистема с открытым ключом» не являются для Вас заклинаниями, you’re welcome!
Историческая справка
В 2008 году, в том же году, когда Сатоши Накамото представил миру Биткойн, срок действия патента Клауса Шнорра истёк. Даже несмотря на то что подписи Шнорра уже можно было использовать, Сатоши Накамото выбрал для Биткоина ECDSA. Это связано с тем, что схема Шнорра ещё не являлась стандартизированной и широко используемой.
Хоть криптографы зачастую и считают ECDSA неудачным, он до сих пор используется. К слову, DSA, предшественник ECDSA, представлял собой гибрид схем Эль-Гамаля и Шнорра, созданный исключительно для обхода патентов Клауса Шнорра Национальным институтом стандартов и технологий США (NIST). После его появления в рассылке Coderpunks начался, что называется, интеллигентный срач, а Клаус Шнорр стал ещё активнее защищать свои патенты.
Суть протокола Шнорра
Вообще говоря схема Шнорра является одним из вариантов протоколов доказательства с нулевым раскрытием. Доказываем мы то, что для некоторого публичного ключа h, который суть элемент группы с фиксированным порождающим элементом g, известен секрет x такой что g степени x суть у нас публичный ключ h.
Также, стоит заметить что протокол интерактивный, т.е. подразумевается многораундовый обмен сообщениями между участниками.
Первым делом Алиса выбирает случайное число k из подгруппы порядка q, оно должно быть уникально для каждой сессии. Затем Алиса считает I и посылает его Бобу.
Боб также выбирает случайное число из подгруппы и отправляет его обратно Алисе.
Алиса вычисляет s и отправляет его Бобу.
Боб совершает проверку и подтверждает.
Схема подписи
Стоит заметить, что на вход хэш-функции идёт элемент группы и сообщение m (это хоть и может быть также элементом группы, но зачастую это просто битовая строка), в таком случае вместо I следует подавать выход некой функции, которая элемент группы переводит в битовую строку.
Вычисление значения r таким образом (изначальная схема подписи): 
называется слабым преобразованием Фиата-Шамира, оно НЕ является безопасным. На практике же стоит также добавлять в r ещё и публичный ключ pk. Слабым преобразованием Фиата-Шамира пользовались до 2010-х годов, хотя оно встречается и сейчас, в нём были найдены различные уязвимости, в частности, например, в системе электронного голосования Helios.
Почему подписи Шнорра считаются лучше ECDSA?
Чтобы ответить на этот вопрос давайте рассмотрим три основных критерия, по которым мы сравним ECDSA и подписи Шнорра.
Безопасность ECDSA
Вообще говоря, для ECDSA отсутствуют доказательства безопасности для задачи дискретного логарифмирования в группе точек эллиптической кривой при использовании случайного генератора группы, но на самом деле это не основная причина, по которой многие хотят изменить ECDSA на подписи Шнорра. С 2009 года ECDSA на кривой x 3 +7 достаточно надёжно работает, и если и была обнаружена какая-то критическая уязвимость, то уже давно об этом знали. То есть фактически на данный момент ECDSA и описанной кривой вполне достаточно. Выходит, дело тут немножко в другом.
Давайте рассмотрим размер подписи. Где вообще на находится это значение? У нас есть транзакция:
Если транзакцию подписывает один участник, то размер одиночного значения подписи плюс-минус одинаковый для ECDSA и для подписи Шнорра. Но что если мы используем мультиподпись, т.е. транзакцию подписывает несколько человек?
В ECDSA мультиподпись представляет из себя просто набор нескольких подписей. Так что при увеличении количества участников, которые должны подписать транзакцию, увеличивается и размер доказательства владения монетами.
Приватность ECDSA
Фактически после подтверждения транзакции каждый участник сети может точно сказать, какие ключи использовались для ее подписания. Так как мультиподпись представляет из себя набор значения подписей, каждая подпись формируется при помощи одного секретного ключа, который относится к одному публичному ключу, то есть каждый публичный ключ связан с конкретным значением подписи. Получив при верификации транзакцию с мультиподписью, можно точно сказать, какие публичные ключи были использованы, и если вы знаете, какой конкретный субъект владеет каким конкретно публичным ключом, вы можете назвать всех участников подписания той или иной транзакции. Получается, приватность не обеспечивается в принципе.
Размер подписи ECDSA
А что же подпись Шнорра?
Подпись Шнорра позволяет агрегировать значение ключей и подписи. Что такое агрегация? Пусть у нас есть 4 субъекта и есть алгоритм мультиподписи, в случае ECDSA каждый из них создает свою подпись, и на выходе получаем 4 подписи. В случае Шнорра у нас есть все те же четыре субъекта они подписывают транзакцию, значения подписи складывается и мы получаем одно общее значение, которое по размеру равно обычному значению подписи.
В результате, если мы применим такую вот модель для транзакции Биткойна, то каждый выход сможет иметь только одно значение подписи, это гораздо уменьшает объем доказательства владения монетами.
Но при этом, когда мы подписываем, определяем значение подписи для каждого входа, мы также подписываем всю транзакцию целиком. Поэтому можно провести агрегацию этих значений, то есть в итоге одно значение подписи будет покрывать всю транзакцию.
Мы агрегируем значение подписей в одно значение, и её можно будет проверить, сагрегировав наши значения публичных ключей. Мы колоссально экономим на объеме транзакции, соответственно пропускная способность повышается, так как транзакция будет занимает меньше места, а блок остается тот же самый.
Касательно приватности в подписи Шнорра. Что такое общий открытый ключ? В общем виде это сумма публичных ключей, это наш агрегированный публичный ключ. Значение подписи тоже агрегируется таким же образом, и получаем одно общее значение подписи. Этот публичный ключ соответствует этой подписи. Когда валидатор проверяет такую транзакцию, в выходе транзакции у нас находится ровно один публичный ключ, во входе транзакции находится ровно одно значение подписи. То есть независимо от того, подписал транзакцию один человек или это была мультиподпись, валидатор не замети тэтой разницы. Это положительно влияет на приватность, ведь нельзя соотнести общий открытый ключ с конкретными субъектами.
В итоге
Схема Шнорра, это одна из наиболее эффективных и теоретически обоснованных схем аутентификации. Она оказалась не очень популярна из-за продолжительного патента, продолжающегося вплоть до 2008 года. Схема хоть претерпела некоторые изменения с момента создания, но её основные идеи остались не тронутыми и высоко ценятся в криптографии.
Как работает мультиподпись в Биткоине
Multisignature address
Multisignature address (multisig address, если сокращенно) — это такой Биткоин адрес, к которому привязано сразу несколько пар ECDSA ключей. Каждая пара состоит из личного и открытого ключей. Схемы комбинаций, согласно которым можно использовать эти ключи, могут быть различными. Более того, можно установить условия, при которых нужно будет предоставить несколько подписей, чтобы потратить монеты с адреса.
Bitcoin транзакция, которая использует мультиподпись
Более детально это можно отобразить схематически. Пока достаточно будет представить образно, что multisignature address формируется путем хеширования сразу нескольких сконкатенированных открытых ключей. Детально мы рассмотрим это чуть дальше. На схеме изображена транзакция, которая тратит с multisignature address.
Серым цветом обозначена область заголовка. Он содержит два поля. Синим цветом обозначены два входа, а зеленым — два выхода. В первом входе находятся заполненные поля: записано хеш-значение предыдущей транзакции, которая тратит данные монеты, номер выхода и т. д. Поле scriptSig содержит открытый ключ и подпись, что характерно для обычной транзакции.
Обратим внимание на второй вход транзакции. В поле scriptSig находится другая комбинация данных: перечислено два открытых ключа и две подписи. Они должны проверяться этими открытыми ключами соответственно. Это и есть тот вход транзакции, который тратит монеты с multisignature address. Именно так будет выглядеть доказательство владения монетами.
Варианты комбинаций ключей
Существуют различные комбинации ключей при использовании multisignature address. Наиболее используемыми вариантами являются 2-из-2, 2-из-3, а также 3-из-3. Максимально возможный вариант — 15-из-15.
Самая простая комбинация — 2-из-2. Она подразумевает, что есть multisignature address, к которому привязано две пары ключей, по сути, захешировано два открытых ключа подряд и получен некоторый адрес. Чтобы потратить монеты с этого адреса, нужно предоставить две подписи, которые будут верифицироваться двумя имеющимися открытыми ключами, конкатенация и хеширование которых в нужном порядке должны давать то же значение адреса. Обобщая, есть два заранее установленных ключа и нужны обязательно две подписи, которые будут проверяться этими ключами соответственно.
Схема использования multisignature address 2-из-3 подразумевает, что любые два ключа из трех заранее установленных должны быть задействованы для проверки двух подписей, представленных в качестве доказательства владения монетами. Иначе говоря, чтобы потратить монеты, нужно предоставить две подписи, которые будут проверены двумя открытыми ключами из предустановленных трех.
Комбинация 3-из-3, как вы уже поняли, требует три подписи, которые будут проверяться тремя заранее установленными ключами. Максимальной в отношении количества необходимых подписей и открытых ключей будет схема 15-из-15.
Давайте пройдемся по вариантам применения указанных комбинаций.
Представьте, что муж и жена захотели вести общий бюджет.
Они договариваются, что только при согласии каждого из них средства из бюджета будут тратиться на определенные нужды. С помощью Биткоина это можно реализовать достаточно просто. Они создают multisignature address по данной схеме, где один ключ контролирует жена, а второй — муж. Тогда все доходы семья будет получать на такие адреса, а тратиться средства смогут только по обоюдной договоренности.
Предугадывая ваш вопрос о сценарии, когда муж и жена не договорятся, представим, что жена считает необходимой покупку стиральной машины, потому что она устала стирать руками, а муж считает, что это не такая уж и тяжелая работа, а будет целесообразнее потратить все монеты на последнюю модель PlayStation и проводить таким образом досуг. Жена обижается на мужа и съедает бумажку со своим личным ключом, делая невозможной трату с этого адреса вообще.
Как избежать такой ситуации и защитить монеты от окончательной потери монет?
Есть возможность создать транзакцию, которая потратит все средства с нужного адреса, несмотря на то, что сумма заранее неизвестна. На вход подается не сумма, а ссылка на транзакцию, откуда эти монеты могут быть потрачены. Есть такое понятие, как hash type, — это способ покрытия подписью транзакций. Он позволяет создать подпись заранее, а некоторые данные транзакции, например вход, можно будет подставить позже. Таким образом, можно создать транзакцию, которая потратит монеты из еще не существующей транзакции, и применить ее позже, т. е. когда это будет нужно.
Более того, на эту транзакцию можно поставить ограничение LockTime. Оно позволяет не подтверждать транзакцию сразу, а отложить ее на некоторый срок. Итак, муж и жена сразу после создания multisignature address, еще до получения любых платежей, могут создать две LockTime транзакции, в которых все будущие монеты будут перенаправлены на обычные адреса мужа и жены, которые они контролируют самостоятельно. При этом транзакции будут отсроченными и могут быть подтверждены только, например через два месяца. Эти транзакции могут быть распечатаны на бумаге и храниться в сейфе у каждого по отдельности. Если возникнет ситуация, когда монеты находятся на балансе multisignature address, а ключи потеряны (один или оба), то монеты становятся замороженными. Но есть LockTime транзакция. Тот, кто опубликует такую транзакцию, сможет вывести эти средства на действующий внешний адрес. Монеты будут сохранены. Это был упрощенный пример, однако возможны и более сложные механизмы.
Допустим, есть группа людей, у которых есть общий бюджет.
Они создают multisignature address, в котором есть три ключа, но для подписи транзакции достаточно двух подписей. При согласии участников, которые составляют большинство группы, эти средства могут быть потрачены. Иначе говоря, любые два участника из трех могут потратить монеты. Им для этого достаточно распространить транзакцию в сеть.
Пример с Wallet сервисом
Есть более интересный способ применения комбинации 2-из-3 и он используется в так называемых сервисах кошельков. Сервис кошелька в данном контексте не стоит путать с обычным Биткоин кошельком, который пользователь контролирует самостоятельно. Сервис не предоставляет полноценное хранилище для монет и не владеет ими, а только оказывает услуги для удобной работы.
Если представить подобную ситуацию схематично, то один ключ принадлежит непосредственно сервису, второй генерируется только пользователем (и только ему известен), третий ключ генерируется и хранится тоже пользователем, но отдельно. После этого вычисляются открытые ключи, соответствующие этим личным, и составляется multisignature address. Туда поступают монеты и теперь условия траты ограничиваются.
Представим, что мы имеем дело с некоторым веб-сервисом и на его ресурс можно войти через браузер. Браузером подгружается код Биткоин кошелька, который по этому адресу получает список не потраченных монет, рассчитывает их баланс и готов потратить. Если пользователь хочет потратить монеты, то он прямо в браузере составляет транзакцию и подписывает ее своей (одной из необходимых) подписью.
Заметим, что личный ключ пользователь может получать либо из своего пароля, либо ключ может случайным образом генерироваться, шифроваться паролем пользователя и храниться у сервиса. Тогда пользователь посылает запрос сервису, получает контейнер с зашифрованным ключом, расшифровывает своим паролем и уже имеет доступ к своему личному ключу.
Когда пользователь подписывает транзакцию, она отправляется на сторону сервиса, чтобы он поставил вторую необходимую подпись и отправил транзакцию. Сервис уточняет факт необходимости подписания транзакции через второй канал аутентификации, то есть через установленный заранее другой канал, которым может быть звонок на мобильный телефон, SMS, сообщение на электронную почту и прочие способы альтернативной коммуникации (вплоть до личного визита, если того требует уровень безопасности). Когда сервис удостоверился, что запрос на подпись транзакции действительно инициирует зарегистрированный пользователь, он ставит недостающую подпись с помощью своего ключа. После этого транзакция становится валидной и может быть распространена в сеть для подтверждения.
Третий ключ используется в тех случаях, когда сервис отказывает в обслуживании. ПО генерирует этот ключ и предлагает его сохранить удобным для вас способом. Пользователь обычно хранит его в надежном месте. Если сервис отказывает в обслуживании, то пользователь может подписать транзакцию своими ключами (вторым и третьим). Если же второй ключ хранился на стороне сервиса, то защищенный контейнер с этим ключом будет заранее отправлен пользователю по альтернативному каналу передачи данных, например на электронную почту. Пользователь расшифровывает контейнер с ключом при помощи своего пароля.
Пользователь получает два необходимых личных ключа и вводит в специальное ПО, которое сервис предоставил заранее. Далее это ПО работает уже автономно на компьютере пользователя, без участия сервиса. Стоит отметить, что этим ПО следует пользоваться только в крайних случаях, когда сервис отказывает в обслуживании (т. е. его взломали, он поврежден или перестал существовать). Тогда пользователь подписывает транзакцию своими ключами и переводит монеты куда нужно.
Преимущества Wallet сервисов с подписью 2-из-3
На преимуществах таких Wallet сервисов остановимся подробнее. Это безопасный способ хранения, потому что сервис не владеет всем необходимым набором ключей — он владеет только одной частью, которой недостаточно, чтобы завладеть средствами. Причем доступа к средствам не имеет ни сам сервис, ни хакер, который его может взломать.
Удобство такого подхода состоит в том, что пользователю не обязательно иметь защищенный доступ к этому сервису. Он может иметь обычное устройство, которое может быть заражено вирусами или контролироваться мошенниками, а данные могут быть скомпрометированы или заменены. Но злоумышленнику недостаточно владеть только этим устройством, потому что из него можно добыть только одну из двух подписей.
Еще одно преимущество состоит в том, что если сервис отказывает в обслуживании, то пользователь не теряет доступ к своим монетам. Это были только некоторые из возможных схем использования multisignature адресов, которых достаточно для знакомства.
Меры предосторожности при работе с мультиподписью
И теперь стоит поговорить о мерах предосторожности, касательно мультиподписи. В случае 2-из-2 нужно создавать LockTime транзакции, которые смогут перевести заблокированные средства на определенный адрес. Это актуально, когда происходит потеря ключей.
Если вы используете multisignature address 2-из-3, то очень важно хранить ключи в надежном месте. В случае потери одного из трех ключей нужно сразу переводить средства и не дожидаться момента, когда будут потеряны 2 ключа из 3 необходимых.
Как работает Bitcoin Script (на примере)
Чтобы понять детальнее, как работает мультиподпись, нам нужно немного поговорить о том, как работает Bitcoin Script: как задаются правила траты монет, как им удовлетворять, какие существуют операции описания правил, что такое Bitcoin Script и как устроено его выполнение.
Рассмотрим пример простого случая траты монет, где есть обычный адрес, к которому привязан хеш одного открытого ключа, соответствующий скрипт, который задает условия траты, и скрипт, который удовлетворяет этим условиям.
На схеме слева мы видим стек данных, а справа сам скрипт. Первые две части строки script — signature и открытый ключ, — так называемый unlocking script, то есть скрипт, который указывается во входе транзакции, которая тратит монеты. После этого следует набор данных, который указывается в выходе транзакции — это называется locking script. Иначе говоря, тут представлена конкатенация двух скриптов: скрипт, отпирающий монеты, и скрипт, запирающий монеты. В случае, когда транзакция будет валидироваться уже узлом сети, эти два скрипта объединяются для выполнения проверки условий траты монет. Таким образом сначала идет unlocking script, а за ним следует locking script.
После этого идет последовательное выполнение полного набора операндов и данных. Точка выполнения идет последовательно по каждому операнду и каждому участку данных. Если точка выполнения попадает на участок данных, то они помещаются в стек. Как мы видим на схеме, курсор выполнения скрипта в верхней части указывает на данные подписи, которые после помещаются в стек.
Далее, курсор выполнения указывает на открытый ключ — он также помещается в стек.
Третьим шагом идет выполнение операции дубликации, что подразумевает копирование верхушки стека и помещение этих данных повторно в стек.
После этого выполняется хеширование с помощью хеш-функции Hash-160. Это значит, что верхушка стека хешируется сначала алгоритмом SHA-2 на длине 256 бит, а потом функцией RIPEMD-160 на длине 160 бит. Операция точно такая, как при хешировании открытого ключа и получении адреса. Фактически это она и есть.
Мы имеем стек, подпись, открытый ключ и хеш-значение открытого ключа. Курсор выполнения скрипта указывает на адрес, который был задан в выходе транзакции, то есть то хеш-значение открытого ключа, которое указывалось, когда монеты на него отправлялись. Эта часть данных тоже попадает в стек.
Следующей выполняется операция проверки на идентичность equal verify.
Два верхних элемента стека сравниваются. Если они побайтово полностью одинаковые, то эти данные удаляются из стека и считается, что проверка прошла успешно. После этого в стеке остаются signature и public key. Соответственно, операция check signature берет эти два операнда и проверяет подпись открытым ключом. Если подпись верна относительно транзакции, которая сейчас проходит проверку, потому что подпись покрывает часть транзакции, соответственно, нужно взять хеш-значение от определенных полей этой транзакции. Это задается отдельным байтом структуры hash type, то есть берется хеш-значение и подается на вход верификации подписи вместе с самой подписью и открытым ключом. Если проверка происходит корректно, то результат проверки — true, это значение кладется в стек. На этом выполнение скрипта заканчивается. Данные передаются в вызывающую функцию и там проверяются. Если в стеке находится значение true, значит верификация данного входа транзакции прошла корректно. Если все входы транзакции были корректно проверены, то и вся транзакция считается правильной.
Мы познакомились с тем как работает Bitcoin Script для проверки простых входов и выходов транзакции. Теперь мы поговорим о том, как организована и как работает multisignature при использовании Bitcoin Script.
Однажды было предложено BIP16, которое задает новый концепт в протоколе Биткоина — так называемый pay to script hash (P2SH). Это возможность задать правила траты монет не открытым скриптом, где вы подряд прописываете операнды и некоторые данные, которые потом выполняются рассмотренным нами образом, а в виде хеш-значения от нужного вам скрипта, то есть контрольной суммы от этих операндов. Это позволило в выходе транзакции задавать большие и сложные условия траты монет, но при этом сам выход оставался коротким.
Чтобы потратить эти монеты при таких условиях, на входе транзакции нужно указать данные, удовлетворяющие этому скрипту, и исходный скрипт целиком, чтобы доказать, что вы знаете, какие условия были заданы при отправке монет, чтобы хеш-значение исходного скрипта совпало с адресов на который были отправлены монеты. Иначе говоря, доказать, что вы знаете условия, и удовлетворить этим условиям.
Это предложение по улучшению Биткоина было принято 3 января 2012 года. Фактически в день рождения Биткоина. Сейчас оно активно применяется для реализации multisignature address.
Как работает P2SH
Давайте рассмотрим на примере, как это работает. Для построения транзакции нам понадобится иметь представление о таких понятиях, как Redeem Script, Locking Script и Unlocking Script.
Redeem Script содержит в себе открытые ключи, к которым будет привязан multisignature address. В данном случае мы рассматриваем комбинацию ключей “2-из-5”. Сначала идет значение 2, то есть мы указываем, что необходимо будет 2 подписи, которые будут проверяться соответствующими открытыми ключами. После этого следуют открытые ключи, в нашем случае их 5. Далее мы указываем значение 5, так как мы указали 5 открытых ключей, а когда данные будут считываться в обратном порядке это значение понадобиться, чтобы понять, сколько ключей нужно прочесть. После этого указывается операция проверки мультиподписи (operation check multisignature).
Locking Script — скрипт, который указывается в выходе транзакции, которая платит на multisignature address. Здесь будет производиться операция получения хеш-значения, с которой мы подробно уже знакомились. Далее следует хеш-значение Redeem Script, которое занимает 20 байт. После этого проводится операция по проверке соответствия данных фактическому хеш-значению.
Unlocking Script является конкатенацией скриптов на входе транзакции со скриптами в выходе транзакции, которая платила на этот адрес. Есть две подписи, необходимые для траты монет, и полный Redeem Script, который позже будет захеширован и проверен на предмет соответствия адресу, на который были отправлены монеты. После этого скрипт будет выполняться целиком, в том числе для проверки мультиподписи.
Важно, что есть ограничения на максимальный размер для каждого из перечисленных скриптов и это 520 байт. Это число было рассчитано, исходя из того, что в Unlocking Script может поместиться максимум 15 подписей и 15 соответствующих открытых ключей, а также несколько операций для проверки этих значений. Именно так было получено некоторое число, которое при округлении дало 520 байт. Следует сказать, что это число получено с расчетом на то, что multisignature address типа “15 из 15” является достаточно разумным пределом для практического применения. Redeem Script при использовании большого количества подписей становится очень большим по объему. Тот пользователь, который использует multisignature address или другие P2SH адреса, при трате монет с них имеет очень большие по объему транзакции. Это значит, что для подтверждения своих транзакций ему придется платить большие комиссии.
Преимущества P2SH
Отдельно рассмотрим преимущества P2SH. Первое из них состоит в том, что такие адреса могут быть закодированы в привычный вид с использованием Base58, в котором их длина составляет 34 символа. В соответствии с BIP13, которое определяет правила установки версионного байта для Биткоин адресов, кодированных Base58Check, начинаться адрес будет с тройки, то есть туда вставляется определенный версионный байт.
На примере вы можете видеть P2SH адрес.
Это может быть не обязательно multisignature address. Redeem Script может описывать не только multisignature address, но и другие сложные правила траты монет.
Добавим, что это не единственный способ организации мультиподписи в Биткоине. Можно и не использовать P2SH, а в выходе, который будет платить на multisignature address, не хеш-значение от скрипта, а сам скрипт, то есть перечислять прямо в выходе все открытые ключи и ставить операцию проверки multisignature. Однако при оправке монет на такой адрес вы сразу разглашаете открытые ключи, так как они будут находиться в открытом доступе и в этот момент на них будут храниться монеты.
И еще одним недостатком является то, что отправитель монет на multisignature address имеет транзакцию большого объема, за которую придется платить большую комиссию. Вряд ли отправитель захочет переплачивать за то, что получатель хочет использовать multisignature. P2SH дает возможность переложить комиссионные затраты на получателя. Если получатель хочет принимать монеты на multisignature address, то он сам будет оплачивать большие транзакции, что является более справедливым подходом.
Добавим, что P2SH позволяет реализовать разные комбинации такого multisignature (2-из-2, 2-из-3 и другие).
Схематично рассмотрим отправку на multisignature address.
Представим, что Алиса хочет заплатить Бобу, который использует только multisignature addresses. Для этого Боб локально на своем компьютере (кстати, вместо Боба может быть какая-то организация) генерирует несколько личных ключей, получает из них соответствующие открытые ключи, которые конкатенируются определенным образом. Чаще всего открытые ключи представлены сначала закодированными Base58Check, а потом они сортируются в алфавитном порядке, после чего конкатенируются.
Такой подход оправдывает себя, когда требуется перерасчет открытых ключей из личных. Их нужно конкатенировать точно в таком же порядке, потому что следующим шагом будет создание Redeem Script и его хеширование. Если точно такие же ключи попадут в Redeem Script, но в другом порядке, мы получим другое хеш-значение и другой адрес. Это повлечет за собой определенные недоразумения. Поэтому перед конкатенацией открытые ключи нужно отсортировать согласно некоторому правилу. И чаще всего используют сортировку по алфавиту в системе счисления Base58.
Итак, Боб посчитал хеш-значение от Redeem Script. Он может его представить в виде 20 байт и отправить Алисе, сказав, что это multisignature address с использованием P2SH. Однако Боб может закодировать его с версионным байтом, как обычный адрес, и просто отправить Алисе. Алиса поймет по версионному байту, что это multisignature address, составит транзакцию и соответствующим образом заполнит ее выход, чтобы Боб получил свои монеты. Далее она распространяет транзакцию в сеть. Они дожидаются подтверждения и Боб принимает платеж от Алисы. Замен Боб, например, оказывает услугу или передает товар.
Наступает момент, когда Боб хочет потратить эти монеты. Следует понимать, что полный Redeem Script не был разглашен публично, пока монеты находились на его multisignature адресе. И даже Алиса не видела, какие именно открытые ключи использовал Боб, сколько их там было и т. д. Она вообще не знает, по каким правилам этот P2SH адрес составлен, multisignature address это или нет и т. д. Соответственно, атаки на электронно-цифровую подпись (на эллиптическую кривую) еще невозможны.
Допустим, Боб хочет отправить платеж Еве.
Она генерирует новый адрес и дает его Бобу. Он создает заготовку транзакции, во входе которой он указывает ту транзакцию, в которой он получил монеты от Алисы, а на выходе — адрес Евы. Теперь он должен предоставить доказательства владения монетами, которые он тратит. Для этого он берет два своих личных ключа (выше мы упоминали, что его multisignature address предполагает вариант “2-из-5”), из которых вычисляет две подписи к данной транзакции. Далее, он берет полный Redeem Script и добавляет его во вход транзакции.
Обратите внимание, что данный Redeem Script должен храниться у Боба на компьютере целиком либо он должен запомнить порядок, в котором он использовал открытые ключи для составления этого скрипта. Если же он применял определенные правила сортировки, то он должен запомнить их. Он также должен помнить, что к определенным личным ключам привязан multisignature address. Без этих знаний Боб не знал бы, какими из его личных ключей оперировать и в каком порядке их следует хешировать для получения нужного адреса.
Итак, у него есть две подписи и полный Redeem Script. Транзакция считается верной и Боб ее распространяет в сеть, а после дожидается подтверждения. Это основное из того, что касается траты с multisignature address.
Вопросы
Сейчас мы переходим к вашим вопросам.
— Можно ли один и тот же кошелек запустить одновременно на трех разных компьютерах и начать синхронизацию?
Скорее всего, речь идет о каком-то узле сети: либо SPV узле, либо полном узле. Было использовано несколько разных компьютеров и один и тот же кошелек. А под кошельком подразумеваются личные ключи. Есть несколько полных узлов, которые реализуют функциональность кошельков. На этих узлах мы вставляем одни и те же личные ключи и начинаем синхронизацию. Скорее всего, при полной синхронизации с сетью мы увидим на каждом кошельке, который использует свой узел, один и тот же баланс. Если же вы увидите изменения на одном узле, то после синхронизации с сетью вы увидите точно такие же изменения на всех остальных узлах. Транзакция не остается в секрете, она распространяется по всем узлам, которые ее верифицируют и отображают соответствующие изменения, если это касается их адресов. Фактически да, можно использовать одни ключи на нескольких узлах, но все транзакции тоже будут синхронизироваться автоматически. Биткоины точно от этого не удвоятся и, более того, не утроятся.
— Как P2SH работает с Segregated Witness?
Segregated Witness — это такая структура транзакций, где доказательства владения монетами выносятся в отдельную структуру, они не попадают в блокчейн, но при валидации транзакций они распространяются вместе, то есть все валидаторы проверяют правильность транзакций по отдельной структуре с доказательством. После подтверждения транзакции доказательства не сохраняются, так как смысла это не имеет. Есть также преимущества в построении таких цепочек транзакций, в которых определенные монеты без фактического подтверждения в текущей транзакции уже тратятся в следующей, построенной на ее основе, но они не распространяются в сеть. Таким образом, формируются цепочки транзакций, которые не разглашают доказательства владения монетами. Это облегчает передачу данных и добавляет приватность. Для Segregated Witness был использован другой тип адресов, он содержит немного другие операнды. Есть возможность отправлять монеты, которые хранятся на обычных адресах, в том числе P2SH адресах, на адреса Witness P2SH.
— Адреса с тройки начинаются в Lighting Network?
По BIP13 определены правила, по которым выбирается версионный байт для Биткоин адресов в test-нете, других валютах и т. п. Да, Lighting Network использует multisignature адреса, которые тоже применяют P2SH способ задания условий.
— Почему нельзя персонализировать кошелек, то есть привязать его к конкретной личности?
Биткоин как протокол платежной системы не требует идентификации личности кошелька, потому что он работает по законам математики, а математика не позволяет описать человека, как личность. Более того, это не является необходимым условием для проверки транзакций. Здесь достаточно электронно-цифровой подписи. Кто может генерировать такие подписи, тот и является их владельцем — к протоколу Биткоина это не относится. Следовательно, подписью может владеть человек, группа из нескольких человек, робот и т. д.
Что касается персонализации, то если вы устанавливаете связь конкретного адреса с конкретной личностью, то вы нарушаете приватность и можете деанонимизировать часть сети с определенной долей вероятности. В общем случае база данных открыта, но никаких данных о личностях в ней нет.
— Если валюта не майнится, а таких валют 70-80%, можно ли им доверять?
Хорошо написано, что это валюта, а не криптовалюта, потому что криптовалюта работает по таким же принципам, как и Биткоин, то есть все процессы максимально децентрализованы: эмиссия, верификация транзакций, хранение данных, принятие изменений и т. д. Но есть такие валюты, мы будем называть их цифровыми валютами, у которых не все из перечисленных процессов децентрализованы. Одним из вариантов может быть централизованная эмиссия, то есть нет такого понятия как добыча, майнинг, то есть нет решения сложной задачи. По такому принципу работает Ripple, Stellar, цифровая валюта NXT, Cardano. Там были применены другие принципы распространения монет среди пользователей, например, через ICO, доказательство личности и т. д. Из-за того, что не все процессы могут быть децентрализованы и независимы, нельзя любую цифровую валюту назвать криптовалютой. Кроме того, вопрос о доверии к той или иной валюте носит личностный характер. Вы сами принимаете решение о размере этого доверия. Нужно учитывать цели, для которых валюта используется, а также ее риски и ограничения.