Topic: Satoshi Nakamoto's Bitcoin Whitepaper auf deutsch? (Read 4591 times)

Vieleicht möchte ja wieder jemand 2 BTC für die Übersetzung spenden? Hätte heute einen ganz anderen Reiz als 2012 

sind auf Englisch. Für eine Einführung brauchst du das Paper nicht.
Na ja dei N... S... A... und deren Auftrags Arbeiter komunizieren halt auf Englisch

...soeben geschehen.

Wie schon im Pad geschrieben, würde ich vorschlagen, das ganze unter einer CC (BY)-NC-SA 3.0-Lizenz zu veröffentlichen. Ich arbeite öfter als Übersetzer und hätte daher u.U. Interesse an einer (pseudonymen) Namensnennung. Ganz sicher bin ich mir aber noch nicht, weil es ja durchaus viele Autoren werden könnten (vielleicht bleibt es auch nur bei zweien)

Spenden nehme ich gerne unter 165N1PmeD7uRTagpUSXVF7kVPARKHocpFC entgegen.

 

Für 10 Euro?

Anforderungen: Der Übersetzer muss sehr gut Deutsch in Wort und Schrift beherrschen und wenigstens gutes Englisch. Außerdem muss es ein Übersetzer für technische/mathematische Dokumente sein. Das kostet gleich nochmal extra. Zu tun haben wird er daran einige Tage. Ich schätze, dass so etwas Minimum ein paar hundert Euro kostet, eher mehr. 

Für 10 Euro erhälst Du dagegen kaum mehr als dieses Niveau:
...

Angebot: Ich spende ~2 BTC (10 EUR) für eine Übersetzung. Vielleicht schließt sich noch jemand an? Bis sich jemand findet, der  es ordentlich übersetzen kann/will. Wie viel BTC wäre eine Übersetzung wert?

