Bitcoin: un sistema di pagamento elettronico peer-to-peer
Satoshi Nakamoto
satoshin@gmx.com
www.bitcoin.org
Astratto . Una versione puramente peer-to-peer del contante elettronico consentirebbe di inviare pagamenti online direttamente da una parte all'altra senza passare attraverso un istituto finanziario. Le firme digitali forniscono parte della soluzione, ma i vantaggi principali vengono persi se è ancora necessaria una terza parte fidata per evitare la doppia spesa. Proponiamo una soluzione al problema della doppia spesa utilizzando una rete peer-to-peer. La rete contrassegna l'ora delle transazioni inserendole in una catena continua di prove di lavoro basate su hash, formando un record che non può essere modificato senza ripetere la prova di lavoro. La catena più lunga non serve solo come prova della sequenza di eventi a cui si è assistito, ma anche come prova che proviene dal più grande pool di potenza della CPU. Finché la maggior parte della potenza della CPU è controllata da nodi che non cooperano per attaccare la rete, genereranno la catena più lunga e supereranno gli aggressori. La rete stessa richiede una struttura minima. I messaggi vengono trasmessi sulla base del massimo sforzo e i nodi possono lasciare e ricongiungersi alla rete a piacimento, accettando la più lunga catena di prove di lavoro come prova di ciò che è accaduto mentre erano via.
1. Introduzione
Il commercio su Internet è arrivato a fare affidamento quasi esclusivamente su istituzioni finanziarie che fungono da terze parti fidate per elaborare i pagamenti elettronici. Sebbene il sistema funzioni abbastanza bene per la maggior parte delle transazioni, soffre ancora delle debolezze intrinseche del modello basato sulla fiducia. Le transazioni completamente irreversibili non sono realmente possibili, poiché le istituzioni finanziarie non possono evitare di mediare le controversie. Il costo della mediazione aumenta i costi di transazione, limitando la dimensione pratica minima della transazione e escludendo la possibilità di piccole transazioni casuali, e vi è un costo più ampio nella perdita della capacità di effettuare pagamenti non reversibili per servizi non reversibili. Con la possibilità di inversione, il bisogno di fiducia si diffonde. I commercianti devono diffidare dei propri clienti, chiedendo loro più informazioni di quelle di cui avrebbero altrimenti bisogno. Una certa percentuale di frode è accettata come inevitabile. Questi costi e incertezze sui pagamenti possono essere evitati di persona utilizzando valuta fisica, ma non esiste alcun meccanismo per effettuare pagamenti tramite un canale di comunicazione senza una parte fidata.
Ciò che serve è un sistema di pagamento elettronico basato sulla prova crittografica anziché sulla fiducia, che consenta a due parti qualsiasi di effettuare transazioni direttamente tra loro senza la necessità di una terza parte fidata. Le transazioni che sono computazionalmente impraticabili da annullare proteggerebbero i venditori dalle frodi e i meccanismi di deposito a garanzia di routine potrebbero essere facilmente implementati per proteggere gli acquirenti. In questo documento, proponiamo una soluzione al problema della doppia spesa utilizzando un server timestamp distribuito peer-to-peer per generare una prova computazionale dell'ordine cronologico delle transazioni. Il sistema è sicuro fintanto che i nodi onesti controllano collettivamente più potenza della CPU rispetto a qualsiasi gruppo cooperante di nodi attaccanti.
2. Transazioni
Definiamo una moneta elettronica come una catena di firme digitali. Ogni proprietario trasferisce la moneta al successivo firmando digitalmente un hash della transazione precedente e la chiave pubblica del proprietario successivo e aggiungendoli alla fine della moneta. Un beneficiario può verificare le firme per verificare la catena di proprietà.
Il problema ovviamente è che il beneficiario non può verificare che uno dei proprietari non abbia speso due volte la moneta. Una soluzione comune consiste nell'introdurre un'autorità centrale fidata, o zecca, che controlla ogni transazione per la doppia spesa. Dopo ogni transazione, la moneta deve essere restituita alla zecca per emettere una nuova moneta, e si ritiene che solo le monete emesse direttamente dalla zecca non vengano spese due volte. Il problema con questa soluzione è che il destino dell'intero sistema monetario dipende dalla società che gestisce la zecca, con ogni transazione che deve passare attraverso di essa, proprio come una banca.
Abbiamo bisogno di un modo per far sapere al beneficiario che i precedenti proprietari non hanno firmato alcuna transazione precedente. Per i nostri scopi, la prima transazione è quella che conta, quindi non ci preoccupiamo dei successivi tentativi di doppia spesa. L'unico modo per confermare l'assenza di una transazione è essere a conoscenza di tutte le transazioni. Nel modello basato sulla zecca, la zecca era a conoscenza di tutte le transazioni e decideva quale arrivava per prima. Per ottenere ciò senza una parte fidata, le transazioni devono essere annunciate pubblicamente [1] e abbiamo bisogno di un sistema per consentire ai partecipanti di concordare un'unica cronologia dell'ordine in cui sono state ricevute. Il beneficiario ha bisogno di una prova che al momento di ogni transazione, la maggior parte dei nodi abbia concordato che fosse la prima ricevuta.
3. Server di marca temporale
La soluzione che proponiamo inizia con un server timestamp. Un server di timestamp funziona prendendo un hash di un blocco di elementi da contrassegnare e pubblicando ampiamente l'hash, ad esempio in un giornale o in un post di Usenet [2-5]. Il timestamp dimostra che i dati dovevano esistere in quel momento, ovviamente, per entrare nell'hash. Ogni timestamp include il timestamp precedente nel suo hash, formando una catena, con ogni timestamp aggiuntivo che rafforza quelli precedenti.
4. Prova di lavoro
Per implementare un server di timestamp distribuito su base peer-to-peer, avremo bisogno di utilizzare un sistema di prova del lavoro simile a Hashcash di Adam Back [6], piuttosto che ai giornali o ai post di Usenet. La prova di lavoro implica la scansione di un valore che quando sottoposto ad hashing, come con SHA-256, l'hash inizia con un numero di zero bit. Il lavoro medio richiesto è esponenziale nel numero di zero bit richiesti e può essere verificato eseguendo un singolo hash.
Per la nostra rete timestamp, implementiamo la prova di lavoro incrementando un nonce nel blocco finché non viene trovato un valore che fornisce all'hash del blocco i bit zero richiesti. Una volta che lo sforzo della CPU è stato speso per soddisfare la prova di lavoro, il blocco non può essere modificato senza rifare il lavoro. Man mano che i blocchi successivi vengono concatenati dopo di esso, il lavoro per modificare il blocco includerebbe la ripetizione di tutti i blocchi successivi.
La prova del lavoro risolve anche il problema di determinare la rappresentanza nel processo decisionale a maggioranza. Se la maggioranza fosse basata su un indirizzo IP-un voto, potrebbe essere sovvertita da chiunque sia in grado di allocare molti IP. La prova di lavoro è essenzialmente una CPU-un voto. La decisione della maggioranza è rappresentata dalla catena più lunga, che ha il massimo sforzo di prova del lavoro investito in essa. Se la maggior parte della potenza della CPU è controllata da nodi onesti, la catena onesta crescerà più velocemente e supererà qualsiasi catena concorrente. Per modificare un blocco passato, un utente malintenzionato dovrebbe rifare la prova di lavoro del blocco e di tutti i blocchi successivi e quindi raggiungere e superare il lavoro dei nodi onesti. Mostreremo in seguito che la probabilità che un utente malintenzionato più lento recuperi diminuisce in modo esponenziale con l'aggiunta di blocchi successivi.
Per compensare l'aumento della velocità dell'hardware e il variare dell'interesse nell'esecuzione dei nodi nel tempo, la difficoltà della prova di lavoro è determinata da una media mobile che mira a un numero medio di blocchi all'ora. Se vengono generati troppo velocemente, la difficoltà aumenta.
5. Rete
I passaggi per eseguire la rete sono i seguenti:
1) Le nuove transazioni vengono trasmesse a tutti i nodi.
2) Ogni nodo raccoglie nuove transazioni in un blocco.
3) Ogni nodo lavora per trovare una difficile prova di lavoro per il suo blocco.
4) Quando un nodo trova una prova di lavoro, trasmette il blocco a tutti i nodi.
5) I nodi accettano il blocco solo se tutte le transazioni in esso contenute sono valide e non già spese.
6) I nodi esprimono la loro accettazione del blocco lavorando alla creazione del blocco successivo nella catena, utilizzando l'hash del blocco accettato come hash precedente.
I nodi considerano sempre la catena più lunga quella corretta e continueranno a lavorare per estenderla. Se due nodi trasmettono contemporaneamente versioni diverse del blocco successivo, alcuni nodi potrebbero ricevere prima l'una o l'altra. In tal caso, lavorano sul primo che hanno ricevuto, ma salvano l'altro ramo nel caso in cui diventi più lungo. Il pareggio verrà spezzato quando verrà trovata la successiva prova di lavoro e un ramo si allungherà; i nodi che stavano lavorando sull'altro ramo passeranno quindi a quello più lungo.
Le trasmissioni di nuove transazioni non devono necessariamente raggiungere tutti i nodi. Finché raggiungono molti nodi, entreranno presto in un blocco. Le trasmissioni di blocco tollerano anche i messaggi eliminati. Se un nodo non riceve un blocco, lo richiederà quando riceve il blocco successivo e si rende conto di averne perso uno.
6. Incentivo
Per convenzione, la prima transazione in un blocco è una transazione speciale che avvia una nuova moneta di proprietà del creatore del blocco. Ciò aggiunge un incentivo per i nodi a supportare la rete e fornisce un modo per distribuire inizialmente le monete in circolazione, poiché non esiste un'autorità centrale per emetterle. L'aggiunta costante di una quantità costante di nuove monete è analoga ai minatori d'oro che spendono risorse per aggiungere oro alla circolazione. Nel nostro caso, è il tempo della CPU e l'elettricità che vengono consumati.
L'incentivo può anche essere finanziato con commissioni di transazione. Se il valore di output di una transazione è inferiore al suo valore di input, la differenza è una commissione di transazione che viene aggiunta al valore di incentivo del blocco contenente la transazione. Una volta che un numero predeterminato di monete è entrato in circolazione, l'incentivo può passare interamente alle commissioni di transazione ed essere completamente privo di inflazione.
L'incentivo può aiutare a incoraggiare i nodi a rimanere onesti. Se un attaccante avido è in grado di assemblare più potenza della CPU di tutti i nodi onesti, dovrebbe scegliere tra usarla per frodare le persone rubando i suoi pagamenti o usarla per generare nuove monete. Dovrebbe trovare più vantaggioso giocare secondo le regole, tali regole che lo favoriscono con più nuove monete di tutti gli altri messi insieme, piuttosto che minare il sistema e la validità della propria ricchezza.
7. Recupero dello spazio su disco
Una volta che l'ultima transazione in una moneta è sepolta sotto un numero sufficiente di blocchi, le transazioni spese prima possono essere scartate per risparmiare spazio su disco. Per facilitare ciò senza rompere l'hash del blocco, le transazioni vengono sottoposte ad hashing in un Merkle Tree [7][2][5], con solo la radice inclusa nell'hash del blocco. I vecchi blocchi possono quindi essere compattati tagliando i rami dell'albero. Gli hash interni non devono essere archiviati.
Un'intestazione di blocco senza transazioni sarebbe di circa 80 byte. Se supponiamo che i blocchi vengano generati ogni 10 minuti, 80 byte * 6 * 24 * 365 = 4,2 MB all'anno. Con i sistemi informatici in genere venduti con 2 GB di RAM a partire dal 2008 e la legge di Moore che prevede l'attuale crescita di
1,2 GB all'anno, l'archiviazione non dovrebbe essere un problema anche se le intestazioni dei blocchi devono essere conservate in memoria.
8. Verifica di pagamento semplificata
È possibile verificare i pagamenti senza eseguire un nodo di rete completo. Un utente deve solo conservare una copia delle intestazioni del blocco della catena di prova di lavoro più lunga, che può ottenere interrogando i nodi di rete fino a quando non è convinto di avere la catena più lunga, e ottenere il ramo Merkle che collega la transazione al blocco non può controllare la transazione da solo, ma collegandola a un punto della catena, può vedere che un nodo di rete l'ha accettata e i blocchi aggiunti dopo confermano ulteriormente che la rete l'ha accettata.
Pertanto, la verifica è affidabile fintanto che i nodi onesti controllano la rete, ma è più vulnerabile se la rete è sopraffatta da un utente malintenzionato. Mentre i nodi di rete possono verificare le transazioni da soli, il metodo semplificato può essere ingannato dalle transazioni fabbricate da un utente malintenzionato fintanto che l'attaccante può continuare a sopraffare la rete. Una strategia per proteggersi da ciò sarebbe accettare avvisi dai nodi di rete quando rilevano un blocco non valido, richiedendo al software dell'utente di scaricare l'intero blocco e avvisare le transazioni per confermare l'incoerenza. Le aziende che ricevono pagamenti frequenti probabilmente vorranno comunque eseguire i propri nodi per una sicurezza più indipendente e una verifica più rapida.
9. Combinare e dividere il valore
Sebbene sia possibile gestire le monete individualmente, sarebbe ingombrante effettuare una transazione separata per ogni centesimo in un trasferimento. Per consentire la suddivisione e la combinazione del valore, le transazioni contengono più input e output. Normalmente ci sarà un singolo input da una transazione precedente più grande o più input che combinano importi più piccoli, e al massimo due output: uno per il pagamento e uno per restituire l'eventuale resto al mittente.
Va notato che il fan-out, in cui una transazione dipende da diverse transazioni e quelle transazioni dipendono da molte altre, non è un problema qui. Non è mai necessario estrarre una copia autonoma completa della cronologia di una transazione.
10. Riservatezza
Il modello bancario tradizionale raggiunge un livello di privacy limitando l'accesso alle informazioni alle parti coinvolte e alla terza parte di fiducia. La necessità di annunciare pubblicamente tutte le transazioni preclude questo metodo, ma la privacy può ancora essere mantenuta interrompendo il flusso di informazioni in un altro luogo: mantenendo anonime le chiavi pubbliche. Il pubblico può vedere che qualcuno sta inviando un importo a qualcun altro, ma senza informazioni che colleghino la transazione a nessuno. Questo è simile al livello di informazioni rilasciate dalle borse valori, dove l'ora e l'entità delle singole negoziazioni, il "nastro", sono rese pubbliche, ma senza dire chi fossero le parti.
Come firewall aggiuntivo, dovrebbe essere utilizzata una nuova coppia di chiavi per ogni transazione per evitare che vengano collegate a un proprietario comune. Alcuni collegamenti sono ancora inevitabili con le transazioni multi-input, che rivelano necessariamente che i loro input erano di proprietà dello stesso proprietario. Il rischio è che se viene rivelato il proprietario di una chiave, il collegamento potrebbe rivelare altre transazioni che appartenevano allo stesso proprietario.
11. Calcoli
Consideriamo lo scenario di un utente malintenzionato che tenta di generare una catena alternativa più veloce della catena onesta. Anche se ciò viene realizzato, non espone il sistema a modifiche arbitrarie, come la creazione di valore dal nulla o il prelievo di denaro che non è mai appartenuto all'aggressore. I nodi non accetteranno una transazione non valida come pagamento e i nodi onesti non accetteranno mai un blocco che li contenga. Un utente malintenzionato può solo provare a modificare una delle sue transazioni per riprendersi i soldi che ha speso di recente.
La corsa tra la catena onesta e una catena attaccante può essere definita come una passeggiata casuale binomiale. L'evento di successo è la catena onesta che viene estesa di un blocco, aumentando il suo vantaggio di +1, e l'evento di fallimento è la catena dell'attaccante che viene estesa di un blocco, riducendo il divario di -1.
La probabilità che un utente malintenzionato recuperi da un dato deficit è analoga a un problema di Gambler's Ruin. Supponiamo che un giocatore d'azzardo con credito illimitato inizi con un deficit e giochi potenzialmente un numero infinito di prove per cercare di raggiungere il pareggio.
Data la nostra ipotesi che p > q, la probabilità diminuisce in modo esponenziale all'aumentare del numero di blocchi che l'attaccante deve recuperare. Con le probabilità contro di lui, se non fa un fortunato affondo in avanti all'inizio, le sue possibilità diventano irrisorie man mano che rimane più indietro.
Consideriamo ora quanto tempo deve attendere il destinatario di una nuova transazione prima di essere sufficientemente certo che il mittente non possa modificare la transazione. Partiamo dal presupposto che il mittente è un utente malintenzionato che vuole far credere al destinatario di averlo pagato per un po ', quindi cambiarlo per ripagare se stesso dopo che è trascorso un po' di tempo. Il destinatario verrà avvisato quando ciò accadrà, ma il mittente spera che sia troppo tardi.
Il destinatario genera una nuova coppia di chiavi e consegna la chiave pubblica al mittente poco prima della firma. Ciò impedisce al mittente di preparare una catena di blocchi in anticipo lavorandoci continuamente fino a quando non ha la fortuna di andare abbastanza avanti, quindi eseguendo la transazione in quel momento. Una volta inviata la transazione, il mittente disonesto inizia a lavorare in segreto su una catena parallela contenente una versione alternativa della sua transazione.
Il destinatario attende fino a quando la transazione non è stata aggiunta a un blocco e z blocchi sono stati collegati dopo di esso. Non conosce l'esatta quantità di progressi compiuti dall'attaccante, ma supponendo che i blocchi onesti abbiano impiegato il tempo medio previsto per blocco, il potenziale progresso dell'attaccante sarà una distribuzione di Poisson.
12. Conclusione
Abbiamo proposto un sistema per le transazioni elettroniche senza fare affidamento sulla fiducia. Abbiamo iniziato con la consueta struttura di monete realizzate con firme digitali, che fornisce un forte controllo della proprietà, ma è incompleta senza un modo per impedire la doppia spesa. Per risolvere questo problema, abbiamo proposto una rete peer-to-peer che utilizza la prova del lavoro per registrare una cronologia pubblica delle transazioni che diventa rapidamente impraticabile dal punto di vista computazionale per un utente malintenzionato da modificare se i nodi onesti controllano la maggior parte della potenza della CPU. La rete è robusta nella sua semplicità non strutturata. I nodi funzionano tutti in una volta con poco coordinamento. Non è necessario identificarli, poiché i messaggi non vengono instradati in un luogo particolare e devono essere recapitati solo al meglio. I nodi possono lasciare e ricongiungersi alla rete a piacimento, accettando la catena di prova del lavoro come prova di ciò che è accaduto mentre erano via. Votano con la loro potenza della CPU, esprimendo la loro accettazione di blocchi validi lavorando per estenderli e rifiutando blocchi non validi rifiutandosi di lavorare su di essi. Tutte le regole e gli incentivi necessari possono essere applicati con questo meccanismo di consenso.
Riferimenti[1] W. Dai, "b-money", http://www.weidai.com/bmoney.txt, 1998.[2]H. Massias , XS Avila e J.-J. Quisquater , "Progettazione di un servizio di timestamp sicuro con requisiti minimi di attendibilità", In 20th Symposium on Information Theory in the Benelux, maggio 1999.[3] S. Haber, WS Stornetta , "Come marcare con data e ora un documento digitale", In Journal of Cryptology, vol 3, n. 2, pagine 99-111, 1991.[4] D. Bayer, S. Haber, WS Stornetta , "Migliorare l'efficienza e l'affidabilità del timestamp digitale", In Sequences II: Methods in Communication, Security and Computer Science, pagine 329-334, 1993.[5] S. Haber, WS Stornetta , "Secure names for bit-strings", In Atti della 4a conferenza ACM sulla sicurezza dei computer e delle comunicazioni, pagine 28-35, aprile 1997.[6] R. Indietro, " Hashcash - una contromisura di negazione del servizio", http://www.hashcash.org/papers/hashcash.pdf, 2002.[7] RC Merkle, "Protocolli per sistemi crittografici a chiave pubblica", In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pagine 122-133, aprile 1980.[8]W. Feller, "Un'introduzione alla teoria della probabilità e alle sue applicazioni", 1957.
Comprare Bitcoin
Puoi acquistare Bitcoin qui .