Механика анонимных койнов — часть 1

Это 1-ая из серии статей, задачка которой – отдать наиболее глубочайшее работы приватных протоколов CoinJoin, Monero, Zcash и Mimblewimble. тут мы дадим концептуальное и наиболее детализированные разъяснение того, как валютные переводы, записи о которых хранятся в общественном реестре, могут быть анонимными, но при всем этом поддаваться проверке хоть какой заинтересованной стороной – два, казалось бы, противоречащих друг другу требования. 1-ая статья посвящена CoinJoin — приватному протоколу, использующему лишь обыкновенные, без доп функционала, транзакции Биткойна.

Кратко, если много букв:

  • Биткойн-транзакции передают право на проведение UTXO (Unspent Transaction Output, непотраченный выход транзакции);
  • Деанонимизация нескольких Биткойн-адресов может привести к серьёзной утечке секретных данных, потому что большая часть транзакций может быть отследить;
  • По наименьшей мере 15% блокчейна Биткойна можно деанонимизировать;
  • Биткойн-транзакции могут содержать UTXO, принадлежащие различным адресам;
  • CoinJoin соединяет воединыжды UTXO выхода от различных участников в одну транзакцию, что препятствует идентификации получателей всякого из платежей;
  • Главным недочетом CoinJoin будет то, что он просит роли иной стороны для сотворения микширующей транзакции (хотя отправитель и получатель могут сохранять полную анонимность).

Вспять, к основам: UTXO

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

Заместо того, чтоб вести перечень счетов с остатками на их (как это делается в Ethereum), реестр Биткойна содержит информацию о том, какой адресок обладает каждым UTXO (значит неизрасходованный выход транзакции, т.е. часть входящих средств, которая ещё не была потрачена юзером). Когда Элис посылает Бобу 1 BTC, она создаёт транзакцию с несколькими UTXO, которыми она обладает – скажем, utxo_1, utxo_2 – в качестве входов транзакции и 2-мя новенькими UTXO (utxo_Bob и utxo_Alice) в качестве её выходов.