Zusammenfassung.
Eine rein Peer-to-Peer-Version des elektronischen Geldes würde es Online
Zahlungen direkt von einer Partei zur anderen geschickt werden, ohne durch ein
Finanzinstitut. Digitale Signaturen stellen ein Teil der Lösung, aber die wichtigste
Vorteile gehen verloren, wenn eine vertrauenswürdige dritte Partei noch erforderlich ist, um Doppel-Ausgaben zu verhindern.
Wir schlagen vor, eine Lösung für die Doppel-Ausgaben Problem mit Hilfe eines Peer-to-Peer-Netzwerk.
Die Netzwerk-Zeitstempel-Transaktionen durch Hashing sie in eine laufende Kette von
Hash-basierte Proof-of-Arbeit und bildet einen Datensatz, der nicht ohne redoing kann geändert werden
Die Proof-of-Arbeit. Die längste Kette dient nicht nur als Beweis für die Abfolge von
Ereignisse miterlebt, sondern Beweis, dass es aus dem größten Pool an CPU-Leistung kam. Als
Solange ein Großteil der CPU-Leistung wird durch Knoten, die nicht kooperieren, um kontrolliert
Angriff auf das Netzwerk, werden sie erzeugen die längste Kette und übertreffen Angreifer. Die
Netzwerk selbst erfordert nur minimale Struktur. Die Nachrichten werden auf einer Best-Effort-Sendung
Grundlage und Knoten können zu verlassen und wieder in das Netzwerk nach Belieben, die Annahme der längste
Proof-of-work-Kette als Beweis dafür, was passiert, während sie weg waren.
1. Einführung
Handel im Internet ist gekommen, fast ausschließlich auf die Finanzinstitute, die als
Vertrauenspersonen auf elektronische Zahlungen zu verarbeiten. Während das System funktioniert gut genug für
die meisten Transaktionen, es leidet immer noch unter den inhärenten Schwächen des Vertrauens basiertes Modell.
Vollständig nicht-reversible Transaktionen sind nicht wirklich möglich, da Finanzinstitute nicht
Vermeidung von Streitigkeiten vermitteln. Die Kosten der Vermittlung erhöht die Transaktionskosten, die Begrenzung der
Minimum Transaktion praktische Größe und das Abschneiden der Möglichkeit für kleine Casual-Transaktionen,
und es gibt eine größere Kosten im Verlust der Fähigkeit, nicht reversible Zahlungen für nicht-make
reversible Dienstleistungen. Mit der Möglichkeit der Umkehr, das Bedürfnis nach Vertrauen breitet sich aus. Händler müssen
vorsichtig sein, ihre Kunden, hassling sie für mehr Informationen, als sie es sonst benötigen.
Ein gewisser Prozentsatz der Betrug wird als unvermeidbar akzeptiert. Diese Kosten und Zahlung Unsicherheiten
können persönlich durch physikalische Währung vermieden werden, aber kein Mechanismus existiert, um Zahlungen zu leisten
über einen Kommunikationskanal, ohne eine vertrauenswürdige Partei.
Was wir brauchen, ist ein elektronisches Zahlungssystem, das auf kryptographischen Beweis anstelle von Vertrauen,
so dass zwei beliebige bereit Parteien direkt miteinander abwickeln, ohne die Notwendigkeit für eine vertrauenswürdige
Dritter. Transaktionen, die rechnerisch nicht praktikabel, umkehren würden sich schützen Verkäufer
von Betrug und Routine Escrow-Mechanismen könnte leicht implementiert werden, um Käufer zu schützen. In
Dieses Papier schlagen wir eine Lösung für das Problem Doppel-Ausgaben über eine Peer-to-Peer-verteilt
Zeitstempel-Server zu rechnerischer Nachweis der chronologischen Reihenfolge der Transaktionen zu generieren. Die
system ist sicher, solange ehrlich Knoten kollektiv mehr CPU-Leistung als jede Kontrolle
kooperierende Gruppe Angreifer Knoten.
12. Transaktionen
Wir definieren eine elektronische Münze als eine Kette von digitalen Signaturen. Jeder Eigentümer überträgt die Münze, um die
Next by digitale Signieren eines Hash-Wert des vorherigen Transaktion und den öffentlichen Schlüssel des nächsten Besitzer
und Addieren dieser bis zum Ende der Münze. Ein Zahlungsempfänger kann keine Überprüfung der Signaturen, die Kette der Überprüfung
Eigentum.
Das Problem ist natürlich der Zahlungsempfänger kann nicht überprüfen, ob einer der Eigentümer nicht doppelt ausgeben
die Münze. Eine gängige Lösung ist, um eine vertrauenswürdige zentrale Behörde, oder Minze, die jeden prüft Einführung
Transaktion für Doppel-Ausgaben. Nach jeder Transaktion muss die Münze in die Münze zurückgegeben werden
dann eine neue Münze, und nur Münzen direkt aus der Münze ausgegeben werden als vertrauenswürdig nicht zu sein doppelt ausgegeben.
Das Problem bei dieser Lösung ist, dass das Schicksal des gesamten Geld-System auf das hängt
Unternehmen laufen die Minze, mit jeder Transaktion zu müssen, durch sie gehen, genau wie eine Bank.
Wir brauchen eine Möglichkeit für den Empfänger zu wissen, dass die bisherigen Eigentümer nicht alle älteren Zeichens
Transaktionen. Für unsere Zwecke ist die früheste der Transaktion ein, die zählt, so dass wir kein Interesse daran haben
Über spätere Versuche, doppelklicken verbringen. Der einzige Weg, um die Abwesenheit einer Transaktion zu bestätigen ist,
sich bewusst sein, über alle Transaktionen. In der Minze basiertes Modell, war die Minze bewusst über alle Transaktionen und
entschieden, welche ankamen. Um dies ohne eine vertrauenswürdige Partei zu erreichen, müssen Transaktionen sein
öffentlich angekündigt [1], und wir brauchen ein System für die Teilnehmer auf einer einzigen Geschichte des zustimmen
Reihenfolge, in der sie empfangen wurden. Der Zahlungsempfänger muss Beweis dafür, dass zum Zeitpunkt der einzelnen Transaktionen, die
Mehrheit der Knoten vereinbart war es das erste erhielt.
3. Zeitstempel-Server
Die von uns vorgeschlagene Lösung beginnt mit einem Zeitstempel-Server. Ein Zeitstempel-Server arbeitet, indem sie ein
Hash-Wert eines Blocks von Elementen Zeitstempel und allgemein die Hash-Veröffentlichung, wie in
Zeitung oder Usenet-Beitrag [2-5]. Der Zeitstempel beweist, dass die Daten müssen an die existiert haben
Zeit offensichtlich, um in den Hash zu erhalten. Jeder Zeitstempel enthält die Vorgängerversion Zeitstempel in
seinen Hash, eine Kette bilden, wobei jede zusätzliche Verstärkung Zeitstempel diejenigen davor.
... Proof-of-Work
Um eine verteilte Zeitstempel-Server auf einem Peer-to-Peer-Basis zu implementieren, müssen wir einen Beweis dafür zu verwenden-
der-Arbeit-System ähnlich wie Adam Zurück zu Hashcash [6], anstatt Zeitung oder Usenet-Postings.
Der Proof-of-Arbeit umfasst das Scannen für einen Wert, wenn gehasht, wie mit SHA-256, das
Hash beginnt mit einer Anzahl von Null-Bits. Die durchschnittliche Arbeit erforderlich ist exponentiell in der Anzahl
mit Null-Bits erforderlich und kann durch das Ausführen einer einzelnen Hash verifiziert werden.
Für unsere Zeitstempel Netzwerk setzen wir das Proof-of-Arbeit durch Inkrementieren eines Nonce in der
blockiert, bis ein Wert gefunden wird, das es dem Block der Hash die erforderlichen Null-Bits. Sobald die CPU
Anstrengungen unternommen wurden aufgewendet, um es zu befriedigen den Proof-of-Arbeit, kann der Block nicht geändert werden
ohne nochmal die Arbeit. Wie später Blöcke gekettet, nachdem sie sind, um die Arbeit ändern Sie den Block
würde redoing alle Blöcke danach.
Der Proof-of-Arbeit löst auch das Problem der Bestimmung Vertretung in Mehrheitsentscheidung
machen. Wenn die Mehrheit auf einem IP-Adresse-one-vote basieren würde, könnte sie von niemandem unterlaufen werden
der Lage, viele IPs zuordnen. Proof-of-Arbeit ist im Prinzip ein-CPU-one-vote. Die Mehrheit
Entscheidung wird von der längsten Kette vertreten, was den größten Proof-of-Arbeitsaufwand investiert
darin. Wenn eine Mehrheit der CPU-Leistung durch ehrliche Knoten gesteuert wird, wird die Kette ehrlich wachsen die
schnellste und übertreffen alle konkurrierenden Supermarktketten. Um einen letzten Block zu ändern, müsste ein Angreifer zu
wiederholen Sie den Proof-of-Arbeit des Blockes und allen Blöcken, nachdem sie und dann einholen und übertreffen die
Arbeit der ehrlichen Knoten. Wir werden später zeigen, dass die Wahrscheinlichkeit einer langsameren Angreifer bis Fang
nimmt exponentiell nachfolgenden Blöcke hinzugefügt werden.
Um zur Erhöhung der Geschwindigkeit und Hardware unterschiedliche Interesse an einer Kandidatur Knoten im Laufe der Zeit zu kompensieren,
Die Proof-of-Arbeit Schwierigkeit wird durch einen gleitenden Durchschnitt dem Ziel eines durchschnittlichen Anzahl der ermittelten
Blöcke pro Stunde. Wenn sie zu schnell sind generiert, erhöht sich der Schwierigkeitsgrad.
5. Netzwerk
Die Schritte, um das Netzwerk ausgeführt sind wie folgt:
1) Neue Transaktionen werden an alle Knoten gesendet.
2) Jeder Knoten sammelt neue Transaktionen zu einem Block.
3) Jeder Knoten arbeitet auf der Suche nach einem schwierigen Proof-of-Arbeit für seinen Block.
4) Wenn ein Knoten eine Proof-of-Arbeit findet, sendet er den Block auf allen Knoten.
5) Die Knoten akzeptieren die Sperre nur, wenn alle Transaktionen in sie gültig und nicht bereits ausgegeben sind.
6) Nodes drücken ihre Akzeptanz des Blocks durch die Arbeit an der Erstellung des nächsten Block in die
Kette, mit dem Hash der akzeptierten Block wie die vorherige Hash.
Knoten stets die längste Kette, um die richtige sein und arbeiten weiter an
Sie erweitert wird. Wenn zwei Knoten gesendet verschiedene Versionen des nächsten Blocks gleichzeitig einige
Knoten werden möglicherweise eine oder das andere zuerst. In diesem Fall arbeiten sie auf dem ersten erhielten,
sondern speichern Sie die anderen Zweig, falls es länger wird. Die Krawatte wird gebrochen, wenn der nächste Proof-werden
der-Arbeit gefunden wird, und ein Zweig wird länger, die Knoten, die auf der anderen Arbeiten wurden
Filiale wird dann auf die längere zu wechseln.

