Guarda l'intero episodio:
Da BDK a Bitcoin Core: un salto nel vuoto
Daniela Brozzoni arriva a Bitcoin Core dopo un periodo di frizioni nel team di BDK, il Bitcoin Development Kit su cui aveva lavorato per anni fino a diventarne maintainer. La scelta di passare al cuore dello sviluppo del protocollo non è stata indolore: per circa tre mesi ha lavorato senza stipendio, attingendo ai risparmi, prima di ricevere due grant da Open Sats e Human Rights Foundation. Un ingresso costruito sulla reputazione accumulata negli anni precedenti nell’ecosistema open source bitcoiner.
Il lavoro quotidiano su Bitcoin Core è lontano dall’immagine romantica del genio solitario che riscrive le regole del denaro. Si tratta principalmente di revisione del codice altrui – le cosiddette pull request – e di analisi delle issue segnalate dagli utenti. Le prime settimane, racconta Brozzoni, si leggono le modifiche degli altri senza riuscire a trovare errori, anche quando esistono. Con il tempo l’occhio si affina.
Il maintainer non è il capo: come funziona davvero la governance
Uno dei punti più chiariti nell’intervista riguarda la distinzione tra developer e maintainer, spesso confusa nel dibattito pubblico. Nel mondo open source tradizionale il maintainer ha un ruolo di comando. In Bitcoin Core funziona diversamente.
Il fatto che il maintainer abbia il potere di cliccare sì o no non vuol dire che il maintainer stia decidendo. Il maintainer è semplicemente questo riflesso di cosa vuole l’intero progetto di Bitcoin Core o una parte degli sviluppatori.
Il maintainer in Bitcoin Core svolge un ruolo quasi di supporto operativo: gestisce i task noiosi che rendono fluido il lavoro del team, media i conflitti, applica le decisioni già maturate nella comunità degli sviluppatori. Le vere scelte, soprattutto quelle che riguardano le regole di consenso – il cuore del protocollo – vengono prese collettivamente. E quando si tratta di softfork o hardfork, il perimetro decisionale si allarga ulteriormente all’intera comunità dei nodi.
OP_RETURN e la proposta di Peter Todd: di cosa si discute
Il dibattito che ha spaccato la comunità negli ultimi anni ruota attorno a una pull request di Peter Todd su GitHub: la rimozione del limite di 80 byte al campo OP_RETURN nelle mempool policy di Bitcoin Core. OP_RETURN è un campo creato appositamente per inserire dati non finanziari nelle transazioni Bitcoin, una sorta di cestino della spazzatura ufficiale per chi vuole scrivere dati sulla blockchain senza creare output spendibili.
La distinzione fondamentale da tenere a mente è quella tra regole di consenso e regole di mempool policy. Le prime definiscono la validità assoluta di una transazione per tutta la rete. Le seconde sono regole più restrittive che ogni nodo applica alla propria mempool – il limbo in cui le transazioni attendono di essere minate – e possono variare da nodo a nodo. Se una transazione non supera il filtro di mempool, non viene propagata alla rete, ma può comunque essere consegnata direttamente a un miner.
La ratio della proposta di Todd, sostenuta anche da Gregory Maxwell, stava nel risolvere un problema concreto: chi vuole inscrivere dati on chain aggira il limite usando le cosiddette fake public keys, ovvero indirizzi Bitcoin che non corrispondono a nessuna chiave reale. Questo approccio gonfia l’UTXO set – il registro di tutti gli output non spesi che ogni nodo deve conservare in memoria – con voci che non potranno mai essere rimosse, perché quei Bitcoin non saranno mai spesi. Allargare OP_RETURN significherebbe incanalare questa pratica verso un campo che non inquina l’UTXO set.
Il nodo della discordia: filtri, miner e decentralizzazione
La risposta della fazione contraria, rappresentata in larga parte dagli utilizzatori di Bitcoin Knots, è che qualsiasi allentamento dei filtri equivale a incentivare l’uso non monetario della blockchain, indipendentemente dalla modalità tecnica. Il dibattito si è incendiato anche perché le due fazioni parlano linguaggi diversi: una tecnica, l’altra filosofica e sociale.
Brozzoni illustra un argomento tecnico spesso trascurato nel dibattito pubblico: la desincronizzazione dei filtri di mempool tra i nodi danneggia il funzionamento del compact block relay, il protocollo che permette ai blocchi di propagarsi rapidamente nella rete. Quando una parte della rete non conosce le transazioni incluse in un blocco perché le ha filtrate, il broadcast rallenta. E questo rallentamento avvantaggia le mining pool più grandi.
Non voglio un Bitcoin che sia completamente legale, assolutamente no. Bitcoin è già bellissimo così perché è utile così per me e per un sacco di persone che hanno le mie stesse idee su come dovrebbe funzionare il denaro.
A questo si aggiunge la questione degli out-of-band payment: le transazioni consegnate direttamente ai miner, bypassando la rete, generano un flusso di ricavi extra accessibile solo alle pool con hashrate sufficiente a rendere il servizio attraente per gli utenti. Solo chi mina una quota significativa dei blocchi può offrire garanzie di conferma ragionevoli. La pressione verso la centralizzazione del mining, in questo scenario, cresce.
La governance dei nodi come ultimo baluardo
Al di là del merito tecnico, l’intervista con Brozzoni mette in luce una tensione strutturale nella governance di Bitcoin: la difficoltà di trovare uno spazio di discussione condiviso tra sviluppatori e utenti. GitHub è percepito come territorio degli sviluppatori, i commenti degli utenti vengono nascosti o rimossi quando non sono tecnici. Le mailing list sono ostili ai non esperti. Twitter è inadatto all’argomentazione tecnica.
La risposta ultima, ricorda Brozzoni, sta nei nodi. Sono gli operatori di nodo – non i developer, non i maintainer – a scegliere quale software eseguire e quindi quali regole applicare. Chi fa girare un nodo ha voce in capitolo sulla direzione del protocollo in modo diretto e concreto, molto più di qualsiasi discussione su GitHub.
Guarda l’intero episodio su YouTube
Share on X