Когда майнинговый узел получает транзакцию Элис, он делает ординарную проверку того, что:

  • utxo_1 и utxo_2 никогда не врубались в другую транзакцию в качестве входов (т.е. это вправду непотраченные выходы транзакции) и
  • сумма всех входов транзакции равна сумме всех её выходов.
  • Наиболее непростая часть состоит в том, чтоб гарантировать, что лишь Боб имеет Право издержать utxo_Bob в дальнейшем. Эта неувязка решается через внедрение «умного» механизма скриптов разблокировки, включаемых в каждую транзакцию при её разработке. Этот скрипт представляет собой микропрограмму с маленьким количеством инструкций, написанную на не-Тьюринг-полном языке. Для того чтоб включить UTXO в качестве 1-го из входов в новейшую транзакцию, необходимо включить в неё некие данные, чтоб скрипт разблокировки UTXO возвращал ответ True (примечание: это относится к транзакциям Биткойна до SegWit. В современных транзакциях употребляется несколько другая схема. Хотя транзакции старенького типа как и раньше признаются сетью как валидные).

    к примеру, разблокирующий скрипт utxo_Bob (прикреплённый Элис) может смотреться как

    <Открытый ключ Боба> OP_CHECKSIG

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

    return secp256k1.verify(sig, <открытый ключ Боба>, sha256(sha256(tx)))

    оценивается как настоящее (True). Дело в том, что предоставить sig может лишь человек, который понимает скрытый ключ Боба. Это фактически гарантировано, так как нрав, а метод ECDSA довольно неопасен. К примеру, взломщик может попробовать отыскать иной стороны, для Боба это рутинная задачка – генерировать sig при помощи собственного закрытого ключа и хоть какой последовательности байтов, а именно sha256 (sha256 (tx)). Так что без необходимости прямой коммуникации с Элис (и даже не будучи онлайн!) Боб может смело принимать биткойны на собственный на публике объявленный адресок и быть уверенным, что никто, не считая него, не может издержать эти средства.

    Биткойн неопасен, но не анонимен

    Давайте начнём с того, что опишем потенциальные утечки анонимности, которые могут употреблять спецы в области блокчейн-аналитики (в порядке уменьшения степени серьёзности):

  • Сравнение адреса A с настоящим лицом/субъектом, контролирующим скрытый ключ.
  • Фактическое доказательство того, что обладатель А выслал некоторую сумму получателю Б (может быть, даже через несколько промежных транзакций).
  • Фактическое доказательство того, что обладатель адреса А обладает X суммой криптовалюты (может быть, даже лежащей на нескольких счетах).
  • Сатоши Накамото утверждал, что, так как хоть какой человек может анонимно сделать Биткойн-адрес, то фактор 1) не несёт внутри себя серьёзной опасности для конфиденциальности юзеров. Это могло быть правдой в то время, когда юзеры получали свои биткойны основным образом путём майнинга. сейчас, из-за всесущих политик KYC/AML (идентификации клиента и противодействия «отмыванию» средств), навязанных большим криптобиржам, почти все Биткойн-адреса можно связать с настоящими личностями юзеров. Ужаснее того: просто анализируя общедоступные профили в BitcoinTalk и Twitter, используя способы умственного анализа данных, можно получить достаточно много инфы о обладателях Биткойн-адресов. Если же соединять это с фактором 2), то можно отследить умопомрачительно много транзакций. Нехорошие анонсы для тех, кто задумывался, что «даркнет» значит, что правоохранительные органы остаются в незнании относительно личностей контрагентов транзакций (извините, Dread Pirate Roberts). Bitfury говорят, что могут деанонимизировать не наименее 16% всех Биткойн-адресов.

    Обратите внимание, что, если 1), по последней мере, просит парсинга данных, то информация о 2), 3), и 4) совсем открыта (для обыденных Биткойн-транзакций) и свободно доступна (нередко это даже преподносится как «фича» общедоступных распределённых реестров).

    CoinJoin

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

    Мысль, которая позднее легла в базу CoinJoin, была предложена Грегом Максвеллом сначала 2013 года. Есть достаточно много коммерческих решений для увеличения анонимности при использовании Биткойном. тут представлен их всеобъятный и животрепещущий обзор. Большая часть из их в той либо другой форме опираются на идею CoinJoin основным образом поэтому, что она не просит каких-то конфигураций на уровне протокола Биткойна.

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

    [правило 1] все входы удачно разблокированы

    [правило 2] общая сумма входов равна сумме выходов.

    Не то чтоб эти два правила гласили о том, что все входы должны исходить от 1-го адреса, либо о том, что все выходы должны быть каким-то образом соединены. означает, полностью кошерно будет включить в одну транзакцию различные UTXO, исходящие из различных несвязанных меж собой адресов. сейчас представим, что Элис желает выслать 1 BTC Бобу и в то же время Кэрол желает выслать 1 BTC Дейву. И Элис, и Кэрол, не желали бы оставлять излишних следов, потому, заместо того, чтоб выслать отслеживаемые транзакции

    tx1: A->B; tx2: C->D

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

    tx: {
    inputs: [
    {1BTC; <Alice’ Sig>},
    {1BTC; <Carol’s Sig>},
    ],
    outputs: [
    {1BTC; <Bob’s PK>},
    {1BTC; <Dave’s PK>}
    ]
    }

    И в этом случае нереально сказать, посылает ли Элис средства Бобу либо Дейву, и это относится к Кэрол. Иллюстративный псевдокод, приведённый выше, очень далёк от того, чтоб быть реальной Биткойн-транзакцией, но достаточен для того, чтоб передать принцип работы CoinJoin.

    Оригинальное разъяснение Грега Максвелла.
    Недочеты CoinJoin

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

    Дальше. изредка случается так, что Элис необходимо выслать Бобу круглое число биткойнов. Для совершения маленького платежа может потребоваться несколько смешанных транзакций с различными контрагентами, что наращивает общую сложность и уменьшает «анонимное огромное количество» (anonymity set, т.е. набор транзакций, неотличимых от транзакции Элис).

    Оба этих вопросца решаются в Monero, Zcash и Mimblewimble, но весьма различными методами. Оставляя подробности для последующих статей, позволим для себя маленькой тизер:

    • Monero и ZCash (задействуя совсем различные способы) употребляют весьма контринтуитивный факт, заключающийся, грубо говоря, в том, что и [правило 1], и [Правило 2] может быть проверить, не зная ни открытых ключей, ни перечисляемых сумм. Monero – это как CoinJoin на криптографических стероидах (со сокрытыми значениями UTXO и неверными контрагентами). В Zcash употребляются zk-proof, за счёт чего же генерируется большее анонимное огромное количество.
    • MimbleWimble – это совсем иной зверек, хотя его базисные криптографические примитивы похожи на применяемые в Monero. В Mimblewimble совершенно нет скрытых ключей и адресов в обыкновенном смысле. Заместо этого, Право издержать определенный UTXO реализуется сложным, но умопомрачительно действенным (исходя из убеждений хранения и обработки данных) методом.

    Дисклэймер: создатель берёт на себя ответственность за все вероятные некорректности, хотя и старался обойтись без их.

    : EthClassic

     

    Источник

    Добавить комментарий

    Ваш e-mail не будет опубликован. Обязательные поля помечены *