... Neue Transaktion Sendungen nicht unbedingt alle Knoten erreichen. Solange sie erreichen
viele Knoten, werden sie in einen Block zu erhalten, bevor lange. Block-Sendungen sind auch tolerant gegenüber fallen gelassen
Nachrichten. Wenn ein Knoten nicht erhält einen Block, fordert es, wenn es den nächsten Block erhält und
realisiert es verpasste ein.
6. Anreiz
Gemäß der Konvention ist die erste Transaktion in einem Block eine spezielle Transaktion, die eine neue Münze im Besitz beginnt
vom Ersteller des Blocks. Dies fügt einen Anreiz für die Knoten, um das Netzwerk zu unterstützen, und bietet
ein Weg, um zunächst zu verteilen Münzen in Umlauf gebracht, da es keine zentrale Autorität, um sie auszustellen.
Der stetige Zugabe einer konstanten Menge an der neuen Münzen ist analog zum Goldgräber aufwendet
Ressourcen, um Gold zu Umlauf hinzuzufügen. In unserem Fall ist es CPU-Zeit und Strom, die verbraucht ist.
Der Anreiz kann auch mit Transaktionsgebühren finanziert werden. Wenn der Ausgabewert einer Transaktion ist
weniger als der Eingabewert, der Unterschied ist eine Transaktionsgebühr, das mit dem Anreiz Wert hinzugefügt
der Block die Transaktion. Sobald eine vorbestimmte Anzahl von Münzen eingegeben
Kreislauf, kann der Anreiz Übergang ganz zu Transaktionsgebühren und völlig Inflation
frei.
Der Anreiz kann helfen, ermutigen Knoten ehrlich zu bleiben. Wenn ein gieriger Angreifer in der Lage,
zusammenzubauen mehr CPU-Leistung als alle ehrlichen Knoten, müsste er zwischen der Verwendung es wählen
die Menschen durch Diebstahl wieder seine Zahlungen ein, oder verwenden es, um neue Münzen zu erzeugen betrügen. Er sollte
finde es profitabler an die Regeln, wie Regeln, die ihn mit mehr neue Münzen zu begünstigen, als spielen
alle anderen kombiniert, als um das System und die Gültigkeit seiner eigenen Reichtum zu untergraben.
7. Reclaiming Disk Space
Sobald die Transaktion spätestens in einer Münze wird unter genügend Blöcke begraben, die verbrauchten Transaktionen vor
es kann verworfen werden, um Speicherplatz zu sparen werden. Um dies ohne Bruch des Blocks Hash zu erleichtern,
Transaktionen werden in einer Hash-Baum Merkle [7] [2] [5], wobei nur in der Wurzel des Blocks Hash enthalten.
Alte Blöcke können dann durch Anstoßen Äste des Baumes verdichtet werden. Die Innen-Hashes zu tun
nicht gespeichert werden müssen.
Ein Block-Header ohne Transaktion würde ungefähr 80 Bytes sein. Wenn wir annehmen, Blöcke sind
generiert alle 10 Minuten, 80 Byte * 6 * 24 * 365 = 4,2 MB pro Jahr. Mit EDV-Systeme
in der Regel den Verkauf mit 2 GB RAM als 2008, und Moores Gesetz Vorhersage aktuellen Wachstum von
1,2 GB pro Jahr, sollte die Speicherung kein Problem, auch wenn die Block-Header in sein müssen eingehalten werden
Speicher.
...
Vereinfachte Zahlungsverifikationsinstruments
Es ist möglich, Zahlungen ohne Ausführung der vollständigen Netzwerk-Knoten zu überprüfen. Ein Nutzer muss nur zu halten
eine Kopie der Block-Header der längsten Proof-of-work-Kette, die er bekommen kann durch Abfragen
Netzknoten, bis er ist überzeugt, er hat die längste Kette, und erhalten die Filiale Merkle
Verknüpfung der Transaktion auf den Block, es ist timestamped in. Er kann nicht überprüfen, das Geschäft für
sich selbst, sondern indem sie ihn mit einem Platz in der Kette, kann er sehen, dass ein Netzknoten hat es akzeptiert,
und Blöcke hinzugefügt werden, nachdem es zu bestätigen weiter die Netzwerk akzeptiert wurde.
Als solche ist die Überprüfung zuverlässig, solange ehrlich Knoten des Netzwerks zu steuern, ist aber
verwundbar, wenn das Netzwerk von einem Angreifer überwältigt. Während Netzknoten können überprüfen
Transaktionen für sich selbst, kann das vereinfachte Verfahren durch eines Angreifers hergestellt täuschen
Transaktionen, solange der Angreifer kann weiterhin das Netzwerk zu überwältigen. Eine Strategie zur
Schutz gegen diese wäre die Warnungen von Netzknoten zu akzeptieren, wenn sie eine ungültige erkennen
Block, woraufhin die Software des Benutzers, um den vollen Block herunterladen und alarmierte Transaktionen zu
bestätigen die Inkonsequenz. Unternehmen, die häufig Zahlungen empfangen wird wahrscheinlich immer noch wollen
betreiben ihre eigenen Knoten für mehr Sicherheit und schnellere unabhängige Überprüfung.
9. Vereinigen und Aufspalten von Wert
Zwar wäre es möglich, Münzen einzeln zu behandeln, wäre es unhandlich, um eine Marke
separate Transaktion für jeden Cent zu einer Übertragung. Damit Wert zu spalten und kombiniert werden,
Transaktionen enthalten mehrere Ein-und Ausgänge. Normalerweise wird es entweder eine einzelne Eingabe
aus einer größeren vorherigen Transaktion oder mehrere Eingänge Kombination kleinerer Mengen, und höchstens zwei
Ausgänge: eine für die Zahlung, und eine Rücksendung der Veränderung, wenn überhaupt, an den Absender zurück.
Es sollte angemerkt werden, dass Fan-Out, wenn das Geschäft hängt von mehreren Transaktionen und die
Transaktionen hängen von vielen mehr, ist nicht ein Problem hier. Es gibt nie die Notwendigkeit, ein Extrakt
komplette, eigenständige Kopie einer Transaktion der Geschichte.
...

