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

1. BOLT11 теперь требует ровно один хэш платежа и один секрет платежа, отклоняя счета с отсутствующими или повторяющимися полями.
2. Один из разработчиков описал, как конфликтующие парсеры счетов могут приводить к тому, что завершенные транзакции будут выглядеть как неоплаченные, открывая путь для дальнейших выплат.
3. В выпущенных версиях lnd реализовано отклонение повторяющихся хэшей, а предложение о добавлении проверок секретов платежей оставалось открытым по состоянию на 27 октября.

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

Внесенное изменение направлено на программные компоненты, которые по-разному обрабатывают один и тот же подписанный запрос на оплату. Хэш платежа идентифицирует платеж, за которым следит компонент. Bitcoin Optech осветил это изменение правил 23 октября.

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

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

Что должны отклонять пользователи

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

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

Важно также учитывать сроки реализации. Программное обеспечение для узла Lightning Network, lnd, внедрило исправление, отклоняющее повторяющиеся хеши 23 сентября, до внесения изменений в спецификацию. В доступных версиях v0.20.5-beta и v0.21.4-beta включено это исправление хеша платежа.

Более широкие проверки секретного ключа платежа рассматриваются в отдельном предложении для lnd, которое оставалось открытым по состоянию на 27 октября. Оно позволит усилить проверки секретного ключа платежа и других декодеров, включая отклонение второго поля s. Автор также объясняет, что некоторые счета, принимаемые декодером, уже проходят проверки на более поздних этапах обработки платежа, поэтому сам факт успешного декодирования не гарантирует, что платеж будет успешно выполнен.

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

Контекст статьи.