Bitcoin P2P e-cash paper

2008-11-09 01:58:48 UTC - Email originale

si dice che se una transazione trasmessa non raggiunge tutti i nodi va bene, perché entrerà nella catena di blocchi entro poco tempo. Questo come funziona? Cosa accade se il nodo che crea il blocco "successivo" (il primo nodo a trovare la collisione hashcash) non è venuto a conoscenza della transazione, e poi qualche altro blocco viene aggiunto anche da nodi che non sono venuti a conoscenza della stessa transazione? Fai in modo che tutti i nodi che l'hanno ricevuta la conservino, sperando di incorporarla in un blocco una volta che saranno abbastanza fortunati da trovare la prossima collisione?

Giusto, i nodi mantengono le transazioni nel loro insieme di lavoro finchè non entrano in un blocco.  Se una transazione raggiunge il 90% dei nodi, ogni volta che viene trovato un nuovo blocco, ha una probabilità del 90% di essere inserita in esso.

O ad esempio, cosa succede se un nodo sta tenendo due o più catene in attesa di vedere quale cresce più velocemente, e arriva un blocco per la catena A che include una doppia spesa di una moneta che si trova nella catena B? Questo viene controllato o no? (Potrebbe accadere se qualcuno spendesse due volte e due diversi insiemi di nodi ricevessero le due diverse transazioni della stessa moneta.)

Non è necessario verificarlo.  La transazione in qualsiasi ramo finisca diventa quella valida, l’altra non è valida.  Se qualcuno cerca di fare una doppia spesa in questo modo, una e una sola spesa diventerà valida, le altre invalide.

I destinatari delle transazioni dovranno normalmente tenerle in sospeso per un’ora o più, in modo da avere il tempo di risolvere questo tipo di problematica.  Nell’immediato possono comunque spendere nuovamente le monete, ma dovrebbero aspettare prima di compiere un’azione come la spedizione di merci.

Inoltre non capisco esattamente come la doppia spesa, o l'annullamento delle transazioni, possa essere eseguita da un attaccante che è in grado di ottenere più potenza di calcolo di tutti i partecipanti onesti. Comprendo che può creare nuovi blocchi e aggiungerli per creare la catena più lunga, ma come può cancellare o aggiungere vecchie transazioni nella catena stessa? Mentre l'attaccante invia i suoi nuovi blocchi, non ci sono controlli di coerenza che i nodi onesti possono eseguire per assicurare che nulla sia stato cancellato? Sarebbe utile una spiegazione più >approfondita di questo attacco, per valutare i guadagni di un aggressore rispetto al semplice utilizzo della sua potenza di calcolo per coniare onestamente nuove monete.

L’attaccante non aggiunge blocchi alla fine.  Deve tornare indietro e rifare il blocco in cui si trova la sua transazione e tutti quelli successivi, oltre a tutti i nuovi blocchi che la rete continua ad aggiungere mentre sta eseguendo l’attacco.  Sta riscrivendo la storia.  Una volta che il suo ramo è più lungo, diventa il nuovo ramo valido.

Questo tocca un punto chiave.  Anche se tutti i presenti possono vedere gli imbrogli in corso, non c’è modo di approfittare di questa conoscenza.

È strettamente necessario che la catena più lunga sia sempre considerata quella valida.  I nodi che erano presenti potrebbero ricordare il ramo precedente, che è stato sostituito da un altro, ma non ci sarebbe modo per loro di convincere chi non era presente di questo.  Non possiamo avere sottofazioni di nodi che si aggrappano a un ramo pensando sia stato il primo, altri che ne hanno visto un altro e altri ancora che si sono uniti più tardi e non hanno mai visto cosa è successo.  Il voto di proof-of-work con la potenza delle CPU deve avere l’ultima parola.  L’unico modo per essere tutti d’accordo è credere che la catena più lunga sia sempre quella valida, a prescindere da tutto.

Per quanto riguarda le transazioni di spesa, quali controlli deve effettuare il destinatario di una moneta? Deve ripercorrere l'intera storia dei trasferimenti di quella moneta e assicurarsi che ogni transazione della lista sia effettivamente collegata alla catena di blocchi di >"timestamp"? O può semplicemente controllare la più recente?

Il destinatario deve solo verificarla a una profondità sufficientemente lontana nella catena di blocchi, che spesso richiede solo 2 transazioni.  Tutte le transazioni precedenti possono essere scartate.

I nodi di timestamp controllano le transazioni, assicurandosi che la precedente transazione di una moneta sia nella catena, facendo così rispettare la regola che tutte le transazioni nella catena rappresentano monete valide?

Giusto, proprio così.  Quando un nodo riceve un blocco controlla le firme di ogni transazione in esso contenute, confrontandole con le transazioni precedenti nei blocchi.  I blocchi possono contenere solo transazioni che dipendono da transazioni valide nei blocchi precedenti o nello stesso blocco.  La transazione C potrebbe dipendere dalla transazione B nello stesso blocco e B dipendere dalla transazione A in un blocco precedente.

Scusa per tutte le domande, ma come ho detto questa sembra essere un'idea molto promettente e originale, non vedo l'ora di vedere come verrà ulteriormente sviluppato il concetto. Sarebbe utile vedere una descrizione più orientata al processo dell'idea, con dettagli concreti sulle strutture dati dei vari oggetti (monete, blocchi, transazioni), sui dati inclusi nei messaggi e sulle descrizioni algoritmiche delle procedure di gestione dei vari eventi che si verificherebbero in questo sistema. Hai detto che stai lavorando a un'implementazione, ma penso che una descrizione più formale e testuale del sistema sarebbe un utile passo successivo.

Apprezzo le tue domande.  In realtà l’ho fatto al contrario.  Ho dovuto scrivere tutto il codice prima di potermi convincere che potessi risolvere ogni problema, poi ho scritto il documento.  Penso che sarò in grado di rilasciare il codice prima di scrivere una specifica dettagliata.  Hai già ragione sulla maggior parte delle tue ipotesi in cui hai riempito gli spazi vuoti.

Satoshi Nakamoto

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