Bitcoin come tribunale: la proposta di Lerner per pubblicare dati e litigarci sopra

• Cosa dice il paper, senza gergo
• Perché un bitcoiner dovrebbe alzare la testa
• Il confronto con OpenTimestamps, che è la domanda ovvia
• Le obiezioni che un bitcoiner deve fare
• Verdetto

C’è un modo per mettere dati su Bitcoin, far verificare a Bitcoin stesso se quei dati rispettano certe regole, e poter smentire chi li ha pubblicati se mente. Il 1° novembre Sergio Demian Lerner — fondatore di Rootstock, nome noto e discusso nella community — ha depositato su ePrint un preprint che descrive questo meccanismo: Verifiable Data on Bitcoin: FlatMerkle Commitments, Refutable Proofs, and FlatChecks, approvato il 4 novembre. Nessuna riga di codice, nessun test, nessun benchmark contro BitVM2. Solo un’idea, ma un’idea che merita di essere letta senza il riflesso condizionato.

§Cosa dice il paper, senza gergo

Tre pezzi che vanno tenuti insieme.

Il primo si chiama FlatMerkle. Di solito, per impegnarsi su molti dati, si costruisce un albero di hash e se ne pubblica la radice: costa poco, ma chi vuole dimostrare che un elemento c’è deve mostrare il ramo, e chi vuole dimostrare che l’albero è costruito male non ha strumenti. Lerner fa il contrario: prende i dati, li serializza in un’unica stringa di byte che contiene al proprio interno anche i nodi di hash, e pubblica l’impronta SHA-256 di tutta la stringa. Così hai due cose insieme — la prova che un elemento è incluso e la prova che il blob è malformato — entrambe di dimensione logaritmica. Ha anche tolto l’obbligo delle potenze di due, che costringeva a riempire i buchi con padding.

Il secondo è il legame con il publisher. I dati si mettono nell’annex di una transazione, oppure in un output (quattro volte più caro, ma almeno relayato da Bitcoin Core: l’annex oggi non lo è). La firma Taproot di chi pubblica, con un sighash type scelto apposta, lega la sua identità crittografica ai dati. Chi vuole contestare autentica la disputa con una compressione SHA-256 più il controllo della firma — tre compressioni se non c’è annex.

Il terzo è il FlatCheck, ed è la parte interessante. Le affermazioni sui dati, e le affermazioni su altre affermazioni, si pubblicano come messaggi di prova in due formati: uno semplice, che si smentisce rivelandolo intero, e uno “tracciato” che salva il risultato del verificatore a ogni passaggio, così un messaggio falso si smonta rivelando al massimo cinque elementi. Il formato è fissato dal contesto pubblico, così nessun messaggio si può leggere in due modi. Una catena di asserzioni su asserzioni si chiude in quattro elementi.

Il cuore teorico è una restrizione: funziona solo con verificatori localmente refutabili, cioè programmi in cui ogni rifiuto è testimoniato da un singolo controllo su poche parole di una traccia canonica. Restringendosi a quelli, una disputa costa qualche decina di hash e una verifica Schnorr: troppo per Script, poco abbastanza per un gioco di bisezione, uno script a blocchi stile BitVM2 o un garbled circuit. Nel FlatCheck chi propone pubblica solo la prova; la traccia esce solo se qualcuno contesta, e la disputa guarda esattamente quel controllo.

I numeri: un batch di 512 transfer di un L2 giocattolo costa 12.200 vbyte per essere asserito; una header-chain di 2.016 header costa 45.200 vbyte. Una disputa su un controllo locale costa 37.500 e 49.200 vbyte, una su una traccia malformata 77.100 e 99.800, indipendentemente dal numero di gruppi. La verifica di proof STARK è indicata come ulteriore applicazione.

§Perché un bitcoiner dovrebbe alzare la testa

Per una ragione semplice e per una meno semplice.

Quella semplice: non serve un soft fork e non serve un opcode nuovo. Tutto si fa con SHA-256, firme Schnorr, l’annex e transazioni grosse. Nessun token, nessuna governance, nessuna fondazione, nessun “comitato”. In un ecosistema dove ogni proposta seria si arenata sul consenso, questa parte è un pregio reale e va detto senza giri di parole.

Quella meno semplice: il paper non chiede a Bitcoin di diventare altro. Non c’è un sidechain, non c’è un rollup da lanciare, non c’è una chain da far crescere. Chiede a Bitcoin di fare ciò che già fa — conservare dati e ancorare impegni — e gli aggiunge sopra la capacità di arbitrare una lite. È l’unica direzione in cui “verifica su Bitcoin” ha senso senza raccontarsi favole.

