Bitcoin P2P e-cash paper

2008-11-15 04:43:00 UTC - Email originale

Cercherò di sbrigarmi a rilasciare il codice sorgente il prima possibile, in modo da poterlo utilizzare come riferimento per chiarire tutti questi dubbi sull’implementazione.

Ray Dillinger (Bear) ha scritto:

Quando una moneta viene spesa, l'acquirente e il venditore firmano digitalmente un record (ceco) della transazione.

Solo l’acquirente firma, e non c’è cecità.

Se qualcuno spende due volte allora il record della transazione può essere esposto, rivelando l’identità del truffatore.

Le identità non vengono utilizzate e non ci si affida al ricorso.  È tutta prevenzione.

Questo avviene tramite un algoritmo abbastanza standard di dividi-e-scegli in cui l'acquirente risponde a diverse sfide con condivisioni segrete

Nessuna sfida o condivisione segreta. Una transazione base è proprio quella che vedi nella figura della sezione 2.  Una firma (dell’acquirente) che soddisfa la chiave pubblica della transazione precedente e una nuova chiave pubblica (del venditore) che deve essere soddisfatta per poterla spendere la volta successiva.

Possono ricevere anche catene lunghe quanto quella che stanno cercando di estendere mentre lavorano, in cui gli ultimi "collegamenti" sono collegamenti non in comune con la catena su cui stanno lavorando. Questi vengono ignorati.

Esatto, se sono uguali in lunghezza, i legami vengono interrotti mantenendo la prima ricevuta.

Se contiene una doppia spesa, allora creano una "transazione" che è una prova della doppia spesa, la aggiungono al loro pool A, la trasmettono e continuano a lavorare.

Non c’è bisogno di segnalare una “prova di doppia spesa” in questo modo.  Se la stessa catena contiene entrambe le spese, il blocco non è valido e viene rifiutato.

Lo stesso vale se un blocco non ha una proof-of-work sufficiente.  Quel blocco non è valido e viene rifiutato. Non c’è bisogno di far circolare una segnalazione al riguardo. Ogni nodo potrebbe vederlo e rifiutarlo prima di ritrasmetterlo.

Se ci sono due catene concorrenti, ognuna delle quali contiene una versione diversa della stessa transazione, con una che cerca di dare denaro a una persona e l’altra che cerca di dare lo stesso denaro a qualcun altro, risolvere quale delle due transazioni è valida è il senso dell’intera catena di proof-of-work.

Non siamo “alla ricerca” di doppie spese per dare l’allarme e catturare il truffatore.  Ci limitiamo a stabilire quale delle spese è valida.  Chi riceve le transazioni deve aspettare qualche blocco per assicurarsi che la risoluzione abbia avuto il tempo di completarsi.  I truffatori possono provare a fare una doppia spesa simultanea quanto vogliono, ma tutto ciò che ottengono è che entro pochi blocchi una delle spese diventa valida e le altre non più.  Qualsiasi doppia spesa successiva viene immediatamente rifiutata una volta presente una spesa nella catena principale.

Anche se una spesa precedente non fosse ancora presente nella catena, nel caso in cui fosse comunque presente nelle pool di tutti i nodi allora la seconda spesa verrebbe rifiutata da tutti i nodi con la prima.

Se la nuova catena viene accettata, allora i nodi rinunciano ad aggiungere il loro collegamento attuale, scartano tutte le transazioni dal pool L al pool A (insieme alle transazioni che loro hanno ricevuto e creato da quando hanno iniziato a lavorare), eliminano dal pool A le registrazioni delle transazioni che fanno già parte di un collegamento nella nuova catena, e iniziano a lavorare nuovamente per provare a estendere la nuova catena.

Giusto.  Inoltre si aggiornano ogni volta che arriva una nuova transazione, quindi L contiene praticamente tutto ciò che è presente in A in ogni momento.

Algoritmo di firma digitale a elevato utilizzo di CPU per firmare la catena, compreso il nuovo blocco L.

Si tratta di una proof-of-work in stile SHA-256 di Hashcash (preimmagine parziale di zero), non di una firma.

Esiste un meccanismo per assicurarsi che la "catena" non sia composta solo di collegamenti aggiunti dai 3 o 4 nodi più veloci? Perché il record di una transazione già trasmessa potrebbe facilmente mancare quei 3 o 4 nodi e se ciò accadde, e quei nodi continuano a dominare la catena, la transazione potrebbe non essere mai aggiunta.

Se la pensi come una firma digitale a elevato uilizzo di CPU, allora potresti pensare a una gara di calcolo di lunghe computazioni in cui il più veloce vince sempre.

La proof-of-work è una ricerca di collisioni in stile SHA-256 di Hashcash.  È un processo senza memoria in cui si eseguono milioni di hash al secondo, con una piccola possibilità di trovarne una collisione ogni volta.  Il dominio dei 3 o 4 nodi più veloci sarebbe solo proporzionale alla loro quota di potenza totale delle CPU.  La possibilità che chiunque ha di trovare una soluzione in qualsiasi momento è proporzionale alla potenza della propria CPU.

Ci saranno commissioni di transazione, quindi i nodi saranno incentivati a ricevere e includere tutte le transazioni possibili.  Alla fine i nodi saranno ricompensati dalle sole commissioni di transazione quando il totale delle monete create raggiungerà il tetto prestabilito.

Inoltre, il lavoro richiesto per aggiungere un collegamento alla catena dovrebbe variare (sempre in modo esponenziale) con il numero di collegamenti aggiunti alla catena nella settimana precedente, facendo sì che il tasso di generazione delle monete (e quindi l'inflazione) sia strettamente controllato.

Corretto.

Per poter scalare, è necessario poter aggregare le monete. Deve esserci una transazione "dimostrabile" in cui qualcuno ritira dieci monete singole e crea una nuova moneta con taglio dieci, ecc.

Ogni transazione è una di queste.  Sezione 9, Combinare e Dividere il valore.

Satoshi Nakamoto

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La Cryptography Mailing List
Annulla l’iscrizione inviando “unsubscribe cryptography” a majordomo su metzdowd.com