Binary Money e Bitcoin – le origini

Spread the love

Mi intriga da morire il denaro.

Nel senso: cos’è il denaro?

Si OK banconote, monete, bancomat, e-commerce… ma mentre è chiaro che il denaro sia una rappresentazione del valore reale delle cose da scambiare nelle transazioni, meno chiaro può essere il perché un pezzo di carta da pochi euro (fatto conto delle materie prime e le lavorazioni, come stampa, filigranatura, inserimento di ologrammi, …) vale in realtà 500 euro, perché solo i governi possano battere moneta, perché lo fanno, quando devono astenersi dal farlo, o farlo in sovrabbondanza e perché i falsari vanno in galera e perché tutti ci crediamo.

Questa riflessione arriva a puntino mentre ho iniziato a leggere il saggio di David Wolman, The End of Money, Laterza.

Un’idea originale è stata quella del matematico cinese Wei Dai che descrisse così il bmoney (denaro binario o digitale) in questo post in un forum nel 1998 che qui traduco integralmente in italiano.

 

Sono affascinato dalla cripto-anarchia di TIm May. Diversamente dalle comunità tradizionalmente associate alla parola “anarchia”, in una cripto-anarchia il governo non viene distrutto temporaneamente, bensì è permanentemente proibito e permanentemente non necessario. E’ una comunità nella quale la minaccia della violenza non impotente, perché la violenza è impossibile e la violenza è impossibile perché i suoi partecipanti non possono essere ricondotti ai lori veri nomi o alla loro posizione fisica.

FInora non è chiaro, nemmeno in teoria, come una comunità del genere possa funzionare. Una comunità è definita dalla cooperazione dei suoi partecipanti e una cooperazione efficiente richiede un mezzo di scambio (denaro) e un modo per applicare i contratti. Tradizionalmente questi servizi sono stati erogati dai governi o da istituzioni riconosciute dal governo e solo verso entità legali. In questo articolo descrivo un protocollo per mezzo del quale questi servizi posso essere erogati da e verso entità non tracciabili.

In effetti descriverò due protocolli il primo è poco pratico, perché fa un uso massiccio di un canale boradcast che è sincrono e non intasabile. In ogni caso motiverò il secondo protocollo, più pratico. In ambo i casi assumerò l’esistenza di una rete non tracciabile, nella quale mittenti e riceventi sono identificati solo attraverso pseudonimi digitali (ad esempio: chiavi pubbliche) e ogni messaggio è firmato dal suo mittente e cifrato con la chiave pubblica del ricevente.

Primo protocollo

Nel primo protocollo, ogni partecipante gestisce un proprio separato database su quanti soldi appartengono ad ogni pseudonimo, e l’oggetto di questo protocollo è il modo nel quale questi conti correnti vengono aggiornati.

  1. Creazione di denaro.

    Chiunque può creare denaro rendendo pubblica (broadcasting) la soluzione di un problema computazionale fino a quel momento irrisolto. La sola condizione è che deve essere facile determinare quanto sforzo computazionale occorre per risolvere il problema e, in caso contrario, la soluzione non deve avere un valore né pratico né intellettuale. Il numero di unità monetarie creato è uguale al costo dello sforzo computazionale in termini di un paniere di beni. Per esempio, se un problema richiede 100 ore ad essere risolto nel computer che lo risolve più convenientemente, e ci vogliono 3 panieri standard per acquistare 100 ore di funzionamento di quel computer nel mercato libero, allora sulla diffusione della soluzione di quel problema ognuno accrediterà al mittente 3 unità nel proprio database.

  2. Trasferimento di denaro.

    Se Alice (il detentore dello pseudonimo K_A) vuole trasferire X unità d denaro a Bob (detentore dello pseudonimo K_B), essa diffonde il messaggio “Io K_A consegno X unità di denaro a K_B”.
    In seguito a questo messaggio broadcast, ciascuno sottrae nel proprio database X unità dall’account di K_A e somma X unità al conto di K_B, a meno che questo non crei un bilancio negativo peer K_A, nel qual caso il messaggio viene ignorato.

  3. Applicazione dei contratti.

    Un contratto valido deve includere un massimo di risarcimento in caso di fallimento di ogni parte contrattuale. Deve anche contemplare una (terza) parte che eseguirà un arbitrato nel caso di contestazioni.  Tutte le parti di un contratto, incluso l’arbitro, devono inviare in rete le loro firme digitali del contratto prima che questo possa essere considerato valido. Al momento della diffusione in rete del contratto e delle firme digitali, ogni partecipante addebita nel proprio daabase al conto di ciascun partecipante il massimo del sua qyuota massiam di risarcimento e accredita su un conto speciale che si identifica con l’hash sicuro del contratto, la somma dei risarcimenti massimi di tutte le parti. Il contratto diviene efficace se gli addebiti funzionano su tutte le parti contrattuali senza che si verifichi un bilancio negativo per nessuno, caso nel quale il contratto viene ignorato e tutti i conti correnti vengono ripristinati al valore precedente (rollback). Un esempio di contratto dovrebbe essere simile a questo:

    K_A acconsente di consegnare a K_B la soluzione del problema P prima delle 00:00:00 del 01/01/2100,
    K_B acconsente di pagare K_A 100 bitcoin (UM, unita di moneta) prima delle 00:00:00 del 01/01/2100,
    K_C acconsente di svolgere un arbitrato in caso di contestazione.
    K_A acconsente di pagare a K_B un massimo di 1000 bitcoin in caso di fallimento [non consegna]
    K_B acconsente di pagare a K_A un massimo di 200 bitcoin in caso di fallimento [non vuole più la soluzione].
    K_C acconsente di pagare [a chi?] un massimo di 500 bitcoin in caso di fallimento [non raggiunge l’accordo].

  4. Conclusione dei contratti.

    Se un contratto di conclude con una disputa, ogni parte invia in rete un messaggio firmato “Il contratto con firma digitale SHA-1 H si conclude senza risarcimenti” o anche “Il contratto con firma digitale SHA-1 H si conclude con i seguenti risarcimenti…”. In seguito alla diffusione di tutte le firme, ogni partecipante accredita nel proprio database nel conto corrente di ogni parte l’importo del suo massimo risarcimento, cancella l’account (fittizio) del contratto, quindi accredita o addebita al conto di ciascuna delle parti contrattuali secondo lo schema di risarcimento, se ce n’è uno.

  5. Applicazione dei contratti.

    Se le parti contrattuali non trovano un accordo su una conclusione appropriata anche con l’aiuto di un arbitro, ogni parte invia in rete una proposta di risarcimento/sanzione e ogni argomento o evidenza che deponga in suo favore. Ogni partecipante fa una determinazione in merito agli effettivi risarcimenti / sanzioni e modifica di conseguenza i conti correnti delle parti nel proprio database,

