Una proposta pubblicata il 4 ottobre 2026 su Delving Bitcoin chiede di dare ai descriptor (le stringhe che descrivono come un wallet costruisce e sblocca un indirizzo) una forma privata per i preimage hash, cioè i segreti che sbloccano uno script bloccato da un hash (hashlock). La proposta è stata ripresa da Bitcoin Optech il 23 ottobre. Come si legge nel thread originale, oggi il wallet di Bitcoin Core non ha alcun modo di ricevere un preimage direttamente e serve passare da strumenti esterni.
Descriptor e preimage hash: cosa propone il thread
Il thread del 4 ottobre 2026 propone quattro varianti di una nuova sintassi per i descriptor, secondo il post su Delving Bitcoin. La forma privata sarebbe del tipo sha256(preimage(HEX)), da replicare per hash256, ripemd160 e hash160, ed è pensata come possibile nuovo BIP che estenda il BIP379, la specifica di Miniscript, ancora in stato Draft.
Il thread è firmato jaonoctus; Bitcoin Optech lo attribuisce a João Dias e lo ha inserito nella newsletter #428 del 23 ottobre.
Il problema nasce da un’asimmetria: un descriptor può già contenere una chiave privata, per esempio nella forma pk(WIF/xprv), e restituirla con listdescriptors private=true, mentre per i segreti dei frammenti hash di Miniscript non esiste un equivalente. L’autore racconta di averlo scoperto risolvendo la sfida CTB di Michael Tidwell al TABConf, in cui per spendere serviva fornire un preimage.
| Elemento | Dato | Fonte |
|---|---|---|
| Data del thread | 4 ottobre 2026 | Delving Bitcoin |
| Sintassi proposta | sha256(preimage(HEX)), e analoghe per hash256, ripemd160, hash160 | Delving Bitcoin |
| Lunghezza del preimage | esattamente 32 byte | Delving Bitcoin |
| Specifica da estendere | BIP379 (Miniscript), stato Draft | Testo del BIP |
| Ripresa da Optech | Newsletter #428, 23 ottobre 2026 | Bitcoin Optech |
| Risposte testuali nel thread | 0 (verificato il 27 ottobre 2026) | Delving Bitcoin |
Perché un preimage somiglia a una chiave
Un preimage da 32 byte dipende solo dallo script, a differenza di una firma. L’autore sostiene che va trattato più come una chiave: una firma si impegna su una transazione specifica e quindi non può far parte di un descriptor, mentre un preimage è un segreto di lunga durata, come spiega il thread.
Il riferimento è alla discussione #24114 di Bitcoin Core, aperta dall’utente sipa il 20 gennaio 2022, dove si ipotizza che molti campi di SignatureData possano essere sostituiti da un oggetto descriptor, a eccezione di firme e preimage. Nel thread l’autore definisce l’assenza dei preimage dai descriptor una delle eccezioni di quel modello.
I vincoli tecnici indicati dall’autore
Il preimage deve essere lungo esattamente 32 byte, perché tutti e quattro i frammenti si compilano in OP_SIZE 32 OP_EQUALVERIFY seguito dall’operazione di hash e dal digest. Qualunque altra lunghezza sarebbe insoddisfacibile e il parser dovrebbe rifiutarla, indica il post.
Serve poi un marcatore esplicito: con sha256 e hash256 sia il preimage sia il digest sono lunghi 32 byte, quindi l’esadecimale grezzo sarebbe ambiguo. La stringa pubblica del descriptor continuerebbe a mostrare il digest, mentre quella privata (private=true) mostrerebbe il preimage, che andrebbe custodito e cifrato come una chiave WIF.
Sul piano della sicurezza, l’autore osserva che un preimage rivelato è pubblico, ma un Miniscript «sano» (sane) richiede già una firma su ogni percorso di spesa (proprietà s), quindi il solo preimage non basta a spendere.
Restano fuori i preimage appresi al momento della spesa, per esempio da una controparte in un HTLC, che continuerebbero a passare dai campi PSBT.
Le questioni ancora aperte
Al 27 ottobre 2026 il thread non ha risposte testuali: contiene solo il post iniziale, con 4 reazioni emoji, secondo l’API del forum. L’autore elenca cinque domande aperte.
- quale sintassi usare per il marcatore;
- se modificare il BIP379 o scrivere un BIP separato;
- se aggiungere a Bitcoin Core un RPC per inserire i preimage in una PSBT;
- se i dispositivi di firma hardware debbano gestire questi segreti o se resti una funzione solo per wallet software;
- se ci sia interesse a derivare i preimage in modo deterministico da materiale di chiavi.
Cosa aspettarsi
Per ora è una discussione preliminare: nel thread l’autore propone solo uno schema da discutere («Sketch/Draft»), senza un testo di BIP formale. Il passo successivo sarebbe la raccolta di feedback sulle questioni aperte.
Su temi affini BitcoinLive24 ha trattato il BIP139 per l’esportazione dei dati dei wallet, unito il 24 ottobre, e il progetto Lichen descritto nello stesso numero di Optech.
Scarica l’app BitcoinLive24 per seguire le novità sul protocollo.
Domande frequenti sui preimage nei descriptor
Che cos’è un preimage hash?
È il dato che, passato in una funzione di hash, produce il digest scritto nello script: chi lo conosce può soddisfare la parte hashlock di quella condizione di spesa. Nella proposta ha sempre una lunghezza di 32 byte, come indica il thread.
Oggi si può dare un preimage al wallet di Bitcoin Core?
Non direttamente: secondo Optech l’unico modo è inserirlo nei campi hash della PSBT, per esempio PSBT_IN_SHA256, con strumenti esterni.
La proposta è già approvata?
No: è un thread di discussione iniziale, e il BIP379 che dovrebbe estendere è a sua volta in stato Draft.
