В этой статье мы рассмотрим, как работает мультиподпись в протоколе Биткойн.
Обратите внимание, что другие криптовалюты и цифровые валюты могут реализовывать эти механизмы по-разному в зависимости от модели транзакции.
Дадим определение мультиподписи, схематично разберем ее структуру на примере транзакции, рассмотрим варианты ее применения и меры предосторожности при работе с ней.
Мы постараемся доходчиво объяснить тему предлагаемых улучшений P2SH, а также с помощью схемы проанализировать механизм отправки платежа на адрес с мультиподписью.
Мы полагаем, что представленный материал будет интересен читателям, чья деятельность или сферы интересов связаны с цифровыми валютами.
Мультиподписной адрес
Адрес с мультиподписью (сокращенно мультиподписный адрес) — это биткойн-адрес, к которому привязано сразу несколько пар ключей ECDSA. Каждая пара состоит из закрытого и открытого ключей.Схемы комбинирования, по которым могут использоваться эти ключи, могут быть разными.
Более того, вы можете установить условия, при которых необходимо будет предоставить несколько подписей, чтобы потратить монеты с адреса.
Биткойн-транзакция, использующая мультиподпись
Более подробно это можно показать схематически.Пока достаточно будет образно представить, что мультиподписной адрес формируется путем хеширования сразу нескольких сцепленных открытых ключей.
Мы рассмотрим это подробно чуть дальше.
На диаграмме показана транзакция, которая проводится с адресом с мультиподписью.
Область заголовка выделена серым цветом.
Он содержит два поля.
Синий указывает на два входа, а зеленый — на два выхода.
Первый вход содержит заполненные поля: записывается хеш-значение предыдущей транзакции, на которую были потрачены данные монеты, номер выхода и т.д. Поле scriptSig содержит открытый ключ и подпись, что типично для обычной транзакции.
Обратим внимание на второй вход транзакции.
Поле scriptSig содержит другую комбинацию данных: указаны два открытых ключа и две подписи.
Соответственно, они должны быть проверены этими открытыми ключами.
Это ввод транзакции, на который тратятся монеты с адресом с мультиподписью.
Вот как будет выглядеть доказательство владения монетой.
Варианты комбинаций клавиш
При использовании адреса с мультиподписью существуют разные комбинации клавиш.Наиболее часто используемые варианты — 2 из 2, 2 из 3 и 3 из 3. Максимально возможный вариант — 15-из-15. Самая простая комбинация — 2-из-2. Это подразумевает наличие мультиподписного адреса, к которому привязаны две пары ключей; фактически два открытых ключа хешируются подряд и получается определенный адрес.
Чтобы потратить монеты с этого адреса, вам необходимо предоставить две подписи, которые будут проверены двумя существующими открытыми ключами, конкатенация и хеширование которых в необходимом порядке должно дать одинаковое значение адреса.
Подводя итог, нужно сказать, что есть два заранее установленных ключа и две подписи, которые будут проверены этими ключами соответственно.
Конструкция адреса с мультиподписью «2 из 3» означает, что любые два из трех предустановленных ключей должны использоваться для проверки двух подписей, представленных в качестве доказательства владения монетами.
Другими словами, чтобы потратить монеты, вам необходимо предоставить две подписи, которые будут проверены двумя из трех предустановленных открытых ключей.
Комбинация 3 из 3, как вы уже поняли, требует трех подписей, которые будут проверены тремя заранее установленными ключами.
Максимум с точки зрения требуемого количества подписей и открытых ключей — это схема 15 из 15. Давайте рассмотрим варианты использования этих комбинаций.
2 из 2
Представьте себе, что муж и жена хотели вести совместный бюджет.
Они договорились, что только с согласия каждого из них средства бюджета будут расходоваться на определенные нужды.
С помощью Биткойна этого можно добиться довольно просто.
Мультиподписной адрес создают по такой схеме, где одним ключом управляет жена, а вторым – муж.
Тогда на такие адреса семья будет получать все доходы, а тратить средства можно будет только по взаимному согласию.
Предвосхищая ваш вопрос о сценарии, когда муж и жена не согласны, представьте, что жена считает необходимым купить стиральную машину, потому что ей надоело стирать вручную, а муж считает, что это не такая уж и тяжелая работа, и целесообразнее было бы потратить все монеты на последнюю модель PlayStation и провести таким образом свой досуг.
Жена обижается на мужа и съедает бумажку со своим личным ключом, в результате чего тратить деньги с этого адреса становится вообще невозможно.
Как избежать такой ситуации и защитить монеты от окончательной потери монет? Есть возможность создать транзакцию, которая потратит все средства с нужного адреса, несмотря на то, что сумма заранее неизвестна.
На входе не сумма, а ссылка на транзакцию, откуда эти монеты можно потратить.
Есть такая вещь, как тип хеша , — это способ покрыть транзакции подписью.
Это позволяет заранее создать подпись, а некоторые данные транзакции, например входные, можно подставить позже.
Таким образом, вы можете создать транзакцию, которая будет тратить монеты из транзакции, которая еще не существует, и применить ее позже, то есть, когда это необходимо.
Более того, вы можете поставить ограничение LockTime на эту транзакцию.
Он позволяет не подтверждать транзакцию сразу, а отложить ее на определенный период времени.
Так, муж и жена сразу после создания мультиподписного адреса, еще до получения каких-либо платежей, могут создать две транзакции LockTime, в которых все будущие монеты будут перенаправляться на обычные адреса мужа и жены, которые они контролируют независимо.
В этом случае транзакции будут задерживаться и их можно будет подтвердить только, например, через два месяца.
Эти транзакции можно распечатать на бумаге и хранить в индивидуальном сейфе.
Если возникает ситуация, когда монеты находятся на балансе мультиподписного адреса, а ключи утеряны (один или оба), то монеты замораживаются.
Но есть транзакция LockTime. Любой, кто опубликует такую транзакцию, сможет вывести эти средства на действующий внешний адрес.
Монеты будут сохранены.
Это был упрощенный пример, но возможны и более сложные механизмы.
2 из 3
Допустим, есть группа людей, имеющих общий бюджет.
Они создают адрес с мультиподписью, который имеет три ключа, но для подписания транзакции достаточно двух подписей.
С согласия участников, составляющих большую часть группы, эти средства могут быть потрачены.
Другими словами, тратить монеты могут любые двое из трех участников.
Для этого им просто нужно распространить транзакцию по сети.
Пример с сервисом Кошелька
Есть более интересный способ использования комбинации 2 из 3, который используется в так называемых сервисах кошельков.Сервис кошелька в этом контексте не следует путать с обычным биткойн-кошельком, которым пользователь управляет самостоятельно.
Сервис не обеспечивает полноценное хранение монет и не владеет ими, а лишь предоставляет услуги для удобной работы.
Если представить подобную ситуацию схематично, то один ключ принадлежит непосредственно сервису, второй генерируется только пользователем (и известен только ему), третий ключ также генерируется и хранится пользователем, но отдельно.
После этого вычисляются открытые ключи, соответствующие этим закрытым ключам, и составляется адрес мультиподписи.
Монеты поступают туда и теперь условия для траты ограничены.
Давайте представим, что мы имеем дело с некоторым веб-сервисом и вы можете получить доступ к его ресурсу через браузер.
Браузер загружает код биткойн-кошелька, который по этому адресу получает список неизрасходованных монет, рассчитывает их баланс и готов потратить.
Если пользователь хочет потратить монеты, то он создает транзакцию прямо в браузере и подписывает ее своей (одной из необходимых) подписью.
Обратите внимание, что пользователь может получить закрытый ключ либо из своего пароля, либо ключ может быть сгенерирован случайным образом, зашифрован паролем пользователя и сохранен службой.
Далее пользователь отправляет запрос в сервис, получает контейнер с зашифрованным ключом, расшифровывает его своим паролем и уже имеет доступ к своему закрытому ключу.
Когда пользователь подписывает транзакцию, она отправляется на сторону службы, чтобы она поставила вторую необходимую подпись и отправила транзакцию.
В сервисе уточняется, что подписывать транзакцию необходимо через второй канал аутентификации, то есть через другой заранее установленный канал, которым может быть звонок на мобильный телефон, SMS, сообщение электронной почты и другие способы альтернативной связи.
(вплоть до личного визита, если того требует уровень безопасности) .
Когда служба проверит, что запрос на подпись транзакции действительно инициирован зарегистрированным пользователем, она добавляет недостающую подпись, используя свой ключ.
После этого транзакция становится действительной и может быть распространена в сеть для подтверждения.
Третий ключ используется в случаях, когда сервис отказывает в обслуживании.
Программа генерирует этот ключ и предлагает сохранить его удобным для вас способом.
Пользователь обычно хранит его в надежном месте.
Если служба отказывает в обслуживании, пользователь может подписать транзакцию своими (вторым и третьим) ключами.
Если второй ключ хранился на стороне сервиса, то защищенный контейнер с этим ключом будет заранее отправлен пользователю по альтернативному каналу передачи данных, например, по электронной почте.
Пользователь расшифровывает контейнер с ключом, используя свой пароль.
Пользователь получает два необходимых персональных ключа и вводит их в специальное программное обеспечение, которое сервис предоставил заранее.
Далее это программное обеспечение работает автономно на компьютере пользователя, без участия сервиса.
Стоит отметить, что это программное обеспечение следует использовать только в крайних случаях, когда в службе произошел сбой (т. е.
она была взломана, повреждена или прекратила свое существование).
Затем пользователь подписывает транзакцию своими ключами и передает монеты куда необходимо.
Преимущества сервисов Кошелька с подписью 2 из 3
Давайте подробнее рассмотрим преимущества таких сервисов кошелька.Это безопасный метод хранения, поскольку сервис не владеет всем набором ключей — ему принадлежит только одна часть, которой недостаточно для того, чтобы завладеть средствами.
При этом ни сам сервис, ни хакер, который может его взломать, не имеют доступа к средствам.
Удобство такого подхода в том, что пользователю не обязательно иметь защищенный доступ к этому сервису.
У него может быть обычное устройство, которое может быть заражено вирусами или контролироваться мошенниками, а данные могут быть скомпрометированы или подменены.
Но злоумышленнику недостаточно владеть только этим устройством, поскольку с него можно получить только одну из двух подписей.
Еще одним преимуществом является то, что если сервис откажет в обслуживании, пользователь не потеряет доступ к своим монетам.
Это были лишь некоторые из возможных схем использования мультиподписных адресов, с которыми достаточно ознакомиться.
Меры предосторожности при работе с мультиподписью
А теперь стоит поговорить о мерах предосторожности относительно мультиподписи.В случае 2-из-2 вам необходимо создать транзакции LockTime, которые смогут перевести заблокированные средства на определенный адрес.
Это актуально, когда ключи утеряны.
Если вы используете адрес с мультиподписью 2 из 3, очень важно хранить ключи в надежном месте.
Если вы потеряете один из трех ключей, вам необходимо перевести средства сразу, а не ждать, пока будут потеряны 2 из 3 необходимых ключей.
Как работает биткойн-скрипт (с примером)
Чтобы подробнее понять, как работает мультиподпись, нужно немного поговорить о том, как работает Bitcoin Script: как задаются правила траты монет, как их удовлетворять, какие операции существуют для описания правил, что такое Bitcoin Script и как он работает. исполнительные работы.Рассмотрим пример простого случая траты монет, где есть обычный адрес, к которому привязан хэш одного публичного ключа, соответствующий скрипт, задающий условия траты, и скрипт, удовлетворяющий этим условиям.
На схеме слева мы видим стек данных, а справа сам скрипт. Первые две части строки сценария — это подпись и открытый ключ, так называемый сценарий разблокировки, то есть сценарий, который указывается на входе транзакции, тратящей монеты.
За этим следует набор данных, который указывается в выводе транзакции — это называется скриптом блокировки.
Другими словами, вот конкатенация двух скриптов: скрипта, который разблокирует монеты, и скрипта, который блокирует монеты.
В случае, когда транзакция будет подтверждена узлом сети, эти два скрипта объединяются для проверки условий траты монет. Таким образом, сначала идет сценарий разблокировки, а затем сценарий блокировки.
После этого последовательно выполняется полный набор операндов и данных.
Точка выполнения последовательно проходит через каждый операнд и каждый фрагмент данных.
Если точка выполнения приходится на фрагмент данных, то он помещается в стек.
Как мы видим на диаграмме, курсор выполнения скрипта вверху указывает на данные подписи, которые затем помещаются в стек.
Далее курсор выполнения указывает на открытый ключ — он также помещается в стек.
Третий шаг — выполнить операцию дублирования, которая включает в себя копирование вершины стека и помещение этих данных обратно в стек.
После этого производится хеширование с помощью хэш-функции Hash-160. Это означает, что вершина стека хешируется сначала алгоритмом SHA-2 длиной 256 бит, а затем функцией RIPEMD-160 длиной 160 бит. Операция точно такая же, как и при хешировании открытого ключа и получении адреса.
На самом деле, это она и есть.
У нас есть стек, подпись, открытый ключ и хеш-значение открытого ключа.
Курсор выполнения скрипта указывает на адрес, который был указан в выводе транзакции, то есть на хэш-значение открытого ключа, который был указан при отправке на него монет. Эта часть данных также попадает в стек.
Следующая операция проверки личности — это проверка равенства.
Сравниваются два верхних элемента стека.
Если они полностью идентичны побайтно, то эти данные удаляются из стека и проверка считается успешной.
После этого подпись и открытый ключ остаются в стеке.
Соответственно, операция проверки подписи принимает эти два операнда и проверяет подпись с помощью открытого ключа.
Если подпись верна в отношении транзакции, которая в данный момент проверяется, поскольку подпись покрывает часть транзакции, то следует взять хеш-значение из определенных полей этой транзакции.
Это задается отдельным байтом структуры типа хэша, то есть значение хэша берется и подается на вход проверки подписи вместе с самой подписью и открытым ключом.
Если проверка происходит правильно, то результат проверки — true, это значение помещается в стек.
На этом выполнение скрипта завершено.
Данные передаются вызывающей функции и проверяются там.
Если значение true находится в стеке, то проверка ввода этой транзакции завершилась корректно.
Если все входные данные транзакции были правильно проверены, то вся транзакция считается правильной.
Мы узнали, как биткойн-скрипт работает для проверки простых входов и выходов транзакций.
Теперь мы поговорим о том, как устроена и работает мультиподпись при использовании Bitcoin Script.
П2Ш
Однажды был предложен BIP16, определяющий новую концепцию в протоколе Биткойн — так называемый хэш pay to script (P2SH).Это возможность задать правила траты монет не в открытом скрипте, где вы записываете подряд операнды и какие-то данные, которые потом исполняются так, как мы обсуждали, а в виде хеш-значения из скрипта, который вы нужна, то есть контрольная сумма от этих операндов.
Это позволяло на выходе транзакции указывать большие и сложные условия траты монет, но при этом сам вывод оставался коротким.
Чтобы потратить эти монеты на этих условиях, вам необходимо указать на входе транзакции данные, удовлетворяющие этому скрипту, и весь исходный скрипт, чтобы доказать, что вы знаете, какие условия были установлены при отправке монет, чтобы хеш-значение источника скрипт сопоставляет адреса, на которые были отправлены монеты.
Другими словами, докажите, что вы знаете условия и удовлетворяете этим условиям.
Это предложение по улучшению Биткойна было принято 3 января 2012 года.
Фактически, в день рождения Биткойна.
Сейчас он активно используется для реализации мультиподписного адреса.
Как работает P2SH
Давайте посмотрим на примере, как это работает. Чтобы построить транзакцию, нам необходимо иметь представление о таких понятиях, как сценарий погашения, сценарий блокировки и сценарий разблокировки.Redeem Script содержит открытые ключи, к которым будет прикреплен адрес мультиподписи.
В данном случае мы рассматриваем комбинацию клавиш 2 из 5. Сначала идет значение 2, то есть мы указываем, что понадобятся 2 подписи, которые будут проверены соответствующими открытыми ключами.
Далее следуют открытые ключи, в нашем случае их 5. Далее указываем значение 5, так как мы указали 5 открытых ключей, и при чтении данных в обратном порядке это значение понадобится, чтобы понять, сколько ключей нужно прочитать.
После этого указывается операция проверки мультиподписи.
Скрипт блокировки — это сценарий, который указывается в выходных данных транзакции, осуществляющей оплату по адресу с мультиподписью.
Здесь будет выполнена операция получения хеш-значения, с которой мы уже подробно ознакомились.
Далее идет хэш-значение Redeem Script, которое занимает 20 байт. После этого выполняется операция по проверке соответствия данных фактическому значению хеш-функции.
Скрипт разблокировки — это объединение скриптов на входе транзакции со скриптами на выходе транзакции, которая заплатила по этому адресу.
Для траты монет необходимы две подписи и полный сценарий погашения, который позже будет хеширован и сверен с адресом, на который были отправлены монеты.
После этого скрипт будет выполнен полностью, включая проверку мультиподписи.
Важно, что существуют ограничения на максимальный размер каждого из перечисленных скриптов и это 520 байт. Это число было рассчитано исходя из того, что сценарий разблокировки может вместить максимум 15 подписей и 15 соответствующих им открытых ключей, а также несколько операций по проверке этих значений.
Так было получено определенное число, которое при округлении дало 520 байт. Следует сказать, что это число получено с расчетом на то, что мультиподписной адрес типа «15 из 15» является вполне разумным пределом для практического использования.
Redeem Script становится очень большим по объёму при использовании большого количества подписей.
Пользователь, который использует адрес с мультиподписью или другие адреса P2SH, имеет очень большие транзакции при трате монет с них.
Это означает, что ему придется платить большие комиссии за подтверждение своих транзакций.
Преимущества P2SH
Отдельно рассмотрим преимущества П2Ш.Во-первых, такие адреса можно закодировать в обычном виде с помощью Base58, в котором их длина составляет 34 символа.
В соответствии с BIP13, определяющим правила установки байта версии для биткойн-адресов, закодированных с помощью Base58Check, адрес будет начинаться с тройки, то есть туда вставляется определенный байт версии.
В примере вы можете увидеть адрес P2SH. 3P14159f73E4gFr7JterCCQh9QjiTjiZrG Это не обязательно может быть адрес с мультиподписью.
Redeem Script может описывать не только мультиподписной адрес, но и другие сложные правила траты монет. Добавим, что это не единственный способ организовать мультиподпись в Биткойне.
Не обязательно использовать P2SH, но в выводе, который будет платить по адресу мультиподписи, не хэш-значение из скрипта, а сам скрипт, то есть перечислять все публичные ключи непосредственно в выводе и ставить проверку мультиподписи операция.
Однако отправляя монеты на такой адрес, вы сразу же раскрываете публичные ключи, так как они будут в открытом доступе и в этот момент на них будут храниться монеты.
И еще один недостаток – отправитель монет на мультиподписной адрес имеет большой объем транзакции, за которую ему придется платить большую комиссию.
Вряд ли отправитель захочет переплачивать за то, что получатель хочет использовать мультиподпись.
P2SH позволяет переложить комиссионные расходы на получателя.
Если получатель хочет принимать монеты по адресу с мультиподписью, то за крупные транзакции он будет платить сам, что является более справедливым подходом.
Добавим, что P2SH позволяет реализовать разные комбинации такой мультиподписи (2-из-2, 2-из-3 и другие).
Давайте схематически рассмотрим отправку на мультиподписной адрес.
Давайте представим, что Алиса хочет заплатить Бобу, который использует только адреса с мультиподписью.
Для этого Боб локально на своем компьютере (кстати, вместо Боба может быть какая-то организация) генерирует несколько приватных ключей, получает от них соответствующие публичные ключи, которые определённым образом конкатенируются.
Чаще всего открытые ключи сначала представляются в кодировке Base58Check, затем они сортируются в алфавитном порядке и затем объединяются.
Такой подход оправдывает себя, когда требуется пересчет открытых ключей из закрытых.
Их необходимо объединить в одном и том же порядке, поскольку следующим шагом будет создание сценария погашения и его хеширование.
Если в Redeem Script попадут точно такие же ключи, но в другом порядке, мы получим другое значение хеш-функции и другой адрес.
Это приведет к определенным недоразумениям.
Поэтому перед конкатенацией публичные ключи необходимо отсортировать по какому-то правилу.
И чаще всего используют сортировку по алфавиту в системе счисления Base58. Итак, Боб вычислил хеш-значение с помощью Redeem Script. Он может представить его в виде 20 байт и отправить Алисе, сказав, что это мультиподписной адрес с использованием P2SH. Однако Боб может закодировать его с помощью версионного байта, например обычного адреса, и просто отправить его Алисе.
Алиса по байту версии поймет, что это мультиподписной адрес, составит транзакцию и соответствующим образом заполнит ее вывод, чтобы Боб получил свои монеты.
Затем он распространяет транзакцию в сеть.
Они ждут подтверждения, и Боб принимает оплату от Алисы.
Например, Боб-заменитель предоставляет услугу или передает продукт. Наступает момент, когда Боб хочет потратить эти монеты.
Следует понимать, что полный сценарий погашения не был публично раскрыт, пока монеты находились на его адресе с мультиподписью.
И даже Алиса не видела, какие именно открытые ключи использовал Боб, сколько их было и т. д. Она вообще не знает, по каким правилам был составлен этот P2SH-адрес, был ли это мультиподписной адрес или нет и т. д. Соответственно, атаки на электронно-цифровую подпись (по эллиптической кривой) пока невозможны.
Допустим, Боб хочет отправить платеж Еве.
Она генерирует новый адрес и передает его Бобу.
Он создает шаблон транзакции, на входе которого находится транзакция, в которой он получил монеты от Алисы, а на выходе — адрес Евы.
Теперь он должен предоставить доказательства права собственности на монеты, которые он тратит. Для этого он берет свои два приватных ключа (выше мы упоминали, что его мультиподписной адрес предполагает вариант «2 из 5»), из которых он вычисляет две подписи для этой транзакции.
Затем он берет полный сценарий погашения и добавляет его во входные данные транзакции.
Обратите внимание, что этот сценарий погашения должен храниться на компьютере Боба целиком, иначе он должен запомнить порядок, в котором он использовал открытые ключи для составления этого сценария.
Если он применил определенные правила сортировки, то он должен их запомнить.
Он также должен помнить, что к некоторым закрытым ключам прикреплен адрес с мультиподписью.
Без этих знаний Боб не знал бы, какой из своих закрытых ключей использовать и в каком порядке их следует хешировать, чтобы получить желаемый адрес.
Итак, у него есть две подписи и полный сценарий погашения.
Транзакция считается корректной, и Боб распространяет ее по сети, а затем ждет подтверждения.
Это главное в тратах с мультиподписным адресом.
Вопросы
Теперь мы переходим к вашим вопросам.— Можно ли одновременно запустить один и тот же кошелек на трех разных компьютерах и начать синхронизацию? Скорее всего, речь идет о каком-то узле сети: либо узле SPV, либо полном узле.
Использовалось несколько разных компьютеров и один и тот же кошелек.
Под кошельком мы подразумеваем приватные ключи.
Существует несколько полных узлов, реализующих функциональность кошелька.
На этих узлах вставляем одинаковые приватные ключи и начинаем синхронизацию.
Скорее всего, при полной синхронизации с сетью мы увидим одинаковый баланс на каждом кошельке, использующем свою ноду.
Если вы видите изменения на одном узле, то после синхронизации с сетью вы увидите точно такие же изменения на всех остальных узлах.
Транзакция не остается секретной, она распространяется по всем узлам, которые ее проверяют и отображают соответствующие изменения, если это касается их адресов.
На самом деле да, вы можете использовать одни и те же ключи на нескольких узлах, но все транзакции также будут синхронизироваться автоматически.
Биткоины точно не удвоятся и, тем более, не утроятся.
— Как P2SH работает с «Segregated Witness»? Segregated Witness — это структура транзакций, в которой доказательства владения монетами размещаются в отдельной структуре; они не попадают в блокчейн, а при валидации транзакций распределяются вместе, то есть все валидаторы проверяют корректность транзакций с помощью отдельной структуры с доказательством.
После подтверждения транзакции доказательства не сохраняются, так как это не имеет смысла.
Также есть преимущества в построении цепочек транзакций, в которых определенные монеты без фактического подтверждения в текущей транзакции уже тратятся в следующей, построенной на ее основе, но не распределяются по сети.
Таким образом формируются цепочки транзакций, не раскрывающие доказательств владения монетой.
Это упрощает передачу данных и повышает конфиденциальность.
Для Segregated Witness использовался другой тип адреса, он содержит немного другие операнды.
Можно отправлять монеты, хранящиеся на обычных адресах, включая адреса P2SH, на адреса Witness P2SH. — В сети освещения адреса начинаются с тройки? BIP13 определяет правила, по которым байт версии выбирается для адресов Bitcoin в тестовой сети, других валют и т. д. Да, Lighting Network использует адреса с мультиподписью, которые также используют метод задания условий P2SH. — Почему нельзя персонализировать кошелек, то есть привязать его к конкретному человеку? Биткойн как протокол платежной системы не требует идентификации личности кошелька, поскольку работает по законам математики, а математика не позволяет описать человека как личность.
Более того, это не является обязательным условием для проверки транзакции.
Здесь достаточно электронной цифровой подписи.
Тот, кто может генерировать такие подписи, является их владельцем — к протоколу Биткойн это не относится.
Таким образом, подпись может принадлежать человеку, группе из нескольких человек, роботу и т. д. Что касается персонализации, то если вы связываете конкретный адрес с конкретным человеком, то вы нарушаете конфиденциальность и с определенной долей вероятности можете деанонимизировать часть сети.
В целом база данных открыта, но данных о физических лицах в ней нет. — Если валюта не майнится, а таких валют 70–80%, можно ли им доверять? Хорошо написано, что это валюта, а не криптовалюта, потому что криптовалюта работает по тем же принципам, что и Биткойн, то есть все процессы максимально децентрализованы: эмиссия, проверка транзакций, хранение данных, принятие изменений и т.д. Но существуют такие валюты, мы будем называть их цифровыми валютами, в которых не все перечисленные процессы децентрализованы.
Одним из вариантов может быть централизованная эмиссия, то есть нет такого понятия, как производство, добыча полезных ископаемых, то есть нет решения сложной проблемы.
По этому принципу работают Ripple, Stellar, цифровая валюта NXT, Cardano. Там применялись другие принципы распределения монет среди пользователей, например, через ICO, подтверждение личности и т. д. В связи с тем, что не все процессы могут быть децентрализованными и независимыми, назвать какую-либо цифровую валюту невозможно криптовалюта .
Кроме того, вопрос доверия к той или иной валюте носит личный характер.
Вы сами решаете размер этого доверия.
Необходимо учитывать цели, для которых используется валюта, а также ее риски и ограничения.
Теги: #bitcoin #Криптовалюты #Криптография #скрипт #Криптовалюта #мультиподпись #цифровой кошелек #p2sh
-
Энке, Иоганн Франц
19 Oct, 24 -
Накрутка Диаграммы Ганта
19 Oct, 24 -
Интернет-Реклама Превзойдет Телевидение
19 Oct, 24 -
Как Программист Купил Машину. Часть Iii
19 Oct, 24
