Bitcoin: Ein elektronisches Peer-to-Peer-Bargeldsystem

Zusammenfassung. Eine reine Peer-to-Peer-Version von elektronischem Bargeld würde es ermöglichen, Online-Zahlungen direkt von einer Partei zur anderen zu senden, ohne den Umweg über ein Finanzinstitut zu nehmen. Digitale Signaturen bieten einen Teil der Lösung, aber die Hauptvorteile gehen verloren, wenn eine vertrauenswürdige dritte Partei immer noch erforderlich ist, um Doppelausgaben zu verhindern. Wir schlagen eine Lösung für das Problem des doppelten Geldausgebens in einem Peer-to-Peer-Netzwerk vor. Das Netzwerk versieht Transaktionen mit einem Zeitstempel, indem es sie in eine fortlaufende Kette von Hash-basierten Proof-of-Work einhängt. Die längste Kette dient nicht nur als Beweis für die beobachtete Abfolge von Ereignissen, sondern auch als Beweis dafür, dass sie von dem größten Pool an CPU-Leistung stammt. Solange die Mehrheit der CPU-Leistung von Knoten kontrolliert wird, die nicht kooperieren, um das Netzwerk anzugreifen, werden sie die längste Kette erzeugen und die Angreifer ausstechen. Das Netzwerk selbst erfordert nur eine minimale Struktur. Nachrichten werden nach bestem Wissen und Gewissen verbreitet, und die Knoten können das Netzwerk nach Belieben verlassen und sich wieder anschließen, wobei die längste Proof-of-Work-Kette als Beweis dafür gilt, was in ihrer Abwesenheit passiert ist.

Satoshi Nakamoto
[email protected]
www.bitcoin.org

1. Einleitung

Der Internethandel stützt sich bei der Abwicklung elektronischer Zahlungen fast ausschließlich auf Finanzinstitute, die als vertrauenswürdige Drittparteien fungieren. Obwohl dieses System für die meisten Transaktionen gut genug funktioniert, leidet es immer noch unter den inhärenten Schwächen des vertrauensbasierten Modells. Völlig unumkehrbare Transaktionen sind nicht wirklich möglich, da die Finanzinstitute nicht umhin können, Streitigkeiten zu schlichten. Die Kosten für die Schlichtung erhöhen die Transaktionskosten, begrenzen die praktische Mindestgröße von Transaktionen und schränken die Möglichkeit für kleine Gelegenheitsgeschäfte ein. Mit der Möglichkeit der Rückabwicklung wächst der Bedarf an Vertrauen. Die Händler müssen ihren Kunden gegenüber vorsichtig sein und sie um mehr Informationen bitten, als sie sonst benötigen würden. Ein gewisser Prozentsatz an Betrug wird als unvermeidlich hingenommen. Diese Kosten und Zahlungsunsicherheiten können durch die Verwendung von physischem Geld vermieden werden, aber es gibt keinen Mechanismus, um Zahlungen über einen Kommunikationskanal ohne eine vertrauenswürdige Partei durchzuführen.

Benötigt wird ein elektronisches Zahlungssystem, das auf kryptografischen Beweisen statt auf Vertrauen basiert und es zwei beliebigen Parteien ermöglicht, direkt miteinander zu handeln, ohne dass eine vertrauenswürdige dritte Partei erforderlich ist. Transaktionen, die rechnerisch nicht rückgängig zu machen sind, würden Verkäufer vor Betrug schützen, und zum Schutz von Käufern ließen sich leicht routinemäßige Treuhandmechanismen einrichten. In diesem Beitrag schlagen wir eine Lösung für das Problem der doppelten Ausgaben vor, bei der ein verteilter Peer-to-Peer-Zeitstempel-Server verwendet wird, um einen rechnerischen Beweis für die chronologische Reihenfolge der Transaktionen zu erstellen. Das System ist sicher, solange ehrliche Knoten gemeinsam mehr CPU-Leistung kontrollieren als eine kooperierende Gruppe von Angreiferknoten.

2. Transaktionen

Wir definieren eine elektronische Münze als eine Kette von digitalen Unterschriften. Jeder Besitzer überträgt die Münze auf den nächsten, indem er einen Hash der vorherigen Transaktion und den öffentlichen Schlüssel des nächsten Besitzers digital signiert und an das Ende der Münze anhängt. Ein Zahlungsempfänger kann die Signaturen überprüfen, um die Kette der Eigentümerschaft zu verifizieren.

