Il BIP139, un formato per esportare i metadati di un wallet Bitcoin (account, descrittori, firmatari, etichette, transazioni, monete e PSBT), è stato unito al repository dei BIP il 24 ottobre 2026, come mostra la pull request #2130 su GitHub. La proposta è dello sviluppatore che si firma Pyth e ha richiesto quasi sette mesi di revisione dall’apertura del 27 marzo; nel testo del BIP lo stato è ancora Draft e la voce «Reference Implementation» riporta «TBD».
BitcoinLive24 riassume cosa prevede il documento, quali regole di sicurezza fissa e quali obiezioni hanno fatto i revisori prima del merge.
BIP139: cosa è stato unito e quando
Il BIP139 si intitola «Wallet Metadata Export Format», appartiene al livello Applications ed è di tipo Specification, secondo l’intestazione del documento. Il numero è stato assegnato l’11 maggio 2026 dall’utente murchandamus, che il 24 ottobre ha anche eseguito il merge dopo aver tolto l’intestazione Version, perché il documento non ha un changelog: lo scrive lui stesso nella discussione della pull request.
| Elemento | Dato | Fonte |
|---|---|---|
| Titolo e numero | BIP139, «Wallet Metadata Export Format» | Testo del BIP |
| Autore | Pyth | Testo del BIP |
| Stato e tipo | Draft, Specification (livello Applications) | Testo del BIP |
| Apertura della pull request | 27 marzo 2026 | Pull request #2130 |
| Numero assegnato | 11 maggio 2026 | Pull request #2130 |
| Merge nel repository | 24 ottobre 2026 | Pull request #2130 |
| Campi obbligatori del wallet | version, network, accounts (almeno un account) | Testo del BIP |
| Implementazione di riferimento | «TBD» | Testo del BIP |
Che cosa contiene l’esportazione di un wallet secondo il BIP139
Il BIP139 definisce un file di testo UTF-8 con un solo oggetto JSON che rappresenta il wallet, come descrive la sezione «Specification» del documento. L’oggetto principale deve avere i campi version, network e accounts: la versione ha la forma BIP139-<numero intero> e la rete può essere bitcoin, testnet3, testnet4, signet, mutinynet o regtest. Un’esportazione copre una sola rete: un wallet con account su più reti scrive un file per ciascuna.
Ogni account deve indicare il tipo e il descrittore. I tipi ammessi sono bip380 (descrittore di output), multi_bip380 (un insieme di descrittori BIP380), bip388 (wallet policy) e bip392 (silent payments), secondo il testo del BIP. Per il tipo multi_bip380 il documento osserva che può servire a wallet come Electrum, il software di cui BitcoinLive24 ha raccontato l’ultima correzione di sicurezza.
Le altre parti sono facoltative. Il registro dei campi elenca per gli account, tra gli altri, il nome, lo stato (active, superseded o archived), il gap_limit, l’altezza di blocco di nascita e le etichette nel formato del BIP-0329; a livello di wallet prevede una mappa delle transazioni, una mappa delle PSBT e l’elenco dei firmatari, con i dati sui dispositivi di firma.
Il registro dei campi e le regole di sicurezza
Il BIP139 definisce nel proprio testo solo i campi obbligatori e rimanda per tutti gli altri a un registro separato, così da poterne aggiungere senza modificare il BIP. Secondo il documento, una richiesta di modifica al registro può aggiungere o cambiare solo campi opzionali, mentre i campi obbligatori sono fissati dal BIP; chi registra un campo deve indicare nome, oggetto, tipo e breve descrizione e, quando possibile, collegare un test vector o un’implementazione.
Sul fronte della sicurezza, la sezione «Security Considerations» del BIP stabilisce che il formato non deve includere chiavi segrete di firma né mnemoniche della mainnet, perché un backup può finire online o nel cloud; l’unica eccezione ammessa è la chiave privata di scansione di un descrittore BIP392 (silent payments). Il campo bip39_mnemonic del registro è pensato solo per le reti di test e non va usato per seed protetti da passphrase BIP-39. Per la cifratura il testo rimanda al BIP-138, la cui pull request #1951 («Compact Encryption Scheme for Non-seed Wallet Data») risulta unita.
Il registro contiene anche una regola per la data di nascita dell’account: se un wallet conosce solo una data, può stimare l’altezza di blocco come (data − orario del blocco genesis) / 600, ma la stima deve cadere al massimo sull’altezza vera, mai dopo, perché partire troppo presto costa solo tempo di scansione mentre partire troppo tardi può far perdere transazioni, spiega il registro. In importazione, i software dovrebbero conservare i metadati che supportano, scartare i campi non supportati e avvisare l’utente se dati essenziali non si possono ripristinare, come indica il BIP.
Le obiezioni dei revisori prima del merge
La pull request #2130 conta 28 commenti e 51 commenti di revisione, secondo i dati dell’API di GitHub. In una revisione di inizio aprile l’utente seedhammer ha segnalato una sovrapposizione con la pull request #2099 (BIP393, «Output Script Descriptor Annotations», risultata anch’essa unita) e ha scritto che sarebbe ideale un solo modo di codificare i metadati di un wallet. Pyth ha risposto il 7 aprile che i due usi sono diversi: la #2099 è, secondo la sua descrizione, un backup minimo da fare una volta alla creazione del wallet, con le sole informazioni per la scansione, mentre il BIP139 punta al backup o all’esportazione del wallet completo.
Il 27 marzo murchandamus aveva chiesto di chiarire il rapporto con il BIP-138 e il 7 aprile aveva notato una possibile sovrapposizione anche con il BIP-329 (il formato per l’esportazione delle etichette); Pyth ha aggiunto una sezione «Encryption» il 9 aprile. Il 26 maggio l’utente Sjors ha dubitato che sia una buona idea un unico blocco JSON per tutto e Pyth ha risposto il 15 giugno ammettendo che la descrizione iniziale della pull request era fuorviante e precisando che il BIP139 ha uno scopo indipendente dal BIP-138, con cui condivide solo la possibilità di essere cifrato. Il 29 giugno l’utente ethicnology ha sostenuto che uno standard richiede campi obbligatori, citando il BIP-329, perché se tutto è opzionale ciascuno implementa solo ciò che gli interessa; tutti i commenti sono nella discussione.
Il 21 agosto Pyth ha scritto di aver esaminato 13 wallet candidati, scelti da lui e senza che avessero manifestato interesse, e di aver rielaborato in modo sostanziale la struttura. Il 21 ottobre, dopo che murchandamus si era detto sorpreso di trovare quella sezione nel testo, ha annunciato di toglierla dalla specifica e di lasciarne il link nella discussione; il merge è arrivato tre giorni dopo, secondo la pull request.
Cosa aspettarsi dopo il merge
Il BIP139 resta una bozza: il testo non indica un’implementazione di riferimento («TBD») né elenca i wallet che lo adotteranno. Il valore pratico dipenderà da quanti software scriveranno e leggeranno il formato, e il registro dei campi è pensato proprio per far dichiarare a ogni implementatore quali campi usa. Per chi segue lo sviluppo del software Bitcoin, un’altra novità recente è la nuova policy di sicurezza di Bitcoin Core. Scarica l’app BitcoinLive24 per ricevere le notizie sul protocollo e sui wallet.
Domande frequenti sul BIP139
Che cos’è il BIP139?
Il BIP139 è una specifica in stato Draft che definisce un formato JSON per esportare i metadati di un wallet Bitcoin, dagli account ai firmatari fino a transazioni, monete e PSBT, secondo il testo del BIP. Serve a far leggere a un’applicazione ciò che un’altra ha scritto.
Il BIP139 salva le chiavi private?
Non le chiavi di firma né le mnemoniche della mainnet: il BIP le vieta nell’esportazione, ammettendo come unica eccezione una chiave privata di scansione dei silent payments (BIP392). Il campo per la mnemonica BIP-39 è previsto solo per le reti di test, come specifica il registro.
Quando sarà usabile nei wallet?
Il documento non lo dice: l’implementazione di riferimento è indicata come «TBD» nel BIP e non elenca wallet che lo supporteranno.
Questo articolo ha scopo informativo e non costituisce consulenza finanziaria o tecnica.
