Fermata #30 - CTV e il consenso in Bitcoin. Con Giacomo Zucco e Alekos Filini

Giacomo Zucco e Alekos Filini partono da CTV, il soft-fork proposto da Jeremy Rubin, per arrivare ad affrontare i temi dello sviluppo su Bitcoin e della sua macchina del consenso

---

Il testo che segue è un riassunto delle parti più importanti del video-confronto pubblicato. Naturalmente la trascrizione è molto più sintetica e meno accurata rispetto ai più articolati ragionamenti emersi nel dibattito. Per una maggior completezza d’approfondimento consiglio quindi di guardare l’intera intervista.

---

Da qualche settimana il dibattito interno alla comunità Bitcoin si concentra intorno alla proposta di soft-fork¹ BIP-119² presentata da Jeremy Rubin, anche conosciuta come CTV, Check Template Verify. Che cosa introdurrebbe l’eventuale attivazione di CTV e quali potrebbero essere le implicazioni? Il tema ha anche permesso di affrontare argomenti quali l’influenza dei core-dev³ sull’opinione della comunità internazionale e il ruolo dei miner nel meccanismo di consenso di Bitcoin.

A parlarne sono Giacomo Zucco, divulgatore, imprenditore, consulente e ricercatore Bitcoin - nonché uno dei bitcoiner italiani più conosciuti e apprezzati a livello mondiale - e Alekos Filini, open-source developer, già sviluppatore per Blockstream - azienda co-fondata da Adam Back, l’inventore di Hashcash citato nel white paper di Bitcoin da Satoshi Nakamoto - e ora per BDK, Bitcoin Dev Kit.

Cos’è Check Template Verify e cosa propone di introdurre in Bitcoin?

• Giacomo Zucco:

CTV è la proposta di trasformare uno degli operatori Opcode⁴ che non fanno niente - nello specifico OP_NOP4 - in una condizione che deve verificarsi, altrimenti il pagamento fallisce. In questo senso è un soft-fork: si prende un elemento che prima non falliva mai - una transazione - e ora invece fallisce se non viene soddisfatta una condizione specifica.

OP_NOP4 verrebbe ridefinito in OP_CHECKTEMPLATEVERIFY e consentirebbe di confrontare l’hash di una transazione con una serie di hash che rappresentano, per esempio, un elenco di transazioni concesse, un elenco di possibili destinatari whitelisted, di possibili importi, ecc. CTV sta a indicare un operatore che controlla che la transazione in oggetto risponda a un certo “template”, cioè a delle condizioni che sono state pre-organizzate.

• Alekos Filini

Nel dibattito si parla spesso di “covenant”: il concetto di covenant è quello di applicare delle restrizioni a ciò che si può fare con una transazione. Ma questo non è CTV, che in realtà è molto più limitato. Con CTV il requisito può essere che la transazione debba corrispondere a un dato hash. La condizione è: “Puoi spendere solo con una specifica transazione, identificata da uno specifico hash”. 

Implicazioni: Lightning Network. Quando apro un canale LN con qualcuno, sia io che la controparte dobbiamo essere online. Io voglio quindi avere la certezza che se apro un canale con Giacomo e lui sparisce, i fondi che ho messo nel canale mi ritornino indietro. Quindi chiedo a Giacomo di firmarmi una transazione che mi autorizza a riavere i miei fondi prima che io li depositi. Adesso funziona così. Con CTV - potendo mettere delle restrizioni su come vengono spesi i fondi - posso creare un indirizzo dove tengo già conto della possibilità di una transazione di rimborso: in pratica io posso spendere la transazione da solo senza avere la pre-firma di Giacomo, ma solamente se devo rimborsarmi.

Implicazioni: Congestion control. Mettiamo che un exchange debba gestire gli ordini di 100 clienti che vogliono ritirare i fondi: deve fare una transazione enorme inviando bitcoin a 100 persone in un colpo solo. Con CTV l’exchange può fare una prima transazione che crea un solo output - quindi molto più piccola e che fa risparmiare in commissioni - specificando che l’unico modo in cui quell’output è spendibile è facendo effettivamente la transazione alle 100 persone. In pratica posso fare un’unica transazione in cui poi mi obbligo a inviare i fondi a quelle 100 persone. Si chiama congestion control perché quando le commissioni sono alte l’exchange - invece che mandare la mega transazione - manda quella piccola dando una prova crittografica a tutte le 100 persone che il prelievo è stato già processato: quindi i clienti hanno la certezza che quei fondi arriveranno anche se non nel momento in cui la rete è congestionata.

Quali sono invece le obiezioni da muovere a CTV? Quali le criticità?

• Giacomo Zucco

Le principali obiezioni sono quattro:

1. Si è creato un dibattito sul fatto che i covenant possano essere usati per bloccare dei bitcoin su liste KYC⁵, whitelisting ecc. Ora in realtà anch’io mi sono abbastanza convinto che quasi tutti i casi d’uso di restrizioni di pagamenti per ragioni normative si possono già eseguire - e in modo più efficace - con un multisig. Questo perché i covenant ti costringono ad avere una lista fissa, e le liste di censura legale quasi mai sono fisse nel tempo, si aggiornano perché i coin si spostano, vengono aggiunte nuove blacklist o nuove whitelist. Quindi questa prima obiezione che è girata molto la considero abbastanza superata.

2. Un’altra obiezione è che ci sono altri modi di fare covenant. Alcuni casi d’uso che permettano canali multiparty non interattivi sono per esempio garantiti da ANYPREVOUT con il discorso di Eltoo. Ci sono adesso molte proposte che competono per casi d’uso simili a quelli di CTV. Si potrebbe dire: ‘Facciamone una e poi le altre eventualmente dopo perché CTV è molto più avanzata e testata, le altre sono più early stage”. Un fork di consenso di Bitcoin però è un evento traumatico, importante, lento e con frizioni. Non è vero che si possono fare tanti soft-fork, quindi c’è una competizione reale tra le proposte.

3. Ci sono cose più importanti da fare rispetto all’introduzione dei covenant. In un’ottica in cui non possiamo fare un soft-fork al mese, Cross Input Signature Aggregation (CISA) è molto più importante per la privacy in Bitcoin, che a sua volta è più importante dei covenant.

4. Con CTV si possono aprire un sacco di canali LN in maniera compatta con una sola transazione, però non si possono chiudere. Quindi si potrebbe creare un’asimmetria tra i corsi d’apertura e i corsi di chiusura che potrebbe portare poi a un’enorme congestione in fase di chiusura.

• Alekos Filini

A me i covenant piacciono e più penso a cosa ci si potrebbe fare, alle possibilità che potrebbero aprire, più mi rendo conto che CTV è un po’ limitato. Secondo me anche Jeremy Rubin si rende conto che è limitato ma per lui si dovrebbero fare soft-fork più spesso. Quindi magari pensa: “Facciamo CTV oggi e domani facciamo una cosa migliore”. La mia impressione è che nella community degli sviluppatori si stia tentando di bloccare CTV non tanto per i covenant - che sono un concetto che piace in generale ai developers - ma perché tutti pensano: “Aspettiamo un attimo, vediamo cos’altro riusciamo a inventare, vediamo che altre idee ci vengono”.

Sono comunque d’accordo sul fatto che CISA potrebbe essere più importante di CTV, ma non mi opporrei comunque a un soft-fork che aggiunge covenant.

Il tema legato a quanti soft-fork si potranno ancora fare è molto discusso: c’è chi pensa che il Layer 1, la blockchain di Bitcoin, debba man mano essere lasciato stare per spostare l’innovazione sui layer successivi, come Lightning Network: la cosiddetta “ossificazione” della blockchain. C’è invece chi pensa che lo sviluppo debba continuare anche sul Layer 1. Come vi posizionate in merito?

• Giacomo Zucco

I pro dell’ossificazione sono di tipo pratico: l’evoluzione che abbiamo avuto su Internet è stata possibile nonostante le limitazioni del livello base IPv4, che di fatto è immutato dagli anni ‘80. Anche il livello subito sopra, TCP, non ha una storia di cambiamenti recenti molto importanti. I livelli più bassi sono livelli che sono rimasti statici. Questo ha permesso una costruzione di Internet che si è basata su fondamenta stabili. Quando hai un sistema stratificato se i layer alla base stanno fermi è possibile costruire molte cose sopra. Come una casa: un edificio ha le fondamenta ferme, poi le pareti portanti che non si toccano, poi le pareti non portanti che ogni tanto si buttano giù, poi l’intonaco, i mobili e i soprammobili. Se cambi le fondamenta con la stessa velocità dei soprammobili hai dei problemi seri.

In Bitcoin questo concetto viene interfacciato con quello di resistenza ad attività di censura e corruzione del protocollo. Se pensiamo a Bitcoin come a uno strumento che verrà osteggiato da entità con la potenza di uno stato nazionale - che potranno comprare developer, hashing power, opinione pubblica - allora stabilizzare i primi livelli serve anche per rendere la base invulnerabile agli attacchi. C’è solo un modello di governance che non si può corrompere ed è la vittoria continua dello status quo. Se un protocollo non si può cambiare perché lo status quo resiste, il protocollo non viene violato.

• Alekos Filini