Das Problem ist natürlich, dass der Zahlungsempfänger nicht nachprüfen kann, ob einer der Besitzer die Münze nicht doppelt ausgegeben hat. Eine gängige Lösung ist die Einführung einer vertrauenswürdigen zentralen Behörde oder Münzprägeanstalt, die jede Transaktion auf Doppelausgaben überprüft. Nach jeder Transaktion muss die Münze an die Prägeanstalt zurückgegeben werden, um eine neue Münze auszugeben, und nur bei Münzen, die direkt von der Prägeanstalt ausgegeben werden, ist sichergestellt, dass sie nicht doppelt ausgegeben werden. Das Problem bei dieser Lösung ist, dass das Schicksal des gesamten Geldsystems von dem Unternehmen abhängt, das die Münzprägeanstalt betreibt, und dass jede Transaktion wie bei einer Bank über sie laufen muss.

Der Zahlungsempfänger muss wissen, dass die früheren Eigentümer keine früheren Transaktionen unterzeichnet haben. Für unsere Zwecke ist die früheste Transaktion diejenige, die zählt, so dass uns spätere Versuche, Geld doppelt auszugeben, gleichgültig sind. Die einzige Möglichkeit, das Nichtvorhandensein einer Transaktion zu bestätigen, besteht darin, alle Transaktionen zu kennen. In dem auf der Münzprägung basierenden Modell kann die Münzprägeanstalt über alle Transaktionen Bescheid wissen und entscheiden, welche zuerst eintrifft. Um dies ohne eine vertrauenswürdige Partei zu erreichen, müssen die Transaktionen öffentlich bekannt gegeben werden [1], und wir brauchen ein System, mit dem sich die Teilnehmer auf eine einzige Historie der Reihenfolge ihres Eingangs einigen können. Der Zahlungsempfänger benötigt den Nachweis, dass zum Zeitpunkt jeder Transaktion die Mehrheit der Knoten zugestimmt hat, dass sie als erste eingegangen ist.

3. Zeitstempel-Server

Die von uns vorgeschlagene Lösung beginnt mit einem Zeitstempel-Server. Ein Zeitstempelserver arbeitet mit einem Hash eines Blocks von Elementen, die mit einem Zeitstempel versehen werden sollen, und veröffentlicht den Hash in großem Umfang, z. B. in einer Zeitung oder einem Usenet-Post [2-5]. Der Zeitstempel beweist, dass die Daten zu dem Zeitpunkt existiert haben müssen, um in den Hash aufgenommen zu werden. Jeder Zeitstempel schließt den vorherigen Zeitstempel in seinen Hash ein und bildet so eine Kette, wobei jeder weitere Zeitstempel die vorherigen verstärkt.

4. Proof-of-Work

Um einen verteilten Zeitstempelserver auf Peer-to-Peer-Basis zu implementieren, müssen wir ein Proof-of-Work-System verwenden, das Adam Backs Hashcash [6] ähnelt, und nicht Zeitungs- oder Usenet-Posts. Der Arbeitsnachweis besteht darin, einen Wert zu suchen, dessen Hashwert, wie bei SHA-256, mit einer Anzahl von Nullbits beginnt. Der durchschnittliche Arbeitsaufwand ist exponentiell zur Anzahl der benötigten Nullbits und kann durch die Ausführung eines einzigen Hashes überprüft werden.

Für unser Zeitstempelnetzwerk implementieren wir den Proof-of-Work, indem wir eine Nonce im Block inkrementieren, bis ein Wert gefunden wird, der dem Hash des Blocks die erforderlichen Nullbits verleiht. Sobald der CPU-Aufwand für die Erfüllung des Proof-of-Work aufgebracht wurde, kann der Block nicht mehr geändert werden, ohne die Arbeit erneut zu machen. Da spätere Blöcke nach ihm verkettet sind, würde die Arbeit, den Block zu ändern, die Wiederholung aller nachfolgenden Blöcke beinhalten.