Das traditionelle Geschäftsmodell erreicht einen Grad an Privatsphäre, indem der Zugriff auf Informationen, um die
beteiligten Parteien und der vertrauenswürdigen Dritten. Die Notwendigkeit, alle Transaktionen öffentlich bekannt
schließt diese Methode, aber kann der Datenschutz dennoch durch das Brechen der Fluss von Informationen in beibehalten werden
ein weiterer Ort: indem sie die öffentlichen Schlüssel anonym. Die Öffentlichkeit kann sehen, dass jemand sendet
ein Betrag an jemand anderen, aber ohne Informationen Verknüpfung der Transaktion an Dritte weiter. Dies ist
etwa auf dem Niveau von Informationen durch die Börsen veröffentlicht, in denen die Zeit und die Größe der
einzelnen Gewerke, die "Band", wird öffentlich gemacht, aber ohne zu sagen wer die Vertragspartner waren.
Als zusätzliche Firewall, sollte ein neues Schlüsselpaar für jede Transaktion verwendet werden, um sie zu halten
eine Verbindung mit einem gemeinsamen Eigentümers. Einige Verknüpfung vor unvermeidbar ist mit Multi-Input
Transaktionen, die unbedingt zeigen, dass ihre Eingänge vom gleichen Besitzer gehörten. Das Risiko
ist, dass, wenn der Besitzer eines Schlüssels wird enthüllt, Verknüpfen könnte andere Transaktionen, die zu offenbaren gehörte
der gleiche Besitzer.
11. Die Berechnungen
Wir betrachten das Szenario, dass ein Angreifer versucht, eine alternative Kette erzeugen schneller als der ehrliche
Kette. Selbst wenn dies erreicht ist, dauert es nicht werfen das System offen für beliebige Veränderungen, wie
wie die Wertschöpfung aus der Luft oder unter Geld, das nie gehörte der Angreifer. Die Knoten sind
nicht auf eine ungültige Transaktion als Zahlungsmittel zu akzeptieren, und ehrlich Knoten werde nie akzeptieren, einen Block
diese enthalten. Ein Angreifer kann nur versuchen, einen seiner eigenen Transaktionen ändern zurück zu nehmen
Geld, das er vor kurzem verbrachte.
Das Rennen zwischen dem ehrlichen Kette und einem Angreifer Kette kann als Binomial charakterisiert werden
Random Walk. Der Erfolg der Veranstaltung ist ehrlich Kette durch einen Block erweitert, die Verbesserung seiner
führen durch ein und das Versagen Veranstaltung wird vom Angreifer Kette durch einen Block erweitert, wodurch die
Lücke von -1.
Die Wahrscheinlichkeit, dass ein Angreifer holt aus einer gegebenen Defizit ist analog eines Spielers
Ruin-Problem. Angenommen, ein Spieler mit unbegrenzten Kredit beginnt bei einem Defizit und spielt möglicherweise ein
unendliche Anzahl von Studien, um zu versuchen die Gewinnschwelle zu erreichen. Wir können die Wahrscheinlichkeit berechnen, die er je
Break-even erreicht, oder dass ein Angreifer immer holt den ehrlichen Kette, wie folgt [8]:
...
Traditionelle Datenschutz ModelGiven unsere Annahme, daß p> q ist die Wahrscheinlichkeit, exponentiell mit der Anzahl von Blöcken der abfällt
Angreifer hat den Anschluss an steigt. Mit den Chancen gegen ihn, wenn er nicht einen glücklichen
Ausfallschritt nach vorn früh, sich seine Chancen verschwindend gering, während er weiter in Verzug gerät.
Wir betrachten nun, wie lange der Empfänger einer neuen Transaktion zu warten, bevor sie braucht
hinreichend sicher der Absender nicht ändern können, die Transaktion. Wir nehmen an, der Absender ist ein Angreifer
wer will, um die Empfänger glauben, dass er bezahlte ihn für eine Weile, dann schalten Sie es zurück zu zahlen, um
sich nach einiger Zeit ist vergangen. Der Empfänger wird alarmiert, wenn das passiert, aber die
Absender hofft, es wird zu spät sein.
Der Receiver erzeugt ein neues Schlüsselpaar und gibt den öffentlichen Schlüssel an den Sender kurz vor
Unterzeichnung. Dies verhindert, dass Sie den Absender von der Vorbereitung einer Kette von Blöcken vor der Zeit durch die Arbeit an
es kontinuierlich, bis er das Glück hat, weit genug vorwärts zu kommen, dann die Ausführung der Transaktion an
in diesem Moment. Sobald die Transaktion gesendet wird, beginnt das unehrlich Absender im Geheimen arbeiten auf ein
parallel Kette, die eine alternative Version seines Transaktion.
Der Empfänger wartet, bis die Transaktion zu einem Block hinzugefügt und z Bausteine ​​sind
verbunden, nachdem sie. Er weiß nicht, die genaue Höhe der Fortschritt der Angreifer gemacht hat, aber
vorausgesetzt, die ehrlich Blöcken nahm die erwartete durchschnittliche Zeit pro Block, der Angreifer Potenzial
Fortschritt wird eine Poisson-Verteilung mit Erwartungswert sein:
...
Um die Wahrscheinlichkeit der Angreifer immer noch fangen konnte bis jetzt bekommen, multiplizieren wir die Poisson-Dichte für
jede Menge Fortschritte, die er mit der Wahrscheinlichkeit, er aufholen konnte von diesem Zeitpunkt hätte machen können:
...
12. Abschluss
Wir haben ein System für elektronische Transaktionen, ohne sich auf Vertrauen vorgeschlagen. Wir begannen mit
den üblichen Rahmen von Münzen aus digitalen Signaturen aus, die starke Kontrolle bietet
Eigentum, sondern ist unvollständig ohne einen Weg zu Doppel-Ausgaben zu verhindern. Um das zu lösen, wir
vorgeschlagen, eine Peer-to-Peer-Netzwerk mit Proof-of-Arbeit, um eine öffentliche Geschichte der Transaktionen aufzeichnen
das wird schnell unpraktisch rechnerisch für einen Angreifer, wenn ehrlich Knoten ändern
kontrollieren einen Großteil der CPU-Leistung. Das Netzwerk ist in seiner Einfachheit unstrukturierten robust. Nodes
arbeiten alle auf einmal mit wenig Koordination. Sie müssen nicht identifiziert werden, da Nachrichten
nicht auf eine bestimmte Stelle weitergeleitet und müssen nur auf einer Best-Effort-Basis ausgeliefert werden. Knoten können
verlassen und wieder in das Netzwerk nach Belieben, die Annahme des Proof-of-work-Kette als Beweis dafür, was
geschah, während sie weg waren. Sie mit ihren CPU-Leistung stimmen, geben, ihre Akzeptanz
gültigen Blöcke durch die Arbeit an deren Ausweitung und ungültigen Blöcke durch die Weigerung, auf Arbeit
sie. Alle benötigten Regeln und Anreize können mit diesem Mechanismus Konsens durchgesetzt werden.
8References

