Bitcoin Core 32.0, de open-source software waarmee computers Bitcoin-betalingen onafhankelijk kunnen verifiëren, is maandag in de release-candidate-testfase gegaan, volgens het projectschema. Release candidates zijn voorlopige versies die worden gepubliceerd zodat testers resterende problemen kunnen opsporen vóór de definitieve build. Ontwikkelaars mikken op 10 oktober om de afgeronde versie uit te brengen, hoewel de uitkomst van de tests die planning nog kan verschuiven.

De update heeft vooral invloed op node-operators en ontwikkelaars die de software gebruiken om wallets en andere diensten te draaien, in plaats van gewone gebruikers van wallet-apps. Prestaties staan centraal: volgens de concept-release notes kan de update blokcontroles versnellen door database-informatie parallel te lezen, zonder dat dit verandert aan de snelheid waarmee Bitcoin blokken produceert. Snellere verificatie is belangrijk omdat de kerntaak van een full node is om elk nieuw blok te toetsen aan de regels van het netwerk—blokken komen ruwweg elke tien minuten binnen—waardoor het verminderen van die werklast de doorlopende taak van het verifiëren van betalingen zonder vertrouwde derde partij lichter maakt.

Vier-commando's zullen daarnaast standaard een nieuwer formaat gebruiken voor het uitwisselen van gedeeltelijk ondertekende transacties tussen wallets en signeerapparaten—een formaat waarmee een onvoltooide transactie handtekeningen kan verzamelen op meerdere apparaten voordat deze compleet is—hoewel applicaties indien nodig nog steeds de oudere versie kunnen opvragen.

Beveiliging is de andere prioriteit van deze release. Eén fix voorkomt dat vervaardigde wallet-namen commando's activeren op de computer van een node. De fout betrof niet-Windows-systemen in gevallen waarin een geauthenticeerde gebruiker wallets kon aanmaken en de walletnotify-functie was geconfigureerd om commando's uit te voeren bij wallet-transacties. Deze klasse van bugs krijgt veel aandacht omdat ze de grens tussen data en instructies doet vervagen: een wallet-naam, normaal gesproken slechts een label, kon in wisselwerking komen met de commando-uitvoering van de walletnotify-functie, en de patch doorknipt dat pad.

Een aparte patch lost overmatig geheugengebruik op in de nieuwe HTTP-server van het project, die verzoeken van verbonden applicaties afhandelt. Contributor Matthew Zipkin, die onder de naam pinheadmz post, beschreef een "memory exhaustion-scenario" in zijn patchvoorstel. Zijn eerste inschatting beperkte het risico tot geauthenticeerde clients.

Zipkin zei de fout te hebben gevonden tijdens het auditen van Bitcoin Cores nieuwe HTTP-server met Kimi K3, een AI-model dat ook door het Bitcoin Red Team is gebruikt om naar kwetsbaarheden in Bitcoin-software te zoeken. Een eerdere fix had een deel van het probleem opgelost, legde hij uit, maar een manier om het beschikbare geheugen van een computer uit te putten—een "OOM"- of out-of-memory-situatie—bleef bestaan.

Tijdens de review van dezelfde patch ontdekte GitHub-gebruiker jeanpablojp dat ook verzoeken zonder inloggegevens geheugengroei kunnen veroorzaken wanneer de REST-interface is ingeschakeld. Nadat Zipkin de patch had herzien, meldde de reviewer dat 16 niet-geauthenticeerde verbindingen ongeveer 3 MB geheugengroei veroorzaakten over 90 seconden, vergeleken met 3,2 GB vóór de wijziging. De herziene patch werd op 5 september samengevoegd in Bitcoin Core 32.0 als onderdeel van doorlopend werk om beveiliging van de software te verbeteren. Het niet-geauthenticeerde scenario vergrootte de zorg boven de eerste inschatting uit, omdat dit soort verzoeken geen vertrouwde, ingelogde gebruiker vereist.

De patch komt in een bredere periode van kwetsbaarheidrespons binnen aan Bitcoin gerelateerde software. Hardware-walletmaker BitBox dichte in augustus twee ernstige firmwarefouten, zonder aanwijzingen voor misbruik. Afzonderlijk waarschuwden de ontwikkelaars van Core Lightning, een betalingssoftware, node-operators voor bevestigde kwetsbaarheden terwijl zij fixes voorbereidden. De release candidates tussen nu en 10 oktober zullen uitwijzen of de beoogde datum haalbaar is, en de fixes zijn alleen effectief waar operators uiteindelijk de bijgewerkte versie draaien.