Der Proof-of-Work löst auch das Problem der Repräsentation bei Mehrheitsentscheidungen. Würde die Mehrheit auf der Grundlage "eine IP-Adresse - eine Stimme" ermittelt, könnte sie von jedem unterlaufen werden, der in der Lage ist, viele IPs zuzuweisen. Proof-of-Work ist im Wesentlichen eine CPU - eine Stimme. Die Mehrheitsentscheidung wird durch die längste Kette repräsentiert, in die der größte Proof-of-Work-Aufwand investiert wurde. Wenn die Mehrheit der CPU-Leistung von ehrlichen Knoten kontrolliert wird, wird die ehrliche Kette am schnellsten wachsen und alle konkurrierenden Ketten überholen. Um einen vergangenen Block zu ändern, müsste ein Angreifer das Proof-of-Work des Blocks und aller folgenden Blöcke neu erstellen und dann die Arbeit der ehrlichen Knoten einholen und übertreffen. Wir werden später zeigen, dass die Wahrscheinlichkeit, dass ein langsamerer Angreifer aufholt, exponentiell abnimmt, wenn weitere Blöcke hinzugefügt werden.

Um die zunehmende Geschwindigkeit der Hardware und das im Laufe der Zeit schwankende Interesse an laufenden Knoten zu kompensieren, wird die Proof-of-Work-Schwierigkeit durch einen gleitenden Durchschnitt bestimmt, der auf eine durchschnittliche Anzahl von Blöcken pro Stunde abzielt. Wenn sie zu schnell erzeugt werden, steigt die Schwierigkeit.

5. Netzwerk

Die Schritte zum Betrieb des Netzwerks sind wie folgt:

Neue Transaktionen werden an alle Knoten gesendet.
Jeder Knoten sammelt neue Transaktionen in einem Block.
Jeder Knoten arbeitet daran, einen schwierigen Proof-of-Work für seinen Block zu finden.
Wenn ein Knoten ein Proof-of-Work findet, sendet er den Block an alle Knoten.
Die Knoten akzeptieren den Block nur, wenn alle darin enthaltenen Transaktionen gültig und noch nicht verbraucht sind.
Die Knoten drücken ihre Akzeptanz des Blocks aus, indem sie an der Erstellung des nächsten Blocks in der Kette arbeiten und dabei den Hash des akzeptierten Blocks als vorherigen Hash verwenden.

Die Knoten betrachten immer die längste Kette als die richtige und arbeiten weiter an ihrer Verlängerung. Wenn zwei Knoten gleichzeitig verschiedene Versionen des nächsten Blocks senden, kann es sein, dass einige Knoten die eine oder andere Version zuerst erhalten. In diesem Fall arbeiten sie an der zuerst empfangenen Version, speichern aber den anderen Zweig für den Fall, dass er länger wird. Der Gleichstand wird aufgelöst, wenn der nächste Proof-of-Work gefunden wird und ein Zweig länger wird; die Knoten, die an dem anderen Zweig gearbeitet haben, wechseln dann zu dem längeren Zweig.

Neue Transaktionsübertragungen müssen nicht unbedingt alle Knoten erreichen. Solange sie viele Knoten erreichen, werden sie schon bald in einen Block gelangen. Block-Broadcasts sind auch tolerant gegenüber verlorenen Nachrichten. Wenn ein Knoten einen Block nicht erhält, fordert er ihn an, wenn er den nächsten Block erhält und feststellt, dass er einen verpasst hat.

6. Anreiz

Konventionell ist die erste Transaktion in einem Block eine spezielle Transaktion, die eine neue Münze im Besitz des Erstellers des Blocks startet. Dies schafft einen Anreiz für die Knoten, das Netzwerk zu unterstützen, und bietet eine Möglichkeit, Münzen in Umlauf zu bringen, da es keine zentrale Behörde gibt, die sie ausgibt. Das stetige Hinzufügen einer konstanten Menge neuer Münzen ist vergleichbar mit Goldschürfern, die Ressourcen aufwenden, um Gold in Umlauf zu bringen. In unserem Fall sind es CPU-Zeit und Strom, die aufgewendet werden.

Der Anreiz kann auch durch Transaktionsgebühren finanziert werden. Wenn der Ausgangswert einer Transaktion geringer ist als ihr Eingangswert, wird die Differenz als Transaktionsgebühr zum Anreizwert des Blocks, der die Transaktion enthält, addiert. Sobald eine bestimmte Anzahl von Münzen in Umlauf gebracht wurde, kann der Anreiz vollständig in Transaktionsgebühren umgewandelt werden und ist dann völlig inflationsfrei.

