Приватность в сети Lightning
Cover

Приватность в сети Lightning

10 мая 2021 г.

Помимо преимущества практически мгновенных платежей, Lightning также может улучшить приватность финансовых взаимодействий. К сожалению, есть сценарии, в которых Lightning не так хорош для обеспечения приватности, как может показаться на первый взгляд.

Перевод статьи Current State of Lightning Network Privacy подготовлен Тони⚡️. Поддержать проект.

В последнее время сеть Lightning Network растет, сейчас в ней насчитывается около 17,000 активных публичных узлов из общего количества, примерно равного 37,000. Помимо преимущества практически мгновенных платежей, Lightning также может улучшить приватность финансовых взаимодействий. К сожалению, есть сценарии, в которых Lightning не так хорош для обеспечения приватности, как может показаться на первый взгляд.

Я бы хотел раскрыть некоторые проблемные аспекты, связанные с приватностью в сети Lightning. Моей целью не является распространение паники; я хочу, чтобы сообщество было максимально информировано, чтобы каждый мог использовать сеть лайтнинг, сохраняя приватность. Все, что написано в этой статье, является общеизвестным и в той или иной степени осознается в сообществе. Это моя попытка собрать известные факты о приватности в сети Lightning воедино.

Каждый имеет право на финансовую приватность и заслуживает того, чтобы быть осведомленным о способах ее обретения.

Обзор Lightning #

Алиса платит Кэрол по существующему каналу, открытому ею с Бобом.

В двух словах, узел Lightning блокирует выход неизрасходованной биткоин-транзакции (UTXO) в канале с другим узлом. Эти два узла могут мгновенно совершать транзакции друг с другом без трансляции их в блокчейн. Этот подход часто масштабируется так, что вы можете аналогичным образом совершать транзакции с узлами, к которым подключен ваш партнер по каналу, и это может происходить до бесконечности.

В сценарии с несколькими “прыжками” или “хопами” (пересыланиями сатоши от одного партнера по каналу к другому и дальше) конечный получатель обретает часть другого UTXO, не того же самого, который вы, как отправитель изначально ему отправляли. Это можно сравнить с тем, как если бы я дал вам купюру в 10 долларов, чтобы вы передали ее вашему другу, а вы потратили мою купюру на проезд и передали вашему другу другую купюру, полученную вами в абсолютно другом месте. Только в Lightning это происходит посредством криптографии и эта система не вынуждает вас никому доверять.

Улучшенная приватность в сети Lightning #

Каждый пир (участник/узел) в многохоповой транзакции запрашивает оплату у следующего пира в прыжке. Все, что они знают, – это кто попросил их направить платеж и кто является следующим пиром, которому следует передать средства. Из-за свойств луковой маршрутизации платежей маршрутизатор не знает, кто выступает в качестве последующих пиров на пути платежа и кто стоит в этой цепочке перед ними. Это также включает в себя первоначального отправителя или конечного получателя.

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

Получатели не могут похвастаться такой же приватностью. Они должны предоставить определенную информацию отправителю, чтобы тот мог переслать средства. Информация, которую они предоставляют, может быть довольно деликатной.

Краткое содержание #

Я начну с основ приватности узла Lightning, с начальной настройки. Затем поговорю об ончейн-информации, которая раскрывается в каналах Lightning. Далее перейду к приватности отправителей и получателей и информации, раскрываемой по мере продвижения средств в сети Lightning.

Наконец, я расскажу о некоторых будущих функциях и свойствах Lightning, как недавно разработанных, так и готовящихся к запуску.

На протяжении всей статьи я буду рекомендовать решения, которые помогут улучшить вашу приватность. В конце я предложу наилучший и реалистичный сетап, который вы можете применить уже сегодня.

Настройка узла #

IP против Tor #

Один из самых важных шагов, который вы можете сделать в первую очередь, — это настроить ваш узел на работу исключительно через Tor.

Большинство, если не все реализации персональных узлов, такие как Raspiblitz или Umbrel, настроят ваш узел именно так. Это более простой способ настройки, который не требует перенаправления портов, что может показаться сущим адом для большинства новичков.

Хотя можно изменить настройки в будущем, эта информация может быть заархивирована другими участниками. Вы можете перейти на сайт обозревателя 1ml, чтобы самостоятельно увидеть, что подобные изменения сети действительно отслеживаются.

Указав эту информацию на сайте поиска IP-адресов, я вижу, что этот узел использует сервер AWS в Ирландии.

Если вы введете свой IP-адрес в службу поиска, она покажет вашего провайдера и примерное местоположение.

Независимо от того, размещаетесь ли вы на сервере AWS или на домашнем сервере, ваша приватная информация может быть раскрыта по решению суда или через инсайдеров. Если вы настаиваете узел на IP-узле, подумайте о постоянном VPN со статическим IP, чтобы защитить свой домашний/серверный IP.

Недостатком использования исключительно Tor является то, что IP-узлы не могут открыть с вами канал. Однако вы можете присоединиться к ним. По данным 1ml, в настоящее время существует около 12,500 узлов Tor.