Der Text würde fast nur aus Anglizismen oder Wörtern bestehen, die nicht im deutschen Sprachgebrauch vorkommen ("block header" = Blockkopfteil?!).

Bitcoin: A Peer-to-Peer Electronic Cash System
Satoshi Nakamoto
[email protected]
www.bitcoin.org
Abstract.
A purely peer-to-peer version of electronic cash would allow online
payments to be sent directly from one party to another without going through a
financial institution.  Digital signatures provide part of the solution, but the main
benefits are lost if a trusted third party is still required to prevent double-spending.
We propose a solution to the double-spending problem using a peer-to-peer network.
The network timestamps transactions by hashing them into an ongoing chain of
hash-based proof-of-work, forming a record that cannot be changed without redoing
the proof-of-work.  The longest chain not only serves as proof of the sequence of
events witnessed, but proof that it came from the largest pool of CPU power.  As
long as a majority of CPU power is controlled by nodes that are not cooperating to
attack the network, they'll generate the longest chain and outpace attackers.  The
network itself requires minimal structure.  Messages are broadcast on a best effort
basis, and nodes can leave and rejoin the network at will, accepting the longest
proof-of-work chain as proof of what happened while they were gone.
1. Introduction
Commerce on the Internet has come to rely almost exclusively on financial institutions serving as
trusted third parties to process electronic payments.  While the system works well enough for
most transactions, it still suffers from the inherent weaknesses of the trust based model.
Completely non-reversible transactions are not really possible, since financial institutions cannot
avoid mediating disputes.  The cost of mediation increases transaction costs, limiting the
minimum practical transaction size and cutting off the possibility for small casual transactions,
and there is a broader cost in the loss of ability to make non-reversible payments for non-
reversible services.  With the possibility of reversal, the need for trust spreads.  Merchants must
be wary of their customers, hassling them for more information than they would otherwise need.
A certain percentage of fraud is accepted as unavoidable.  These costs and payment uncertainties
can be avoided in person by using physical currency, but no mechanism exists to make payments
over a communications channel without a trusted party.
What is needed is an electronic payment system based on cryptographic proof instead of trust,
allowing any two willing parties to transact directly with each other without the need for a trusted
third party.  Transactions that are computationally impractical to reverse would protect sellers
from fraud, and routine escrow mechanisms could easily be implemented to protect buyers.  In
this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed
timestamp server to generate computational proof of the chronological order of transactions.  The
system is secure as long as honest nodes collectively control more CPU power than any
cooperating group of attacker nodes.
12. Transactions
We define an electronic coin as a chain of digital signatures.  Each owner transfers the coin to the
next by digitally signing a hash of the previous transaction and the public key of the next owner
and adding these to the end of the coin.  A payee can verify the signatures to verify the chain of
ownership.
The problem of course is the payee can't verify that one of the owners did not double-spend
the coin.  A common solution is to introduce a trusted central authority, or mint, that checks every
transaction for double spending.  After each transaction, the coin must be returned to the mint to
issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent.
The problem with this solution is that the fate of the entire money system depends on the
company running the mint, with every transaction having to go through them, just like a bank.
We need a way for the payee to know that the previous owners did not sign any earlier
transactions.  For our purposes, the earliest transaction is the one that counts, so we don't care
about later attempts to double-spend.  The only way to confirm the absence of a transaction is to
be aware of all transactions.  In the mint based model, the mint was aware of all transactions and
decided which arrived first.  To accomplish this without a trusted party, transactions must be
publicly announced [1], and we need a system for participants to agree on a single history of the
order in which they were received.  The payee needs proof that at the time of each transaction, the
majority of nodes agreed it was the first received.
3. Timestamp Server
The solution we propose begins with a timestamp server.  A timestamp server works by taking a
hash of a block of items to be timestamped and widely publishing the hash, such as in a
newspaper or Usenet post [2-5].  The timestamp proves that the data must have existed at the
time, obviously, in order to get into the hash.  Each timestamp includes the previous timestamp in
its hash, forming a chain, with each additional timestamp reinforcing the ones before it.
...Proof-of-Work
To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-
of-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts.
The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the
hash begins with a number of zero bits.  The average work required is exponential in the number
of zero bits required and can be verified by executing a single hash.
For our timestamp network, we implement the proof-of-work by incrementing a nonce in the
block until a value is found that gives the block's hash the required zero bits.  Once the CPU
effort has been expended to make it satisfy the proof-of-work, the block cannot be changed
without redoing the work.  As later blocks are chained after it, the work to change the block
would include redoing all the blocks after it.
The proof-of-work also solves the problem of determining representation in majority decision
making.  If the majority were based on one-IP-address-one-vote, it could be subverted by anyone
able to allocate many IPs.  Proof-of-work is essentially one-CPU-one-vote.  The majority
decision is represented by the longest chain, which has the greatest proof-of-work effort invested
in it.  If a majority of CPU power is controlled by honest nodes, the honest chain will grow the
fastest and outpace any competing chains.  To modify a past block, an attacker would have to
redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the
work of the honest nodes.  We will show later that the probability of a slower attacker catching up
diminishes exponentially as subsequent blocks are added.
To compensate for increasing hardware speed and varying interest in running nodes over time,
the proof-of-work difficulty is determined by a moving average targeting an average number of
blocks per hour.  If they're generated too fast, the difficulty increases.
5. Network
The steps to run the network are as follows:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block. 
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the
chain, using the hash of the accepted block as the previous hash.
Nodes always consider the longest chain to be the correct one and will keep working on
extending it.  If two nodes broadcast different versions of the next block simultaneously, some
nodes may receive one or the other first.  In that case, they work on the first one they received,
but save the other branch in case it becomes longer.  The tie will be broken when the next proof-
of-work is found and one branch becomes longer; the nodes that were working on the other
branch will then switch to the longer one.