Der Anreiz kann dazu beitragen, Knoten zu ermutigen, ehrlich zu bleiben. Wenn ein gieriger Angreifer in der Lage ist, mehr CPU-Leistung als alle ehrlichen Knoten zu sammeln, müsste er sich entscheiden, ob er sie zum Betrug nutzt, indem er seine Zahlungen zurückstiehlt, oder ob er sie zur Erzeugung neuer Münzen verwendet. Es dürfte für ihn profitabler sein, sich an die Regeln zu halten, die ihn mit mehr neuen Münzen als alle anderen zusammen begünstigen, als das System und die Gültigkeit seines eigenen Reichtums zu untergraben.

7. Rückgewinnung von Speicherplatz

Sobald die letzte Transaktion einer Münze unter einer ausreichenden Anzahl von Blöcken begraben ist, können die davor liegenden Transaktionen verworfen werden, um Speicherplatz zu sparen. Um dies zu erleichtern, ohne den Hash des Blocks zu zerstören, werden die Transaktionen in einem Merkle-Baum [7][2][5] gehasht, wobei nur die Wurzel in den Hash des Blocks aufgenommen wird. Alte Blöcke können dann durch Abschneiden von Zweigen des Baums verdichtet werden. Die inneren Hashes brauchen nicht gespeichert zu werden.

Ein Blockkopf ohne Transaktionen würde etwa 80 Byte umfassen. Wenn wir davon ausgehen, dass alle 10 Minuten Blöcke erzeugt werden, ergeben sich 80 Byte * 6 * 24 * 365 = 4,2 MB pro Jahr. Da Computersysteme ab 2008 in der Regel mit 2 GB Arbeitsspeicher verkauft werden und das Mooresche Gesetz ein Wachstum von 1,2 GB pro Jahr vorhersagt, sollte die Speicherung kein Problem darstellen, selbst wenn die Blockheader im Speicher gehalten werden müssen.

8. Vereinfachte Zahlungsüberprüfung

Es ist möglich, Zahlungen zu überprüfen, ohne einen kompletten Netzwerkknoten zu betreiben. Ein Benutzer muss nur eine Kopie der Blockheader der längsten Proof-of-Work-Kette aufbewahren, die er durch Abfragen von Netzwerkknoten erhalten kann, bis er überzeugt ist, dass er die längste Kette hat, und den Merkle-Zweig erhalten, der die Transaktion mit dem Block verbindet, in dem sie zeitgestempelt ist. Er kann die Transaktion nicht selbst überprüfen, aber indem er sie mit einer Stelle in der Kette verknüpft, kann er sehen, dass ein Netzwerkknoten sie akzeptiert hat, und Blöcke, die danach hinzugefügt wurden, bestätigen, dass das Netzwerk sie akzeptiert hat.

Daher ist die Überprüfung zuverlässig, solange ehrliche Knoten das Netz kontrollieren, aber anfälliger, wenn das Netz von einem Angreifer überwältigt wird. Während die Netzknoten Transaktionen selbst überprüfen können, kann die vereinfachte Methode durch die gefälschten Transaktionen eines Angreifers getäuscht werden, solange dieser das Netz kontrollieren kann. Eine Strategie zum Schutz dagegen wäre, dass die Netzwerkknoten Warnmeldungen akzeptieren, wenn sie einen ungültigen Block entdecken, und die Software des Benutzers auffordern, den vollständigen Block und die gewarnten Transaktionen herunterzuladen, um die Inkonsistenz zu bestätigen. Unternehmen, die häufig Zahlungen erhalten, werden wahrscheinlich weiterhin ihre eigenen Knoten betreiben wollen, um eine unabhängigere Sicherheit und eine schnellere Überprüfung zu gewährleisten.

9. Kombinieren und Aufteilen von Werten

Obwohl es möglich wäre, Münzen einzeln zu behandeln, wäre es unhandlich, für jeden Cent einer Überweisung eine eigene Transaktion durchzuführen. Damit Werte geteilt und kombiniert werden können, enthalten Transaktionen mehrere Ein- und Ausgänge. Normalerweise gibt es entweder einen einzigen Eingang aus einer größeren vorherigen Transaktion oder mehrere Eingänge, die kleinere Beträge kombinieren, und höchstens zwei Ausgänge: einen für die Zahlung und einen, der das Wechselgeld, falls vorhanden, an den Absender zurückgibt.

