Custodire Bitcoin non significa soltanto proteggere una seed phrase o scegliere tra hot wallet e hardware wallet. In alcuni casi si può voler aggiungere una regola ulteriore: impedire che determinate monete vengano spese prima di una data, oppure prima che sia trascorso un certo numero di blocchi. Questa funzione prende il nome di timelock, cioè blocco temporale.
Il timelock non è un conto vincolato gestito da un exchange e non è una promessa fatta da un intermediario. È una condizione incorporata nella transazione o nello script Bitcoin. Se la condizione non è ancora soddisfatta, la rete non considera valida la spesa, anche se qualcuno possiede la chiave privata corretta.
La funzione può essere utile per costruire procedure di custodia più prudenti, ma introduce anche complessità. Un errore nella configurazione può rendere i fondi inutilizzabili per un periodo molto lungo o creare una falsa sensazione di sicurezza. Per questo è importante distinguere il funzionamento tecnico dai casi d’uso e dai rischi operativi.
Che cos’è un timelock Bitcoin
Un timelock è una regola che ritarda la possibilità di spendere un output Bitcoin. La regola può riferirsi a un momento del tempo oppure all’avanzamento della blockchain. In termini pratici, il proprietario può avere già una chiave privata valida, ma la transazione resta non spendibile fino a quando non viene raggiunta la condizione prevista.
Esistono due famiglie principali di blocchi temporali:
- Timelock assoluto: la spesa è possibile soltanto a partire da una data o da un’altezza di blocco specifica.
- Timelock relativo: la spesa diventa possibile dopo che è trascorso un certo intervallo dal momento in cui l’output è stato confermato nella blockchain.
Questa distinzione è importante. Un blocco assoluto può essere collegato a una scadenza fissata in anticipo. Un blocco relativo, invece, parte dal momento in cui una determinata moneta viene inclusa in un blocco e segue quindi la storia effettiva dell’output.
Il timelock non congela necessariamente un intero wallet. Di norma riguarda specifici output, cioè singole unità di Bitcoin risultanti da transazioni precedenti. Un wallet può contenere contemporaneamente fondi liberi e fondi soggetti a condizioni temporali differenti.
nLockTime, CLTV e CSV: tre concetti da non confondere
Nel linguaggio Bitcoin si incontrano diverse funzioni collegate al tempo. Sono simili soltanto in apparenza e svolgono ruoli differenti.
nLockTime è un campo della transazione. Indica che una transazione non dovrebbe essere inclusa in un blocco prima di una determinata altezza oppure prima di una certa soglia temporale. Da solo, però, non equivale sempre a una protezione permanente dei fondi: il comportamento dipende dalla transazione, dagli input e dalle regole applicabili. È spesso utilizzato per coordinare una spesa futura o per costruire transazioni prefirmate.
CHECKLOCKTIMEVERIFY, spesso abbreviato in CLTV, è un’operazione di script che impone una condizione assoluta. L’output può essere speso solo con una transazione che rispetta il limite temporale previsto. La condizione può essere espressa usando un’altezza di blocco oppure un riferimento temporale, ma i due formati non sono intercambiabili.
CHECKSEQUENCEVERIFY, abbreviato in CSV, impone invece un limite relativo. La spesa diventa valida dopo un certo intervallo a partire dalla conferma dell’output precedente. È la base di molte costruzioni in cui una strada di recupero diventa disponibile soltanto dopo un’attesa.
Esiste anche una differenza tra il tempo indicato come data e il tempo indicato come altezza di blocco. Una data non corrisponde a un orologio perfettamente preciso: i blocchi non vengono prodotti a intervalli identici. Quando la precisione operativa è importante, bisogna considerare questa variabilità e non trattare una previsione dell’altezza di blocco come un appuntamento garantito al minuto.
Come si usa nella custodia di Bitcoin
Un timelock può essere inserito in procedure di custodia che richiedono una separazione tra possesso della chiave e possibilità immediata di spesa. L’idea generale è creare una o più condizioni alternative, ciascuna con requisiti diversi.
Un esempio concettuale è un output con due percorsi:
- un percorso principale, che consente la spesa con più chiavi o con una firma prevista;
- un percorso di recupero, che diventa disponibile soltanto dopo un intervallo temporale.
Questo schema può ridurre il rischio di una perdita immediata in alcuni scenari, per esempio quando si vuole prevedere una procedura di emergenza. Non significa però che il timelock riconosca automaticamente un erede, notifichi qualcuno o trasferisca i Bitcoin senza una transazione. Qualcuno deve conoscere l’esistenza della struttura, possedere le informazioni necessarie e sapere come costruire e firmare la spesa.
Un altro uso riguarda le transazioni prefirmate. È possibile preparare una transazione che potrà essere trasmessa solo in un momento successivo, mantenendo nel frattempo i fondi in una configurazione definita. Questo approccio richiede però un controllo rigoroso delle transazioni, degli input, delle fee e delle eventuali possibilità di sostituzione.
In tutti questi casi, il timelock è una regola di protocollo. Non è sufficiente scrivere la data in un documento o impostare un promemoria nel wallet: la condizione deve essere effettivamente incorporata nella struttura che blocca la spesa.
Un esempio pratico, senza confondere il tempo con la sicurezza
Immaginiamo un output soggetto a un blocco relativo. La regola stabilisce che un determinato percorso di spesa sia possibile solo dopo un certo numero di blocchi dalla conferma dell’output. Subito dopo il deposito, la chiave prevista per il recupero non è sufficiente. Quando la blockchain ha raggiunto l’intervallo richiesto, la transazione di recupero può diventare valida.
Questo esempio non implica che il wallet mostri sempre il saldo nello stesso modo. Un software non compatibile potrebbe visualizzare l’output come non spendibile, mostrarlo senza indicare correttamente il percorso temporale o non riconoscerlo affatto. Il problema non è necessariamente nella blockchain, ma nella descrizione del wallet e nel modo in cui il software interpreta lo script.
Prima di utilizzare una struttura di questo tipo servono quindi almeno:
- una descrizione precisa dello script o del wallet policy;
- la documentazione delle chiavi e dei percorsi di spesa;
- un modo per monitorare gli output senza esporre le chiavi private;
- una procedura verificata per creare, firmare e trasmettere la transazione;
- un controllo delle commissioni e della validità temporale della transazione.
La prova dovrebbe essere eseguita con importi limitati e in un ambiente separato dal patrimonio principale. Non basta verificare che il wallet generi un indirizzo: occorre controllare anche che il recupero previsto funzioni davvero e che la transazione non possa essere trasmessa prima o dopo il momento desiderato per un errore di configurazione.
Rischi ed errori da evitare
Il primo rischio è rendere i fondi temporaneamente o permanentemente non spendibili. Un’altezza di blocco inserita in modo errato, una data interpretata con un formato diverso o una durata relativa confusa con una durata assoluta possono modificare completamente il risultato.
Il secondo rischio è perdere le informazioni necessarie al recupero. La seed phrase può non essere sufficiente se la struttura utilizza script, percorsi di derivazione, policy multifirma o descrittori specifici. Chi conserva soltanto le parole di recupero, senza documentare la configurazione, potrebbe non riuscire a ricostruire il wallet corretto.
Il terzo rischio riguarda la compatibilità. Non tutti i wallet supportano allo stesso modo CLTV, CSV, transazioni prefirmate o policy avanzate. Un indirizzo visualizzato da un’interfaccia non dimostra da solo che quella stessa interfaccia sappia recuperare e spendere correttamente l’output.
Occorre inoltre considerare le commissioni. Una transazione preparata molto tempo prima potrebbe diventare poco competitiva quando sarà trasmessa. Se il formato della transazione e le regole applicabili lo consentono, possono esistere strategie di sostituzione o di aumento della fee, ma devono essere previste in anticipo. Una transazione prefirmata non è una garanzia assoluta di esecuzione futura.
Un ulteriore errore consiste nel pensare che il timelock protegga da ogni furto. Se esiste un percorso immediato e un aggressore ottiene le chiavi necessarie per quel percorso, il ritardo alternativo potrebbe non offrire alcuna protezione. Se invece il timelock è troppo rigido, può ostacolare il proprietario legittimo proprio durante un’emergenza.
Timelock e sicurezza operativa
Una configurazione con blocco temporale dovrebbe essere trattata come un piccolo sistema, non come una semplice impostazione del wallet. Servono una mappa delle chiavi, una copia della policy, istruzioni comprensibili e verifiche periodiche. Le informazioni operative devono essere sufficienti per il recupero, ma non devono contenere segreti privati nello stesso luogo.
È utile separare almeno tre elementi: la conoscenza dell’esistenza dei fondi, le informazioni pubbliche necessarie per monitorarli e le chiavi private necessarie per spenderli. Un wallet watch-only può aiutare a controllare gli output senza esporre la seed phrase, ma non sostituisce la documentazione della policy né la prova di recupero.
La verifica dovrebbe includere la costruzione di una transazione di prova, il controllo indipendente della condizione temporale e l’uso di strumenti compatibili con lo script adottato. Quando la struttura è complessa, anche un singolo dettaglio sbagliato può cambiare chi può spendere, quando può farlo e con quali firme.
Quando il timelock non è la soluzione giusta
Un timelock non risolve automaticamente i problemi di backup, perdita della seed phrase, furto delle chiavi o assenza di istruzioni. Non sostituisce un hardware wallet, una procedura di verifica o un piano di successione. In alcuni casi aggiunge soprattutto complessità, senza offrire un vantaggio proporzionato.
Per una custodia ordinaria, la priorità resta comprendere dove si trovano gli output, come vengono recuperati e quali procedure consentono di spendere in sicurezza. Le condizioni temporali hanno senso quando esiste un’esigenza precisa, documentata e testabile. Se la struttura non può essere spiegata e verificata anche a distanza di tempo, il ritardo imposto dal protocollo può trasformarsi in un ostacolo.
Il valore del timelock sta quindi nella sua natura deterministica: una regola scritta nello script può limitare il momento della spesa senza affidarsi a un intermediario. Proprio per questo, però, non lascia spazio a interpretazioni benevole. Prima di adottarlo bisogna sapere esattamente quali output vengono bloccati, quali chiavi servono, quale evento fa partire il conteggio e come verrà effettuato il recupero quando la condizione sarà soddisfatta.
