Bitcoin Core heeft de officiële openbaarmaking gepubliceerd van CVE-2025-62861, een fout met hoge ernst in de transactie-relaylogica van de node-software die mining-activiteiten kon laten hashen op verouderde bloktemplates zonder enige zichtbare waarschuwing. Het advies schrijft de melding toe aan securityonderzoeker Niklas Goegge en herleidt het probleem tot een relayregel die op het verkeerde moment afging: tijdens een chain reorganization, wanneer deze juist stil had moeten blijven.

De getroffen versies lopen van Bitcoin Core 28.0 tot en met 28.2 en van 29.0 tot en met 29.1. De oplossing verscheen in oktober 2025, maar de volledige technische details werden tot november 2026 achtergehouden op grond van het gecoördineerde openbaarmakingsbeleid van het project. Het advies noemt geen storing en geen getroffen beheerder; de blootstelling is historisch. Mininghardware die wees naar een node in de gecorrumpeerde toestand zou zijn blijven hashen, maar op de laatste template die het had ontvangen, waardoor nieuwe transacties en hun fees onopgeëist bleven totdat iemand het doorhad.

Hoe een reorganisatie een transactie kan wees maken

Een reorganisatie treedt op wanneer een node zijn huidige chain tip laat vallen voor een concurrerende, zwaardere tak. De transacties in de losgekoppelde blokken blijven geldig, dus Bitcoin Core plaatst ze terug in de mempool, de opslagplaats voor onbevestigde transacties. Omdat die transacties al waren bevestigd in een geldig blok, voegt de node ze opnieuw toe met een vlag genaamd bypass_limits, die de gebruikelijke anti-spam- en topologiecontroles uitschakelt. Het doel is de pool getrouw te herstellen, niet transacties die al door consensus zijn gekomen opnieuw te beoordelen.

Een van de controles die had moeten worden uitgeschakeld, betreft versie-drie-, of TRUC-, transacties. Onder BIP 431 mag een TRUC-transactie maximaal één onbevestigde ouder en één onbevestigd kind hebben. Dat is een relaybeleid, geen consensusregel: een blok kan legitiem een TRUC-ouder met meerdere kinderen bevatten, ook al zou geen enkele node die vorm vanuit het netwerk in zijn mempool accepteren. Diezelfde grens tussen beleid en consensus bepaalde ook de grens van de bug zelf: CVE-2025-62861 kon de mempool van een node corrumperen en de template-output vastzetten, maar het kon geen ongeldig blok creëren of de regels van de chain wijzigen.

Sinds versie 28.0 handhaaft Bitcoin Core de limiet van één kind via een mechanisme genaamd sibling eviction. Wanneer een nieuwe transactie een TRUC-ouder een tweede onbevestigd kind zou geven, behandelt de node het bestaande kind als vervangingskandidaat en, als de nieuweling genoeg fees betaalt, wordt het verwijderd volgens replace-by-fee-regels.

De bug was dat sibling eviction werd uitgevoerd zelfs wanneer bypass_limits was gezet. Een reorg die een TRUC-ouder met meerdere kinderen herstelde — een vorm die in het losgekoppelde blok volkomen geldig was — kon de verwijdering van één herstelde transactie veroorzaken terwijl de transacties die zijn outputs uitgaven in de pool bleven. De mempool bevatte toen kinderen wiens ouder nergens meer bestond: niet in de chain, en niet in de pool.

De oplossing van Greg Sands koppelde de TRUC-controles aan bypass_limits, zodat eviction niet meer wordt uitgevoerd tijdens het herstel van een reorg. De bijbehorende pull request, PR #33504, voegde ook het testscenario toe dat de oorspronkelijke code miste: transacties die afkomstig zijn uit losgekoppelde blokken in plaats van van peers.

Hoe een vastgelopen template eruitziet vanuit het mining-perspectief

Een node geeft werk aan mining-software via getblocktemplate, dat een kandidaatblok samenstelt, dit door de eigen geldigheidscontrole van de node haalt en het vorige blokhash, de gekozen transacties en de volgende hoogte teruggeeft. Met een weestransactie in de pool voldeed de samengestelde kandidaat niet aan die controle, waardoor de aanroep geen vers werk kon teruggeven.

Van buitenaf leek de node gezond:

• Proces draait
• Peer-verbindingen open
• Chain tip schrijdt voort
• Mempool accepteert nieuwe transacties

Wat er feitelijk kapot was:

• De template-aanvraag geeft een fout terug
• Hashers blijven werken op verouderd werk
• Er kan geen blok worden gevonden op de huidige tip
• De toestand blijft bestaan tot de node opnieuw wordt gestart

Alles wat een generiek monitoringdashboard in de gaten houdt, zou groen zijn gebleven. Het netwerk gaf ook geen signaal terug: de chain tip schreed voort — blokken werden nog steeds gevonden, alleen niet door deze partij — dus de kosten kwamen alleen op de vastgelopen miner neer, in hashing die geen blok op de huidige tip kon produceren en in fees die het anders had geïncasseerd. Het enige dat een miner van de node nodig heeft — een actuele template — was precies datgene wat de node niet meer produceerde.

Herstart, patch en einde levensduur

Het herstarten van de node herlaadt de mempool vanaf schijf in een consistente toestand, wat het symptoom wegneemt. Het doet niets aan de oorzaak: de volgende reorg met dezelfde transactievorm kon de node opnieuw vast laten lopen.

Het onderliggende defect werd in drie releases verwijderd. Versie 30.0 verscheen met de oplossing op 10 oktober 2025, gevolgd door backports in 29.2 en 28.3. Van de private melding tot de laatste van die releases duurde drie weken:

Beide backportbranches zijn inmiddels uit support gevallen. Het onderhoudsbeleid van Bitcoin Core dekt de drie meest recente hoofdreleases — momenteel 30.x, 31.x en 32.x — en 29.x bereikte het einde van de levensduur op 27 oktober 2026. Een beheerder die de oorspronkelijke storing alleen met een herstart beantwoordde, draait nu niet-ondersteunde code, met een publieke beschrijving van precies welke transactievorm het probleem veroorzaakt.

Waarom het advies 396 dagen wachtte

Van de eerste opgeloste release tot het gedetailleerde advies duurde het 396 dagen, en de openbaarmaking viel precies twee weken nadat 29.x het einde van de levensduur had bereikt. Geen van beide getallen is toeval. Het openbaarmakingsbeleid van Bitcoin Core houdt details van gemiddelde en hoge ernst achter tot twee weken nadat de laatste getroffen release niet meer wordt ondersteund, met een aankondiging vooraf twee weken daarvoor, getimed op een nieuwe hoofdrelease.

De embargo besloeg de uitleg, niet de code. De pull request is publiek sinds 29 september 2025, en de release notes van 28.3 en 29.2 vermeldden destijds al een mempool-fix. Wat een jaar lang privé bleef, was de toelichting die de patch verbindt aan een reproduceerbare mining-stilstand.

Het beleid biedt wel een snellere route. Bugs die als eenvoudig te ontdekken worden ingedeeld — wat het project definieert als vindbaar met minimale inspanning — krijgen onmiddellijk een puntrelease en advies zonder embargo. Deze ging door de standaardplanning, dus de maintainers beschouwden hem niet als triviaal te vinden. Hij werd op dezelfde dag gepubliceerd naast twee andere adviezen van hoge en gemiddelde ernst, over een blokverwerkingsstilstand en een Tor-machtigingsfout; alle drie werden opgelost in dezelfde releasecyclus van oktober 2025. Elke build die nieuw genoeg is om de mempool-patch te bevatten, bevat dus ook de andere twee fixes.

De tragere route belichaamt zijn eigen aanname: dat beheerders binnen het jaarlange venster upgraden, zodat tegen de tijd dat de trigger publiekelijk wordt beschreven, niemand kwetsbaar er nog naar luistert.

Wat te monitoren in plaats van uptime

Voor een mining-activiteit is de nuttige controle niet of de node leeft, maar hoe oud de meest recente succesvolle template is. Een proces dat draait, verbonden en gesynchroniseerd is, kan desondanks zijn gestopt met het leveren van werk, en deze bug was één manier waarop dat geruisloos kon gebeuren. De build-versie hoort in dezelfde controle thuis, want een node die vandaag actuele templates heeft, kan morgen uit support zijn.

Backuptemplate-bronnen stellen dezelfde vraag. Een failover-node op dezelfde release en hetzelfde mempoolbeleid zou dezelfde reorg en dezelfde stilstand hebben getroffen; twee draaiende processen zijn geen twee onafhankelijke werkbronnen. Alleen een node op een andere, gepatchte build zou de operatie minend hebben gehouden, en alleen een beheerder die dat onder een gesimuleerde reorg had getest, zou dat vooraf hebben geweten.