Es ist anzumerken, dass ein Fan-Out, bei dem eine Transaktion von mehreren Transaktionen abhängt und diese wiederum von vielen weiteren Transaktionen abhängen, hier kein Problem darstellt. Es besteht nie die Notwendigkeit, eine vollständige, eigenständige Kopie der Geschichte einer Transaktion zu extrahieren.

10. Datenschutz

Das traditionelle Bankmodell erreicht ein gewisses Maß an Privatsphäre, indem es den Zugang zu Informationen auf die beteiligten Parteien und die Vertrauensperson beschränkt. Die Notwendigkeit, alle Transaktionen öffentlich bekannt zu geben, schließt diese Methode aus, aber die Privatsphäre kann dennoch gewahrt werden, indem der Informationsfluss an anderer Stelle unterbrochen wird: durch die Anonymität der öffentlichen Schlüssel. Die Öffentlichkeit kann sehen, dass jemand einen Betrag an eine andere Person sendet, aber ohne Informationen, die die Transaktion mit jemandem verbinden. Dies ist vergleichbar mit den Informationen, die von den Börsen herausgegeben werden, wo der Zeitpunkt und der Umfang der einzelnen Transaktionen, das "Band", veröffentlicht werden, ohne jedoch zu sagen, wer die Parteien waren.

Als zusätzliche Firewall sollte für jede Transaktion ein neues Schlüsselpaar verwendet werden, um zu verhindern, dass sie mit einem gemeinsamen Eigentümer verknüpft werden. Ein gewisses Maß an Verknüpfung ist bei Transaktionen mit mehreren Eingängen unvermeidlich, da diese zwangsläufig erkennen lassen, dass ihre Eingänge demselben Eigentümer gehörten. Das Risiko besteht darin, dass, wenn der Eigentümer eines Schlüssels offengelegt wird, die Verknüpfung andere Transaktionen aufdecken könnte, die demselben Eigentümer gehörten.

11. Berechnungen

Wir betrachten das Szenario, dass ein Angreifer versucht, eine alternative Kette schneller als die ehrliche Kette zu erzeugen. Selbst wenn dies gelingt, ist das System nicht anfällig für willkürliche Änderungen, wie z. B. die Schaffung von Werten aus dem Nichts oder die Entnahme von Geld, das dem Angreifer nie gehörte. Die Knoten werden eine ungültige Transaktion nicht als Zahlung akzeptieren, und ehrliche Knoten werden niemals einen Block akzeptieren, der sie enthält. Ein Angreifer kann nur versuchen, eine seiner eigenen Transaktionen zu ändern, um Geld zurückzubekommen, das er kürzlich ausgegeben hat.

Das Rennen zwischen der ehrlichen Kette und einer Angreiferkette kann als Binomial Random Walk charakterisiert werden. Das Erfolgsereignis ist die Verlängerung der ehrlichen Kette um einen Block, wodurch sich ihr Vorsprung um +1 erhöht, und das Misserfolgsereignis ist die Verlängerung der Kette des Angreifers um einen Block, wodurch sich der Abstand um -1 verringert.

Die Wahrscheinlichkeit, dass ein Angreifer einen gegebenen Rückstand aufholt, ist analog zum Gambler's-Ruin-Problem. Nehmen wir an, ein Spieler mit unbegrenztem Guthaben beginnt mit einem Defizit und spielt eine potenziell unendliche Anzahl von Versuchen, um die Gewinnschwelle zu erreichen. Die Wahrscheinlichkeit, dass er jemals die Gewinnschwelle erreicht oder dass ein Angreifer die ehrliche Kette einholt, lässt sich wie folgt berechnen [8]:

p = Wahrscheinlichkeit, dass ein ehrlicher Knoten den nächsten Block findet
q = Wahrscheinlichkeit, dass der Angreifer den nächsten Block findet
qz = Wahrscheinlichkeit, dass der Angreifer jemals einen Rückstand von z Blöcken aufholt

Unter der Annahme, dass p > q ist, nimmt die Wahrscheinlichkeit exponentiell ab, wenn die Anzahl der Blöcke, die der Angreifer aufholen muss, steigt. Wenn der Angreifer nicht schon früh einen glücklichen Sprung nach vorne macht, werden seine Chancen verschwindend gering, je weiter er zurückfällt.