Идентификация узла #

Псевдоним #

В настройках своего узла вы можете задать псевдоним, благодаря чему пользователи могут видеть “имена” этих узлов в одноранговом режиме. Если вы запускаете сервис или магазин, привязывая к нему собственный лайтнинг-узел, то, вероятно, вы захотите, чтобы ваш псевдоним соответствовал названию вашего бизнеса и клиентам было проще ассоциировать одно с другим.

Однако если это не так, я бы посоветовал не указывать псевдоним и, тем более, не выбирать что-то, связанное с вашим реальным именем. В любом случае решать вам, но помните, что это все равно что прикрепить собственное имя к вашему биткоин-адресу, а в большинстве случаев этого делать не стоит. Это делает вас мишенью, так как публичная пропускная способность узла, информация о UTXO и многое другое отображается для остальных участников сети.

Приложения #

Псевдоним узла оглашается, когда вы открываете публичный канал, но есть и другие способы, с помощью которых ваш узел может быть связан с вашей личностью.

Приложения-чаты, такие как Sphinx Chat, работают посредством связи между вашим и другими узлами через Lightning Network. Это очень крутая технология, которую я люблю и использую. Тем не менее, она основана на связи вашего узла с Sphinx, и когда люди общаются с вами в чате, они отправляют платежи на ваш узел. Таким образом они могут видеть всю публичную информацию о вашем узле. RaspiBlitz умеет параллельно запускать c-lightning и LND, таким образом вы можете использовать LND для таких приложений как Sphinx и оставить c-lightning для осуществления приватных платежей и маршрутизации. Я бы настоятельно рекомендовал использовать этот подход или, например, запустить отдельный узел Umbrel для тестирования интересных приложений и личного использования. В настоящее время Sphinx позволяет вам использовать один из своих узлов, но имейте в виду, что в таком случае они могут отслеживать и читать каждое сообщение.

Помимо таких приложений, как Sphinx, будьте осторожны с любыми сервисами, которые отправляют вам средства и получают доступ к вашим персональным данным. Если вы не готовы предоставить свой XPUB сервису, не предоставляйте ему и идентификатор своего узла. Подробнее об этом в разделе Приватность получателя.

Одним заметным исключением является LNURL Auth. Несмотря на то, что он основан на Lightning, он не привязывает ссылку к вашему Lightning- узлу. Каждый сайт получает свой идентификатор LNURL, поэтому они не соотносятся друг с другом. Это гораздо лучший и более приватный способ логина, чем использование электронной почты или номера телефона. Сервис LNURL все еще может захотеть отправить средства на ваш узел, но сам по себе он является приватным и некоррелируемым.

UTXO и их использование в Lightning #

Как я уже упоминал, для открытия канала необходимо заблокировать UTXO с другим участником сети. Транзакции в открытом канале выглядят как перевод средств на мультисиг-адрес. Эта транзакция или адрес не раскрывают никакой приватной информации. Однако информация о канале (если он публичный) распространяется по всей сети Lightning. Информация о канале включает в себя индекс транзакции и выход (точка канала).

Приватные каналы не публикуются в сети. Если кто-то из пиров попытается опубликовать такой канал в сети, действие будет отклонено в соответствии с требованиями протокола.

Итак, давайте разберем использование UTXO в сети Lightning.

UTXO, используемые для открытия публичных каналов #

Многие биткоинеры, заботящиеся о приватности, знают, что генерировать новый биткоин-адрес для каждой транзакции – это здоровая практика. Узлы Lightning используют ту же практику при создании нового адреса для обычных транзакций и новых каналов. Учитывая, что вы не можете отличить транзакцию, открывающую канал от, например, мультисиг-транзакции, вы не можете обычно связать один UTXO с другими. Однако информация, передаваемая по сети Lightning, и есть та самая связь.

Когда вы открываете канал, транзакционные выходы “превращаются” во входы, и таким образом блокируется новый UTXO. Затем, с помощью ончейн-анализа, можно определить источник средств, использованных для открытия канала. Рассматривая только информацию о канале, невозможно определить, какой именно узел заблокировал средства. Мы только знаем, что это был один из двух участников (хотя ваш контрагент знает, что это был не он, и может поделиться этой информацией с внешним миром). Тем не менее, можно определить, какой узел заблокировал UTXO.

Примечание: При наличии каналов с двойным финансированием это могли быть оба узла. Однако можно спровоцировать узел на раскрытие своих UTXO, инициировав запрос на открытие канала с двойным финансированием и прервав его в процессе. Если бы этот UTXO был использован в канале с двойным финансированием позже, мы бы знали, какому узлу он принадлежал.