§Il confronto con OpenTimestamps, che è la domanda ovvia

Qui bisogna essere onesti, perché la tentazione è dire “ennesimo modo di mettere roba on-chain”.

OpenTimestamps fa una cosa sola e la fa bene dal 2016: prende l’hash del tuo file, lo aggrega insieme a migliaia di altri in un albero di Merkle, mette la radice in una transazione e ti consegna una prova che il file esisteva prima del blocco X. Il dato resta fuori dalla chain, la verifica si fa contro l’header del blocco, il costo si ammortizza fino a diventare irrilevante. È il non-atto notarile più economico che Bitcoin abbia mai prodotto.

FlatMerkle/FlatCheck fa un’altra cosa: non dice “questo esisteva”, dice “questa affermazione su questo dato è vera, e se il publisher mente lo dimostro”. La differenza sta nell’avversario. Con OTS nessuno ha interesse a mentirti: il digest è il digest, e l’albero non si falsifica senza rompere SHA-256. Ma OTS non sa nulla del contenuto: se il file è una lista di saldi inventati, OTS te la certifica lo stesso, e il verificatore deve fidarsi di ciò che legge. Con FlatCheck il publisher è l’avversario, l’identità è legata alla firma, e la lite si risolve con una macchina di disputa.

Il prezzo di questa ambizione è di due ordini di grandezza: OTS costa centesimi per file, FlatCheck costa 12.200 vbyte per 512 transfer — circa 24 vbyte a transfer, ma tutti in una transazione sola — e fino a 100.000 vbyte per una disputa. OTS è anche già in produzione con client e calendar; FlatCheck è un preprint.

In sintesi: OTS è la scelta giusta per datare, FlatCheck serve quando devi dimostrare qualcosa sul dato, non solo datarlo. Non sono in competizione, si sovrappongono solo nel gesto di mettere un’impronta in una transazione.

§Le obiezioni che un bitcoiner deve fare

Prima: spazio nei blocchi. 45.200 vbyte per 2.016 header sono un blocco intero ogni volta che qualcuno aggiorna un light client. Con le fee a 10 sat/vB parliamo di 4,5 milioni di satoshi per asserzione. Chi paga? Il paper non lo dice.

Seconda: l’economia della disputa è assente. Non c’è un bond, non c’è un incentivo per il challenger, non è chiaro chi deve stare online per tutta la finestra. Un protocollo senza strato economico è griefable: si può aprire una disputa tanto per far spendere soldi all’altro. La sicurezza qui è crittografica, non economica, e la differenza conta.

Terza: il buco di disponibilità. “Il prover pubblica solo la prova” funziona se qualcuno conserva quella prova. Se nessuno la tiene, la contestazione non parte. La disputa su traccia malformata mitiga, non risolve.

Quarta: l’annex non è standard. La versione economica richiede che qualcuno la relati. Oggi dipendi dalla policy o dalla benevolenza di un miner.

Quinta: la classe di verificatori è stretta, e la parte STARK è asserita, non dimostrata. Un verificatore STARK non è banalmente localmente refutabile, e il paper non lo argomenta.

Sesta, la più politica: c’è stanchezza da BitVM. La community ha visto passare decine di “si può verificare X su Bitcoin” e quasi nessuno è diventato software. Un preprint di un autore solo, prolifico ma solo, senza implementazione e senza benchmark contro BitVM2, va collocato lì: nella categoria “da leggere”, non “da usare”.

§Verdetto

L’idea di restringere il verificatore a una classe smentibile con un solo controllo è la mossa giusta e la parte originale: è ciò che rende le dispute di dimensione costante invece che proporzionali al programma. L’uso dell’annex e del sighash per legare l’identità evita opcode nuovi, che è esattamente il modo in cui si fa una proposta che un bitcoiner può guardare senza irritarsi.

Ma è una primitiva, non un prodotto. Manca lo strato economico, manca il codice, manca la disponibilità dei dati, e manca la policy per l’annex. Tienila d’occhio se lavori su BitVM o su light client trust-minimized; se ti serve solo dimostrare che un file esisteva ieri, OpenTimestamps è ancora lì che funziona, gratis, e non ha bisogno di un tribunale.

Il preprint è su ePrint, numero 2026/2717, licenza CC BY: https://ia.cr/2026/2717