Timelock relativo

BIP-68 ha dato un significato di consenso al campo sequence di quattro byte presente su ogni input, ma solo per le transazioni che dichiarano la versione 2 o superiore. La regola è arrivata alla rete tramite un deployment versionbits di BIP-9 sul bit 0, aperto il 1º maggio 2016 e distribuito insieme a BIP-112 e BIP-113. Se conservi bitcoin bloccati dietro uno script di recupero o di canale, il conto alla rovescia riparte ogni volta che quei bitcoin si muovono.

Come funziona

I timelock relativi sono codificati nel campo sequence, e il bit più alto decide se succede qualcosa.

Con il bit 31 impostato, il campo non ha alcun significato di consenso e l'input può finire in qualsiasi blocco. Con il bit 31 azzerato, i nodi applicano al campo la maschera 0x0000ffff e leggono i 16 bit rimasti come periodo di attesa. Il bit 22 sceglie l'unità. Se è azzerato, il numero conta i blocchi, e BIP-68 indica l'intervallo da 0 a 65.535 blocchi, che definisce 1,25 anni. Se è impostato, il numero conta periodi di 512 secondi, un intervallo che il BIP indica come inferiore a 33.554.431 secondi, circa 1,06 anni. Il curioso 512 fu scelto perché i blocchi arrivano all'incirca ogni 600 secondi, così entrambe le unità coprono un arco simile con gli stessi 16 bit.

Un input che porta un valore n basato sui blocchi può essere incluso n blocchi dopo il blocco che ha minato l'output che spende, quindi un valore di 1 si esaurisce già nel blocco immediatamente successivo, non in quello dopo. I valori basati sul tempo non vengono mai confrontati con un orologio. BIP-68 misura dal median time past del blocco precedente a quello che ha minato l'output, e rispetto al median time past del blocco precedente a quello in costruzione, e BIP-113 definisce quel valore come la mediana degli ultimi 11 timestamp di blocco. Si usano le mediane e non i timestamp grezzi perché le regole di consenso garantiscono che la mediana avanzi in modo monotono, il che impedisce a un miner di incassare commissioni extra mentendo sull'ora di un blocco.

Contano due eccezioni. Le regole non si applicano mai al campo sequence dell'input di una transazione coinbase. E sei posizioni, dalla 16 alla 21, sono state lasciate indefinite perché un futuro soft fork possa alzare la granularità o il tetto senza un nuovo campo.

Dove lo vedi

BIP-112 applica un timelock relativo tramite un contratto di deposito a garanzia che scade 30 giorni dopo che vi sono stati versati i fondi.

Alice, Bob e un agente di deposito a garanzia condividono uno script 2-di-3. Due qualsiasi possono spendere in qualsiasi momento; dopo il ritardo Alice firma da sola. Il BIP è netto sul momento di avvio: il conto alla rovescia non parte finché non si conferma il pagamento all'indirizzo di deposito a garanzia. È tutta qui la differenza rispetto a una scadenza di calendario, ed è il motivo per cui un solo script serve ogni nuovo deposito a garanzia senza riscritture.

La regola condiziona anche il comportamento delle mempool. Il controllo dei sequence lock di Bitcoin Core gira sull'altezza del blocco successivo e non su quella della punta attuale, e tratta una transazione madre non confermata come se dovesse confermarsi in quel blocco, così una spesa la cui attesa scade con il blocco in arrivo viene ritrasmessa poco prima di essere spendibile. Fuori da quel margine non c'è coda: una spesa non matura è invalida, non in sospeso.

Timelock relativo vs OP_CHECKSEQUENCEVERIFY

Un timelock relativo risiede sull'input di transazione, mentre OP_CHECKSEQUENCEVERIFY risiede nello script dell'output e verifica che un input che lo spende ne rispetti uno.

BIP-68 da solo non vincola nessuno. Chi costruisce la spesa sceglie il valore sequence, quindi un ritardo scritto lì è una preferenza, non una regola su cui una controparte possa fare affidamento. BIP-112 colma la lacuna rendendo il campo leggibile dallo script: l'opcode fallisce se la versione della transazione è inferiore a 2, se il sequence dell'input ha impostato il flag di disattivazione, se i due valori non concordano sull'unità o se il numero sullo stack supera il sequence mascherato. Un valore sullo stack che porta esso stesso il flag di disattivazione fa comportare l'opcode come un NOP, uno spazio lasciato di proposito per un futuro soft fork. Solo con questi controlli in vigore l'attesa diventa qualcosa su cui un agente di deposito a garanzia o un peer Lightning possono contare.