Итак, мы выяснили, что в настоящее время один или другой узел в канале владеет используемыми UTXO. Вероятность 50/50. Но представьте ситуацию, когда Алиса получила UTXO от Coinbase и использует его для открытия канала. Coinbase будет знать, что инициатором была Алиса, поскольку они отслеживают, что делают их пользователи после вывода средств. Это либо Алиса, либо человек, которому Coinbase отправила средства от имени Алисы. Если бы Coinbase решили докопаться до истины, они могли бы спросить Алису и заблокировать ее счет (средства, принадлежащие Алисе, но хранящиеся на подконтрольном Coinbase кошельке), если бы им что-то не понравилось.

В другом случае, если у Алисы был 1 UTXO и она открыла канал на неполную сумму, а затем использовала сдачу для открытия другого канала, можно предположить, что оба канала были инициированы Алисой. Алиса использовала свою сдачу с одного канала для открытия другого, поэтому мы знаем, что эти UTXO принадлежат ей. Узел, открывающий канал на неполную сумму, устанавливает собственный адрес для получения сдачи.

Алиса, использующая TX 1 для открытия двух последовательных каналов, выдает себя как открывающую оба канала.

Когда речь идет о публичных каналах, в лучшем случае у вас есть 50% шанс, что UTXO принадлежит вашему узлу. В худшем – 100% вероятность того, что некоторые или все UTXO вашего канала принадлежат вам.

Поскольку вся сеть Lightning может видеть эту информацию, считайте, что она публичная. Есть вероятность, что аналитические фирмы и регуляторы воспользуются этим.

Решение: открывая публичные каналы, используйте весь UTXO (без сдачи), не привязанный к вашей личности.

Приватные каналы не приватны #

Приватные каналы (private channels) – это термин, используемый для описания канала, который публично не объявляется в Lightning Network. Общественность не может знать о существовании канала между двумя узлами или UTXO, стоящими за ними, не приложив никаких усилий. По умолчанию эту информацию знает только ваш контрагент по каналу. Однако давайте разберемся, почему “приватные каналы на самом деле не являются приватными”.

Начнем с того, что есть несколько причин для открытия приватного канала. Возможно, вы не хотите, чтобы другие узлы направляли по нему платежи, поскольку вы запустили узел на смартфоне и не всегда находитесь онлайн. Вы также можете захотеть скрыть истинную сумму, заблокированную в каналах между вами и другим узлом. Для этого можно открыть публичный канал с узлом и при этом иметь гораздо более крупные приватные каналы с тем же узлом. Вы можете лично прокладывать маршруты через свои приватные каналы без ведома общественности. Использование такой теневой маршрутизации можно обнаружить с помощью методов зондирования баланса, несмотря на то, что информация о канале скрыта.

Еще одна причина, по которой люди решают открыть приватный канал, – это сокрытие UTXO. В конце концов, это стандартная гигиена приватности – не связывать ваши UTXO между собой. Это предположение ошибочно по нескольким причинам.

Инвойс с инструкциями приватной маршрутизации включает идентификатор канала, который, в свою очередь, содержит информацию о UTXO.

Чтобы получать средства по приватным каналам, вы должны закодировать информацию о канале в инвойсе, который вы предоставляете отправителю. К сожалению, идентификаторы каналов основываются на информации о UTXO. Отправители могут определить, какие UTXO лежат в основе ваших приватных каналов. Помните о 50% в лучшем случае, 100% в худшем, о которых мы говорили выше? То же самое применимо и здесь. Если вы не отправили инвойс по защищенному каналу связи, считайте, что это публичная информация. Также учитывайте, что отправитель может использовать эту информацию против вас — он может продать или обнародовать ее.

Но и это не самое страшное. Вы не только раскрываете эту информацию каждому отправителю, у которого запрашиваете средства, но и можете быть атакованы злоумышленниками. Можно спамить платежами через узел в попытке попасть в реальный приватный канал, угадав UTXO. Злоумышленник начинает с анализа всех транзакций в сети Биткоин и создания набора UTXO, которые отправляются на адрес, похожий на мультисиг. Обнаружив, что UTXO используется в приватном канале жертвы, злоумышленник может попытаться узнать, кто является обладателем второго узла. Это делается путем замены pubkey узла на один из 37,000 узлов, известных сети Lightning. Угадать другой узел невозможно только в том случае, если он никогда не открывал публичный канал и никогда не запускал приватный.

Если вы открыли приватный канал и никогда не создавали инвойс, все равно возможно, что ваш партнер по каналу разгласил канал и публичный ключ. Он мог включить данные в один из своих инвойсов. Для этого ему не нужно ваше согласие.

Таким образом, даже если ваш узел “полностью приватный”, вы никогда не открывали публичный канал и не делились ни с кем инвойсами, достаточно, чтобы один из ваших партнеров по каналу раскрыл ваш приватный канал и публичный ключ через инвойс. После этого злоумышленник может прощупать ваши приватные каналы, UTXO, балансы и даже контрагентов по каналам. Поэтому можно предположить, что любой из ваших приватных каналов и поддерживающих их UTXO открыты для всего мира. Для определения стоимости и времени выполнения этой атаки на зондирование частных каналов потребуются дополнительные исследования.