Concordo sul fatto che un protocollo è difficile da cambiare se è difficile da corrompere. Non sono del tutto d’accordo con il ragionamento delle fondamenta: essendo che i soft-fork sono retro-compatibili non cambiano davvero il sottostante. Aggiungono cose al sottostante che i layer superiori possono decidere di ignorare.

Io vedo più di Giacomo il rischio che se ossifichiamo tutte le fondamenta rischiamo di perdere talento. Nell’ambiente tech in generale c’è tanta concorrenza e così facendo rischiamo di avere nuove generazioni di developer che si trovano davanti a uno strumento dove non è possibile innovare al layer base e che quindi possano essere più stimolati da altri settori.

L’altro punto è che secondo me serve sempre un team che sia in grado di mettere mano al codice di Bitcoin Core. Se non si può più innovare le nuove generazioni avranno zero esperienza specifica sul codice di consenso di Bitcoin Core.

Il dibattito su CTV ha reso nuovamente attuale una frequente critica a Bitcoin: l’influenza che i core-dev hanno sulla comunità (Jeremy Rubin, che ha proposto CTV, è un core-dev, nda). Secondo voi questo può rappresentare un problema concreto?

• Giacomo Zucco

L’influenza c’è ed è inevitabile: uno dei confronti che dobbiamo fare è però tra il potere d’influenza dei core dev e quello dei miner: secondo me non c’è paragone nella preferibilità del primo: se i core dev hanno un’opinione che è considerata sbagliata dalla maggioranza economica, quest’ultima assume degli altri sviluppatori per fare altro. Se io sono un dev e non sono d’accordo con gli altri, creo un client Bitcoin alternativo. Inoltre anche all’interno del gruppo dei core dev c’è un’enorme varietà di opinioni anche molto accesamente contrapposte.

E’ un problema che può essere inteso in due direzioni: una governance di veto - se i core dev non concordano su un’idea allora questa non passa - e una governance di spinta - se i core dev sono d’accordo e convincono anche altri allora magari l’idea riesce a passare. A me spaventa molto di più la seconda.

Molti non erano d’accordo - ad esempio Luke Dashjr - sull’attivazione di Taproot⁶ tramite Speedy Trial, poi però i core dev hanno spinto l’attivazione con questa modalità e alla fine la cosa è passata. Questo tipo d’influenza è molto più pericolosa da un punto di vista di futura ipotesi di corruzione. Costa poco a un governo rapire i figli di qualche core dev famoso e fargli fare le modifiche che vuole. L’autorità come veto è molto meno pericolosa perché al peggio porta all’ossificazione, come dicevamo prima.

• Alekos Filini

E’ un problema che esiste ma è anche una cosa inevitabile. Pochissime persone al mondo sono capaci di verificare il codice di Bitcoin Core e quindi la stragrande maggioranza delle persone deve affidarsi a qualcun altro che faccia quel lavoro per loro.

Il precedente che è stato creato con lo Speedy Trial di Taproot non è bello, è un esempio del gruppo di core dev che spinge la sua attuazione, ma è anche un caso in cui l’unica discussione su Taproot era relativa a come arrivare alla sua attivazione, non se farla o meno. Tutti erano d’accordo sulla bontà di Taproot, il dissenso era solo sulle modalità di attuazione. Questo processo non avviene quando si parla di modifiche al consenso: se il problema fosse stato: “Attiviamo o no Taproot?” non credo che i core dev avrebbero forzato la mano.

L’attivazione del soft-fork tramite Speedy Trial è stata inizialmente proposta anche per CTV dallo stesso Jeremy Rubin, che recentemente ha fatto marcia indietro.

Quali sono le criticità di uno Speedy Trial in CTV e come si collegano con il ruolo dei miner in Bitcoin? Qual è il potere che esercitano?

• Giacomo Zucco

 Taproot era una cosa che tutti inequivocabilmente approvavano, non c’erano sostanziali opposizioni, c’era anzi molta attesa. Invece su CTV ci sono delle contrarietà, seppur lievi. In questo caso, dunque, lo Speedy Trial è ancora peggiore. Ma secondo me lo Speedy Trial era un problema anche in Taproot.

Il mining viene implementato da Satoshi Nakamoto con una funzione precisa: quella di dare ai miner la governance sulla cronologia delle transazioni valide. La validità di queste transazioni è stabilita da ogni nodo e l’unica cosa che possono fare i miner è decidere la sequenzialità cronologica tra le transazioni già valide. Questo è un potere forte che può essere utilizzato per censura temporanea o per double-spending ma non può cambiare le regole di Bitcoin. I miner possono rallentare Bitcoin, censurare l’approvazione di transazioni o tentare una truffa di double-spending. Questa cosa crea problemi limitati e gestibili.