...New transaction broadcasts do not necessarily need to reach all nodes.  As long as they reach
many nodes, they will get into a block before long.  Block broadcasts are also tolerant of dropped
messages.  If a node does not receive a block, it will request it when it receives the next block and
realizes it missed one.
6. Incentive
By convention, the first transaction in a block is a special transaction that starts a new coin owned
by the creator of the block.  This adds an incentive for nodes to support the network, and provides
a way to initially distribute coins into circulation, since there is no central authority to issue them. 
The steady addition of a constant of amount of new coins is analogous to gold miners expending
resources to add gold to circulation.  In our case, it is CPU time and electricity that is expended.
The incentive can also be funded with transaction fees.  If the output value of a transaction is
less than its input value, the difference is a transaction fee that is added to the incentive value of
the block containing the transaction.  Once a predetermined number of coins have entered
circulation, the incentive can transition entirely to transaction fees and be completely inflation
free.
The incentive may help encourage nodes to stay honest.  If a greedy attacker is able to
assemble more CPU power than all the honest nodes, he would have to choose between using it
to defraud people by stealing back his payments, or using it to generate new coins.  He ought to
find it more profitable to play by the rules, such rules that favour him with more new coins than
everyone else combined, than to undermine the system and the validity of his own wealth.
7. Reclaiming Disk Space
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before
it can be discarded to save disk space.  To facilitate this without breaking the block's hash,
transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash.
Old blocks can then be compacted by stubbing off branches of the tree.  The interior hashes do
not need to be stored.
A block header with no transactions would be about 80 bytes.  If we suppose blocks are
generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year.  With computer systems
typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of
1.2GB per year, storage should not be a problem even if the block headers must be kept in
memory.
...
Simplified Payment Verification
It is possible to verify payments without running a full network node.  A user only needs to keep
a copy of the block headers of the longest proof-of-work chain, which he can get by querying
network nodes until he's convinced he has the longest chain, and obtain the Merkle branch
linking the transaction to the block it's timestamped in.  He can't check the transaction for
himself, but by linking it to a place in the chain, he can see that a network node has accepted it,
and blocks added after it further confirm the network has accepted it.
As such, the verification is reliable as long as honest nodes control the network, but is more
vulnerable if the network is overpowered by an attacker.  While network nodes can verify
transactions for themselves, the simplified method can be fooled by an attacker's fabricated
transactions for as long as the attacker can continue to overpower the network.  One strategy to
protect against this would be to accept alerts from network nodes when they detect an invalid
block, prompting the user's software to download the full block and alerted transactions to
confirm the inconsistency.  Businesses that receive frequent payments will probably still want to
run their own nodes for more independent security and quicker verification.
9. Combining and Splitting Value
Although it would be possible to handle coins individually, it would be unwieldy to make a
separate transaction for every cent in a transfer.  To allow value to be split and combined,
transactions contain multiple inputs and outputs.  Normally there will be either a single input
from a larger previous transaction or multiple inputs combining smaller amounts, and at most two
outputs: one for the payment, and one returning the change, if any, back to the sender. 
It should be noted that fan-out, where a transaction depends on several transactions, and those
transactions depend on many more, is not a problem here.  There is never the need to extract a
complete standalone copy of a transaction's history.
...