Secondo protocollo

Nel secondo protocollo, i conti correnti di ciascuno sono localizzati in un sottoinsieme di partecipanti (che chiameremo server d’ora in poi) invece che nel database di ciascun partecipante. Questi server sono collegati da una rete di trasmissione di tipo Usenet. Il formato dei messaggi di transazione trasmessi su questo canale rimane lo stesso del primo protocollo, ma i partecipanti ai quali è arrivato il messaggio broadcast devono verificare che il messaggio è stato ricevuto e correttamente elaborato su un sottoinsieme casuale di questi server.

Poiché i server devono possedere un certo grado di affidabilità, è necessario un meccanismo per mantenere la loro onestà. Ad ogni server viene richiesto di accreditare una certa quantità di denaro su un conto corrente speciale, denaro potenziale per ricompense o multe in caso di buona o cattiva condotta. Inoltre, ogni server periodicamente deve periodicamente pubblicare i propri database e registrare su di essi le operazioni di creazione di denaro e le attribuzioni di denaro ai partecipanti. Ogni partecipante deve verificare che il bilancio del proprio conto corrente sia esatto e che la somma dei bilanci non sia maggiore della quantità di denaro creata. Questo impedisce ai server, anche in caso di collusione totale, di aumentare l’immissione di denaro costantemente e senza costi. Nuovi server possono anche usare i database pubblicati per sincronizzarsi con gli altri server.

Il protocollo proposto in questo articolo permette a entità pseudonime non identificabili (non rintracciabili) di cooperare tra loro più efficientemente fornendo loro un mezzo di scambio e un metodo per applicare i contratti. Il protocollo può probabilmente essere reso più efficiente e sicuro, ma io spero che questo sia un passo verso la realizzazione della cripto anarchia come possibilità pratica come anche teorica.

 

Appendice A: una creazione di denaro elettronico alternativa

Uno degli aspetti più problematici nel protocollo di b-money è la creazione del denaro. Questa parte del protocollo richiede che tutti i detentori di un conto si accordino e decidano sul costo di computazioni particolari. Sfortunatamente, poiché la tecnologia dei computer tende ad avanzare rapidamente e non sempre pubblicamente, questa informazione potrebbe essere non disponibile, inaccurata o obsoleta, circostanze che possono causare seri problemi al protocollo.

Così, vi propongo un’alternativa al subprotocollo di creazione del denaro, nel quale ogni proprietario di un conto (tutti, nel primo protocollo, oppure i server, nel secondo protocollo) si accordino e decidano invece sulla quantità di denaro da creare una volta ogni periodo, con il costo che viene determinato a mezzo di un’asta. Ogni periodo di creazione di denaro viene così suddiviso in quattro fasi:

  1. Pianificazione

    I possessori di un conto calcolano e negoziano con gli altri una somma ottimale di denaro da fornire per il prossimo periodo. Sia che raggiungano o meno il consenso, essi inoltrano nella rete (broadcast) la loro quota di denaro creata e ogni calcolo macroeconomico fatto a supporto delle previsioni

  2. Offerta.

    Chiunque voglia creare denaro binario immette nella rete un’offerta nella forma <x, y>, dove x è la quantità di denaro che vuole creare e y è un problema irrisolto appartenente ad una predeterminata classe di problemi. Ogni problema in questa classe deve avere un costo nominale (ad esempio in MIPS/anno) sul quale ci sia un consenso generale.

  3. Calcolo

    Dopo aver visto le offerte,  coloro che le hanno lanciate possono ora risolvere i problemi e pubblicare in rete le soluzioni

  4. Creazione del denaro

    Ogni possessore di un conto, accetta le offerte più alte (tra coloro che le hanno effettivamente pubblicate in rete) in termini di costo nominale per unità di denaro binario creato, e le accredita sui conto degli offerenti corrispondenti.

 

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.