✅✅✅
Новый класс меток Noinput
В продолжение поста про OP_CHECKTEMPLATEVERIFY (OP_CTV)
⬇️⬇️⬇️
С Signature Hash Types разобрались
Транзакция состоит из:
Input (Вход) - это ссылка на выход другой транзакции. У транзакции их может быть несколько. Ссылки суммируются и сумма BTC используется в выходе этой транзакции.
Output (Выход) - содержит информацию об отправке BTC. Их может быть несколько, тогда они делят сумму пришедшую со входа между собой.Каждый выход используется для входа следующей транзакции, только один раз. Сумма всех входов для транзакции используется на её выходах.
Разработчик Blockstream и Xapo Кристиан Декер и Таунс разработали новый вид "меток SIGHASH": SIGHASH NOINPUT, SIGHASH ANYPREVOUT,
SIGHASH ANYPREVOUTANYSCRIPT
Как я уже писал, транзакция состоит из нескольких частей информации. Входные данные разблокируют монеты, выходные данные запирают монеты с указанием будущей траты и т.д.
Добавляется подпись соответствующая PublicKey, которая доказывает, что их владелец хочет произвести трату.
Подписывать каждую часть транзакции необязательно. Можно указать какую часть транзакции подписывать при помощи SIGHASH.
Новый класс Noinput (Noinput, Anyprevout и Anyprevoutanyscript) указывает, что выходные данные будут подписаны, а входные нет. Это значит, что не подписывая входные данные, можно осуществить транзакцию, поменяв местами совместимые входы, не генерируя новую подпись.
Таких совместимых входов, чаще всего не существует. Подпись соответствует PublicKey, а следовательно определенным монетам. Замена входа на другой приведет к тому, что транзакция станет недействительной.
Но не все так противоречиво :)
Разбирая стек биткоина я писал о решении для упрощенного способа осуществления "off-chain" (внесетевых) транзакций - Eltoo.
Чтобы Bitcoin мог поддерживать Eltoo, алгоритм подписей sighash noinput должен быть внедрен в код Bitcoin.
Имея возможность менять данные на входе, в промежутке между инициацией транзакции и записи ее в блокчейн, все записи об операциях, совершенные с момента открытия платежного канала до момента его закрытия, будут удалены. Первоначальные и конечные входные данные будут отличаться.
Такое решение необходимо, так как eltoo добавляет процедуру, которая делает каждое обновленное состояние платежного канала заданным. Любое обновление канала, например, когда А совершает транзакцию Б, состоит из двух транзакций, каждая из которых хранит, и впоследствии полностью заменяет, предыдущую транзакцию.
При помощи Eltoo оба пользователя канала сохраняют копию одной и той же необработанной транзакции - "update transaction", которая представляет их средства в канале. Эту транзакцию подписывают оба пользователя и каждый из них может транслировать ее в блокчейн.
Один из пользователей решает транслировать транзакцию в сеть. Средства могут быть потрачены двумя способами:
1) Оба пользователя тратят свою долю средств до истечения временного интервала
2) Средства используются для траты на новую взаимоподписанную "update transaction".
В Eltoo операции update пронумерованы в хронологическом порядке. Update transaction 3 может тратить средства из 2, а update transaction 2 из 1, но не наоборот.
В сети Bitcoin уже возможно такое, но куда же без нюансов...Так как входные данные должны быть подписаны, update transaction должны ссылаться только на выходные данные транзакции, которая была перед ней. Т.е. 3 тратит из 2, но не из 1.
Если таких транзакций 100, а первая транслируется в сеть, то реальный баланс канала можно восстановить только транслируя все последующие транзакции. Это очень большая нагрузка на сеть.
Чтобы update transaction мог тратить средства из 2 и из 1, необходимы метки Noinput. При замене входных данных последняя update transaction всегда может быть переписана для прямой ссылки на любую другую транзакцию.
Обмен входными данными возможен. Ведь независимо от того, какая предыдущая транзакция выбрана, в платежном канале требуемые подписи всегда исходят от одних и тех же двух пользователей с одинаковыми двумя public и private keys.
Новый класс меток Noinput
В продолжение поста про OP_CHECKTEMPLATEVERIFY (OP_CTV)
⬇️⬇️⬇️
С Signature Hash Types разобрались
Транзакция состоит из:
Input (Вход) - это ссылка на выход другой транзакции. У транзакции их может быть несколько. Ссылки суммируются и сумма BTC используется в выходе этой транзакции.
Output (Выход) - содержит информацию об отправке BTC. Их может быть несколько, тогда они делят сумму пришедшую со входа между собой.Каждый выход используется для входа следующей транзакции, только один раз. Сумма всех входов для транзакции используется на её выходах.
Разработчик Blockstream и Xapo Кристиан Декер и Таунс разработали новый вид "меток SIGHASH": SIGHASH NOINPUT, SIGHASH ANYPREVOUT,
SIGHASH ANYPREVOUTANYSCRIPT
Как я уже писал, транзакция состоит из нескольких частей информации. Входные данные разблокируют монеты, выходные данные запирают монеты с указанием будущей траты и т.д.
Добавляется подпись соответствующая PublicKey, которая доказывает, что их владелец хочет произвести трату.
Подписывать каждую часть транзакции необязательно. Можно указать какую часть транзакции подписывать при помощи SIGHASH.
Новый класс Noinput (Noinput, Anyprevout и Anyprevoutanyscript) указывает, что выходные данные будут подписаны, а входные нет. Это значит, что не подписывая входные данные, можно осуществить транзакцию, поменяв местами совместимые входы, не генерируя новую подпись.
Таких совместимых входов, чаще всего не существует. Подпись соответствует PublicKey, а следовательно определенным монетам. Замена входа на другой приведет к тому, что транзакция станет недействительной.
Но не все так противоречиво :)
Разбирая стек биткоина я писал о решении для упрощенного способа осуществления "off-chain" (внесетевых) транзакций - Eltoo.
Чтобы Bitcoin мог поддерживать Eltoo, алгоритм подписей sighash noinput должен быть внедрен в код Bitcoin.
Имея возможность менять данные на входе, в промежутке между инициацией транзакции и записи ее в блокчейн, все записи об операциях, совершенные с момента открытия платежного канала до момента его закрытия, будут удалены. Первоначальные и конечные входные данные будут отличаться.
Такое решение необходимо, так как eltoo добавляет процедуру, которая делает каждое обновленное состояние платежного канала заданным. Любое обновление канала, например, когда А совершает транзакцию Б, состоит из двух транзакций, каждая из которых хранит, и впоследствии полностью заменяет, предыдущую транзакцию.
При помощи Eltoo оба пользователя канала сохраняют копию одной и той же необработанной транзакции - "update transaction", которая представляет их средства в канале. Эту транзакцию подписывают оба пользователя и каждый из них может транслировать ее в блокчейн.
Один из пользователей решает транслировать транзакцию в сеть. Средства могут быть потрачены двумя способами:
1) Оба пользователя тратят свою долю средств до истечения временного интервала
2) Средства используются для траты на новую взаимоподписанную "update transaction".
В Eltoo операции update пронумерованы в хронологическом порядке. Update transaction 3 может тратить средства из 2, а update transaction 2 из 1, но не наоборот.
В сети Bitcoin уже возможно такое, но куда же без нюансов...Так как входные данные должны быть подписаны, update transaction должны ссылаться только на выходные данные транзакции, которая была перед ней. Т.е. 3 тратит из 2, но не из 1.
Если таких транзакций 100, а первая транслируется в сеть, то реальный баланс канала можно восстановить только транслируя все последующие транзакции. Это очень большая нагрузка на сеть.
Чтобы update transaction мог тратить средства из 2 и из 1, необходимы метки Noinput. При замене входных данных последняя update transaction всегда может быть переписана для прямой ссылки на любую другую транзакцию.
Обмен входными данными возможен. Ведь независимо от того, какая предыдущая транзакция выбрана, в платежном канале требуемые подписи всегда исходят от одних и тех же двух пользователей с одинаковыми двумя public и private keys.
Forwarded from PrimeBlock
Внимание !
Как видите со вчерашнего дня проект @Primeblock сильно вырос ! Мы собираемся развивать его и дальше.
Политика проекта насчет репостов останется неизменной - мы репостим бесплатно но только тех кого ситаем нужным и интересным для развития коммунити.
Поэтому - если у тебя есть маленький и интересный канал у тебя есть шанс чтобы тебя прочитали ведущие представители индустрии.
Прочитай политику канала, она в закрепе и напиши мне в личку, чтобы я потом тебя репостил личка - @IzhakShvarts
Прошу тех, кто поддерживает проект - репостнуть это обьявление.
Как видите со вчерашнего дня проект @Primeblock сильно вырос ! Мы собираемся развивать его и дальше.
Политика проекта насчет репостов останется неизменной - мы репостим бесплатно но только тех кого ситаем нужным и интересным для развития коммунити.
Поэтому - если у тебя есть маленький и интересный канал у тебя есть шанс чтобы тебя прочитали ведущие представители индустрии.
Прочитай политику канала, она в закрепе и напиши мне в личку, чтобы я потом тебя репостил личка - @IzhakShvarts
Прошу тех, кто поддерживает проект - репостнуть это обьявление.
✅✅✅
Simplicity - новый язык для блокчейнов, реализующий смарт-контракты в биткоине.
Для стека биткоина
⬇️⬇️⬇️
Я уже писал о других языках способных помочь деду стать более подвижным и удобным. Это обновленный язык Биткойна Tapscript для сценариев Taproot. Это MiniScript на базе языка смарт-контрактов Script.
Скриптовый язык Биткойна очень ограничен дизайном и непригоден для построения сложных смарт-контрактов. Некоторые опкоды (подробнее тут) были отключены еще в самом начале пути Биткойна.
Ethereum имеет полный гибкий и полный по Тьюрингу язык. Но и тут есть проблема...Ethereum не поддерживает статический анализ, который позволяет заранее определить какое количество вычислительных ресурсов потребуется программе. Таким образом можно отфильтровать дорогостоящие контракты и бесконечные циклы.
Simplicity был представлен разработчиком из Blockstream Russell O’Connor. Simplicity предназначен для включения в сайдчейн BlockStream и в дальнейшем, при помощи софтфорка, имплементирование его в Биткойн. Simplicity позволит завершать и расширять возможности сценариев.
Simplicity - это низкоуровневый язык основанный на алгоритме последовательного вычисления для выполнения смарт-контрактов. Это типизированный функциональный язык программирования, использующий комбинаторы. Он может быть использован как основа для других языков, более высокого уровня, так и для улучшения существующих (Bitcoin Script, EVM Ethereum).
Simplicity - это не полный по Тьюрингу, обеспечивающий ограничение рекурсивного вызова и защиту от бесконечных циклов язык. Он позволяет проводить статический анализ кода (эффективно ограничивать объем вычислительных ресурсов, необходимый программе до ее выполнения). Имеет встроенную поддержку мерклизованных абстрактных синтаксических деревьев (MAST)
Разработка пакетов SDK (Software Developer Kit) первый шаг, по развертыванию языка в проекте Elements от Blockstream.
Software Development Kit (комплект программ для разработки) - это набор необходимых программных продуктов (библиотек, скриптов), предназначенный для облегчения процесса разработки и тестирования кода для конкретных программных платформ.
Simplicity в будущем может быть интегрирован с Ivy (язык более высокого уровня, позволяющий писать смарт-контракты для протокола Bitcoin). О нем мы тоже поговорим позже, так как я собираюсь разобрать стек до конца.😇
WhitePaper
Site
#SmartContracts
Simplicity - новый язык для блокчейнов, реализующий смарт-контракты в биткоине.
Для стека биткоина
⬇️⬇️⬇️
Я уже писал о других языках способных помочь деду стать более подвижным и удобным. Это обновленный язык Биткойна Tapscript для сценариев Taproot. Это MiniScript на базе языка смарт-контрактов Script.
Скриптовый язык Биткойна очень ограничен дизайном и непригоден для построения сложных смарт-контрактов. Некоторые опкоды (подробнее тут) были отключены еще в самом начале пути Биткойна.
Ethereum имеет полный гибкий и полный по Тьюрингу язык. Но и тут есть проблема...Ethereum не поддерживает статический анализ, который позволяет заранее определить какое количество вычислительных ресурсов потребуется программе. Таким образом можно отфильтровать дорогостоящие контракты и бесконечные циклы.
Simplicity был представлен разработчиком из Blockstream Russell O’Connor. Simplicity предназначен для включения в сайдчейн BlockStream и в дальнейшем, при помощи софтфорка, имплементирование его в Биткойн. Simplicity позволит завершать и расширять возможности сценариев.
Simplicity - это низкоуровневый язык основанный на алгоритме последовательного вычисления для выполнения смарт-контрактов. Это типизированный функциональный язык программирования, использующий комбинаторы. Он может быть использован как основа для других языков, более высокого уровня, так и для улучшения существующих (Bitcoin Script, EVM Ethereum).
Simplicity - это не полный по Тьюрингу, обеспечивающий ограничение рекурсивного вызова и защиту от бесконечных циклов язык. Он позволяет проводить статический анализ кода (эффективно ограничивать объем вычислительных ресурсов, необходимый программе до ее выполнения). Имеет встроенную поддержку мерклизованных абстрактных синтаксических деревьев (MAST)
Разработка пакетов SDK (Software Developer Kit) первый шаг, по развертыванию языка в проекте Elements от Blockstream.
Software Development Kit (комплект программ для разработки) - это набор необходимых программных продуктов (библиотек, скриптов), предназначенный для облегчения процесса разработки и тестирования кода для конкретных программных платформ.
Simplicity в будущем может быть интегрирован с Ivy (язык более высокого уровня, позволяющий писать смарт-контракты для протокола Bitcoin). О нем мы тоже поговорим позже, так как я собираюсь разобрать стек до конца.😇
WhitePaper
Site
#SmartContracts
✅✅✅
Mining Derivatives - контракты на биткойн-хэшрейт.
Для стека биткоина
⬇️⬇️⬇️
Деривативы - это производные финансовые инструменты. Производные они, потому что сами по себе они ничего не стоят, поэтому их стоимость определяется ценой базового актива. Базовым активом может быть что угодно: долговые обязательства, валюты, ценные бумаги, или как в нашем случае, биткойн-хэшрейт.
Деривативы предназначены для спекуляций и хэджирования рисков. Если с первым все довольно понятно, то вот с хэджированием думаю стоит разобраться...
Хеджирование - открытие сделок на одном рынке для компенсации воздействия ценовых рисков равной, но противоположной позиции на другом рынке.
В статье "Hedging mining difficulty", Tamas Blummer провел исследование расчета и хэджирования сложности майнинга.
Оценивая скорость увеличения сложности невозможно точно определить влияние изменений сложности на добычу на более длительный срок. Более точный эффект корректировки сложности можно рассчитать наблюдая за совокупной работой, требуемой сетью. А фактическая производительность майнера пропорциональна той доле работы, которую он смог выполнить из общего количества требуемых сетью.
Чтобы немного больше погрузиться в тему хэшрейта и его влияния на цену BTC, рекомендую к прочтению статьи автора канала t.me/gfoundinshit.
Ну а теперь собственно к хэджированию...
Майнер хочет перестраховаться от более сильного (чем ожидалось) увеличения сложности. Есть спекулянт который хочет взять другую сторону этой ставки. В итоге, они создают две транзакции:
1-ая транзакция - майнер и спекулянт вносят средства для совместного депонирования (multisig). Спекулянт вносит X BTC, а майнер <X BTC, и они оба согласны в справедливости цены страховки.
2-ая транзакция блокируется и не вносится в блокчейн установленный контрактом срок. По истечении времени одна из сторон получает сумму условного депонирования в зависимости от увеличения сложности на момент разблокировки контракта.
Такой способ создает полностью обеспеченную ставку, без третей стороны или оракула.
Проект позволяющий спекулировать на хэшрейте BTC, для хэджирования от волатильности цен сейчас в AlphaTest.
PowSwap - это метод торговли производными хешрейта биткойна, использующий протокол Биткойна в качестве оракула, таким образом, не полагаясь на доверенных третьих лиц.
Разработчик Powswap Jeremy Rubin объявил о запуске проекта в ноябре 2019 года.
"Это смарт-контракт/платформа для торговли деривативами Биткойн-хешрейта. Без посредников. Никаких оракулов. Никаких депозитов. Ничего, кроме Биткойна.”
Powswap работает на Bitcoin Core и не требует софтфорка. Базовый протокол не требует участия других сторон. Это некастодиальная, не требующая доверия платформа производных хэшрейта.
Используя смарт-контракты, powswap автоматически обнаруживает изменения в хешрейте биткойна и производит выплаты контрактов на этой основе. Протокол Powswap является гибкой основой для экзотических контрактов хешрейта.
Платформа ретранслирует заказы через доску объявлений доступных предложений и берет небольшую комиссию за ретрансляцию заказов. Контракты могут обновляться без взаимодействия по цепочке, что позволяет договаривающимся сторонам пересматривать контракты по мере корректировки рыночных прогнозов.
Сложность возникает лишь в том, будут ли стороны согласны заключать предложенные ставки...Ведь такой вид деривативов весьма специфичен
В апреле 2017 года CME Group опубликовали патент на создание платформы для майнеров BTC, позволяющую хэджировать операционные риски.
В декабре 2019 года компания Canaan в партнерстве с маркет-мейкером GSR и Interhash создала концепцию, позволяющую майнерам хеджировать свои риски. (Ссылка)
В чем же основные отличия?
Powswap - это децентрализованная платформа, что определенно большой плюс для нее...
#Mining
Mining Derivatives - контракты на биткойн-хэшрейт.
Для стека биткоина
⬇️⬇️⬇️
Деривативы - это производные финансовые инструменты. Производные они, потому что сами по себе они ничего не стоят, поэтому их стоимость определяется ценой базового актива. Базовым активом может быть что угодно: долговые обязательства, валюты, ценные бумаги, или как в нашем случае, биткойн-хэшрейт.
Деривативы предназначены для спекуляций и хэджирования рисков. Если с первым все довольно понятно, то вот с хэджированием думаю стоит разобраться...
Хеджирование - открытие сделок на одном рынке для компенсации воздействия ценовых рисков равной, но противоположной позиции на другом рынке.
В статье "Hedging mining difficulty", Tamas Blummer провел исследование расчета и хэджирования сложности майнинга.
Оценивая скорость увеличения сложности невозможно точно определить влияние изменений сложности на добычу на более длительный срок. Более точный эффект корректировки сложности можно рассчитать наблюдая за совокупной работой, требуемой сетью. А фактическая производительность майнера пропорциональна той доле работы, которую он смог выполнить из общего количества требуемых сетью.
Чтобы немного больше погрузиться в тему хэшрейта и его влияния на цену BTC, рекомендую к прочтению статьи автора канала t.me/gfoundinshit.
Ну а теперь собственно к хэджированию...
Майнер хочет перестраховаться от более сильного (чем ожидалось) увеличения сложности. Есть спекулянт который хочет взять другую сторону этой ставки. В итоге, они создают две транзакции:
1-ая транзакция - майнер и спекулянт вносят средства для совместного депонирования (multisig). Спекулянт вносит X BTC, а майнер <X BTC, и они оба согласны в справедливости цены страховки.
2-ая транзакция блокируется и не вносится в блокчейн установленный контрактом срок. По истечении времени одна из сторон получает сумму условного депонирования в зависимости от увеличения сложности на момент разблокировки контракта.
Такой способ создает полностью обеспеченную ставку, без третей стороны или оракула.
Проект позволяющий спекулировать на хэшрейте BTC, для хэджирования от волатильности цен сейчас в AlphaTest.
PowSwap - это метод торговли производными хешрейта биткойна, использующий протокол Биткойна в качестве оракула, таким образом, не полагаясь на доверенных третьих лиц.
Разработчик Powswap Jeremy Rubin объявил о запуске проекта в ноябре 2019 года.
"Это смарт-контракт/платформа для торговли деривативами Биткойн-хешрейта. Без посредников. Никаких оракулов. Никаких депозитов. Ничего, кроме Биткойна.”
Powswap работает на Bitcoin Core и не требует софтфорка. Базовый протокол не требует участия других сторон. Это некастодиальная, не требующая доверия платформа производных хэшрейта.
Используя смарт-контракты, powswap автоматически обнаруживает изменения в хешрейте биткойна и производит выплаты контрактов на этой основе. Протокол Powswap является гибкой основой для экзотических контрактов хешрейта.
Платформа ретранслирует заказы через доску объявлений доступных предложений и берет небольшую комиссию за ретрансляцию заказов. Контракты могут обновляться без взаимодействия по цепочке, что позволяет договаривающимся сторонам пересматривать контракты по мере корректировки рыночных прогнозов.
Сложность возникает лишь в том, будут ли стороны согласны заключать предложенные ставки...Ведь такой вид деривативов весьма специфичен
В апреле 2017 года CME Group опубликовали патент на создание платформы для майнеров BTC, позволяющую хэджировать операционные риски.
В декабре 2019 года компания Canaan в партнерстве с маркет-мейкером GSR и Interhash создала концепцию, позволяющую майнерам хеджировать свои риски. (Ссылка)
В чем же основные отличия?
Powswap - это децентрализованная платформа, что определенно большой плюс для нее...
#Mining
✅✅✅
ZeroLink - усовершенствованный CoinJoin
Для стека биткоина
⬇️⬇️⬇️
Посты на тему конфиденциальных платежей под тегом #Privacy
CoinJoin
MimbleWimble
CoinSwap
TumbleBit
Dandelion
Теперь поехалите...
Важным свойством денег является их взаимозаменяемость - идентичность каждой единицы каждой другой единице. Уже сейчас видно, как биржи блокируют средства, если они отмечаются как "грязные" или засвеченные в миксерах. А компании вроде Crystal или ChainAnalysis помогают им в этом. Подробнее о том, как правоохранительные органы используют блокчейн я писал в этом посте
Идеальная взаимозаменяемость требует, чтобы каждая биткойн-транзакция была неотличима друг от друга
Проблему взаимозаменяемости, которая присутствует сегодня, можно решить лишь при помощи улучшения конфиденциальности проведения платежей.
Протокол ZeroLink, от разработчиков HiddenWallet (тот что внедрил TumbleBit) и Samourai Wallet, предлагает технологию микширования Chaumian CoinJoin для обеспечения анонимности транзакций. ZeroLink разрывает связи между отдельными наборами монет.
Давайте по порядку:
CoinJoin был представлен еще в 2013 году и имеет огромное количество модификаций и вариаций использования: SharedCoin, Dark Wallet, DarkSend в Altcoin Dash, JoinMarket. Честно, не скажу, используют их сегодня или нет.😅
"Классический" CoinJoin работает так:
Несколько пользователей согласовывают и создают совместно подписанную транзакцию с множеством входов и выходов. Эта транзакция содержит средства из кошельков этих пользователей. Выходы общей транзакции перемешиваются и невозможно отследить кому и от кого шел каждый конкретный платеж.
Недостаток думаю понятен...Кто-то должен запустить такую транзакцию и пользователи проводящие CoinJoin-транзакцию знают друг о друге достаточно, чтобы восстановить цепочку транзакций: адрес отправителя, адрес получателя, количество монет, адрес сдачи. Похожая проблема существовала в CoinSwap (ссылочка выше).
Модификация Chaumian CoinJoin, которую предложил Maxwell - это система микширования, которая использует слепые подписи.
Слепые подписи основаны на схеме Дэвида Чаума (David Chaum). Подписывающая сторона не может точно знать содержимое подписываемого документа.
Каждый из пользователей отправляет вход для траты своих монет, адрес получения сдачи и криптографически замаскированную версию адреса, для совершения платежа.
Сервер проверяет и подписывает выход, а затем отправляет подпись обратно пользователю. Сервер не видит адрес отправки, так как используется слепая подпись. Пользователь анонимно переподключается к серверу и демаскирует (убирает ослепление) выходного, уже подписанного адреса. Сервер определяет, что все выходы были им подписаны и поступили от реальных участников, при чем он не знает какой вход, соответствует определенному выходу.
После этого пользователи снова анонимно переподключаются и предоставляют подписи. Сервер создает транзакцию CoinJoin и отправляет пользователям для подписи.
Ещё раз момент с подписями. Всего с подписями совершается два шага:
1) Сначала проставляется слепая подпись. Координатор узнает, кто какую подпись поставил.
2) Каждый участник анонимно подключается к серверу координатора и снимает ослепление с подписи.
Как итог, координатор не может определить кому принадлежит какая подпись
Суть в том, что не возможно украсть средства или деанонимизировать пользователей. Вся процедура занимает около минуты. Также такое взаимодействие может происходить при помощи анонимных сетей (TOR, I2P и т.д.)
На GitHub расписаны механизмы защиты от нарушения процессов создания транзакций недобросовестными участниками.
К решению ZeroLink вернулись в 2017 году, так как комиссии в сети Биткойн уже не нулевые, и нарушить процесс миксинга монет, при комиссиях около 1$ не выгодно экономически.
Samourai внедрил ZeroLink в Whirlpool.
#Privacy
ZeroLink - усовершенствованный CoinJoin
Для стека биткоина
⬇️⬇️⬇️
Посты на тему конфиденциальных платежей под тегом #Privacy
CoinJoin
MimbleWimble
CoinSwap
TumbleBit
Dandelion
Теперь поехалите...
Важным свойством денег является их взаимозаменяемость - идентичность каждой единицы каждой другой единице. Уже сейчас видно, как биржи блокируют средства, если они отмечаются как "грязные" или засвеченные в миксерах. А компании вроде Crystal или ChainAnalysis помогают им в этом. Подробнее о том, как правоохранительные органы используют блокчейн я писал в этом посте
Идеальная взаимозаменяемость требует, чтобы каждая биткойн-транзакция была неотличима друг от друга
Проблему взаимозаменяемости, которая присутствует сегодня, можно решить лишь при помощи улучшения конфиденциальности проведения платежей.
Протокол ZeroLink, от разработчиков HiddenWallet (тот что внедрил TumbleBit) и Samourai Wallet, предлагает технологию микширования Chaumian CoinJoin для обеспечения анонимности транзакций. ZeroLink разрывает связи между отдельными наборами монет.
Давайте по порядку:
CoinJoin был представлен еще в 2013 году и имеет огромное количество модификаций и вариаций использования: SharedCoin, Dark Wallet, DarkSend в Altcoin Dash, JoinMarket. Честно, не скажу, используют их сегодня или нет.😅
"Классический" CoinJoin работает так:
Несколько пользователей согласовывают и создают совместно подписанную транзакцию с множеством входов и выходов. Эта транзакция содержит средства из кошельков этих пользователей. Выходы общей транзакции перемешиваются и невозможно отследить кому и от кого шел каждый конкретный платеж.
Недостаток думаю понятен...Кто-то должен запустить такую транзакцию и пользователи проводящие CoinJoin-транзакцию знают друг о друге достаточно, чтобы восстановить цепочку транзакций: адрес отправителя, адрес получателя, количество монет, адрес сдачи. Похожая проблема существовала в CoinSwap (ссылочка выше).
Модификация Chaumian CoinJoin, которую предложил Maxwell - это система микширования, которая использует слепые подписи.
Слепые подписи основаны на схеме Дэвида Чаума (David Chaum). Подписывающая сторона не может точно знать содержимое подписываемого документа.
Каждый из пользователей отправляет вход для траты своих монет, адрес получения сдачи и криптографически замаскированную версию адреса, для совершения платежа.
Сервер проверяет и подписывает выход, а затем отправляет подпись обратно пользователю. Сервер не видит адрес отправки, так как используется слепая подпись. Пользователь анонимно переподключается к серверу и демаскирует (убирает ослепление) выходного, уже подписанного адреса. Сервер определяет, что все выходы были им подписаны и поступили от реальных участников, при чем он не знает какой вход, соответствует определенному выходу.
После этого пользователи снова анонимно переподключаются и предоставляют подписи. Сервер создает транзакцию CoinJoin и отправляет пользователям для подписи.
Ещё раз момент с подписями. Всего с подписями совершается два шага:
1) Сначала проставляется слепая подпись. Координатор узнает, кто какую подпись поставил.
2) Каждый участник анонимно подключается к серверу координатора и снимает ослепление с подписи.
Как итог, координатор не может определить кому принадлежит какая подпись
Суть в том, что не возможно украсть средства или деанонимизировать пользователей. Вся процедура занимает около минуты. Также такое взаимодействие может происходить при помощи анонимных сетей (TOR, I2P и т.д.)
На GitHub расписаны механизмы защиты от нарушения процессов создания транзакций недобросовестными участниками.
К решению ZeroLink вернулись в 2017 году, так как комиссии в сети Биткойн уже не нулевые, и нарушить процесс миксинга монет, при комиссиях около 1$ не выгодно экономически.
Samourai внедрил ZeroLink в Whirlpool.
#Privacy
✅✅✅
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused
Для стека биткоина
Часть 1.
⬇️⬇️⬇️
SNICKER ("Простые неинтерактивные Coinjoins с ключами для повторного использования шифрования") - это метод, позволяющий создать двухпартийный CoinJoin (CJ) без какой-либо синхронизации или взаимодействия между участниками.
Автором SNICKER является один из разработчиков JoinMarket Adam Gibson. SNICKER представлен в качестве проекта предложения по улучшению биткойна (BIP).
Чтобы совершить транзакцию-CJ пользователи должны подписать всю транзакцию, добавив все свои монеты и новые адреса получения. Они должны совершить транзакцию несколько раз и одновременно быть в сети. SNICKER же требует лишь сторону для передачи зашифрованных данных, а другую - для их получения.
Объясняя процесс SNICKER я использовал статью "SNICKER: How Alice And Bob Can Mix Bitcoin With No Interaction".
Повторное использование адресов:
Алиса имеет 1BTC, который она хочет миксануть и он представлен как UTXO в блокчейн. Он отправляет этот биткоин себе же, на свой же адрес, публично отмечая UTXO как потенциально доступный для микса.
Боб также имеет 1BTC и он не знает Алису, но знает, что где-то в сети есть такие пользователи, которые помечают свои UTXOs для микса. Боб сканирует блокчейн в поисках таких помеченных UTXOs, плюс ко всему находит повторно используемые адреса, которые недоступны для смешивания (о них чуть позже).
Так как Алиса, отправила биткоин на тот же адрес, ее PublicKey опубликован в блокчейне. Боб использует этот PublicKey Aлисы и объединяет его со своим PrivateKey для создания “shared secret”.
Shared secret - это часть данных, известных только вовлеченным сторонам в защищенном сообщении. Обычно это относится к ключу симметричной криптосистемы. Общий секрет может быть паролем, парольной фразой, большим числом или массивом случайно выбранных байтов.
Этот секрет является общим, потому что только Алиса и Боб могут генерировать его: Боб со своим PrivateKey и PublicKey Алисы, а Алиса со своим PrivateKey и PublicKey Боба (соответствующим монетам, которые они хотят смешать).
Итак: Боб имеет UTXO Алисы (потому что он помечен) и ее PublicKey + общий секрет.
Боб берет "общий секрет" и использует его для математической "настройки" PublicKey Алисы. Такая настройка создает новый PublicKey, но без PrivateKey...пока без него.
Тут интересный момент....Этот PrivateKey для нового PublicKey может быть обнаружен Алисой, при условии, что она изменит свой первоначальный PrivateKey при помощи общего секрета и полученный измененный PrivateKey соответствовал бы измененному PublicKey.
То есть Боб может генерировать новый PublicKey, а значит и новый адрес для Алисы, без ее ведома и который только она может потратить.
Итак: Боб имеет: UTXO Алисы, ее PublicKey, общий секрет и новый адрес для Алисы.
Боб создает транзакцию с двумя входами (UTXO Алисы и UTXO для своего биткоина). Он добавляет новый адрес Алисы и свой собственный адрес в качестве выходов и подписывает транзакцию.
Для создания транзакции-CoinJoin не хватает только подписи Алисы.
Боб шифрует транзакцию при помощи PublicKey Алисы, и только Алиса может расшифровать транзакцию. Боб публикует транзакцию на доске объявлений для пользователей SNICKER. Шифрование необходимо, так как, без него, потенциальный наблюдатель может определить какой вход принадлежит Бобу, а какой Алисе.
Транзакция CJ зашифрована и хоть Алиса и знает где искать, она не знает что искать. Алиса пытается расшифровать все предложенные объявления при помощи своего PrivateKey,
Найдя ту зашифрованную транзакцию, у Алисы есть все для завершения микса. Она использует свой PrivateKey и PublicKey Боба (в входных данных) для созданияобщего секрета, который она использует для создания нового PrivateKey. После проверки этого нового PrivateKey, который должен соответствовать ее новому, созданному Бобом, адресу, она подписывает и транслирует транзакцию в сеть.
Следующим постом разберу еще одну версию без повторного использования адреса.
#Privacy
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused
Для стека биткоина
Часть 1.
⬇️⬇️⬇️
SNICKER ("Простые неинтерактивные Coinjoins с ключами для повторного использования шифрования") - это метод, позволяющий создать двухпартийный CoinJoin (CJ) без какой-либо синхронизации или взаимодействия между участниками.
Автором SNICKER является один из разработчиков JoinMarket Adam Gibson. SNICKER представлен в качестве проекта предложения по улучшению биткойна (BIP).
Чтобы совершить транзакцию-CJ пользователи должны подписать всю транзакцию, добавив все свои монеты и новые адреса получения. Они должны совершить транзакцию несколько раз и одновременно быть в сети. SNICKER же требует лишь сторону для передачи зашифрованных данных, а другую - для их получения.
Объясняя процесс SNICKER я использовал статью "SNICKER: How Alice And Bob Can Mix Bitcoin With No Interaction".
Повторное использование адресов:
Алиса имеет 1BTC, который она хочет миксануть и он представлен как UTXO в блокчейн. Он отправляет этот биткоин себе же, на свой же адрес, публично отмечая UTXO как потенциально доступный для микса.
Боб также имеет 1BTC и он не знает Алису, но знает, что где-то в сети есть такие пользователи, которые помечают свои UTXOs для микса. Боб сканирует блокчейн в поисках таких помеченных UTXOs, плюс ко всему находит повторно используемые адреса, которые недоступны для смешивания (о них чуть позже).
Так как Алиса, отправила биткоин на тот же адрес, ее PublicKey опубликован в блокчейне. Боб использует этот PublicKey Aлисы и объединяет его со своим PrivateKey для создания “shared secret”.
Shared secret - это часть данных, известных только вовлеченным сторонам в защищенном сообщении. Обычно это относится к ключу симметричной криптосистемы. Общий секрет может быть паролем, парольной фразой, большим числом или массивом случайно выбранных байтов.
Этот секрет является общим, потому что только Алиса и Боб могут генерировать его: Боб со своим PrivateKey и PublicKey Алисы, а Алиса со своим PrivateKey и PublicKey Боба (соответствующим монетам, которые они хотят смешать).
Итак: Боб имеет UTXO Алисы (потому что он помечен) и ее PublicKey + общий секрет.
Боб берет "общий секрет" и использует его для математической "настройки" PublicKey Алисы. Такая настройка создает новый PublicKey, но без PrivateKey...пока без него.
Тут интересный момент....Этот PrivateKey для нового PublicKey может быть обнаружен Алисой, при условии, что она изменит свой первоначальный PrivateKey при помощи общего секрета и полученный измененный PrivateKey соответствовал бы измененному PublicKey.
То есть Боб может генерировать новый PublicKey, а значит и новый адрес для Алисы, без ее ведома и который только она может потратить.
Итак: Боб имеет: UTXO Алисы, ее PublicKey, общий секрет и новый адрес для Алисы.
Боб создает транзакцию с двумя входами (UTXO Алисы и UTXO для своего биткоина). Он добавляет новый адрес Алисы и свой собственный адрес в качестве выходов и подписывает транзакцию.
Для создания транзакции-CoinJoin не хватает только подписи Алисы.
Боб шифрует транзакцию при помощи PublicKey Алисы, и только Алиса может расшифровать транзакцию. Боб публикует транзакцию на доске объявлений для пользователей SNICKER. Шифрование необходимо, так как, без него, потенциальный наблюдатель может определить какой вход принадлежит Бобу, а какой Алисе.
Транзакция CJ зашифрована и хоть Алиса и знает где искать, она не знает что искать. Алиса пытается расшифровать все предложенные объявления при помощи своего PrivateKey,
Найдя ту зашифрованную транзакцию, у Алисы есть все для завершения микса. Она использует свой PrivateKey и PublicKey Боба (в входных данных) для созданияобщего секрета, который она использует для создания нового PrivateKey. После проверки этого нового PrivateKey, который должен соответствовать ее новому, созданному Бобом, адресу, она подписывает и транслирует транзакцию в сеть.
Следующим постом разберу еще одну версию без повторного использования адреса.
#Privacy
✅✅✅
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused
Для стека биткоина
Часть.2
Повторно использованные подписанные входные данные
⬇️⬇️⬇️
Вторую версию SNICKER также описал Adam Gibson. В ней удалось избежать необходимости повторного использования адреса - за счет некоторого усложнения.
В этом варианте, Боб берет PublicKey из входных данных транзакции которая создала UTXO Алисы, а не из повторно используемого адреса, как в 1 варианте.
Боб полагает, что один из входов этой транзакции был создан самой Алисой, и у нее есть PrivateKey для него. Это верно, так как UTXO Алисы обозначен как готовый к миксингу и что владелец, т.е.Алиса, владеет PrivateKey.
В BIP не указывается как будет выполнена первоначальная маркировка. Но есть предположение что некоторые кошельки (например JoinMarket) смогут видеть такую информацию.
Альтернативным вариантом, Алиса могла бы разместить сообщение на доске объявлений, а именно засветить UTXO.
Как только SNICKER начнет использоваться, поиск запросов на миксинг станет проще. Сами SNIKER -транзакции просты для распознавания. Поэтому после начальной фазы загрузки несмешанные монеты будут смешиваться с ранее смешиваемыми монетами, и в свою очередь могут быть использованы для следующего смешивания...
Как упоминалось в 1 варианте, Существует проблема выбора "тех самых" UTXO, которые готовы к миксингу и уменьшение количества ложных совпадений.
Ложные совпадения, это помеченные UTXO, уже пройденные этап миксинга или проходящие в данный момент. Потенциальные совпадения могут быть отфильтрованы по суммам, возрасту UTXO или типа используемых кошельков.
Один из вариантов: Боб использует один и тот же UTXO для всех объявлений. То есть первый кто успеет проведет миксинг. Другие же, желающие провести миксинг, остаются неудел, но проблем не возникнет.Предложение Боба будет просто висеть на доске пока не удалят или навсегда.
Проблема номер 2: Так как доска объявлений будет содержать зашифрованные "запросы", то невозможно будет отфильтровать "поддельные" предложения. Одним из решений проблемы являются затраты на публикацию предложения.
Очень интересное преимущество предоставляет SNICKER. Боб, который заинтересован в миксе своих монет, может добавлять средства к выходу принимающей стороны, для стимулирования желания провести миксинг.
Так же, не отрицается возможность и использования троих сторон в миксе, но это будет довольно сложна схема.
#Privacy
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused
Для стека биткоина
Часть.2
Повторно использованные подписанные входные данные
⬇️⬇️⬇️
Вторую версию SNICKER также описал Adam Gibson. В ней удалось избежать необходимости повторного использования адреса - за счет некоторого усложнения.
В этом варианте, Боб берет PublicKey из входных данных транзакции которая создала UTXO Алисы, а не из повторно используемого адреса, как в 1 варианте.
Боб полагает, что один из входов этой транзакции был создан самой Алисой, и у нее есть PrivateKey для него. Это верно, так как UTXO Алисы обозначен как готовый к миксингу и что владелец, т.е.Алиса, владеет PrivateKey.
В BIP не указывается как будет выполнена первоначальная маркировка. Но есть предположение что некоторые кошельки (например JoinMarket) смогут видеть такую информацию.
Альтернативным вариантом, Алиса могла бы разместить сообщение на доске объявлений, а именно засветить UTXO.
Как только SNICKER начнет использоваться, поиск запросов на миксинг станет проще. Сами SNIKER -транзакции просты для распознавания. Поэтому после начальной фазы загрузки несмешанные монеты будут смешиваться с ранее смешиваемыми монетами, и в свою очередь могут быть использованы для следующего смешивания...
Как упоминалось в 1 варианте, Существует проблема выбора "тех самых" UTXO, которые готовы к миксингу и уменьшение количества ложных совпадений.
Ложные совпадения, это помеченные UTXO, уже пройденные этап миксинга или проходящие в данный момент. Потенциальные совпадения могут быть отфильтрованы по суммам, возрасту UTXO или типа используемых кошельков.
Один из вариантов: Боб использует один и тот же UTXO для всех объявлений. То есть первый кто успеет проведет миксинг. Другие же, желающие провести миксинг, остаются неудел, но проблем не возникнет.Предложение Боба будет просто висеть на доске пока не удалят или навсегда.
Проблема номер 2: Так как доска объявлений будет содержать зашифрованные "запросы", то невозможно будет отфильтровать "поддельные" предложения. Одним из решений проблемы являются затраты на публикацию предложения.
Очень интересное преимущество предоставляет SNICKER. Боб, который заинтересован в миксе своих монет, может добавлять средства к выходу принимающей стороны, для стимулирования желания провести миксинг.
Так же, не отрицается возможность и использования троих сторон в миксе, но это будет довольно сложна схема.
#Privacy
✅✅✅
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused ("Простые неинтерактивные Coinjoins с ключами для повторного использования шифрования")
Для стека биткоина
⬇️⬇️⬇️
Часть 1. Повторное использование адресов:
Часть 2. Повторно использованные подписанные входные данные
BIP SNICKER
Статья используемая для описания работы протокола
#Privacy
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused ("Простые неинтерактивные Coinjoins с ключами для повторного использования шифрования")
Для стека биткоина
⬇️⬇️⬇️
Часть 1. Повторное использование адресов:
Часть 2. Повторно использованные подписанные входные данные
BIP SNICKER
Статья используемая для описания работы протокола
#Privacy
✅✅✅
Confidential transactions (CT) - Конфиденциальные транзакции
Для стека биткоина
⬇️⬇️⬇️
Продолжая направление #Privacy сегодня о конфиденциальных транзакциях.
Анализ блокчейна, мониторинг сети, KYC, AML, нарушение принципа взаимозаменяемости - все это уже работает для того, чтобы определить, посчитать, добавить в базу и взять под контроль тебя и твои биткоины. Это бесконечная гонка, где с одной стороны регуляторы, в виде корпораций, государств и твоих кредиторов,а с другой - борцы за анонимность, приватность и свободу.
Ну а сегодня, про еще один ход черных...или белых...в этой шахматной партии. Если честно, тут тоже сложно определить, кто на чей стороне, да и не суть...В этой игре по ходу, каждый сам за себя😏
Все транзакции в сети Биткойн записаны в блокчейн. Это является как плюсом так и минусом. С одной стороны, доверие без доверия, с другой - возможность тривиального отслеживания количества BTC, с адресов на адреса.
Решить проблему можно, скрыв количество BTC в совершаемой транзакции.
Еще в 2013 году, Адам Бэк, предложил эту концепцию под названием “bitcoins with homomorphic value”. Позже ее подхватили нынешние "двигатели" развития: Gregory Maxwell, Dr. Pieter Wuille, Andrew Poelstra. В итоге на свет появились Confidential Transactions.
Confidential Transactions - это криптографический метод сокрытия суммы отправляемых и получаемых средств.
CT полностью скрывает суммы на входах и выходах транзакции, давая возможность проверить, что сумма всех выходов не превышает сумму всех входов.
Чуть подробнее:
В основе решения лежат Борромеевские кольцевые подписи и схемы обязательств Педерсена.
Боромеевские кольцевые подписи - новый тип кольцевой подписи, основанный на задаче дискретного логарифма, который использовал новую структуру обязательств для получения значительной экономии размера и времени проверки кольцевых подписей.
Если кому интересно, вот ссылочка на документацию.
Cхемы обязательств Педерсена (Petersen Commitment) - это криптографическая схема, позволяющая зафиксировать сообщение каким-либо значением, сохраняя сообщение в секрете, с возможностью последующего раскрытия зафиксированного значения. Схемы обязательств разработаны таким образом, что ни одна из сторон не может изменить сообщение после того, как они его зафиксировали. Используются для того, чтобы одна сторона могла доказать, знание секрета, не раскрывая его.
Схемы обязательств используются в интерактивном криптографическом протоколе "Zero-knowledge proof", а тот в свою очередь в Bulletproofs для BTC, в ZCash и его форках.
В Confidential Transactions используется Petersen Commitment для доказательства того, что сумма выходов не превышает сумму входов. То есть благодаря ему и скрывается сумма перевода.
В качестве суммы в commitments можно использовать отрицательное число, что приведет к неконтролируемой эмиссией монет. Range Proofs используется как раз для доказательства использования неотрицательных сумм. Проще говоря, Range Proofs - это доказательство, где каждый commitment подписан кольцевой подписью Борромео и гарантирует, что сумма находится в заданном интервале.
Проблема здесь в Range Proofs. На их создание уходит большое количество ресурсов и они имеют достаточно большой объем, что приведет к высоким комиссиям в сети.
Еще одной недогляделкой является тот факт, что суммы скрываются для конкретной транзакции. Если следующая транзакция не является конфиденциальной, предыдущие действия были бессмысленны.
CT скрывают суммы транзакций, но не адреса отправителя и получателя. Тут то и можно использовать CoinJoin или CoinSwap, с которыми CT совместим.
Так же при проведении Soft Fork, встает вопрос, о синхронизации старых и новых узлов.
В криптовалюте Monero используется версия CT - Ring Confidential Transactions, где вместо подписей Борромео (об этом ниже) используется Bulletproofs. BitShares использует CT совместно с Stealth Addresses. CT имплементированы в Liquid от Blockstream.
Confidential Transactions.txt by Greg Maxwell
О RingCT в Monero
#Privacy
Confidential transactions (CT) - Конфиденциальные транзакции
Для стека биткоина
⬇️⬇️⬇️
Продолжая направление #Privacy сегодня о конфиденциальных транзакциях.
Анализ блокчейна, мониторинг сети, KYC, AML, нарушение принципа взаимозаменяемости - все это уже работает для того, чтобы определить, посчитать, добавить в базу и взять под контроль тебя и твои биткоины. Это бесконечная гонка, где с одной стороны регуляторы, в виде корпораций, государств и твоих кредиторов,а с другой - борцы за анонимность, приватность и свободу.
Ну а сегодня, про еще один ход черных...или белых...в этой шахматной партии. Если честно, тут тоже сложно определить, кто на чей стороне, да и не суть...В этой игре по ходу, каждый сам за себя😏
Все транзакции в сети Биткойн записаны в блокчейн. Это является как плюсом так и минусом. С одной стороны, доверие без доверия, с другой - возможность тривиального отслеживания количества BTC, с адресов на адреса.
Решить проблему можно, скрыв количество BTC в совершаемой транзакции.
Еще в 2013 году, Адам Бэк, предложил эту концепцию под названием “bitcoins with homomorphic value”. Позже ее подхватили нынешние "двигатели" развития: Gregory Maxwell, Dr. Pieter Wuille, Andrew Poelstra. В итоге на свет появились Confidential Transactions.
Confidential Transactions - это криптографический метод сокрытия суммы отправляемых и получаемых средств.
CT полностью скрывает суммы на входах и выходах транзакции, давая возможность проверить, что сумма всех выходов не превышает сумму всех входов.
Чуть подробнее:
В основе решения лежат Борромеевские кольцевые подписи и схемы обязательств Педерсена.
Боромеевские кольцевые подписи - новый тип кольцевой подписи, основанный на задаче дискретного логарифма, который использовал новую структуру обязательств для получения значительной экономии размера и времени проверки кольцевых подписей.
Если кому интересно, вот ссылочка на документацию.
Cхемы обязательств Педерсена (Petersen Commitment) - это криптографическая схема, позволяющая зафиксировать сообщение каким-либо значением, сохраняя сообщение в секрете, с возможностью последующего раскрытия зафиксированного значения. Схемы обязательств разработаны таким образом, что ни одна из сторон не может изменить сообщение после того, как они его зафиксировали. Используются для того, чтобы одна сторона могла доказать, знание секрета, не раскрывая его.
Схемы обязательств используются в интерактивном криптографическом протоколе "Zero-knowledge proof", а тот в свою очередь в Bulletproofs для BTC, в ZCash и его форках.
В Confidential Transactions используется Petersen Commitment для доказательства того, что сумма выходов не превышает сумму входов. То есть благодаря ему и скрывается сумма перевода.
В качестве суммы в commitments можно использовать отрицательное число, что приведет к неконтролируемой эмиссией монет. Range Proofs используется как раз для доказательства использования неотрицательных сумм. Проще говоря, Range Proofs - это доказательство, где каждый commitment подписан кольцевой подписью Борромео и гарантирует, что сумма находится в заданном интервале.
Проблема здесь в Range Proofs. На их создание уходит большое количество ресурсов и они имеют достаточно большой объем, что приведет к высоким комиссиям в сети.
Еще одной недогляделкой является тот факт, что суммы скрываются для конкретной транзакции. Если следующая транзакция не является конфиденциальной, предыдущие действия были бессмысленны.
CT скрывают суммы транзакций, но не адреса отправителя и получателя. Тут то и можно использовать CoinJoin или CoinSwap, с которыми CT совместим.
Так же при проведении Soft Fork, встает вопрос, о синхронизации старых и новых узлов.
В криптовалюте Monero используется версия CT - Ring Confidential Transactions, где вместо подписей Борромео (об этом ниже) используется Bulletproofs. BitShares использует CT совместно с Stealth Addresses. CT имплементированы в Liquid от Blockstream.
Confidential Transactions.txt by Greg Maxwell
О RingCT в Monero
#Privacy
✅✅✅
Механизм обеспечения конфиденциальности для смарт-контрактов в сети эфира (ETH) - Zether.
⬇️⬇️⬇️
https://t.me/CryptoBotan/874
Как и обещал описание протокола более подробно.
Zether - это полностью децентрализованный конфиденциальный платежный механизм, который совместим и с сетью Ethereum, и с другими платформами смарт-контрактов.
Он был разработан и предложен для криптоконтрактов на основе учетных записей, таких как Ether, ERC20 и Stellar Lumens.
Авторами протокола являются Shashank Agrawal и Mahdi Zamani из Visa Research, Dr. Dan Boneh и Benedikt из Стэнфордского университета, которые работали над протоколом Bulletproofs, о котором тоже в скором времени сделаю пост.
Bulletproofs - это короткие неинтерактивные доказательства с нулевым разглашением, которые не требуют доверенной установки. Они позволяет спрятать денежное значение посылаемой транзакции от общего реестра, для сохранения приватности её создателя.
Для того, чтобы доказать, что зашифрованные транзакции верны, исследователи добавили Σ-Bullets, оптимизацию Bulletproofs. Σ-Bullets делает Bulletproofs совместимым с протоколом Sigma - протоколом конфедициальности использующийся в ZCoin.
”Мы описываем Zether как смарт-контракт, который может быть выполнен либо индивидуально, либо другими смарт-контрактами для обмена конфиденциальными суммами токенов - ZTH".
Механизм Zether напоминает систему поддержания приватности, используемую в сети Monero.
Zether шифрует балансы счетов и сохраняет эту информацию до исполнения депозитов или проведения транзакции с помощью "криптодоказательств".
Cредства закрываются в смарт-контракте и остаются там запертыми. Контракт Zether проводит операцию по переводу средств только после получения соответствующего доказательства сжигания или перевода средств, и это не зависит от того, с какой стороны поступает запрос.
Контракт Zether не переводит средства без предварительной проверки соответствующего подтверждения переноса, даже если запрос исходит от другого смарт-контракта, внутренние правила которого не разрешают переводы такого формата.
Это гарантирует, что безопасность Zether зависит только от своей внутренней структуры, а не от какого-либо внешнего смарт-контракта. Даже специально написанный или небезопасный смарт-контракт не может привести к неправильном решениям Zether.
Используя протокол, пользователь отправляет один из совместимых с ним токенов в контракт ZSC, взамен получая эквивалентный токен ZTH. Он используется для скрытых транзакций. После этого он может вернуть исходные токены.
Смарт-контракт ZSC, и имеет пять публичных функций:
Fund – создание ZTH путем депозита ETH
Burn – Возврат ETH
Transfer – Перевод ZTH
Lock- Блокировка ZTH в смарт-контракте
Unlock – Разблокировка ZTH в смарт-контракте
Это делает Zether отличным инструментом для закрытых заявок на аукцион, конфиденциальных каналов оплаты,
конфиденциального голосования.
Ссылка на документ с описанием протокола. (англ)
Механизм обеспечения конфиденциальности для смарт-контрактов в сети эфира (ETH) - Zether.
⬇️⬇️⬇️
https://t.me/CryptoBotan/874
Как и обещал описание протокола более подробно.
Zether - это полностью децентрализованный конфиденциальный платежный механизм, который совместим и с сетью Ethereum, и с другими платформами смарт-контрактов.
Он был разработан и предложен для криптоконтрактов на основе учетных записей, таких как Ether, ERC20 и Stellar Lumens.
Авторами протокола являются Shashank Agrawal и Mahdi Zamani из Visa Research, Dr. Dan Boneh и Benedikt из Стэнфордского университета, которые работали над протоколом Bulletproofs, о котором тоже в скором времени сделаю пост.
Bulletproofs - это короткие неинтерактивные доказательства с нулевым разглашением, которые не требуют доверенной установки. Они позволяет спрятать денежное значение посылаемой транзакции от общего реестра, для сохранения приватности её создателя.
Для того, чтобы доказать, что зашифрованные транзакции верны, исследователи добавили Σ-Bullets, оптимизацию Bulletproofs. Σ-Bullets делает Bulletproofs совместимым с протоколом Sigma - протоколом конфедициальности использующийся в ZCoin.
”Мы описываем Zether как смарт-контракт, который может быть выполнен либо индивидуально, либо другими смарт-контрактами для обмена конфиденциальными суммами токенов - ZTH".
Механизм Zether напоминает систему поддержания приватности, используемую в сети Monero.
Zether шифрует балансы счетов и сохраняет эту информацию до исполнения депозитов или проведения транзакции с помощью "криптодоказательств".
Cредства закрываются в смарт-контракте и остаются там запертыми. Контракт Zether проводит операцию по переводу средств только после получения соответствующего доказательства сжигания или перевода средств, и это не зависит от того, с какой стороны поступает запрос.
Контракт Zether не переводит средства без предварительной проверки соответствующего подтверждения переноса, даже если запрос исходит от другого смарт-контракта, внутренние правила которого не разрешают переводы такого формата.
Это гарантирует, что безопасность Zether зависит только от своей внутренней структуры, а не от какого-либо внешнего смарт-контракта. Даже специально написанный или небезопасный смарт-контракт не может привести к неправильном решениям Zether.
Используя протокол, пользователь отправляет один из совместимых с ним токенов в контракт ZSC, взамен получая эквивалентный токен ZTH. Он используется для скрытых транзакций. После этого он может вернуть исходные токены.
Смарт-контракт ZSC, и имеет пять публичных функций:
Fund – создание ZTH путем депозита ETH
Burn – Возврат ETH
Transfer – Перевод ZTH
Lock- Блокировка ZTH в смарт-контракте
Unlock – Разблокировка ZTH в смарт-контракте
Это делает Zether отличным инструментом для закрытых заявок на аукцион, конфиденциальных каналов оплаты,
конфиденциального голосования.
Ссылка на документ с описанием протокола. (англ)
Telegram
CryptoBotan
✅✅✅
В феврале 2019 года был представлен механизм обеспечения конфиденциальности для смарт-контрактов в сети эфира (ETH) - Zether.
Механизм Zether напоминает систему поддержания приватности, используемую в сети Monero
Чуть подробнее ниже...сделаю ещё отдельный…
В феврале 2019 года был представлен механизм обеспечения конфиденциальности для смарт-контрактов в сети эфира (ETH) - Zether.
Механизм Zether напоминает систему поддержания приватности, используемую в сети Monero
Чуть подробнее ниже...сделаю ещё отдельный…
✅✅✅
P2EP - Pay to Endpoint (Оплата до конечной точки)
Для стека биткоина
⬇️⬇️⬇️
Решение P2EP было предложено на так называемом "brainstorming event on Bitcoin privacy". Участники этого ивента предлагали решения для улучшения базовой конфиденциальности транзакций в Биткойн.
Есть еще несколько реализаций P2EP:
1) PayJoin для JoinMarket от Adam Gibson
2) Bustapay базовая версия P2EP от Havar
Основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев.
Цель создания P2EP: обеспечить способ гарантировать, что операции с входными данными, принадлежащими более чем одной стороне, являются достаточно распространенным явлением.
P2EP - это особый тип CoinJoin-транзакций.
Ограничения использования CoinJoin:
- если все участники CoinJoin не используют равные суммы, то можно определить какие входы, оплачивают выходы
- наблюдатель может определить, что это CoinJoin-транзакция, а следовательно, нарушается принцип взаимозаменяемости.
P2EP устраняет ограничения классического CoinJoin и может использоваться для регулярных платежей.
Суть P2EP такова, что и отправитель, и получатель вносят входные данные в транзакцию посредством взаимодействий, координируемых конечной точкой, которую представляет получатель, используя совместимый URI BIP 21.
BIP 21 предлагает схему URI для осуществления биткойн-платежей.
Б (получатель) генерирует URI BIP 21 с параметром определяющим конечную точку P2EP.
А (отправитель) инициирует взаимодействие с Б, подтверждая, что предоставленная конечная точка доступна. Если конечная точка Б доступна, А предоставляет Б подписанную транзакцию в качестве доказательства владения UTXO.
Затем Б отправляет несколько транзакций А, которые он должен подписать. Из этих транзакций только одна включает в себя UTXO, который фактически принадлежит Б, остальные могут быть выбраны из пула расходуемых UTXOs. После эти транзакции могут быть отправлены либо последовательно, либо параллельно отправителю.
Каждый подход отправки транзакций имеет свои плюсы и минусы. Но стоит заметить, что есть и третий подход для обмена UTXO. Это Bulletproofs который я довольно много в последнее время упоминаю...
Когда Б получает подписанную транзакцию, которая соответствует их UTXO, они могут подписать и транслировать транзакцию, которая теперь будет содержать входные данные как от А, так и от Б.
В случае сбоя P2EP по любым причинам транзакция передается как обычная.
Пример:
Если Алиса хочет отправить Бобу 1.2 BTC, то она может отправить их с двух входов: 1 и 0.5 BTC. Лишние 0.3 BTC отправялются обратно в виде сдачи.
При помощи P2EP Боб добавляет один свой вход в транзакцию, например 0.9 BTC. Теперь транзакция имеет 3 входа 1+0.9+0.5 = 2.4 BTC, и два адреса: 2.1 и 0.3 BTC. В итоге Алиса заплатила 1.2 BTC, несмотря на некоторое усложнение.
Здесь то и достигнута цель, которую я описал в самом начале. Не все входы принадлежат Алисе, следовательно тот факт, что это CoinJoin транзакция, не очевиден. Нет совпадающих сумм при отправке и получении, а значит и связать адреса вместе не представляется возможным. Такие транзакции можно интерпретировать как оплачивающие что-то с остатками сдачи.
Такие транзакции нарушают эвристику "общего владения входными данными" и улучшают конфиденциальность, тем самым не отличаясь от обычных транзакций.
Нет ничего совершенного, поэтому некоторые недостатки:
1) Обе стороны сделки должны быть онлайн.
2) Получатель должен иметь "hot wallet" для подписи транзакций.
3) Более высокие комиссионные сборы из-за увеличения объема транзакции.
4) Получатель должен иметь доступ к полному узлу
На сегодняшний день, это одно из самых обсуждаемых разработок в направлении #Privacy
Статья Blockstream
Статья на Medium by Nopara73
P2EP - Pay to Endpoint (Оплата до конечной точки)
Для стека биткоина
⬇️⬇️⬇️
Решение P2EP было предложено на так называемом "brainstorming event on Bitcoin privacy". Участники этого ивента предлагали решения для улучшения базовой конфиденциальности транзакций в Биткойн.
Есть еще несколько реализаций P2EP:
1) PayJoin для JoinMarket от Adam Gibson
2) Bustapay базовая версия P2EP от Havar
Основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев.
Цель создания P2EP: обеспечить способ гарантировать, что операции с входными данными, принадлежащими более чем одной стороне, являются достаточно распространенным явлением.
P2EP - это особый тип CoinJoin-транзакций.
Ограничения использования CoinJoin:
- если все участники CoinJoin не используют равные суммы, то можно определить какие входы, оплачивают выходы
- наблюдатель может определить, что это CoinJoin-транзакция, а следовательно, нарушается принцип взаимозаменяемости.
P2EP устраняет ограничения классического CoinJoin и может использоваться для регулярных платежей.
Суть P2EP такова, что и отправитель, и получатель вносят входные данные в транзакцию посредством взаимодействий, координируемых конечной точкой, которую представляет получатель, используя совместимый URI BIP 21.
BIP 21 предлагает схему URI для осуществления биткойн-платежей.
Б (получатель) генерирует URI BIP 21 с параметром определяющим конечную точку P2EP.
А (отправитель) инициирует взаимодействие с Б, подтверждая, что предоставленная конечная точка доступна. Если конечная точка Б доступна, А предоставляет Б подписанную транзакцию в качестве доказательства владения UTXO.
Затем Б отправляет несколько транзакций А, которые он должен подписать. Из этих транзакций только одна включает в себя UTXO, который фактически принадлежит Б, остальные могут быть выбраны из пула расходуемых UTXOs. После эти транзакции могут быть отправлены либо последовательно, либо параллельно отправителю.
Каждый подход отправки транзакций имеет свои плюсы и минусы. Но стоит заметить, что есть и третий подход для обмена UTXO. Это Bulletproofs который я довольно много в последнее время упоминаю...
Когда Б получает подписанную транзакцию, которая соответствует их UTXO, они могут подписать и транслировать транзакцию, которая теперь будет содержать входные данные как от А, так и от Б.
В случае сбоя P2EP по любым причинам транзакция передается как обычная.
Пример:
Если Алиса хочет отправить Бобу 1.2 BTC, то она может отправить их с двух входов: 1 и 0.5 BTC. Лишние 0.3 BTC отправялются обратно в виде сдачи.
При помощи P2EP Боб добавляет один свой вход в транзакцию, например 0.9 BTC. Теперь транзакция имеет 3 входа 1+0.9+0.5 = 2.4 BTC, и два адреса: 2.1 и 0.3 BTC. В итоге Алиса заплатила 1.2 BTC, несмотря на некоторое усложнение.
Здесь то и достигнута цель, которую я описал в самом начале. Не все входы принадлежат Алисе, следовательно тот факт, что это CoinJoin транзакция, не очевиден. Нет совпадающих сумм при отправке и получении, а значит и связать адреса вместе не представляется возможным. Такие транзакции можно интерпретировать как оплачивающие что-то с остатками сдачи.
Такие транзакции нарушают эвристику "общего владения входными данными" и улучшают конфиденциальность, тем самым не отличаясь от обычных транзакций.
Нет ничего совершенного, поэтому некоторые недостатки:
1) Обе стороны сделки должны быть онлайн.
2) Получатель должен иметь "hot wallet" для подписи транзакций.
3) Более высокие комиссионные сборы из-за увеличения объема транзакции.
4) Получатель должен иметь доступ к полному узлу
На сегодняшний день, это одно из самых обсуждаемых разработок в направлении #Privacy
Статья Blockstream
Статья на Medium by Nopara73
✅✅✅
BetterHash - альтернативный майнинг-протокол
Для стека биткоина
⬇️⬇️⬇️
Подробнее на эту тему не напишешь, поэтому, дабы избежать плагиата, ниже перевод статьи "BetterHash: Decentralizing Bitcoin Mining With New Hashing Protocols"
https://bitnovosti.com/2020/03/04/betterhash-detsentralizovannyj-majning-bitkojnov-s-novymi-protokolami-heshirovaniya/
#Mining
BetterHash - альтернативный майнинг-протокол
Для стека биткоина
⬇️⬇️⬇️
Подробнее на эту тему не напишешь, поэтому, дабы избежать плагиата, ниже перевод статьи "BetterHash: Decentralizing Bitcoin Mining With New Hashing Protocols"
https://bitnovosti.com/2020/03/04/betterhash-detsentralizovannyj-majning-bitkojnov-s-novymi-protokolami-heshirovaniya/
#Mining
✅✅✅
Stratum - объединенный протокол майнинга
Для стека биткоина
⬇️⬇️⬇️
До конца 2012 года для майнинга использовался протокол "getwork". После, в середине 2012 года, разработан новый децентрализованный протокол майнинга BTC "getblocktemplate".
Оригинальный протокол getwork был заменен, так как просто выдавал заголовки блоков для решения. Майнер понятия не имел, что находится в блоке и никак не влиял на него. Майнер мог решать какие транзакции принимаются и передавать их оператору пула, а тот в свою очередь, мог использовать мощности всех майнеров для атак с двойной тратой и др.
Протокол "getblocktemplate" позволил перемещать создание блоков в майнер, предоставляя пулам возможность устанавливать правила участия. Это повысило безопасность сети за счет повторной децентрализации блоков.
"Getwork" предоставлял только один заголовок блока, которого достаточно для общей сложности около 4 GH. Майнер отправлял пулу запросы getwork уже начиная от 4GH, что не позволяло подключать к пулу большие мощности. "Getblocktemplate" снизил нагрузку, необходимую для одного запроса на новый блок в сети.
С помощью "getwork", заголовок блока передавался с сервера на клиент без каких-либо транзакций. Единственный способ изменить блок можно было через значение nonce. Максимум, что мог сделать клиент, - это попробовать все значения nonce, требующие дополнительной работы от сервера. Плюс ко всему "getwork" был несовместим с расширениями.
Протокол Stratum был представлен основателем SlushPool Марек Палатинусом. Stratum на тот момент, был более стабилен, меньше нагружал сеть и решал проблемы безопасности и роста сети. Он явился заменой сетевых серверов пула и позволил клиентам генерировать работу.
Сегодня, Stratum используется при майнинге криптовалют на алгоритме PoW. Изначально же он разрабатывался для light биткоин-клиента Electrum. Как оказалось, требования протокола схожи и для майнинга BTC и его начали использовать как сеть.
Stratum-это линейный протокол, использующий TCP socket, с полезной нагрузкой, закодированной в виде сообщений JSON-RPC. Такое решение, позволяет клиенту и серверу общаться в удобно-читаемом формате. Этот протокол легко расширяется и не нарушает обратной совместимости.
Stratum решал ситуацию с HTTP, где клиенты запрашивали у сервера определенный контент. Т.е. в майнинге HTTP управляется майнерами, запрашивающими новые задания для майнинга, доступные для серверов пула. Майнеры тратили время на эти запросы. Stratum позволил более эффективно управлять коммуникацией майнеров и пула.
Для каждого задания майнер может изменять поля ntime и nonce. Крупные майнеры перебирают все возможные значения двух полей в поисках решения. Если у майнера заканчиваются уникальные возможности перебора, он отправляет новый запрос. Новым и более быстрым майнерам сделать это проще. Stratum позволяет майнерам изменять еще несколько полей, что увеличивает общее число возможных решений для блока.
nonce-это 32-битное значение, которое корректируется постепенно и используется для повторного хэширования хэшированного блока до тех пор, пока хэш-выход не будет соответствовать текущим ограничениям уровня сложности сети, сигнализируя о том, что было найдено допустимое решение, и майнер может затем предложить свой блок остальной части сети.
nTime - это целочисленная временная метка (в секундах), включенная в заголовок блока. Rolling NTime-это способ для майнеров увеличить отметку времени локально в своем оборудовании, а не требовать каждый раз новый заголовок блока из своего пула, уменьшая объем передачи данных, которые должны происходить между пулами и майнерами.
Уже все наслышаны о v.2 протокола Stratum. Новая модификация протокола предназначена для улучшения совместной работы майнеров и пулов. И самое важно, версия 2.0. сделает добычу более децентрализованной.
Более подробно затрону Stratum при разборе v.2.0.
#Mining
Stratum - объединенный протокол майнинга
Для стека биткоина
⬇️⬇️⬇️
До конца 2012 года для майнинга использовался протокол "getwork". После, в середине 2012 года, разработан новый децентрализованный протокол майнинга BTC "getblocktemplate".
Оригинальный протокол getwork был заменен, так как просто выдавал заголовки блоков для решения. Майнер понятия не имел, что находится в блоке и никак не влиял на него. Майнер мог решать какие транзакции принимаются и передавать их оператору пула, а тот в свою очередь, мог использовать мощности всех майнеров для атак с двойной тратой и др.
Протокол "getblocktemplate" позволил перемещать создание блоков в майнер, предоставляя пулам возможность устанавливать правила участия. Это повысило безопасность сети за счет повторной децентрализации блоков.
"Getwork" предоставлял только один заголовок блока, которого достаточно для общей сложности около 4 GH. Майнер отправлял пулу запросы getwork уже начиная от 4GH, что не позволяло подключать к пулу большие мощности. "Getblocktemplate" снизил нагрузку, необходимую для одного запроса на новый блок в сети.
С помощью "getwork", заголовок блока передавался с сервера на клиент без каких-либо транзакций. Единственный способ изменить блок можно было через значение nonce. Максимум, что мог сделать клиент, - это попробовать все значения nonce, требующие дополнительной работы от сервера. Плюс ко всему "getwork" был несовместим с расширениями.
Протокол Stratum был представлен основателем SlushPool Марек Палатинусом. Stratum на тот момент, был более стабилен, меньше нагружал сеть и решал проблемы безопасности и роста сети. Он явился заменой сетевых серверов пула и позволил клиентам генерировать работу.
Сегодня, Stratum используется при майнинге криптовалют на алгоритме PoW. Изначально же он разрабатывался для light биткоин-клиента Electrum. Как оказалось, требования протокола схожи и для майнинга BTC и его начали использовать как сеть.
Stratum-это линейный протокол, использующий TCP socket, с полезной нагрузкой, закодированной в виде сообщений JSON-RPC. Такое решение, позволяет клиенту и серверу общаться в удобно-читаемом формате. Этот протокол легко расширяется и не нарушает обратной совместимости.
Stratum решал ситуацию с HTTP, где клиенты запрашивали у сервера определенный контент. Т.е. в майнинге HTTP управляется майнерами, запрашивающими новые задания для майнинга, доступные для серверов пула. Майнеры тратили время на эти запросы. Stratum позволил более эффективно управлять коммуникацией майнеров и пула.
Для каждого задания майнер может изменять поля ntime и nonce. Крупные майнеры перебирают все возможные значения двух полей в поисках решения. Если у майнера заканчиваются уникальные возможности перебора, он отправляет новый запрос. Новым и более быстрым майнерам сделать это проще. Stratum позволяет майнерам изменять еще несколько полей, что увеличивает общее число возможных решений для блока.
nonce-это 32-битное значение, которое корректируется постепенно и используется для повторного хэширования хэшированного блока до тех пор, пока хэш-выход не будет соответствовать текущим ограничениям уровня сложности сети, сигнализируя о том, что было найдено допустимое решение, и майнер может затем предложить свой блок остальной части сети.
nTime - это целочисленная временная метка (в секундах), включенная в заголовок блока. Rolling NTime-это способ для майнеров увеличить отметку времени локально в своем оборудовании, а не требовать каждый раз новый заголовок блока из своего пула, уменьшая объем передачи данных, которые должны происходить между пулами и майнерами.
Уже все наслышаны о v.2 протокола Stratum. Новая модификация протокола предназначена для улучшения совместной работы майнеров и пулов. И самое важно, версия 2.0. сделает добычу более децентрализованной.
Более подробно затрону Stratum при разборе v.2.0.
#Mining
Немного про повторное использование ключей
⬇️⬇️⬇️
Совершая транзакцию и отправитель и получатель раскрывают друг другу PublicKeys и PublicAddresses, которые используются в транзакции.
Если один и тот же PublicKey использовать повторно, например биткойн-адреса в качестве статических платежных адресов, то можно отследить пути расходования и получения, а также количество средств. А потом, как пример, спросить за эти полученные средства.
Но возможна и ситуация, когда использование каждого PublicKeys происходит лишь дважды - для получения платежа и для отправки платежа. Тогда пользователь вполне конфиденциален. Хоть и не настолько, насколько хотелось бы, особенно если у тебя действительно крупная сумма.
Для больше конфиденциальности, можно использовать методы микширования или сокрытия сумм и адресов, вроде СoinJoin и его имплементаций, о которых я уже писал ранее под тегом #Privacy.
Избегая потворное использование ключей, можно обеспечить защиту от атак, вроде "восстановление PrivateKey из PublicKey" или "сравнение сигнатур".
Во избежание атак по восстановлению PrivateKey из PublicKey используются уникальные адреса P2PKH и P2SH (вот тут писал о них). Они сохраняют PublicKeys ECDSA хэшированными, пока не произойдет первая трата, отправленных монет на этот адрес. Если способ восстановления PrivateKey не осуществим менее чем за час, то она бессмысленна.
Уникальные PrivateKeys защищают от атаки "сравнение сигнатур", генерируя одну подпись на каждый PrivateKey. Потому, атакующий не сможет получить последующую подпись для использования сравнения.
Стоит избегать повторного использования PublicKeys, а также повторного использования адресов. Если же вам нужно использовать фиксированный URI, то P2EP, который имеет все шансы скорое принятие, может вам с этим помочь, сохранив вашу приватность.
#Privacy
⬇️⬇️⬇️
Совершая транзакцию и отправитель и получатель раскрывают друг другу PublicKeys и PublicAddresses, которые используются в транзакции.
Если один и тот же PublicKey использовать повторно, например биткойн-адреса в качестве статических платежных адресов, то можно отследить пути расходования и получения, а также количество средств. А потом, как пример, спросить за эти полученные средства.
Но возможна и ситуация, когда использование каждого PublicKeys происходит лишь дважды - для получения платежа и для отправки платежа. Тогда пользователь вполне конфиденциален. Хоть и не настолько, насколько хотелось бы, особенно если у тебя действительно крупная сумма.
Для больше конфиденциальности, можно использовать методы микширования или сокрытия сумм и адресов, вроде СoinJoin и его имплементаций, о которых я уже писал ранее под тегом #Privacy.
Избегая потворное использование ключей, можно обеспечить защиту от атак, вроде "восстановление PrivateKey из PublicKey" или "сравнение сигнатур".
Во избежание атак по восстановлению PrivateKey из PublicKey используются уникальные адреса P2PKH и P2SH (вот тут писал о них). Они сохраняют PublicKeys ECDSA хэшированными, пока не произойдет первая трата, отправленных монет на этот адрес. Если способ восстановления PrivateKey не осуществим менее чем за час, то она бессмысленна.
Уникальные PrivateKeys защищают от атаки "сравнение сигнатур", генерируя одну подпись на каждый PrivateKey. Потому, атакующий не сможет получить последующую подпись для использования сравнения.
Стоит избегать повторного использования PublicKeys, а также повторного использования адресов. Если же вам нужно использовать фиксированный URI, то P2EP, который имеет все шансы скорое принятие, может вам с этим помочь, сохранив вашу приватность.
#Privacy
✅✅✅
Ivy - язык для написания смарт-контрактов Биткойн
Для стека биткоина
⬇️⬇️⬇️
О смарт-контрактах в сети Биткойн я уже писал не один раз:
- платформа RootStock
- смарт-контракты LN
- Musig
- Scriptless Scripts
- Язык Simplicity
- Язык MiniScript
-DAML
Теперь про еще один язык высокого уровня, позволяющий писать смарт-контракты для протокола Bitcoin - Ivy. Разработали язык в Chain (сайт ныне недоступен).
Как уже говорилось, писать смарт-контракты в сети Биткойн можно, но Bitcoin Script является низкоуровневым и ограниченным в функциональности. Bitcoin Script - это последовательность opcodes, выполняющихся по порядку. Bitcoin Script не является полным по Тьюрингу, а также не позволяет скриптам проверять другие входы или выходы в транзакции, а следовательно контракт не может контролировать поток стоимости.
Bitcoin-Script используется для создания Multisig-адресов, time-locked транзакций и платежных каналов. Ivy, как и другие альтернативные решения, создаются для облегчения написания и создания этих реализаций.
Ivy компилируется в Bitcoin Script и может использоваться для создания совместимых с Segwit адресов. Это язык более высокого уровня и обеспечивает выполнение произвольных комбинаций условий, такие как проверка подписей, временные блокировки и хэш-обязательства.
Ребята из Chain даже выпустили "Ivy Playground for Bitcoin" - площадку для опробования языка. Игровая площадка включает в себя предварительно загруженные шаблоны смарт-контрактов для биткойнов.
Платформа позволяет создавать и разблокировать фиктивные контракты, писать шаблоны контрактов и создавать экземпляры с параметрами для генерации адресов тестовых сетей Биткойн, создавать имитированные контракты и пытаться их тратить.
Что сейчас с этим проектом я, увы, не ведаю...Возможно, что альтернативные варианты оказались более востребованы. В любом случае, написание смарт-контрактов в сети Биткойн станет проще. Об этом говорит большое количество разработок и решений.
#SmartContracts
Ivy - язык для написания смарт-контрактов Биткойн
Для стека биткоина
⬇️⬇️⬇️
О смарт-контрактах в сети Биткойн я уже писал не один раз:
- платформа RootStock
- смарт-контракты LN
- Musig
- Scriptless Scripts
- Язык Simplicity
- Язык MiniScript
-DAML
Теперь про еще один язык высокого уровня, позволяющий писать смарт-контракты для протокола Bitcoin - Ivy. Разработали язык в Chain (сайт ныне недоступен).
Как уже говорилось, писать смарт-контракты в сети Биткойн можно, но Bitcoin Script является низкоуровневым и ограниченным в функциональности. Bitcoin Script - это последовательность opcodes, выполняющихся по порядку. Bitcoin Script не является полным по Тьюрингу, а также не позволяет скриптам проверять другие входы или выходы в транзакции, а следовательно контракт не может контролировать поток стоимости.
Bitcoin-Script используется для создания Multisig-адресов, time-locked транзакций и платежных каналов. Ivy, как и другие альтернативные решения, создаются для облегчения написания и создания этих реализаций.
Ivy компилируется в Bitcoin Script и может использоваться для создания совместимых с Segwit адресов. Это язык более высокого уровня и обеспечивает выполнение произвольных комбинаций условий, такие как проверка подписей, временные блокировки и хэш-обязательства.
Ребята из Chain даже выпустили "Ivy Playground for Bitcoin" - площадку для опробования языка. Игровая площадка включает в себя предварительно загруженные шаблоны смарт-контрактов для биткойнов.
Платформа позволяет создавать и разблокировать фиктивные контракты, писать шаблоны контрактов и создавать экземпляры с параметрами для генерации адресов тестовых сетей Биткойн, создавать имитированные контракты и пытаться их тратить.
Что сейчас с этим проектом я, увы, не ведаю...Возможно, что альтернативные варианты оказались более востребованы. В любом случае, написание смарт-контрактов в сети Биткойн станет проще. Об этом говорит большое количество разработок и решений.
#SmartContracts
✅✅✅
Cross-Input Aggregation - Агрегация перекрестного ввода
Для стека биткоина
⬇️⬇️⬇️
Так, так...нам снова придется вернуться к подписям Шнорра и затронуть MuSig.
Схема Шнорра — это протокол идентификации и метод агрегирования (суммирование) подписей, необходимых для транзакции BTC. Подписи Шнорра позволяют создавать подпись действительную для суммы PublicKeys. Несколько подписывающих лиц в транзакции-multisig, объединяют свои PublicKeys в агрегированный ключ.
Multisig-транзакции не поддерживаются ECDSA и потому реализуются при помощи смарт-контракта P2SH.
1) P2SH требуют знания PublicKeys все подписавшихся участников multisig, что не особо радует. Агрегирование этих ключей позволит обеспечить более эффективную проверку, т.к. придется проверить лишь один ключ, а не n-ключей.
2) Транзакции P2SH требуют адреса начинающихся с числа 3 (см. BIP 13). А это удар по конфиденциальности. Агрегирование ключей позволяет multisig выглядеть как обычная транзакция.
Прежде чем перейти к теме поста, еще затронем MuSig. Это новая схема мультиподписи на основе Шнорр. Агрегация ключей в MuSig позволяет создавать частные смарт-контракты за пределами блокчейна.
Итак, агрегация ключей это крутая плюшка для multisig-транзакций, которые тратят один вход. Но биткойн-транзакции чаще всего имеют больше одного входа?В будущем, подписи Шнорра могут быть использованы для создания интерактивной схемы агрегированной подписи (interactive aggregate signature - IAS).
IAS - расширяют схемы multisig, позволяя каждому подписавшему подписать свое сообщение и вместо подписей для каждого отдельного входа, можно использовать одну подпись, которая проверит все входы.
Теперь одна подпись может использоваться для траты всех входных данных транзакции. Каждый вход также будет иметь свой собственный PublicKey, но его можно будет использовать с помощью IAS Schnorr. Эту новую подпись можно очень легко проверить с помощью OPCHECKDLS, который является новым опкодом и будет введен в схему подписи Schnorr.
Taproot, который предназначается для увеличения гибкости смарт-контрактов, призван облегчить переход от агрегации ключей к агрегации перекрестного ввода (Cross-Input Aggregation).
Для каждой транзакции требуется более одной подписи - по одной на каждый вход. Агрегация подписей с перекрестным вводом обеспечивает экономию, за счет сокращения количества подписей на транзакцию до 1.
Комбинация данных ввода повышает конфиденциальность и освобождает пространство, которое ранее использовалось для размещения всех подписей на множестве разных входов.
Cross-input aggregation может улучшить транзакции CoinJoin. Решение вводит дополнительный механизм запутывания на уровне протокола. С его помощью можно построить основанные на Шнорр CJ-транзакции с n-подписями, которые выглядят как обычные транзакции с одной подписью. Проблемы с конфиденциальностью были разобраны мной в постах под тегом #Privacy.
Как уже писалось в посте про P2EP: "основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев".
P2EP обратно совместим, и при использовании в сочетании со Schnorr он может обеспечить достаточную конфиденциальность в базовом слое биткойна.
Cross-input aggregation имеет ряд проблем и не может быть внедрен по ряду причин. В любом случае, без внедрения подписей Шнорра, сделать это будет невозможно.
#PerfomanceAndUsability
Cross-Input Aggregation - Агрегация перекрестного ввода
Для стека биткоина
⬇️⬇️⬇️
Так, так...нам снова придется вернуться к подписям Шнорра и затронуть MuSig.
Схема Шнорра — это протокол идентификации и метод агрегирования (суммирование) подписей, необходимых для транзакции BTC. Подписи Шнорра позволяют создавать подпись действительную для суммы PublicKeys. Несколько подписывающих лиц в транзакции-multisig, объединяют свои PublicKeys в агрегированный ключ.
Multisig-транзакции не поддерживаются ECDSA и потому реализуются при помощи смарт-контракта P2SH.
1) P2SH требуют знания PublicKeys все подписавшихся участников multisig, что не особо радует. Агрегирование этих ключей позволит обеспечить более эффективную проверку, т.к. придется проверить лишь один ключ, а не n-ключей.
2) Транзакции P2SH требуют адреса начинающихся с числа 3 (см. BIP 13). А это удар по конфиденциальности. Агрегирование ключей позволяет multisig выглядеть как обычная транзакция.
Прежде чем перейти к теме поста, еще затронем MuSig. Это новая схема мультиподписи на основе Шнорр. Агрегация ключей в MuSig позволяет создавать частные смарт-контракты за пределами блокчейна.
Итак, агрегация ключей это крутая плюшка для multisig-транзакций, которые тратят один вход. Но биткойн-транзакции чаще всего имеют больше одного входа?В будущем, подписи Шнорра могут быть использованы для создания интерактивной схемы агрегированной подписи (interactive aggregate signature - IAS).
IAS - расширяют схемы multisig, позволяя каждому подписавшему подписать свое сообщение и вместо подписей для каждого отдельного входа, можно использовать одну подпись, которая проверит все входы.
Теперь одна подпись может использоваться для траты всех входных данных транзакции. Каждый вход также будет иметь свой собственный PublicKey, но его можно будет использовать с помощью IAS Schnorr. Эту новую подпись можно очень легко проверить с помощью OPCHECKDLS, который является новым опкодом и будет введен в схему подписи Schnorr.
Taproot, который предназначается для увеличения гибкости смарт-контрактов, призван облегчить переход от агрегации ключей к агрегации перекрестного ввода (Cross-Input Aggregation).
Для каждой транзакции требуется более одной подписи - по одной на каждый вход. Агрегация подписей с перекрестным вводом обеспечивает экономию, за счет сокращения количества подписей на транзакцию до 1.
Комбинация данных ввода повышает конфиденциальность и освобождает пространство, которое ранее использовалось для размещения всех подписей на множестве разных входов.
Cross-input aggregation может улучшить транзакции CoinJoin. Решение вводит дополнительный механизм запутывания на уровне протокола. С его помощью можно построить основанные на Шнорр CJ-транзакции с n-подписями, которые выглядят как обычные транзакции с одной подписью. Проблемы с конфиденциальностью были разобраны мной в постах под тегом #Privacy.
Как уже писалось в посте про P2EP: "основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев".
P2EP обратно совместим, и при использовании в сочетании со Schnorr он может обеспечить достаточную конфиденциальность в базовом слое биткойна.
Cross-input aggregation имеет ряд проблем и не может быть внедрен по ряду причин. В любом случае, без внедрения подписей Шнорра, сделать это будет невозможно.
#PerfomanceAndUsability
✅✅✅
Спецификация протокола Stratum V2
Для стека биткоина
⬇️⬇️⬇️
Предыдущие посты о протоколах майнинга: Stratum V1 и BetterHash. Stratum V2 - это объединение этих двух решений для повышения децентрализации майнинга.
Stratum V1, разработанный SlushPool 7 лет назад, используется почти всеми майнинговыми пулами. С ростом сети, изъяны, которые никуда не делись, стали представлять угрозу для экосистемы Биткойна:
Транзакции, входящие в блоки, не отправляются майнерам. Оператор пула решает какие из них будут включены в блок. Оператор пула отвечает за распределение вознаграждений. Так же оператор пула может заблокировать определенные обновления протокола, так как имеет возможность выбирать версию блока.
Майнинг в соло имеет проблему, связанную с неравномерным распределением наград. Если обратиться к статистике, то 3-4 пула, контролируют 50% хэшрейта сети и могут выбирать транзакции, которые будут включены в блоки.
Коротко о майнинге в пуле:
Майнер в пуле подключает свои вычислительные мощности к серверу пула, к которому подключены остальные майнеры пула. Каждый из них передает свои вычислительные мощности пулу и объединив их вместе, пул ищет блок транзакций. При успешном хэшировании, пул получает вознаграждение и делит между участниками сети.
Пул состоит из n-го количества майнеров и каждый пытается найти решение для блока. Майнеры запрашивают у оператора пула частичный “шаблон блока" (“block template”). Это неполный блок Биткойна, без доказательства работы. В процессе поиска майнеры отправляют свои решения (Share, Шары) оператору пула и тот проверяет правильность решения.
Новая версия позволит майнерам добывать собственные блоки, вместо предлагаемых пулом. Также Stratum V2 использует решение "Job Negotiation", дающее майнерам возможность выбирать транзакции включаемые в блоки. Вместо того чтобы оператор пула отправлял шаблон блока майнеру (“block template”), майнер отправляет шаблон блока оператору пула. Такое решение позволяет майнерам самим выбирать транзакции и версию блока.
Stratum V1 основан на JSON и не имеет криптографической аутентификации, что делает его более медленным, тяжелым и менее безопасным. Связь Stratum V2 осуществляется в двоичном коде.
Stratum V2 повышает передачу данных между майнерами, прокси-серверами и операторами пулов, что повышает пропускную способность сети.
\\\
Stratum V1 имеет проблемы с безопасностью, так как уязвима для атак MITM (Человек посередине), что позволяет перехватывать хэшрейт и присваивать награду третей стороне. Изображение
Такая атака возможна так как нет никакой криптографической аутентификации данных, для проверки того, что компьютер майнера действительно связан с компьютером оператора пула, и только с ним.
Новая версия протокола использует режим блочного шифрования - AEAD для устранения этой уязвимости. Операторы пула криптографически подписывают шаблоны частичных блоков. Если майнер знает открытый ключ оператора пула, он может проверить, что шаблон частичного блока поставляется с действительной подписью и, следовательно, действительно предоставляется оператором.
Еще больше об изменениях в протоколе здесь
stratumprotocol.org
Video about Stratum V2 by ChicoCrypto
#Mining
Спецификация протокола Stratum V2
Для стека биткоина
⬇️⬇️⬇️
Предыдущие посты о протоколах майнинга: Stratum V1 и BetterHash. Stratum V2 - это объединение этих двух решений для повышения децентрализации майнинга.
Stratum V1, разработанный SlushPool 7 лет назад, используется почти всеми майнинговыми пулами. С ростом сети, изъяны, которые никуда не делись, стали представлять угрозу для экосистемы Биткойна:
Транзакции, входящие в блоки, не отправляются майнерам. Оператор пула решает какие из них будут включены в блок. Оператор пула отвечает за распределение вознаграждений. Так же оператор пула может заблокировать определенные обновления протокола, так как имеет возможность выбирать версию блока.
Майнинг в соло имеет проблему, связанную с неравномерным распределением наград. Если обратиться к статистике, то 3-4 пула, контролируют 50% хэшрейта сети и могут выбирать транзакции, которые будут включены в блоки.
Коротко о майнинге в пуле:
Майнер в пуле подключает свои вычислительные мощности к серверу пула, к которому подключены остальные майнеры пула. Каждый из них передает свои вычислительные мощности пулу и объединив их вместе, пул ищет блок транзакций. При успешном хэшировании, пул получает вознаграждение и делит между участниками сети.
Пул состоит из n-го количества майнеров и каждый пытается найти решение для блока. Майнеры запрашивают у оператора пула частичный “шаблон блока" (“block template”). Это неполный блок Биткойна, без доказательства работы. В процессе поиска майнеры отправляют свои решения (Share, Шары) оператору пула и тот проверяет правильность решения.
Новая версия позволит майнерам добывать собственные блоки, вместо предлагаемых пулом. Также Stratum V2 использует решение "Job Negotiation", дающее майнерам возможность выбирать транзакции включаемые в блоки. Вместо того чтобы оператор пула отправлял шаблон блока майнеру (“block template”), майнер отправляет шаблон блока оператору пула. Такое решение позволяет майнерам самим выбирать транзакции и версию блока.
Stratum V1 основан на JSON и не имеет криптографической аутентификации, что делает его более медленным, тяжелым и менее безопасным. Связь Stratum V2 осуществляется в двоичном коде.
Stratum V2 повышает передачу данных между майнерами, прокси-серверами и операторами пулов, что повышает пропускную способность сети.
\\\
Stratum V1 имеет проблемы с безопасностью, так как уязвима для атак MITM (Человек посередине), что позволяет перехватывать хэшрейт и присваивать награду третей стороне. Изображение
Такая атака возможна так как нет никакой криптографической аутентификации данных, для проверки того, что компьютер майнера действительно связан с компьютером оператора пула, и только с ним.
Новая версия протокола использует режим блочного шифрования - AEAD для устранения этой уязвимости. Операторы пула криптографически подписывают шаблоны частичных блоков. Если майнер знает открытый ключ оператора пула, он может проверить, что шаблон частичного блока поставляется с действительной подписью и, следовательно, действительно предоставляется оператором.
Еще больше об изменениях в протоколе здесь
stratumprotocol.org
Video about Stratum V2 by ChicoCrypto
#Mining
✅✅✅
Value Shuffle - протокол микширования на базе CoinJoin
Для стека биткоина
Продолжая говорить о конфиденциальности, повторю, одно из основных свойств Биткойна, это его взаимозаменяемость. Актуально, исходя из новостей про ETHProtect в Etherscan, позволяющий отслеживать скомпрометированные монеты, а также о сервисах анализа блокчейна Биткойн. Итог: две одинаковые монеты - не равны.
Проблема тут в улучшениях для повышения конфиденциальности, т.к. такие решения либо направляют свой фокус на решение одного аспекта конфиденциальности, либо требуют серьезных изменений функционала в коде Биткойна.
Value Shuffle - это протокол микширования монет на базе CoinJoin, реализуемый при помощи Confidential Transaction и Stealth Addresses.
В своей статье ниже, и о протоколе Value Shuffle, и небольшой итог моих исследований под тегом #Privacy. На этом я не остановлюсь и мы дальше продолжим знакомиться с протоколами конфиденциальности.
⬇️⬇️⬇️
https://teletype.in/@russiano55/ValueShuffleforBitcoin
#Privacy
Value Shuffle - протокол микширования на базе CoinJoin
Для стека биткоина
Продолжая говорить о конфиденциальности, повторю, одно из основных свойств Биткойна, это его взаимозаменяемость. Актуально, исходя из новостей про ETHProtect в Etherscan, позволяющий отслеживать скомпрометированные монеты, а также о сервисах анализа блокчейна Биткойн. Итог: две одинаковые монеты - не равны.
Проблема тут в улучшениях для повышения конфиденциальности, т.к. такие решения либо направляют свой фокус на решение одного аспекта конфиденциальности, либо требуют серьезных изменений функционала в коде Биткойна.
Value Shuffle - это протокол микширования монет на базе CoinJoin, реализуемый при помощи Confidential Transaction и Stealth Addresses.
В своей статье ниже, и о протоколе Value Shuffle, и небольшой итог моих исследований под тегом #Privacy. На этом я не остановлюсь и мы дальше продолжим знакомиться с протоколами конфиденциальности.
⬇️⬇️⬇️
https://teletype.in/@russiano55/ValueShuffleforBitcoin
#Privacy
Telegram
CryptoBotan
✅✅✅
Технологический стек биткоина (Update)
Несколько месяцев работы в этом посте. Как итог: визуализация масштабов экосистемы Биткойна и работы над ней.
Добавил от себя некоторые решения. Внутри ссылки на проекты и протоколы, статьи и посты из других…
Технологический стек биткоина (Update)
Несколько месяцев работы в этом посте. Как итог: визуализация масштабов экосистемы Биткойна и работы над ней.
Добавил от себя некоторые решения. Внутри ссылки на проекты и протоколы, статьи и посты из других…
✅✅✅
Платформа RootStock или RSK
Для стека биткоина
⬇️⬇️⬇️
Часть.1 Внедрение смарт-контрактов для сети биткоина
Часть.2 Принцип работы
Мост между сетью BTC и ETH от компании RSK
#Sidechains
Платформа RootStock или RSK
Для стека биткоина
⬇️⬇️⬇️
Часть.1 Внедрение смарт-контрактов для сети биткоина
Часть.2 Принцип работы
Мост между сетью BTC и ETH от компании RSK
#Sidechains
Forwarded from CryptoBotan
✅✅✅
Identity
Для стека биткоина
Часть.1
⬇️⬇️⬇️
Поговорим просто о технологии такой, какая она есть и как может применяться
Всякий раз, когда мы должны идентифицировать себя, мы вынуждены предоставлять информацию, чтобы доказать, что мы те, за кого себя выдаём.
Примером является Эстония, лидер во внедрении технологии цифровой идентификации. Это первая страна, где каждый гражданин получил цифровую идентичность.
У них это выглядит как карта с чипом. С ее помощью они могут подписывать официальные документы.
Каждый человек для общения в Интернете или обмена данными с другими пользователями может создать себе «личный идентификатор» (ID, никнейм) и «цифровую подпись», подтверждающее подлинность автора.
Электронная цифровая подпись- это зашифрованный файл, который содержит информацию о владельце подписи и документах связанных с ним.
ЭЦП дает возможность проверить отсутствие искажения информации в электронном документе с момента формирования подписи (целостность), принадлежность подписи владельцу сертификата ключа подписи (авторство), а в случае успешной проверки подтвердить факт подписания электронного документа (неотказуемость).
Электронная подпись позволяет:
1) Подтвердить авторство отправителя сообщения
2) Гарантировать, что отправленное и подтвержденное через ЭП сообщение никто не сможет подделать.
Проекты разрабатывающие продукты в области идентификации:
Civic
Включает в себя три взаимозависимых объекта: пользователей, валидаторов и поставщиков услуг.
Пользователи — это все, кто хочет использовать протокол для регистрации личности.
Валидаторы - отвечают за проверку подлинности личности.
Затем валидаторы могут продавать эту информацию поставщикам услуг, которым необходимо подтвердить личности своих клиентов, обмениваясь данными для CVC.
Civic построен на блокчейне Ethereum и использует интеллектуальные контракты для контроля аттестации данных и выплат за эту работу.
BlockVerify
Цель платформы — предоставлять те же услуги, что и государственные органы, но в децентрализованной и добровольной манере, независимо от географической привязки. Они разработали идентификационное решение, которое на данный момент включает в себя блокчейн-паспорт и свидетельство о браке.
Blockstack
Предоставляет децентрализованные DNS, децентрализованную систему распределения публичных ключей и реестр для приложений и пользовательских идентичностей. Персональный пользовательский API поставляется вместе с приложением Blockstack и работает с самыми разными сущностями: от идентичности и аутентификации до хранения данных.
Мои прошлые посты на эту тему:
DID - Decentralized Identity
Идентификационные модели и их виды
IBM Crypto Anchor Verifier - технология идентификации
Ещё списочек проектов, платформ и решений
1) BlockAuth
2) Cambridge Blockchain LLC
3) Evernym
4) Guardtime's BLT
#Layer2
Identity
Для стека биткоина
Часть.1
⬇️⬇️⬇️
Поговорим просто о технологии такой, какая она есть и как может применяться
Всякий раз, когда мы должны идентифицировать себя, мы вынуждены предоставлять информацию, чтобы доказать, что мы те, за кого себя выдаём.
Примером является Эстония, лидер во внедрении технологии цифровой идентификации. Это первая страна, где каждый гражданин получил цифровую идентичность.
У них это выглядит как карта с чипом. С ее помощью они могут подписывать официальные документы.
Каждый человек для общения в Интернете или обмена данными с другими пользователями может создать себе «личный идентификатор» (ID, никнейм) и «цифровую подпись», подтверждающее подлинность автора.
Электронная цифровая подпись- это зашифрованный файл, который содержит информацию о владельце подписи и документах связанных с ним.
ЭЦП дает возможность проверить отсутствие искажения информации в электронном документе с момента формирования подписи (целостность), принадлежность подписи владельцу сертификата ключа подписи (авторство), а в случае успешной проверки подтвердить факт подписания электронного документа (неотказуемость).
Электронная подпись позволяет:
1) Подтвердить авторство отправителя сообщения
2) Гарантировать, что отправленное и подтвержденное через ЭП сообщение никто не сможет подделать.
Проекты разрабатывающие продукты в области идентификации:
Civic
Включает в себя три взаимозависимых объекта: пользователей, валидаторов и поставщиков услуг.
Пользователи — это все, кто хочет использовать протокол для регистрации личности.
Валидаторы - отвечают за проверку подлинности личности.
Затем валидаторы могут продавать эту информацию поставщикам услуг, которым необходимо подтвердить личности своих клиентов, обмениваясь данными для CVC.
Civic построен на блокчейне Ethereum и использует интеллектуальные контракты для контроля аттестации данных и выплат за эту работу.
BlockVerify
Цель платформы — предоставлять те же услуги, что и государственные органы, но в децентрализованной и добровольной манере, независимо от географической привязки. Они разработали идентификационное решение, которое на данный момент включает в себя блокчейн-паспорт и свидетельство о браке.
Blockstack
Предоставляет децентрализованные DNS, децентрализованную систему распределения публичных ключей и реестр для приложений и пользовательских идентичностей. Персональный пользовательский API поставляется вместе с приложением Blockstack и работает с самыми разными сущностями: от идентичности и аутентификации до хранения данных.
Мои прошлые посты на эту тему:
DID - Decentralized Identity
Идентификационные модели и их виды
IBM Crypto Anchor Verifier - технология идентификации
Ещё списочек проектов, платформ и решений
1) BlockAuth
2) Cambridge Blockchain LLC
3) Evernym
4) Guardtime's BLT
#Layer2
✅✅✅
Identity
Для стека биткоина
Часть.2
⬇️⬇️⬇️
В этой части, расскажу о решениях которые были предложены еще в далеких 2014-2016 годах. Судьба этих предложений мне неизвестна, но судя по отсутствию информации в интернете, в сети Биткойн все заняты решением других проблем.
///
Onename
Onename - это поставщик протоколов с открытым исходным кодом, по созданию безопасных и надежных идентификаторов в сети, разработанный в 2014 году.
Это децентрализованная система идентификации, в которой пользователи регистрируются и поддерживают блокчейн-идентификатор, которым можно делиться на своих веб-сайтах, профилях в социальных сетях. Разработчики могли реализовать свою технологию для создания входа без пароля с использованием выданных блокчейн-идентификаторов, предоставляя пользователям детальный контроль над их конфиденциальностью и доступом к данным. Первым шагом была замена биткойн-адреса оплаты на более удобные запросы на оплату.
Физические лица регистрировали имя и владеющий им открытый ключ. При условии, что они первыми зарегистрируют это имя, они могли произвольно обновлять связанные значения, подписывая их зарегистрированным ключом.
Протокол был построен поверх протокола NameCoin. В 2015 году платформа переключилась с блокчейна Namecoin на Bitcoin в связи с доминацией F2POOL над сетью. Дальнейшая судьба неизвестна.
///
Identity protocol (bitcoinwiki)
Целью создания протокола является полностью децентрализованная, анонимная, безопасная идентификация.
SIN (Secure Identity Number) - это уникальный идентификатор записи, с помощью которого идентификационные данные могут стать известны. Он позволяет доказывать права собственности, прикреплять публичные доказательства (последовательность пар key-value) и частные доказательства (хэши) к записи SIN. “Master public key” образует корень цифрового доверия. Пользователи децентрализованного рынка в цифровом виде подписывают SIN друг друга, создавая тем самым децентрализованную репутацию друг друга.
///
Decentralized Anonymous Credentials (DAC)
Децентрализованная выдача учетных данных. Это новая схема анонимных учетных данных, которая устраняет необходимость в доверенном эмитенте учетных данных.
Заявляя о себе, что я это я, организации и центры сертификации, службы поддержки DNS и провайдеры входа в систему, вроде Google, предоставляют наши учетные данные, для проверки, что это действительно вы.
Работа над протоколом, базировалась на DAA (Direct Anonymous Attestation - "прямая анонимная аттестация"). DAA расширяет стандартные возможности аттестации позволяя проводить анонимные аттестации и принимать псевдонимы, которые криптографически привязаны к внутреннему сертификату идентификации. DAA имеют некоторые ограничения. Они используют слепые подписи и поэтому требуют назначения центральной, доверенной стороны для выдачи учетных данных. Этот эмитент представляет собой единственную точку отказа.
Решение DAC может управляться специальной группой недоверчивых участников и расширять схему учетных данных для создания обновляемых анонимных учетных данных, в которых пользователи получают новые учетные данные на основе изменения свойств своей личности. Все что для этого нужно - это распределенная система.
Возможность устанавливать удостоверения и привязывать их к открытому ключу гарантирует, что пользователи могут утверждать свою личность не анонимным способом, просто выдавая подписи из соответствующего секретного ключа.
Чтобы выдать новые учетные данные, пользователь устанавливает личность и связанные с ней атрибуты. Система присоединяет специальное обязательство к PrivateKey вместе со строками идентификатора и атрибута, содержащимися в ее утверждении идентичности. Система включает в себя неинтерактивное доказательство того, что учетные данные правильно сконструированы, т.е. что атрибуты в обязательстве соответствуют тем, которые раскрываются в утверждении идентичности. Сеть примет утверждение идентичности только тогда, когда это утверждение считается правильным и прилагаемое доказательство является действительным.
Ссылка на документацию
#Layer2
Identity
Для стека биткоина
Часть.2
⬇️⬇️⬇️
В этой части, расскажу о решениях которые были предложены еще в далеких 2014-2016 годах. Судьба этих предложений мне неизвестна, но судя по отсутствию информации в интернете, в сети Биткойн все заняты решением других проблем.
///
Onename
Onename - это поставщик протоколов с открытым исходным кодом, по созданию безопасных и надежных идентификаторов в сети, разработанный в 2014 году.
Это децентрализованная система идентификации, в которой пользователи регистрируются и поддерживают блокчейн-идентификатор, которым можно делиться на своих веб-сайтах, профилях в социальных сетях. Разработчики могли реализовать свою технологию для создания входа без пароля с использованием выданных блокчейн-идентификаторов, предоставляя пользователям детальный контроль над их конфиденциальностью и доступом к данным. Первым шагом была замена биткойн-адреса оплаты на более удобные запросы на оплату.
Физические лица регистрировали имя и владеющий им открытый ключ. При условии, что они первыми зарегистрируют это имя, они могли произвольно обновлять связанные значения, подписывая их зарегистрированным ключом.
Протокол был построен поверх протокола NameCoin. В 2015 году платформа переключилась с блокчейна Namecoin на Bitcoin в связи с доминацией F2POOL над сетью. Дальнейшая судьба неизвестна.
///
Identity protocol (bitcoinwiki)
Целью создания протокола является полностью децентрализованная, анонимная, безопасная идентификация.
SIN (Secure Identity Number) - это уникальный идентификатор записи, с помощью которого идентификационные данные могут стать известны. Он позволяет доказывать права собственности, прикреплять публичные доказательства (последовательность пар key-value) и частные доказательства (хэши) к записи SIN. “Master public key” образует корень цифрового доверия. Пользователи децентрализованного рынка в цифровом виде подписывают SIN друг друга, создавая тем самым децентрализованную репутацию друг друга.
///
Decentralized Anonymous Credentials (DAC)
Децентрализованная выдача учетных данных. Это новая схема анонимных учетных данных, которая устраняет необходимость в доверенном эмитенте учетных данных.
Заявляя о себе, что я это я, организации и центры сертификации, службы поддержки DNS и провайдеры входа в систему, вроде Google, предоставляют наши учетные данные, для проверки, что это действительно вы.
Работа над протоколом, базировалась на DAA (Direct Anonymous Attestation - "прямая анонимная аттестация"). DAA расширяет стандартные возможности аттестации позволяя проводить анонимные аттестации и принимать псевдонимы, которые криптографически привязаны к внутреннему сертификату идентификации. DAA имеют некоторые ограничения. Они используют слепые подписи и поэтому требуют назначения центральной, доверенной стороны для выдачи учетных данных. Этот эмитент представляет собой единственную точку отказа.
Решение DAC может управляться специальной группой недоверчивых участников и расширять схему учетных данных для создания обновляемых анонимных учетных данных, в которых пользователи получают новые учетные данные на основе изменения свойств своей личности. Все что для этого нужно - это распределенная система.
Возможность устанавливать удостоверения и привязывать их к открытому ключу гарантирует, что пользователи могут утверждать свою личность не анонимным способом, просто выдавая подписи из соответствующего секретного ключа.
Чтобы выдать новые учетные данные, пользователь устанавливает личность и связанные с ней атрибуты. Система присоединяет специальное обязательство к PrivateKey вместе со строками идентификатора и атрибута, содержащимися в ее утверждении идентичности. Система включает в себя неинтерактивное доказательство того, что учетные данные правильно сконструированы, т.е. что атрибуты в обязательстве соответствуют тем, которые раскрываются в утверждении идентичности. Сеть примет утверждение идентичности только тогда, когда это утверждение считается правильным и прилагаемое доказательство является действительным.
Ссылка на документацию
#Layer2