Решение: чтобы скрыть один из ваших UTXO, откройте приватный канал за одним из ваших публичных каналов. Альтернативный вариант – заставить другой узел открыть канал к вам, раскрывая только его UTXO.

Закрытие канала #

Помимо того, что можно найти активные приватные каналы, можно также обнаружить уже закрытые приватные каналы. Ончейн-аналитика может быть применена к транзакциям, закрывающим канал, чтобы выявить обоих участников канала.

Можно определить приватный канал Алисы и Боба на основе действий со сдачей, выполненных после его закрытия.

Сдача из приватного канала может быть использована в новом публичном канале или оказаться слитой в приватном. Если оба узла использовали сдачу из приватного канала для создания нового, то между ними существует вероятная связь. Вы сможете просмотреть исходный выход транзакции и определить, что он был использован для приватного канала между узлами.

Также можно обнаружить, что выход транзакции был частью приватного канала, если этот приватный канал будет вынужденно (принудительно) закрыт. Принудительно закрытые каналы выявляют неразрешенные выходы ончейн, характерные для Lightning. После этого можно проанализировать выходы сдачи таким же образом, чтобы обнаружить аналогичные каналы.

Решение: после закрытия канала смешайте выходы сдачи.

Смешанные UTXO #

Управление смешанными UTXO – тема, которая горячо обсуждается биткоинерами, использующими CoinJoin. Смешивать UTXO, а затем снова объединять их без острой необходимости, как правило, является плохой идеей. Если вы владеете несколькими UTXO из одного источника, смешиваете их, а затем отправляете их на один и тот же адрес, вы снижаете анонимность этих монет. Ситуация ухудшается по мере того, как вы объединяете все больше UTXO.

Существует множество нюансов и сложностей ончейн-аналитики в контексте деанонимизации смешанных UTXO. Мой совет – не объединять их, но здесь присутствует немало переменных.

Исходя из вышесказанного, я считаю, что отправлять более одного смешанного UTXO на узел Lightning – плохая идея. По всем причинам, описанным выше, все ваши смешанные UTXO на узле Lightning потенциально могут быть связаны. Неважно, предназначены ли они для публичных или приватных каналов. Если вы не уверены в своих действиях со своими смешанными UTXO, я бы по возможности избегал их консолидации на узле.

Решение: Не используйте более одного смешанного UTXO на узел.

Приватность получателя #

На данном этапе я рассказал о UTXO и каналах, лежащих в основе вашего узла. Теперь давайте разберемся, какая информация раскрывается при получении платежей.

Инвойсы #

Обычно, когда вы хотите получить платеж, вы создаете инвойс и передаете его отправителю. Счет будет состоять из публичного ключа вашего узла, суммы, описания, подсказок по приватной маршрутизации; он будет подписан приватным ключом вашего узла. С помощью вашего публичного ключа отправитель может найти ваш узел и выяснить каналы, UTXO, информацию о TOR/IP-адресе и многое другое. Подсказки по приватной маршрутизации также раскрывают информацию о UTXO вашего приватного канала.

Пример Lightning-инвойса

И вся эта информация доступна из простого инвойса. Вот где можно допустить ошибку в плане приватности. Во-первых, будьте осторожны с тем, где вы размещаете инвойс. Если вы пытаетесь сохранить приватность/анонимность узла, не делитесь инвойсами на публичных форумах. Или даже в незашифрованных сообщениях или с людьми, которым вы не доверяете информацию о своем узле. Если вы это сделаете, считайте, что эта информация доступна всему миру и каждый может связать ее с вами. Если вы коммерсант, этого невозможно избежать. Стоит иметь в виду, что любой может сгенерировать инвойс от вашего узла под видом попытки осуществления покупки в вашем магазине.

Инвойсы могут раскрыть еще больше информации о вас или о конкретной сделке. Вы же не скажете в описании платежа на PayPal “На приобретение кокаина”, то же самое верно и здесь. Каждый инвойс подписывается, поэтому любое сообщение, которое вы в него помещаете, по сути, является заявлением, подписанным вашим узлом. Классический пример – инвойс Мэтта Оделла, в примечании которого упоминается покер. Он передал этот инвойс своему другу, который оплатил его через KYC-биржу. Теперь эта биржа знает больше, чем, вероятно, хотелось бы Мэтту. Это даже ставит его друга в опасное положение. Если биржа захочет, она может цензурировать платежи на узел Мэтта, пояснив свое решение увлечением пользователя азартными играми.

Учитывая, что каждый инвойс, который вы выставляете, раскрывает информацию о публичном ключе вашего узла, эти данные также сопоставимы. В идеальном мире инвойсы, которые вы выставляете, не раскрывают информацию о вашем узле и не связаны между собой. Каждый новый инвойс будет показывать новую информацию о публичном ключе. Это технически возможно уже сегодня, и, более того, мобильный кошелек Muun поступает именно таким образом!

Muun использует “поддельные” приватные каналы с прикрепленными к ним динамично меняющимися парами ключей. Они создают инвойсы, которые выглядят так, будто они проходят через ваш узел и каждый раз направляются в другой пункт назначения, что предоставляет вам возможность правдоподобного отрицания. Хотя это не идеальный сценарий, он намного лучше невозможности отрицания.

В конце концов, можно предположить, что ваш узел, маршрутизирующий платежи на эти виртуальные приватные узлы, на самом деле является конечным пунктом назначения. Но это предположение не всегда будет верным. Оно может включать независимые узлы, которые могут иметь единственный приватный канал к вашему узлу.

Решение: Создавать новый публичный ключ узла для каждого инвойса (в реальности это легко сделать только с Muun, поскольку здесь этот подход используется по умолчанию). Я слышал, что другие проекты также работают над внедрением такого подхода.

Приватность отправителя #

Приватность отправителей в Lightning Network обычно очень высока. Отправители создают зашифрованный луковый путь, чтобы ни один узел не мог определить, кто стоит на маршруте средств, помимо его непосредственных “соседей по хопу”. По мере прохождения средств по сети слои разворачиваются, поэтому предыдущие узлы также неизвестны. Известен только непосредственный предыдущий узел, что защищает и оригинального отправителя. Хотя в некоторых случаях первоначального отправителя можно предположить.

Почему важно обеспечить приватность отправителя? Если Алиса покупает что-то у Боба, и Боб знает Алису, почему важно сохранить приватность ее узла?

Этот вопрос подводит нас к значимости ончейн-приватности и причинам ротации биткоин-адресов после каждого их использования. Бобу не нужно знать всю описанную в этой статье информацию об узле. IP-адрес узла, информация о каналах и UTXO, балансы и многое другое – все это не является необходимым для получения средств. Все, что нужно знать Бобу — это минимальное количество информации для выполнения заказа Алисы и тот факт, что Боб получил средства в соответствии с полученным заказом.

Итак, давайте рассмотрим некоторые случаи, позволяющие деанонимизировать отправителя.

1 хоп #

Пример с ограниченным количеством соединений между пирами в сети Lightning, где Алиса платит Бобу. Кто еще мог заплатить Бобу, кроме Алисы? Боб знает, что никто.

Представьте, что у Алисы есть узел с единственным каналом связи с Бобом. Она посылает платеж Бобу напрямую через их канал. Боб сможет предположить, что узел Алисы был первоначальным отправителем. Какой другой узел мог отправить эти средства через Алису? У Алисы может быть открыт приватный канал с другим узлом, но, как мы уже выяснили, существование приватных каналов может быть раскрыто.

То же самое может произойти, если Боб определит, что Алиса не является узлом маршрутизации. Некоторые узлы могут отклонять запросы на маршрутизацию. Если Боб попытается провести платеж через узел Алисы и платеж будет отклонен по этой причине, то у Боба есть возможность обоснованно предположить, что Алиса не маршрутизирует платежи. Соответственно, другой узел не мог бы маршрутизировать платеж через Алису к Бобу. Возможно, Алиса отклоняет запросы на маршрутизацию только в одну сторону, но это было бы очень нестандартно, если вообще возможно.

Решение: Если у вас только 1 канал, не отправляйте средства напрямую партнеру по каналу как адресату.

2 хопа #

Пример с ограниченным количеством соединений между пирами в сети Lightning, где Боб выступает в роли провайдера лайтнинг-сервисов (LSP). Боб может знать, что платежи идут от одного пользователя к другому в том случае, когда у них нет других соединений.

Представьте себе сценарий, в котором Алиса подключена к Бобу, а Боб подключен к Кэрол. Боб знает, что Алиса не подключена к другим пирам, и то же самое касается Кэрол.

Алиса отправляет платеж Кэрол через Боба. Боб знает, что Алиса отправила платеж Кэрол и на какую сумму.

Это обычная схема работы лайтнинг-провайдеров в лице операторов мобильных кошельков. Обычно мобильные пользователи не подключаются ни к какому другому каналу, кроме как к самому LSP. Если мобильный пользователь посылает другому пользователю мобильного кошелька, использующему тот же LSP, это означает, что LSP знает, когда их пользователи платят друг другу.

Решение: Если вы используете мобильный LSP, откройте и другие публичные каналы, или не пытайтесь платить другим пользователям, использующим тот же LSP.

Отправка средств через сеть #

Я описал сценарий с 1 и 2 хопами, когда маршрутизатор или получатель могут определить отправителя. Есть более активные способы попытаться выяснить эту информацию на более длинных путях передачи средств.

Зондирование балансов #

Зондирование балансов (Balance probing) – это практика, при которой злоумышленник пытается провести множество фальшивых платежей через узлы в попытке выяснить, сколько средств находится на той или иной стороне. В сети Lightning известна только общая сумма публичного канала. При канале в 1 биткоин между Алисой и Бобом в любой момент времени на стороне Алисы может быть 0.7 BTC, а на стороне Боба – 0.3 BTC. Это может меняться по мере прохождения платежей через их канал.