The traditional banking model achieves a level of privacy by limiting access to information to the
parties involved and the trusted third party.  The necessity to announce all transactions publicly
precludes this method, but privacy can still be maintained by breaking the flow of information in
another place: by keeping public keys anonymous.  The public can see that someone is sending
an amount to someone else, but without information linking the transaction to anyone.  This is
similar to the level of information released by stock exchanges, where the time and size of
individual trades, the "tape", is made public, but without telling who the parties were.
As an additional firewall, a new key pair should be used for each transaction to keep them
from being linked to a common owner.  Some linking is still unavoidable with multi-input
transactions, which necessarily reveal that their inputs were owned by the same owner.  The risk
is that if the owner of a key is revealed, linking could reveal other transactions that belonged to
the same owner.
11. Calculations
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest
chain.  Even if this is accomplished, it does not throw the system open to arbitrary changes, such
as creating value out of thin air or taking money that never belonged to the attacker.  Nodes are
not going to accept an invalid transaction as payment, and honest nodes will never accept a block
containing them.  An attacker can only try to change one of his own transactions to take back
money he recently spent.
The race between the honest chain and an attacker chain can be characterized as a Binomial
Random Walk.  The success event is the honest chain being extended by one block, increasing its
lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the
gap by -1.
The probability of an attacker catching up from a given deficit is analogous to a Gambler's
Ruin problem.  Suppose a gambler with unlimited credit starts at a deficit and plays potentially an
infinite number of trials to try to reach breakeven.  We can calculate the probability he ever
reaches breakeven, or that an attacker ever catches up with the honest chain, as follows [8]:
...
Traditional Privacy ModelGiven our assumption that p > q, the probability drops exponentially as the number of blocks the
attacker has to catch up with increases.  With the odds against him, if he doesn't make a lucky
lunge forward early on, his chances become vanishingly small as he falls further behind.
We now consider how long the recipient of a new transaction needs to wait before being
sufficiently certain the sender can't change the transaction.  We assume the sender is an attacker
who wants to make the recipient believe he paid him for a while, then switch it to pay back to
himself after some time has passed.  The receiver will be alerted when that happens, but the
sender hopes it will be too late.
The receiver generates a new key pair and gives the public key to the sender shortly before
signing.  This prevents the sender from preparing a chain of blocks ahead of time by working on
it continuously until he is lucky enough to get far enough ahead, then executing the transaction at
that moment.  Once the transaction is sent, the dishonest sender starts working in secret on a
parallel chain containing an alternate version of his transaction.
The recipient waits until the transaction has been added to a block and z blocks have been
linked after it.  He doesn't know the exact amount of progress the attacker has made, but
assuming the honest blocks took the average expected time per block, the attacker's potential
progress will be a Poisson distribution with expected value:
...
To get the probability the attacker could still catch up now, we multiply the Poisson density for
each amount of progress he could have made by the probability he could catch up from that point:
...
12. Conclusion
We have proposed a system for electronic transactions without relying on trust.  We started with
the usual framework of coins made from digital signatures, which provides strong control of
ownership, but is incomplete without a way to prevent double-spending.  To solve this, we
proposed a peer-to-peer network using proof-of-work to record a public history of transactions
that quickly becomes computationally impractical for an attacker to change if honest nodes
control a majority of CPU power.  The network is robust in its unstructured simplicity.  Nodes
work all at once with little coordination.  They do not need to be identified, since messages are
not routed to any particular place and only need to be delivered on a best effort basis.  Nodes can
leave and rejoin the network at will, accepting the proof-of-work chain as proof of what
happened while they were gone.  They vote with their CPU power, expressing their acceptance of
valid blocks by working on extending them and rejecting invalid blocks by refusing to work on
them.  Any needed rules and incentives can be enforced with this consensus mechanism.
8References
[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.
9

Ich wüsste nicht wozu, da wohl jeder, der den Inhalt verstehen könnte, auch englisch kann.