Core Lightning 26.06.9 усуває вразливості платіжних вузлів і затримки трафіку
Публікація джерела: 2026-10-07 · Редакційний аналіз опубліковано: 2026-10-09
Реліз від 7 жовтня виправляє регресію gossip у 26.06.8, посилює захист каналів та API і додає підписані збірки для ARM. Розробники радять якнайшвидше оновитися.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Оновлення платіжного рівня вже випущене
7 жовтня 2026 року Core Lightning опублікував на GitHub версію 26.06.9. Журнал змін у відповідному тегу датований 6 жовтня. Розробники рекомендують якнайшвидше встановити цей коригувальний реліз: він містить виправлення безпеки та усуває регресію обробки повідомлень із 26.06.8. Це програмне забезпечення платіжного вузла, а не прошивка ASIC і не зміна правил консенсусу Bitcoin. Оновлення сервера платежів не змінює хешрейт, налаштування потужності майнера чи винагороду за блок.
ASIC.tools перевірив офіційний реліз і журнал змін. Наш подальший аналіз стосується експлуатації вузла та пов’язаних сервісів, а не обіцяє зростання доходу від майнінгу. Фермі, що отримує лише звичайні виплати в блокчейні, може взагалі не знадобитися це оновлення. Якщо бізнес приймає Lightning-платежі за хостинг, тепло або послуги, спочатку слід встановити, яку саме реалізацію та версію він використовує: різні продукти екосистеми Bitcoin мають власні релізи й процедури переходу.
Чому навантажені вузли затримували повідомлення
У 26.06.9 виправлено облік ресурсу CPU для gossip-запитів. Звичайні gossip-повідомлення, ping і onion-повідомлення більше не витрачають ліміт, призначений для цих запитів. У 26.06.8 завантажений вузол міг обмежувати обробку повідомлень інших вузлів і затримувати трафік каналів. Йдеться про конкретну регресію під навантаженням, а не про зупинку всіх платежів Lightning чи надходження блоків Bitcoin. Ліміт для запитів, які він має контролювати, залишається.
Для оператора тайм-аут застосунку та невдалий платіж — різні стани. Коли оплата на касі затримується, повторення запиту навмання може заплутати рахунки, незавершені спроби й бухгалтерські записи. До створення нового продажу треба звірити ідентифікатор платежу, стан рахунку та остаточний розрахунок. Після оновлення порівнюйте однакове навантаження за однакові інтервали: кілька швидких відповідей ще не підтверджують коректної роботи у найзавантаженіші години.
Закриття каналу та строк виконання HTLC
Журнал змін описує виправлення ситуації, коли запропонований HTLC досягає граничного строку під час закриття каналу. Тепер вузол примусово закриває саме канал, захищаючи транзитні кошти від запізнілого виконання. HTLC — умовний платіжний контракт, а не шара ASIC, надіслана майнінговому пулу. Виправлення стосується взаємодії каналу поза блокчейном із механізмом виконання у блокчейні; воно не гарантує повернення вже втрачених коштів і не означає, що кожен закритий канал був уразливим.
Облік має відображати обидва рівні. Ліквідність каналу не тотожна підтвердженому балансу в блокчейні, доступному для витрачання. Транзакція закриття може спричинити комісії та очікування. Для майнінгового хостингу це впливає на кошти, доступні для електроенергії й повернень клієнтам. Варто звіряти стан каналів і записи розрахунків із журналом застосунку, а не оцінювати платоспроможність за одним числом на панелі чи успішним тестовим платежем.
Окремо перевірте права API
Реліз посилює авторизацію API через rune, приховує низку конфіденційних параметрів конфігурації, усуває можливість ін’єкції рядків у постійну конфігурацію та перевіряє псевдоніми методів на відповідність обмеженням. Rune тут означає облікові дані авторизації, а не криптовалютний токен. Зміни методів слід зіставити з власними інтеграціями, особливо якщо моніторинг або білінг використовує навмисно обмежений доступ.
Сервісу виставлення рахунків зазвичай не потрібні всі права адміністратора. Відокремлення моніторингу лише для читання від виконання платежів і змін конфігурації полегшує аудит. Під час оновлення перевірте, який процес має кожні облікові дані, де вони зберігаються та як відкликаються. Коректна інтеграція повинна працювати з установленими обмеженнями; виправляти її прихованою заміною обмеженого доступу на повний не варто.
Підписані збірки для нових архітектур
Поряд з amd64 додано відтворювані бінарні збірки arm64 та armv7 для Ubuntu 22.04, 24.04 і 26.04. Для кожної архітектури є окремий підписаний маніфест контрольних сум. Офіційна процедура спочатку перевіряє підпис маніфесту, потім контрольні суми файлів. Те, що ARM-пристрій і сервер x86 працюють на Linux, не робить їхні виконувані файли взаємозамінними. Пакет має відповідати архітектурі, дистрибутиву та способу розгортання.
Контрольна сума підтверджує відповідність завантажених байтів маніфесту; перевірений підпис пов’язує його з ключем, якому ви довіряєте. Збереження точної назви файлу, версії та результату перевірки допомагає більше, ніж запис «оновлено до останньої». Це особливо корисно, коли машини встановлювалися у різний час, а контейнерний образ і пакет на хості мають окремі механізми оновлення та можуть містити різні версії.
Сумісність бази даних обмежує відкат
Розробники попереджають: вузли, які запускали збірки гілки розробки master, не можуть повернутися на 26.06.x через новішу схему бази даних. Зберігаються також застереження щодо експериментального dual funding і каналів без підтверджень із недовіреними вузлами. Це не означає, що публічний коригувальний реліз є експериментальною збіркою. Шлях переходу залежить від історії вузла; працездатний бінарний файл сам по собі не доводить сумісності з його каталогом даних.
Перед змінами запишіть початкову версію, джерело пакета, активні плагіни й структуру сховища. Резервне копіювання має відповідати вимогам застосунку щодо узгодженості та відновлення: довільне копіювання відкритих файлів бази не є готовим планом відновлення. Відновлення старого стану каналу також не дорівнює відновленню статичного сайту. Відкат операційної системи та стану платежів — окремі процедури, які варто перевіряти у відповідному тестовому середовищі.
Перевірка після технічного обслуговування
Наша рекомендована перевірка виходить із реальної функції сервісу. Переконайтеся, що вузол працює зі своїм Bitcoin-бекендом, відновлює очікувані з’єднання та відкриває лише потрібні інтерфейси керування. Далі перевірте контрольований рахунок і його остаточний стан через той самий застосунок, яким користуються клієнти. Протягом типового завантаженого інтервалу спостерігайте за помилками, незавершеними платежами й результатами звірки. Це перевірки вашої інсталяції, а не виміряні розробниками показники продуктивності.
Для ферми доступність платежів і доступність майнінгу треба вимірювати окремо. Рахунок клієнта може затримуватися, коли ASIC продовжують хешувати; успішний платіж нічого не говорить про несправний насос чи відхилені шари. Окремі показники допомагають знайти проблемну систему й не пов’язувати помилку платіжного вузла з прошивкою майнера. Клієнтам також простіше пояснити обслуговування платіжного сервісу, яке не зупиняє їхнє обладнання на хостингу.
Що підтверджує цей реліз
Оновлення доступне, але розробники тимчасово не оприлюднюють тести для виправлень безпеки, щоб дати операторам час оновитися. Це не означає, що сам реліз ще не випущений, і не є причиною чекати демонстрацій експлойтів. Для встановлення та сумісності спирайтеся на офіційні примітки. Описова назва релізу сама по собі не доводить появи нової гарантії квантової безпеки для майнінгу Bitcoin чи всіх транзакцій Lightning: технічні властивості встановлюють за реалізацією і документацією.
Матеріал ілюструють різні ліцензовані архівні фото серверного та мережевого обладнання. Вони не показують команду розробників або скомпрометований вузол. Наступні коригувальні релізи ASIC.tools розглядатиме окремо після підтвердження журналів змін і дат. Для цього оновлення практична дія така: з’ясувати, чи використовує сервіс Core Lightning, перевірити зміни та обрати сумісний шлях обслуговування з перевіреними інсталяційними файлами.
Джерело: Core Lightning ↗ · Versioned 26.06.9 changelog ↗
Калькулятор майнінгу ↗
