Bitcoin Core v32.0rc1: cambiano i protocolli del wallet, possibili disservizi per app e servizi

Bitcoin Core v32.0rc1 apre una finestra di test di compatibilità tra il 14 settembre e il 10 ottobre per operatori di nodi, provider di wallet e servizi che dipendono dalle interfacce RPC di Bitcoin Core. Il candidato è stato taggato con firma verificata il 14 settembre. Nel calendario ufficiale la data obiettivo per il tag finale v32.0 è il 10 ottobre, con un intervallo di 26 giorni. Un’anteprima di CryptoSlate pubblicata ad agosto indicava come target per RC1 il 10 settembre, mentre il calendario aggiornato riporta il 14 settembre: uno scarto di quattro giorni, senza che sia chiaro se una scadenza invariata sia stata mancata. Il tag v32.0rc1 identifica software in prerelease, non un aggiornamento "production-final", e non implica l’attivazione di nuove regole di consenso. Tra le modifiche spicca un intervento collegato alla bozza BIP 323, che cambia il modo in cui Bitcoin Core gestisce i bit di segnalazione e gli avvisi per "unknown deployment". La proposta resta in stato Draft. Per iniziare i test, gli operatori possono seguire l’impostazione suggerita nella più recente guida di testing per RC di Bitcoin Core: esercitare le funzionalità usate abitualmente in directory dati temporanee separate e confrontare il candidato con la release precedente. La pagina di download ufficiale indica 31.1 come baseline corrente. Questo confronto consente di individuare differenze nell’avvio del nodo, nel comportamento del wallet e nelle risposte RPC senza trattare la RC come un normale aggiornamento di produzione. Sul fronte performance, la bozza delle note di rilascio v32 evidenzia soprattutto il prefetch parallelo degli output di transazione durante la connessione dei blocchi. L’impostazione predefinita è di otto worker, con supporto fino a 16 e possibilità di disattivazione. Eseguire la validazione legata al disco con più configurazioni permette di capire se l’aumento di velocità nell’elaborazione dei blocchi comporta costi non accettabili in termini di CPU, memoria o latenza di storage sull’hardware dell’operatore. Più delicato il rischio di rotture per integrazioni di wallet e servizi. Quattro RPC passeranno di default a PSBTv2; altre interfacce rimuovono campi deprecati o respingono argomenti che versioni precedenti accettavano. Chi crea, converte o effettua feebump su PSBT dovrebbe quindi seguire end-to-end questi flussi attraverso parser e signer a valle. Anche la gestione delle fee richiede copertura dei percorsi di errore. Il percorso predefinito di estimatesmartfee combina stimatori blockpolicy e mempool, può restituire una stima più bassa e può fallire se uno dei due componenti va in errore. Conviene osservare condizioni di avvio e scenari con mempool scarso o in cattivo stato, verificando che il monitoraggio e i fallback espliciti su blockpolicy funzionino come previsto. La riscrittura del server HTTP amplia l’area di test oltre il nodo. Introduce un limite di 8.192 byte per gli header, una gestione più severa degli header malformati, un tetto predefinito di 16 connessioni RPC, nuovi controlli di cache per REST e la disconnessione immediata degli indirizzi client non autorizzati. Effetti potenziali: reverse proxy, health check, pool di client e gestione degli errori. Va pianificato anche il rollback. Un indice delle transazioni ricostruito usa meno della metà dello spazio su disco, ma le release precedenti non leggono il nuovo formato: un downgrade può innescare una nuova ricostruzione che dura ore. Per gli operatori attenti alla privacy, è opportuno riprodurre anche i percorsi di errore relativi alla trasmissione privata intorno al fix del fallback Tor, alla coda da 10.000 voci, al limite di 1.000 tentativi e al comportamento di relay sotto carico. Con il tag finale ancora indicato come obiettivo, questi casi limite rappresentano il lavoro pratico della finestra di RC.