Lightning посилює правила виставлення рахунків після повідомлення про атаку, що зробила виведення Bitcoin не сплаченими.

Розробники Lightning Network 19 жовтня посилили стандарт рахунків BOLT11, вимагаючи від програмного забезпечення відхиляти неоднозначні поля payment-hash та payment-secret.

Це рішення стало наслідком випадку, коли завершені виведення біткойн з’являлися як не сплачені. Зміна стосується програмного забезпечення, яке по-різному обробляє підписані запити на оплату.

Payment hash дозволяє ідентифікувати платіж, який відслідковує компонент.

23 жовтня про цей зміни повідомив Bitcoin Optech. У заяві від 10 вересня розробник Roasbeef повідомив про нещодавню атаку на Telegram-бота, який використовував бібліотеки з різними хешами: деякі брали перше поле payment-hash в рахунку, інші — останнє.

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

Виникає ризик помилитися, вважаючи завершене виведення непогашеним, що створює можливості для подальших виплат. Нові правила вимагають наявності рівно одного payment-hash поля та одного payment-secret.

Наявність зайвого поля або його відсутність призведе до невдачі платежу.

Це правило виявляє будь-які двоякі ситуації, а описана атака стосується конфліктуючих payment hashes. Читачам слід ретельно враховувати кількість полів.

Неправильні тестові випадки включають рахунки з повторюваним одним і тим же хешем або з різними хешами.

Об'єднання ідентичних значень в одне призведе до пропуску рахунку, який потрібно відхилити. Терміни впровадження також мають значення.

Програмне забезпечення вузла Lightning, lnd, включило відхилення дублікатів хешів 23 вересня, до зміни специфікації.

Документи версій v0.20.5-beta та v0.21.4-beta вже містять виправлення payment-hash. Перевірка payment-secret розглядається в окремій пропозиції lnd, що залишалася відкритою станом на 27 жовтня.

Вона посилить перевірки payment-secret і інші декодери, включаючи відхилення другого s поля.

Автор пояснює, що деякі рахунки, прийняті декодером, вже підлягають перевіркам під час обробки платежу, тому успішний декодування не гарантує, що платіж пройде. Для операторів платежів документовані невдачі вказують на дві перевірки: відхиляти неоднозначні рахунки та забезпечити, щоб облік виведення відповідав тому ж payment hash, що й вузол.