Core Lightning, een van de belangrijkste software-implementaties voor het draaien van Bitcoin Lightning-betalingsnodes, heeft versie 26.06.10 uitgebracht met een nieuwe reeks beveiligingsfixes, en de maintainers dringen er bij alle gebruikers op aan zo snel praktisch mogelijk te upgraden. De update koppelt de softwarepatch aan een tweede taak voor operators: het controleren van de credentials die externe opdrachten op hun nodes mogelijk maken, een stap die de maintainers beschrijven als losstaand van het installeren van de nieuwe versie. De update combineert de versterking van de plugin die externe opdrachten afhandelt met wijzigingen in de manier waarop nodes kanaalopeningen en betaalvoorwaarden beoordelen.

Dit is de derde opeenvolgende puntrelease die zonder embargo-periode is uitgebracht. Versies 26.06.8 en 26.06.9 volgden dezelfde aanpak, waarbij de fixes onmiddellijk openbaar werden gemaakt. Net als bij die releases hebben de maintainers nu opnieuw de tests achtergehouden die aan de beveiligingsfixes zijn gekoppeld. Volgens de release notes maakt dit het moeilijker om de fixes om te zetten in werkende exploits en geeft het gebruikers meer tijd om te upgraden. Het openbaarmakingsmodel bepaalt ook de inzet voor operators: zodra een release openbaar is, zijn de zwakke plekken die wordt aangepakt dat ook, wat betekent dat een node die achterloopt software draait met gedocumenteerde gebreken.

Credential-controle toegevoegd aan de upgrade-checklist

Runes en commando staan centraal in het beveiligingswerk van deze update. Commando laat een direct verbonden peer een node verzoeken een opdracht uit te voeren, en de peer heeft doorgaans een rune nodig — een autorisatie-credential — om dat te doen.

De update sluit een manier om de rune-limieten op parameternamen te omzeilen via dubbele namen of namen met leestekenvarianten. Daarnaast wordt een commando-crash verholpen die werd veroorzaakt door het hergebruiken van een commando-ID na een mislukte opdracht. Te grote runes worden nu resoluut geweigerd; voorheen kon de software kwadratische tijd besteden aan het decoderen ervan.

De maintainers raden aan elke rune die via commando wordt gebruikt te koppelen aan de node-ID van de app die deze gebruikt. Met deze id-restrictie kan de rune nergens anders worden ingezet. Operators wordt eveneens opgedragen runes die zij niet kunnen verantwoorden te blacklisten met het commando blacklistrune, en daarna nieuwe runes met strengere restricties uit te geven. Samen genomen komen deze stappen neer op een audit van elke credential die externe opdrachten op een node kan activeren, waarbij onverklaarde runes worden ingetrokken voordat nieuwe worden uitgegeven.

Kanaal- en betaalfixes

De nieuwe versie controleert de transactiehandtekeningen van een peer tijdens de opening van kanalen met dubbele financiering en bij splicing, de operatie die het kapitaal van een kanaal aanpast zonder het te sluiten. Dit volgt de BOLT 2-specificatie van het Lightning-protocol, die kanaalvestiging en normale peer-to-peer-werking behandelt, aldus de changelog.

Een andere fix heeft betrekking op een voorwaardelijk betaalcontract dat bekendstaat als een HTLC. Een zojuist verwijderde HTLC kon worden verward met een actieve HTLC die dezelfde payment hash, hetzelfde bedrag en dezelfde vervaldatum deelde, waardoor de node de actieve betaling liet mislukken terwijl de peer deze alsnog kon claimen.

De afhandeling van kanaalopeningen is ook strenger. Nodes weigeren nu kanaalopeningen wanneer een peer een dust limit — de drempel waaronder outputs als dust worden beschouwd — boven de 5.000 satoshis voorstelt; de changelog meldt dat het oude gedrag een peer in staat stelde het saldo van de node tijdens een gedwongen sluiting om te zetten in transactiekosten. Bij openingen met dubbele financiering wordt ook een dust limit van een peer boven het kanaalreserve geweigerd, en een v2 zero-confirmation opening — een kanaal dat live gaat voordat de funding-transactie is bevestigd — wordt geweigerd, tenzij de operator de node heeft ingesteld er er een van die peer te accepteren. Dubbele financiering blijft experimenteel, en de maintainers ontmoedigen zero-confirmation-kanalen met peers die niet worden vertrouwd.

Andere wijzigingen geven een veilig standaardantwoord wanneer een plugin-hook faalt, in plaats van een crash of vastloop. Splice fee bumps gebruiken nu ten minste 25/24 van de eerdere feerate, wat peers zoals Eclair vereisen. Nodes die development-builds hebben gedraaid, kunnen niet afgraderen naar de 26.06.x-serie, omdat hun databaseschema nieuwer is. De release bevat reproduceerbare binaries voor Ubuntu 22.04, 24.04 en 26.04, plus Docker-images.

Openbaarmaking en releasetiming

De gebreken die in deze release zijn verholpen, werden gemeld door bijna 20 bij naam genoemde bronnen, waaronder The Bitcoin Red Team, Matt Morehouse en Niklas Gögge. Anderen verzochten niet met name genoemd te worden.

GitHub vermeldt 4 november als releasedatum voor de versie, terwijl de getagde changelog 5 november toont. De update volgt op een aparte stored-trigger-crash die op 2 november werd openbaar gemaakt. Ten tijde van het schrijven handelde bitcoin rond $76.002, een daling van 5,29% in 24 uur.