В связи с началом активной фазы активации Taproot и практической ее поддержкой майнерами , решил немного оживить эту тему обсуждением того, что же принесет обычным пользователям это обновление битка. Из того что я знаю основные изменения должны почувствовать те пользователи ( я к ним пока не отношусь, но все может измениться), которые используют мультиподписи в своих транзакциях.
Две основные фишки, для пользователей, которые начнут использовать P2TR скрипт:
1) маскирование multysig транзакции под обычную транзакцию, подписанную одиночным приватным ключом, и следовательно улучшение конфиденциальности транзакции.
2) снижение стоимости multysig транзакции, за счет уменьшения ее размера.
Topic: Технологический стек Биткоина (Read 1632 times)
Две основные фишки, для пользователей, которые начнут использовать P2TR скрипт:
1) маскирование multysig транзакции под обычную транзакцию, подписанную одиночным приватным ключом, и следовательно улучшение конфиденциальности транзакции.
2) снижение стоимости multysig транзакции, за счет уменьшения ее размера.
1) маскирование multysig транзакции под обычную транзакцию, подписанную одиночным приватным ключом, и следовательно улучшение конфиденциальности транзакции.
2) снижение стоимости multysig транзакции, за счет уменьшения ее размера.
Здесь так же фигня что и с любой "анонимностью": Главное количество пользователей.
Как я понял, multisig транзакции не обязательно маскирировать, останется P2SH в классическом виде. А это уже не ок, так как кто будет себя нагружать лишним скриптом если можно по старинке?
Всё хотел найти время, чтобы продолжить публиковать материал из канала, дабы очень интересное чтиво выкладывалось тут, но, перейдя на канал, увидел вот такую грустную новость:
Новость увидел, а откуда она не прочитал. Это был перепост с Гфшитинголд-а. Сам КриптоБотан вроде бы живой (но канал он как я понял забросил). На канале последний пост 10 апреля, а админ ГфШита - Исаак умер еще в марте (RIP). Админ Криптоботана после 10 апреля также менял свою аватарку в ТГ аккаунте, с чего я делаю вывод что он живой просто по каким то причинам передумал вести канал.
CoinJoinXT
Напомню, CoinJoin предлагает возможность предоставлять входные данные для транзакций, для невозможности определения владения или контроля над выходными данными. Как уже давно всем известно, классический CJ имеет ряд недостатков и упущений:
- если все участники CoinJoin не используют равные суммы, то можно определить какие входы, оплачивают выходы
- наблюдатель может определить, что это CoinJoin-транзакция, а следовательно, нарушается принцип взаимозаменяемости.
Анализ блокчейна подразумевает вероятностные предположения - эвристику. Подробнее в разделе “Блокчейн-атаки на приватность” (https://t.me/bitcoin_translated/286) на канале @bitcoin_translated
Эвристика 1 - все входные данные для транзакции принадлежат одной и той же стороне.
Эвристика 2-одноразовые адреса изменения принадлежат той же стороне, что и входные данные.
Также существует еще одна эвристика: "передача права собственности между сторонами в одной сделке подразумевает передачу права собственности"😐 Но я тоже не сразу въехал и об этом позже.
Adam Gibson, один из разработчиков JoinMarket, называет CoinJoin моделью "внутренней взаимозаменяемости", хоть и создаваемая транзакция распознается как CoinJoin, невозможно различить выходы, так как они равны. Также он предлагает модель "отрицания", где транзакции взаимозаменяемы, но выглядят как обычные платежи. Такой способ он назвал CoinJoinXT.
CoinJoinXT - это метод повышения приватности не связанный с хранением данных и связанный с CoinJoin. Принцип работы основан на создании графов декларируемых траназкций или просто графов транзакций (proposed transaction graph, PTG).
PTG представляет собой цепочку (дерево транзакций), где каждый TX имеет F (транзакцию финансирования) в качестве предка и один вход зависящий от F. В PTG биткоины, принадлежащие определенным лицам, отправляются от одной стороны другой во всех транзакциях, и в итоге возвращаются их законным владельцам. Система устроена так, что процесс PTG является атомарным. Либо весь PTG подтверждается в блокчейне, либо ни одна из транзакций. Это не дает возможности участвующим сторонам украсть средства.PTG может содержать любой список транзакций, который усложняет граф транзакций.
Для CoinJoinXT требуется, чтобы все транзакции в PTG были только segwit. Segwit позволяет предварительно подписывать не только отдельные транзакции, но и цепочки транзакций.
Модель использующаяся в CJTX
Две стороны отправляют BTC на выход 2-of-2 multisig (транзакция финансирования). Не подписывая эту транзакцию, они создают другую транзакцию time-locked и тратят 2-of-2 multisig на третий счет (транзакция расходов). Они подписывают сделку о расходах и обмениваются подписями. Затем подписывают и фиксируют транзакцию финансирования в блокчейне. Транзакция расходов будет подтверждена после истечения времени блокировки (lock-time) и в соответствии с контрактом транзакция финансирования будет реализована.
В CoinJoin две и более сторон вносят свои UTXOs в одну транзакцию. При помощи CoinJoinXT стороны делают то же самое с транзакцией финансирования, но предварительно подписывая набор из более чем одной транзакции расходов. Схема ниже.
A 1btc --->
F (2,2,A,B) --+
Б 1btc --->|
+-->(PTG)->TX1->TX2->TX3 ..
Можно создавать транзакции, используя предложенный график транзакций, но производить платежи по отдельности А или Б, тем самым нарушая эвристику о передачи прав собственности (1часть (https://t.me/CryptoBotan/1013)). Транзакция может платить А, но это может и не быть платеж. Это и есть модель отрицания.
Однако, такая конструкция ограничена, потому что все начинается с одной транзакции. Даже если это дерево, а не цепочка, все еще остается одна уникальная точка входа в блокчейн.
Статья by Adam Gibson (https://joinmarket.me/blog/blog/coinjoinxt/)
Более тезисно о CoinJoinXT (https://diyhpl.us/wiki/transcripts/building-on-bitcoin/2018/coinjoinxt/)
Напомню, CoinJoin предлагает возможность предоставлять входные данные для транзакций, для невозможности определения владения или контроля над выходными данными. Как уже давно всем известно, классический CJ имеет ряд недостатков и упущений:
- если все участники CoinJoin не используют равные суммы, то можно определить какие входы, оплачивают выходы
- наблюдатель может определить, что это CoinJoin-транзакция, а следовательно, нарушается принцип взаимозаменяемости.
Анализ блокчейна подразумевает вероятностные предположения - эвристику. Подробнее в разделе “Блокчейн-атаки на приватность” (https://t.me/bitcoin_translated/286) на канале @bitcoin_translated
Эвристика 1 - все входные данные для транзакции принадлежат одной и той же стороне.
Эвристика 2-одноразовые адреса изменения принадлежат той же стороне, что и входные данные.
Также существует еще одна эвристика: "передача права собственности между сторонами в одной сделке подразумевает передачу права собственности"😐 Но я тоже не сразу въехал и об этом позже.
Adam Gibson, один из разработчиков JoinMarket, называет CoinJoin моделью "внутренней взаимозаменяемости", хоть и создаваемая транзакция распознается как CoinJoin, невозможно различить выходы, так как они равны. Также он предлагает модель "отрицания", где транзакции взаимозаменяемы, но выглядят как обычные платежи. Такой способ он назвал CoinJoinXT.
CoinJoinXT - это метод повышения приватности не связанный с хранением данных и связанный с CoinJoin. Принцип работы основан на создании графов декларируемых траназкций или просто графов транзакций (proposed transaction graph, PTG).
PTG представляет собой цепочку (дерево транзакций), где каждый TX имеет F (транзакцию финансирования) в качестве предка и один вход зависящий от F. В PTG биткоины, принадлежащие определенным лицам, отправляются от одной стороны другой во всех транзакциях, и в итоге возвращаются их законным владельцам. Система устроена так, что процесс PTG является атомарным. Либо весь PTG подтверждается в блокчейне, либо ни одна из транзакций. Это не дает возможности участвующим сторонам украсть средства.PTG может содержать любой список транзакций, который усложняет граф транзакций.
Для CoinJoinXT требуется, чтобы все транзакции в PTG были только segwit. Segwit позволяет предварительно подписывать не только отдельные транзакции, но и цепочки транзакций.
Модель использующаяся в CJTX
Две стороны отправляют BTC на выход 2-of-2 multisig (транзакция финансирования). Не подписывая эту транзакцию, они создают другую транзакцию time-locked и тратят 2-of-2 multisig на третий счет (транзакция расходов). Они подписывают сделку о расходах и обмениваются подписями. Затем подписывают и фиксируют транзакцию финансирования в блокчейне. Транзакция расходов будет подтверждена после истечения времени блокировки (lock-time) и в соответствии с контрактом транзакция финансирования будет реализована.
В CoinJoin две и более сторон вносят свои UTXOs в одну транзакцию. При помощи CoinJoinXT стороны делают то же самое с транзакцией финансирования, но предварительно подписывая набор из более чем одной транзакции расходов. Схема ниже.
A 1btc --->
F (2,2,A,B) --+
Б 1btc --->|
+-->(PTG)->TX1->TX2->TX3 ..
Можно создавать транзакции, используя предложенный график транзакций, но производить платежи по отдельности А или Б, тем самым нарушая эвристику о передачи прав собственности (1часть (https://t.me/CryptoBotan/1013)). Транзакция может платить А, но это может и не быть платеж. Это и есть модель отрицания.
Однако, такая конструкция ограничена, потому что все начинается с одной транзакции. Даже если это дерево, а не цепочка, все еще остается одна уникальная точка входа в блокчейн.
Статья by Adam Gibson (https://joinmarket.me/blog/blog/coinjoinxt/)
Более тезисно о CoinJoinXT (https://diyhpl.us/wiki/transcripts/building-on-bitcoin/2018/coinjoinxt/)
Не знаете случайно, что-нибудь аналогичное ETHprotect есть для битка? Я не говорю о платных сервисах, а именно о бесплатном, который бы позволил показать есть у тебя в наличии скомпрометированные монеты. Проблема видно будет с каждым днем усугубляться так как появляется все больше и больше скумузденных монет и можно невзначай нарваться самому.
https://traceer.co/ru/ - тут вроде можно проверить поштучно. (1 проверка - 1$) Но это не точно...
Не знаете случайно, что-нибудь аналогичное ETHprotect есть для битка? Я не говорю о платных сервисах, а именно о бесплатном, который бы позволил показать есть у тебя в наличии скомпрометированные монеты. Проблема видно будет с каждым днем усугубляться так как появляется все больше и больше скумузденных монет и можно невзначай нарваться самому.
Я так понимаю скомпрометированные монеты можно получить только через крипто-обменники, через DEX биржи или при покупке напрямую у физлица? При выводе монет с централизованной биржи проблемных монет быть не должно. Раньше я об этом даже не задумывался, но видимо пора.
Value Shuffle - протокол микширования на базе CoinJoin
Для стека биткоина (https://t.me/CryptoBotan/888)
Продолжая говорить о конфиденциальности, повторю, одно из основных свойств Биткойна, это его взаимозаменяемость. Актуально, исходя из новостей (https://t.me/PrimeBlock/3641) про ETHProtect в Etherscan, позволяющий отслеживать скомпрометированные монеты, а также о сервисах (https://t.me/CryptoBotan/744) анализа блокчейна Биткойн. Итог: две одинаковые монеты - не равны.
Проблема тут в улучшениях для повышения конфиденциальности, т.к. такие решения либо направляют свой фокус на решение одного аспекта конфиденциальности, либо требуют серьезных изменений функционала в коде Биткойна.
Value Shuffle - это протокол микширования монет на базе CoinJoin (https://t.me/CryptoBotan/584), реализуемый при помощи Confidential Transaction (https://t.me/CryptoBotan/987) и Stealth Addresses (https://t.me/CryptoBotan/584).
В своей статье ниже, и о протоколе Value Shuffle, и небольшой итог моих исследований под тегом #Privacy. На этом я не остановлюсь и мы дальше продолжим знакомиться с протоколами конфиденциальности.
https://teletype.in/@russiano55/DVXdGQIua (https://teletype.in/@russiano55/DVXdGQIua)
Для стека биткоина (https://t.me/CryptoBotan/888)
Продолжая говорить о конфиденциальности, повторю, одно из основных свойств Биткойна, это его взаимозаменяемость. Актуально, исходя из новостей (https://t.me/PrimeBlock/3641) про ETHProtect в Etherscan, позволяющий отслеживать скомпрометированные монеты, а также о сервисах (https://t.me/CryptoBotan/744) анализа блокчейна Биткойн. Итог: две одинаковые монеты - не равны.
Проблема тут в улучшениях для повышения конфиденциальности, т.к. такие решения либо направляют свой фокус на решение одного аспекта конфиденциальности, либо требуют серьезных изменений функционала в коде Биткойна.
Value Shuffle - это протокол микширования монет на базе CoinJoin (https://t.me/CryptoBotan/584), реализуемый при помощи Confidential Transaction (https://t.me/CryptoBotan/987) и Stealth Addresses (https://t.me/CryptoBotan/584).
В своей статье ниже, и о протоколе Value Shuffle, и небольшой итог моих исследований под тегом #Privacy. На этом я не остановлюсь и мы дальше продолжим знакомиться с протоколами конфиденциальности.
https://teletype.in/@russiano55/DVXdGQIua (https://teletype.in/@russiano55/DVXdGQIua)
~
Cross-Input Aggregation - Гибридная агрегация
Сюда бы еще Craftroot добавить, который позволит уменьшить "вес" скриптов навешанных Таproot. Ждем появления нового типа адресов?
Мне только одному кажется, что после Shnorr, Taproot и Craftroot о таком явлении как Monero забудут? Роль то монеры сильно преувеличена и даже сейчас до всех ожидаемых улучшений 85% даркнета юзает биток.
Добавил линки на обзоры Kartoffan-а в раздел Обзоры каталога.
Буду еще дополнения делать к стеку, если есть предложения и проекты выстраивающиеся в стеке, предлагайте...обязательно напишу. Монеро уже топят...так, что шнорр и составляющие только забьют последний гвоздь, если и останется существовать, то только среди ограниченного круга лиц с небольшой ликвидностью. За добавление в обзоры - благодарствую)
Cross-Input Aggregation - Агрегация перекрестного ввода
Для стека биткоина (https://t.me/CryptoBotan/888)
Так, так...нам снова придется вернуться к подписям Шнорра (https://t.me/CryptoBotan/702) и затронуть MuSig (https://t.me/CryptoBotan/936).
Схема Шнорра — это протокол идентификации и метод агрегирования (суммирование) подписей, необходимых для транзакции BTC. Подписи Шнорра позволяют создавать подпись действительную для суммы PublicKeys. Несколько подписывающих лиц в транзакции-multisig, объединяют свои PublicKeys в агрегированный ключ. Multisig-транзакции не поддерживаются ECDSA (https://t.me/CryptoBotan/824) и потому реализуются при помощи смарт-контракта P2SH (https://t.me/CryptoBotan/715).
1) P2SH требуют знания PublicKeys все подписавшихся участников multisig, что не особо радует. Агрегирование этих ключей позволит обеспечить более эффективную проверку, т.к. придется проверить лишь один ключ, а не n-ключей.
2) Транзакции P2SH требуют адреса начинающихся с числа 3 (см. BIP 13 (https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki)). А это удар по конфиденциальности. Агрегирование ключей позволяет multisig выглядеть как обычная транзакция.
Прежде чем перейти к теме поста, еще затронем MuSig. Это новая схема мультиподписи на основе Шнорр. Агрегация ключей в MuSig позволяет создавать частные смарт-контракты за пределами блокчейна. Итак, агрегация ключей это крутая плюшка для multisig-транзакций, которые тратят один вход. Но биткойн-транзакции чаще всего имеют больше одного входа?В будущем, подписи Шнорра могут быть использованы для создания интерактивной схемы агрегированной подписи (interactive aggregate signature - IAS).
IAS - расширяют схемы multisig, позволяя каждому подписавшему подписать свое сообщение и вместо подписей для каждого отдельного входа, можно использовать одну подпись, которая проверит все входы. Теперь одна подпись может использоваться для траты всех входных данных транзакции. Каждый вход также будет иметь свой собственный PublicKey, но его можно будет использовать с помощью IAS Schnorr. Эту новую подпись можно очень легко проверить с помощью OPCHECKDLS, который является новым опкодом и будет введен в схему подписи Schnorr.
Taproot (https://t.me/CryptoBotan/710), который предназначается для увеличения гибкости смарт-контрактов, призван облегчить переход от агрегации ключей к агрегации перекрестного ввода (Cross-Input Aggregation). Для каждой транзакции требуется более одной подписи - по одной на каждый вход. Агрегация подписей с перекрестным вводом обеспечивает экономию, за счет сокращения количества подписей на транзакцию до 1. Комбинация данных ввода повышает конфиденциальность и освобождает пространство, которое ранее использовалось для размещения всех подписей на множестве разных входов.
Cross-input aggregation может улучшить транзакции CoinJoin (https://t.me/CryptoBotan/584). Решение вводит дополнительный механизм запутывания на уровне протокола. С его помощью можно построить основанные на Шнорр CJ-транзакции с n-подписями, которые выглядят как обычные транзакции с одной подписью. Проблемы с конфиденциальностью были разобраны мной в постах под тегом #Privacy.
Как уже писалось в посте про P2EP (https://t.me/CryptoBotan/989): "основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев".
P2EP обратно совместим, и при использовании в сочетании со Schnorr он может обеспечить достаточную конфиденциальность в базовом слое биткойна.
Cross-input aggregation имеет ряд проблем (https://smart-lab.ru/r.php?u=https%3A%2F%2F[Suspicious link removed]%3Ftopic%3D5140134.msg53720057%23msg53720057&s=2896124645) и не может быть внедрен по ряду причин. В любом случае, без внедрения подписей Шнорра, сделать это будет невозможно.
Для стека биткоина (https://t.me/CryptoBotan/888)
Так, так...нам снова придется вернуться к подписям Шнорра (https://t.me/CryptoBotan/702) и затронуть MuSig (https://t.me/CryptoBotan/936).
Схема Шнорра — это протокол идентификации и метод агрегирования (суммирование) подписей, необходимых для транзакции BTC. Подписи Шнорра позволяют создавать подпись действительную для суммы PublicKeys. Несколько подписывающих лиц в транзакции-multisig, объединяют свои PublicKeys в агрегированный ключ. Multisig-транзакции не поддерживаются ECDSA (https://t.me/CryptoBotan/824) и потому реализуются при помощи смарт-контракта P2SH (https://t.me/CryptoBotan/715).
1) P2SH требуют знания PublicKeys все подписавшихся участников multisig, что не особо радует. Агрегирование этих ключей позволит обеспечить более эффективную проверку, т.к. придется проверить лишь один ключ, а не n-ключей.
2) Транзакции P2SH требуют адреса начинающихся с числа 3 (см. BIP 13 (https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki)). А это удар по конфиденциальности. Агрегирование ключей позволяет multisig выглядеть как обычная транзакция.
Прежде чем перейти к теме поста, еще затронем MuSig. Это новая схема мультиподписи на основе Шнорр. Агрегация ключей в MuSig позволяет создавать частные смарт-контракты за пределами блокчейна. Итак, агрегация ключей это крутая плюшка для multisig-транзакций, которые тратят один вход. Но биткойн-транзакции чаще всего имеют больше одного входа?В будущем, подписи Шнорра могут быть использованы для создания интерактивной схемы агрегированной подписи (interactive aggregate signature - IAS).
IAS - расширяют схемы multisig, позволяя каждому подписавшему подписать свое сообщение и вместо подписей для каждого отдельного входа, можно использовать одну подпись, которая проверит все входы. Теперь одна подпись может использоваться для траты всех входных данных транзакции. Каждый вход также будет иметь свой собственный PublicKey, но его можно будет использовать с помощью IAS Schnorr. Эту новую подпись можно очень легко проверить с помощью OPCHECKDLS, который является новым опкодом и будет введен в схему подписи Schnorr.
Taproot (https://t.me/CryptoBotan/710), который предназначается для увеличения гибкости смарт-контрактов, призван облегчить переход от агрегации ключей к агрегации перекрестного ввода (Cross-Input Aggregation). Для каждой транзакции требуется более одной подписи - по одной на каждый вход. Агрегация подписей с перекрестным вводом обеспечивает экономию, за счет сокращения количества подписей на транзакцию до 1. Комбинация данных ввода повышает конфиденциальность и освобождает пространство, которое ранее использовалось для размещения всех подписей на множестве разных входов.
Cross-input aggregation может улучшить транзакции CoinJoin (https://t.me/CryptoBotan/584). Решение вводит дополнительный механизм запутывания на уровне протокола. С его помощью можно построить основанные на Шнорр CJ-транзакции с n-подписями, которые выглядят как обычные транзакции с одной подписью. Проблемы с конфиденциальностью были разобраны мной в постах под тегом #Privacy.
Как уже писалось в посте про P2EP (https://t.me/CryptoBotan/989): "основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев".
P2EP обратно совместим, и при использовании в сочетании со Schnorr он может обеспечить достаточную конфиденциальность в базовом слое биткойна.
Cross-input aggregation имеет ряд проблем (https://smart-lab.ru/r.php?u=https%3A%2F%2F[Suspicious link removed]%3Ftopic%3D5140134.msg53720057%23msg53720057&s=2896124645) и не может быть внедрен по ряду причин. В любом случае, без внедрения подписей Шнорра, сделать это будет невозможно.
Ivy - язык для написания смарт-контрактов Биткойн
Для стека биткоина (https://t.me/CryptoBotan/888)
О смарт-контрактах в сети Биткойн я уже писал не один раз:
- платформа RootStock (https://t.me/CryptoBotan/943)
- смарт-контракты LN (https://t.me/CryptoBotan/819)
- Musig (https://t.me/CryptoBotan/936)
- Scriptless Scripts (https://t.me/CryptoBotan/944)
- Язык Simplicity (https://t.me/CryptoBotan/980)
- Язык MiniScript (https://t.me/CryptoBotan/862)
- DAML (https://t.me/CryptoBotan/694)
Теперь про еще один язык высокого уровня, позволяющий писать смарт-контракты для протокола Bitcoin - Ivy (https://github.com/ivy-lang/ivy-bitcoin/tree/main/docs). Разработали язык в Chain (сайт ныне недоступен).
Как уже говорилось, писать смарт-контракты в сети Биткойн можно, но Bitcoin Script является низкоуровневым и ограниченным в функциональности. Bitcoin Script - это последовательность opcodes (https://t.me/CryptoBotan/931), выполняющихся по порядку. Bitcoin Script не является полным по Тьюрингу, а также не позволяет скриптам проверять другие входы или выходы в транзакции, а следовательно контракт не может контролировать поток стоимости.
Bitcoin-Script используется для создания Multisig-адресов, time-locked транзакций и платежных каналов. Ivy, как и другие альтернативные решения, создаются для облегчения написания и создания этих реализаций. Ivy компилируется в Bitcoin Script и может использоваться для создания совместимых с Segwit адресов. Это язык более высокого уровня и обеспечивает выполнение произвольных комбинаций условий, такие как проверка подписей, временные блокировки и хэш-обязательства.
Ребята из Chain даже выпустили "Ivy Playground for Bitcoin" - площадку для опробования языка. Игровая площадка включает в себя предварительно загруженные шаблоны смарт-контрактов для биткойнов.
Платформа позволяет создавать и разблокировать фиктивные контракты, писать шаблоны контрактов и создавать экземпляры с параметрами для генерации адресов тестовых сетей Биткойн, создавать имитированные контракты и пытаться их тратить.
Что сейчас с этим проектом я, увы, не ведаю...Возможно, что альтернативные варианты оказались более востребованы. В любом случае, написание смарт-контрактов в сети Биткойн станет проще. Об этом говорит большое количество разработок и решений.
Для стека биткоина (https://t.me/CryptoBotan/888)
О смарт-контрактах в сети Биткойн я уже писал не один раз:
- платформа RootStock (https://t.me/CryptoBotan/943)
- смарт-контракты LN (https://t.me/CryptoBotan/819)
- Musig (https://t.me/CryptoBotan/936)
- Scriptless Scripts (https://t.me/CryptoBotan/944)
- Язык Simplicity (https://t.me/CryptoBotan/980)
- Язык MiniScript (https://t.me/CryptoBotan/862)
- DAML (https://t.me/CryptoBotan/694)
Теперь про еще один язык высокого уровня, позволяющий писать смарт-контракты для протокола Bitcoin - Ivy (https://github.com/ivy-lang/ivy-bitcoin/tree/main/docs). Разработали язык в Chain (сайт ныне недоступен).
Как уже говорилось, писать смарт-контракты в сети Биткойн можно, но Bitcoin Script является низкоуровневым и ограниченным в функциональности. Bitcoin Script - это последовательность opcodes (https://t.me/CryptoBotan/931), выполняющихся по порядку. Bitcoin Script не является полным по Тьюрингу, а также не позволяет скриптам проверять другие входы или выходы в транзакции, а следовательно контракт не может контролировать поток стоимости.
Bitcoin-Script используется для создания Multisig-адресов, time-locked транзакций и платежных каналов. Ivy, как и другие альтернативные решения, создаются для облегчения написания и создания этих реализаций. Ivy компилируется в Bitcoin Script и может использоваться для создания совместимых с Segwit адресов. Это язык более высокого уровня и обеспечивает выполнение произвольных комбинаций условий, такие как проверка подписей, временные блокировки и хэш-обязательства.
Ребята из Chain даже выпустили "Ivy Playground for Bitcoin" - площадку для опробования языка. Игровая площадка включает в себя предварительно загруженные шаблоны смарт-контрактов для биткойнов.
Платформа позволяет создавать и разблокировать фиктивные контракты, писать шаблоны контрактов и создавать экземпляры с параметрами для генерации адресов тестовых сетей Биткойн, создавать имитированные контракты и пытаться их тратить.
Что сейчас с этим проектом я, увы, не ведаю...Возможно, что альтернативные варианты оказались более востребованы. В любом случае, написание смарт-контрактов в сети Биткойн станет проще. Об этом говорит большое количество разработок и решений.
Stratum - объединенный протокол майнинга
Для стека биткоина (https://t.me/CryptoBotan/888)
До конца 2012 года для майнинга использовался протокол "getwork". После, в середине 2012 года, разработан новый децентрализованный протокол майнинга BTC "getblocktemplate".
Оригинальный протокол getwork был заменен, так как просто выдавал заголовки блоков для решения. Майнер понятия не имел, что находится в блоке и никак не влиял на него. Майнер мог решать какие транзакции принимаются и передавать их оператору пула, а тот в свою очередь, мог использовать мощности всех майнеров для атак с двойной тратой и др. Протокол "getblocktemplate" позволил перемещать создание блоков в майнер, предоставляя пулам возможность устанавливать правила участия. Это повысило безопасность сети за счет повторной децентрализации блоков.
"Getwork" предоставлял только один заголовок блока, которого достаточно для общей сложности около 4 GH. Майнер отправлял пулу запросы getwork уже начиная от 4GH, что не позволяло подключать к пулу большие мощности. "Getblocktemplate" снизил нагрузку, необходимую для одного запроса на новый блок в сети. С помощью "getwork", заголовок блока передавался с сервера на клиент без каких-либо транзакций. Единственный способ изменить блок можно было через значение nonce. Максимум, что мог сделать клиент, - это попробовать все значения nonce, требующие дополнительной работы от сервера. Плюс ко всему "getwork" был несовместим с расширениями.
Протокол Stratum (https://stratumprotocol.org/) был представлен основателем 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.
Для стека биткоина (https://t.me/CryptoBotan/888)
До конца 2012 года для майнинга использовался протокол "getwork". После, в середине 2012 года, разработан новый децентрализованный протокол майнинга BTC "getblocktemplate".
Оригинальный протокол getwork был заменен, так как просто выдавал заголовки блоков для решения. Майнер понятия не имел, что находится в блоке и никак не влиял на него. Майнер мог решать какие транзакции принимаются и передавать их оператору пула, а тот в свою очередь, мог использовать мощности всех майнеров для атак с двойной тратой и др. Протокол "getblocktemplate" позволил перемещать создание блоков в майнер, предоставляя пулам возможность устанавливать правила участия. Это повысило безопасность сети за счет повторной децентрализации блоков.
"Getwork" предоставлял только один заголовок блока, которого достаточно для общей сложности около 4 GH. Майнер отправлял пулу запросы getwork уже начиная от 4GH, что не позволяло подключать к пулу большие мощности. "Getblocktemplate" снизил нагрузку, необходимую для одного запроса на новый блок в сети. С помощью "getwork", заголовок блока передавался с сервера на клиент без каких-либо транзакций. Единственный способ изменить блок можно было через значение nonce. Максимум, что мог сделать клиент, - это попробовать все значения nonce, требующие дополнительной работы от сервера. Плюс ко всему "getwork" был несовместим с расширениями.
Протокол Stratum (https://stratumprotocol.org/) был представлен основателем 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.
P2EP - Pay to Endpoint (Оплата до конечной точки)
Для стека биткоина (https://t.me/CryptoBotan/888)
Решение 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 (https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) предлагает схему URI для осуществления биткойн-платежей.
Б (получатель) генерирует URI BIP 21 с параметром определяющим конечную точку P2EP.
А (отправитель) инициирует взаимодействие с Б, подтверждая, что предоставленная конечная точка доступна. Если конечная точка Б доступна, А предоставляет Б подписанную транзакцию в качестве доказательства владения UTXO.
Затем Б отправляет несколько транзакций А, которые он должен подписать. Из этих транзакций только одна включает в себя UTXO, который фактически принадлежит Б, остальные могут быть выбраны из пула расходуемых UTXOs. После эти транзакции могут быть отправлены либо последовательно, либо параллельно отправителю.
Каждый подход отправки транзакций имеет свои плюсы и минусы. Но стоит заметить, что есть и третий подход для обмена UTXO. Это Bulletproofs (https://t.me/CryptoBotan/878) который я довольно много в последнее время упоминаю...
Когда Б получает подписанную транзакцию, которая соответствует их 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 (https://blockstream.com/2018/08/08/en-improving-privacy-using-pay-to-endpoint/)
Статья на Medium by Nopara73 (https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6)
Для стека биткоина (https://t.me/CryptoBotan/888)
Решение 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 (https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) предлагает схему URI для осуществления биткойн-платежей.
Б (получатель) генерирует URI BIP 21 с параметром определяющим конечную точку P2EP.
А (отправитель) инициирует взаимодействие с Б, подтверждая, что предоставленная конечная точка доступна. Если конечная точка Б доступна, А предоставляет Б подписанную транзакцию в качестве доказательства владения UTXO.
Затем Б отправляет несколько транзакций А, которые он должен подписать. Из этих транзакций только одна включает в себя UTXO, который фактически принадлежит Б, остальные могут быть выбраны из пула расходуемых UTXOs. После эти транзакции могут быть отправлены либо последовательно, либо параллельно отправителю.
Каждый подход отправки транзакций имеет свои плюсы и минусы. Но стоит заметить, что есть и третий подход для обмена UTXO. Это Bulletproofs (https://t.me/CryptoBotan/878) который я довольно много в последнее время упоминаю...
Когда Б получает подписанную транзакцию, которая соответствует их 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 (https://blockstream.com/2018/08/08/en-improving-privacy-using-pay-to-endpoint/)
Статья на Medium by Nopara73 (https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6)
Confidential transactions (CT) - Конфиденциальные транзакции
Для стека биткоина (https://t.me/CryptoBotan/888)
Продолжая направление #Privacy сегодня о конфиденциальных транзакциях.
Анализ блокчейна, мониторинг сети, KYC, AML, нарушение принципа взаимозаменяемости - все это уже работает для того, чтобы определить, посчитать, добавить в базу и взять под контроль тебя и твои биткоины. Это бесконечная гонка, где с одной стороны регуляторы, в виде корпораций, государств и твоих кредиторов,а с другой - борцы за анонимность, приватность и свободу.
Все транзакции в сети Биткойн записаны в блокчейн. Это является как плюсом так и минусом. С одной стороны, доверие без доверия, с другой - возможность тривиального отслеживания количества BTC, с адресов на адреса.
Решить проблему можно, скрыв количество BTC в совершаемой транзакции.
Еще в 2013 году, Адам Бэк, предложил эту концепцию под названием “bitcoins with homomorphic value”. Позже ее подхватили нынешние "двигатели" развития: Gregory Maxwell, Dr. Pieter Wuille, Andrew Poelstra. В итоге на свет появились Confidential Transactions.
Confidential Transactions - это криптографический метод сокрытия суммы отправляемых и получаемых средств.
CT полностью скрывает суммы на входах и выходах транзакции, давая возможность проверить, что сумма всех выходов не превышает сумму всех входов.
Чуть подробнее:
В основе решения лежат Борромеевские кольцевые подписи и схемы обязательств Педерсена.
Боромеевские кольцевые подписи - новый тип кольцевой подписи, основанный на задаче дискретного логарифма, который использовал новую структуру обязательств для получения значительной экономии размера и времени проверки кольцевых подписей.
Если кому интересно, вот ссылочка (https://pdfs.semanticscholar.org/4160/470c7f6cf05ffc81a98e8fd67fb0c84836ea.pdf) на документацию.
Cхемы обязательств Педерсена (Petersen Commitment) - это криптографическая схема, позволяющая зафиксировать сообщение каким-либо значением, сохраняя сообщение в секрете, с возможностью последующего раскрытия зафиксированного значения. Схемы обязательств разработаны таким образом, что ни одна из сторон не может изменить сообщение после того, как они его зафиксировали. Используются для того, чтобы одна сторона могла доказать, знание секрета, не раскрывая его.
Схемы обязательств используются в интерактивном криптографическом протоколе "Zero-knowledge proof", а тот в свою очередь в Bulletproofs (https://t.me/CryptoBotan/878) для BTC, в ZCash и его форках.
В Confidential Transactions используется Petersen Commitment для доказательства того, что сумма выходов не превышает сумму входов. То есть благодаря ему и скрывается сумма перевода.
В качестве суммы в commitments можно использовать отрицательное число, что приведет к неконтролируемой эмиссией монет. Range Proofs используется как раз для доказательства использования неотрицательных сумм. Проще говоря, Range Proofs - это доказательство, где каждый commitment подписан кольцевой подписью Борромео и гарантирует, что сумма находится в заданном интервале.
Проблема здесь в Range Proofs. На их создание уходит большое количество ресурсов и они имеют достаточно большой объем, что приведет к высоким комиссиям в сети.
Еще одной недогляделкой является тот факт, что суммы скрываются для конкретной транзакции. Если следующая транзакция не является конфиденциальной, предыдущие действия были бессмысленны.
CT скрывают суммы транзакций, но не адреса отправителя и получателя. Тут то и можно использовать CoinJoin (https://t.me/CryptoBotan/584) или CoinSwap (https://t.me/CryptoBotan/967), с которыми CT совместим.
Так же при проведении Soft Fork, встает вопрос, о синхронизации старых и новых узлов.
В криптовалюте Monero используется версия CT - Ring Confidential Transactions, где вместо подписей Борромео (об этом ниже) используется Bulletproofs (https://t.me/CryptoBotan/878). BitShares использует CT совместно с Stealth Addresses (https://t.me/CryptoBotan/584). CT имплементированы в Liquid (https://t.me/CryptoBotan/890) от Blockstream.
Confidential Transactions.txt (https://people.xiph.org/~greg/confidential_values.txt) by Greg Maxwell
Для стека биткоина (https://t.me/CryptoBotan/888)
Продолжая направление #Privacy сегодня о конфиденциальных транзакциях.
Анализ блокчейна, мониторинг сети, KYC, AML, нарушение принципа взаимозаменяемости - все это уже работает для того, чтобы определить, посчитать, добавить в базу и взять под контроль тебя и твои биткоины. Это бесконечная гонка, где с одной стороны регуляторы, в виде корпораций, государств и твоих кредиторов,а с другой - борцы за анонимность, приватность и свободу.
Все транзакции в сети Биткойн записаны в блокчейн. Это является как плюсом так и минусом. С одной стороны, доверие без доверия, с другой - возможность тривиального отслеживания количества BTC, с адресов на адреса.
Решить проблему можно, скрыв количество BTC в совершаемой транзакции.
Еще в 2013 году, Адам Бэк, предложил эту концепцию под названием “bitcoins with homomorphic value”. Позже ее подхватили нынешние "двигатели" развития: Gregory Maxwell, Dr. Pieter Wuille, Andrew Poelstra. В итоге на свет появились Confidential Transactions.
Confidential Transactions - это криптографический метод сокрытия суммы отправляемых и получаемых средств.
CT полностью скрывает суммы на входах и выходах транзакции, давая возможность проверить, что сумма всех выходов не превышает сумму всех входов.
Чуть подробнее:
В основе решения лежат Борромеевские кольцевые подписи и схемы обязательств Педерсена.
Боромеевские кольцевые подписи - новый тип кольцевой подписи, основанный на задаче дискретного логарифма, который использовал новую структуру обязательств для получения значительной экономии размера и времени проверки кольцевых подписей.
Если кому интересно, вот ссылочка (https://pdfs.semanticscholar.org/4160/470c7f6cf05ffc81a98e8fd67fb0c84836ea.pdf) на документацию.
Cхемы обязательств Педерсена (Petersen Commitment) - это криптографическая схема, позволяющая зафиксировать сообщение каким-либо значением, сохраняя сообщение в секрете, с возможностью последующего раскрытия зафиксированного значения. Схемы обязательств разработаны таким образом, что ни одна из сторон не может изменить сообщение после того, как они его зафиксировали. Используются для того, чтобы одна сторона могла доказать, знание секрета, не раскрывая его.
Схемы обязательств используются в интерактивном криптографическом протоколе "Zero-knowledge proof", а тот в свою очередь в Bulletproofs (https://t.me/CryptoBotan/878) для BTC, в ZCash и его форках.
В Confidential Transactions используется Petersen Commitment для доказательства того, что сумма выходов не превышает сумму входов. То есть благодаря ему и скрывается сумма перевода.
В качестве суммы в commitments можно использовать отрицательное число, что приведет к неконтролируемой эмиссией монет. Range Proofs используется как раз для доказательства использования неотрицательных сумм. Проще говоря, Range Proofs - это доказательство, где каждый commitment подписан кольцевой подписью Борромео и гарантирует, что сумма находится в заданном интервале.
Проблема здесь в Range Proofs. На их создание уходит большое количество ресурсов и они имеют достаточно большой объем, что приведет к высоким комиссиям в сети.
Еще одной недогляделкой является тот факт, что суммы скрываются для конкретной транзакции. Если следующая транзакция не является конфиденциальной, предыдущие действия были бессмысленны.
CT скрывают суммы транзакций, но не адреса отправителя и получателя. Тут то и можно использовать CoinJoin (https://t.me/CryptoBotan/584) или CoinSwap (https://t.me/CryptoBotan/967), с которыми CT совместим.
Так же при проведении Soft Fork, встает вопрос, о синхронизации старых и новых узлов.
В криптовалюте Monero используется версия CT - Ring Confidential Transactions, где вместо подписей Борромео (об этом ниже) используется Bulletproofs (https://t.me/CryptoBotan/878). BitShares использует CT совместно с Stealth Addresses (https://t.me/CryptoBotan/584). CT имплементированы в Liquid (https://t.me/CryptoBotan/890) от Blockstream.
Confidential Transactions.txt (https://people.xiph.org/~greg/confidential_values.txt) by Greg Maxwell
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused
Для стека биткоина (https://t.me/CryptoBotan/888)
Часть 1.
SNICKER ("Простые неинтерактивные Coinjoins с ключами для повторного использования шифрования") - это метод, позволяющий создать двухпартийный CoinJoin (https://t.me/CryptoBotan/584) (CJ) без какой-либо синхронизации или взаимодействия между участниками.
Автором SNICKER является один из разработчиков JoinMarket Adam Gibson. SNICKER представлен в качестве проекта предложения по улучшению биткойна (BIP) (https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79).
Чтобы совершить транзакцию-CJ пользователи должны подписать всю транзакцию, добавив все свои монеты и новые адреса получения. Они должны совершить транзакцию несколько раз и одновременно быть в сети. SNICKER же требует лишь сторону для передачи зашифрованных данных, а другую - для их получения.
Объясняя процесс SNICKER я использовал статью "SNICKER: How Alice And Bob Can Mix Bitcoin With No Interaction" (https://bitcoinmagazine.com/articles/snicker-how-alice-and-bob-can-mix-bitcoin-with-no-interaction).
Повторное использование адресов:
Алиса имеет 1BTC, который она хочет миксануть и он представлен как UTXO (https://t.me/CryptoBotan/742) в блокчейн. Он отправляет этот биткоин себе же, на свой же адрес, публично отмечая 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, который должен соответствовать ее новому, созданному Бобом, адресу, она подписывает и транслирует транзакцию в сеть.
Часть.2
Повторно использованные подписанные входные данные
Вторую версию SNICKER также описал Adam Gibson. В ней удалось избежать необходимости повторного использования адреса - за счет некоторого усложнения.
В этом варианте, Боб берет PublicKey из входных данных транзакции которая создала UTXO Алисы, а не из повторно используемого адреса, как в 1 варианте (https://t.me/CryptoBotan/983).
Боб полагает, что один из входов этой транзакции был создан самой Алисой, и у нее есть PrivateKey для него. Это верно, так как UTXO Алисы обозначен как готовый к миксингу и что владелец, т.е.Алиса, владеет PrivateKey.
В BIP не указывается как будет выполнена первоначальная маркировка. Но есть предположение что некоторые кошельки (например JoinMarket) смогут видеть такую информацию.
Альтернативным вариантом, Алиса могла бы разместить сообщение на доске объявлений, а именно засветить UTXO.
Как только SNICKER начнет использоваться, поиск запросов на миксинг станет проще. Сами SNIKER -транзакции просты для распознавания. Поэтому после начальной фазы загрузки несмешанные монеты будут смешиваться с ранее смешиваемыми монетами, и в свою очередь могут быть использованы для следующего смешивания...
Как упоминалось в 1 варианте, Существует проблема выбора "тех самых" UTXO, которые готовы к миксингу и уменьшение количества ложных совпадений. Ложные совпадения, это помеченные UTXO, уже пройденные этап миксинга или проходящие в данный момент. Потенциальные совпадения могут быть отфильтрованы по суммам, возрасту UTXO или типа используемых кошельков.
Один из вариантов: Боб использует один и тот же UTXO для всех объявлений. То есть первый кто успеет проведет миксинг. Другие же, желающие провести миксинг, остаются неудел, но проблем не возникнет.Предложение Боба будет просто висеть на доске пока не удалят или навсегда.
Проблема номер 2: Так как доска объявлений будет содержать зашифрованные "запросы", то невозможно будет отфильтровать "поддельные" предложения. Одним из решений проблемы являются затраты на публикацию предложения.
Очень интересное преимущество предоставляет SNICKER. Боб, который заинтересован в миксе своих монет, может добавлять средства к выходу принимающей стороны, для стимулирования желания провести миксинг. Так же, не отрицается возможность и использования троих сторон в миксе, но это будет довольно сложна схема.
Для стека биткоина (https://t.me/CryptoBotan/888)
Часть 1.
SNICKER ("Простые неинтерактивные Coinjoins с ключами для повторного использования шифрования") - это метод, позволяющий создать двухпартийный CoinJoin (https://t.me/CryptoBotan/584) (CJ) без какой-либо синхронизации или взаимодействия между участниками.
Автором SNICKER является один из разработчиков JoinMarket Adam Gibson. SNICKER представлен в качестве проекта предложения по улучшению биткойна (BIP) (https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79).
Чтобы совершить транзакцию-CJ пользователи должны подписать всю транзакцию, добавив все свои монеты и новые адреса получения. Они должны совершить транзакцию несколько раз и одновременно быть в сети. SNICKER же требует лишь сторону для передачи зашифрованных данных, а другую - для их получения.
Объясняя процесс SNICKER я использовал статью "SNICKER: How Alice And Bob Can Mix Bitcoin With No Interaction" (https://bitcoinmagazine.com/articles/snicker-how-alice-and-bob-can-mix-bitcoin-with-no-interaction).
Повторное использование адресов:
Алиса имеет 1BTC, который она хочет миксануть и он представлен как UTXO (https://t.me/CryptoBotan/742) в блокчейн. Он отправляет этот биткоин себе же, на свой же адрес, публично отмечая 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, который должен соответствовать ее новому, созданному Бобом, адресу, она подписывает и транслирует транзакцию в сеть.
Часть.2
Повторно использованные подписанные входные данные
Вторую версию SNICKER также описал Adam Gibson. В ней удалось избежать необходимости повторного использования адреса - за счет некоторого усложнения.
В этом варианте, Боб берет PublicKey из входных данных транзакции которая создала UTXO Алисы, а не из повторно используемого адреса, как в 1 варианте (https://t.me/CryptoBotan/983).
Боб полагает, что один из входов этой транзакции был создан самой Алисой, и у нее есть PrivateKey для него. Это верно, так как UTXO Алисы обозначен как готовый к миксингу и что владелец, т.е.Алиса, владеет PrivateKey.
В BIP не указывается как будет выполнена первоначальная маркировка. Но есть предположение что некоторые кошельки (например JoinMarket) смогут видеть такую информацию.
Альтернативным вариантом, Алиса могла бы разместить сообщение на доске объявлений, а именно засветить UTXO.
Как только SNICKER начнет использоваться, поиск запросов на миксинг станет проще. Сами SNIKER -транзакции просты для распознавания. Поэтому после начальной фазы загрузки несмешанные монеты будут смешиваться с ранее смешиваемыми монетами, и в свою очередь могут быть использованы для следующего смешивания...
Как упоминалось в 1 варианте, Существует проблема выбора "тех самых" UTXO, которые готовы к миксингу и уменьшение количества ложных совпадений. Ложные совпадения, это помеченные UTXO, уже пройденные этап миксинга или проходящие в данный момент. Потенциальные совпадения могут быть отфильтрованы по суммам, возрасту UTXO или типа используемых кошельков.
Один из вариантов: Боб использует один и тот же UTXO для всех объявлений. То есть первый кто успеет проведет миксинг. Другие же, желающие провести миксинг, остаются неудел, но проблем не возникнет.Предложение Боба будет просто висеть на доске пока не удалят или навсегда.
Проблема номер 2: Так как доска объявлений будет содержать зашифрованные "запросы", то невозможно будет отфильтровать "поддельные" предложения. Одним из решений проблемы являются затраты на публикацию предложения.
Очень интересное преимущество предоставляет SNICKER. Боб, который заинтересован в миксе своих монет, может добавлять средства к выходу принимающей стороны, для стимулирования желания провести миксинг. Так же, не отрицается возможность и использования троих сторон в миксе, но это будет довольно сложна схема.
ZeroLink - усовершенствованный CoinJoin
Для стека биткоина (https://t.me/CryptoBotan/888)
Посты на тему конфиденциальных платежей под тегом
CoinJoin (https://t.me/CryptoBotan/584)
MimbleWimble (https://t.me/CryptoBotan/805)
CoinSwap (https://t.me/CryptoBotan/967)
TumbleBit (https://t.me/CryptoBotan/969)
Dandelion (https://t.me/CryptoBotan/964)
Теперь поехалите...
Важным свойством денег является их взаимозаменяемость - идентичность каждой единицы каждой другой единице. Уже сейчас видно, как биржи блокируют средства, если они отмечаются как "грязные" или засвеченные в миксерах. А компании вроде Crystal или ChainAnalysis помогают им в этом. Подробнее о том, как правоохранительные органы используют блокчейн я писал в этом посте (https://t.me/CryptoBotan/744). Идеальная взаимозаменяемость требует, чтобы каждая биткойн-транзакция была неотличима друг от друга
Проблему взаимозаменяемости, которая присутствует сегодня, можно решить лишь при помощи улучшения конфиденциальности проведения платежей.
Протокол ZeroLink, от разработчиков HiddenWallet (тот что внедрил TumbleBit (https://t.me/CryptoBotan/969)) и Samourai Wallet (https://t.me/CryptoBotan/667), предлагает технологию микширования 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 (https://github.com/nopara73/ZeroLink) расписаны механизмы защиты от нарушения процессов создания транзакций недобросовестными участниками.
К решению ZeroLink вернулись в 2017 году, так как комиссии в сети Биткойн уже не нулевые, и нарушить процесс миксинга монет, при комиссиях около 1$ не выгодно экономически.
Samourai внедрил ZeroLink в Whirlpool (https://github.com/Samourai-Wallet/Whirlpool).
Для стека биткоина (https://t.me/CryptoBotan/888)
Посты на тему конфиденциальных платежей под тегом
CoinJoin (https://t.me/CryptoBotan/584)
MimbleWimble (https://t.me/CryptoBotan/805)
CoinSwap (https://t.me/CryptoBotan/967)
TumbleBit (https://t.me/CryptoBotan/969)
Dandelion (https://t.me/CryptoBotan/964)
Теперь поехалите...
Важным свойством денег является их взаимозаменяемость - идентичность каждой единицы каждой другой единице. Уже сейчас видно, как биржи блокируют средства, если они отмечаются как "грязные" или засвеченные в миксерах. А компании вроде Crystal или ChainAnalysis помогают им в этом. Подробнее о том, как правоохранительные органы используют блокчейн я писал в этом посте (https://t.me/CryptoBotan/744). Идеальная взаимозаменяемость требует, чтобы каждая биткойн-транзакция была неотличима друг от друга
Проблему взаимозаменяемости, которая присутствует сегодня, можно решить лишь при помощи улучшения конфиденциальности проведения платежей.
Протокол ZeroLink, от разработчиков HiddenWallet (тот что внедрил TumbleBit (https://t.me/CryptoBotan/969)) и Samourai Wallet (https://t.me/CryptoBotan/667), предлагает технологию микширования 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 (https://github.com/nopara73/ZeroLink) расписаны механизмы защиты от нарушения процессов создания транзакций недобросовестными участниками.
К решению ZeroLink вернулись в 2017 году, так как комиссии в сети Биткойн уже не нулевые, и нарушить процесс миксинга монет, при комиссиях около 1$ не выгодно экономически.
Samourai внедрил ZeroLink в Whirlpool (https://github.com/Samourai-Wallet/Whirlpool).
Mining Derivatives - контракты на биткойн-хэшрейт
Для стека биткоина (https://t.me/CryptoBotan/888)
Деривативы - это производные финансовые инструменты. Производные они, потому что сами по себе они ничего не стоят, поэтому их стоимость определяется ценой базового актива. Базовым активом может быть что угодно: долговые обязательства, валюты, ценные бумаги, или как в нашем случае, биткойн-хэшрейт. Деривативы предназначены для спекуляций и хэджирования рисков. Если с первым все довольно понятно, то вот с хэджированием думаю стоит разобраться...
Хеджирование - открытие сделок на одном рынке для компенсации воздействия ценовых рисков равной, но противоположной позиции на другом рынке.
В статье "Hedging mining difficulty" (https://medium.com/@tamas.blummer/hedging-mining-difficulty-42f0f8652d7c), Tamas Blummer провел исследование расчета и хэджирования сложности майнинга.
Оценивая скорость увеличения сложности невозможно точно определить влияние изменений сложности на добычу на более длительный срок. Более точный эффект корректировки сложности можно рассчитать наблюдая за совокупной работой, требуемой сетью. А фактическая производительность майнера пропорциональна той доле работы, которую он смог выполнить из общего количества требуемых сетью.
Чтобы немного больше погрузиться в тему хэшрейта и его влияния на цену BTC, рекомендую к прочтению статьи (https://t.me/gfoundinshit/1756) автора канала t.me/gfoundinshit.
Ну а теперь собственно к хэджированию...
Майнер хочет перестраховаться от более сильного (чем ожидалось) увеличения сложности. Есть спекулянт который хочет взять другую сторону этой ставки. В итоге, они создают две транзакции:
1-ая транзакция - майнер и спекулянт вносят средства для совместного депонирования (multisig). Спекулянт вносит X BTC, а майнер
Такой способ создает полностью обеспеченную ставку, без третей стороны или оракула.
Проект позволяющий спекулировать на хэшрейте BTC, для хэджирования от волатильности цен сейчас в AlphaTest. PowSwap (https://powswap.com/) - это метод торговли производными хешрейта биткойна, использующий протокол Биткойна в качестве оракула, таким образом, не полагаясь на доверенных третьих лиц. Разработчик Powswap Jeremy Rubin объявил (https://twitter.com/JeremyRubin/status/1192958303464067072) о запуске проекта в ноябре 2019 года.
"Это смарт-контракт/платформа для торговли деривативами Биткойн-хешрейта. Без посредников. Никаких оракулов. Никаких депозитов. Ничего, кроме Биткойна.”
Powswap работает на Bitcoin Core и не требует софтфорка. Базовый протокол не требует участия других сторон. Это некастодиальная, не требующая доверия платформа производных хэшрейта. Используя смарт-контракты, powswap автоматически обнаруживает изменения в хешрейте биткойна и производит выплаты контрактов на этой основе. Протокол Powswap является гибкой основой для экзотических контрактов хешрейта. Платформа ретранслирует заказы через доску объявлений доступных предложений и берет небольшую комиссию за ретрансляцию заказов. Контракты могут обновляться без взаимодействия по цепочке, что позволяет договаривающимся сторонам пересматривать контракты по мере корректировки рыночных прогнозов.
Сложность возникает лишь в том, будут ли стороны согласны заключать предложенные ставки...Ведь такой вид деривативов весьма специфичен
В апреле 2017 года CME Group опубликовали (http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=20170103458.PGNR.&OS=DN/20170103458&RS=DN/20170103458) патент на создание платформы для майнеров BTC, позволяющую хэджировать операционные риски.
В декабре 2019 года компания Canaan в партнерстве с маркет-мейкером GSR (https://www.gsr.io/our-services/market-making/) и Interhash (http://interhash.by/) создала концепцию, позволяющую майнерам хеджировать свои риски. (Ссылка (https://bits.media/gsr-i-interhash-razrabotayut-reshenie-dlya-khedzhirovaniya-riskov-dlya-maynerov/))
В чем же основные отличия?
Powswap - это децентрализованная платформа, что определенно большой плюс для нее...
Для стека биткоина (https://t.me/CryptoBotan/888)
Деривативы - это производные финансовые инструменты. Производные они, потому что сами по себе они ничего не стоят, поэтому их стоимость определяется ценой базового актива. Базовым активом может быть что угодно: долговые обязательства, валюты, ценные бумаги, или как в нашем случае, биткойн-хэшрейт. Деривативы предназначены для спекуляций и хэджирования рисков. Если с первым все довольно понятно, то вот с хэджированием думаю стоит разобраться...
Хеджирование - открытие сделок на одном рынке для компенсации воздействия ценовых рисков равной, но противоположной позиции на другом рынке.
В статье "Hedging mining difficulty" (https://medium.com/@tamas.blummer/hedging-mining-difficulty-42f0f8652d7c), Tamas Blummer провел исследование расчета и хэджирования сложности майнинга.
Оценивая скорость увеличения сложности невозможно точно определить влияние изменений сложности на добычу на более длительный срок. Более точный эффект корректировки сложности можно рассчитать наблюдая за совокупной работой, требуемой сетью. А фактическая производительность майнера пропорциональна той доле работы, которую он смог выполнить из общего количества требуемых сетью.
Чтобы немного больше погрузиться в тему хэшрейта и его влияния на цену BTC, рекомендую к прочтению статьи (https://t.me/gfoundinshit/1756) автора канала t.me/gfoundinshit.
Ну а теперь собственно к хэджированию...
Майнер хочет перестраховаться от более сильного (чем ожидалось) увеличения сложности. Есть спекулянт который хочет взять другую сторону этой ставки. В итоге, они создают две транзакции:
1-ая транзакция - майнер и спекулянт вносят средства для совместного депонирования (multisig). Спекулянт вносит X BTC, а майнер
Такой способ создает полностью обеспеченную ставку, без третей стороны или оракула.
Проект позволяющий спекулировать на хэшрейте BTC, для хэджирования от волатильности цен сейчас в AlphaTest. PowSwap (https://powswap.com/) - это метод торговли производными хешрейта биткойна, использующий протокол Биткойна в качестве оракула, таким образом, не полагаясь на доверенных третьих лиц. Разработчик Powswap Jeremy Rubin объявил (https://twitter.com/JeremyRubin/status/1192958303464067072) о запуске проекта в ноябре 2019 года.
"Это смарт-контракт/платформа для торговли деривативами Биткойн-хешрейта. Без посредников. Никаких оракулов. Никаких депозитов. Ничего, кроме Биткойна.”
Powswap работает на Bitcoin Core и не требует софтфорка. Базовый протокол не требует участия других сторон. Это некастодиальная, не требующая доверия платформа производных хэшрейта. Используя смарт-контракты, powswap автоматически обнаруживает изменения в хешрейте биткойна и производит выплаты контрактов на этой основе. Протокол Powswap является гибкой основой для экзотических контрактов хешрейта. Платформа ретранслирует заказы через доску объявлений доступных предложений и берет небольшую комиссию за ретрансляцию заказов. Контракты могут обновляться без взаимодействия по цепочке, что позволяет договаривающимся сторонам пересматривать контракты по мере корректировки рыночных прогнозов.
Сложность возникает лишь в том, будут ли стороны согласны заключать предложенные ставки...Ведь такой вид деривативов весьма специфичен
В апреле 2017 года CME Group опубликовали (http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=20170103458.PGNR.&OS=DN/20170103458&RS=DN/20170103458) патент на создание платформы для майнеров BTC, позволяющую хэджировать операционные риски.
В декабре 2019 года компания Canaan в партнерстве с маркет-мейкером GSR (https://www.gsr.io/our-services/market-making/) и Interhash (http://interhash.by/) создала концепцию, позволяющую майнерам хеджировать свои риски. (Ссылка (https://bits.media/gsr-i-interhash-razrabotayut-reshenie-dlya-khedzhirovaniya-riskov-dlya-maynerov/))
В чем же основные отличия?
Powswap - это децентрализованная платформа, что определенно большой плюс для нее...
Simplicity - новый язык для блокчейнов, реализующий смарт-контракты в биткоине.
Для стека биткоина (https://t.me/CryptoBotan/888)
Я уже писал о других языках способных помочь деду стать более подвижным и удобным. Это обновленный язык Биткойна Tapscript (https://t.me/CryptoBotan/931) для сценариев Taproot (https://t.me/CryptoBotan/710). Это MiniScript (https://t.me/CryptoBotan/862) на базе языка смарт-контрактов Script.
Скриптовый язык Биткойна очень ограничен дизайном и непригоден для построения сложных смарт-контрактов. Некоторые опкоды (подробнее тут (https://t.me/CryptoBotan/931)) были отключены еще в самом начале пути Биткойна.
Ethereum имеет полный гибкий и полный по Тьюрингу (https://t.me/CryptoBotan/864) язык. Но и тут есть проблема...Ethereum не поддерживает статический анализ, который позволяет заранее определить какое количество вычислительных ресурсов потребуется программе. Таким образом можно отфильтровать дорогостоящие контракты и бесконечные циклы.
Simplicity был представлен разработчиком из Blockstream Russell O’Connor. Simplicity предназначен для включения в сайдчейн BlockStream и в дальнейшем, при помощи софтфорка, имплементирование его в Биткойн. Simplicity позволит завершать и расширять возможности сценариев.
Simplicity - это низкоуровневый язык основанный на алгоритме последовательного вычисления для выполнения смарт-контрактов. Это типизированный функциональный язык программирования, использующий комбинаторы. Он может быть использован как основа для других языков, более высокого уровня, так и для улучшения существующих (Bitcoin Script, EVM Ethereum (https://t.me/CryptoBotan/868)).
Simplicity - это не полный по Тьюрингу, обеспечивающий ограничение рекурсивного вызова и защиту от бесконечных циклов язык. Он позволяет проводить статический анализ кода (эффективно ограничивать объем вычислительных ресурсов, необходимый программе до ее выполнения). Имеет встроенную поддержку мерклизованных абстрактных синтаксических деревьев (MAST)(https://t.me/CryptoBotan/719)
Разработка пакетов SDK (Software Developer Kit) первый шаг, по развертыванию языка в проекте Elements (https://t.me/CryptoBotan/889) от Blockstream.
Software Development Kit (комплект программ для разработки) - это набор необходимых программных продуктов (библиотек, скриптов), предназначенный для облегчения процесса разработки и тестирования кода для конкретных программных платформ.
Simplicity в будущем может быть интегрирован с Ivy (язык более высокого уровня, позволяющий писать смарт-контракты для протокола Bitcoin). О нем мы тоже поговорим позже, так как я собираюсь разобрать стек до конца.😇
WhitePaper (https://blockstream.com/simplicity.pdf)
Для стека биткоина (https://t.me/CryptoBotan/888)
Я уже писал о других языках способных помочь деду стать более подвижным и удобным. Это обновленный язык Биткойна Tapscript (https://t.me/CryptoBotan/931) для сценариев Taproot (https://t.me/CryptoBotan/710). Это MiniScript (https://t.me/CryptoBotan/862) на базе языка смарт-контрактов Script.
Скриптовый язык Биткойна очень ограничен дизайном и непригоден для построения сложных смарт-контрактов. Некоторые опкоды (подробнее тут (https://t.me/CryptoBotan/931)) были отключены еще в самом начале пути Биткойна.
Ethereum имеет полный гибкий и полный по Тьюрингу (https://t.me/CryptoBotan/864) язык. Но и тут есть проблема...Ethereum не поддерживает статический анализ, который позволяет заранее определить какое количество вычислительных ресурсов потребуется программе. Таким образом можно отфильтровать дорогостоящие контракты и бесконечные циклы.
Simplicity был представлен разработчиком из Blockstream Russell O’Connor. Simplicity предназначен для включения в сайдчейн BlockStream и в дальнейшем, при помощи софтфорка, имплементирование его в Биткойн. Simplicity позволит завершать и расширять возможности сценариев.
Simplicity - это низкоуровневый язык основанный на алгоритме последовательного вычисления для выполнения смарт-контрактов. Это типизированный функциональный язык программирования, использующий комбинаторы. Он может быть использован как основа для других языков, более высокого уровня, так и для улучшения существующих (Bitcoin Script, EVM Ethereum (https://t.me/CryptoBotan/868)).
Simplicity - это не полный по Тьюрингу, обеспечивающий ограничение рекурсивного вызова и защиту от бесконечных циклов язык. Он позволяет проводить статический анализ кода (эффективно ограничивать объем вычислительных ресурсов, необходимый программе до ее выполнения). Имеет встроенную поддержку мерклизованных абстрактных синтаксических деревьев (MAST)(https://t.me/CryptoBotan/719)
Разработка пакетов SDK (Software Developer Kit) первый шаг, по развертыванию языка в проекте Elements (https://t.me/CryptoBotan/889) от Blockstream.
Software Development Kit (комплект программ для разработки) - это набор необходимых программных продуктов (библиотек, скриптов), предназначенный для облегчения процесса разработки и тестирования кода для конкретных программных платформ.
Simplicity в будущем может быть интегрирован с Ivy (язык более высокого уровня, позволяющий писать смарт-контракты для протокола Bitcoin). О нем мы тоже поговорим позже, так как я собираюсь разобрать стек до конца.😇
WhitePaper (https://blockstream.com/simplicity.pdf)
Дополнение к протоколу Eltoo (https://t.me/CryptoBotan/911)
Прежде чем писать о Noinput (о котором обещал рассказать в этом посте (https://t.me/CryptoBotan/973) и который позволит внедрить протокол Eltoo), разберемся с SIGHASH...Пригодиться😒
Signature Hash Types
Вспомним о транзакциях BTC.
Bitcoin транзакция — это подтверждённая подписью секция данных, которая передаётся по сети и собирается в блоки. Юзер пытается совершить транзакцию и потратить средства. Ему надо доказать, что он авторизовал транзакцию. Для этого используются подписи которые вычисляются на основе хэша транзакций. Хэш транзакции генерируется частями транзакции. Эти части транзакций зависят от типа Sighash. Подписи, подтверждают, что владелец PublicKey хочет потратить соответствующие монеты в конкретной транзакции. Важно, что трата происходит не всей подписанной транзакции, а ее части. Определяет эту часть подписанной транзакции для траты такая вещь как "метка sighash (Signature Hash Types)".
SIGHASH - Это метка для подписей биткойнов, который указывает, какие части транзакции подписывает подпись. (По умолчанию используется SIGHASHALL). SIGHASH позволяет построить контракты, в которых каждая сторона подписывает только часть договора, позволяя изменять другие части без их участия
Имеется 3 типа SIGHASH:
SIGHASHALL - устанавливает требование, что все части транзакции (все входы и выходы, кроме входных скриптов) должны быть подписаны, а следовательно никакая из этих частей не может быть изменена. Упрощенно это выглядит так: "Я согласен вложить свои деньги, если каждый вложит свои деньги, таким способом."
SIGHASH_NONE - подписывает все входы, но не выходы. Другие пользователи могут обновлять транзакцию. Упрощенно: "Я согласен вложить свои деньги, если каждый вложит свои деньги, таким способом, но мне плевать куда они будут потрачены."
SIGHASH_SINGLE - подписываются только соответствующие входные и выходные данные (выходные данные с тем же индексным номером, что и входные данные). Упрощенно: "Я согласен вложить свои деньги, если каждый вложит свои деньги, но меня волнуют только моя часть средств."
Плюс ко всему вышесказанному, существует специальный модификатор ANYONECANPAY, который можно использовать с любым из трех типов SIGHASH. Этот модификатор игнорирует все вводы, кроме текущего. Т.е. подписывается только один вход.
Новый класс меток Noinput
С Signature Hash Types разобрались (https://t.me/CryptoBotan/977)
Транзакция состоит из:
Input (Вход) - это ссылка на выход другой транзакции. У транзакции их может быть несколько. Ссылки суммируются и сумма BTC используется в выходе этой транзакции.
Output (Выход) - содержит информацию об отправке BTC. Их может быть несколько, тогда они делят сумму пришедшую со входа между собой.Каждый выход используется для входа следующей транзакции, только один раз. Сумма всех входов для транзакции используется на её выходах.
Разработчик Blockstream и Xapo Кристиан Декер и Таунс разработали новый вид "меток SIGHASH": SIGHASH NOINPUT, SIGHASH ANYPREVOUT,
SIGHASH ANYPREVOUTANYSCRIPT
Как я уже писал, транзакция состоит из нескольких частей информации. Входные данные разблокируют монеты, выходные данные запирают монеты с указанием будущей траты и т.д. Добавляется подпись соответствующая PublicKey, которая доказывает, что их владелец хочет произвести трату. Подписывать каждую часть транзакции необязательно. Можно указать какую часть транзакции подписывать при помощи SIGHASH.
Новый класс Noinput (Noinput, Anyprevout и Anyprevoutanyscript) указывает, что выходные данные будут подписаны, а входные нет. Это значит, что не подписывая входные данные, можно осуществить транзакцию, поменяв местами совместимые входы, не генерируя новую подпись.
Таких совместимых входов, чаще всего не существует. Подпись соответствует PublicKey, а следовательно определенным монетам. Замена входа на другой приведет к тому, что транзакция станет недействительной.
Но не все так противоречиво
Разбирая стек биткоина (https://t.me/CryptoBotan/888) я писал о решении для упрощенного способа осуществления "off-chain" (внесетевых) транзакций - Eltoo (https://t.me/CryptoBotan/911).
Чтобы 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 3 мог тратить средства из 2 и из 1, необходимы метки Noinput. При замене входных данных последняя update transaction всегда может быть переписана для прямой ссылки на любую другую транзакцию. Обмен входными данными возможен. Ведь независимо от того, какая предыдущая транзакция выбрана, в платежном канале требуемые подписи всегда исходят от одних и тех же двух пользователей с одинаковыми двумя public и private keys.
Прежде чем писать о Noinput (о котором обещал рассказать в этом посте (https://t.me/CryptoBotan/973) и который позволит внедрить протокол Eltoo), разберемся с SIGHASH...Пригодиться😒
Signature Hash Types
Вспомним о транзакциях BTC.
Bitcoin транзакция — это подтверждённая подписью секция данных, которая передаётся по сети и собирается в блоки. Юзер пытается совершить транзакцию и потратить средства. Ему надо доказать, что он авторизовал транзакцию. Для этого используются подписи которые вычисляются на основе хэша транзакций. Хэш транзакции генерируется частями транзакции. Эти части транзакций зависят от типа Sighash. Подписи, подтверждают, что владелец PublicKey хочет потратить соответствующие монеты в конкретной транзакции. Важно, что трата происходит не всей подписанной транзакции, а ее части. Определяет эту часть подписанной транзакции для траты такая вещь как "метка sighash (Signature Hash Types)".
SIGHASH - Это метка для подписей биткойнов, который указывает, какие части транзакции подписывает подпись. (По умолчанию используется SIGHASHALL). SIGHASH позволяет построить контракты, в которых каждая сторона подписывает только часть договора, позволяя изменять другие части без их участия
Имеется 3 типа SIGHASH:
SIGHASHALL - устанавливает требование, что все части транзакции (все входы и выходы, кроме входных скриптов) должны быть подписаны, а следовательно никакая из этих частей не может быть изменена. Упрощенно это выглядит так: "Я согласен вложить свои деньги, если каждый вложит свои деньги, таким способом."
SIGHASH_NONE - подписывает все входы, но не выходы. Другие пользователи могут обновлять транзакцию. Упрощенно: "Я согласен вложить свои деньги, если каждый вложит свои деньги, таким способом, но мне плевать куда они будут потрачены."
SIGHASH_SINGLE - подписываются только соответствующие входные и выходные данные (выходные данные с тем же индексным номером, что и входные данные). Упрощенно: "Я согласен вложить свои деньги, если каждый вложит свои деньги, но меня волнуют только моя часть средств."
Плюс ко всему вышесказанному, существует специальный модификатор ANYONECANPAY, который можно использовать с любым из трех типов SIGHASH. Этот модификатор игнорирует все вводы, кроме текущего. Т.е. подписывается только один вход.
Новый класс меток Noinput
С Signature Hash Types разобрались (https://t.me/CryptoBotan/977)
Транзакция состоит из:
Input (Вход) - это ссылка на выход другой транзакции. У транзакции их может быть несколько. Ссылки суммируются и сумма BTC используется в выходе этой транзакции.
Output (Выход) - содержит информацию об отправке BTC. Их может быть несколько, тогда они делят сумму пришедшую со входа между собой.Каждый выход используется для входа следующей транзакции, только один раз. Сумма всех входов для транзакции используется на её выходах.
Разработчик Blockstream и Xapo Кристиан Декер и Таунс разработали новый вид "меток SIGHASH": SIGHASH NOINPUT, SIGHASH ANYPREVOUT,
SIGHASH ANYPREVOUTANYSCRIPT
Как я уже писал, транзакция состоит из нескольких частей информации. Входные данные разблокируют монеты, выходные данные запирают монеты с указанием будущей траты и т.д. Добавляется подпись соответствующая PublicKey, которая доказывает, что их владелец хочет произвести трату. Подписывать каждую часть транзакции необязательно. Можно указать какую часть транзакции подписывать при помощи SIGHASH.
Новый класс Noinput (Noinput, Anyprevout и Anyprevoutanyscript) указывает, что выходные данные будут подписаны, а входные нет. Это значит, что не подписывая входные данные, можно осуществить транзакцию, поменяв местами совместимые входы, не генерируя новую подпись.
Таких совместимых входов, чаще всего не существует. Подпись соответствует PublicKey, а следовательно определенным монетам. Замена входа на другой приведет к тому, что транзакция станет недействительной.
Но не все так противоречиво
Разбирая стек биткоина (https://t.me/CryptoBotan/888) я писал о решении для упрощенного способа осуществления "off-chain" (внесетевых) транзакций - Eltoo (https://t.me/CryptoBotan/911).
Чтобы 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 3 мог тратить средства из 2 и из 1, необходимы метки Noinput. При замене входных данных последняя update transaction всегда может быть переписана для прямой ссылки на любую другую транзакцию. Обмен входными данными возможен. Ведь независимо от того, какая предыдущая транзакция выбрана, в платежном канале требуемые подписи всегда исходят от одних и тех же двух пользователей с одинаковыми двумя public и private keys.
FIBRE - Протокол для ретрансляции блоков
Для стека биткоина (https://t.me/CryptoBotan/888)
FIBRE (https://bitcoinfibre.org/) (Fast Internet Bitcoin Relay Engine - высокоскоростная ретрансляция блоков на базе сети Интернет) - это расширение для Bitcoin Core, которое обеспечивает ретрансляцию блоков с высокой скоростью и ручным выбором равноправных узлов по UDP.
UDP – это транспортный протокол, передающий сообщения без необходимости установки соединения в IP-сети. Его можно считать оптимальным протоколом для приложений, которые рассчитаны на широкую пропускную способность и быстрый обмен.
Биткойн - это одноранговая сеть, где узлы соединяются друг с другом случайным образом. Транзакции и блоки по этой сети передаются всем узлам. Пока все узлы получат информацию о блоке или транзакции должно пройти время. Тут то и проблема...Майнеры тратят некоторое количество времени на майнинг поверх старых блоков, когда сеть уже выбрала последний блок. Информация об этом, еще не дошла до всех узлов.
FIBRE решает проблему скорости распространения блоков.
Информация о блоках между узлами передается пакетами (порциями). Узел в сети получает каждый пакет и восстанавливает блоки из данных в этих пакетах и снова отправляет другим узлам, и снова в разных пакетах. Тут есть проблема: эти пакеты могут теряться и узлам необходимо повторно передавать данные, а это влияет на скорость передачи.
Основным улучшением в FIBRE является переход от использования TCP к использованию UDP с прямой коррекцией ошибок (FEC).
В чем разница между TCP и UDP (https://t.me/CryptoBotan/765)?
В отличие от TCP, скорость передачи UDP предварительно закодирована (предопределена), поэтому нет медленного времени нарастания или ожидания потерянных пакетов.
FEC (Forward Error Correction) - техника помехоустойчивого кодирования и декодирования, позволяющая исправлять ошибки методом упреждения. Применяется для исправления сбоев и ошибок при передаче данных путём передачи избыточной служебной информации, на основе которой может быть восстановлено первоначальное содержание.
Использование FEC позволяет узлам восстанавливать передаваемые данные, даже если некоторые из них потерялись в пути. Дополнительные данные посылаются вдоль ретранслируемых блоков, так что принимающий узел может восстановить полные блоки, без контакта с отправляющим узлом.
FIBRE спроектирован как более децентрализованная альтернатива другим ретрансляционным сетям, например Fast Relay Network.
Ключевая особенность FIBRE в том, что он разработан как дополнение для ядра биткойна, поэтому каждый, кто управляет узлом, имеет возможность настроить свою собственную сеть.
Стоит отметить, что в 2018 году, была найдена (https://forklog.com/v-kode-bitkoina-ustranena-kriticheskaya-uyazvimost-v-techenie-dvuh-let-ugrozhavshaya-seti/) и исправлена уязвимость в Bitcoin Core, которая позволяла нарушить работу 90% нод и нарушить ограничение на максимальное количество биткоинов в обращении. Встроенный в сеть Bitcoin Core алгоритм The Fast Internet Bitcoin Relay Engine (FIBRE) мог облегчить работу при использовании уязвимости.
Для стека биткоина (https://t.me/CryptoBotan/888)
FIBRE (https://bitcoinfibre.org/) (Fast Internet Bitcoin Relay Engine - высокоскоростная ретрансляция блоков на базе сети Интернет) - это расширение для Bitcoin Core, которое обеспечивает ретрансляцию блоков с высокой скоростью и ручным выбором равноправных узлов по UDP.
UDP – это транспортный протокол, передающий сообщения без необходимости установки соединения в IP-сети. Его можно считать оптимальным протоколом для приложений, которые рассчитаны на широкую пропускную способность и быстрый обмен.
Биткойн - это одноранговая сеть, где узлы соединяются друг с другом случайным образом. Транзакции и блоки по этой сети передаются всем узлам. Пока все узлы получат информацию о блоке или транзакции должно пройти время. Тут то и проблема...Майнеры тратят некоторое количество времени на майнинг поверх старых блоков, когда сеть уже выбрала последний блок. Информация об этом, еще не дошла до всех узлов.
FIBRE решает проблему скорости распространения блоков.
Информация о блоках между узлами передается пакетами (порциями). Узел в сети получает каждый пакет и восстанавливает блоки из данных в этих пакетах и снова отправляет другим узлам, и снова в разных пакетах. Тут есть проблема: эти пакеты могут теряться и узлам необходимо повторно передавать данные, а это влияет на скорость передачи.
Основным улучшением в FIBRE является переход от использования TCP к использованию UDP с прямой коррекцией ошибок (FEC).
В чем разница между TCP и UDP (https://t.me/CryptoBotan/765)?
В отличие от TCP, скорость передачи UDP предварительно закодирована (предопределена), поэтому нет медленного времени нарастания или ожидания потерянных пакетов.
FEC (Forward Error Correction) - техника помехоустойчивого кодирования и декодирования, позволяющая исправлять ошибки методом упреждения. Применяется для исправления сбоев и ошибок при передаче данных путём передачи избыточной служебной информации, на основе которой может быть восстановлено первоначальное содержание.
Использование FEC позволяет узлам восстанавливать передаваемые данные, даже если некоторые из них потерялись в пути. Дополнительные данные посылаются вдоль ретранслируемых блоков, так что принимающий узел может восстановить полные блоки, без контакта с отправляющим узлом.
FIBRE спроектирован как более децентрализованная альтернатива другим ретрансляционным сетям, например Fast Relay Network.
Ключевая особенность FIBRE в том, что он разработан как дополнение для ядра биткойна, поэтому каждый, кто управляет узлом, имеет возможность настроить свою собственную сеть.
Стоит отметить, что в 2018 году, была найдена (https://forklog.com/v-kode-bitkoina-ustranena-kriticheskaya-uyazvimost-v-techenie-dvuh-let-ugrozhavshaya-seti/) и исправлена уязвимость в Bitcoin Core, которая позволяла нарушить работу 90% нод и нарушить ограничение на максимальное количество биткоинов в обращении. Встроенный в сеть Bitcoin Core алгоритм The Fast Internet Bitcoin Relay Engine (FIBRE) мог облегчить работу при использовании уязвимости.
К стеку Биткоина также можно отнести dPoW от Komodo
И причём здесь биткоин? Можно ли отнести к Ленину тех кто смотрит на него в мавзолее?
И какое отношение один из пользователей имеет к технологическому стеку биткоина? По твоей логике выходит что любой пользователь интернета имеет отношение к технологическому стеку интернета из-за того что использует его для своих нужд.
Это имеет отношению к использованию Биткоина для Data Anchoring . Этот кейс есть в табличке в первом посте.
Этот топик о стеке биткоина, а не о том кто и как им пользуется. Если следовать твоей логике, то надо всех пользователей записывать в причастных к стеку. Очень легко убедиться что использование не относится к теме топика. Представим что пользователей нет. Стек при этом останется? Я утверждаю что да.
TumbleBit решение для конфиденциальных транзакций BTC
Для стека биткоина (https://t.me/CryptoBotan/888)
TumbleBit (https://github.com/BUSEC/TumbleBit) - это однонаправленный, несвязываемый платежный хаб. Протокол для анонимных платежей, полностью совместимый с протоколом Биткойн, так как реализован в виде слоя поверх сети.
В прошлом посте о CoinSwap (https://t.me/CryptoBotan/967) я говорил, что TumbleBit решает вопрос с посредником, который знает о транзакции между А и Б, и потенциально может повторно восстановить связь между участниками.
Решение было предложено (https://eprint.iacr.org/2016/575.pdf) в 2016 году и представлено на конференции Scaling Bitcoin. После этого, другой разработчик, Николас Дориер презентовал свою имплементацию на языке C# - NTumbleBit. После чего она стала оффициальной имплементацией TumbleBit.
Платежи TumbleBit совершаются через посредника - Тамблер (Tumbler). Этот посредник не может деанонимизировать участников, украсть средства или выдать платежи сам себе.
TumbleBit позволяет совершать быстрые оффчейн платежи множеству получателей. Ничего не напоминает?? LN (https://t.me/CryptoBotan/600), Channel Factories (https://t.me/CryptoBotan/902). Платежи совершаются вне блокчейна, следовательно TumbleBit служит для масштабирования объема и скорости сети.
Участники открывают платежный канал, который депонирует BTC на депозитный адрес в блокчейн и совершают оффчейн платежи. Все как у LN, вот только с одной маленькой оговорочкой - эти платежи невозможно связать. Никто не может сказать кто перевел средства и кому их перевели.
Работает это так (по-крайней мере я так понял, да еще и долго думал писать или нет):
Для совершения неотслеживаемых транзакций используется TumbleBit, который решает криптографическую головоломку RSA (https://t.me/CryptoBotan/824).
А отправляет BTC в платежный канал с Тамблером (хабом). Средства принимаются только после того, как А представит решение головоломки. Это схема "Puzzle-Solver Protocol".
Б "заключает соглашение" с хабом. Тамблер заплатит Б после представления решения головоломки. Это схема "Puzzle-Promise Protocol".
TumbleBit знает, что решение действительно, но он не может точно определить, какую головоломку он решает, тем самым запутывая отношения между плательщиком и получателем.
TumbleBit также можно использовать как классический миксер, смешивая вместе передачу одного биткоина от Аn различных плательщиков к различным получателям Бn.
TumbleBit интегрирован с Tor, что уменьшает шанс быть раскрытым по IP, ведь пользователи подключаются к TumblerBit используя собственный адрес.
Сейчас идет поиск решений для повышения конфиденциальности сети Lightning при помощи TumblerBit.
Разработчики Stratis интегрировали TumbleBit в Breeze Wallet (пруф) (https://forklog.com/servis-mikshirovaniya-bitkoinov-tumblebit-budet-integrirovan-v-breeze-wallet/)
SPV (https://t.me/CryptoBotan/939) HiddenWallet поддерживает решение TumbleBit (пруф) (https://news.bitcoin.com/tumblebit-hiddenwallet-released/). Кстати, статьи, приведенные ниже, написаны разработчиком этого кошелька и он же интегрировал Tor в TumbleBit. ☺️
В транслейте читаются легко.
Объяснение TumbleBit Часть 1 (https://hackernoon.com/understanding-tumblebit-part-1-making-the-case-823d786113f3)
Объяснение TumbleBit Часть 2 (https://hackernoon.com/understanding-tumblebit-part-2-the-endgame-instant-anonymous-scaleable-payment-system-on-top-479e7eb9ca24)
Объяснение TumbleBit Часть 3 (https://hackernoon.com/understanding-tumblebit-part-3-not-even-the-tumbler-can-breach-your-privacy-how-8d49d89e3a0d)
GitHub NTumbleBit (https://github.com/NTumbleBit/NTumbleBit)
Documentation (https://eprint.iacr.org/2016/575.pdf)
Для стека биткоина (https://t.me/CryptoBotan/888)
TumbleBit (https://github.com/BUSEC/TumbleBit) - это однонаправленный, несвязываемый платежный хаб. Протокол для анонимных платежей, полностью совместимый с протоколом Биткойн, так как реализован в виде слоя поверх сети.
В прошлом посте о CoinSwap (https://t.me/CryptoBotan/967) я говорил, что TumbleBit решает вопрос с посредником, который знает о транзакции между А и Б, и потенциально может повторно восстановить связь между участниками.
Решение было предложено (https://eprint.iacr.org/2016/575.pdf) в 2016 году и представлено на конференции Scaling Bitcoin. После этого, другой разработчик, Николас Дориер презентовал свою имплементацию на языке C# - NTumbleBit. После чего она стала оффициальной имплементацией TumbleBit.
Платежи TumbleBit совершаются через посредника - Тамблер (Tumbler). Этот посредник не может деанонимизировать участников, украсть средства или выдать платежи сам себе.
TumbleBit позволяет совершать быстрые оффчейн платежи множеству получателей. Ничего не напоминает?? LN (https://t.me/CryptoBotan/600), Channel Factories (https://t.me/CryptoBotan/902). Платежи совершаются вне блокчейна, следовательно TumbleBit служит для масштабирования объема и скорости сети.
Участники открывают платежный канал, который депонирует BTC на депозитный адрес в блокчейн и совершают оффчейн платежи. Все как у LN, вот только с одной маленькой оговорочкой - эти платежи невозможно связать. Никто не может сказать кто перевел средства и кому их перевели.
Работает это так (по-крайней мере я так понял, да еще и долго думал писать или нет):
Для совершения неотслеживаемых транзакций используется TumbleBit, который решает криптографическую головоломку RSA (https://t.me/CryptoBotan/824).
А отправляет BTC в платежный канал с Тамблером (хабом). Средства принимаются только после того, как А представит решение головоломки. Это схема "Puzzle-Solver Protocol".
Б "заключает соглашение" с хабом. Тамблер заплатит Б после представления решения головоломки. Это схема "Puzzle-Promise Protocol".
TumbleBit знает, что решение действительно, но он не может точно определить, какую головоломку он решает, тем самым запутывая отношения между плательщиком и получателем.
TumbleBit также можно использовать как классический миксер, смешивая вместе передачу одного биткоина от Аn различных плательщиков к различным получателям Бn.
TumbleBit интегрирован с Tor, что уменьшает шанс быть раскрытым по IP, ведь пользователи подключаются к TumblerBit используя собственный адрес.
Сейчас идет поиск решений для повышения конфиденциальности сети Lightning при помощи TumblerBit.
Разработчики Stratis интегрировали TumbleBit в Breeze Wallet (пруф) (https://forklog.com/servis-mikshirovaniya-bitkoinov-tumblebit-budet-integrirovan-v-breeze-wallet/)
SPV (https://t.me/CryptoBotan/939) HiddenWallet поддерживает решение TumbleBit (пруф) (https://news.bitcoin.com/tumblebit-hiddenwallet-released/). Кстати, статьи, приведенные ниже, написаны разработчиком этого кошелька и он же интегрировал Tor в TumbleBit. ☺️
В транслейте читаются легко.
Объяснение TumbleBit Часть 1 (https://hackernoon.com/understanding-tumblebit-part-1-making-the-case-823d786113f3)
Объяснение TumbleBit Часть 2 (https://hackernoon.com/understanding-tumblebit-part-2-the-endgame-instant-anonymous-scaleable-payment-system-on-top-479e7eb9ca24)
Объяснение TumbleBit Часть 3 (https://hackernoon.com/understanding-tumblebit-part-3-not-even-the-tumbler-can-breach-your-privacy-how-8d49d89e3a0d)
GitHub NTumbleBit (https://github.com/NTumbleBit/NTumbleBit)
Documentation (https://eprint.iacr.org/2016/575.pdf)
sr. member
Activity: 938
Merit: 466
~[f#
К стеку Биткоина также можно отнести dPoW от Komodo
И причём здесь биткоин? Можно ли отнести к Ленину тех кто смотрит на него в мавзолее?
И какое отношение один из пользователей имеет к технологическому стеку биткоина? По твоей логике выходит что любой пользователь интернета имеет отношение к технологическому стеку интернета из-за того что использует его для своих нужд.
Это имеет отношению к использованию Биткоина для Data Anchoring . Этот кейс есть в табличке в первом посте.
К стеку Биткоина также можно отнести dPoW от Komodo
И причём здесь биткоин? Можно ли отнести к Ленину тех кто смотрит на него в мавзолее?
И какое отношение один из пользователей имеет к технологическому стеку биткоина? По твоей логике выходит что любой пользователь интернета имеет отношение к технологическому стеку интернета из-за того что использует его для своих нужд.
sr. member
Activity: 938
Merit: 466
~[f#
К стеку Биткоина также можно отнести dPoW от Komodo
И причём здесь биткоин? Можно ли отнести к Ленину тех кто смотрит на него в мавзолее?
К стеку Биткоина также можно отнести dPoW от Komodo
И причём здесь биткоин? Можно ли отнести к Ленину тех кто смотрит на него в мавзолее?
Технология CoinSwap
Для стека биткоина (https://t.me/CryptoBotan/888)
Вы А и хотите отправить транзакцию продавцу Б, но не хотите, чтобы Б мог отследить ваши транзакции. Участник сети В предлагает свои услуги в виде посредника: он получает ваши монеты и отправляет Б другие - несвязанные монеты. Но в такой ситуации отсутствует доверие к каждой из сторон, ну если конечно вы не лучшие кореша, и то не всегда это доверие есть...
CoinSwap - это альтернативный метод обеспечения приватности для биткоина не связанный с хранением конфиденциальности, основанный на идее атомарных свопов. CoinSwap был предложен в 2013 году Грегори Максвеллом.
А может отправить BTC Б через В, где В не может их обмануть. А меняет BTC на то же количество BTC Б (минус комиссия), и делается это при помощи смарт-контрактов биткоина, чтобы исключить возможность мошенничества с любой из сторон. Проблема мошенничества решается при помощи "Hash time lock contracts" (HTLC) (https://t.me/CryptoBotan/819).
Протокол требует четырех опубликованных транзакций, но транзакции выглядят как обычные 2 из 2 escrow transaction (два escrow платежа, два ecrow выпуска).
CoinSwaps разрушает связь транзакций между отправленными и полученными биткоинами. В блокчейне это выглядит как два набора полностью несвязанных транзакций:
Адрес А ---> эскроу адрес 1 ---> Адрес Б
Адрес Б ---> эскроу адрес 2 ---> Адрес А
Если сравнивать CoinJoin и CoinSwap, то можно определить некоторые существенные недостатки и преимущества.
Операции CoinJoin (https://t.me/CryptoBotan/584) эффективны при объединении транзакций и могут экономить немного места. CoinSwap требует минимум четырех транзакций, хотя две Coinswap могут эффективно выполняться одновременно.
Набор анонимности CoinJoin равен количеству участников транзакции (или каскада транзакций). Набор анонимности CoinSwap - это все Coinswap происходящие одновременно, даже если пользователи не взаимодействуют друг с другом.
Транзакции CoinSwap выглядят как обычные транзакции 2-2 escrow. Если 2-2 escrow становятся общими, то операции CoinSwap могут быть менее идентифицируемыми, чем крупные операции CoinJoin с кучей выходов одинакового размера, и, следовательно, более устойчивыми к цензуре.
CoinSwaps требуют большого количества взаимодействий между вовлеченными сторонами, что может усложнить проектирование системы и избежать атак типа "отказ в обслуживании". Участники всегда должны иметь доступ к сети. Если интернет будет отключен, то наполовину завершенный CoinSwap может закончиться кражей средств одной из сторон.
Для достижения конфиденциальности, CoinJoin должна иметь много участников. Это усложняет разработку ПО.
CoinSwap эффективно нарушает связь между транзакциями в блокчейне, но это не решает всех проблем приватности и взаимозаменяемости. Посредник в сделке, все же знает о транзакции и может повторно восстановить связь между ними.
Именно эти проблемы и решает TumbleBit, о чем и напишу чуть позже.
Для стека биткоина (https://t.me/CryptoBotan/888)
Вы А и хотите отправить транзакцию продавцу Б, но не хотите, чтобы Б мог отследить ваши транзакции. Участник сети В предлагает свои услуги в виде посредника: он получает ваши монеты и отправляет Б другие - несвязанные монеты. Но в такой ситуации отсутствует доверие к каждой из сторон, ну если конечно вы не лучшие кореша, и то не всегда это доверие есть...
CoinSwap - это альтернативный метод обеспечения приватности для биткоина не связанный с хранением конфиденциальности, основанный на идее атомарных свопов. CoinSwap был предложен в 2013 году Грегори Максвеллом.
А может отправить BTC Б через В, где В не может их обмануть. А меняет BTC на то же количество BTC Б (минус комиссия), и делается это при помощи смарт-контрактов биткоина, чтобы исключить возможность мошенничества с любой из сторон. Проблема мошенничества решается при помощи "Hash time lock contracts" (HTLC) (https://t.me/CryptoBotan/819).
Протокол требует четырех опубликованных транзакций, но транзакции выглядят как обычные 2 из 2 escrow transaction (два escrow платежа, два ecrow выпуска).
CoinSwaps разрушает связь транзакций между отправленными и полученными биткоинами. В блокчейне это выглядит как два набора полностью несвязанных транзакций:
Адрес А ---> эскроу адрес 1 ---> Адрес Б
Адрес Б ---> эскроу адрес 2 ---> Адрес А
Если сравнивать CoinJoin и CoinSwap, то можно определить некоторые существенные недостатки и преимущества.
Операции CoinJoin (https://t.me/CryptoBotan/584) эффективны при объединении транзакций и могут экономить немного места. CoinSwap требует минимум четырех транзакций, хотя две Coinswap могут эффективно выполняться одновременно.
Набор анонимности CoinJoin равен количеству участников транзакции (или каскада транзакций). Набор анонимности CoinSwap - это все Coinswap происходящие одновременно, даже если пользователи не взаимодействуют друг с другом.
Транзакции CoinSwap выглядят как обычные транзакции 2-2 escrow. Если 2-2 escrow становятся общими, то операции CoinSwap могут быть менее идентифицируемыми, чем крупные операции CoinJoin с кучей выходов одинакового размера, и, следовательно, более устойчивыми к цензуре.
CoinSwaps требуют большого количества взаимодействий между вовлеченными сторонами, что может усложнить проектирование системы и избежать атак типа "отказ в обслуживании". Участники всегда должны иметь доступ к сети. Если интернет будет отключен, то наполовину завершенный CoinSwap может закончиться кражей средств одной из сторон.
Для достижения конфиденциальности, CoinJoin должна иметь много участников. Это усложняет разработку ПО.
CoinSwap эффективно нарушает связь между транзакциями в блокчейне, но это не решает всех проблем приватности и взаимозаменяемости. Посредник в сделке, все же знает о транзакции и может повторно восстановить связь между ними.
Именно эти проблемы и решает TumbleBit, о чем и напишу чуть позже.
sr. member
Activity: 938
Merit: 466
~[f#
https://www.cryptoninjas.net/2020/03/05/interlay-awarded-grant-to-create-bitcoin-btc-polkadot-dot-bridge/ -Interlay awarded grant to create Bitcoin (BTC) – Polkadot (DOT) bridge
Протокол конфиденциальности Dandelion
Для стека биткоина (https://t.me/CryptoBotan/888)
Начну я с презентации своих старых постов на тему конфиденциальности:
MimbleWimble (https://t.me/CryptoBotan/805)
CoinJoin, CoinShuffle и Stealth-Addresses (https://t.me/CryptoBotan/584)
Bulletproofs (https://t.me/CryptoBotan/878)
Теперь к нашим "Одуванчикам" (англ. Dandelion)...
Биткоин можно разделить на два уровня функционирования:
1) Прикладной уровень: управление транзакциями, блокчейн, майнинг, идентификация узлов в сети по PublicKey
2) Сетевой уровень: обработка связей между узлами через P2P-сеть, идентификация узлов по IP.
Суть в том, что сетевой уровень должен обладать:
а) низкой задержкой. Максимальное время, за которое сообщение достигнет всех узлов сети, должно быть небольшим и ограниченным.
б) анонимность. Невозможность связать сообщения от транзакциях с IP-адресом, который инициировал транзакцию.
Совершая транзакцию с узла, она передается всем связанным узлам, далее другим связанным, и по цепочке. Думаю, всем известный факт...Создается цепочка, которую можно отследить до начального узла. Каждый узел получающий данные о транзакции, становится доступным для запроса. Передача транзакции происходит с экспоненциальными задержками, что позволяет якобы усилить анонимность IP-адреса, но такое решение ее не обеспечивает. Ссылка (https://habr.com/ru/post/363769/), где объясняется способ деанонимизации транзакций и вычисление IP.
Летом 2017 года Shaileshh Bojja, Giulia Fant, Pramod Viswanath опубликовали BIP (https://github.com/dandelion-org/bips/blob/master/bip-dandelion.mediawiki#Implementation) - сетевое решение для Биткойна, которое легко интегрируется в существующие блокчейн-сети. Протокол Dandelion - это решение для улучшения анонимизации на сетевом уровне.
Dandelion повышает конфиденциальность пользователей, отправляя транзакции через фазу анонимности, прежде чем передать их по сети. Dandelion повышает конфиденциальность за счет нарушения симметрии диффузии (форма передачи транзакции), и смешивания транзакций путем пересылки сообщений из разных источников по одному и тому же пути.
Версия "Одуванчик" предложенная в 2017 году имела ряд недостатков и потому в 2018 году вышла новая версия - Dandelion++. Протокол делает попытку деанонимизации - непрактичным.
Работает это все по аналогии с одуванчиком (см. рисунок ниже):
1) Stem Phase (фаза стебля)
Этот этап предназначен для избежания отслеживания транзакций к исходной. Каждый узел отправляет транзакцию одному рандомному (на основе алгоритма) узлу. Этот узел передает сообщение о транзакции другому рандомному узлу и т.д. Информация передается по переплетенным маршрутам. Они могут быть фрагментированы, но распространение ограничено локально. То есть транзакция остается анонимной для сети, кроме тех узлов, которые ее получают. В какой-то точке (каком-то из узлов) сообщение о транзакции транслируется в сеть. Эта какая-то точка определяется протоколом. Выбирается 4 одноранговых узла, позволяющих использовать 2 пути для передачи сообщения о транзакции.
2) Fluff Phase (фаза пуха)
Начало процесса диффузии (передачи транзакций в сеть).
"Распушивание" транзакции происходит либо:
- путем вероятностной игры, когда каждый узел, который получал транзакцию в фазе стебля с 90%-ой вероятностью, передает сообщение дальше
- путем истечения времени задержки, которое определяется индивидуально каждым узлом на фазе стебля.
Важно заметить, что при передаче сообщения о транзакции на стебле, каждый узел проверяет сеть на наличие этой транзакции. Если эта транзакция появилась в сети, узлы передают копию сообщения в сеть.
Протокол не требует сложных вычислений и может быть развернут без каких-либо изменений в базовом протоколе сети Биткойн.
Для стека биткоина (https://t.me/CryptoBotan/888)
Начну я с презентации своих старых постов на тему конфиденциальности:
MimbleWimble (https://t.me/CryptoBotan/805)
CoinJoin, CoinShuffle и Stealth-Addresses (https://t.me/CryptoBotan/584)
Bulletproofs (https://t.me/CryptoBotan/878)
Теперь к нашим "Одуванчикам" (англ. Dandelion)...
Биткоин можно разделить на два уровня функционирования:
1) Прикладной уровень: управление транзакциями, блокчейн, майнинг, идентификация узлов в сети по PublicKey
2) Сетевой уровень: обработка связей между узлами через P2P-сеть, идентификация узлов по IP.
Суть в том, что сетевой уровень должен обладать:
а) низкой задержкой. Максимальное время, за которое сообщение достигнет всех узлов сети, должно быть небольшим и ограниченным.
б) анонимность. Невозможность связать сообщения от транзакциях с IP-адресом, который инициировал транзакцию.
Совершая транзакцию с узла, она передается всем связанным узлам, далее другим связанным, и по цепочке. Думаю, всем известный факт...Создается цепочка, которую можно отследить до начального узла. Каждый узел получающий данные о транзакции, становится доступным для запроса. Передача транзакции происходит с экспоненциальными задержками, что позволяет якобы усилить анонимность IP-адреса, но такое решение ее не обеспечивает. Ссылка (https://habr.com/ru/post/363769/), где объясняется способ деанонимизации транзакций и вычисление IP.
Летом 2017 года Shaileshh Bojja, Giulia Fant, Pramod Viswanath опубликовали BIP (https://github.com/dandelion-org/bips/blob/master/bip-dandelion.mediawiki#Implementation) - сетевое решение для Биткойна, которое легко интегрируется в существующие блокчейн-сети. Протокол Dandelion - это решение для улучшения анонимизации на сетевом уровне.
Dandelion повышает конфиденциальность пользователей, отправляя транзакции через фазу анонимности, прежде чем передать их по сети. Dandelion повышает конфиденциальность за счет нарушения симметрии диффузии (форма передачи транзакции), и смешивания транзакций путем пересылки сообщений из разных источников по одному и тому же пути.
Версия "Одуванчик" предложенная в 2017 году имела ряд недостатков и потому в 2018 году вышла новая версия - Dandelion++. Протокол делает попытку деанонимизации - непрактичным.
Работает это все по аналогии с одуванчиком (см. рисунок ниже):
1) Stem Phase (фаза стебля)
Этот этап предназначен для избежания отслеживания транзакций к исходной. Каждый узел отправляет транзакцию одному рандомному (на основе алгоритма) узлу. Этот узел передает сообщение о транзакции другому рандомному узлу и т.д. Информация передается по переплетенным маршрутам. Они могут быть фрагментированы, но распространение ограничено локально. То есть транзакция остается анонимной для сети, кроме тех узлов, которые ее получают. В какой-то точке (каком-то из узлов) сообщение о транзакции транслируется в сеть. Эта какая-то точка определяется протоколом. Выбирается 4 одноранговых узла, позволяющих использовать 2 пути для передачи сообщения о транзакции.
2) Fluff Phase (фаза пуха)
Начало процесса диффузии (передачи транзакций в сеть).
"Распушивание" транзакции происходит либо:
- путем вероятностной игры, когда каждый узел, который получал транзакцию в фазе стебля с 90%-ой вероятностью, передает сообщение дальше
- путем истечения времени задержки, которое определяется индивидуально каждым узлом на фазе стебля.
Важно заметить, что при передаче сообщения о транзакции на стебле, каждый узел проверяет сеть на наличие этой транзакции. Если эта транзакция появилась в сети, узлы передают копию сообщения в сеть.
Протокол не требует сложных вычислений и может быть развернут без каких-либо изменений в базовом протоколе сети Биткойн.
sr. member
Activity: 938
Merit: 466
~[f#
Сам рынок предсказаний это интересная тема. В отношении "мудрости толпы" сложно сказать - возможно это работает в каких - то определенных обстоятельствах и ситуациях.
Но рынки предсказаний можно рассматривать, как альтернативы криптобиржам.
Почему они могут быть интересны ?
Сейчас на криптобиржах торгую очень опытные трейдеры. Это люди пришедшие из фонды, но уже успевшие получить хороший опыт на крипте.
А на рынках предсказаний (особенно поначалу) таких профи может не быть.
И человек, умеюший правильно оценивать вероятности, может неплохо там проявить и хорошо заработать ☺
sr. member
Activity: 938
Merit: 466
~[f#
https://bitcoinops.org/en/newsletters/2020/02/19/ -Bitcoin Optech Newsletter #85
https://bitcoinops.org/en/newsletters/2020/02/26/ -Bitcoin Optech Newsletter #86
https://bitcoinops.org/en/newsletters/2020/02/26/ -Bitcoin Optech Newsletter #86
Для стека биткоина(https://t.me/CryptoBotan/888)
Bitcoin Hivemind (http://bitcoinhivemind.com/) ( в прошлом Truthcoin) - это opensource, P2P протокол Oracle, предложенный Paul Sztorc и функционирующий как сайдчейн, который дает возможность вносить в блокчейн точные данные, позволяющие владельцам биткоинов спекулировать на рынке прогнозов. Т.е. он позволяет использовать BTC для создания "PM"- “prediction markets” (рынков прогнозирования) и участия в них.
Рынки прогнозирования - это инструменты для принятия решений определяемых рыночными силами, и в то же время устраняющие большую часть шума и неопределенности, которые мешают процессу принятия решений. Они используют прогнозы пользователей для сбора информации о будущих событиях.
Одна из основных концепций PM заключается в том, что если вы не согласны с тем, что показывает рынок, то вы можете воспользоваться этими маржами и сделать ставку против рынка.
Такие проекты как Augur (https://www.augur.net/) и Gnosis (https://gnosis.io/) опираются на понятие “Wisdom of the Crowd” - мудрость толпы - явление, в котором коллективные предсказания группы людей обычно более точны, чем индивидуальные, даже если толпа состоит не из экспертов, а один человек таковым является.
Hivemind является методом краудсорсинга для определения вероятных исходов событий и фокусируется на управлении, решая проблемы с многофакторным принятием решений.
У Hivemind есть пользователи и “employees”. Эти "employees" работают в "филиалах “(каждый филиал напоминает товарооборотную биржу) и голосуют за ”решения“ (результаты выборов или ценовые каналы), которые разрешают ”рынки" (торговые арены, определенные одним или несколькими решениями). Пользователи могут свободно создавать любые решения или рынки, которые им нравятся, несмотря на то, что они экономически конкурируют за ограниченные “слоты принятия решений”.
Hivemind - это сайдчейн, который использует двойную схему токенов с биткойном, функционирующим в качестве пользовательского уровня, и VoteCoins в качестве уровня репутации/“employees”. Ценность биткойна отражает именно то, что он делает — хранилище ценности, — в то время как VoteCoins используются для обозначения репутации пользователя на платформе.
Любой пользователь может создать рынок предсказаний, если он способен заплатить за него BTC.
Все решения добавляются в блокчейн самостоятельно. Авторам впоследствии нужно предоставить стартовый капитал, чтобы обеспечить начальную ликвидность рынка и “сделать рынок"."Авторы получают выгоду от создания рынка и его использования, но также несут ответственность за поддержание рынка и все затраты ресурсов, связанные с его созданием.
Торговая активность должна сходиться к рыночной цене вероятного "состояния" события, но такая точность требует высоколиквидного и активного рынка, что требует времени для развития, особенно когда это PM, построенный на новой технологии, такой как биткойн.
На вопрос чем HiveMind лучше Augur и Gnosis, ответ прост...HiveMind - это P2P-протокол, а значит децентрализован, в отличие от двух других.
WhitePaper (http://bitcoinhivemind.com/papers/truthcoin-whitepaper.pdf)
Bitcoin Hivemind (http://bitcoinhivemind.com/) ( в прошлом Truthcoin) - это opensource, P2P протокол Oracle, предложенный Paul Sztorc и функционирующий как сайдчейн, который дает возможность вносить в блокчейн точные данные, позволяющие владельцам биткоинов спекулировать на рынке прогнозов. Т.е. он позволяет использовать BTC для создания "PM"- “prediction markets” (рынков прогнозирования) и участия в них.
Рынки прогнозирования - это инструменты для принятия решений определяемых рыночными силами, и в то же время устраняющие большую часть шума и неопределенности, которые мешают процессу принятия решений. Они используют прогнозы пользователей для сбора информации о будущих событиях.
Одна из основных концепций PM заключается в том, что если вы не согласны с тем, что показывает рынок, то вы можете воспользоваться этими маржами и сделать ставку против рынка.
Такие проекты как Augur (https://www.augur.net/) и Gnosis (https://gnosis.io/) опираются на понятие “Wisdom of the Crowd” - мудрость толпы - явление, в котором коллективные предсказания группы людей обычно более точны, чем индивидуальные, даже если толпа состоит не из экспертов, а один человек таковым является.
Hivemind является методом краудсорсинга для определения вероятных исходов событий и фокусируется на управлении, решая проблемы с многофакторным принятием решений.
У Hivemind есть пользователи и “employees”. Эти "employees" работают в "филиалах “(каждый филиал напоминает товарооборотную биржу) и голосуют за ”решения“ (результаты выборов или ценовые каналы), которые разрешают ”рынки" (торговые арены, определенные одним или несколькими решениями). Пользователи могут свободно создавать любые решения или рынки, которые им нравятся, несмотря на то, что они экономически конкурируют за ограниченные “слоты принятия решений”.
Hivemind - это сайдчейн, который использует двойную схему токенов с биткойном, функционирующим в качестве пользовательского уровня, и VoteCoins в качестве уровня репутации/“employees”. Ценность биткойна отражает именно то, что он делает — хранилище ценности, — в то время как VoteCoins используются для обозначения репутации пользователя на платформе.
Любой пользователь может создать рынок предсказаний, если он способен заплатить за него BTC.
Все решения добавляются в блокчейн самостоятельно. Авторам впоследствии нужно предоставить стартовый капитал, чтобы обеспечить начальную ликвидность рынка и “сделать рынок"."Авторы получают выгоду от создания рынка и его использования, но также несут ответственность за поддержание рынка и все затраты ресурсов, связанные с его созданием.
Торговая активность должна сходиться к рыночной цене вероятного "состояния" события, но такая точность требует высоколиквидного и активного рынка, что требует времени для развития, особенно когда это PM, построенный на новой технологии, такой как биткойн.
На вопрос чем HiveMind лучше Augur и Gnosis, ответ прост...HiveMind - это P2P-протокол, а значит децентрализован, в отличие от двух других.
WhitePaper (http://bitcoinhivemind.com/papers/truthcoin-whitepaper.pdf)
libMiniScetch - библиотека для согласования наборов.
Для стека биткоина
(https://t.me/CryptoBotan/888)⬇️⬇️⬇️
libMiniSketch - это автономная библиотека API для построения и декодирования эскизов наборов, использующаяся для согласования компактных наборов.
В посте про Erlay (https://t.me/CryptoBotan/955), я упоминал, что MiniSketch используется для сверки и согласования транзакций.
Minisketch создает библиотеку данных, которая будет использоваться для построения эскизов наборов (наборов данных транзакций). Узлы и майнеры могут затем использовать эти наборы для сверки компактных наборов.
MiniSketch использует коды исправления ошибок для передачи набора транзакций одноранговому узлу с неизвестным, но похожим набором, используя пропускную способность, равную только размеру разницы, а не размеру самих наборов. Т.е. почти половина пропускной способности, которую потребляет узел, можно сэкономить.
Узлы пытаются выяснить, каковы различия между двумя наборами, хранящимися на разных компьютерах, минимизируя при этом, количество данных которое должно быть обменено между ними.
Эскизы имеют заданную емкость, и когда количество элементов в наборе не превышает эту емкость, libminisketch всегда будет восстанавливать весь набор из эскиза.
Суть эскизов (Sketch) в том, чтобы иметь пакет данных, содержащий id для всех транзакций, которые узел принял (после последней выверки), но в компактной форме. Используя эскизы, узел может вычислить, какие транзакции у него есть, по сравнению с другими узлами. После этого он может запросить только те транзакции у тех одноранговых узлов, которые не отображаются в их эскизе.
Если у А и Б есть набор элементов, и они подозревают, что наборы в значительной степени, но не полностью перекрываются, они могут использовать протокол, чтобы позволить обеим сторонам изучить все элементы.
Мне понравилось вот такое описание решения :
Операторам узлов нужно сравнивать заметки о транзакционных данных. Это позволит им набрасывать (создавать) наборы (списки) транзакций, и программа будет перепроверять эти наборы, чтобы увидеть, какие данные встречаются в одном, но не в обоих наборах. И вместо того, чтобы тратить время и энергию на раскрытие всех этих данных друг другу, узлам с minisketch нужно знать только разницу между их наборами транзакций, чтобы создать полный набор.
У меня есть множество 3, 5, 7, 11, а у вас 3, 5, 7, 9, 11. Очевидно, что разница 9. Мы оба вычисляем сумму наших элементов:
3+5+7+11=26 - у меня
3+5+7+9+11=35 - у вас
Я посылаю вам свою сумму 26 и вы вычитаете ее из своей суммы. Разница равна 9.
GitHub (https://github.com/sipa/minisketch)
Для стека биткоина
(https://t.me/CryptoBotan/888)⬇️⬇️⬇️
libMiniSketch - это автономная библиотека API для построения и декодирования эскизов наборов, использующаяся для согласования компактных наборов.
В посте про Erlay (https://t.me/CryptoBotan/955), я упоминал, что MiniSketch используется для сверки и согласования транзакций.
Minisketch создает библиотеку данных, которая будет использоваться для построения эскизов наборов (наборов данных транзакций). Узлы и майнеры могут затем использовать эти наборы для сверки компактных наборов.
MiniSketch использует коды исправления ошибок для передачи набора транзакций одноранговому узлу с неизвестным, но похожим набором, используя пропускную способность, равную только размеру разницы, а не размеру самих наборов. Т.е. почти половина пропускной способности, которую потребляет узел, можно сэкономить.
Узлы пытаются выяснить, каковы различия между двумя наборами, хранящимися на разных компьютерах, минимизируя при этом, количество данных которое должно быть обменено между ними.
Эскизы имеют заданную емкость, и когда количество элементов в наборе не превышает эту емкость, libminisketch всегда будет восстанавливать весь набор из эскиза.
Суть эскизов (Sketch) в том, чтобы иметь пакет данных, содержащий id для всех транзакций, которые узел принял (после последней выверки), но в компактной форме. Используя эскизы, узел может вычислить, какие транзакции у него есть, по сравнению с другими узлами. После этого он может запросить только те транзакции у тех одноранговых узлов, которые не отображаются в их эскизе.
Если у А и Б есть набор элементов, и они подозревают, что наборы в значительной степени, но не полностью перекрываются, они могут использовать протокол, чтобы позволить обеим сторонам изучить все элементы.
Мне понравилось вот такое описание решения :
Операторам узлов нужно сравнивать заметки о транзакционных данных. Это позволит им набрасывать (создавать) наборы (списки) транзакций, и программа будет перепроверять эти наборы, чтобы увидеть, какие данные встречаются в одном, но не в обоих наборах. И вместо того, чтобы тратить время и энергию на раскрытие всех этих данных друг другу, узлам с minisketch нужно знать только разницу между их наборами транзакций, чтобы создать полный набор.
У меня есть множество 3, 5, 7, 11, а у вас 3, 5, 7, 9, 11. Очевидно, что разница 9. Мы оба вычисляем сумму наших элементов:
3+5+7+11=26 - у меня
3+5+7+9+11=35 - у вас
Я посылаю вам свою сумму 26 и вы вычитаете ее из своей суммы. Разница равна 9.
GitHub (https://github.com/sipa/minisketch)
sr. member
Activity: 938
Merit: 466
~[f#
https://basicblockradio.libsyn.com/-110-square-crypto-ldk-bitcoin - ББ-110: Арик Сосман (Square Crypto) об LDK и поддержке Bitcoin-экосистемы
https://basicblockradio.libsyn.com/-108-bluewallet-lightning - ББ-108: Игорь Корсаков (Bluewallet) о Lightning-кошельках
https://basicblockradio.libsyn.com/-108-bluewallet-lightning - ББ-108: Игорь Корсаков (Bluewallet) о Lightning-кошельках
Erlay может существенно сократить объем пропускной способности (на ≈40%), необходимой для поддержания текущего уровня подключения между биткойн-узлами.
Это, конечно, хорошо. Лишний раз показывает, что еще много что можно оптимизировать в Биткоине только за счет программирования.С другой стороны, можно прикинуть эффект от внедрения. Учитывая, что в ближайшем будущем блок не планируют увеличивать.
Сейчас у нас транзакций транслируется по сети где-то на 1.25мб каждые 10 минут, может вырасти до 1.5 мб.
"50% пропускной способности, необходимой для запуска узла используется для объявления транзакций. 45% - для ретрансляции данных о транзакции." - исходя из этого, на объявление транзакций приходится еще ~1.5мб каждые 10 минут. Итого, в среднем, каждая фулл-нода на трансляцию транзакций тратит 3мб пропускной способности.
Для соединения 100мбит/сек. а это ~10мб/сек, на это тратится, ВНИМАНИЕ, 0.3 секунды. Каждые 10 минут фулл-нода тратит всего 0.3 секунды!!!
Внедрим оптимизацию Erlay - будет 0.15 сек. Это же ПШИК. Фулл-ноды просто не заметят этой оптимизации. Даже с помощью тестов, боюсь, нельзя будет увидеть. Это же на уровне статистической погрешности.
Можно взять соединение 10мбит/с . 3 сек на 10мин, после оптимизации 1,5 сек. Практически, нулевой эффект.
Что получается. На данный момент средний компьютер со средним интернетом с легкостью справляется с ролью фулл-ноды. Настолько легко, что любые оптимизации уже ничего не дают.
Erlay - новый протокол выполнения транзакций.
Для стека биткоина
(https://t.me/CryptoBotan/888)⬇️⬇️⬇️
Протокол был представлен в рассылке для разработчиков BTC (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016994.html) 28 мая 2019 года. Разработчиками решения являются: Грегори Максвелл, Питер Велле и Глеб Науменко.
Как известно, новая транзакция, при трансляции в сеть, отправляется на все узлы в сети.
Как это происходит:
После получения транзакции, узел отправляет id транзакции всем узлам, с которыми он связан (кроме того, от которого он получил транзакцию). Все эти узлы проверяют этот id, дабы удостовериться, получили ли они эту транзакцию от другого узла. Если не получили, то они запрашивают всю транзакцию от узла, который отправил id этой транзакции. Затем процесс повторяется снова...
Так как узлы совместно используют id транзакций с узлами, которые уже отправили транзакцию, образуется множество ненужных сообщений используемых в сети BTC. Эти сообщения "жрут" пропускную способность сети. 50% пропускной способности, необходимой для запуска узла используется для объявления транзакций. 45% - для ретрансляции данных о транзакции. Согласно разработчикам, 44% всего трафика - это избыточные сообщения.
Протокол Erlay сделает так, что в обработке транзакций будет участвовать только 8 узлов (в дальнейшем 32). Т.е. узлы, как и сейчас, будут использовать новые id транзакций со своими связанными узлами, но они будут отправлять id транзакции только 8-ми случайным узлам, даже если связей с другими узлами больше. Затем, связанные узлы запросят "Sketch", который содержит id для всех транзакций, принятых узлом, в компактной форме.
Ретрансляция данных о транзакциях будет происходить путем периодического запуска протокола сверки по каждому соединению. При помощи библиотеки MiniScetch - транзакции можно будет согласовать с другими узлами.
Этот протокол сверки уже разработан, но пока не разобран мной для стека, но не все сразу😅
Такой подход совершения транзакций позволит более эффективно передавать id транзакций, сокращая количество сообщений, передаваемых между узлами, при сохранении поддержки передачи новых транзакций всем узлам.
Erlay может существенно сократить объем пропускной способности (на ≈40%), необходимой для поддержания текущего уровня подключения между биткойн-узлами.
Дополнительной плюшкой решения Erlay является улучшение конфиденциальности. Так как id транзакций не являются общими для всех узлов, то труднее отслеживать появление конкретных транзакций. Также, Erlay делает сеть более устойчивой к ряду нескольких атак, таких как: атака по времени (https://ru.wikipedia.org/wiki/%D0%90%D1%82%D0%B0%D0%BA%D0%B0_%D0%BF%D0%BE_%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8) и атака Eclipse (https://eprint.iacr.org/2015/263.pdf)
Для стека биткоина
(https://t.me/CryptoBotan/888)⬇️⬇️⬇️
Протокол был представлен в рассылке для разработчиков BTC (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016994.html) 28 мая 2019 года. Разработчиками решения являются: Грегори Максвелл, Питер Велле и Глеб Науменко.
Как известно, новая транзакция, при трансляции в сеть, отправляется на все узлы в сети.
Как это происходит:
После получения транзакции, узел отправляет id транзакции всем узлам, с которыми он связан (кроме того, от которого он получил транзакцию). Все эти узлы проверяют этот id, дабы удостовериться, получили ли они эту транзакцию от другого узла. Если не получили, то они запрашивают всю транзакцию от узла, который отправил id этой транзакции. Затем процесс повторяется снова...
Так как узлы совместно используют id транзакций с узлами, которые уже отправили транзакцию, образуется множество ненужных сообщений используемых в сети BTC. Эти сообщения "жрут" пропускную способность сети. 50% пропускной способности, необходимой для запуска узла используется для объявления транзакций. 45% - для ретрансляции данных о транзакции. Согласно разработчикам, 44% всего трафика - это избыточные сообщения.
Протокол Erlay сделает так, что в обработке транзакций будет участвовать только 8 узлов (в дальнейшем 32). Т.е. узлы, как и сейчас, будут использовать новые id транзакций со своими связанными узлами, но они будут отправлять id транзакции только 8-ми случайным узлам, даже если связей с другими узлами больше. Затем, связанные узлы запросят "Sketch", который содержит id для всех транзакций, принятых узлом, в компактной форме.
Ретрансляция данных о транзакциях будет происходить путем периодического запуска протокола сверки по каждому соединению. При помощи библиотеки MiniScetch - транзакции можно будет согласовать с другими узлами.
Этот протокол сверки уже разработан, но пока не разобран мной для стека, но не все сразу😅
Такой подход совершения транзакций позволит более эффективно передавать id транзакций, сокращая количество сообщений, передаваемых между узлами, при сохранении поддержки передачи новых транзакций всем узлам.
Erlay может существенно сократить объем пропускной способности (на ≈40%), необходимой для поддержания текущего уровня подключения между биткойн-узлами.
Дополнительной плюшкой решения Erlay является улучшение конфиденциальности. Так как id транзакций не являются общими для всех узлов, то труднее отслеживать появление конкретных транзакций. Также, Erlay делает сеть более устойчивой к ряду нескольких атак, таких как: атака по времени (https://ru.wikipedia.org/wiki/%D0%90%D1%82%D0%B0%D0%BA%D0%B0_%D0%BF%D0%BE_%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8) и атака Eclipse (https://eprint.iacr.org/2015/263.pdf)
sr. member
Activity: 938
Merit: 466
~[f#
https://arxiv.org/pdf/2002.02819.pdf -Ресерч про централизацию в Латнинге
Нашел вот более подробное описание работы Тапрут
Нашел вот более подробное описание работы Тапрут
Quote
Taproot: что это и зачем он нужен
(Этот пост — часть большого паззла. Дописав его я понял, что нужно было бы написать вводный пост по криптографии и некоторым важным механикам. Буду раскрывать тему постепенно.)
P2SH-транзакции (оплата на хэш скрипта), по сути, позволяют создавать смарт-контракты на Биткоине (хоть они и способны лишь проверять права доступа к биткам). Но по сравнению с обычным переводом битков у этого способа есть существенный недостаток: чтобы вывести битки с хэша скрипта, нужно раскрыть весь код скрипта, т. к. у ноды должна быть возможность взять хэш от кода скрипта и сравнить его с хэшем, который был записан в выходе предыдущей транзакции. Это серьёзный удар по анонимности: мало того, что раскрывается сам факт оплаты на скрипт, так ещё и раскрывается сам скрипт, в который часто заносятся адреса других участников транзакции. Taproot призван исправить эту ситуацию, сделав P2SH-транзакции неотличимыми от P2PKH и избавив от необходимости раскрывать код скрипта. Но не все так радужно, у новой механики есть и недостатки.
Taproot кардинальным образом меняет способ организации кода в Биткоин-скриптах. Теперь, если код содержит несколько логических веток (т. е. содержит операторы IF/ELSE/ENDIF), то каждая логическая ветка становится листом в дереве Меркла. (Дерево Меркла это обычное бинарное дерево, в котором листья хранят хэши данных, а узлы — хэши от сложенных значений дочерних узлов.) Если точнее: скрипт разбивается на несколько частей (каждая часть — отдельная логическая ветка), в листьях дерева записываются хэши от этих скриптов-веток, и дальше от этих листьев строится дерево. Хэш из корня такого дерева дальше используется для построения адреса, на который производится перевод. Само дерево нигде не хранится и не публикуется в блокчейне при расходовании битков.
Но само по себе такое скриптовое дерево это ещё не Taproot. Taproot это криптографическая схема, которая позволяет создать публичный ключ, владение которым может быть проверено двумя способами: подписью (стандартный и всем нам известный сценарий) или проверкой алгоритма создания этого ключа. (Автор этой схемы, кстати, небезызвестный Gregory Maxwell.) Taproot в связке со скриптовым деревом позволяет создать такой публичный ключ, который будет соответствовать либо:
1. Одному листу скриптового дерева, который (лист) был выбран заранее перед созданием ключа. Чтобы вывести биткоины, нужно сделать подпись, используя хэш этого листа в качестве приватного ключа. Этот способ и является самым анонимным в алгоритме Taproot. Вы переводите на публичный ключ и предоставляете подпись, когда выводите с него. Но такой вариант возможен только для одного листа из дерева, т. е. только для одной логической ветки скрипта. Поэтому тут нужно выбирать ветку, которая в вашем скрипте будет использоваться чаще остальных.
2. Любому другому листу, для которого вы раскроете: код скрипта, путь в дереве, правильные входные параметры. Этот способ используется для всех остальных логических веток, и он менее анонимен. Не смотря на это, он все равно лучше чем P2SH, т. к . вы раскрываете только часть скрипта.
Формула создания ключа-адреса выглядит так:
Q = P + hash(P || treeRoot)•G
Q — Taproot-адрес, на который переводятся битки. (Как видно, в формуле не участвует приватный ключ, т. е. публичный ключ создаётся не из приватного — почему такое возможно, разберём позже.) P — некоторый публичный ключ, который уникален для каждого скрипта и для которого известен приватный ключ. treeRoot — хэш из корня скриптового дерева. hash — функция хеширования (SHA-256). || — конкатенация, • — операция умножения по модулю, которая используется для получения публичного ключа из приватного.
Получается вот что:
1. Берём хэш листа, соответствующего логической ветке, которая, как мы считаем, будет использоваться чаще всего. Используем этот хэш в качестве приватного ключа (они оба имеют одинаковый размер — 32 байта) и считаем соответствующий ему публичный ключ. Получаем пару p, P.
2. Складываем (операция ||) P с хэшем из корня скриптового дерева.
3. Хэшируем.
https://t.me/blockndev/30(Этот пост — часть большого паззла. Дописав его я понял, что нужно было бы написать вводный пост по криптографии и некоторым важным механикам. Буду раскрывать тему постепенно.)
P2SH-транзакции (оплата на хэш скрипта), по сути, позволяют создавать смарт-контракты на Биткоине (хоть они и способны лишь проверять права доступа к биткам). Но по сравнению с обычным переводом битков у этого способа есть существенный недостаток: чтобы вывести битки с хэша скрипта, нужно раскрыть весь код скрипта, т. к. у ноды должна быть возможность взять хэш от кода скрипта и сравнить его с хэшем, который был записан в выходе предыдущей транзакции. Это серьёзный удар по анонимности: мало того, что раскрывается сам факт оплаты на скрипт, так ещё и раскрывается сам скрипт, в который часто заносятся адреса других участников транзакции. Taproot призван исправить эту ситуацию, сделав P2SH-транзакции неотличимыми от P2PKH и избавив от необходимости раскрывать код скрипта. Но не все так радужно, у новой механики есть и недостатки.
Taproot кардинальным образом меняет способ организации кода в Биткоин-скриптах. Теперь, если код содержит несколько логических веток (т. е. содержит операторы IF/ELSE/ENDIF), то каждая логическая ветка становится листом в дереве Меркла. (Дерево Меркла это обычное бинарное дерево, в котором листья хранят хэши данных, а узлы — хэши от сложенных значений дочерних узлов.) Если точнее: скрипт разбивается на несколько частей (каждая часть — отдельная логическая ветка), в листьях дерева записываются хэши от этих скриптов-веток, и дальше от этих листьев строится дерево. Хэш из корня такого дерева дальше используется для построения адреса, на который производится перевод. Само дерево нигде не хранится и не публикуется в блокчейне при расходовании битков.
Но само по себе такое скриптовое дерево это ещё не Taproot. Taproot это криптографическая схема, которая позволяет создать публичный ключ, владение которым может быть проверено двумя способами: подписью (стандартный и всем нам известный сценарий) или проверкой алгоритма создания этого ключа. (Автор этой схемы, кстати, небезызвестный Gregory Maxwell.) Taproot в связке со скриптовым деревом позволяет создать такой публичный ключ, который будет соответствовать либо:
1. Одному листу скриптового дерева, который (лист) был выбран заранее перед созданием ключа. Чтобы вывести биткоины, нужно сделать подпись, используя хэш этого листа в качестве приватного ключа. Этот способ и является самым анонимным в алгоритме Taproot. Вы переводите на публичный ключ и предоставляете подпись, когда выводите с него. Но такой вариант возможен только для одного листа из дерева, т. е. только для одной логической ветки скрипта. Поэтому тут нужно выбирать ветку, которая в вашем скрипте будет использоваться чаще остальных.
2. Любому другому листу, для которого вы раскроете: код скрипта, путь в дереве, правильные входные параметры. Этот способ используется для всех остальных логических веток, и он менее анонимен. Не смотря на это, он все равно лучше чем P2SH, т. к . вы раскрываете только часть скрипта.
Формула создания ключа-адреса выглядит так:
Q = P + hash(P || treeRoot)•G
Q — Taproot-адрес, на который переводятся битки. (Как видно, в формуле не участвует приватный ключ, т. е. публичный ключ создаётся не из приватного — почему такое возможно, разберём позже.) P — некоторый публичный ключ, который уникален для каждого скрипта и для которого известен приватный ключ. treeRoot — хэш из корня скриптового дерева. hash — функция хеширования (SHA-256). || — конкатенация, • — операция умножения по модулю, которая используется для получения публичного ключа из приватного.
Получается вот что:
1. Берём хэш листа, соответствующего логической ветке, которая, как мы считаем, будет использоваться чаще всего. Используем этот хэш в качестве приватного ключа (они оба имеют одинаковый размер — 32 байта) и считаем соответствующий ему публичный ключ. Получаем пару p, P.
2. Складываем (операция ||) P с хэшем из корня скриптового дерева.
3. Хэшируем.
Quote
Получаем 32-байтный хэш, который опять используем в качестве приватного ключа (пусть будет x) и для которого также находим публичный (операция `hash(...)•G`). Получаем публичный ключ X.
4. Складываем ключи P и X. Это возможно, потому что публичные ключи это точки на эллиптической кривой.
5. Получаем публичный ключ Q. Соответствующий ему приватный ключ можно получить, если сложить приватные ключи p и x (это свойство называется гомоморфизм, и мы его ещё не раз будем разбирать).
Отправляем на Q биткоины. Как потом их вывести с такого адреса? Есть два способа:
1. Предоставить подпись, сделанную приватным ключом q. Зная приватный ключ p и посчитав приватный ключ x, их нужно сложить, и получится ключ q. Приватный ключ p знает только тот, кто знает хэш корня дерева (а значит и весь скрипт) и скрипт, который был записан в ветке, которая используется по-умолчанию (шаг 1 из предыдущего списка).
2. Воссоздать ключ Q. Зная P, скрипт-ветку, его входные параметры, путь до него в дереве, можно посчитать хэш корня дерева и воспроизвести Q. В новой транзакции вам нужно будет передать все эти данные, и нода сама посчитает Q и сравнит с Taproot-адресом, который был записан в предыдущей транзакции. Входные параметры скрипта должны быть верными, т. е. скрипт должен завершиться успешно.
Вот, в общем-то, и всё.
Получается, что скрипты в открытом виде почти полностью убираются из блокчейна Биткоина, но при этом возрастает нагрузка и ответственность на кошельки и сторонние приложения, т. к. теперь именно им нужно реализовывать вот эти сложные криптографические механики.
https://t.me/blockndev/31 4. Складываем ключи P и X. Это возможно, потому что публичные ключи это точки на эллиптической кривой.
5. Получаем публичный ключ Q. Соответствующий ему приватный ключ можно получить, если сложить приватные ключи p и x (это свойство называется гомоморфизм, и мы его ещё не раз будем разбирать).
Отправляем на Q биткоины. Как потом их вывести с такого адреса? Есть два способа:
1. Предоставить подпись, сделанную приватным ключом q. Зная приватный ключ p и посчитав приватный ключ x, их нужно сложить, и получится ключ q. Приватный ключ p знает только тот, кто знает хэш корня дерева (а значит и весь скрипт) и скрипт, который был записан в ветке, которая используется по-умолчанию (шаг 1 из предыдущего списка).
2. Воссоздать ключ Q. Зная P, скрипт-ветку, его входные параметры, путь до него в дереве, можно посчитать хэш корня дерева и воспроизвести Q. В новой транзакции вам нужно будет передать все эти данные, и нода сама посчитает Q и сравнит с Taproot-адресом, который был записан в предыдущей транзакции. Входные параметры скрипта должны быть верными, т. е. скрипт должен завершиться успешно.
Вот, в общем-то, и всё.
Получается, что скрипты в открытом виде почти полностью убираются из блокчейна Биткоина, но при этом возрастает нагрузка и ответственность на кошельки и сторонние приложения, т. к. теперь именно им нужно реализовывать вот эти сложные криптографические механики.
Для стека биткоина
(https://t.me/CryptoBotan/888)
Биткоин доступный на Ethereum. Сегодня про tBTC.
⬇️⬇️⬇️
DEX в сети Ethereum имеет существенный недостаток: они позволяют торговать только активами, основанными на Ethereum. tBTC позволит держателям BTC подключаться к (DeFi) Ethereum.
Хотя уже есть подобные решения, но есть нюансы...
1) Например Liquid (https://t.me/CryptoBotan/890). Проблема в том, что BTC, запираются на мультивалютном кошельке, подписывают который участники проверенные BlockStream. Они проверяют сайдчейн и голосуют за подписание блоков, плюс и одобряют peg-out транзакции.
2) WBTC (https://www.wbtc.network/#) - это поддерживаемый BTC токен ERC-20. Консорциум проводит голосование за добавление и удаление хранителей, управляющих BTC - резервами токена. Эти хранители управляют multisig кошельком BTC, контролируют ключи, перемещают их и создают WBTC на Ethereum.
Проблема состоит в том, что нужно доверять свои средства третей стороне.
tBTC - это депозитный токен (TDT) ERC-20 с поддержкой BTC 1:1. Это способ для юзеров вносить свои BTC и создавать биткойн-токены на Ethereum без посредников и KYC.
Это проект, предложенный Cross Chain Group (CCG) (https://www.crosschain.group/) и крупный dApp, построенный на Keep Network (https://keep.network/), автономной сети узлов, считывающих и записывающих данные в сети Ethereum и Bitcoin.
Как это происходит? Я постарался подробно описать принцип работы, но если что, жду фидбэка😉
Небольшая вводная:
tBTC (TDT) - это депозитный токен, который привязан к конкретному депозиту tBTC Bitcoin UTXO. Удержание токена позволяет выкупить этот депозит tBTC за оригинальный биткоин, используемый для его финансирования. Владелец TDT обладает исключительным правом выкупа базового UTXO до истечения срока действия депозита (6 месяцев).
Существует отдельный контракт, называемый торговым автоматом TBTC, который используется для чеканки взаимозаменяемых TBTC в обмен на TDT.
Депонирование BTC для создания TBTC.
Вкладчик размещает облигационный контракт (ETH) и отправляет запрос депозита в смарт-контракт tBTC на Ethereum. Отправка запроса сигнализирует смарт-контракт о том, что вкладчик хочет депонировать BTC и создать TBTC.
Облигационный контракт нужен для защиты от спама, который возвращаются после завершения депонирования.
Создается адрес депозита и система случайным образом выбирает группу подписчиков, которые генерируют BTC-кошелек. Этот кошелек требует M из N подписей для генерации действительных транзакций. Подписавшие должны внести залог в размере 1,5х суммы BTC, депонированного в ETH.
Контракт создает tBTC (токен депозита) и токен ERC-721 (NFT токен -токен получателя) и они отправляются вкладчику. Токен получателя используется для управления депозитом.
BTC отправляются на указанный адрес, после чего отправляется SPV (https://t.me/CryptoBotan/939)-подтверждение платежа из цепочки BTC в депозитный контракт на цепочке ETH. После чего создается TBTC из контракта и передаются вкладчику.
Для обмена TBTC в BTC есть возможность использовать токен депозита tBTC (TDT) для погашения точного UTXO вашего первоначального депозита, если он находится в пределах установленного 6-месячного периода. Есть несколько способов обмена в BTC:
1) Если есть TDT, то нужно отправить плату подписчикам (0.005 TBTC). Это даст точное UTXO связанное с TDT.
2) Если TDT нет, но нужны BTC для TBTC, то можно заплатить 0.005 TBTC подписавшему, чтобы выкупить BTC из системы
3) Если нет TDT, но есть депозит, который существовал в системе больше 6 месяцев, то он обойдется в 1TBTC, чтобы выкупить его за 1 BTC. В таком случае сборы подписчикам оплачивает текущий владелец депозита tBTC.
Система просит подтвердить запрос BTC на блокчейне Ethereum. Затем выпускаются BTC и подтверждается выпуск по цепочке ETH. Затем отправляется подтверждение транзакции BTC в цепочку ETH, инициируя платеж подписавшего.
///
tBTC полагается на ценовые каналы, облигации и арбитражные возможности, для поддержания честной работы системы. DeFi получит доступ к ликвидности биткойна. Протокол автоматизации инвестиций сможет снизить риски для своих пользователей, которые связаны с хранением и ценами, при помощи интеграции tBTC. Вся подробная информация о tBTC по ссылочке http://docs.keep.network/tbtc/index.pdf
(https://t.me/CryptoBotan/888)
Биткоин доступный на Ethereum. Сегодня про tBTC.
⬇️⬇️⬇️
DEX в сети Ethereum имеет существенный недостаток: они позволяют торговать только активами, основанными на Ethereum. tBTC позволит держателям BTC подключаться к (DeFi) Ethereum.
Хотя уже есть подобные решения, но есть нюансы...
1) Например Liquid (https://t.me/CryptoBotan/890). Проблема в том, что BTC, запираются на мультивалютном кошельке, подписывают который участники проверенные BlockStream. Они проверяют сайдчейн и голосуют за подписание блоков, плюс и одобряют peg-out транзакции.
2) WBTC (https://www.wbtc.network/#) - это поддерживаемый BTC токен ERC-20. Консорциум проводит голосование за добавление и удаление хранителей, управляющих BTC - резервами токена. Эти хранители управляют multisig кошельком BTC, контролируют ключи, перемещают их и создают WBTC на Ethereum.
Проблема состоит в том, что нужно доверять свои средства третей стороне.
tBTC - это депозитный токен (TDT) ERC-20 с поддержкой BTC 1:1. Это способ для юзеров вносить свои BTC и создавать биткойн-токены на Ethereum без посредников и KYC.
Это проект, предложенный Cross Chain Group (CCG) (https://www.crosschain.group/) и крупный dApp, построенный на Keep Network (https://keep.network/), автономной сети узлов, считывающих и записывающих данные в сети Ethereum и Bitcoin.
Как это происходит? Я постарался подробно описать принцип работы, но если что, жду фидбэка😉
Небольшая вводная:
tBTC (TDT) - это депозитный токен, который привязан к конкретному депозиту tBTC Bitcoin UTXO. Удержание токена позволяет выкупить этот депозит tBTC за оригинальный биткоин, используемый для его финансирования. Владелец TDT обладает исключительным правом выкупа базового UTXO до истечения срока действия депозита (6 месяцев).
Существует отдельный контракт, называемый торговым автоматом TBTC, который используется для чеканки взаимозаменяемых TBTC в обмен на TDT.
Депонирование BTC для создания TBTC.
Вкладчик размещает облигационный контракт (ETH) и отправляет запрос депозита в смарт-контракт tBTC на Ethereum. Отправка запроса сигнализирует смарт-контракт о том, что вкладчик хочет депонировать BTC и создать TBTC.
Облигационный контракт нужен для защиты от спама, который возвращаются после завершения депонирования.
Создается адрес депозита и система случайным образом выбирает группу подписчиков, которые генерируют BTC-кошелек. Этот кошелек требует M из N подписей для генерации действительных транзакций. Подписавшие должны внести залог в размере 1,5х суммы BTC, депонированного в ETH.
Контракт создает tBTC (токен депозита) и токен ERC-721 (NFT токен -токен получателя) и они отправляются вкладчику. Токен получателя используется для управления депозитом.
BTC отправляются на указанный адрес, после чего отправляется SPV (https://t.me/CryptoBotan/939)-подтверждение платежа из цепочки BTC в депозитный контракт на цепочке ETH. После чего создается TBTC из контракта и передаются вкладчику.
Для обмена TBTC в BTC есть возможность использовать токен депозита tBTC (TDT) для погашения точного UTXO вашего первоначального депозита, если он находится в пределах установленного 6-месячного периода. Есть несколько способов обмена в BTC:
1) Если есть TDT, то нужно отправить плату подписчикам (0.005 TBTC). Это даст точное UTXO связанное с TDT.
2) Если TDT нет, но нужны BTC для TBTC, то можно заплатить 0.005 TBTC подписавшему, чтобы выкупить BTC из системы
3) Если нет TDT, но есть депозит, который существовал в системе больше 6 месяцев, то он обойдется в 1TBTC, чтобы выкупить его за 1 BTC. В таком случае сборы подписчикам оплачивает текущий владелец депозита tBTC.
Система просит подтвердить запрос BTC на блокчейне Ethereum. Затем выпускаются BTC и подтверждается выпуск по цепочке ETH. Затем отправляется подтверждение транзакции BTC в цепочку ETH, инициируя платеж подписавшего.
///
tBTC полагается на ценовые каналы, облигации и арбитражные возможности, для поддержания честной работы системы. DeFi получит доступ к ликвидности биткойна. Протокол автоматизации инвестиций сможет снизить риски для своих пользователей, которые связаны с хранением и ценами, при помощи интеграции tBTC. Вся подробная информация о tBTC по ссылочке http://docs.keep.network/tbtc/index.pdf
sr. member
Activity: 938
Merit: 466
~[f#
К стеку Биткоина также можно отнести dPoW от Komodo https://komodoplatform.com/delayed-proof-of-work/
Кстати Комодо запускает стейблкоин на Биткоин-активах https://www.cryptoninjas.net/2020/02/10/komodo-launches-stablecoin-module-collateralized-with-btc-based-assets/
Еще вот интересный проект нашёл. Будут делать Делать Дефи для Биткоина https://www.meter.io/
https://bitcoinops.org/en/newsletters/2020/01/29/ -Bitcoin Optech Newsletter #82
https://bitcoinops.org/en/newsletters/2020/02/05/ - Bitcoin Optech Newsletter #83
https://bitcoinops.org/en/newsletters/2020/02/12/ - Bitcoin Optech Newsletter #84
https://www.youtube.com/watch?v=5SjqMp9KDUE - Биткоинизация / Не только халвинг: технологии, которые изменят Биткоин уже в 2020 — Глеб Науменко
Кстати Комодо запускает стейблкоин на Биткоин-активах https://www.cryptoninjas.net/2020/02/10/komodo-launches-stablecoin-module-collateralized-with-btc-based-assets/
Еще вот интересный проект нашёл. Будут делать Делать Дефи для Биткоина https://www.meter.io/
https://bitcoinops.org/en/newsletters/2020/01/29/ -Bitcoin Optech Newsletter #82
https://bitcoinops.org/en/newsletters/2020/02/05/ - Bitcoin Optech Newsletter #83
https://bitcoinops.org/en/newsletters/2020/02/12/ - Bitcoin Optech Newsletter #84
https://www.youtube.com/watch?v=5SjqMp9KDUE - Биткоинизация / Не только халвинг: технологии, которые изменят Биткоин уже в 2020 — Глеб Науменко
~
Если разработки приведут к успеху, нам обещают фулноды на мобильных устройствах😅
Кому интересно подробнее, вот ссылочка (https://eprint.iacr.org/2019/611) на публикацию Тадж Драя
Достаточно интересное решение, которое рано или поздно должно быть реализовано в том или ином виде: размер блокчейна и требования к дисковому пространству при запуске полной ноды не могут расти вечно, нужно работать над оптимизацией уже сейчас. Не знаю, возможно ли будет уменьшить размер настолько, что бы было возможным запускам на смартфонах, но если это окажется реализуемым, то это поспоспособствует не только резкому увеличению децецентрализации сети Биткойна, но и придаст самой сети некую "подвижность", будет сложнее препятствовать развертыванию узлов и цензурируемость будет приближаться к нулю. Если разработки приведут к успеху, нам обещают фулноды на мобильных устройствах😅
Кому интересно подробнее, вот ссылочка (https://eprint.iacr.org/2019/611) на публикацию Тадж Драя
https://t.me/CryptoBotan/948
Для стека биткоина (https://t.me/CryptoBotan/888).
Решение для масштабирования сети Биткойн - uTreeXo.
Хоть в таблице оно идет совместно с такими решениями как libMiniSketch и Tx Accumulators, я все-таки решил разобрать их по отдельности.
⬇️⬇️⬇️
Решение предложил один из главных разработчиков LN Тадж Драй в июне 2019 года.
uTreeXo - это динамический аккумулятор UTXO (неизрасходованных остатков транзакций). А нужно оно для упрощения управления полными нодами в сети биткоина.
Об UTXO я тоже уже писал и кстати в этом посте (https://t.me/CryptoBotan/742) я упоминал решение uTreeXo.
Немного разберемся...
Каждый узел в сети Биткойн проверяет и сохраняет состояние сети, а кошельки отслеживают UTXO (Unspent Transaction (TX) Output). Каждый узел, для предотвращения даблспендов, должен отслеживать набор всех UTXO при проверке каждой транзакции каждого блока.
Кстати, если хотите разобраться с тем, как устроены транзакции в сети и что такое UTXO, советую глянуть пост (https://t.me/CryptoLamer/2118) на канале @CryptoLamer.
UTXO сильно упрощает методы учета на блокчейне. Вместо того, чтобы вынужденно отслеживать и хранить каждую транзакцию, система отслеживает только неизрасходованные коины (UTXO).
Растет количество юзеров, а следовательно и количество кошельков и наборов UTXO. Запускать узел напряжно, так как требуется все больше ресурсов. Вместо этого, юзеры используют легкие клиенты и сторонние узлы для отслеживания состояния сети. Эти легкие клиенты не хранят состояния системы и не првоеряют транзакции, но используют упрощенную проверку платежей SPV (https://t.me/CryptoBotan/939).
SPV имеет ряд недостатков и потенциальных уязвимостей, которые я описывал ранее. Тут я не буду на этом останавливаться, подробности по ссылочке выше.
Проблема таится в объеме хранимой информации. Ее можно решить при помощи криптографических аккумуляторов (компактное представление множества). Динамический аккумулятор позволяет добавлять и удалять элементы из множества, но он требует наличия общего секрета (Trusted Setup), который при генерации и утечки позволяет создавать фальшивые доказательства существования UTXO.
А теперь проще: полным узлам не нужно хранить все данные блокчейна, вместо этого аккумуляторы предоставят доказательства того, что данные верны.
uTreeXo позволяет создать динамический аккумулятор без общего секрета.
Решение uTreeXo сокращает объем памяти, необходимый для запуска полного узла, что делает фулноды более легкими. Узлам не нужно отслеживать набор всех UTXO при проверке каждой транзакции каждого блока. Достаточно лишь логарифмического представления набора этих UTXO.
При помощи uTreeXo, транзакции не просто указывают уникальный ID UTXO, который они хотят потратить, но также указывают его доказательство. Это позволяет узлам сети как проверять правильность UTXO, так и вносить необходимые изменения в соответствующие деревья Меркла.
Каждая версия uTreeXo должна содержать информацию, которая может быть использована для обновления доказательств, и владелец должен убедиться, что все такие версии применяются к доказательству UTXO, прежде чем попытаться его использовать.
Если разработки приведут к успеху, нам обещают фулноды на мобильных устройствах😅
Кому интересно подробнее, вот ссылочка (https://eprint.iacr.org/2019/611) на публикацию Тадж Драя
Для стека биткоина (https://t.me/CryptoBotan/888).
Решение для масштабирования сети Биткойн - uTreeXo.
Хоть в таблице оно идет совместно с такими решениями как libMiniSketch и Tx Accumulators, я все-таки решил разобрать их по отдельности.
⬇️⬇️⬇️
Решение предложил один из главных разработчиков LN Тадж Драй в июне 2019 года.
uTreeXo - это динамический аккумулятор UTXO (неизрасходованных остатков транзакций). А нужно оно для упрощения управления полными нодами в сети биткоина.
Об UTXO я тоже уже писал и кстати в этом посте (https://t.me/CryptoBotan/742) я упоминал решение uTreeXo.
Немного разберемся...
Каждый узел в сети Биткойн проверяет и сохраняет состояние сети, а кошельки отслеживают UTXO (Unspent Transaction (TX) Output). Каждый узел, для предотвращения даблспендов, должен отслеживать набор всех UTXO при проверке каждой транзакции каждого блока.
Кстати, если хотите разобраться с тем, как устроены транзакции в сети и что такое UTXO, советую глянуть пост (https://t.me/CryptoLamer/2118) на канале @CryptoLamer.
UTXO сильно упрощает методы учета на блокчейне. Вместо того, чтобы вынужденно отслеживать и хранить каждую транзакцию, система отслеживает только неизрасходованные коины (UTXO).
Растет количество юзеров, а следовательно и количество кошельков и наборов UTXO. Запускать узел напряжно, так как требуется все больше ресурсов. Вместо этого, юзеры используют легкие клиенты и сторонние узлы для отслеживания состояния сети. Эти легкие клиенты не хранят состояния системы и не првоеряют транзакции, но используют упрощенную проверку платежей SPV (https://t.me/CryptoBotan/939).
SPV имеет ряд недостатков и потенциальных уязвимостей, которые я описывал ранее. Тут я не буду на этом останавливаться, подробности по ссылочке выше.
Проблема таится в объеме хранимой информации. Ее можно решить при помощи криптографических аккумуляторов (компактное представление множества). Динамический аккумулятор позволяет добавлять и удалять элементы из множества, но он требует наличия общего секрета (Trusted Setup), который при генерации и утечки позволяет создавать фальшивые доказательства существования UTXO.
А теперь проще: полным узлам не нужно хранить все данные блокчейна, вместо этого аккумуляторы предоставят доказательства того, что данные верны.
uTreeXo позволяет создать динамический аккумулятор без общего секрета.
Решение uTreeXo сокращает объем памяти, необходимый для запуска полного узла, что делает фулноды более легкими. Узлам не нужно отслеживать набор всех UTXO при проверке каждой транзакции каждого блока. Достаточно лишь логарифмического представления набора этих UTXO.
При помощи uTreeXo, транзакции не просто указывают уникальный ID UTXO, который они хотят потратить, но также указывают его доказательство. Это позволяет узлам сети как проверять правильность UTXO, так и вносить необходимые изменения в соответствующие деревья Меркла.
Каждая версия uTreeXo должна содержать информацию, которая может быть использована для обновления доказательств, и владелец должен убедиться, что все такие версии применяются к доказательству UTXO, прежде чем попытаться его использовать.
Если разработки приведут к успеху, нам обещают фулноды на мобильных устройствах😅
Кому интересно подробнее, вот ссылочка (https://eprint.iacr.org/2019/611) на публикацию Тадж Драя
✅✅✅
К стеку (https://t.me/CryptoBotan/888) биткоина. Сегодня обращусь к SmartsContracts, а именно к решению Scriptless Scripts (https://github.com/ElementsProject/scriptless-scripts).
Scriptless Scripts ("Скрипты без скриптов")
⬇️⬇️⬇️
Смарт-контракты в сети BTC существуют и существовали до этого. Например Musig (https://t.me/CryptoBotan/936) или смарт-контракты Lightning Network (https://t.me/CryptoBotan/819).
Но есть проблемка, и при чем не одна:
1) Ресурсы
Чем сложнее смарт-контракт, тем больше требуется ресурсов. Ведь все узлы сети должны исполнить контракт, а не только участники сделки.
2) Конфедициальность
Если все узлы сети испольняют контракт, то и об условиях контракта знает вся сеть.
Вообщем, почему я решил перескочить на решение "скрипты без скриптов". Все дело в том, что нужно опять немножко зацепить подписи Шнорра (https://t.me/CryptoBotan/930).
Суть:
Подписи Шнорра меньше, чем ECDSA (https://t.me/CryptoBotan/824), и могут быть объединены при помощи агрегации подписей. Это ведет к совместному использованию подписей несколькими входами. А это приводит к повышению конфиденциальности и масштабируемости сети.
Вот мы и у сути повествования:
Andrew Poelstra из BlockStream онаружил, что сами подписи могут быть сконструированы и модифицированы специальными способами для обеспечения выполнения различных соглашений между сторонами. Вводятся условия расходов, которые полностью скрыты от блокчейна. Только вовлеченные стороны знают об условиях договора или о том, что договор вообще существует. Для остальных транзакции выглядят совершенно обычными и неотличимыми от обычных.
Изучая протокол MimbleWimble (https://t.me/CryptoBotan/808), где вообще отсутсвуют скрипты, а весь блокчейн функционирует только на подписях и обязательствах, которые представляют собой расходуемые монеты, он выяснил, как при помощи скриптов обеспечить функциональность без необходимости их присутствия в блокчейне. Отсюда и название собственно говоря...
Большая часть контрактов просто перемещается за пределы блокчейна. Вместо исполнения контракта всей сетью, этим займутся только участвующие стороны. А выполнение результатов контракта, производится при требуемых условиях.
Чтобы смарт-контракты применяли только подписи, используются преимущества агрегации подписей Шнорра. Подписи могут добавляться и вычитаться, и результатом является допустимая подпись, соответствующая тому же добавлению или вычитанию открытых ключей.
Как это работает?
pubkey1 + pubkey2 + pubkey3 = pubkey Y
signature1 + signature2 + signature3 = signature Y
Мы привязываем биткоин к pubkey Y, который не является ключом и к которому у кого-либо есть доступ, но на самом деле он представляет собой сумму pubkeys. Подписи от каждого из ключей 1, 2 и 3 можно суммировать, чтобы создать подпись для pubkey Y, и сеть не будет в курсе, что на самом деле было три ключа, участвующих в создании подписи. Она будет выглядеть так же, как обычная подпись из pubkey Y, но сеть будет воспринимать ее как разрешение на расходование.
Сценарии без скриптов масштабируются лучше, чем обычные смарт-контракты, потому что выполнение условий контракта происходит вне цепочки, а следовательно и нет необходимости хранения данных контракта и выполнения его условий.
К стеку (https://t.me/CryptoBotan/888) биткоина. Сегодня обращусь к SmartsContracts, а именно к решению Scriptless Scripts (https://github.com/ElementsProject/scriptless-scripts).
Scriptless Scripts ("Скрипты без скриптов")
⬇️⬇️⬇️
Смарт-контракты в сети BTC существуют и существовали до этого. Например Musig (https://t.me/CryptoBotan/936) или смарт-контракты Lightning Network (https://t.me/CryptoBotan/819).
Но есть проблемка, и при чем не одна:
1) Ресурсы
Чем сложнее смарт-контракт, тем больше требуется ресурсов. Ведь все узлы сети должны исполнить контракт, а не только участники сделки.
2) Конфедициальность
Если все узлы сети испольняют контракт, то и об условиях контракта знает вся сеть.
Вообщем, почему я решил перескочить на решение "скрипты без скриптов". Все дело в том, что нужно опять немножко зацепить подписи Шнорра (https://t.me/CryptoBotan/930).
Суть:
Подписи Шнорра меньше, чем ECDSA (https://t.me/CryptoBotan/824), и могут быть объединены при помощи агрегации подписей. Это ведет к совместному использованию подписей несколькими входами. А это приводит к повышению конфиденциальности и масштабируемости сети.
Вот мы и у сути повествования:
Andrew Poelstra из BlockStream онаружил, что сами подписи могут быть сконструированы и модифицированы специальными способами для обеспечения выполнения различных соглашений между сторонами. Вводятся условия расходов, которые полностью скрыты от блокчейна. Только вовлеченные стороны знают об условиях договора или о том, что договор вообще существует. Для остальных транзакции выглядят совершенно обычными и неотличимыми от обычных.
Изучая протокол MimbleWimble (https://t.me/CryptoBotan/808), где вообще отсутсвуют скрипты, а весь блокчейн функционирует только на подписях и обязательствах, которые представляют собой расходуемые монеты, он выяснил, как при помощи скриптов обеспечить функциональность без необходимости их присутствия в блокчейне. Отсюда и название собственно говоря...
Большая часть контрактов просто перемещается за пределы блокчейна. Вместо исполнения контракта всей сетью, этим займутся только участвующие стороны. А выполнение результатов контракта, производится при требуемых условиях.
Чтобы смарт-контракты применяли только подписи, используются преимущества агрегации подписей Шнорра. Подписи могут добавляться и вычитаться, и результатом является допустимая подпись, соответствующая тому же добавлению или вычитанию открытых ключей.
Как это работает?
pubkey1 + pubkey2 + pubkey3 = pubkey Y
signature1 + signature2 + signature3 = signature Y
Мы привязываем биткоин к pubkey Y, который не является ключом и к которому у кого-либо есть доступ, но на самом деле он представляет собой сумму pubkeys. Подписи от каждого из ключей 1, 2 и 3 можно суммировать, чтобы создать подпись для pubkey Y, и сеть не будет в курсе, что на самом деле было три ключа, участвующих в создании подписи. Она будет выглядеть так же, как обычная подпись из pubkey Y, но сеть будет воспринимать ее как разрешение на расходование.
Сценарии без скриптов масштабируются лучше, чем обычные смарт-контракты, потому что выполнение условий контракта происходит вне цепочки, а следовательно и нет необходимости хранения данных контракта и выполнения его условий.
sr. member
Activity: 938
Merit: 466
~[f#
https://cryptobriefing.com/rsk-introduces-interoperability-bridge-bitcoin-ethereum/ - RSK представили мост между Биткоином и Эфиром
https://t.me/CryptoBotan/942
✅✅✅
Итак, что такое SPV "Simplified Payment Verification (https://t.me/CryptoBotan/939)" разобрались. Это пригодится нам, чтобы рассмотреть еще одно решение в стеке биткоина (https://t.me/CryptoBotan/888) для Perfomance&Usability - Neutrino.
⬇️⬇️⬇️
В марте 2018 года Lightning Labs объявила (https://blog.lightning.engineering/announcement/2018/03/15/lnd-beta.html) о выпуске бета-версии программного клиента Lightning Network Daemon (LND) (https://github.com/lightningnetwork/lnd). Этот клиент предназначен для разработчиков и используется для доступа к сети LN.
Lightning Network Daemon (LND) - это комплексная реализация сетевого узла Lightning. У LND есть несколько подключаемых сервисов back-end chain, включая btcd (полный узел), bitcoind (консольный интерфейс) и наш сегодняшний герой, протокол Neutrino (новый экспериментальный клиент-light).
Протокол Neutrino (BIP 157, BIP 158) был предложен Olaoluwa Osuntokun, Alex Akselrod, Jim Posen.
Neutrino - это защищающий конфиденциальность клиент light-wallet, разработанный с упором на использование LN. Он написан на языке Go и использует уплотненные блочные фильтры для улучшения реализации SPV Bloom Filtering (BIP 37 (https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki)) Light-client.
Я писал о BIP 37 и фильтрах Блума в посте о SPV (https://t.me/CryptoBotan/939).
Если сказать совсем уж просто, Neutrino придуман для того, чтобы из всего Биткойн-блокчейна быстро доставать те транзакции, которые относятся только к конкретному пользователю, который использует маломощное устройство с ограниченной памятью, пропускной способностью и ненадежной связью. Плюс ко всему контроль над PrivateKey находится в руках пользователя.
Если тебе, мой криптоботанёнок, больше и не нужно знать, то тут можешь остановиться. Дальше я разберу все это, более детально😉
Как работает Neutrino?
Neutrino предназначен для минимизации пропускной способности и хранения данных на стороне клиента при сохранении конфиденциальности на полных узлах, обслуживающих клиентов light.
Это достигается с помощью механизма, в котором фильтры GSC используются для представления адресов, соответствующих определенному блоку, которые представляют собой более сжатую версию блока (около 15Кб), чем исходный (до 4Мб).
Фильтры GCS или Golomb-Coded Set - это метод сжатия данных без потерь, использующий семейство кодов сжатия данных,(Википедия (https://en.wikipedia.org/wiki/Golomb_coding))
Устройства с низкой пропускной способностью (мобильные устройства) могут в дальнейшем определить, имеют ли транзакции внутри недавно созданного блока отношение к кошельку пользователя. Если блок содержит соответствующие транзакции, то клиент Neutrino загружает соответствующий блок, но не весь, а только данные транзакции, а не подписи или данные свидетеля.
Затем клиент может сканировать и обновлять информацию о своих транзакциях с помощью процесса, выполняемого ПО кошелька пользователя, а не удаленным узлом, как в BIP37, что является важным соображением конфиденциальности, так как данные не пересылаются по сети.
Основная проблема, которую решает Neutrino и которую не решала SPV в BIP 37 - это утечка информации с помощью фильтров Блума в узлах SPV, которые могут быть использованы для деанонимизации пользователей.
Клиенты Neutrino требуют значительно меньшей пропускной способности из-за сжатия GSC и уменьшают вычислительную нагрузку на полные узлы, так как фильтры, отправленные клиентам Neutrino, должны быть вычислены только один раз (в BIP37 fullnodes вычисляют результаты для каждого клиента).
На узле Neutrino может храниться несколько десятков Мб данных, что по сравнению с fullnode не такая уж и большая цифра.
Будущие разработки в области Neutrino включают в себя извлечение блочного фильтра из внешней сети Биткойна и потенциальную интеграцию хэша блочного фильтра GSC непосредственно в заголовок блока через софт-форк. В конечном итоге, целью Neutrino является создание фундамента для следующего поколения приложений кошельков, которые будут построены поверх сети.
Интересно, но факт:
Разработчик Bitcoin Advisory-Пьер Рошар-предложил плагин Microsoft Excel для сети Lightning. Плагин использует клиент Neutrino и позволяет пользователям вставлять адреса кошельков и платить другим пользователям в Excel через LN.😕
✅✅✅
Итак, что такое SPV "Simplified Payment Verification (https://t.me/CryptoBotan/939)" разобрались. Это пригодится нам, чтобы рассмотреть еще одно решение в стеке биткоина (https://t.me/CryptoBotan/888) для Perfomance&Usability - Neutrino.
⬇️⬇️⬇️
В марте 2018 года Lightning Labs объявила (https://blog.lightning.engineering/announcement/2018/03/15/lnd-beta.html) о выпуске бета-версии программного клиента Lightning Network Daemon (LND) (https://github.com/lightningnetwork/lnd). Этот клиент предназначен для разработчиков и используется для доступа к сети LN.
Lightning Network Daemon (LND) - это комплексная реализация сетевого узла Lightning. У LND есть несколько подключаемых сервисов back-end chain, включая btcd (полный узел), bitcoind (консольный интерфейс) и наш сегодняшний герой, протокол Neutrino (новый экспериментальный клиент-light).
Протокол Neutrino (BIP 157, BIP 158) был предложен Olaoluwa Osuntokun, Alex Akselrod, Jim Posen.
Neutrino - это защищающий конфиденциальность клиент light-wallet, разработанный с упором на использование LN. Он написан на языке Go и использует уплотненные блочные фильтры для улучшения реализации SPV Bloom Filtering (BIP 37 (https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki)) Light-client.
Я писал о BIP 37 и фильтрах Блума в посте о SPV (https://t.me/CryptoBotan/939).
Если сказать совсем уж просто, Neutrino придуман для того, чтобы из всего Биткойн-блокчейна быстро доставать те транзакции, которые относятся только к конкретному пользователю, который использует маломощное устройство с ограниченной памятью, пропускной способностью и ненадежной связью. Плюс ко всему контроль над PrivateKey находится в руках пользователя.
Если тебе, мой криптоботанёнок, больше и не нужно знать, то тут можешь остановиться. Дальше я разберу все это, более детально😉
Как работает Neutrino?
Neutrino предназначен для минимизации пропускной способности и хранения данных на стороне клиента при сохранении конфиденциальности на полных узлах, обслуживающих клиентов light.
Это достигается с помощью механизма, в котором фильтры GSC используются для представления адресов, соответствующих определенному блоку, которые представляют собой более сжатую версию блока (около 15Кб), чем исходный (до 4Мб).
Фильтры GCS или Golomb-Coded Set - это метод сжатия данных без потерь, использующий семейство кодов сжатия данных,(Википедия (https://en.wikipedia.org/wiki/Golomb_coding))
Устройства с низкой пропускной способностью (мобильные устройства) могут в дальнейшем определить, имеют ли транзакции внутри недавно созданного блока отношение к кошельку пользователя. Если блок содержит соответствующие транзакции, то клиент Neutrino загружает соответствующий блок, но не весь, а только данные транзакции, а не подписи или данные свидетеля.
Затем клиент может сканировать и обновлять информацию о своих транзакциях с помощью процесса, выполняемого ПО кошелька пользователя, а не удаленным узлом, как в BIP37, что является важным соображением конфиденциальности, так как данные не пересылаются по сети.
Основная проблема, которую решает Neutrino и которую не решала SPV в BIP 37 - это утечка информации с помощью фильтров Блума в узлах SPV, которые могут быть использованы для деанонимизации пользователей.
Клиенты Neutrino требуют значительно меньшей пропускной способности из-за сжатия GSC и уменьшают вычислительную нагрузку на полные узлы, так как фильтры, отправленные клиентам Neutrino, должны быть вычислены только один раз (в BIP37 fullnodes вычисляют результаты для каждого клиента).
На узле Neutrino может храниться несколько десятков Мб данных, что по сравнению с fullnode не такая уж и большая цифра.
Будущие разработки в области Neutrino включают в себя извлечение блочного фильтра из внешней сети Биткойна и потенциальную интеграцию хэша блочного фильтра GSC непосредственно в заголовок блока через софт-форк. В конечном итоге, целью Neutrino является создание фундамента для следующего поколения приложений кошельков, которые будут построены поверх сети.
Интересно, но факт:
Разработчик Bitcoin Advisory-Пьер Рошар-предложил плагин Microsoft Excel для сети Lightning. Плагин использует клиент Neutrino и позволяет пользователям вставлять адреса кошельков и платить другим пользователям в Excel через LN.😕
✅✅✅
Layer 2 стека ВТС (https://t.me/CryptoBotan/888) я описал. Дальше буду писать в хаотичном порядке, исходя из настроения, новостей и ваших пожеланий.
MuSig - схема мультиподписей на базе подписей Шнорра.
⬇️⬇️⬇️
Я уже много раз упоминал свой пост (https://t.me/CryptoBotan/704) про подписи Шнорра...и вот опять пришлось...Для более ясной картины оставлю ссылку на канал, где ребятушки еще проще описали это решение и рассказали почему о нем так много разговоров.
⬇️⬇️⬇️
https://t.me/blockndev/23
Если обратится к схеме стека, то подписи Шнорра являются основой для построения двух решений: MuSig и Cross-Input-Aggregation (о котором в другой раз)
MuSig - это новая схема подписи для биткоина, которая призвана увеличить масштабируемость сети и конфедициальность транзакций.
MuSig - это многофункциональная схема цифровой подписи совместимая с BIP-Shnorr.
BIP-Shnorr описывает спецификации и технические особенности потенциальной реализации Schnorr, которая будет иметь следующие преимущества по сравнению с ECDSA:
1) Доказательство безопасности - В бипе было что-то про дискретный логарифм эллиптической кривой😐, но я скажу так: "То доказательство, которое есть в подписях Шнорр, нет в ECDSA".🙈
2) Подписи Шнорра дают возможность нескольким сторонам совместно создавать подписи, которые действительны для суммы их открытых ключей. Это основа для построения конструкций более высокого уровня, которые повышают эффективность и конфиденциальность мульти-подписей и смарт-контрактов.
MuSig дает Бате вот какие плюшки:
1) Позволяет агрегировать несколько открытых ключей (PublicKey) в один открытый ключ. Если еще проще, позволяет группе подписывающих лиц (каждый со своим собственным закрытым/открытым ключом) совместно подписывать одно сообщение, в результате чего получается одна подпись. Эта единственная подпись может быть затем проверена любым, кто также знает сообщение и открытые ключи подписывающих лиц.
Свойство объединения PublicKey называется агрегированием.
2) Схемы мультиподписей, дающих агрегацию подписей Шнорра, уже имеются на "рынке" решений. Но их недостаток в том, что эти схемы требуют проверки наличия PrivateKey, соответствующего PublicKey. MuSig таких требований не предъявляет. Все что нужно - это PublicKey.
В схеме мультиподписей, поддерживающих агрегацию ключей, мультиподпись выглядит как подпись с одним ключом. Верификаторам не требуются знания открытых ключей исходных участников. Им будет достаточно только агрегированного ключа. MuSig фактически является ключевой схемой агрегирования подписей Шнорра.
Схема агрегирования ключей также позволяет сократить число PublicKey на вход транзакции до одного.
Но ясное дело, что без проблем не обошлось.
Подписи MuSig, так же как подписи Schnorr или ECDSA, используют в своей конструкции поле “nonce”, которое должно быть неповторяемым.
Буду честен, я не смог до конца разобраться в описании этой уязвимости. Математика тут сильнее меня☺️ Для тех кому интересно, оставляю ссылочку (https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da) (англ.)
А это статья (https://blockstream.com/2019/02/18/en-musig-a-new-multisignature-standard/) разработчика BlockStream о MuSig...Ну чтобы подробнее разобраться (англ.)😉
GitHub MuSig (https://github.com/ElementsProject/secp256k1-zkp/tree/secp256k1-zkp/src/modules/musig)
Layer 2 стека ВТС (https://t.me/CryptoBotan/888) я описал. Дальше буду писать в хаотичном порядке, исходя из настроения, новостей и ваших пожеланий.
MuSig - схема мультиподписей на базе подписей Шнорра.
⬇️⬇️⬇️
Я уже много раз упоминал свой пост (https://t.me/CryptoBotan/704) про подписи Шнорра...и вот опять пришлось...Для более ясной картины оставлю ссылку на канал, где ребятушки еще проще описали это решение и рассказали почему о нем так много разговоров.
⬇️⬇️⬇️
https://t.me/blockndev/23
Если обратится к схеме стека, то подписи Шнорра являются основой для построения двух решений: MuSig и Cross-Input-Aggregation (о котором в другой раз)
MuSig - это новая схема подписи для биткоина, которая призвана увеличить масштабируемость сети и конфедициальность транзакций.
MuSig - это многофункциональная схема цифровой подписи совместимая с BIP-Shnorr.
BIP-Shnorr описывает спецификации и технические особенности потенциальной реализации Schnorr, которая будет иметь следующие преимущества по сравнению с ECDSA:
1) Доказательство безопасности - В бипе было что-то про дискретный логарифм эллиптической кривой😐, но я скажу так: "То доказательство, которое есть в подписях Шнорр, нет в ECDSA".🙈
2) Подписи Шнорра дают возможность нескольким сторонам совместно создавать подписи, которые действительны для суммы их открытых ключей. Это основа для построения конструкций более высокого уровня, которые повышают эффективность и конфиденциальность мульти-подписей и смарт-контрактов.
MuSig дает Бате вот какие плюшки:
1) Позволяет агрегировать несколько открытых ключей (PublicKey) в один открытый ключ. Если еще проще, позволяет группе подписывающих лиц (каждый со своим собственным закрытым/открытым ключом) совместно подписывать одно сообщение, в результате чего получается одна подпись. Эта единственная подпись может быть затем проверена любым, кто также знает сообщение и открытые ключи подписывающих лиц.
Свойство объединения PublicKey называется агрегированием.
2) Схемы мультиподписей, дающих агрегацию подписей Шнорра, уже имеются на "рынке" решений. Но их недостаток в том, что эти схемы требуют проверки наличия PrivateKey, соответствующего PublicKey. MuSig таких требований не предъявляет. Все что нужно - это PublicKey.
В схеме мультиподписей, поддерживающих агрегацию ключей, мультиподпись выглядит как подпись с одним ключом. Верификаторам не требуются знания открытых ключей исходных участников. Им будет достаточно только агрегированного ключа. MuSig фактически является ключевой схемой агрегирования подписей Шнорра.
Схема агрегирования ключей также позволяет сократить число PublicKey на вход транзакции до одного.
Но ясное дело, что без проблем не обошлось.
Подписи MuSig, так же как подписи Schnorr или ECDSA, используют в своей конструкции поле “nonce”, которое должно быть неповторяемым.
Буду честен, я не смог до конца разобраться в описании этой уязвимости. Математика тут сильнее меня☺️ Для тех кому интересно, оставляю ссылочку (https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da) (англ.)
А это статья (https://blockstream.com/2019/02/18/en-musig-a-new-multisignature-standard/) разработчика BlockStream о MuSig...Ну чтобы подробнее разобраться (англ.)😉
GitHub MuSig (https://github.com/ElementsProject/secp256k1-zkp/tree/secp256k1-zkp/src/modules/musig)
плюсую по Stratum V2
тоже почитал бы информацию
тоже почитал бы информацию
Приветствую, хочу выразить благодарность за освещение постов с канала t.me/CryptoBotan, тут на форуме. Я веду этот канал, но вот юзать форумы, для меня, увы, сложновато)
На самом деле, испытываю огромное количество проблем при разборе и поиске инфы. Во-первых, из-за того, что я абсолютно далек от темы кодинга или программирования (но это не основное). Во-вторых, малое количество информации в сети и отсутствие коммуникации со знающими людьми, которые могли бы чуть что указать на ошибки и растолковать непонятные вещи.
Я сам себе поставил цель, стать мостом между массами и гиками. Так что, тот факт, что, при написании поста о Tapscript и поиске инфы о нем, я случайно наткнулся на этот топик, дает мне новый толчок к стремлению реализовать мои цели и планы
Буду рад замечаниям и критике со стороны знающих людей. Я не отрицаю тот факт, что мои упрощения смыслов, при написании постов, могут быть неверны. Именно поэтому приму любой фидбек.
t.me/Russiano55
. Я веду этот канал, но вот юзать форумы, для меня, увы, сложновато)На самом деле, испытываю огромное количество проблем при разборе и поиске инфы. Во-первых, из-за того, что я абсолютно далек от темы кодинга или программирования (но это не основное). Во-вторых, малое количество информации в сети и отсутствие коммуникации со знающими людьми, которые могли бы чуть что указать на ошибки и растолковать непонятные вещи.
Я сам себе поставил цель, стать мостом между массами и гиками. Так что, тот факт, что, при написании поста о Tapscript и поиске инфы о нем, я случайно наткнулся на этот топик, дает мне новый толчок к стремлению реализовать мои цели и планы
Буду рад замечаниям и критике со стороны знающих людей. Я не отрицаю тот факт, что мои упрощения смыслов, при написании постов, могут быть неверны. Именно поэтому приму любой фидбек.
t.me/Russiano55
Вот интересная тема о которой я мало что нашел в интернете: https://www.youtube.com/watch?v=_lLhPyiyarY
Как я понимаю это новые предложения по улучшению функционала BTC.
Очень интересен момент по децентрализации майнинга путем Stratum V2, но не очень понятно как это планируется сделать на практике.
https://t.me/CryptoBotan/935
Microsoft ION: глобальная децентрализованная идентификация пользователей.
Для описания стека биткоина (https://t.me/CryptoBotan/888)
Анонс творения (https://www.microsoft.com/en-us/microsoft-365/blog/2018/02/12/decentralized-digital-identities-and-blockchain-the-future-as-we-see-it/) произошел в феврале 2018 года, под названием "Система децентрализованной идентификации - Decentralized identities digital" (DID). В мае 2019 компания рассказала о первых наработках — система получила название ION и в её основе лежит Биткойн-блокчейн.
Microsoft разрабатывает протоколы и стандарты с открытым исходным кодом совместно с консорциумом World Wide Web и ассоциацией Decentralized Identity Foundation, членами которой также являются IBM и Mastercard.
Если коротко, то идея в том, чтобы создать универсальный идентификатор для сервисов, сайтов и приложений по типу Facebook Connect. Но персональные данные будут храниться децентрализованно, а не на серверах Microsoft.
ION - это опенсорс проект, имеющий в себе инструменты для обмена информации между порталами и сетями. Мы уже используем такой подход, когда пытаемся пройти аворизацию, используя почту или FB. Данные просто передаются между сетями.
В случае с ION, обрабатывается децентрализованный идентификатор (DID), который доказывает право на владения ключами. По словам разработчиков, решение обеспечивает куда большую пропускную способность, чем сам блокчейн.
ION работает с протоколами 2 уровня, то есть поверх блокчейна Биткойна, а не по цепочке транзакций, для увеличения масштабируемости сети.
Основные компоненты ION:
Decentralized Identifiers (DID) - это спецификация W3C, определяющая общий формат документа для описания состояния децентрализованного идентификатора.
W3C — это консорциум всемирной сети, такая некоммерческая организация, в рамках которой разрабатывают технологии, на которых работает веб.
Identity Hubs -это зашифрованное хранилище данных идентификации, которое включает ретрансляцию сообщений, обработку аттестации и вычислительные конечные точки для идентификации.
Universal DID Resolver - сервера, что пропускают DID через блокчейн.
Verifiable Credentials - спецификация W3C, которая определяет формат документа для кодирования.
Управляемые ION идентификаторы децентрализованы. После удаления учетной записи, доступ к привязанным к аккаунту сервисам сохранится. Все публикуемые в профиле фотографии будут принадлежать пользователю, а не соцсети.
Для тестирования своего децентрализованного детища, будет добавлена (сроки не указаны) поддержка Microsoft Authenticator, который уже юзают миллионы пользователей.
Microsoft Authenticator сможет выступать в качестве агента пользователя для управления идентификационными данными и криптографическими ключами. Идентификационные данные хранятся в Identity Hubs, зашифрованном с помощью этих криптографических ключей.
Как только появится эта возможность, приложения и службы смогут взаимодействовать с данными пользователя, используя общий канал обмена сообщениями.
И в конце немного закулисных игр.
Microsoft приглашала для тестирования решения и совместной разработки продукта - Facebook. Но те отказались. Интересное мнение на этот счет ниже/.
⬇️⬇️⬇️
https://www.coindesk.com/microsoft-launches-decentralized-identity-tool-on-bitcoin-blockchain
Microsoft ION: глобальная децентрализованная идентификация пользователей.
Для описания стека биткоина (https://t.me/CryptoBotan/888)
Анонс творения (https://www.microsoft.com/en-us/microsoft-365/blog/2018/02/12/decentralized-digital-identities-and-blockchain-the-future-as-we-see-it/) произошел в феврале 2018 года, под названием "Система децентрализованной идентификации - Decentralized identities digital" (DID). В мае 2019 компания рассказала о первых наработках — система получила название ION и в её основе лежит Биткойн-блокчейн.
Microsoft разрабатывает протоколы и стандарты с открытым исходным кодом совместно с консорциумом World Wide Web и ассоциацией Decentralized Identity Foundation, членами которой также являются IBM и Mastercard.
Если коротко, то идея в том, чтобы создать универсальный идентификатор для сервисов, сайтов и приложений по типу Facebook Connect. Но персональные данные будут храниться децентрализованно, а не на серверах Microsoft.
ION - это опенсорс проект, имеющий в себе инструменты для обмена информации между порталами и сетями. Мы уже используем такой подход, когда пытаемся пройти аворизацию, используя почту или FB. Данные просто передаются между сетями.
В случае с ION, обрабатывается децентрализованный идентификатор (DID), который доказывает право на владения ключами. По словам разработчиков, решение обеспечивает куда большую пропускную способность, чем сам блокчейн.
ION работает с протоколами 2 уровня, то есть поверх блокчейна Биткойна, а не по цепочке транзакций, для увеличения масштабируемости сети.
Основные компоненты ION:
Decentralized Identifiers (DID) - это спецификация W3C, определяющая общий формат документа для описания состояния децентрализованного идентификатора.
W3C — это консорциум всемирной сети, такая некоммерческая организация, в рамках которой разрабатывают технологии, на которых работает веб.
Identity Hubs -это зашифрованное хранилище данных идентификации, которое включает ретрансляцию сообщений, обработку аттестации и вычислительные конечные точки для идентификации.
Universal DID Resolver - сервера, что пропускают DID через блокчейн.
Verifiable Credentials - спецификация W3C, которая определяет формат документа для кодирования.
Управляемые ION идентификаторы децентрализованы. После удаления учетной записи, доступ к привязанным к аккаунту сервисам сохранится. Все публикуемые в профиле фотографии будут принадлежать пользователю, а не соцсети.
Для тестирования своего децентрализованного детища, будет добавлена (сроки не указаны) поддержка Microsoft Authenticator, который уже юзают миллионы пользователей.
Microsoft Authenticator сможет выступать в качестве агента пользователя для управления идентификационными данными и криптографическими ключами. Идентификационные данные хранятся в Identity Hubs, зашифрованном с помощью этих криптографических ключей.
Как только появится эта возможность, приложения и службы смогут взаимодействовать с данными пользователя, используя общий канал обмена сообщениями.
И в конце немного закулисных игр.
Microsoft приглашала для тестирования решения и совместной разработки продукта - Facebook. Но те отказались. Интересное мнение на этот счет ниже/.
⬇️⬇️⬇️
https://www.coindesk.com/microsoft-launches-decentralized-identity-tool-on-bitcoin-blockchain
https://t.me/CryptoBotan/934
Компания Tierion https://tierion.com/объявила о выпуске набора инструментов, разработанного совместно с Lightning Labs https://lightning.engineering/, которые помогут включить аутентификацию Bitcoin-native с использованием токенов аутентификации LSATS – Lightning Service.
https://www.cryptoninjas.net/2020/01/21/tierion-introduces-set-of-open-source-tools-to-create-trustless-lightning-apps/
Tierion - это универсальная платформа, позволяющая проводить верификацию данных. Tierion создает доказательство привязки данных с транзакциями на блокчейне. Используя это доказательство, любой человек может проверить метку времени и целостность данных без третьих лиц.
LSATs объединяет микроплатежи через Lightning со стандартом 402 Payment Required HTTP status code, macaroons, и authorization headers.
Macaroons (аналог Cookies) - это небольшой кусочек данных, чтобы подтвердить разрешение выполнять действия. Служба ищет идентификатор macaroon и проверяет, что он был изначально подписан корневым ключом сервиса. Однако, в отличие от файла cookie, вы можете делегировать macaroon или создать его версию с более ограниченными возможностями, а затем отправить его кому-то другому для использования.
402 Payment Required HTTP status code - этот код указывает, что запрос не может быть обработан до тех пор, пока клиент не производеит оплату. Это означает, что запрашиваемые данные не будут доступны до тех пор, пока клиент не производит оплату.
Authorization header содержит учетные данные для аутентификации агента пользователя с сервером.
Аутентификация (кто делает запрос) и авторизация (устанавливает разрешения для каждого пользователя) требуются для различных веб-и мобильных приложений.
ПО Boltwall активирует Bitcoin Lightning доступ и идентификацию используя LSATs. Пользователи могут взимать плату за доступ к своему API, не требуя учетных записей пользователей, ключей API, кредитных карт или хранения каких-либо пользовательских данных.
LSAT - это заголовок HTTP, который кодирует macaroons и lightning-счет. Токен LSAT состоит из двух частей: macaroons и подтверждения оплаты. Платежи Lightning обеспечивают криптографически безопасный способ подтверждения платежа.
Now-Boltwall - это утилита командной строки, которая помогает развернуть живой сервер с поддержкой Boltwall.
LSAT-js - служебная библиотека, написанная на машинном языке и совместимая с большинством современных браузеров. Он предоставляет инструменты для построения, анализа и проверки LSAT на стороне сервера или клиента.
LSAT Playground - клиентское веб-приложение, которое демонстрирует все инструменты, доступные в lsat-js.
Boltwall и lsat-js облегчат разработчикам создание приложений, построенных на основе инфраструктуры аутентификации.
GitHub Boltwall (https://github.com/Tierion/boltwall)
Компания Tierion https://tierion.com/объявила о выпуске набора инструментов, разработанного совместно с Lightning Labs https://lightning.engineering/, которые помогут включить аутентификацию Bitcoin-native с использованием токенов аутентификации LSATS – Lightning Service.
https://www.cryptoninjas.net/2020/01/21/tierion-introduces-set-of-open-source-tools-to-create-trustless-lightning-apps/
Tierion - это универсальная платформа, позволяющая проводить верификацию данных. Tierion создает доказательство привязки данных с транзакциями на блокчейне. Используя это доказательство, любой человек может проверить метку времени и целостность данных без третьих лиц.
LSATs объединяет микроплатежи через Lightning со стандартом 402 Payment Required HTTP status code, macaroons, и authorization headers.
Macaroons (аналог Cookies) - это небольшой кусочек данных, чтобы подтвердить разрешение выполнять действия. Служба ищет идентификатор macaroon и проверяет, что он был изначально подписан корневым ключом сервиса. Однако, в отличие от файла cookie, вы можете делегировать macaroon или создать его версию с более ограниченными возможностями, а затем отправить его кому-то другому для использования.
402 Payment Required HTTP status code - этот код указывает, что запрос не может быть обработан до тех пор, пока клиент не производеит оплату. Это означает, что запрашиваемые данные не будут доступны до тех пор, пока клиент не производит оплату.
Authorization header содержит учетные данные для аутентификации агента пользователя с сервером.
Аутентификация (кто делает запрос) и авторизация (устанавливает разрешения для каждого пользователя) требуются для различных веб-и мобильных приложений.
ПО Boltwall активирует Bitcoin Lightning доступ и идентификацию используя LSATs. Пользователи могут взимать плату за доступ к своему API, не требуя учетных записей пользователей, ключей API, кредитных карт или хранения каких-либо пользовательских данных.
LSAT - это заголовок HTTP, который кодирует macaroons и lightning-счет. Токен LSAT состоит из двух частей: macaroons и подтверждения оплаты. Платежи Lightning обеспечивают криптографически безопасный способ подтверждения платежа.
Now-Boltwall - это утилита командной строки, которая помогает развернуть живой сервер с поддержкой Boltwall.
LSAT-js - служебная библиотека, написанная на машинном языке и совместимая с большинством современных браузеров. Он предоставляет инструменты для построения, анализа и проверки LSAT на стороне сервера или клиента.
LSAT Playground - клиентское веб-приложение, которое демонстрирует все инструменты, доступные в lsat-js.
Boltwall и lsat-js облегчат разработчикам создание приложений, построенных на основе инфраструктуры аутентификации.
GitHub Boltwall (https://github.com/Tierion/boltwall)
sr. member
Activity: 938
Merit: 466
~[f#
Приветствую, хочу выразить благодарность за освещение постов с канала t.me/CryptoBotan, тут на форуме. Я веду этот канал, но вот юзать форумы, для меня, увы, сложновато)
На самом деле, испытываю огромное количество проблем при разборе и поиске инфы. Во-первых, из-за того, что я абсолютно далек от темы кодинга или программирования (но это не основное). Во-вторых, малое количество информации в сети и отсутствие коммуникации со знающими людьми, которые могли бы чуть что указать на ошибки и растолковать непонятные вещи.
Я сам себе поставил цель, стать мостом между массами и гиками. Так что, тот факт, что, при написании поста о Tapscript и поиске инфы о нем, я случайно наткнулся на этот топик, дает мне новый толчок к стремлению реализовать мои цели и планы
Буду рад замечаниям и критике со стороны знающих людей. Я не отрицаю тот факт, что мои упрощения смыслов, при написании постов, могут быть неверны. Именно поэтому приму любой фидбек.
t.me/Russiano55
. Я веду этот канал, но вот юзать форумы, для меня, увы, сложновато)На самом деле, испытываю огромное количество проблем при разборе и поиске инфы. Во-первых, из-за того, что я абсолютно далек от темы кодинга или программирования (но это не основное). Во-вторых, малое количество информации в сети и отсутствие коммуникации со знающими людьми, которые могли бы чуть что указать на ошибки и растолковать непонятные вещи.
Я сам себе поставил цель, стать мостом между массами и гиками. Так что, тот факт, что, при написании поста о Tapscript и поиске инфы о нем, я случайно наткнулся на этот топик, дает мне новый толчок к стремлению реализовать мои цели и планы
Буду рад замечаниям и критике со стороны знающих людей. Я не отрицаю тот факт, что мои упрощения смыслов, при написании постов, могут быть неверны. Именно поэтому приму любой фидбек.
t.me/Russiano55
Круто!
Спасибо тебе за интересный контент. Я думаю что это для многих интересно.
Если тебе удобно то можешь и сюда постить. Это лучше чем если я буду репостить.
Тем технологических улучшений Биткоина актуальна сейчас. Я думаю что будет активность в этом направлении.
Quote
Лукас Нуцци, соучредитель и директор Digital Asset Research написал в своем твиттере (https://twitter.com/LucasNuzzi/status/1217903211950092288 https://coinspot.io/technology/bitcoin/podpisi-shnorra-taproot-i-tapscript-bitcoin-mozhet-provesti-novyj-softfork-uzhe-v-etom-godu/):
Биткоин проведет софтфорк в этом году. Это пока одни из самых инновационных решений первого уровня: bip- schnorr + bip-taproot + bip-tapscript. Это мощные фундаментальные технологии, которые реализуют новые смарт-контракты на базовом уровне биткоина. 2020 год будет хорошим.
⬇️⬇️⬇️
https://coinspot.io/technology/bitcoin/podpisi-shnorra-taproot-i-tapscript-bitcoin-mozhet-provesti-novyj-softfork-uzhe-v-etom-godu/
Подписи Шнорра в BTC
⬇️⬇️⬇️
https://t.me/CryptoBotan/704
Для понимания Taproot необходимо разобраться с MAST
⬇️⬇️⬇️
https://t.me/CryptoBotan/719
Технология Taproot
⬇️⬇️⬇️
https://t.me/CryptoBotan/710
Плюс к этому посту, хочу добавить пост про Miniscript - язык программирования для смарт-контрактов Bitcoin.
⬇️⬇️⬇️
https://t.me/CryptoBotan/862
Пост про Tapscript сделаю отдельный, так что, считайте это анонсом😅
https://t.me/CryptoBotan/930Биткоин проведет софтфорк в этом году. Это пока одни из самых инновационных решений первого уровня: bip- schnorr + bip-taproot + bip-tapscript. Это мощные фундаментальные технологии, которые реализуют новые смарт-контракты на базовом уровне биткоина. 2020 год будет хорошим.
⬇️⬇️⬇️
https://coinspot.io/technology/bitcoin/podpisi-shnorra-taproot-i-tapscript-bitcoin-mozhet-provesti-novyj-softfork-uzhe-v-etom-godu/
Подписи Шнорра в BTC
⬇️⬇️⬇️
https://t.me/CryptoBotan/704
Для понимания Taproot необходимо разобраться с MAST
⬇️⬇️⬇️
https://t.me/CryptoBotan/719
Технология Taproot
⬇️⬇️⬇️
https://t.me/CryptoBotan/710
Плюс к этому посту, хочу добавить пост про Miniscript - язык программирования для смарт-контрактов Bitcoin.
⬇️⬇️⬇️
https://t.me/CryptoBotan/862
Пост про Tapscript сделаю отдельный, так что, считайте это анонсом😅
Quote
Затрагивая стек биткоина (https://t.me/CryptoBotan/888), который я разбираю уже второй месяц и прошлый пост (https://t.me/CryptoBotan/930) про софтфорк, сегодня о tapscript.
Tapscript - обновленная версия языка программирования Bitcoin.
⬇️⬇️⬇️
Прежде чем затронуть tapscript, нужно кое с чем разобраться
Биткойн использует скриптовую систему для транзакций.
Script (сценарий) - это, по сути, список инструкций, записанных с каждой транзакцией, которые описывают, как следующий человек, желающий потратить передаваемые биткойны, может получить к ним доступ.
Скриптинг предоставляет возможность гибко изменять параметры, которые определяют правила траты переведенных биткоинов.
Скриптовая система может быть использована для того, чтобы потребовать два закрытых ключа, или комбинацию нескольких ключей, или никаких ключей.
Opcodes (опкоды, команды, функции) - это список всех слов скрипта. Это коды операций на языке Bitcoin Script, которые передают данные или выполняют функции в ScriptPubKey или скрипте подписи.
Что за ScriptPubKey читайте в этом посте
(https://t.me/CryptoBotan/715)Ссылочка (https://en.bitcoin.it/wiki/Script#Opcodes) для детального изучения Opcodes.
Кстати, некоторые опкоды были удалены из протокола. Какие-то из-за ненадобности, а какие-то были вредны. Например, так называемы опкоды Сатоши, OP_LSHIFT, OP_RSHIFT, OP_DIV, OP_MUL и другие...
Но да ладно, я отвлекся...
///
Итак, Tapscript - это язык сценариев, используемый для сценариев Taproot (https://t.me/CryptoBotan/710). В нем отключены, объединены или модифицированы некоторые из опкодов. Отключенные опкоды отказывают и завершают сценарии сразу же при выполнении, и игнорируются, когда обнаруживаются в неисполненной ветви сценария.
В Script присутствуют такие опкоды как:
OP_CHECKMULTISIG - Сравнивает первую подпись с каждым открытым ключом, пока не найдет соответствие ECDSA (https://t.me/CryptoBotan/824). Начиная с последующего открытого ключа, он сравнивает вторую подпись с каждым оставшимся открытым ключом, пока не найдет соответствие ECDSA. Процесс повторяется до тех пор, пока не будут проверены все подписи или не останется достаточного количества открытых ключей для получения успешного результата. Все подписи должны соответствовать открытому ключу.
OP_CHECKMULTISIGVERIFY - То же самое, но выполняется позже.
В Tapscript эти два опкода отключены, а вместо них используется один - OP_CHECK SIG ADD. Он позволяет формировать ту же самую мультиподпись с возможностью пакетной проверки.
///
Опкоды OP_CHECKSIG и OP_CHECKSIGVERIFY ⬇️ модифицированы для работы с открытыми ключами и сигнатурами Шнорр (https://t.me/CryptoBotan/704), вместо ECDSA (https://t.me/CryptoBotan/824), и добавляется новый код OP_CHECKSIGADD.
OP_CHECKSIG - это код операции сценария, используемый для проверки правильности подписи для ввода tx. Т.е. проверяет подпись на соответствие транзакции.
OP_CHECKSIGVERIFY - То же самое, но позже.
///
Подпись сообщений tapscript также упрощает обработку OP_CODESEPARATOR и делает ее более эффективной.
OP_CODESEPARATOR используется для проверки OP_CHECKSIG
///
Опкод OP_NOP: в библиотеке опкодов (https://en.bitcoin.it/wiki/Script)красуется надпись "Does nothing". Но, как оказалось, этот опкод позволяет внедрять новые опкоды. В Tapscript он заменен на OP_SUCCESS, который позволяет делать это более "cleanly".
Более подробную информацию можно взять на github: bip-tapscript.mediawiki
(https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki#Rationale)Tapscript может быть внедрен с помощью софт-форка. Внедрение Tapscript упростит внедрение опкодов и проведение софтфорков.
https://t.me/CryptoBotan/931Tapscript - обновленная версия языка программирования Bitcoin.
⬇️⬇️⬇️
Прежде чем затронуть tapscript, нужно кое с чем разобраться
Биткойн использует скриптовую систему для транзакций.
Script (сценарий) - это, по сути, список инструкций, записанных с каждой транзакцией, которые описывают, как следующий человек, желающий потратить передаваемые биткойны, может получить к ним доступ.
Скриптинг предоставляет возможность гибко изменять параметры, которые определяют правила траты переведенных биткоинов.
Скриптовая система может быть использована для того, чтобы потребовать два закрытых ключа, или комбинацию нескольких ключей, или никаких ключей.
Opcodes (опкоды, команды, функции) - это список всех слов скрипта. Это коды операций на языке Bitcoin Script, которые передают данные или выполняют функции в ScriptPubKey или скрипте подписи.
Что за ScriptPubKey читайте в этом посте
(https://t.me/CryptoBotan/715)Ссылочка (https://en.bitcoin.it/wiki/Script#Opcodes) для детального изучения Opcodes.
Кстати, некоторые опкоды были удалены из протокола. Какие-то из-за ненадобности, а какие-то были вредны. Например, так называемы опкоды Сатоши, OP_LSHIFT, OP_RSHIFT, OP_DIV, OP_MUL и другие...
Но да ладно, я отвлекся...
///
Итак, Tapscript - это язык сценариев, используемый для сценариев Taproot (https://t.me/CryptoBotan/710). В нем отключены, объединены или модифицированы некоторые из опкодов. Отключенные опкоды отказывают и завершают сценарии сразу же при выполнении, и игнорируются, когда обнаруживаются в неисполненной ветви сценария.
В Script присутствуют такие опкоды как:
OP_CHECKMULTISIG - Сравнивает первую подпись с каждым открытым ключом, пока не найдет соответствие ECDSA (https://t.me/CryptoBotan/824). Начиная с последующего открытого ключа, он сравнивает вторую подпись с каждым оставшимся открытым ключом, пока не найдет соответствие ECDSA. Процесс повторяется до тех пор, пока не будут проверены все подписи или не останется достаточного количества открытых ключей для получения успешного результата. Все подписи должны соответствовать открытому ключу.
OP_CHECKMULTISIGVERIFY - То же самое, но выполняется позже.
В Tapscript эти два опкода отключены, а вместо них используется один - OP_CHECK SIG ADD. Он позволяет формировать ту же самую мультиподпись с возможностью пакетной проверки.
///
Опкоды OP_CHECKSIG и OP_CHECKSIGVERIFY ⬇️ модифицированы для работы с открытыми ключами и сигнатурами Шнорр (https://t.me/CryptoBotan/704), вместо ECDSA (https://t.me/CryptoBotan/824), и добавляется новый код OP_CHECKSIGADD.
OP_CHECKSIG - это код операции сценария, используемый для проверки правильности подписи для ввода tx. Т.е. проверяет подпись на соответствие транзакции.
OP_CHECKSIGVERIFY - То же самое, но позже.
///
Подпись сообщений tapscript также упрощает обработку OP_CODESEPARATOR и делает ее более эффективной.
OP_CODESEPARATOR используется для проверки OP_CHECKSIG
///
Опкод OP_NOP: в библиотеке опкодов (https://en.bitcoin.it/wiki/Script)красуется надпись "Does nothing". Но, как оказалось, этот опкод позволяет внедрять новые опкоды. В Tapscript он заменен на OP_SUCCESS, который позволяет делать это более "cleanly".
Более подробную информацию можно взять на github: bip-tapscript.mediawiki
(https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki#Rationale)Tapscript может быть внедрен с помощью софт-форка. Внедрение Tapscript упростит внедрение опкодов и проведение софтфорков.
Несколько новостей по проектам развивающим технологии в Биткоине
https://www.cryptoninjas.net/2020/01/21/tierion-introduces-set-of-open-source-tools-to-create-trustless-lightning-apps/ -Tierion introduces set of open-source tools to create ‘trustless’ Lightning apps
https://www.cryptoninjas.net/2020/01/20/dexfreight-integrates-rif-blockchain-solutions-to-decentralize-logistics/- dexFreight integrates RIF blockchain solutions to decentralize logistics
https://www.cryptoninjas.net/2020/01/21/ptokens-cross-chain-platform-adds-bitcoin-pbtc-to-testnet/ - pTokens cross-chain platform adds bitcoin (pBTC) to testnet
https://www.cryptoninjas.net/2020/01/21/btcpay-launches-desktop-app-to-improve-hardware-wallet-node-communication/ - BTCPay launches desktop app to improve hardware wallet – node communication
https://www.cryptoninjas.net/2020/01/22/blockstack-proposes-new-consensus-which-provides-network-rewards-in-bitcoin/ -Blockstack proposes new consensus which provides network rewards in bitcoin
Приветствую, хочу выразить благодарность за освещение постов с канала t.me/CryptoBotan, тут на форуме. Я веду этот канал, но вот юзать форумы, для меня, увы, сложновато)
На самом деле, испытываю огромное количество проблем при разборе и поиске инфы. Во-первых, из-за того, что я абсолютно далек от темы кодинга или программирования (но это не основное). Во-вторых, малое количество информации в сети и отсутствие коммуникации со знающими людьми, которые могли бы чуть что указать на ошибки и растолковать непонятные вещи.
Я сам себе поставил цель, стать мостом между массами и гиками. Так что, тот факт, что, при написании поста о Tapscript и поиске инфы о нем, я случайно наткнулся на этот топик, дает мне новый толчок к стремлению реализовать мои цели и планы
Буду рад замечаниям и критике со стороны знающих людей. Я не отрицаю тот факт, что мои упрощения смыслов, при написании постов, могут быть неверны. Именно поэтому приму любой фидбек.
t.me/Russiano55
. Я веду этот канал, но вот юзать форумы, для меня, увы, сложновато)На самом деле, испытываю огромное количество проблем при разборе и поиске инфы. Во-первых, из-за того, что я абсолютно далек от темы кодинга или программирования (но это не основное). Во-вторых, малое количество информации в сети и отсутствие коммуникации со знающими людьми, которые могли бы чуть что указать на ошибки и растолковать непонятные вещи.
Я сам себе поставил цель, стать мостом между массами и гиками. Так что, тот факт, что, при написании поста о Tapscript и поиске инфы о нем, я случайно наткнулся на этот топик, дает мне новый толчок к стремлению реализовать мои цели и планы
Буду рад замечаниям и критике со стороны знающих людей. Я не отрицаю тот факт, что мои упрощения смыслов, при написании постов, могут быть неверны. Именно поэтому приму любой фидбек.
t.me/Russiano55
sr. member
Activity: 938
Merit: 466
~[f#
https://bitcoinops.org/en/newsletters/2020/01/22/ - Bitcoin Optech Newsletter #81
Походу еще одна инфографика технологического стека BTC с довольно неплохим объяснением
sr. member
Activity: 938
Merit: 466
~[f#
https://twitter.com/wiz/status/1219680013370310657
https://twitter.com/hodlhodl/status/1219295106496372737
https://twitter.com/Blockstream/status/1217543901709553672
Ликвид залистили на двух p2p площадках обмена и на платёжном сервисе. Ожидаю что эта тенденция будет продолжаться.
https://twitter.com/hodlhodl/status/1219295106496372737
https://twitter.com/Blockstream/status/1217543901709553672
Ликвид залистили на двух p2p площадках обмена и на платёжном сервисе. Ожидаю что эта тенденция будет продолжаться.
sr. member
Activity: 938
Merit: 466
~[f#
Quote
Omni (Omni Layer) (https://www.omnilayer.org/) - это платформа, для создания и торговли пользовательскими цифровыми активами и валютами.
Проект был основан в марте 2014 года на базе криптовалютного проекта Mastercoin, который существовал с июля 2013 года под контролем Mastercoin Foundation. Mastercoin Foundation создавался для временного управления фондами в адресе Exodus и распределении MSC. В январе 2016 года Фонд Mastercoin был переименован в Фонд Omni, а маркеры проекта MSC переименовали в OMNI. Ребрендинг был необходим в связи со сложившейся ситуацией связанной с MaidSafe и SafeCoin. (обязательно напишу об этом)
Omni представляет собой открытый исходный код криптовалюты и коммуникационный протокол. Это программный уровень, который облегчает создание и торговлю цифровыми активами и валютами.
Платформа использует блокчейн деда для предоставления дополнительных распределенных услуг, таких как децентрализованная торговля валютой, смарт-контракты, а также торговля цифровыми активами.
Omni позволяет генерировать выделенные пользователем ресурсы, которые в основном представлены в виде токенов. Эти токены могут олицетворять любую ценность, будь то товары или информация.
Так как Omni построен поверх сети Биткоин, то блокчейн BTC автоматически поддерживает токены OMNI.
Продукты Omni:
- протокола Omni – это надстройка над блокчейном BTC, которая позволяет создавать цифровые активы, осуществлять транзакции и проводить краудсейлы.
- Omni Core (https://www.omnilayer.org/download.html) - локальный кошелек платформы Omni, являющийся доработкой официального кошелька Биткоина.
- онлайн кошелек Omni (https://www.omniwallet.org/) - кошелек, привязанный к уникальному идентификатору, генерирующемуся при создании кошелька Omni, использование которого не требует инсталляции и запуска ноды.
- эксплорер Omni (https://omniexplorer.info/) - онлайн платформа, позволяющая отслеживать транзакции Omni в сети Биткоина.
- OmniDex (https://omniexplorer.info/) - децентрализованная криптовалютная торговая площадка, которую можно использовать с помощью кошельков Omni. (Позже и о дексе сделаю отдельный пост. Но это не точно)
Компанией, которая используют протокол Omni, является всеми известная и “любимая”- Tether.
Существует tether на основе протокола Omni Layer, на основе ERC20 и TRC20. Но это так, к слову.
Tether был изначально создан для использования блокчейна Bitcoin, а именно протокола Omni Layer, в качестве транспортного протокола для проведения транзакций токенов, обеспеченных фиатными деньгами.
Кстати в декабре 19-го, Tether инвестировал (https://bits.media/tether-investiroval-v-razrabotku-obnovleniya-dlya-protokola-omni-v-seti-bitkoina/) в разработку обновления протокола Omni в сети Биткойна.
Omni Layer Protocol — позволяет добавить сложные функции, не внося изменения в блокчейн Bitcoin.
Omni отвечает за следующие действия:
1. Создание и ликвидация токенов Tether;
2. Запись транзакций в блокчейн Tether и отображение деталей совершенных переводов;
3. Хранение токенов USDT, EURT, JPYT на кошельке Omni Wallet;
4. Создание мультиподписей
Кстати, протокол Omni использует тразакции OPReturn и был заменен, как наиболее часто используемый протокол в 2019 году. Veriblock использовался для создания 57% нового вывода OPReturn.
https://t.me/CryptoBotan/927Проект был основан в марте 2014 года на базе криптовалютного проекта Mastercoin, который существовал с июля 2013 года под контролем Mastercoin Foundation. Mastercoin Foundation создавался для временного управления фондами в адресе Exodus и распределении MSC. В январе 2016 года Фонд Mastercoin был переименован в Фонд Omni, а маркеры проекта MSC переименовали в OMNI. Ребрендинг был необходим в связи со сложившейся ситуацией связанной с MaidSafe и SafeCoin. (обязательно напишу об этом)
Omni представляет собой открытый исходный код криптовалюты и коммуникационный протокол. Это программный уровень, который облегчает создание и торговлю цифровыми активами и валютами.
Платформа использует блокчейн деда для предоставления дополнительных распределенных услуг, таких как децентрализованная торговля валютой, смарт-контракты, а также торговля цифровыми активами.
Omni позволяет генерировать выделенные пользователем ресурсы, которые в основном представлены в виде токенов. Эти токены могут олицетворять любую ценность, будь то товары или информация.
Так как Omni построен поверх сети Биткоин, то блокчейн BTC автоматически поддерживает токены OMNI.
Продукты Omni:
- протокола Omni – это надстройка над блокчейном BTC, которая позволяет создавать цифровые активы, осуществлять транзакции и проводить краудсейлы.
- Omni Core (https://www.omnilayer.org/download.html) - локальный кошелек платформы Omni, являющийся доработкой официального кошелька Биткоина.
- онлайн кошелек Omni (https://www.omniwallet.org/) - кошелек, привязанный к уникальному идентификатору, генерирующемуся при создании кошелька Omni, использование которого не требует инсталляции и запуска ноды.
- эксплорер Omni (https://omniexplorer.info/) - онлайн платформа, позволяющая отслеживать транзакции Omni в сети Биткоина.
- OmniDex (https://omniexplorer.info/) - децентрализованная криптовалютная торговая площадка, которую можно использовать с помощью кошельков Omni. (Позже и о дексе сделаю отдельный пост. Но это не точно)
Компанией, которая используют протокол Omni, является всеми известная и “любимая”- Tether.
Существует tether на основе протокола Omni Layer, на основе ERC20 и TRC20. Но это так, к слову.
Tether был изначально создан для использования блокчейна Bitcoin, а именно протокола Omni Layer, в качестве транспортного протокола для проведения транзакций токенов, обеспеченных фиатными деньгами.
Кстати в декабре 19-го, Tether инвестировал (https://bits.media/tether-investiroval-v-razrabotku-obnovleniya-dlya-protokola-omni-v-seti-bitkoina/) в разработку обновления протокола Omni в сети Биткойна.
Omni Layer Protocol — позволяет добавить сложные функции, не внося изменения в блокчейн Bitcoin.
Omni отвечает за следующие действия:
1. Создание и ликвидация токенов Tether;
2. Запись транзакций в блокчейн Tether и отображение деталей совершенных переводов;
3. Хранение токенов USDT, EURT, JPYT на кошельке Omni Wallet;
4. Создание мультиподписей
Кстати, протокол Omni использует тразакции OPReturn и был заменен, как наиболее часто используемый протокол в 2019 году. Veriblock использовался для создания 57% нового вывода OPReturn.
Quote
В прошлом посте об Omni Layer (https://t.me/CryptoBotan/927) говорилось о ребрендинге, который разработчики решили сделать в связи с запятнанной репутацией.
⬇️⬇️⬇️
Omni Layer - это бывший MasterCoin.
MSC был первым решением для Bitcoin 2.0, где технология использовалась для безопасных транзакций.
Проект предназначался для разрешения сложных финансовых задач в криптовалюте. Возможности MasterCoin включали в себя создание новых уровней валюты с новыми процедурами, используя Биткойн на уровне протокола. Этот новый уровень протокола должен был позволить создавать новые умные контракты, не выходя из настройки сети Биткойн. Протокол интеллектуальных контрактов, усиленный с использованием Mastercoin, инкапсулирует аутентификацию и реализацию контрактов. Т.е. позволяет виртуально обмениваться интеллектуальными активами.
Именно MasterCoin стал первым проектом вышедшим на ICO. Но это и погубило проект.
"Первопроходцами мостят дорогу" - не помню кто сказал.
Нашел на просторах, вот такую статью (https://newconomy.media/news/the-origin-story-of-the-initial-coin-offering-ico-token-sale-history) о MasterCoin. Там внутри еще и видео 2013 года, где основатель MasterCoin JR Willett представляет свою концепцию. Можно ли назвать это переломным моментом в криптоиндустрии?🤔
На тот момент, понятие "первичное предложение монет", было чем-то новым и революционным. Им удалось собрать что-то около $500к. Это был 2013 год, не забывайте...
В обновленной White Paper в 2013 году, содержался призыва к сбору средств. Средства нужно было отправить на адрес Bitcoin Exodus. Каждый инвестор получал х100 в виде MasterCoin в качестве pre-invest. План также включал в себя создание стимулирующих MSC на каждые 10MSC, которые планировалось отправить на тот же адрес Exodus, чтобы убедиться, что у команды достаточно средств, чтобы поднять их стоимость.
Как вы сами понимаете, такой подход вызвал волну критики и негодования со стороны сообщества. Хотя такой подход принес успех MSC.
В 2014 году, на рынке появился прямой конкурент MasterCoin - Counterparty (https://counterparty.io/), который занял значительную долю рынка, успех которого пришелся на черную полосу MasterCoin.
Значительную роль в подрыве репутации MasterCoin сыграл проект MaidSafe.
Проект предлагает обмен данными на жестком диске, который позволяет пользователям обмениваться своим дополнительным пространством хранения с другими людьми, которым необходимо место для хранения своих файлов. Для продажи места единицей транзакции являлся SafeCoin.
Основатель MaidSafe, Дэвид Ирвин, планировал собирать средства через массовую продажу Mastercoin, из которых 400 миллионов SafeCoins были получены по общей цене продажи в $8млн.
Суть такова: было объявлено вознаграждение за покупку SafeCoin за MSC, а не за BTC, для увеличения несуществующего объема продаж MSC. Ирвин предполагал, что MSC для продажи составит не менее 25% от рыночной капитализации.
В итоге предложенные вознаграждения обернулись накоплением большой суммы MSC и BTC около $7млн, что привело к повышению стоимости MSC. В результате ранние инвесторы MSC скинули свои монеты, что оставило Ирвину миллионы неликвидных средств и бесценных MSC.
Но пареньку все же удалось собрать BTC на $3млн, которые он использует для финансирования своего проекта.
Но даже после ребрендинга и переименования в Omni, проект остается позади своего конкурента CounterParty (https://counterparty.io/).
https://t.me/CryptoBotan/928⬇️⬇️⬇️
Omni Layer - это бывший MasterCoin.
MSC был первым решением для Bitcoin 2.0, где технология использовалась для безопасных транзакций.
Проект предназначался для разрешения сложных финансовых задач в криптовалюте. Возможности MasterCoin включали в себя создание новых уровней валюты с новыми процедурами, используя Биткойн на уровне протокола. Этот новый уровень протокола должен был позволить создавать новые умные контракты, не выходя из настройки сети Биткойн. Протокол интеллектуальных контрактов, усиленный с использованием Mastercoin, инкапсулирует аутентификацию и реализацию контрактов. Т.е. позволяет виртуально обмениваться интеллектуальными активами.
Именно MasterCoin стал первым проектом вышедшим на ICO. Но это и погубило проект.
"Первопроходцами мостят дорогу" - не помню кто сказал.
Нашел на просторах, вот такую статью (https://newconomy.media/news/the-origin-story-of-the-initial-coin-offering-ico-token-sale-history) о MasterCoin. Там внутри еще и видео 2013 года, где основатель MasterCoin JR Willett представляет свою концепцию. Можно ли назвать это переломным моментом в криптоиндустрии?🤔
На тот момент, понятие "первичное предложение монет", было чем-то новым и революционным. Им удалось собрать что-то около $500к. Это был 2013 год, не забывайте...
В обновленной White Paper в 2013 году, содержался призыва к сбору средств. Средства нужно было отправить на адрес Bitcoin Exodus. Каждый инвестор получал х100 в виде MasterCoin в качестве pre-invest. План также включал в себя создание стимулирующих MSC на каждые 10MSC, которые планировалось отправить на тот же адрес Exodus, чтобы убедиться, что у команды достаточно средств, чтобы поднять их стоимость.
Как вы сами понимаете, такой подход вызвал волну критики и негодования со стороны сообщества. Хотя такой подход принес успех MSC.
В 2014 году, на рынке появился прямой конкурент MasterCoin - Counterparty (https://counterparty.io/), который занял значительную долю рынка, успех которого пришелся на черную полосу MasterCoin.
Значительную роль в подрыве репутации MasterCoin сыграл проект MaidSafe.
Проект предлагает обмен данными на жестком диске, который позволяет пользователям обмениваться своим дополнительным пространством хранения с другими людьми, которым необходимо место для хранения своих файлов. Для продажи места единицей транзакции являлся SafeCoin.
Основатель MaidSafe, Дэвид Ирвин, планировал собирать средства через массовую продажу Mastercoin, из которых 400 миллионов SafeCoins были получены по общей цене продажи в $8млн.
Суть такова: было объявлено вознаграждение за покупку SafeCoin за MSC, а не за BTC, для увеличения несуществующего объема продаж MSC. Ирвин предполагал, что MSC для продажи составит не менее 25% от рыночной капитализации.
В итоге предложенные вознаграждения обернулись накоплением большой суммы MSC и BTC около $7млн, что привело к повышению стоимости MSC. В результате ранние инвесторы MSC скинули свои монеты, что оставило Ирвину миллионы неликвидных средств и бесценных MSC.
Но пареньку все же удалось собрать BTC на $3млн, которые он использует для финансирования своего проекта.
Но даже после ребрендинга и переименования в Omni, проект остается позади своего конкурента CounterParty (https://counterparty.io/).
sr. member
Activity: 938
Merit: 466
~[f#
Quote
Blockstream - сообщили (https://twitter.com/blockstream/status/1215726024224399362?s=21), что сегодня был завершен самый крупный peg-in в сайдчене BTC - Liquid, (500 BTC) и количество циркулируемых там L-BTC достигло исторического максимума - 600 L-BTC.
Столь быстрое развитие емкости сайдчена заставляет еще раз задуматься о том, что было сказано в этом посте (https://t.me/gfoundinshit/3227).
Емкость сети Lighting Network по данным 1ml.com составляет на данный момент - 865 BTC. Не намногим больше - чем емкость Liquid - и это результат долгого развития.
https://t.me/gfoundinshit/3253Столь быстрое развитие емкости сайдчена заставляет еще раз задуматься о том, что было сказано в этом посте (https://t.me/gfoundinshit/3227).
Емкость сети Lighting Network по данным 1ml.com составляет на данный момент - 865 BTC. Не намногим больше - чем емкость Liquid - и это результат долгого развития.
И еще вот пару репортов по развитию Биткоин-технологий
https://bitcoinops.org/en/newsletters/2020/01/08/
https://bitcoinops.org/en/newsletters/2020/01/15/
sr. member
Activity: 938
Merit: 466
~[f#
Вот появился годовой обзор технологий в Биткоине Bitcoin Optech Newsletter #78: 2019 Year-in-Review Special
Написал в задания.Может вдруг кто-то переведёт.
UPD : https://bitcointalksearch.org/topic/bitcoin-optech-78-5217103 -тема с переводом
Написал в задания.Может вдруг кто-то переведёт.
UPD : https://bitcointalksearch.org/topic/bitcoin-optech-78-5217103 -тема с переводом
то что с телеграмма копировать - это ок
но и тема может получится тоже интересной, если подключатся люди со знаниями и переводом
жаль что на форуме в основном люди другого типа
картинка довольно интересная, нигде не видел подобной диаграммы
да, довольно не малое количество разработок, я сам больше 50% только названия слышал и не знаю что это такое вообще
при внимательном рассмотрении, будет заметно, что одна и так же технология/разработка, может (и должна) относится не к одной категории, а к нескольким
тот же Шноррр, эрлей, ликвил, свопы или тапрут
скорее всего соединением, просто выделено основной направление
меня лично, больше всего интересует пропускная способность, а следовательно, все вещи связные с этим решения, протоколы, сайдчейны...
вот эти вот вещи https://utxos.org/uses/scaling/ и https://utxos.org/uses/batch-channels/ как-то обозначены?
по идее их надо бы отнести в "Performance & Usabillity" и лайтингу соответственно
в бипе - https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki
но и тема может получится тоже интересной, если подключатся люди со знаниями и переводом
жаль что на форуме в основном люди другого типа
картинка довольно интересная, нигде не видел подобной диаграммы
да, довольно не малое количество разработок, я сам больше 50% только названия слышал и не знаю что это такое вообще
при внимательном рассмотрении, будет заметно, что одна и так же технология/разработка, может (и должна) относится не к одной категории, а к нескольким
тот же Шноррр, эрлей, ликвил, свопы или тапрут
скорее всего соединением, просто выделено основной направление
меня лично, больше всего интересует пропускная способность, а следовательно, все вещи связные с этим решения, протоколы, сайдчейны...
вот эти вот вещи https://utxos.org/uses/scaling/ и https://utxos.org/uses/batch-channels/ как-то обозначены?
по идее их надо бы отнести в "Performance & Usabillity" и лайтингу соответственно
в бипе - https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki
sr. member
Activity: 938
Merit: 466
~[f#
Quote
Хай ботанята, надеюсь разбор стека биткоина (https://t.me/CryptoBotan/888) вам еще не наскучил😅
Сегодня продолжу говорить про решения второго уровня бати, а именно про Data anchoring on Bitcoin (DAB)
⬇️⬇️⬇️
На самом деле потенциал этого решения огромен, я приведу лишь примеры для более ясного понимания сути работы.
Data anchoring - это технология, в соответствии с которой операторы эксклюзивного блокчейна периодически высылают хеши блоков для включения в поддерживающий общедоступный блокчейн в формате транзакций-свидетельств.
Data anchoring on Bitcoin (привязка данных к биткойну) - это новый способ защиты и стандарт для создания надежных цифровых данных.
Основной принцип DAB заключается в привязке отпечатка (хэша) любых цифровых данных с транзакцией.
Вы знаете такую штуку, как Timestamp (временная метка), когда транзакция подтверждается, она попадает в блокчейн и открыта для всех, так что каждый желающий может проверить существование тех или иных данных в определенный момент времени. DAB являет собой новую и специфическую форму timestamping.
Привязка к блокчейнам не требует большого количества ресурсов и не создает критической зависимости от поддерживающего блокчейна — сотрудничество между операторами эксклюзивного блокчейна и майнерами на поддерживающем блокчейне носит необязательный характер.
Так же DAB решает проблему диверсификации безопасности распределенных реестров и может применяться в блокчейнах, которые не используют внутреннее доказательство работы. При этом оба подхода не являются взаимно исключающими и могут применяться одновременно для повышения уровня защищенности.
Какие проекты используют DAB в своих кейсах? Я привожу их только с точки зрения реализации решений.
https://www.woleet.io
Если очень коротко, то это DAB-провайдер, который выступает в качестве хаба, который факторизует хэши от разных клиентов, для уменьшения количества транзакций, снижая стоимость каждой проверки. Это низкоуровневый технический вариант использования принципа, что-то типа "Дай свой хэш и мы отправим тебе сертификат, мол твои данные целы и действительно существуют". Здесь биткоин используется только для привязки данных, что достигается путем использования протоколов второго уровня.
https://exonum.com
Это опенсорс фреймворк для создания приватных блокчейнов от компании Bitfury Group (https://bitfury.com/).
Exonum привязывается к биткойн-блокчейну, периодически высылая хеши блоков для включения в поддерживающий общедоступный блокчейн в формате транзакций-свидетельств. Для атаки на сеть, защищенную привязкой к открытому блокчейну, злоумышленникам приходится одновременно преодолевать механизмы консенсуса для эксклюзивного блокчейна и для поддерживающей цепи, что требует колоссальных вычислительных мощностей и не является рентабельным с точки зрения материальных затрат.
https://faizod.com
Предоставляет аналогичное решение
В следующих постах разберу на частных примерах, как используют DAB в своих решениях VeriBlock и Open Timestamps.
https://t.me/CryptoBotan/917Сегодня продолжу говорить про решения второго уровня бати, а именно про Data anchoring on Bitcoin (DAB)
⬇️⬇️⬇️
На самом деле потенциал этого решения огромен, я приведу лишь примеры для более ясного понимания сути работы.
Data anchoring - это технология, в соответствии с которой операторы эксклюзивного блокчейна периодически высылают хеши блоков для включения в поддерживающий общедоступный блокчейн в формате транзакций-свидетельств.
Data anchoring on Bitcoin (привязка данных к биткойну) - это новый способ защиты и стандарт для создания надежных цифровых данных.
Основной принцип DAB заключается в привязке отпечатка (хэша) любых цифровых данных с транзакцией.
Вы знаете такую штуку, как Timestamp (временная метка), когда транзакция подтверждается, она попадает в блокчейн и открыта для всех, так что каждый желающий может проверить существование тех или иных данных в определенный момент времени. DAB являет собой новую и специфическую форму timestamping.
Привязка к блокчейнам не требует большого количества ресурсов и не создает критической зависимости от поддерживающего блокчейна — сотрудничество между операторами эксклюзивного блокчейна и майнерами на поддерживающем блокчейне носит необязательный характер.
Так же DAB решает проблему диверсификации безопасности распределенных реестров и может применяться в блокчейнах, которые не используют внутреннее доказательство работы. При этом оба подхода не являются взаимно исключающими и могут применяться одновременно для повышения уровня защищенности.
Какие проекты используют DAB в своих кейсах? Я привожу их только с точки зрения реализации решений.
https://www.woleet.io
Если очень коротко, то это DAB-провайдер, который выступает в качестве хаба, который факторизует хэши от разных клиентов, для уменьшения количества транзакций, снижая стоимость каждой проверки. Это низкоуровневый технический вариант использования принципа, что-то типа "Дай свой хэш и мы отправим тебе сертификат, мол твои данные целы и действительно существуют". Здесь биткоин используется только для привязки данных, что достигается путем использования протоколов второго уровня.
https://exonum.com
Это опенсорс фреймворк для создания приватных блокчейнов от компании Bitfury Group (https://bitfury.com/).
Exonum привязывается к биткойн-блокчейну, периодически высылая хеши блоков для включения в поддерживающий общедоступный блокчейн в формате транзакций-свидетельств. Для атаки на сеть, защищенную привязкой к открытому блокчейну, злоумышленникам приходится одновременно преодолевать механизмы консенсуса для эксклюзивного блокчейна и для поддерживающей цепи, что требует колоссальных вычислительных мощностей и не является рентабельным с точки зрения материальных затрат.
https://faizod.com
Предоставляет аналогичное решение
В следующих постах разберу на частных примерах, как используют DAB в своих решениях VeriBlock и Open Timestamps.
Quote
VeriBlock и Data anchoring
Как и говорил, проект VeriBlock (https://www.veriblock.com/) использующий решение "привязка к блокчейну" (https://t.me/CryptoBotan/917).
⬇️⬇️⬇️
Это проект, реализующий алгоритм консенсуса Proof of Proof - PoP (доказательство доказательства).
В PoP, протокол консенсуса позволяет блокчейнам наследовать доказательства работы безопасности от других блокчейнов. Такая экосистема создает косвенную масштабируемость биткоина, используя его в качестве механизма безопасности для специально построенных, отдельных цепочек.
Внебиржевые транзакционные сети (LN) и сайдчейны, зависят от иерархической модели безопасности, которая позволяет всем блокчейнам работать в контексте безопасности биткойна. Протокол PoP позволяет наследовать свойства блокчейна Биткойн без участия и одобрения биткойн-майнеров, без централизации и без наложения каких-либо технологических ограничений на блокчейны, которые принимают этот протокол.
Протокол PoP вводит новый тип майнеров, которые выполняют периодические публикации текущего состояния одного блокчейна другому блокчейну. На эти публикации ссылаются в случае реорганизации блокчейна.
Эти майнеры, как мосты между наследуемым (SPB) и наследующими блокчейнами (SIB). Для встраивания данных состояния можно использовать несколько методов, один из которых OPRETURN
OPRETURN - это такой тип транзакции, который добавляет произвольные данные в скрипт PublicKey, но полные ноды не хранят эти данные в своей базе UTXO.
VeriBlock - это сеть на базе PoW, предназначенная для обработки простых транзакций (без сценариев) на мини-блокчейне, защищенном сетью Биткойн при помощью PoP. Здесь используется Algo PoP с привязкой к блокчейну Биткойн и PoW с хэшированием vBlake (https://bytwork.com/articles/algoritm-blake256-blake-r14-spisok-vseh-monet-i-maynerov-asic).
Блокчейн, использующий VeriBlock, будет использовать предоставленную библиотеку для автоматического отслеживания консенсуса VeriBlock и Bitcoin. Изменяя формат блока и структуру вознаграждения, происходит воознаграждение PoP-майнеров.
Совместно с VeriBlock используется блокчейн Custody, который предоставляет услуги по обеспечению целостности цифровых данных, поддерживаемые крупнейшим в мире источником хеширующей мощности (блокчейн биткоина).
Grand Central—мини-блокчейн, разрабатываемый для перекрестных каналов платежей, атомарных свопов и постквантовых подписей.
Одной из обсуждаемых тем (https://bits.media/proekt-veriblock-generiruet-bolee-30-tranzaktsiy-v-bitkoine/) использования VeriBlock стало большое число генерируемых транзакций в сети деда. Часть сообщества считают, что такой подход захламляет сеть и может привести к спам-атакам сети.
White Paper проекта VeriBlock
(https://www.veriblock.org/wp-content/uploads/2018/03/PoP-White-Paper.pdf)GitHub проекта проекта VeriBlock (https://github.com/VeriBlock/)
https://t.me/CryptoBotan/918 Как и говорил, проект VeriBlock (https://www.veriblock.com/) использующий решение "привязка к блокчейну" (https://t.me/CryptoBotan/917).
⬇️⬇️⬇️
Это проект, реализующий алгоритм консенсуса Proof of Proof - PoP (доказательство доказательства).
В PoP, протокол консенсуса позволяет блокчейнам наследовать доказательства работы безопасности от других блокчейнов. Такая экосистема создает косвенную масштабируемость биткоина, используя его в качестве механизма безопасности для специально построенных, отдельных цепочек.
Внебиржевые транзакционные сети (LN) и сайдчейны, зависят от иерархической модели безопасности, которая позволяет всем блокчейнам работать в контексте безопасности биткойна. Протокол PoP позволяет наследовать свойства блокчейна Биткойн без участия и одобрения биткойн-майнеров, без централизации и без наложения каких-либо технологических ограничений на блокчейны, которые принимают этот протокол.
Протокол PoP вводит новый тип майнеров, которые выполняют периодические публикации текущего состояния одного блокчейна другому блокчейну. На эти публикации ссылаются в случае реорганизации блокчейна.
Эти майнеры, как мосты между наследуемым (SPB) и наследующими блокчейнами (SIB). Для встраивания данных состояния можно использовать несколько методов, один из которых OPRETURN
OPRETURN - это такой тип транзакции, который добавляет произвольные данные в скрипт PublicKey, но полные ноды не хранят эти данные в своей базе UTXO.
VeriBlock - это сеть на базе PoW, предназначенная для обработки простых транзакций (без сценариев) на мини-блокчейне, защищенном сетью Биткойн при помощью PoP. Здесь используется Algo PoP с привязкой к блокчейну Биткойн и PoW с хэшированием vBlake (https://bytwork.com/articles/algoritm-blake256-blake-r14-spisok-vseh-monet-i-maynerov-asic).
Блокчейн, использующий VeriBlock, будет использовать предоставленную библиотеку для автоматического отслеживания консенсуса VeriBlock и Bitcoin. Изменяя формат блока и структуру вознаграждения, происходит воознаграждение PoP-майнеров.
Совместно с VeriBlock используется блокчейн Custody, который предоставляет услуги по обеспечению целостности цифровых данных, поддерживаемые крупнейшим в мире источником хеширующей мощности (блокчейн биткоина).
Grand Central—мини-блокчейн, разрабатываемый для перекрестных каналов платежей, атомарных свопов и постквантовых подписей.
Одной из обсуждаемых тем (https://bits.media/proekt-veriblock-generiruet-bolee-30-tranzaktsiy-v-bitkoine/) использования VeriBlock стало большое число генерируемых транзакций в сети деда. Часть сообщества считают, что такой подход захламляет сеть и может привести к спам-атакам сети.
White Paper проекта VeriBlock
(https://www.veriblock.org/wp-content/uploads/2018/03/PoP-White-Paper.pdf)GitHub проекта проекта VeriBlock (https://github.com/VeriBlock/)
sr. member
Activity: 938
Merit: 466
~[f#
Quote
Продолжаем разбирать стек деда (https://t.me/CryptoBotan/888), а именно сайдчейны. Сегодня на очереди DriveChain, где аксиомой в сути работы является тот факт, что с точки зрения теории игр, майнеры наименее "проблемные" хранители средств. Попытался заинтриговать🙈 Подробнее дальше...
DriveChain
(https://github.com/drivechain-project/docs/)⬇️⬇️⬇️
Драйвчейн - это имплементация сайдчейна, разработанная биткоин-разработчиком и директором по исследованиям в Tierion (TNT) Полом Шторцем.
Tierion (TNT) – токен ERC20, платформы для верификации данных.
Протокол позволяет создавать новые сайдчейны bitcoin, а также позволяет другим блокчейнам присоединяться к bitcoin и совершать транзакции, применяя BTC, но при этом оставаться и функционировать как отдельный блокчейн.
Драйвчейн, как и сайдчейн, используют модель "Двойной фиксации"two-way pegs (2WP), чтобы передавать BTC из основной сети в боковую. Я уже писал о способах двойной фиксации в посте про RSK (https://t.me/CryptoBotan/813)
Как работает DriveChain?
Передавая BTC из основной цепи в боковую, они блокируются на уникальном адресе P2SH (https://t.me/CryptoBotan/715). В основной сети монеты заблокированы, и никакая деятельность по реорганизации монет не может произойти, зато в боковой цепи, их можно использовать. Все как и в сайдчейнах, но разница в том, кто предоставляет информацию для передачи монет из основной сети в боковую и наоборот.
Протокол полагается на майнеров, которые становятся «алгоритмическими хранителями полномочий». Такой протокол сможет информировать майнеров о состоянии других сайдчейнов, подключенных к сети.
При использовании протокола драйвчейн, майнеры рассматриваются как хранители и управляют транзакциями.
Серхио Демиэн Лернер, работающий над этой версией протокола, представил биткоин-скрипт "OPCOUNTACKS". Он реализует такой функционал.
Тут попытался проще, заране извиняюсь😇:
Перенос монет из основной в боковую сети и наоборот, происходит путем объединенного майнинга, используя принципы теории игр. Майнеры майнят одновременно на двух цепях. Блок DriveChain собирается и хэшируется сначала с хэшем в coinbase-транзакции биткоина. Как только нужная сложность достигнута, блок биткоина отправляется в сеть. Блок DriveChain объединяется со всей инфой биткоин-блока.
Coinbase-транзакция - это особый тип транзакции, который не требует ранее существующих выходов. Он создает выходы (т. е. монеты) из ниоткуда. Это награда, которую майнеры получают за добычу новых блоков.
Объединенный майнинг используется для передачи BTC в боковую цепь. Для переноса BTC из боковой цепи, используется упрощенный метод проверки платежей.
При отправке монет в основную цепь, создаётся транзакция, которая "отменяет" монеты в боковой цепи и запрашивает адрес назначения в основной цепи. Создаётся транзакция CoinJoin (https://t.me/CryptoBotan/584) и id транзакции включается в заголовок блока боковой цепи. Затем транзакция CoinJoin включается в coinbase-блок биткоина. Майнеры голосуют за подтверждение транзакции и подтверждают, что она не была изменена, путем ссылки на боковую цепь. Затем происходит отправка монет.
Преимущества DriveChain:
1) Масштабирумость
2) Новшества без разрешения
Любой желающий может создать новый блокчейн, не создавая собственные монеты и системы.
3) Избавление от конкурентов (сомнительное преимущество)
Избавление от альткоинов
4) Функциональность
Драйвчейны как и сайдчейны позволяют тестировать новые функции. Они могут использоваться как тестовые сети.
https://t.me/CryptoBotan/899DriveChain
(https://github.com/drivechain-project/docs/)⬇️⬇️⬇️
Драйвчейн - это имплементация сайдчейна, разработанная биткоин-разработчиком и директором по исследованиям в Tierion (TNT) Полом Шторцем.
Tierion (TNT) – токен ERC20, платформы для верификации данных.
Протокол позволяет создавать новые сайдчейны bitcoin, а также позволяет другим блокчейнам присоединяться к bitcoin и совершать транзакции, применяя BTC, но при этом оставаться и функционировать как отдельный блокчейн.
Драйвчейн, как и сайдчейн, используют модель "Двойной фиксации"two-way pegs (2WP), чтобы передавать BTC из основной сети в боковую. Я уже писал о способах двойной фиксации в посте про RSK (https://t.me/CryptoBotan/813)
Как работает DriveChain?
Передавая BTC из основной цепи в боковую, они блокируются на уникальном адресе P2SH (https://t.me/CryptoBotan/715). В основной сети монеты заблокированы, и никакая деятельность по реорганизации монет не может произойти, зато в боковой цепи, их можно использовать. Все как и в сайдчейнах, но разница в том, кто предоставляет информацию для передачи монет из основной сети в боковую и наоборот.
Протокол полагается на майнеров, которые становятся «алгоритмическими хранителями полномочий». Такой протокол сможет информировать майнеров о состоянии других сайдчейнов, подключенных к сети.
При использовании протокола драйвчейн, майнеры рассматриваются как хранители и управляют транзакциями.
Серхио Демиэн Лернер, работающий над этой версией протокола, представил биткоин-скрипт "OPCOUNTACKS". Он реализует такой функционал.
Тут попытался проще, заране извиняюсь😇:
Перенос монет из основной в боковую сети и наоборот, происходит путем объединенного майнинга, используя принципы теории игр. Майнеры майнят одновременно на двух цепях. Блок DriveChain собирается и хэшируется сначала с хэшем в coinbase-транзакции биткоина. Как только нужная сложность достигнута, блок биткоина отправляется в сеть. Блок DriveChain объединяется со всей инфой биткоин-блока.
Coinbase-транзакция - это особый тип транзакции, который не требует ранее существующих выходов. Он создает выходы (т. е. монеты) из ниоткуда. Это награда, которую майнеры получают за добычу новых блоков.
Объединенный майнинг используется для передачи BTC в боковую цепь. Для переноса BTC из боковой цепи, используется упрощенный метод проверки платежей.
При отправке монет в основную цепь, создаётся транзакция, которая "отменяет" монеты в боковой цепи и запрашивает адрес назначения в основной цепи. Создаётся транзакция CoinJoin (https://t.me/CryptoBotan/584) и id транзакции включается в заголовок блока боковой цепи. Затем транзакция CoinJoin включается в coinbase-блок биткоина. Майнеры голосуют за подтверждение транзакции и подтверждают, что она не была изменена, путем ссылки на боковую цепь. Затем происходит отправка монет.
Преимущества DriveChain:
1) Масштабирумость
2) Новшества без разрешения
Любой желающий может создать новый блокчейн, не создавая собственные монеты и системы.
3) Избавление от конкурентов (сомнительное преимущество)
Избавление от альткоинов
4) Функциональность
Драйвчейны как и сайдчейны позволяют тестировать новые функции. Они могут использоваться как тестовые сети.
Quote
Так, так...Сайдчейны входящие в технологический стек биткоина (https://t.me/CryptoBotan/888) мы разобрали, смотри выше. Переходим ко 2 слою решений для масштабируемости сети Биткоин. Начнем, а точнее продолжим с Lightning Network.
Что такое LN писали много и не только я. Ниже посты для того, чтобы освежить память.
Подробнее о LN
⬇️⬇️⬇️
https://t.me/CryptoBotan/600
Приложения и дополнения LN.
⬇️⬇️⬇️
https://t.me/CryptoBotan/791
Channel Factories (CF)
⬇️⬇️⬇️
Это решение делает LN третьим слоем сети, в то время как сама лежит между блокчейном и платежными каналами, образуя новый слой и трехуровневую систему:
Blockchain - транзакции проверяются каждым узлом
CF - многосторонние платежные каналы
LN - результирующая сеть CF для платежей
Идея была предложена в 2017 году разработчиками: Conrad Burchert, Christian Decker и Roger Wattenhofer.
Они опубликовали White Paper (https://tik-old.ee.ethz.ch/file//a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf) "Scalable Funding of Bitcoin Micropayment Channel Networks" - "Масштабируемое финансирование сетевых каналов микроплатежей биткойн", где описали свое детище. Я постараюсь описать короче, лишь для понимания и представления.
Для открытия платежного канала LN юзер сначала финансирует свой канал. Он переводят свои средства на адрес 2-of-2 multisig в блокчейне.
После подтверждения, пользователи выполняют любое количество транзакций в этом канале, не помещая транзакции в блокчейн.
В завершении они могут закрыть канал, записав последнее состояние канала в блокчейн.
LN создавалась для увеличения скорости транзакций и обеспечивает создание двунаправленных каналов, которые имеют некоторые ограничения при настройке:
1) Средства блокируются в канале, до момента закрытия канала.
Блокировка средств в канале неудобна, особенно если нужно сделать ребаланс или заполнить каналы.
2) Открытие/закрытие транзакций внутри цепочки плохо масштабируется из-за ограничений пропускной способности Биткойна.
По мере увеличения числа пользователей LN, количество транзакций в цепочке тоже возрастет. Если 100 юзеров LN откроют по 5 каналов, то создаться 1000 транзакций в цепочке.
CF обеспечивает масштабируемое решение, при котором пользователи создают произвольное количество каналов в составе группы, что значительно снижает стоимость транзакций блокчейна. (Пример на фото)
Такая система позволяет быстро перераспределять средств по каналам, что снижает затраты на открытие новых каналов. Вместо одной блокчейн-транзакции, каждому пользователю требуется только одна транзакция для входа в группу узлов. Внутри группы пользователь может создать произвольное количество каналов. Для группы из 20 пользователей со 100 внутригрупповыми каналами стоимость блокчейн-транзакций снижается на 90% по сравнению со 100 обычными микроплатежными каналами.
Если ввести подписи Шнорра (https://t.me/CryptoBotan/704), этот показатель можно увеличить до 96%. Включение подписей Шнорра в протокол Биткоина совместно с CF обеспечит более компактные транзакции при публикации их в цепочке.
CF, как новый второй слой, состоит из многосторонних каналов для микроплатежей (Channel Factories), которые могут быстро переводить средства как и обычные двунаправленные каналы. Такая сеть обеспечивает уровень, где выполняются регулярные транзакции.
В CF работает "Хук-транзакция", открывающая совместное владение депонированными средствами между сторонами. Компонент, который обеспечивает финансирование нескольких многосторонних каналов, называется "распределением". Блгодаря распределению, одна или несколько последовательных транзакций могут извлекать заблокированные средства из многостороннего канала в качестве входных данных и финансировать несколько каналов с их выходами.
"Хук-транзакция" - это транзакция финансирования многостороннего канала, которая позволяет юзерам выводить средства из канала, если другие стороны становятся некооперативными. Открытие вторичных платежных каналов внутри CF происходит мгновенно.
Пользователи могут открывать и закрывать практически неограниченное количество каналов, что может значительно снизить нагрузку на сеть LN, если она будет масштабироваться до глобальной платежной сети с миллионами пользователей.
https://zen.yandex.ru/media/id/5c30dd7ce5e73b00aad07f3c/channel-factories-novyi-sloi-v-seti-bitcoin-dlia-provedeniia-mikroplatejei-5dfa4b6a5d6c4b00b8bae359
https://t.me/CryptoBotan/902Что такое LN писали много и не только я. Ниже посты для того, чтобы освежить память.
Подробнее о LN
⬇️⬇️⬇️
https://t.me/CryptoBotan/600
Приложения и дополнения LN.
⬇️⬇️⬇️
https://t.me/CryptoBotan/791
Channel Factories (CF)
⬇️⬇️⬇️
Это решение делает LN третьим слоем сети, в то время как сама лежит между блокчейном и платежными каналами, образуя новый слой и трехуровневую систему:
Blockchain - транзакции проверяются каждым узлом
CF - многосторонние платежные каналы
LN - результирующая сеть CF для платежей
Идея была предложена в 2017 году разработчиками: Conrad Burchert, Christian Decker и Roger Wattenhofer.
Они опубликовали White Paper (https://tik-old.ee.ethz.ch/file//a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf) "Scalable Funding of Bitcoin Micropayment Channel Networks" - "Масштабируемое финансирование сетевых каналов микроплатежей биткойн", где описали свое детище. Я постараюсь описать короче, лишь для понимания и представления.
Для открытия платежного канала LN юзер сначала финансирует свой канал. Он переводят свои средства на адрес 2-of-2 multisig в блокчейне.
После подтверждения, пользователи выполняют любое количество транзакций в этом канале, не помещая транзакции в блокчейн.
В завершении они могут закрыть канал, записав последнее состояние канала в блокчейн.
LN создавалась для увеличения скорости транзакций и обеспечивает создание двунаправленных каналов, которые имеют некоторые ограничения при настройке:
1) Средства блокируются в канале, до момента закрытия канала.
Блокировка средств в канале неудобна, особенно если нужно сделать ребаланс или заполнить каналы.
2) Открытие/закрытие транзакций внутри цепочки плохо масштабируется из-за ограничений пропускной способности Биткойна.
По мере увеличения числа пользователей LN, количество транзакций в цепочке тоже возрастет. Если 100 юзеров LN откроют по 5 каналов, то создаться 1000 транзакций в цепочке.
CF обеспечивает масштабируемое решение, при котором пользователи создают произвольное количество каналов в составе группы, что значительно снижает стоимость транзакций блокчейна. (Пример на фото)
Такая система позволяет быстро перераспределять средств по каналам, что снижает затраты на открытие новых каналов. Вместо одной блокчейн-транзакции, каждому пользователю требуется только одна транзакция для входа в группу узлов. Внутри группы пользователь может создать произвольное количество каналов. Для группы из 20 пользователей со 100 внутригрупповыми каналами стоимость блокчейн-транзакций снижается на 90% по сравнению со 100 обычными микроплатежными каналами.
Если ввести подписи Шнорра (https://t.me/CryptoBotan/704), этот показатель можно увеличить до 96%. Включение подписей Шнорра в протокол Биткоина совместно с CF обеспечит более компактные транзакции при публикации их в цепочке.
CF, как новый второй слой, состоит из многосторонних каналов для микроплатежей (Channel Factories), которые могут быстро переводить средства как и обычные двунаправленные каналы. Такая сеть обеспечивает уровень, где выполняются регулярные транзакции.
В CF работает "Хук-транзакция", открывающая совместное владение депонированными средствами между сторонами. Компонент, который обеспечивает финансирование нескольких многосторонних каналов, называется "распределением". Блгодаря распределению, одна или несколько последовательных транзакций могут извлекать заблокированные средства из многостороннего канала в качестве входных данных и финансировать несколько каналов с их выходами.
"Хук-транзакция" - это транзакция финансирования многостороннего канала, которая позволяет юзерам выводить средства из канала, если другие стороны становятся некооперативными. Открытие вторичных платежных каналов внутри CF происходит мгновенно.
Пользователи могут открывать и закрывать практически неограниченное количество каналов, что может значительно снизить нагрузку на сеть LN, если она будет масштабироваться до глобальной платежной сети с миллионами пользователей.
https://zen.yandex.ru/media/id/5c30dd7ce5e73b00aad07f3c/channel-factories-novyi-sloi-v-seti-bitcoin-dlia-provedeniia-mikroplatejei-5dfa4b6a5d6c4b00b8bae359
Quote
Протокол Eltoo в сети Lightning Network
⬇️⬇️⬇️
Всякий раз, когда совершается новый платеж, юзер-каналы Lightning обновляются для верного отображения их общих балансов.
Фишка в том, что существует наказание в виде штрафа, если юзер пытается обмануть, распространяя старую версию баланса (например, для экономии средств).
Пользователи, которые пытаются совершить обман, могут потерять свои средства в платежном канале. Это достигается за счет системы L2-penalty.
Но существует нюанс, который состоит в том, что рассылка старых балансов по сети не всегда является попыткой обмана. Иногда юзеры могут случайно распространять старые балансы (из-за ошибки в коде или при неправильном сохранении резервной копии).
Такой нюанс назвали «токсичной информацией».
Соучредитель Lightning Labs Лаолу Осантокун, Кристиан Декер и Расти Расселом из Blockstream, в 2018 году представили (https://blockstream.com/eltoo.pdf) новое решение, в котором предложили «упрощённый» способ осуществления "off-chain" (внесетевых) транзакций.
Eltoo обновляет канал за счет построения цепи транзакций с временным замком, где каждая транзакция тратит средства из предыдущей для отображения актуального баланса.
Решение Eltoo позволяет хранить только свежие данные о транзакциях вне блокчейна, решая проблему «информационной асимметрии».
Проблема «информационной асимметрии» заключается в том, что в случае, если устройство с запущенным приложением Lightning выйдет из строя или будет утеряно, пользователь может потерять доступ ко всей истории данных.
Если подробнее, то eltoo добавляет процедуру, которая делает каждое обновленное состояние заданным. Любое обновление канала, например, когда А совершает транзакцию Б, состоит из двух транзакций, каждая из которых хранит, и впоследствии полностью заменяет, предыдущую транзакцию.
Eltoo также увеличивает масштабируемость LN. У нод пропадает необходимость хранить все промежуточные состояния платежного канала. Вместо этого ноды хранят только самую последнюю версию состояния и некоторую информацию о самой транзакции, такую как соответствующую ей расчетную транзакцию и Hash Time Lock контракты.
https://t.me/CryptoBotan/911⬇️⬇️⬇️
Всякий раз, когда совершается новый платеж, юзер-каналы Lightning обновляются для верного отображения их общих балансов.
Фишка в том, что существует наказание в виде штрафа, если юзер пытается обмануть, распространяя старую версию баланса (например, для экономии средств).
Пользователи, которые пытаются совершить обман, могут потерять свои средства в платежном канале. Это достигается за счет системы L2-penalty.
Но существует нюанс, который состоит в том, что рассылка старых балансов по сети не всегда является попыткой обмана. Иногда юзеры могут случайно распространять старые балансы (из-за ошибки в коде или при неправильном сохранении резервной копии).
Такой нюанс назвали «токсичной информацией».
Соучредитель Lightning Labs Лаолу Осантокун, Кристиан Декер и Расти Расселом из Blockstream, в 2018 году представили (https://blockstream.com/eltoo.pdf) новое решение, в котором предложили «упрощённый» способ осуществления "off-chain" (внесетевых) транзакций.
Eltoo обновляет канал за счет построения цепи транзакций с временным замком, где каждая транзакция тратит средства из предыдущей для отображения актуального баланса.
Решение Eltoo позволяет хранить только свежие данные о транзакциях вне блокчейна, решая проблему «информационной асимметрии».
Проблема «информационной асимметрии» заключается в том, что в случае, если устройство с запущенным приложением Lightning выйдет из строя или будет утеряно, пользователь может потерять доступ ко всей истории данных.
Если подробнее, то eltoo добавляет процедуру, которая делает каждое обновленное состояние заданным. Любое обновление канала, например, когда А совершает транзакцию Б, состоит из двух транзакций, каждая из которых хранит, и впоследствии полностью заменяет, предыдущую транзакцию.
Eltoo также увеличивает масштабируемость LN. У нод пропадает необходимость хранить все промежуточные состояния платежного канала. Вместо этого ноды хранят только самую последнюю версию состояния и некоторую информацию о самой транзакции, такую как соответствующую ей расчетную транзакцию и Hash Time Lock контракты.
Quote
Private messages в сети Lightning Network
⬇️⬇️⬇️
Думали LN предназначен для масштабирования сети Биткоин? Что на счет отправки личных сообщений?
В ноябре 2019 года разработчик Lightning Labs Джуст Джагер представил (https://twitter.com/joostjgr/status/1190714028626251779) собственное решение Whatsat - версию LN для отправки сообщений.
Whatsat - это децентрализованный и устойчивый к цензуре способ отправки сообщений другим пользователям Lightning Network. Протокол является настоящей одноранговой сетью, в которой может участвовать любой желающий.
После недавнего обновления сети LN, появилась возможность добавить дополнительные данные к платежам lightning.
Пока можно отправлять сообщения бесплатно. В сети LN за неудавшийся платеж не взимается комиссия. Платеж доходит до получателя, который извлекает сообщение, но не принимает платеж.
Это две системы в одной: обмен сообщениями и платежи. Вот вам и новый мессенджер - конкурент на рынке😁
https://github.com/joostjager/whatsat
https://t.me/CryptoBotan/912⬇️⬇️⬇️
Думали LN предназначен для масштабирования сети Биткоин? Что на счет отправки личных сообщений?
В ноябре 2019 года разработчик Lightning Labs Джуст Джагер представил (https://twitter.com/joostjgr/status/1190714028626251779) собственное решение Whatsat - версию LN для отправки сообщений.
Whatsat - это децентрализованный и устойчивый к цензуре способ отправки сообщений другим пользователям Lightning Network. Протокол является настоящей одноранговой сетью, в которой может участвовать любой желающий.
После недавнего обновления сети LN, появилась возможность добавить дополнительные данные к платежам lightning.
Пока можно отправлять сообщения бесплатно. В сети LN за неудавшийся платеж не взимается комиссия. Платеж доходит до получателя, который извлекает сообщение, но не принимает платеж.
Это две системы в одной: обмен сообщениями и платежи. Вот вам и новый мессенджер - конкурент на рынке😁
https://github.com/joostjager/whatsat
sr. member
Activity: 938
Merit: 466
~[f#
Наткнулся на интересный канал который публикует разбор инноваций в Биткоине.
Буду копировать текст с телеграмма https://t.me/CryptoBotan
Буду копировать текст с телеграмма https://t.me/CryptoBotan
Quote
Наткнулся вот на такую публикацию. Текущий технологический стек Биткоина. Изображение ниже.
⬇️⬇️⬇️
t.me/tezonaut/380
Сегодня приведу список того, о чем уже писал. Все разбросано и не систематизировано, но исправлю. В дальнейшем постараюсь разобрать остальные компоненты. 😉 Работы много, но думаю она того стоит.
Поехали!
Сегодня приведу список того, о чем уже писал. Все разбросано и не систематизировано, но исправлю. В дальнейшем постараюсь разобрать остальные компоненты. 😉 Работы много, но думаю она того стоит.
Поехали!
1. Sadechains
Хабр статья "Как перевести криптовалюту в другой блокчейн: немного о сайдчейнах"
(https://t.me/CryptoBotan/814)
1.1. Rootstock (https://t.me/CryptoBotan/811)
1.2. Некоторые особенности и нюансы чуть подробнее + Drivechain
(https://t.me/CryptoBotan/813)
1.3. Elements
1.4. Liquid + Issued Assets
2. Layer 2
2.1. Lightning Network (https://t.me/CryptoBotan/600)
1) Все о Lightning Network. От введения до построения платежных каналов
(https://t.me/CryptoBotan/859)2) О типах Lightning Network смарт-контрактов
(https://t.me/CryptoBotan/819)3) Приложения и плагины для Lightning Network
(https://t.me/CryptoBotan/791)
2.1.1. Channel Factories
2.1.2. eltoo
2.1.3. Atomic Swaps
(https://t.me/CryptoBotan/706)
2.1.4. Private Messages
2.2. Omni + Omni DEX
2.3. Identity + Microsoft ION
2.4. Data Anchors + Open Timestamps + VeriBlock
3. Performance & Usabillity
3.1. Schnorr Signatures (https://t.me/CryptoBotan/704) + MuSig + Cross-Input Aggregation
3.2. Neutrino
3.3. Erlay
3.4. BTCPay
3.5. uTreeXo,libMiniSketch, Tx Accumulators
4. Smart Contracts
4.1. Check Template Verify
4.2. tBTC
4.3. MAST (https://t.me/CryptoBotan/719)/Taproot (https://t.me/CryptoBotan/710) + G'root + Tapscript
4.4. Scriptless Scripts
4.5. Simplicity
4.6. Ivy
4.7 Hivemind
5. Privacy
5.1. CoinJoin
(https://t.me/CryptoBotan/584)
5.1.1. ZeroLink + P2EP + SNICKER + Value Shuffle
5.2. Dandelion
5.3. Confidential Transaction + Bulletproofs
(https://t.me/CryptoBotan/881)
5.4, CoinSwap + TumbleBit
6. Mining
6.1. FIBRE
6.2. BetterHash
Stratum V2
6.3. Stratum
6.4. Mining Derivatives
https://t.me/CryptoBotan/888⬇️⬇️⬇️
t.me/tezonaut/380
Сегодня приведу список того, о чем уже писал. Все разбросано и не систематизировано, но исправлю. В дальнейшем постараюсь разобрать остальные компоненты. 😉 Работы много, но думаю она того стоит.
Поехали!
Сегодня приведу список того, о чем уже писал. Все разбросано и не систематизировано, но исправлю. В дальнейшем постараюсь разобрать остальные компоненты. 😉 Работы много, но думаю она того стоит.
Поехали!
1. Sadechains
Хабр статья "Как перевести криптовалюту в другой блокчейн: немного о сайдчейнах"
(https://t.me/CryptoBotan/814)
1.1. Rootstock (https://t.me/CryptoBotan/811)
1.2. Некоторые особенности и нюансы чуть подробнее + Drivechain
(https://t.me/CryptoBotan/813)
1.3. Elements
1.4. Liquid + Issued Assets
2. Layer 2
2.1. Lightning Network (https://t.me/CryptoBotan/600)
1) Все о Lightning Network. От введения до построения платежных каналов
(https://t.me/CryptoBotan/859)2) О типах Lightning Network смарт-контрактов
(https://t.me/CryptoBotan/819)3) Приложения и плагины для Lightning Network
(https://t.me/CryptoBotan/791)
2.1.1. Channel Factories
2.1.2. eltoo
2.1.3. Atomic Swaps
(https://t.me/CryptoBotan/706)
2.1.4. Private Messages
2.2. Omni + Omni DEX
2.3. Identity + Microsoft ION
2.4. Data Anchors + Open Timestamps + VeriBlock
3. Performance & Usabillity
3.1. Schnorr Signatures (https://t.me/CryptoBotan/704) + MuSig + Cross-Input Aggregation
3.2. Neutrino
3.3. Erlay
3.4. BTCPay
3.5. uTreeXo,libMiniSketch, Tx Accumulators
4. Smart Contracts
4.1. Check Template Verify
4.2. tBTC
4.3. MAST (https://t.me/CryptoBotan/719)/Taproot (https://t.me/CryptoBotan/710) + G'root + Tapscript
4.4. Scriptless Scripts
4.5. Simplicity
4.6. Ivy
4.7 Hivemind
5. Privacy
5.1. CoinJoin
(https://t.me/CryptoBotan/584)
5.1.1. ZeroLink + P2EP + SNICKER + Value Shuffle
5.2. Dandelion
5.3. Confidential Transaction + Bulletproofs
(https://t.me/CryptoBotan/881)
5.4, CoinSwap + TumbleBit
6. Mining
6.1. FIBRE
6.2. BetterHash
Stratum V2
6.3. Stratum
6.4. Mining Derivatives
Quote
Sidechain Elements
⬇️⬇️⬇️
Elements - это блокчейн-платформа (https://elementsproject.org/) с открытым исходным кодом, дающая доступ к различному функционалу, разработанная членами криптосообщества. BlockStream, выпустила первый релиз (https://github.com/ElementsProject/elements/tree/alpha) «Альфа-сайдчейн», в 2015 году. Набор функций для блокчейна, которые выходят за пределы цепочки блоков биткоина.
Основной идеей проекта является то, что пользователям предоставляется возможность создавать новые продукты или предоставлять услуги и экспериментировать, не создавая новую криптовалюту.
Elements снижает затраты на разработку и исследования, открывая огромное количество новых вариантов использования. Например, блокчейн на основе Elements может работать как автономный блокчейн или быть привязан к другому и работать как сайдчейн.
Функционируя в качестве боковой цепи, Elements позволяет проверять активы, которые передаются между различными блокчейнами.
Некоторый набор функций:
1) Конфиденциальные транзакции (Confidential Transactions)
Функция Confidential Transactions позволяет скрыть сумму перевода для всех, кроме отправителя, получателя и тех, кому они по своему желанию открывают доступ. Итоговая транзакция становится значительно больше по размеру, включает при этом соответствующее по размеру поле «memo», которое может содержать данные о транзакции или прочие метаданные, но при этом размер все равно будет меньше, чем, например у Zerocoin.
2) Изолированные подтверждения (Segregated Witnesses)
Алгоритм подписи биткоин-транзакции сложнен, что ведет к проблеме «пластичности транзакций» (transaction malleability). Функция Segregated Witnesses убирает эту проблему, улучшая ПО BTC.
3) Отдельные свидетели
Это вид данных, подтверждающих действительность транзакции и которые отделены от спецификации ее результатов.
Биткойн-транзакции содержат как информацию о влиянии транзакции на блокчейн (тратимые UTXO, адреса и суммы), так и данные, подтверждающие, что транзакция действительна (входные подписи). С отделенными свидетелями идентификаторы транзакций переопределяются так, чтобы они зависели только от информации, добавляемой в блокчейн, а подтверждение блоков осуществляется отдельно согласно «показаниям свидетелей».
4) Выпуск базового актива (Basic Asset Issuance).
Эта функция позволяет клиенту сайдчейна выпускать собственные, новые активы, которые, могут защищенно передаваться по цепочке блоков. Это ваучеры, купоны, акции, облигации и т.д.
5) Относительное время блокировки
Подробнее можно ознакомиться здесь
(https://ru.bitcoinwiki.org/wiki/NSequence)В "альфа-сайдчейне" подписанный вход транзакции может оставаться недействительным в течение определенного интервала времени после подтверждения соответствующего выхода. Это необходимо, чтобы можно было заменять транзакции по согласию.
6) Новые опкоды (opcodes).
Каждая биткоин-транзакция – это сценарий, написанный на определенном языке. Новые операционные коды расширяют возможности этого языка, что открывает возможности создания абсолютно новых транзакций (лотереи, платежи произвольно выбранным получателям и тп).
Когда-то Биткойн поддерживал больше опкодов Script, чем доступно сейчас. Многие из них были отключены в 2010 году из соображений безопасности, и чтобы снова включить их, требуется хард-форк. Некоторые из них (но не все) связаны со значительным риском, таким как неограниченное использование памяти. В альфа-сайдчейнах заново задействуются безопасные отключенные опкоды таких команд, как конкатенация строк, выделение подстрок, сдвиг целых чисел и несколько побитовых операций.
https://t.me/CryptoBotan/889⬇️⬇️⬇️
Elements - это блокчейн-платформа (https://elementsproject.org/) с открытым исходным кодом, дающая доступ к различному функционалу, разработанная членами криптосообщества. BlockStream, выпустила первый релиз (https://github.com/ElementsProject/elements/tree/alpha) «Альфа-сайдчейн», в 2015 году. Набор функций для блокчейна, которые выходят за пределы цепочки блоков биткоина.
Основной идеей проекта является то, что пользователям предоставляется возможность создавать новые продукты или предоставлять услуги и экспериментировать, не создавая новую криптовалюту.
Elements снижает затраты на разработку и исследования, открывая огромное количество новых вариантов использования. Например, блокчейн на основе Elements может работать как автономный блокчейн или быть привязан к другому и работать как сайдчейн.
Функционируя в качестве боковой цепи, Elements позволяет проверять активы, которые передаются между различными блокчейнами.
Некоторый набор функций:
1) Конфиденциальные транзакции (Confidential Transactions)
Функция Confidential Transactions позволяет скрыть сумму перевода для всех, кроме отправителя, получателя и тех, кому они по своему желанию открывают доступ. Итоговая транзакция становится значительно больше по размеру, включает при этом соответствующее по размеру поле «memo», которое может содержать данные о транзакции или прочие метаданные, но при этом размер все равно будет меньше, чем, например у Zerocoin.
2) Изолированные подтверждения (Segregated Witnesses)
Алгоритм подписи биткоин-транзакции сложнен, что ведет к проблеме «пластичности транзакций» (transaction malleability). Функция Segregated Witnesses убирает эту проблему, улучшая ПО BTC.
3) Отдельные свидетели
Это вид данных, подтверждающих действительность транзакции и которые отделены от спецификации ее результатов.
Биткойн-транзакции содержат как информацию о влиянии транзакции на блокчейн (тратимые UTXO, адреса и суммы), так и данные, подтверждающие, что транзакция действительна (входные подписи). С отделенными свидетелями идентификаторы транзакций переопределяются так, чтобы они зависели только от информации, добавляемой в блокчейн, а подтверждение блоков осуществляется отдельно согласно «показаниям свидетелей».
4) Выпуск базового актива (Basic Asset Issuance).
Эта функция позволяет клиенту сайдчейна выпускать собственные, новые активы, которые, могут защищенно передаваться по цепочке блоков. Это ваучеры, купоны, акции, облигации и т.д.
5) Относительное время блокировки
Подробнее можно ознакомиться здесь
(https://ru.bitcoinwiki.org/wiki/NSequence)В "альфа-сайдчейне" подписанный вход транзакции может оставаться недействительным в течение определенного интервала времени после подтверждения соответствующего выхода. Это необходимо, чтобы можно было заменять транзакции по согласию.
6) Новые опкоды (opcodes).
Каждая биткоин-транзакция – это сценарий, написанный на определенном языке. Новые операционные коды расширяют возможности этого языка, что открывает возможности создания абсолютно новых транзакций (лотереи, платежи произвольно выбранным получателям и тп).
Когда-то Биткойн поддерживал больше опкодов Script, чем доступно сейчас. Многие из них были отключены в 2010 году из соображений безопасности, и чтобы снова включить их, требуется хард-форк. Некоторые из них (но не все) связаны со значительным риском, таким как неограниченное использование памяти. В альфа-сайдчейнах заново задействуются безопасные отключенные опкоды таких команд, как конкатенация строк, выделение подстрок, сдвиг целых чисел и несколько побитовых операций.
Quote
Продолжаю разбирать решения технологическиго стека Биткоина.
Снова сайдчейен и снова BlockStream
Сайдчейн Liquid
(https://blockstream.com/liquid/)⬇️⬇️⬇️
Liquid - это платежный сайдчейн на основе межбанковской расчетной сети для трейдеров, бирж и процессинговых сервисов, позволяющий выпускать цифровые активы, проводить быстрые и конфиденциальные транзакции больших объемов в сети Биткоин. Liquid - это реализация Elements (https://t.me/CryptoBotan/889).
Оф. релиз состоялся в октябре 2018 года. Решение используют биржи и компании на долю которых приходится более 60% всех биткоин-транзакций. Сюда входят: Bitbank, Bitfinex, Bitmax, BitMEX, OKCoin, Kraken, BTCC, Xapo, Altonomy, L2B, Korbit и еще, еще и еще...
Liquid снижает время, необходимое для перемещения депозитов с 60 минут до двух минут. Компании использующие Liquid проводят операции через сайдчейн, но являются клиентами BlockStream, оплачивая "ежемесячную подписку". BlockStream не контролирует сеть, а является лишь поставщиком решения. Сеть управляется ее участниками.
Функции предоставляющая сеть Liquid:
1) Быстрые расчеты
Перемещение BTC в Liquid называется peg-in. Участник Liquid сети отправляет BTC на сгенерированный Liquid адрес и создает транзакцию peg-in для восстребования эквивалентных L-BTC. Транзакция peg-in требует 102 подтверждения в Bitcoin сети. Это необходимо для защиты средств всех участников в сети
Peg-out - это процесс перемещения средств из Liquid обратно в блокчейн биткоина. Такие транзакции периодически (пакетами) обрабатываются "watchmen -ми" (о них ниже). Каждый раунд обработки занимает порядка 17 минут.
L-BTC создаются как в сети так и другими методами. Например: для обработки быстрого вывода используя Liquid, Bitfinex предоставляет конвертацию BTC в L-BTC 1к1 и соответственно вывод. Подробнее о методах
(https://docs.blockstream.com/liquid/acquire_lbtc.html)2) Конфедициальные транзакции
По умолчанию сумма и тип активов скрыты. Ликвид-транзакции используют конфиденциальные адреса, которые включают открытый blinding ключ и основной адрес. Получатель может использовать приватный blinding ключ совместно с третьей стороной, для проверки суммы и типа актива.
Но есть нюанс, выраженный в ограничении суммы конфиденциальной транзакции. Большая сумма транзакции потребует больше доказательств, что приведет к большему общему объему транзакции и низкой пропускной способности. Предел около 687 BTC. Все что больше необходимо делить на несколько транзакций
3) Токенизация:
Выпуск новых токенов на базе Liquid: фиата, ценных бумаг и цифровых активов
4) Совместимость:
Интегрируясь, поддерживает L-BTC и выпущенные активы. Все токены базируются на одном стандарте, что дает возможность использовать свопы (https://t.me/CryptoBotan/706) и multisig (https://habr.com/ru/company/mixbytes/blog/412675/).
Liquid использует решение на основе консенсуса "Strong Federations". Это устраняет необходимость использовать механизм доказательства работы. Управление сетью осуществляется коллективными действиями взаимно-недоверяющих участников - функционерами (functionaries).
Функционеры (functionaries) выполняют две функции: blocksigners - подписывают блоки;
watchmen - контролируют транзакции в сети.
Генерация блоков происходит каждую минуту.В отличие от сети Bitcoin, где генерация блоков вероятностная, в Liquid генерация последовательная.
Модель Liquid требует, чтобы блоки подписывались 2/3 всех blocksigner. Blocksigner по очереди предлагают новыей блоки каждую минуту в циклическом порядке, а другие функционеры подписывают эти блоки после проверки его содержимого.
В марте 2019 года BlockStream добавил поддержку сайчейна Liquid в свой кошелек GreenAddress или Blockstream Green, где также есть возможность создавать пользовательские активы. А за две недели до этого выпустила еще один кошелек (https://github.com/Blockstream/liquid/releases/tag/liquid.3.14.1.23) для пользователей Liquid. В Liquid также доступны платежи через LN.
В июле 2019 на сайдчейне Liquid был запущен Tether, для быстрых депозитов и выводов на Bitfinex.
Инструмент для создания пользовательских активов в сайдчейне Liquid называется Issued Assets, но о нем уже позже😉
Еще больше информации о Liquid и продуктах BlockStream (https://docs.blockstream.com/liquid/technical_overview.html)
https://t.me/CryptoBotan/890Снова сайдчейен и снова BlockStream
Сайдчейн Liquid
(https://blockstream.com/liquid/)⬇️⬇️⬇️
Liquid - это платежный сайдчейн на основе межбанковской расчетной сети для трейдеров, бирж и процессинговых сервисов, позволяющий выпускать цифровые активы, проводить быстрые и конфиденциальные транзакции больших объемов в сети Биткоин. Liquid - это реализация Elements (https://t.me/CryptoBotan/889).
Оф. релиз состоялся в октябре 2018 года. Решение используют биржи и компании на долю которых приходится более 60% всех биткоин-транзакций. Сюда входят: Bitbank, Bitfinex, Bitmax, BitMEX, OKCoin, Kraken, BTCC, Xapo, Altonomy, L2B, Korbit и еще, еще и еще...
Liquid снижает время, необходимое для перемещения депозитов с 60 минут до двух минут. Компании использующие Liquid проводят операции через сайдчейн, но являются клиентами BlockStream, оплачивая "ежемесячную подписку". BlockStream не контролирует сеть, а является лишь поставщиком решения. Сеть управляется ее участниками.
Функции предоставляющая сеть Liquid:
1) Быстрые расчеты
Перемещение BTC в Liquid называется peg-in. Участник Liquid сети отправляет BTC на сгенерированный Liquid адрес и создает транзакцию peg-in для восстребования эквивалентных L-BTC. Транзакция peg-in требует 102 подтверждения в Bitcoin сети. Это необходимо для защиты средств всех участников в сети
Peg-out - это процесс перемещения средств из Liquid обратно в блокчейн биткоина. Такие транзакции периодически (пакетами) обрабатываются "watchmen -ми" (о них ниже). Каждый раунд обработки занимает порядка 17 минут.
L-BTC создаются как в сети так и другими методами. Например: для обработки быстрого вывода используя Liquid, Bitfinex предоставляет конвертацию BTC в L-BTC 1к1 и соответственно вывод. Подробнее о методах
(https://docs.blockstream.com/liquid/acquire_lbtc.html)2) Конфедициальные транзакции
По умолчанию сумма и тип активов скрыты. Ликвид-транзакции используют конфиденциальные адреса, которые включают открытый blinding ключ и основной адрес. Получатель может использовать приватный blinding ключ совместно с третьей стороной, для проверки суммы и типа актива.
Но есть нюанс, выраженный в ограничении суммы конфиденциальной транзакции. Большая сумма транзакции потребует больше доказательств, что приведет к большему общему объему транзакции и низкой пропускной способности. Предел около 687 BTC. Все что больше необходимо делить на несколько транзакций
3) Токенизация:
Выпуск новых токенов на базе Liquid: фиата, ценных бумаг и цифровых активов
4) Совместимость:
Интегрируясь, поддерживает L-BTC и выпущенные активы. Все токены базируются на одном стандарте, что дает возможность использовать свопы (https://t.me/CryptoBotan/706) и multisig (https://habr.com/ru/company/mixbytes/blog/412675/).
Liquid использует решение на основе консенсуса "Strong Federations". Это устраняет необходимость использовать механизм доказательства работы. Управление сетью осуществляется коллективными действиями взаимно-недоверяющих участников - функционерами (functionaries).
Функционеры (functionaries) выполняют две функции: blocksigners - подписывают блоки;
watchmen - контролируют транзакции в сети.
Генерация блоков происходит каждую минуту.В отличие от сети Bitcoin, где генерация блоков вероятностная, в Liquid генерация последовательная.
Модель Liquid требует, чтобы блоки подписывались 2/3 всех blocksigner. Blocksigner по очереди предлагают новыей блоки каждую минуту в циклическом порядке, а другие функционеры подписывают эти блоки после проверки его содержимого.
В марте 2019 года BlockStream добавил поддержку сайчейна Liquid в свой кошелек GreenAddress или Blockstream Green, где также есть возможность создавать пользовательские активы. А за две недели до этого выпустила еще один кошелек (https://github.com/Blockstream/liquid/releases/tag/liquid.3.14.1.23) для пользователей Liquid. В Liquid также доступны платежи через LN.
В июле 2019 на сайдчейне Liquid был запущен Tether, для быстрых депозитов и выводов на Bitfinex.
Инструмент для создания пользовательских активов в сайдчейне Liquid называется Issued Assets, но о нем уже позже😉
Еще больше информации о Liquid и продуктах BlockStream (https://docs.blockstream.com/liquid/technical_overview.html)
Quote
Итак, я говорил в прошлом посте (https://t.me/CryptoBotan/890), что в сайдчене Liquid на базе Elements (https://t.me/CryptoBotan/889), есть возможность создавать собственные токенизированные активы при помощи инструмента Issued Assets (IA).
О нем сегодня и пойдет речь. Поехалите...
Issued Assets (IA) - выпущенные активы
⬇️⬇️⬇️
Инструмент был представлен на конверенции Consensus 2018. Выпущенными активами могут быть как существующие финансовые инструменты, например, токены, криптоактивы, аттестованные активы (золотые монеты), стэйблкоины, security токены, служебные токены или совершенно новые активы.
Решение было продемонстрированно весьма интересным способом.
Для конференции были созданы 5 отдельных типов IA: подарки в виде наклеек, рубашек и толстовок. Каждый актив был выпущен в количестве, равному количеству подарков. Эти активы были случайным образом отправлены на сотни бумажных кошельков, которые раздали участникам конференции.
Public Key каждого бумажного кошелька содержал как минимум один или несколько разных активов. Пользователи могли использовать свой бумажный кошелек Liquid , чтобы выкупить токены для каждого актива, который содержался в нем. Затем цифровой актив уничтожился, так как его физический эквивалент был выкуплен.
Что хотели продемонстрировать разработчики?
- Можно выпускать активы в любом количестве
- Можно отправлять одну транзакцию с несколькими активами
- Транзакции осуществляются при помощи технологии Confidential Transactions (сумма видна только непосредственным участникам транзакции или назначенной ими третьей стороне)
- Можно уничтожить активы
IA могут также выпускаться с течением времени. Это позволяет создавать оцифрованные коллекционные предметы и бонусные баллы, а также проводить токенсейлы. Вообщем все то, что может быть выпущено на Liquid.
Атомарные свопы (https://t.me/CryptoBotan/706) в сети Liquid позволяют юзерам обменивать активы без необходимости привлечения третей стороны. Так как IA и BTC могут быть как входными так и выходными в Liquid транзакции, обмен может быть выполнен за одну транзакцию.
Так же IA могут быть перенесены на другую платформу или новый блокчейн совместимый с Liquid.
Как я уже упоминал (https://t.me/CryptoBotan/890), Liquid поддерживает транзакции LN с L-BTC, также ведется работа над поддержкой Issued Assets в LN.
Также оставляю ссылочку (https://docs.blockstream.com/liquid/developer-guide/issued-assets.html?highlight=issued%20assets)на FAQ по созданию IA в Liquid. Может пригодиться😉/quote]
https://t.me/CryptoBotan/893
О нем сегодня и пойдет речь. Поехалите...
Issued Assets (IA) - выпущенные активы
⬇️⬇️⬇️
Инструмент был представлен на конверенции Consensus 2018. Выпущенными активами могут быть как существующие финансовые инструменты, например, токены, криптоактивы, аттестованные активы (золотые монеты), стэйблкоины, security токены, служебные токены или совершенно новые активы.
Решение было продемонстрированно весьма интересным способом.
Для конференции были созданы 5 отдельных типов IA: подарки в виде наклеек, рубашек и толстовок. Каждый актив был выпущен в количестве, равному количеству подарков. Эти активы были случайным образом отправлены на сотни бумажных кошельков, которые раздали участникам конференции.
Public Key каждого бумажного кошелька содержал как минимум один или несколько разных активов. Пользователи могли использовать свой бумажный кошелек Liquid , чтобы выкупить токены для каждого актива, который содержался в нем. Затем цифровой актив уничтожился, так как его физический эквивалент был выкуплен.
Что хотели продемонстрировать разработчики?
- Можно выпускать активы в любом количестве
- Можно отправлять одну транзакцию с несколькими активами
- Транзакции осуществляются при помощи технологии Confidential Transactions (сумма видна только непосредственным участникам транзакции или назначенной ими третьей стороне)
- Можно уничтожить активы
IA могут также выпускаться с течением времени. Это позволяет создавать оцифрованные коллекционные предметы и бонусные баллы, а также проводить токенсейлы. Вообщем все то, что может быть выпущено на Liquid.
Атомарные свопы (https://t.me/CryptoBotan/706) в сети Liquid позволяют юзерам обменивать активы без необходимости привлечения третей стороны. Так как IA и BTC могут быть как входными так и выходными в Liquid транзакции, обмен может быть выполнен за одну транзакцию.
Так же IA могут быть перенесены на другую платформу или новый блокчейн совместимый с Liquid.
Как я уже упоминал (https://t.me/CryptoBotan/890), Liquid поддерживает транзакции LN с L-BTC, также ведется работа над поддержкой Issued Assets в LN.
Также оставляю ссылочку (https://docs.blockstream.com/liquid/developer-guide/issued-assets.html?highlight=issued%20assets)на FAQ по созданию IA в Liquid. Может пригодиться😉/quote]
https://t.me/CryptoBotan/893
Quote
Снова стек (https://t.me/CryptoBotan/888), снова Layer 2 и снова Data Anchors (https://t.me/CryptoBotan/917).
OpenTimestamps (OTS)
⬇️⬇️⬇️
OpenTimestamps (ОТС) (https://opentimestamps.org/) - это open source проект, который призван обеспечить стандартный формат для блокчейн- штампов времени.
Повторюсь, что с появлением биткойна, можно создавать и проверять доказательства существования данных (временных меток), не полагаясь на доверенную третью сторону. Это позволяет повысить уровень безопасности, поскольку исключает возможность злоумышленного/неосторожного скомпрометирования временных меток.
Временная метка - это доказательство того, что некоторые данные (Д) существовали до определенного момента времени.
Чтобы создать такое доказательство не обязательно публиковать данные в блокчейне. Достаточно
OpenTimestamps (OTS)
⬇️⬇️⬇️
OpenTimestamps (ОТС) (https://opentimestamps.org/) - это open source проект, который призван обеспечить стандартный формат для блокчейн- штампов времени.
Повторюсь, что с появлением биткойна, можно создавать и проверять доказательства существования данных (временных меток), не полагаясь на доверенную третью сторону. Это позволяет повысить уровень безопасности, поскольку исключает возможность злоумышленного/неосторожного скомпрометирования временных меток.
Временная метка - это доказательство того, что некоторые данные (Д) существовали до определенного момента времени.
Чтобы создать такое доказательство не обязательно публиковать данные в блокчейне. Достаточно
Jump to: