Слепой маршрут

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

Как это работает

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

Получатель начинает с реального маршрута к самому себе и случайного эфемерного ключа, из которого выводит цепочку ключей маршрута, устроенную так, что каждый переход может вычислить следующий, не получая его извне. Каждый переход в итоге разделяет с получателем секрет ECDH, и из этого секрета получаются две вещи. Первая из них представляет собой коэффициент ослепления, HMAC строки blinded_node_id под общим секретом, который получатель умножает на публичный ключ этого перехода. Переход по-прежнему может подписывать результат, потому что выводит тот же коэффициент и применяет его к своему приватному ключу, но никто другой не может сопоставить этот ключ с опубликованным графом. Вторая представляет собой ключ шифрования, которым запечатывается небольшой блок инструкций для этого перехода с помощью ChaCha20-Poly1305 при nonce из одних нулей.

Публикуется немногое: точка входа открытым текстом, один начальный ключ маршрута, затем список скорректированных ключей, каждый в паре со своим запечатанным блоком. Внутри блока находятся поля, которые читает этот переход: short_channel_id или next_node_id для того, куда платеж идет дальше, payment_relay для комиссии и приращения CLTV, которые он должен применить, payment_constraints для максимального срока действия и минимального размера HTLC, заполнение и, на последнем переходе, path_id.

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

BOLT 12 добавляет последний элемент маскировки. Вместо комиссии за каждый слепой переход счет несет ровно один blinded_payinfo на маршрут: базовую комиссию в миллисатоши, пропорциональную ставку в миллионных долях, одно суммарное приращение CLTV, минимальный и максимальный размер HTLC и вектор возможностей. Указанная причина состоит в том, что поштучные данные по переходам тривиально выявили бы неоднородность, отличающую маршрут.

Почему это важно при покупке биткоина

Слепые маршруты меняют то, что узнает о вас середина сети Lightning, и ничего не меняют в том, что узнает ваш собственный первый переход.

Ослепление маршрутов скрывает переходы после точки входа и ничего не говорит об узле, через который подключается ваш кошелек, а именно он видит ваши суммы и адреса назначения. Phoenix, который этот сайт оценивает в 4,0 в нашем рейтинге из 41 обзора кошельков, необычно честен в этом вопросе: собственные ответы на частые вопросы ACINQ говорят, что кошелек не дает никакого преимущества в приватности по сравнению с кастодиальным кошельком, где ключи хранит провайдер, и что ACINQ знает конечный адрес назначения и сумму платежей. Слепой маршрут в предложении, которое вы оплачиваете, на это не влияет.

Кастодиальное хранение полностью снимает этот вопрос. Wallet of Satoshi, который этот сайт оценивает в 2,7 и помечает предупреждением, хранит ключи в своем кастодиальном режиме, поэтому оба конца платежа являются его записями; он перестал обслуживать клиентов в США 23 ноября 2023 года и с тех пор отказался от кастодиального сервиса на всей территории Европейского союза. Ничего вашего не ослепляется, когда платеж вообще не покидает книги провайдера.

Ослепление дало бы вам что-то при самом выводе средств. Strike, платформа с наивысшей оценкой в нашем рейтинге, ориентированная прежде всего на Lightning, с оценкой 4,6, не добавляет собственной комиссии за переводы и выплачивает на указанный вами адрес назначения в Lightning. Передайте ей счет BOLT 11, и вы передадите свой узел: подпись несет идентификатор восстановления, поэтому из нее можно восстановить ключ получателя. Предложение подставляет вместо этого точку входа, если плательщик ее поддерживает.

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

Дейв передает Алисе маршрут через Боба и Кэрол

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

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

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

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

Слепой маршрут vs подсказка маршрута

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

Подсказка маршрута представляет собой поле r счета BOLT 11, и это открытый текст. Каждая запись несет публичный ключ в 264 бит, короткий идентификатор канала в 64 бит, базовую комиссию, пропорциональную ставку и приращение CLTV, все открыто, поэтому любой, у кого есть счет, знает, от какого хорошо связанного узла вы зависите. Слепой маршрут называет точку входа и затем становится непрозрачным: каждый последующий переход представляет собой скорректированный ключ, не совпадающий ни с чем в графе, а комиссии приходят суммарно, а не по отдельности. Слепые маршруты также берут на себя задачу, которой у подсказок маршрута никогда не было: они заменяют поля payment_secret и payment_metadata счета BOLT 11.

Слепой маршрут vs луковичная маршрутизация

Луковичная маршрутизация скрывает плательщика от переходов; слепой маршрут скрывает получателя от плательщика.

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