Che cos’è il Covenant?

Un Bitcoin Covenant è un tipo di transazione in cui l’output della transazione pone delle condizioni su come quel particolare output può essere speso in futuro. Questi vincoli di spesa si distinguono da quelli già esistenti nelle transazioni Bitcoin, dove per spendere un UTXO è necessaria una firma valida e una particolare pubkey.

I Covenant estendono lo script di Bitcoin in modo significativo; consentono casi d’uso come caveau sicuri, drivechain con pegged a 2 vie, riduzione della spesa per le commissioni, trading di opzioni decentralizzato, apertura di canali lightning in batch, canali lightning multiparty (3+) e altro ancora.

Invece di esaminare ogni proposta di implementazione del patto, le classificheremo in base alla funzionalità.

Generalizzato: Questi Covenant sono flessibili nelle applicazioni e nei casi d’uso abilitati. Il compromesso è che questa flessibilità comporta una maggiore complessità di implementazione e il potenziale di casi limite difficili.

Restrittivi: Come suggerisce il nome, questi Covenan si concentrano sull’abilitazione di una serie specifica di funzionalità e non su molto altro, come ad esempio le volte. La portata funzionale ridotta di queste proposte riduce anche le complessità di implementazione.

Un altro modo per classificare i Covenant è esaminare se e come i loro vincoli si propagano nel futuro. I Covenant che replicano se stessi e le loro regole nelle UXTO future a cui vengono inviati i fondi, senza limitazioni, sono detti ricorsivi.

Al contrario, quelli che applicano le loro regole per un solo “giro” di valore che scorre attraverso qualsiasi albero logico sia implementato sono chiamati non ricorsivi.

Possiamo anche considerare come questi covenant proposti verrebbero implementati; se sono basati su opcode, allora sarà necessario un soft fork per aggiungere qualsiasi nuova operazione allo script di Bitcoin.
I patti basati sulla firma – in cui le transazioni future (prefirmate) possono avere i loro attributi verificati costruendoli durante l’esecuzione dello script e confrontando i valori hash con OP_CHECKSIG – non richiederebbero un soft fork per essere implementati.

Il compromesso con i patti basati sulla firma è che tutte le possibili transazioni future dovrebbero essere costruite e firmate, il che significa che gli utenti dovrebbero impegnarsi a pagare tariffe e chiavi private specifiche.