Кэрол атакует канал между Алисой и Бобом, чтобы выяснить баланс в канале Алисы и Боба.

Злоумышленник может узнать баланс, пытаясь направить платежи с разными суммами через канал между Алисой и Бобом. Если платеж в 1 BTC не проходит к Алисе, злоумышленник уменьшает сумму до тех пор, пока он не пройдет. Злоумышленник использует поддельный хэш платежа, который никогда не будет исполнен. Как только Алиса отвечает ошибкой хэша платежа, злоумышленник понимает, что зондирование прошло успешно. Баланс на стороне канала Боба приблизительно равен сумме на самом высоком успешном зондировании.

Если баланс канала Алисы с Бобом изменился и составляет 0.1 на ее стороне и 0.9 на его стороне, в то время как ни один из других балансов канала Боба не изменился, мы знаем, что Алиса заплатила Бобу 0.6 BTC. Либо одним платежом, либо несколькими.

Можно также расширить зондирование баланса на всю сеть. Если крупный платеж проходит через более двух узлов, злоумышленник может проследить за движением средств, сделав снимки балансов до и после платежа.

Хотя это возможно, на практике потребуется много ресурсов, чтобы сделать это оперативно, особенно по мере масштабирования сети. Снимки всей сети занимают много времени. По мере увеличения количества платежей, проходящих через сеть, становится нецелесообразным делать это достаточно быстро, чтобы точно определить отдельных отправителей и их адресатов. Проведены исследования и выпущены документы о стоимости и времени, необходимых для таких атак. Делать это в больших масштабах нецелесообразно. Однако многомиллиардные аналитические фирмы или силовые структуры определенно на это способны.

Атакующему будет более разумно нацелиться на конкретные направления. Это позволило бы оценить их общую экономическую активность.

Злоумышленник может нацелиться на узел магазина конкурента и сделать снимок всех его каналов. Они могли бы следить за тем, как уменьшается входящая ликвидность узла конкурентов. Атакующий может проверить цены на товары магазина и сделать некоторые предположения о продажах конкурента. Возможное решение для борьбы с этой проблемой заключается в том, чтобы узел мерчанта регулярно выталкивал средства на противоположные стороны своих каналов пропорционально получаемым оплатам. В идеале – сразу после получения платежей. Таким образом злоумышленники не успевали бы зафиксировать отдельные покупки. Они могут направлять средства на другой подконтрольный им узел, не связанный с их магазином.

Есть способы определить, зондируются ли ваш балансы, и вы можете попытаться отсечь такую активность. С другой стороны зондирование может быть неотличимо от того, что узлы испытывают трудности с проведением платежа и пробуют разные пути. Я считаю, что для защиты приватности можно отказаться от получения после пары попыток. Случайный отказ от маршрутизации фактического платежа может привести к упущенному доходу от маршрутизации. Кроме того, меньшее количество платежей будет направлено в вашу сторону из-за репутационной природы алгоритмов маршрутизации платежей. Я не знаю программного обеспечения для борьбы с зондированием балансов, поэтому необходимо написать что-то собственное.

Решение: Пока не будет разработан лучший метод борьбы с зондированием, периодически восстанавливайте баланс и ребалансируйте каналы. Это не самое лучшее решение, но эта проблема не проста.

Временные атаки #

Временные атаки делают обоснованные предположения на основе того, как быстро что-то произошло. В случае с Lightning Network маршрутизатор может определить, кто является получателем платежа. Они делают это на основе того, как быстро прошла успешная транзакция. Существуют базовые ограничения на задержку в сети, когда мы переходим от прыжка к прыжку по сети. Например, представьте, что средняя сетевая задержка составляет 100 мс на один хоп. Если платеж прошел успешно за 500 мс, можно предположить, что получатель платежа находится на расстоянии 5 хопов. Если атакующий просканирует время между каждым узлом, он сможет сделать еще более точное предположение.

По мере роста сети и увеличения количества пунктов назначения и задержек, я полагаю, это будет сложнее.

_Решение: Как узел, вы можете добавить случайное количество времени для пересылки или приема платежей. Однако это может ухудшить пользовательский опыт взаимодействия с мгновенными платежами, задерживая некоторые транзакции на несколько секунд. Пользователь reddit поделился своим плагином c-lightning для достижения этой цели).

Дополнительные технологии лайтнинг-протокола #

На сегодняшний день есть несколько дополнительных технологий протокола Lightning, о которых стоит упомянуть.

Многопутевые платежи (MPP) #

Небольшая часть сети Lightning, где Алиса оплачивает счет по нескольким путям. Боб и Кэрол не видят общую сумму платежа.

(Базовые) Многопутевые платежи (MPP) – это существующее сегодня, но, возможно, не так часто используемое решение. Вместо того чтобы один платеж проходил по одному маршруту, это решение позволяет разбить один платеж на меньшие суммы и пройти по нескольким маршрутам. Это повышает вероятность того, что более крупный платеж пройдет по сети. Это также в определенной степени повышает приватность.