Speedy Trial nasce perché se dobbiamo fare un soft-fork - con gli sviluppatori che sono tutti d’accordo e lo sviluppano e i nodi concordi che lo installano - prima di mandarlo in produzione dobbiamo essere sicuri che i miner ne siano consapevoli, perché se non si aggiornano creano blocchi invalidi e perdono la ricompensa della coinbase transaction. Quindi l’idea dello Speedy Trial nasce come tutela nei confronti dei miner.

Chi ha capito male questo meccanismo ha pensato che questo fosse un modo per i miner di votare se volessero l’implementazione del protocollo o meno. Non è così. L’idea che i miner possano decidere i cambiamenti del protocollo è pericolosa. Il concetto di Speedy Trial è un problema perché va in questa direzione⁷.

• Alekos Filini

Io non la vedo come Giacomo. A me piaceva lo Speedy Trial per Taproot perché l’idea era la seguente: “Facciamo lo Speedy Trial: è vero che i miner possono decidere, hanno diritto di veto e possono quindi non far partire inizialmente il soft-fork, ma se questo accade poi tramite BIP-8 ne forziamo comunque l’attivazione futura”.

Quindi tramite il voto dello Speedy Trial il soft-fork può partire prima ma in ogni caso successivamente verrebbe attivato ugualmente con UASF⁸.

---

Come acquistare Bitcoin?

Personalmente, quello che reputo come il servizio migliore è Relai. Per acquistare bitcoin risparmiando lo 0,5% in commissioni potete usare il codice “FEDERICO”.

Si tratta di un’applicazione sviluppata da un’azienda svizzera che applica una politica di KYC light: a differenza dei grandi exchange non richiede registrazioni o dati personali, tutto che serve per comprare è il proprio IBAN. E’ ottimale per impostare dei piani di accumulo.

Una delle migliori caratteristiche è il servizio non-custodial. Gli euro bonificati a Relai vengono convertiti automaticamente in bitcoin e trasferiti su un wallet di cui è l’utente ad avere il controllo. I grossi exchange, al contrario, non forniscono le chiavi private ai clienti. In più Relai non vende centinaia di inutili criptovalute, ma solo bitcoin.

NOTA - Questo NON è un messaggio pubblicitario. Relai è un servizio che utilizzo personalmente e che reputo tra i migliori sul mercato in termini di affidabilità, sicurezza e facilità d’uso. Lo consiglio spesso ad amici e parenti. Cosa ci guadagno? Quello che fanno guadagnare i referral code. In questo caso se acquistate con il codice “FEDERICO” risparmiate lo 0,5% sulle commissioni e io ricevo (in bitcoin) lo 0,5% dell’importo che avete deciso di investire.

---

Online su YouTube il terzo video con Massimo Musumeci

Di seguito la terza puntata della nuova serie di video-approfondimenti live dedicati al tema della settimana di Bitcoin Train sul canale YouTube di Massimo Musumeci, fisico, ricercatore Bitcoin ed esperto di privacy e sicurezza informatica.

Appuntamento tutti i lunedì alle ore 17:00.

1. Soft-fork: è un cambiamento del protocollo di Bitcoin in cui vengono aggiunte delle regole. Blocchi che prima del soft-fork venivano considerati validi dai nodi, dopo vengono considerati non validi. L’hard fork è la situazione opposta, blocchi che prima venivano considerati non validi, dopo sono considerati validi. Un hard fork rende i vecchi nodi impossibilitati a seguire la blockchain, in un soft-fork si può avere comunque una parte dei vecchi nodi che continuano a usare Bitcoin funzionalmente.

2. Bitcoin Improvement Proposal, uno standard per proporre modifiche o implementazioni al codice di Bitcoin.

3. Core-dev(elopers): gli sviluppatori che hanno contribuito e contribuiscono al codice di Bitcoin Core, il client più diffuso per far girare un full-node Bitcoin ed entrare quindi a far parte della rete.

4. Operatori propri del linguaggio di scripting di Bitcoin.

5. KYC: Know Your Customer, processo di riconoscimento dell’identità attuato in particolare da aziende che offrono servizi finanziari o da governi. Pratiche, dunque, che riducono la privacy.

6. Taproot: l’ultimo soft-fork avvenuto in Bitcoin. Lo ha spiegato Federico Tenga a Bitcoin Train nella fermata #10.

7. Perché in caso di voto negativo dei miner durante lo Speedy Trial, l’attivazione del soft-fork viene temporaneamente sospesa.

8. UASF: User Activated Soft-Fork. Meccanismo attivato dai full-node in un periodo di tempo specifico che consente a Bitcoin di passare a un nuovo sistema di regole di consenso.