Wir betrachten nun, wie lange der Empfänger einer neuen Transaktion warten muss, bevor er hinreichend sicher sein kann, dass der Absender die Transaktion nicht ändern kann. Wir gehen davon aus, dass der Absender ein Angreifer ist, der dem Empfänger vorgaukeln will, dass er ihn eine Zeit lang bezahlt hat, um dann nach einiger Zeit die Transaktion zu ändern und sich selbst zu bezahlen. Der Empfänger wird gewarnt, wenn dies geschieht, aber der Absender hofft, dass es zu spät sein wird.

Der Empfänger erzeugt ein neues Schlüsselpaar und gibt den öffentlichen Schlüssel kurz vor der Unterzeichnung an den Absender weiter. Dadurch wird verhindert, dass der Absender eine Kette von Blöcken im Voraus vorbereitet, indem er kontinuierlich daran arbeitet, bis er das Glück hat, weit genug voraus zu sein, und die Transaktion dann in diesem Moment ausführt. Sobald die Transaktion abgeschickt ist, beginnt der unehrliche Absender im Geheimen an einer parallelen Kette zu arbeiten, die eine alternative Version seiner Transaktion enthält.

Der Empfänger wartet, bis die Transaktion zu einem Block hinzugefügt wurde und z Blöcke nach ihr verlinkt wurden. Er kennt den genauen Fortschritt, den der Angreifer gemacht hat, nicht, aber unter der Annahme, dass die ehrlichen Blöcke die durchschnittlich erwartete Zeit pro Block benötigt haben, wird der potenzielle Fortschritt des Angreifers eine Poisson-Verteilung mit Erwartungswert sein:

Um die Wahrscheinlichkeit zu erhalten, dass der Angreifer jetzt noch aufholen könnte, multiplizieren wir die Poisson-Dichte für jeden Fortschritt, den er gemacht haben könnte, mit der Wahrscheinlichkeit, dass er ab diesem Punkt aufholen könnte:

Um den unendlichen Schwanz der Verteilung nicht zu summieren, wird umgeordnet...

Konvertierung in C-Code...

#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}

Anhand einiger Ergebnisse können wir sehen, dass die Wahrscheinlichkeit exponentiell mit z abnimmt.

q=0.1
z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137
z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012

q=0.3
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006

Solving for P less than 0.1%...

P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340

12. Schlußfolgerung

Wir haben ein System für elektronische Transaktionen vorgeschlagen, das sich nicht auf Vertrauen stützt. Wir begannen mit dem üblichen Rahmen von Münzen, die aus digitalen Signaturen bestehen, was eine starke Kontrolle des Eigentums ermöglicht, aber unvollständig ist, da es keine Möglichkeit gibt, Doppelausgaben zu verhindern. Um dieses Problem zu lösen, haben wir ein Peer-to-Peer-Netzwerk vorgeschlagen, das Proof-of-Work verwendet, um einen öffentlichen Transaktionsverlauf aufzuzeichnen, der für einen Angreifer schnell rechnerisch unpraktisch wird, wenn ehrliche Knoten eine Mehrheit der CPU-Leistung kontrollieren. Das Netzwerk ist durch seine unstrukturierte Einfachheit robust. Die Knoten arbeiten alle auf einmal und mit wenig Koordination. Sie müssen nicht identifiziert werden, da Nachrichten nicht an einen bestimmten Ort weitergeleitet werden und nur nach bestem Bemühen zugestellt werden müssen. Die Knoten können das Netz nach Belieben verlassen und wieder eintreten, wobei sie die Proof-of-Work-Kette als Beweis dafür akzeptieren, was während ihrer Abwesenheit geschehen ist. Sie stimmen mit ihrer CPU-Leistung ab, indem sie gültige Blöcke akzeptieren, indem sie an deren Erweiterung arbeiten, und ungültige Blöcke ablehnen, indem sie sich weigern, an ihnen zu arbeiten. Alle erforderlichen Regeln und Anreize können mit diesem Konsensmechanismus durchgesetzt werden.

References

[1] W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998.

[2] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal

trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999.

[3] S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no

2, pages 99-111, 1991.

[4] D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital time-stamping,"

In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.

[5] S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference

on Computer and Communications Security, pages 28-35, April 1997.

[6] A. Back, "Hashcash - a denial of service counter-measure,"

http://www.hashcash.org/papers/hashcash.pdf, 2002.

[7] R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and

Privacy, IEEE Computer Society, pages 122-133, April 1980.

[8] W. Feller, "An introduction to probability theory and its applications," 1957.

JETZT LOSLEGEN - BITCOINS MISCHEN

whir.store