В соответствии с разделом Зондирование баланса, вместо крупного платежа, проходящего через сеть, осуществляются более мелкие платежи. Это позволяет лучше скрыть платеж и точную общую сумму. Одна из проблем заключается в том, что каждый MPP использует один и тот же хэш платежа, поэтому маршрутизатор (или сговорившиеся маршрутизаторы) может сопоставить их.

Атомарные многопутевые платежи (AMP) #

Атомарные многопутевые платежи – это усовершенствование базовых MPP, в котором каждый разделенный платеж получает свой хэш платежа. Таким образом они не так коррелируют в сети, как MPP.

Rendezvous #

Маршрутизация Rendezvous – это значительное улучшение приватности получателей. Получатели скрывают свой публичный ключ и приватные каналы, создавая инвойс с уже заполненной зашифрованной луковым методом информацией. Они указывают случайный узел, к которому отправитель должен создать путь, и оттуда направляется остальная часть платежа. Отправитель никогда не знает конечного получателя платежа, как и любой узел на маршруте.

Ослепление маршрута (Route Blinding) #

Ослепление маршрута – это альтернатива Rendezvous. Оно аналогично, но помогает предотвратить раскрытие приватных каналов злоумышленникам. Ослепление маршрута позволяет обеспечить конфиденциальность получателя и повторение маршрутов с различными суммами. Однако в целом это решение может быть менее приватным, и все еще может оставить некоторые возможности зондирования.

Rendezvous и Route Blinding все еще могут быть подвержены атакам через снэпшоты балансов как способу раскрытия отправителя и получателя. Для этого достаточно сделать снимок до совершения платежа и после. В случае с ослеплением маршрута можно добиться того, чтобы приватные каналы были недоступны до тех пор, пока узел не выдал инвойс ослепленного маршрута.

Маршрутизация Trampoline (Trampoline routing) #

Маршрутизация Trampoline – это метод, при котором узел хочет отправить средства в определенный пункт назначения, но не обладает достаточной информацией, чтобы это осуществить. Вместо этого отправитель передает платеж известному Trampoline маршрутизатору. Этот маршрутизатор далее создает путь, чтобы доставить платеж в пункт назначения.

Даже если получатель также поддерживает (или хотя бы понимает) протокол Trampoline, то другие маршрутизаторы продолжают не знать, является ли следующий Trampoline конечным пунктом назначения. Примерно так же, как это происходит сегодня, когда обычные маршрутизаторы не знают, является ли их следующий хоп последним. Получатели могут даже реализовать Rendezvous поверх этого решения.

Маршрутизация с публичным ключом (Public Key Routing) #

Простой альтернативой сокрытию UTXO в основе канала является реализация маршрутизации с публичным ключом. Хотя по-прежнему можно обнаружить приватный канал между двумя пирами, которые не имеют открытого канала между собой, это исключает возможность узнать UTXO, стоящий за ним.

Immortan #

Immortan – это “минимальная, ориентированная на приватность реализация протокола LN, предназначенная как основа для легких узлов LN”. Эта реализация решает такие задачи, как ротация публичных ключей/инвойсов и поддельные идентификаторы каналов. В настоящее время она находится в разработке.

zkChannels #

zkChannels предлагает надежную анонимность и невозможность связывания оффчейн-транзакций, минимизируя объем информации, которую получатель имеет об отправителе, (кроме суммы платежа). Это предложенный уровень обновления, который характеризуется асимметричным потоком информации для сохранения приватности через искаженные схемы.

Он в первую очередь улучшает приватность отправителя. Однако он поддерживает только отношения типа “продавец-клиент”, когда клиент раскрывает продавцу только сумму платежа. zkChannels не поддерживает пересылку платежей.

Taproot #

Taproot привнес множество улучшений, но с точки зрения Lightning одним из преимуществ является сокрытие мультисиг-транзакций. Каждое совместное закрытие без неразрешенных (проблемных/спорных) платежей будет выглядеть как обычная Taproot-трата с одной подписью. Таким образом, будет сложнее угадать, какая из транзакций может являться закрытием приватного канала.

Фабрики каналов (Channel factories) #

Фабрики каналов – это место, где множество пиров могут объединить свои средства для совместного создания подсети каналов. В этом есть преимущества масштабируемости, но еще один потенциальный результат заключается в том, что со стороны они могут выглядеть как канал CoinJoin. Для создания фабрик каналов потребуется несколько усовершенствований протокола базового уровня и уровня Lightning. В качестве альтернативы аналогичного результата можно добиться с помощью многостороннего приложения для пакетного создания каналов.

Другие решения #

Существует множество возможных улучшений или предложений для Lightning, которые могли бы улучшить приватность пользователей. Реализация некоторых из них, включая упомянутые здесь, может занять годы. Я пока не рассматриваю их слишком глубоко, поскольку эта статья посвящена возможностям, доступным уже сегодя.

Итоговые советы по приватности #

Итак, мы определили несколько моментов, касающихся приватности в сети Lightning:

  1. Любой может увидеть информацию о публичном узле любого участника, если он когда-либо открывал публичный канал.
  2. Любой может увидеть UTXO, лежащие в основе канала, приватные каналы также могут подвергнуться раскрытию.
  3. Ончейн-аналитики могут нацелиться на узлы, их активные и уже закрытые каналы, UTXO и т.д.
  4. Размещение более одного смешанного (CoinJoin) UTXO на вашем узле может нивелировать смешивание и раскрыть вашу истинную личность.
  5. Уровень приватности получателей очень низок; это не изменится до тех пор, пока не будет реализовано что-то вроде Rendezvous.
  6. Отдельные платежи, проходящие через сеть, можно засечь. Хотя маловероятно получить какие-либо гарантии, если только речь не идет о злоумышленнике, обладающем огромными ресурсами. Более реалистична атака, нацеленная на конкретные узлы для оценки их экономической активности.

Учитывая вышесказанное, поделюсь своими предложениями по улучшению собственной приватности в сети Lightning.

Отправителям #

  1. 1 UTXO на узел на приватном канале. В идеале смешанный и использующий полный баланс UTXO (без сдачи).
  2. Не отправляйте напрямую своему партнеру по каналу (это следует делать обходными путями через других пиров).
  3. Когда закончили, полностью исчерпайте свой канал и закройте его.
  4. Не получайте, не создавайте инвойсы и т.д., которые раскрывают информацию о канале/UTXO.
  5. Если пройдет достаточно времени, этот канал станет известен сети и его можно будет прозондировать, поэтому не держите эти одноразовые узлы в течение длительного периода времени.
  6. Отправляйте платежи небольшими частями и по более длинным путям, чтобы скрыть их от перехвата.

Получателям #

  1. Никогда не открывайте канал на основе принадлежащего вам UTXO. Попросите вторую сторону открыть канал с их UTXO или найдите источник UTXO для открытия канала. Источниками могут послужить Bitrefill Thor, Lightning Lab’s Loop Out, LNBig, Yalls и т.д.
  2. Если вы хотите отправить некоторые средства ончейн, либо воспользуйтесь сервисом вроде Loop Out, либо закройте канал и смешайте средства перед открытием нового.
  3. Используйте только Tor и не используйте псевдонимов для вашей ноды.
  4. Не делитесь инвойсами публично и не получайте их от сервисов, на которых вы прошли проверку KYC, разве что вы используете систему одноразовых инвойсов.
  5. Не сообщайте окружающим, каким именно узлом вы оперируете.
  6. Не создавайте инвойсы с заметками, содержащими раскрывающую информацию.

Смешивание в LN #

Если вам интересно смешивании в сети, вы можете заплатить за услугу, например, Bitrefill Thor, чтобы открыть канал с совершенно новым узлом. Затем вы можете отправить средства с вашего одноразового узла на ваш арендованный узел канала. Таким образом, после закрытия каналов вы больше не владеете UTXO, с которым открывали первый канал. Теперь вы владеете новым UTXO с другого узла. Оплата арендованного канала или UTXO через Lightning также позволит скрыть вас как отправителя, если следовать лучшим практикам.

Заключение #

Цель сети Lightning Network – молниеносные платежи. Базовый уровень Биткоина не предоставляет никаких гарантий приватности, точно так же как и Lightning. Существуют способы попытаться скрыться среди активности сети, но это не гарантия. Крупные игроки могут атаковать и попытаться раскрыть приватные каналы, которые, по сути, являются лишь продолжением основного графа. Отсюда следует, что движение средств по сети должно считаться достоянием общественности.

Подпольные сети Lightning, состоящие из полностью приватных узлов, которые доверяют друг другу свою приватность, вполне могут существовать сейчас или в будущем. Но маршрутизация платежей по основному публичному графу сопряжена с определенными рисками в плане приватности. Учитывайте ту модель угроз, которую считаете уместной в своей ситуации и используйте представленную выше информацию соответствующим образом.

Возможно, в будущем появятся решения, которые смогут улучшить ситуацию, но на сегодняшний день мы находимся именно на этом этапе общего использования сети Lightning Network.

Благодарности #

Огромное спасибо всем, кто нашел время, чтобы просмотреть и дать ценные предложения по нескольким черновикам этой статьи! Это openoms, Abubakar, Evan, Andrew и другие.

Исследователи и разработчики Lightning Network также заслуживают отдельной благодарности, поскольку большая часть информации в этой статье получена в результате их многолетней работы. Я привел множество их ссылок, но в этой статье особо выделяются Rusty, Sergei, Bastien и Joost!

Не стесняйтесь поддержать биткоин-разработчиков в Bitcoin Dev List!

Поддержать проект 21 идея, подготовивший перевод этой статьи можно, перейдя по ссылке.


Connect to our relay to leave a comment. Details.
Подключитесь к нашему релею, чтобы оставить комментарий. Подробнее.