Bitcoin begreifen

Schritt 1 des Prozesses (Abbildung 3) ist, dass Alice das Netzwerk bittet, 1 bitcoin auf Bob umzubuchen. Um dies zu tun, schickt sie eine Transaktion an das Bitcoin Netzwerk. Diese Transaktion enthält Anweisungen, wie das Geld zu bewegen ist, sowie eine digitale Signatur, die beweist, dass die Transaktion wirklich von Alice stammt.

Die Bitcoin Transaktion ist ein Datenblock, der angibt

Die digitale Signature wird erzeugt aus der Transaktion und einer riesengrossen geheimen Zahl, dem sogenannten privaten Schlüssel, auf den ausschliesslich Alice Zugriff hat. Das Ergebnis ist eine digitale Signatur, die nur der Besitzer des privaten Schlüssels erzeugt haben konnte.

Alices mobiles Wallet ist mit einem oder mehreren Nodes im Bitcoin Netzwerk verbunden und schickt die Transaktion an diese Nodes.

Alice hat eine Bitcoin Transaktion an einen oder mehrere Bitcoin Nodes geschickt. In Schritt 2 des Vorgangs (Abbildung 4) prüft jeder dieser Nodes, dass die Transaktion gültig ist und leitet sie dann an seine Peers weiter. Die Prüfung geschieht anhand seiner lokalen Kopie der Blockchain und indem er sichergeht, dass

Wenn alle Prüfungen erfolgreich waren, leitet ein Node die Transaktion an seine Peers im Bitcoin Netzwerk weiter. Dies wird als Relaying bezeichnet. Alices Transaktion wird in Kürze das gesamte Netzwerk durchwandert haben, wobei sie von jedem Node auf dem Weg überprüft wird. Die Blockchain wird noch nicht aktualisiert; das geschieht im nächsten Schritt.

In Schritt 3 aktualisieren die Nodes ihre lokalen Kopien der Bitcoin Blockchain mit Alices Transaktion. Die Blockchain enthält historische Informationen über alle früheren Transaktion; neue Transaktion, solche wie Alices, werden ab und zu hinten angehängt.

Das Aktualisieren der Blockchain mit Alices Transaktion ist nicht ganz so einfach wie man denkt. Alices Transaktion ist ja nicht die einzige, die im Bitcoin Netzwerk passiert. Möglicherweise sind tausende von Transaktionen gleichzeitig unterwegs. Würden nun alle Nodes ihre jeweilige Kopie der Blockchain mit Transaktion in der Reihenfolge aktualisieren, in der sie sie erhalten haben, dann wären das schnell keine Kopien mehr voneinander. Denn Transaktionen kommen auf verschiedenen Nodes in unterschiedlicher Reihenfolge an, wie man an Abbildung 5 sehen kann.

Zur Koordination der Reihenfolge der Transaktionen übernimmt ein Node die Führung und sagt: “Ich möchte folgende zwei Transaktionen in der Reihenfolge X, Y an die Blockchain anhängen.” Diese Nachricht, bekannt als Block, wird von diesem Führungsnode an das Netzwerk geschickt (Abbildung 6), genau so wie Alice die Transaktion an das Netzwerk geschickt hatte.

Wenn Nodes diesen Block sehen, aktualisieren sie ihre Kopie der Blockchain entsprechend der Nachricht und geben den Block an ihre Peers weiter. Alices Transaktion war eine der Transaktionen in dem Block und ist jetzt Teil der Blockchain.

Warum würde ein Node die Führung übernehmen wollen? Der Node, der die Führung übernimmt, wird mit frisch erzeugten bitcoins und den Transaktionsgebühren belohnt, die von den im Block enthaltenen Transaktionen bezahlt werden.

Aber würde nicht jeder Node ständig die Führung übernehmen, um die Belohnung zu kassieren? Nein, denn um die Führung übernehmen zu können, muss ein Node ein schwieriges Problem lösen. Das verlangt vom Node den Verbrauch einer erheblichen Menge an Zeit und Strom, womit gewährleistet wird, dass nicht ständig neue Führungsnodes auftauchen. Das Problem ist so schwierig, dass die meisten Nodes im Netzwerk es noch nicht einmal probieren zu lösen. Nodes, die es probieren, nennt man Miner, denn sie schürfen neue Coins, ähnlich wie ein Goldgräber nach Gold schürft. Wir besprechen diesen Prozess näher in Kapitel 7.

Bob und Alice sind Nutzer des Bitcoin Netzwerks und die beiden brauchen ein Computerprogramm, um mit dem Netzwerk zu interagieren. Solch ein Programm nennt man Bitcoin Wallet (Wallet = Geldbörse, der Übers.). Verschiedene Arten von Bitcoin Wallets sind für diverse Geräte erhältlich, zum Beispiel für Smartphones und Desktop Computer und es gibt sogar einige spezielle Hardware Wallets.

Vor Schritt 4 des Zahlungsprozesses aktualisieren die Nodes im Netzwerk ihre lokale Kopie der Blockchain. Nun muss das Netzwerk Alice und Bob darüber informieren, dass die Transaktion durchgegangen ist, wie in Abbildung 7 dargestellt.

Bobs Wallet ist mit einigen der Nodes im Bitcoin Netzwerk verbunden. Wenn eine Transaktion zur Blockchain hinzugefügt wird, die Bob betrifft, dann informieren die mit Bobs Wallet verbundenen Nodes dieses Wallet entsprechend. Das Wallet zeigt dann im Display eine Meldung an, dass er 1 bitcoin erhalten hat. Alice benutzt ebenfalls ein Wallet. Ihr Wallet wird über ihre eigene Transaktion informiert.

Abgesehen vom Senden und Empfangen von Transaktionen verwalten die Wallets von Bob und Alice auch deren private Schlüssel. Wie zuvor beschrieben werden private Schlüssel zum Erzeugen digitaler Signaturen und auch zur Generierung von Bitcoin Adressen benutzt. Alice hat ihre digitale Signatur mit einem ihrer privaten Schlüssel erzeugt. Wenn Bob später das Geld, das er von Alice auf der Bitcoin Adresse erhielt, die er mit seinem privaten Schlüssel erzeugt hatte, ausgeben will, so muss er eine Transaktion erzeugen und sie mit dem privaten Schlüssel genau dieser Adresse signieren.

Leute mit Bankkonten und Zugang zu Bankdienstleistungen wie online Zahlungen oder Kredite sind privilegiert. Laut der Weltbank besitzen rund 38% der Weltbevölkerung überhaupt kein Bankkonto. (siehe Web resource 6). Diese Zahlen bessern sich langsam, aber viele Leute stecken immer noch in einer Umgebung fest, die ausschliesslich auf Bargeld basiert.

Ohne Bankkonto und elementare Bankdienstleistungen, wie online Zahlungen, können Leute ihre Geschäfte nicht auf Bereiche ausserhalb ihrer lokalen Gemeinde ausdehnen. Ein Händler kann dann seine Waren und Dienstleistungen nicht im Internet anbieten, um seine Kundenbasis zu vergrössern. Jemand auf dem Lande muss vielleicht eine halbe Tagesreise unternehmen, um eine Versorgerrechnung zu bezahlen oder sein Prepaid Mobiltelefon aufzufüllen.

Diese Ausgrenzung von Leuten ohne Bankzugang wird von mehreren Faktoren getrieben:

Wenn es um elektronische Zahlungen wie solche mittels Kreditkarten oder Überweisungen geht, hat traditionelles Geld mehrere Vertraulichkeitsprobleme. Staaten können recht einfach

Sie können sagen: “Ich habe nichts zu verbergen und die Regierung braucht diese Werkzeuge zur Verbrechensbekämpfung.” Das Problem ist, du weisst nicht, wie deine Regierung in fünf Jahren aussieht und wie diese Regierung Verbrechen definieren wird. Neue Gesetze sind nur eine Legislaturperiode entfernt. Nach der nächsten Wahl könnte deine Regierung ein Gesetz erlassen, das es ihr erlaubt die Guthaben von Leuten mit deiner politischen Gesinnung zu beschlagnahmen. In manchen Teilen der Welt geschieht dies bereits.

Wir haben eine Menge Beispiele gesehen, bei denen diese Macht missbraucht wurde, um jemandem die Transaktionsfähigkeit zu nehmen. Zum Beispiel wurde die Non-Profit Organisation WikiLeaks im Jahre 2010 mit einer Blockade belegt, bei der auf Druck der US Regierung alle Spenden über traditionelle Kanäle wie Visa und MasterCard blockiert wurden (siehe Web resource 7). Wir haben auch miterlebt, wie Zypern im Jahr 2013 als Teil eines finanziellen Rettungsplans 47,5% aller Bankguthaben von über €100.000 annektiert hat (siehe Web resource 8)..

Wohlgemerkt sind Banknoten und Münzen davon normalerweise nicht betroffen. Solange es Bargeld gibt, können Leute frei und vertraulich Handel treiben. In einigen Teilen der Welt–zum Beispiel Schweden–befindet sich Bargeld aber auf dem Rückzug, was bedeutet, du kannst bald nicht einmal mehr einen Kaugummi kaufen, ohne dass jemand diese Transaktion aufzeichnet.

Inflation bedeutet die Kaufkraft einer Währung schwindet (Abbildung 8).

Die meisten Währungen unterliegen einer Inflation, manche mehr als andere. Zum Beispiel inflationierte der Simbabwische Dollar um fast 10^23% zwischen 2007 und 2008, mit einem Spitzenwert von 80 Milliarden Prozent pro Monat während einiger Monate des Jahres 2008. Das entspricht einer täglichen Inflationsrate von fast 100%. Die Preise verdoppelten sich praktisch täglich.

Solche extremen Fälle von Inflation wie diese, werden als Hyperinflation bezeichnet und werden meist von einer rapiden Zunahme der Geldmenge verursacht. Regierungen vergrössern manchmal die Geldmenge, um aus der Bevölkerung Wert zu extrahieren und Ausgaben wie die Staatsverschuldung, Kriege oder Sozialleistungen zu bezahlen. Wird dieses Werkzeug zu viel benutzt, so wird das Risiko der Hyperinflation offensichtlich.

Eine rasche Zunahme der Geldmenge führt fast zwangsläufig zu einer Abwertung der Landeswährung. Das wiederum treibt Leute dazu, ihre lokale Währung in Güter oder Währungen umzutauschen, die wertstabiler sind, was den Wert der Landeswährung weiter senkt. Dies kann in einer extremen Spirale enden, wie in Simbabwe. Das Resultat ist verheerend für die Bevölkerung, weil diese zusehen, wie ihre Ersparnisse dahinschwinden bis praktisch nicht mehr übrig bleibt. Tabelle 1 zeigt Beispiele jüngerer Hyperinflationen.

Simbabwe ist einer der extremsten Fälle in der Geschichte der Inflation, aber selbst heute leiden einige Länder unter sehr hoher Inflation. Eines davon ist Venezuela, dessen Währung, der Bolivar, im Jahr 2016 eine Inflation von 254% erlitt und im Jahr 2017 sogar 1.088%. Für das Jahr 2018 wird eine erschütternde Inflationsrate von 1.370.000% vorausgesagt.

Wert mit Landes– oder fiat–Währung über Landesgrenzen hinweg zu schicken ist schwierig, teuer und manchmal sogar verboten. Wenn du versuchst 1.000 Schwedische Kronen (SEK) von Schweden an jemanden auf den Philippinen zu schicken, kannst du einen Dienst wie Western Union für den Transfer in Anspruch nehmen. Zu dem Zeitpunkt, an dem ich dies untersuchte, waren 1.000 SEK gerade 5.374 Philippinische Pesos (PHP) oder 109 US-Dollar wert. Siehe Tabelle 2.

Wenn der Empfänger ein Bankkonto besitzt, das für internationale Überweisungen geeignet ist, kommt man mit 4,9% hin. Aber ein typischer Empfänger solcher internationaler Überweisungen wird nur Bargeld erhalten können, was die Kosten verdoppelt bis verdreifacht auf 10,5% oder gar 16,3%, je nachdem, wie schnell oder bequem sie es erhalten möchten.

Im Gegensatz zu internationalen Transfers ist das Bewegen von Fiatwährung innerhalb der eigenen Landesgrenzen normalerweise praktisch. Zum Beispiel kann man dem Gegenüber einfach Bargeld reichen oder Geld mit einer mobilen App, die diese Währung unterstützt, transferieren. Solange du innerhalb des Landes und der Währung bleibst, funktionieren Fiatwährungen recht gut.

Anstelle einer zentralen Organisation wie der US Federal Reserve, die die Währung kontrolliert, ist die Kontrolle über Bitcoin über tausende von Computern, die Nodes, verteilt. Kein einzelner Node und keine Gruppe von Nodes besitzt irgendwelche Privilegien gegenüber irgendwelchen anderen. Diese Gleichberechtigung zwischen allen Nodes macht Bitcoin dezentralisiert, im Gegensatz zu zentralisierten Systemen wie Banken oder der Google Suchmaschine (Abbildung 9).

In einem zentralisierten System wird der Dienst von einer einzelnen Einheit kontrolliert, zum Beispiel einer Bank. Diese einzelne Einheit kann entscheiden, wer den Dienst benutzen darf und was die Benutzer damit tun dürfen. Zum Beispiel kann ein online Videoservice beschliessen, nur Personen innerhalb einer bestimmten geographischen Region zu bedienen.

Bei einem dezentralisierten System wie Bitcoin, das mehrere tausend Nodes über der Welt verteilt hat, ist es extrem schwierig zu kontrollieren, wer das System benutzt und wie. Egal wo oder wer sie sind, oder wem sie Geld schicken, das Bitcoin System behandelt alle Benutzer gleich. Das Bitcoin System hat keinen zentralen Punkt, der zur Zensur, Dienstverweigerung oder zur Beschlagnahme von Guthaben ausgenutzt werden könnte.

Die Regeln von Bitcoin ohne sehr breiten Konsens zu ändern ist praktisch unmöglich. Wenn sich ein Node nicht an die Regeln hält, werden die restlichen Nodes diesen schlicht ignorieren. Eine solche Regel ist zum Beispiel, dass die Geldmenge auf 21 Millionen bitcoins begrenzt ist. Diese Grenze zu verschieben ist wegen der Dezentralisierung praktisch unmöglich; es gibt niemanden, den man bestechen oder bedrohen könnte, um das durchzusetzen.

Weil Bitcoins Geldmenge niemals 21 Millionen bitcoin überschreiten wird, können Leute sicher sein, dass wenn sie 1 bitcoin besitzen, sie immer mindestens ein 21-millionstel der Gesamtmenge besitzen werden. Diese Eigenschaft existiert in keiner einzigen Fiatwährung, wo Entscheidungen über die Geldmenge immer wieder mal von einer Firma oder dem Staat gemacht werden. Bitcoin widersteht hoher Inflation, weil man die Geldmenge nicht beliebig erhöhen kann.

Bitcoins Geldmenge ist nicht auf die heutige Menge festgelegt. Sie nimmt zu, mit abnehmender Geschwindigkeit, gemäss einem vorprogrammierten Zeitplan, und sie hört irgendwann um das Jahr 2140 herum auf zu wachsen. Siehe Abbildung 10.

Weil Bitcoin ein System ist, das auf normalen am Internet hängenden Computern läuft, ist es so global wie das Internet. Das bedeutet, jeder mit einer Internetverbindung kann Geld an andere Leute auf der Welt schicken, wie in Bild Abbildung 11 dargestellt.

Es gibt keinen Unterschied zwischen dem Senden von einem bitcoin an jemanden im selben Zimmer oder an jemanden auf einem anderen Kontinent. Die Erfahrung ist dieselbe: Geld wird direkt an den Empfänger geschickt, der die Zahlung fast sofort sieht. Innerhalb ca, 60 Minuten kann dieser Empfänger sicher sein, dass ihm nun das Ged gehört. Einmal abgeschlossen, kann der Transfer nicht ohne das Einverständnis des Empfängers rückgängig gemacht werden.

Bitcoin hat die interessante Eigenschaft, dass man zur Sicherung seines Vermögens einfach die privaten Schlüssel sicher aufbewahren muss: die geheimen Informationen, die du brauchst, wenn du dein Geld ausgeben willst. Du suchst dir selber aus, wie du diese privaten Schlüssel aufheben möchtest. Du kannst sie auf Papier schreiben, oder sie zum leichterem Zugriff elektronisch in einer mobilen App speichern. Du kannst sie auch einfach auswendig lernen. Diese Schlüssel sind alles, was man braucht, um dein Geld auszugeben. Bewahre sie sicher auf.

Sparen ist ein attraktiver Anwendungsfall für Bitcoin. Ein einfacher Weg zum Sparen ist, einen privaten Schlüssel zu erzeugen und auf einem Blatt Papier in einem Safe zu lagern. Das Blatt Papier ist jetzt dein Sparkonto, dein Spar-Wallet. Du kannst bitcoins an dieses Wallet schicken. Solange deine privaten Schlüssel in Sicherheit sind, ist es dein Geld auch. Du kannst aus einer Menge Sparmethoden die richtige auswählen, um dein bevorzugtes Gleichgewicht zwischen Sicherheit und Bequemlichkeit zu erreichen. Zum Beispiel kannst du deine Schlüssel im Klartext auf deinem Mobiltelefon speichern, um einfach zugreifen zu können, oder sie verschlüsselt auf Papier in einem Tresor mit bewaffneten Wachtposten lagern.

Wie erwähnt ist das Bewegen von Geld aus einem Land in ein anderes teuer (sagen wir, 15%), besonders wenn man Geld in ein armes Land schickt und der Empfänger kein Bankkonto hat. Es wird immer beliebter, Bitcoin zur Umgehung dieses langsamen und teuren alten Systems zu verwenden. Es kostet normalerweise weniger, in Schweden schwedische Kronen in bitcoin umzutauschen und an den Freund auf den Philippinen zu schicken. Dein Freund tauscht dann die bitcoin lokal in philippinische Pesos um.

Manche Firmen bieten Dienstleistungen an, bei denen du schwedische Kronen der Firma übergibst und diese dann auf den Philippinen Pesos an deinen Freund auszahlt (Abbildung 12). Du merkst noch nicht einmal, dass intern Bitcoin dafür verwendet wird. Solche Firmen verlangen normalerweise ein paar Prozent für den Service, was aber billiger ist als die traditionellen internationalen Überweisungsverfahren.

Wenn natürlich die Empfänger Bitcoin dort, wo sie wohnen, direkt verwenden können, braucht man keinen Mittelsmann, der einen Teil des Geldes behält. Du kannst deinem Freund auch direkt bitcoins schicken. Darum geht es ja bei Bitcoin. Exchanges und solcherlei Dienstleister sind nur Brücken zwischen der althergebrachten Finanzwelt und der Bitcoin-Welt.

Der offensichtlichste Anwendungsfall für Bitcoin ist das Einkaufen. Bitcoins Globalität und Sicherheit machen es ideal für das online Bezahlen von Waren und Dienstleistungen.

In traditionellen online Zahlungsverfahren schickt man Debitkarteninformationen an den Händler und hofft, dass der Händler nur so viel abbucht, wie als Preis vereinbart war. Du hoffst auch, dass der Händler gut auf deine Kartendaten aufpasst. Die Händler speichern die Kartendaten wahrscheinlich in einer Datenbank. Denk mal darüber nach: für jeden Kauf, den du mit Debitkarte bezahlst, speichert ein Händler deine Kartendaten in einer Datenbank. Es ist sehr wahrscheinlich, dass eine dieser Datenbanken gehackt wird und auch deine Kartendaten gestohlen werden. Je mehr Händler deine Daten haben, desto höher ist das Risiko.

Mit Bitcoin hast du dieses Problem nicht, denn du brauchst weder dem Händler noch sonst jemandem heikle Daten zu schicken. Du schickst die vereinbarte Summe und fertig.

Die Welt ist voller Leute, die schnell reich werden wollen. Bitcoin kann für die sehr interessant sein, weil sein Preis sehr volatil ist, also zu grossen Ausschlägen neigt. Schaut man sich den Preis von bitcoin an, wie hier Abbildung 13, so kommt man in Versuchung, es billig zu kaufen und teurer wieder zu verkaufen.

Manchmal stellt eine Regierung oder eine grosse Firma eine negative Behauptung über Bitcoin auf, die Angst im Markt erzeugt, aber diese Vorkommnisse neigen nicht dazu, grossen Einfluss auf den Wert von Bitcoin zu haben.

Die Preisvolatilität von Bitcoin scheint der Behauptung zu widersprechen, Bitcoin sei nicht-inflationär; ein 50% Abfall im Marktwert kann einem schon ziemlich inflationär vorkommen. Bitcoin ist aber immer noch relativ neu und die Volatilität wird viel durch kurzfristige Spekulation genährt. Aber mit dem Wachsen von Bitcoin und zunehmender Akzeptanz durch Personen und Institutionen zum Speichern ihrer Vermögenswerte, wird sich langfristig der Preis wahrscheinlich stabilisieren und die deflationären Eigenschaften von Bitcoin werden sich im Laufe der Zeit zeigen.

Bitcoin ist digitales Bargeld, aber diese Form von Bargeld kann für Dinge verwendet werden, die über das Geld hinausgehen. Dieser Abschnitt behandelt zwei gebräuchliche Verwendungen, aber es gibt andere, einschließlich der noch nicht erfundenen.

Wie in Abschnitt 1.5.4 erklärt, kann der Preis von bitcoin dramatisch fluktuieren. Aber woher kommt der Preis? Es gibt mehrere Bitcoin Exchanges, die meisten davon sind internetbasiert. Sie ähneln Aktienmärkten, auf denen Benutzer, die bitcoins verkaufen wollen, mit denen verbunden werden, die welche kaufen wollen.

Auf verschiedenen Märkten können sich unterschiedliche Marktpreise ergeben, abhängig von Angebot und Nachfrage auf dem jeweiligen Markt. Zum Beispiel ist das Angebot von bitcoins in Märkten wie Venezuela, wo die Regierung den Bitcoin Markt zu unterdrücken versucht, gering. Andererseits ist die Nachfrage aber hoch, weil die Bevölkerung der Hyperinflation ihrer Währung zu entrinnen versucht. Diese Faktoren treiben den Bitcoin Preis in diesem Markt im Vergleich zu beispielsweise dem US-amerikanischen oder europäischen Markt hoch.

Bitcoin ist schön und gut, aber es ist nicht für alle Finanzaktivitäten geeignet. Jedenfalls noch nicht.

Kryptografische Hashfunktionen können zur Integritätsprüfung verwendet werden, um Änderungen in Daten festzustellen. Angenommen du willst dein Lieblings-Katzenbild auf der Festplatte deines Laptops abspeichern, aber du machst dir Sorgen, dass die Datei beschädigt werden könnte. Das könnte zum Beispiel aufgrund von Festplatten Fehlern oder Hackern geschehen. Wie kannst du sichergehen, dass du eine Beschädigung der Datei feststellen kannst?

Zunächst berechnest du den kryptografischen Hash des Katzenbildes auf deiner Festplatte und schreibst ihn auf ein Blatt Papier (Abbildung 22).

Später, wenn du das Bild anschauen willst, kannst du überprüfen, ob es sich geändert hat, seitdem du den Hash aufgeschrieben hast. Berechne den kryptografischen Hash des Katzenbildes erneut und vergleiche ihn mit dem, den du auf Papier hast (Abbildung 23).

Wenn der neue Hash mit dem auf dem Papier übereinstimmt, kannst du sicher sein, dass das Bild unverändert ist. Auf der anderen Seite, sollten die Hashes sich unterscheiden, so hat sich das Bild definitiv geändert.

Bitcoin verwendet kryptografische Hashfunktionen sehr ausgiebig, um zu überprüfen, dass sich Daten nicht geändert haben. Zum Beispiel wird immer ab und zu–durchschnittlich alle 10 Minuten–ein neuer Hash der gesamten Zahlungsgeschichte erzeugt. Wenn jemand versucht, diese Daten zu ändern, wird dies sofort von jedem, der die Hashes überprüft, bemerkt.

Die korrekte Antwort ist komplex, also werde ich nicht tief in’s Detail gehen. Aber um die Arbeitsweise einer kryptografischen Hashfunktion zu verstehen, werden wir eine sehr einfache schreiben. Nun ja, ehrlich gesagt ist sie nicht wirklich kryptografisch, wie ich später noch erklären werde. Nennen wir sie erstmal einfach eine Hashfunktion.

Angenommen du willst den Hash einer Datei mit den sechs Bytes a1 02 12 6b c6 7d berechnen. Du möchtest, dass der Hash eine 1 Byte lange Zahl ist (8 Bits) Du benutzt eine Hashfunktion, die die Addition modulo 256 benutzt, was bedeutet, sie bricht beim Wert von 256 um und fängt wieder bei 0 an, sobald das Ergebnis einer Addition den Wert 256 überschreitet (Abbildung 24).

Das Ergebnis ist die Dezimalzahl 99. Was sagt 99 über die Eingabedaten a1 02 12 6b c6 7d aus? Nicht viel; 99 sieht genauso zufällig aus wie jede andere zufällige Zahl.

Wenn du die Eingabedaten änderst, ändert sich auch der Hashwert, obwohl es möglich ist, dass der Hash trotzdem zufällig 99 ergibt. Schliesslich hat diese Hashfunktion nur 256 verschiedene mögliche Ergebnisse. Mit echten kryptografischen Hashfunktionen wie der, die wir für das Katzenbild benutzt hatten, ist diese Wahrscheinlichkeit unvorstellbar klein. Du wirst bald eine Idee von dieser Wahrscheinlichkeit bekommen.

Eine kryptografische Hashfunktion nimmt beliebige Eingabedaten, das sogenannte Pre-Image, und erzeugt daraus eine Ausgabe von fester Länge, die als Hash bezeichnet wird. In dem Beispiel mit dem Katzenbild auf deiner Festplatte ist das Pre-Image das Katzenbild von 1,21 MB und der Hash ist eine 256 Bit lange Zahl. Die Funktion liefert jedesmal genau denselben Hash für dasselbe Pre-Image. Aber mit allerhöchster Wahrscheinlichkeit wird sie einen vollkommen anderen Wert ergeben, wenn auch nur die winzigste Änderung am Pre-Image stattgefunden hat. Der Hash wird gemeinhin auch als Digest, also Kurzfassung, bezeichnet.

Schauen wir uns an, welche Eigenschaften wir von einer kryptografischen Hashfunktion erwarten können. Ich illustriere das anhand der Funktion SHA256, weil diese in Bitcoin am meisten verwendet wird. Mehrere kryptografische Hashfunktionen sind verfügbar, aber sie besitzen alle dieselben grundlegenden Eigenschaften:

Abbildung 25 illustriert die ersten drei Eigenschaften. Die vierte Eigenschaft einer kryptografischen Hashfunktion ist das, was sie kryptografisch macht, und das bedarf einer gewissen Erläuterung. Es gibt einige Varianten der vierten Eigenschaft, von denen alle für kryptografische Hashfunktionen wünschenswert sind (Abbildung 26):

Der Term schwierig bedeutet in diesem Zusammenhang astronomisch schwierig. Es wäre albern, es überhaupt zu versuchen. Wir betrachten Zweit-Pre-Image-Resistenz als Beispiel dafür, was schwierig bedeutet, aber ein ähnliches Beispiel kann für jede der drei Varianten aufgestellt werden.

Angenommen du willst einen Input für SHA256 finden, der zu demselben Hash führt wie der Input “Hello!”:

Du kannst ja nicht den Input “Hello!” einfach so geringfügig verändern, dass die Hashfunktion das nicht bemerkt. Sie wird es bemerken und der Output wird ein vollständig anderer Hash sein. Der einzige Weg, einen anderen Input als “Hello!” zu finden, der den Hash 334d016f…​d42c87b7 erzeugt, ist, verschiedene Inputs durchzuprobieren und immer wieder zu prüfen, ob der richtige Hash dabei herauskommt.

Probieren wir es mal mit Tabelle 7.

Wie du siehst, sind wir nicht sonderlich erfolgreich. Denk mal, wie lange ein Desktop Computer brauchen würde, um einen solchen Input zu finden. Er kann ungefähr 60 Millionen Hashes pro Sekunde berechnen, und die erwartete Anzahl Versuche, um eine Lösung zu finden, beträgt 2²⁵⁵. Das Ergebnis ist 2²⁵⁵ / (60 × 10⁶) s ≈ 10⁶⁸ s ≈ 3 × 10⁶¹ Jahre, oder etwa 30,000,000,000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000 Jahre.

Ich glaube wir können aufhören, es zu versuchen, oder? Ich glaube nicht, dass es helfen würde, einen schnelleren Computer zu kaufen. Selbst wenn wir 1 Billion Computer hätten und sie alle gleichzeitig laufen würden, würde es noch 3 × 10⁴⁹ Jahre dauern.

Pre-Image-Resistenz, Zweit-Pre-Image-Resistenz und Kollisionsresistenz sind in Bitcoin extrem wichtig. Der Grossteil von Bitcoins Sicherheit beruht auf diesen Eigenschaften.

Tabelle 8 zeigt verschiedene kryptografische Hashfunktionen. Einige gelten als nicht kryptografisch sicher.

Ganz allgemein, wenn eine einzige Kollision in einer kryptografischen Hashfunktion entdeckt wurde, werden die meisten Kryptografen diese Funktion als unsicher betrachten.

Eine kryptografische Hashfunktion ist ein Computerprogramm, das beliebige Daten als Input nimmt und eine grosse Zahl berechnet–einen kryptografischen Hash–, der aus dem Input hervorgeht.

Es ist astronomisch schwierig, einen Input zu finden, der zu einem bestimmten Output führt. Deswegen nennen wir sie Einbahnfunktionen. Man muss immer wieder mit unterschiedlichen Inputs probieren.

Wir diskutieren wichtige Themen im ganzen Buch. Wenn du ein bestimmtes Thema gelernt hast, wie kryptografische Hashfunktionen, dann kannst du dieses Werkzeug für später in deine Werkzeugkiste legen. Dein erstes Werkzeug sind kryptografische Hashfunktionen, die hier durch einen Papierschredder dargestellt werden; der kryptografische Hash wird als ein Haufen Papierstreifen dargestellt.

Von nun an werden wir diese Werkzeug-Icons benutzen, um kryptografische Hashfunktionen und kryptografische Hashes darzustellen, mit wenigen Ausnahmen.

Angenommen, du willst dein Lieblings-Katzenbild per Email deinem Freund Fred schicken, vermutest aber, dass das Bild, auf bösartige oder anderweitige Weise, auf dem Weg dorthin verändert werden könnte. Wie könnten Fred und du sicherstellen, dass das Bild, das Fred erhält, genau das ist, das du weggeschickt hast?

Du kannst in der Email eine digitale Signatur des Katzenbildes mitschicken. Fred kann dann diese digitale Signatur verifizieren, um sicherzustellen, dass das Bild authentisch ist. Dies geschieht in drei verschiedenen Phasen, wie in Abbildung 27 dargestellt.

Schritt 1 ist die Vorbereitung. Du erzeugst eine Zufallszahl: den privaten Schlüssel oder private Key. Diesen benutzt du, um digitale Signaturen zu erstellen. Dann erzeugst du einen öffentlichen Schlüssel oder public Key, der dazu verwendet wird, die digitale Signatur zu überprüfen, die der private Key erzeugt hat. Der public Key wird aus dem private Key berechnet. Du übergibst Fred den public Key persönlich, damit Fred sicher sein kann, dass es wirklich dein public Key ist.

Schritt 2 ist die Signatur. Du schreibst eine Email an Fred und hängst das Katzenbild an. Du benutzt ausserdem deinen private Key und das Katzenbild, um das Katzenbild digital zu signieren. Das Ergebnis ist eine digitale Signatur, die du der Email Nachricht beifügst. Danach sendest du die Email an Fred.

Schritt 3 ist die Verifikation. Fred bekommt deine Mail, aber er macht sich Sorgen um die Echtheit des Bildes, also möchte er die Signatur überprüfen, oder verifizieren. Er verwendet den public Key, den er in Schritt 1 von dir bekommen hatte, die digitale Signatur in der Mail, und das angehängte Katzenbild. Wenn die Signatur oder das Katzenbild seit Erstellung der Signatur verändert wurde, dann scheitert die Überprüfung.

Es ist Zeit, auf unser Cookie Token Spreadsheet zurückzukommen. Die Firma wächst, und Lisa fällt es schwer, sich jeden Mitarbeiter zu merken. Ausserdem merkt sie, dass nicht jeder ehrlich ist. Zum Beispiel behauptet Mallory, Anne zu sein und Lisa dazu zu bringen, Cookie Tokens von Anne an das Café zu schicken, anstatt von Mallory. Lisa kommt auf die Idee, von jedem zu verlangen, alle Cookie Token Transfers digital zu signieren, indem sie eine Nachricht schreiben und dessen Signatur mit der Email mitschicken, wie in Abbildung 28 dargestellt.

Angenommen, John ist der neue Mitarbeiter im Büro. Die Firma hat ihm als Willkommensgeschenk einige Cookie Tokens gegeben, als er anfing. Nun möchte John im Café einen Keks für 10 CT kaufen. Er muss den Cookie Token Transfer digital signieren. Abbildung 29 zeigt, was er dafür tun muss.

Genau wie mit der Mail von Fred im vorigen Abschnitt besteht auch dieser Vorgang aus drei Phasen (vergleiche mit den Schritten in Abbildung 27, um die Ähnlichkeiten zu erkennen):

Die Signier- und Prüfvorgänge basieren auf einem Schlüsselpaar. John benutzt einen private Key, um die Zahlung zu signieren, und Lisa braucht Johns public Key, um die Signatur zu verifizieren. John muss das vorbereiten, indem er ein Schlüsselpaar erstellt. Er tut dies, indem er zunächst einen private Key erzeugt und dann daraus dessen public Key berechnet, wie in Abbildung 30 zu sehen ist.

John will einen Zufallszahlengenerator benutzen, um eine riesige, 256 Bit lange Zahl zu erzeugen. Ein Zufallszahlengenerator ist Teil praktisch jedes Betriebssystems. Die Zufallszahl ist Johns private Key. Der private Key wird dann mittels einer Ableitungsfunktion zum public Key umgeformt.

Der public Key ist 33 Bytes (66 Hexziffern) lang. Das ist länger als der private Key, der 32 Bytes (64 Hexziffern) lang ist. Der Grund für dieses zusätzliche Byte und wie die public Key Ableitung funktioniert ist ein schwieriges Thema, das in Kapitel 4 behandelt wird. Glücklicherweise muss man kein Kryptografie-Experte sein, um zu verstehen, wie digitale Signaturen aus Benutzersicht funktionieren.

Fassen wir zusammen, was wir über public und private Keys gelernt haben. Man erzeugt ein Schlüsselpaar, indem man zunächst einen private Key generiert. Der private Key ist eine riesige, geheime Zufallszahl. Der public Key wird dann aus dem private Key berechnet.

Man kann den private Key zum Verschlüsseln einer Nachricht benutzen, die nur mit dem public Key entschlüsselt werden kann.

Die Ver- und Entschlüsselung in diesem Bild sind die Grundlage für digitale Signaturen. Dieser Prozess ist ungeeignet zum Versenden geheimer Nachrichten, da der public Key normalerweise allgemein bekannt ist.

Der umgekehrte Prozess ist ebenfalls häufig, wobei der public Key zum Verschlüsseln und der private Key zum Entschlüsseln verwendet wird. Dieser Prozess wird zum Versenden geheimer Nachrichten verwendet. Bitcoin benutzt ihn nicht.

Schauen wir uns an, wie das Signieren tatsächlich vonstatten geht (Abbildung 33).

Die Nachricht, die John signieren will, lautet: "Lisa, please move 10CT to Café. /John". Die Signaturfunktion hasht diese Nachricht mittels SHA256, was als Output eine 256 Bit lange Zahl ergibt. Dieser Hash wird dann mit John’s private Key verschlüsselt. Das Ergebnis ist eine digitale Signatur, die so aussieht:

Zum Beispiel würde die Input Nachricht “Lisa, please move 10CT to Mallory. /John” folgende Signatur erzeugen:

Das ähnelt nicht entfernt der vorigen Signatur. Das ist gut für John, denn er weiss, dass seine Signatur nicht für andere Nachrichten benutzt werden kann als seine eigene.

John hat eine Mail an Lisa erstellt. Diese Mail enthält eine Nachricht und die Signatur dieser Nachricht. John beendet den Vorgang mit dem Senden der Mail an Lisa.

Lisa schaut in die Mail und sieht, dass sie angeblich von John ist, also sucht sie in der Liste ihrer public Keys nach John (Abbildung 34).

Lisa versucht in dieser Grafik festzustellen, dass der Cookie Token Transfer mit dem private Key signiert wurde, mit dem es vorgibt, signiert worden zu sein. Die Nachricht sagt sie komme von John. Sie hatte Johns public Key neulich erhalten und ihn in ihre Tabelle der public Keys eingetragen. Die Dinge, die sie zur Verfügung hat, sind

Lisa nimmt die Signatur (B) und entschlüsselt sie mit dem public Key (C), den sie in ihrer Tabelle mit public Key nachgeschaut hat. Die Entschlüsselung ergibt eine grosse Zahl. Wenn diese Zahl mit dem Hash der Nachricht (A) übereinstimmt, so beweist dies, dass Johns private Key zum Signieren der Nachricht benutzt worden war. Lisa nimmt die Nachricht (A), genauso wie sie da steht, und hasht sie ebenso wie John das getan hat, als er die Signatur erstellte. Dieser Nachrichten-Hash wird dann mit der entschlüsselten Signatur verglichen. Der Nachrichten-Hash und die entschlüsselte Signatur sind identisch, also ist die Signatur gültig.

Wohlgemerkt funktioniert dieser Prozess nur, wenn John und Lisa dasselbe Signaturverfahren benutzen. Darauf müssen sie sich vorher geeinigt haben, aber es ist normalerweise standardisiert. In Bitcoin weiss jeder, welches Signaturverfahren zu verwenden ist.

Lisa kann jetzt sicher sein, dass niemand sie betrügen will. Sie aktualisiert das Spreadsheet mit Johns Transfer wie in Abbildung 35 gezeigt.

John besitzt die Kontrolle über seine Cookie Token, weil er den private Key besitzt. Niemand ausser John kann Johns Cookie Token benutzen, weil er der einzige mit Zugang zu seinem private Key ist. Wenn sein private Key gestohlen wird, kann er alle seine Cookie Token verlieren.

Am Morgen nach Johns Transfer kommt er ins Büro, nimmt seinen Laptop vom Tisch und geht direkt zum Café, um sich zwei Frühstückskekse zu holen. Er öffnet seinen Laptop und schreibt eine Nachricht an Lisa:

Er sendet diese Mail mit der Nachricht und der Signatur an Lisa. Aber das Café gibt ihm keine Kekse. Der Mensch hinter der Theke sagt, er hätte noch keine einkommende Zahlung über 20 Cookie Token gesehen. Lisa verifiziert und führt Transfers normalerweise schnell aus.

John öffnet das Spreadsheet—vergiss nicht, dass er read-only Zugriff besitzt, und sucht “John.” Abbildung 36 zeigt, was er sieht.

John geht in Lisas Büro und bittet um eine Erklärung. Sie antwortet, dass sie eine Nachricht bekommen hatte, die mit Johns private Key signiert worden war, und in der sie gebeten wurde, Geld an eine neue Mitarbeiterin namens Melissa zu schicken. Natürlich gibt es gar keine Melissa im Büro, obwohl mehrere neue Mitarbeiter bei der Firma angefangen haben. Lisa interessieren Namen nicht mehr, nur noch public Key und Signaturen. Aber sie braucht den Namen noch, um in der Tabelle nach dem richtigen public Key zu schauen.

Die Erklärung für all das ist, dass Mallory

Lisa hat den Transfer in Schritt 3 verifiziert, festgestellt, dass er gültig ist, und ihn dann ausgeführt. John bittet Lisa, den–ihm zufolge– betrügerischen Transfer rückgängig zu machen, aber Lisa weigert sich. Sie hält den Transfer für einwandfrei. Wenn John jemanden an seinen private Key heranlässt, dann ist das sein Problem, nicht Lisas. Das ist einer der Gründe, warum Lisa in der Firma als so vertrauenswürdig gilt–sie hält ihre Versprechen.

John erzeugt ein neues Schlüsselpaar und bittet Lisa, den neuen public Key unter dem Namen John2 abzulegen. Wie kann John seinen neuen private Key sichern und ihn dennoch immer bereithalten, wenn er einen Keks möchte? John ist sich ziemlich sicher, dass er nicht mehr als 1.000 Cookie Token auf diesem Key haben wird.

Die Sicherheit des Spreadsheet hat sich gewandelt von einem System, in dem Lisa von jedem das Gesicht kennt, zu einem, in dem sie von jedem den public Key kennt. In gewisser Weise steht es um die Sicherheit jetzt schlechter, denn es ist einfacher für Mallory, Johns private Key zu stehlen als Lisa dazu zu bringen, sie für John zu halten. Es hängt davon ab, wie sicher John seinen private Key verwahrt. Wichtig ist, dass die Sicherheit für Johns private Key vollständig ihm selbst überlassen ist. Niemand wird seinen private Key wiederherstellen können, wenn er ihn verliert. Und Lisa macht bestimmt keine “betrügerischen” Transfers rückgängig, weil John nachlässig mit seiner Sicherheit umgegangen ist.

Wenn John seinen private Key im Klartext in einem gemeinsam benutzten Folder auf dem Firmen-Intranet ablegt, kann diesen jeder kopieren und zum Stehlen seiner Cookie Tokens benutzen. Aber wenn John den private Key von einem starken Passwort geschützt in einer verschlüsselten Datei auf seinem eigenen Laptop ablegt, dann ist es viel schwieriger, den Schlüssel zu ergaunern. Ein Angreifer müsste

Wenn John nie mehr als 50 CT auf seinem private Key hat, dann mag er sich nicht viele Gedanken um die Sicherheit machen. Aber das Café, das etwa 10.000 CT pro Tag verwaltet, sollte besorgt sein. John und das Café brauchen wahrscheinlich unterschiedliche Strategien, um ihre private Keys zu sichern.

Es gibt einen Tradeoff zwischen Sicherheit und Bequemlichkeit. Du kannst zum Beispiel deinen private Key verschlüsselt auf einem Laptop in einem Bankschliessfach lagern. Wenn du einen Keks kaufen willst, musst du zur Bank gehen, den Laptop aus dem Schliessfach nehmen, den private Key entschlüsseln und eine digitale Nachricht an Lisa verschlüsseln, die du auf einem USB-Stick speicherst. Dann musst du den Laptop wieder in das Schliessfach einschliessen, den USB-Stick ins Büro mitnehmen und die Mail an Lisa schicken. Der private Key verlässt dabei nie den Laptop im Schliessfach. Sehr sicher, und sehr unbequem.

Auf der anderen Seite kannst du den private Key auch im Klartext auf dem Telefon speichern. Dann hast du den Key immer bereit und kannst in Sekunden eine Message signieren, wenn dich die Lust auf einen Keks packt. Sehr bequem, und sehr unsicher.

Einige der Tradeoffs, wie in Abbildung 37 dargestellt, sind die Folgenden:

Du kannst irgendeine Kombination dieser Methoden benutzen, um deine Keys zu speichern. Aber als Daumenregel gilt, je grösser die Sicherheit gegenüber Angreifern, desto grösser das Risiko, die Keys versehentlich zu verlieren. Wenn du zum Beispiel den private Key verschlüsselt auf deiner Festplatte speicherst, riskiert du dessen Verlust, wenn die Festplatte kaputtgeht oder du das Passwort vergisst. In dieser Hinsicht ist es umso unsicherer, je sicherer es ist.

Angenommen eine neue Mitarbeiterin hat gerade in der Firma angefangen. Ihr Name ist Faiza. Die Firma möchte ihr 100 CT als Willkommensgeschenk senden. Wie kann die Firma die 100 CT an Faiza schicken?

Zuerst braucht die Firma den public Key des Empfängers–Faiza. Faiza hat noch nie Cookie Tokens benutzt, also muss sie ein neues Schlüsselpaar generieren und den public Key dem Sender–der Firma–geben, wie Abbildung 42 zeigt.

Faiza erzeugt einen private und einen public Key, wobei sie dem selben Prozess folgt wie in Abschnitt 2.3.2, aber sie gibt ihren public Key nicht Lisa. Jetzt wo Lisa nicht mehr die Tabelle mit Namen und public Keys pflegt, hat es keinen Sinn, ihr den public Key zu geben. Sie braucht ihn nicht. Stattdessen gibt Faiza den public Key der Partei, die ihr Cookie Tokens schicken will–der Firma.

Die Firma erzeugt eine Nachricht, in der sie Lisa bittet, 100 CT von 037e944a…36de9496 an 029a726c…ad8f436d zu senden. Dann signiert sie diese Nachricht digital und schickt sie an Lisa. Lisa benutzt

um sicherzustellen, dass die Nachricht mit dem private Key, der zu dem public Key des Senders gehört, signiert wurde. Sie verifiziert ebenfalls, dass im Spreadsheet auf dem public Key des Senders ausreichend Guthaben vorhanden ist. Sie tut dies auf die gleiche Weise, wie sie es tat, als im Spreadsheet noch Namen standen–sie sucht nach dem public Key des Senders und berechnet den Kontostand.

Lisa hat den public Key des Empfängers vorher noch nie gesehen, aber das ist ihr egal. Ihr geht es nur darum, dass der Sender genug Geld zum Ausgeben hat, und dass die Nachricht korrekt signiert wurde. Sie trägt in die Empfängerspalte des Spreadsheets ein, was immer in der Nachricht stand.

Faiza entdeckt eine neue Zeile mit ihrem public Key in der An: Spalte. Das gibt ihr ein warmes, gutes Gefühl. Jetzt kann sie ihre Cookie Tokens benutzen, wie sie will. Faiza musste Lisa nicht mit ihrem public Key behelligen, was Lisa einiges an Arbeit erspart hat.

Sammeln wir einmal auf, was bisher passiert ist:

Diese Änderungen haben die Privacy verbessert und Lisa die Arbeit vereinfacht. Am Ende dieses Kapitels werden wir mehr darüber diskutieren, wie wir die Privacy weiter verbessern können.

Die Mail an Lisa in diesem Beispiel gibt gegenüber Lisa preis, wer der Sender ist (die Firma in diesem Fall), weil deren Absenderadresse im Von: Feld der Mail steht. Für den Moment können wir annehmen, dass Lisa diese persönliche Information weder ausnutzt noch preisgibt. Wir benutzen Mail in diesen Beispielen anstelle des Bitcoin Peer-to-Peer Netzwerks. Das Bitcoin Netzwerk, eingehender besprochen in Kapitel 8, benutzt keinerlei persönliche Information.

Bitte denk einen Moment darüber nach, was die Acme Versicherung jetzt noch aus dem Spreadsheet herauslesen kann. Welche Information kann sie herausbekommen, wenn sie den Namen von Sender oder Empfänger einer Zahlung herausbekommt? Sie wird in der Lage sein, alle Zahlungen herauszubekommen, die diese Person getätigt hat.

Einige Entwickler unter den Kollegen glauben, sie können die 33 Byte public Keys durch etwas kürzeres ersetzen und trotzdem ausreichende Sicherheit beibehalten. Sie schlagen vor, jeden public Key im Cookie Token Spreadsheet durch einen kryptografischen Hash des public Key zu ersetzen. Das kürzt Sender und Empfänger im Spreadsheet ab, schützt aber das Geld der Benutzer im Falle eines Fehlers in der public Key Ableitungsfunktion, wie wir später sehen werden. Das Hashen geschieht nicht mittels einer einzelnen kryptografische Hashfunktion, sondern mit zwei verschiedenen, wie Abbildung 43 illustriert. Wir diskutieren den Grund für die Benutzung zweier Hashfunktionen im nächsten Abschnitt.

Der public Key wird zunächst mit SHA256 gehasht, womit du aus dem letzten Kapitel schon vertraut sein müsstest. Der Output dieser kryptografischen Hashfunktion wird dann mit RIPEMD160 gehasht, einer anderen kryptografischen Hashfunktion, die als Output eine 160 Bit (20 Byte) lange Zahl erzeugt. Wir nennen diesen letzten Hash den public Key Hash (PKH). Alle public Key im Spreadsheet werden durch ihre jeweiligen PKHs ersetzt.

Die Zahlung unterscheidet sich jetzt von der, bei der Faiza 100 CT von der Firma erhalten hatte. Angenommen John möchte einen Keks kaufen (Abbildung 44).

Erstens wird die Nachricht an Lisa etwas abgewandelt. John muss den PKH des Cafés–was früher der public Key war–als Empfänger verwenden. Der Sender ist immer noch ein public Key in der Nachricht, da der public Key zur Verifikation der Signatur benötigt wird. Lisa merkt sich ja nicht mehr die public Keys der Kollegen.

Zweitens, weil das Spreadsheet jetzt PKHs enthält, muss Lisa den PKH des Senders aus dem public Key des Senders ausrechnen, um den Kontostand des Senders zu berechnen und um in der Lage zu sein, die Zahlung in das Spreadsheet einzutragen.

RIPEMD160 als letzten kryptografischen Hash zu benutzen ist eine bewusste Wahl, damit die PKHs möglichst kurz werden. Vergleiche doch einmal die Outputs von SHA256 und RIPEMD160:

Es ist ein gut balancierter Tradeoff zwischen Sicherheit und Grösse.

Aber weshalb zwei verschiedene kryptografische Hashfunktionen? Wir wissen nicht genau, warum dieses Schema für Bitcoin ausgesucht wurde, weil sein Erfinder, Satoshi Nakamoto, aufgehört hat, mit der Bitcoin Community zu kommunizieren. Wir können nur spekulieren. Diskutieren wir stattdessen lieber die Eigenschaften dieses Verfahrens.

Wenn eine der Hashfunktionen sich als nicht Pre-Image resistent herausstellen würde, wäre es die andere immer noch. Wenn man also einen Input für RIPEMD160 berechnen könnte, der einen bestimmten PKH Output ergibt, dann müsste man immer noch eine Pre-Image Attacke gegen SHA256 (mit ungefähr 2²⁵⁵ mal raten) ausführen, um den public Key zu finden. Ebenso müsste man, wenn man einen Input für SHA256 finden könnte, der einen bestimmten Output erzeugt, immer noch erst eine Pre-Image Attacke auf RIPEMD160 ausführen, bevor man das Ergebnis zur Berechnung des public Keys hernehmen kann.

Sollte sich andererseits herausstellen, dass die Outputmenge einer der kryptografischen Hashfunktionen kleiner ist als angenommen, dann leidet darunter die Sicherheit der gesamten Hashfunktionen-Kette. Um das klarer zu machen, nimm an, SHA256 hätte nur 100 mögliche Output Werte. man kann dann Geld stehlen, indem man verschiedene zufällige private Keys ausprobiert und die korrespondierenden PKHs ausrechnet. Wenn ein PKH mit dem Zielwert übereinstimmt, dann hättest du einen private Key gefunden, mit dem du Geld stehlen könntest. Im Durchschnitt müsstest du nur 50 private Keys ausprobieren, um von einem PKH zu stehlen. Diese Eigenschaft verbindet das Schlechteste beider Welten: Wenn eine der beiden Funktionen Schwächen hat, dann ist die gesamte Kette geschwächt. Die Wahrscheinlichkeit, dass eine der Funktionen eine solche Schwäche hat, ist gering. Wenn es eine solche Schwäche wirklich gibt, dann ist die Verringerung der Outputmenge wahrscheinlich nicht signifikant genug, um die Sicherheit in der Praxis zu beeinträchtigen. Denke dran, dass wir immer noch keine einzige Kollision in irgendeiner dieser kryptografischen Hashfunktionen gefunden haben.

Es gibt ausserdem noch zu bedenken, dass unterschiedliche Organisationen die beiden kryptografischen Hashfunktionen entwickelt haben. RIPEMD160 wurde an einer Europäischen Universität in offener Kollaboration mit einer grossen Gemeinde von Kryptografen entwickelt. SHA256 wurde von der US National Security Agency (NSA) entwickelt. Beide werden als sicher betrachtet, und beide unterzogen sich genauesten Prüfungen durch eine grosse Menge Leute.

Jetzt, wo wir die Sicherheit des Cookie Token Spreadsheets verbessert haben, lass uns erneut über Sicherheit nachdenken. Hat es die Privacy verbessert? Ist es schwieriger für die Acme Versicherung geworden, Information darüber herauszufinden, wer wen bezahlt im Vergleich zu der Zeit, wo wir public Keys im Spreadsheet benutzt haben?

Die Antwort lautet Nein. Es gibt praktisch eine eins-zu-eins Beziehung zwischen public Keys und PKHs. PKHs zu benutzen verhüllt nicht zusätzlich persönliche Informationen gegenüber der Verwendung von public Keys.

Die sicherheitsorientierten Leute unter den Kollegen diskutieren das Problem mit den Tippfehlern und lassen sich die Idee mit Cookie Token Adressen einfallen. Eine Cookie Token Adresse ist ein PKH, der codiert wird, um Tippfehler zu bemerken. Der PKH kann zwischen dieser Codierung und dem einfachen Textformat hin und zurück konvertiert werden.

Angenommen Faiza tut John leid, und sie möchte ihm 20 CT von ihren 100 CT geben, um seinen Schmerz zu lindern. Sie möchte nicht denselben Fehler wie John begehen, also bittet sie ihn um seine Cookie Token Adresse. John erzeugt diese, indem er seinen PKH mit einer Funktion namens base58check codiert (Abbildung 47).

Das Resultat ist Johns Cookie Token Adresse: 19g6oo8f…gCenRBPD. John reicht diese Adresse Faiza, die dann die Zahlung anhand des Prozesses in Abbildung 48 durchführt.

Der Zahlungsprozess ändert sich für den Sender, aber für Lisa ändert sich nichts. Faiza base58check–decodiert Johns Adresse in einen PKH. Dieses Decodieren stellt sicher, dass keine Tippfehler in der Adresse gemacht worden waren.

Wie zuvor erwähnt, kann ein PKH von und zu einer Adresse konvertiert werden. Es ist keine Einwegfunktion. Es sind lediglich zwei verschiedene Arten, den PKH zu repräsentieren, entweder als eine Serie von Bytes oder als eine Adresse (Abbildung 49).

Die Mail an Lisa ist genau dieselbe wie bisher. Nur Benutzer verwenden die Cookie Token Adresse. Sie gehört keineswegs zu Lisas Validierungsprozess oder zum Spreadsheet.

Die Kozepttabelle (Tabelle 11) hat sich in diesem Kapitel nicht verändert. Cookie Token Adressen sind exakt das, was Bitcoin benutzt, also haben wir keine Konzepte eingeführt, die von Bitcoin abweichen.

Dank PKH und Cookie Token Adressen kann Lisa ihre Tabelle von public Key loswerden. Wir nehmen PKH und Adressen in unseren Werkzeugkasten mit auf und geben Version 3.0 des Cookie Token Systems frei (Tabelle 12).

Die Stärke eines Passworts wird in Entropie gemessen. Je höher die Entropie, desto schwieriger ist es, das Passwort zu erraten. Das Wort Entropie, wie es in der Informationssicherheit verwendet wird, kommt aus der Thermodynamik und bedeutet Unordnung oder Unsicherheit. Angenommen du konstruierst ein Passwort aus 8 Zeichen aus dem Satz der folgenden 64 Zeichen:

Jedes Zeichen im Passwort würde dann 6 Bits Entropie darstellen, denn es gibt 64 = 2⁶ mögliche Zeichen. Wenn du 8 Zeichen daraus zufällig wählst (nichts herauspicken, bitte!), sagen wir E3NrkbA7, dann wird das 8 Zeichen lange Passwort 6 × 8 = 48 Bits an Entropie haben. Das entspricht von der Stärke her 48 Münzwürfen.

Nimm stattdessen an, dass du zufällige Wörter aus einem Vorrat von 2¹¹= 2,048 Wörtern heraussuchst. Wie viele Wörter brauchst du, um die 48 Bit Entropie von deinem 8 Zeichen langen Passwort zu schlagen? Vier Wörter wären nicht genug, denn das wären 4 × 11 = 44 Bit Entropie. Aber fünf Wörter stünden schon für 55 Bit Entropie, was besser ist als die Entropie des Passworts.

Die echte Entropie eines Passworts hängt aber auch davon ab, was der Angreifer über das Passwort weiss. Zum Beispiel, mal angenommen ein Angreifer, Mallory, stiehlt Johns verschlüsselte Backupdatei und versucht, es mit der Holzhammermethode, oder brute force attack zu knacken. Eine brute force attack heisst, der Angreifer geht durch alle möglichen Passwörter und rät immer und immer wieder, bis er das richtige Passwort findet. Wenn Mallory weiss, dass das Passwort genau 8 Zeichen lang ist, und dass die Zeichen zu den vorhin genannten 64 Zeichen gehören müssen, dann ist die Entropie 48 Bit. Wenn sie weiss, dass das dritte Zeichen 3 ist, sinkt die Entropie auf 6 × 7 = 42 Bit. Wenn Mallory auf der anderen Seite nicht weiss, wie viele Zeichen das Passwort hat, wird es schwieriger für sie, das heisst die Entropie wird höher sein.

Das gilt nur, wenn die Passwort Auswahl wirklich völlig zufällig ist. Wenn John sich Zeichen auswählt, um sich das Passwort j0Hn4321 auszusuchen, fällt die Entropie dramatisch. Typische brute-force Angriffsprogramme probieren zuerst eine Menge bekannte Wörter und Namen in verschiedenen Variationen, bevor sie “zufälliger” aussehende Passwörter probieren. John ist ein geläufiger Name, also wird ein Angreifer eine Menge verschiedener Variationen dieses Namens probieren, sowie andere Namen und Worte. Zum Beispiel:

Bingo! Angenommen es gibt 1.000.000 geläufige Wörter und Namen, und jedes Wort kommt durchschnittlich in 100.000 Variationen. Das sind 100 Milliarden verschiedene Passwörter zum Ausprobieren, was etwa 37 Bit Entropie entspricht; für 100 Milliarden Versuche braucht ein High-End Desktop Computer ein paar Tage. Sagen wir, der Einfachheit halber, dass es einen Tag dauert. Benutzt John ein echtes Zufallspasswort, dann ist die Entropie für den Angreifer 48 Bit. Das wären rund 2.000 Tage, oder etwa 5,5 Jahre, um das Passwort zu knacken.

Der Prozess für passwortgeschützte Backups klappt ziemlich gut, führt aber auch neue Probleme ein:

Anscheinend musst du dir immer noch ein gutes Schema einfallen lassen, um mit Backups zurechtzukommen. Geben wir uns aber nicht mit dieser halbgaren Lösung zufrieden–es gibt bessere Ansätze.

Schauen wir uns die Erzeugung eines Master xprv näher an (Abbildung 63).

Um einen neuen Master private Key zu erzeugen, wird der Seed mit HMAC-SHA512 gehasht (HMAC ist die Abkürzung für Hash Based Message Authentication Code), was einen 512 Bit Hashwert ergibt. HMAC-SHA512 ist eine spezielle kryptografische Hashfunktion, die neben dem normalen einfachen Input noch einen Key erwartet. Aus Benutzersicht kann man HMAC-SHA512 als normale kryptografische Hashfunktion betrachten, aber als eine mit mehreren Inputs. Der Hashwert wird in die linken 256 Bit und die rechten 256 Bit aufgespalten. Die linken 256 Bit werden zum Master private Key, was ein normaler private Key ist.; er heisst nur Master private Key, weil alle anderen private Keys von diesem einzelnen private Key abgeleitet werden (sowie vom Chain Code). Die rechten 256 Bit werden der Chain Code, der im nächsten Schritt benutzt wird, um die Kinder vom Master xprv abzuleiten.

Du hast Ritas Master xprv erzeugt. Es ist Zeit, den Child xprv abzuleiten, der die drei Sparkonto-Keys bündelt. Die direkten Kinder eines xprvs können in beliebiger Reihenfolge abgeleitet werden. Leiten wir den Sparkonto-Key m/1 zuerst ab. Der Vorgang, um ein Child xprv von einem Parent xprv abzuleiten, ist wie folgt (Abbildung 64):

Derselbe Prozess wird für alle Children und Grandchildren des Master xprv benutzt, bis man alle Keys hat, die Rita in ihrem Wallet haben wollte.

Du fragst dich vielleicht, wozu man die Addition braucht–warum nimmt man nicht einfach die linken 256 Bits als Child private Key? Der 512 Bit Hash wird vom public Key und dem Chain Code–zusammen als extended public Key (xpub) bezeichnet–und dem Index berechnet. Du siehst später, wie der xpub in weniger sicheren Umgebungen, zum Beispiel auf einem Web Server, zur Erzeugung eines ganzen Baumes von public Keys benutzt werden kann. Man muss den Parent private Key zu den linken 256 Bit addieren, damit jemand, der den xpub besitzt, keine Child private Keys generieren kann.

Erinnere dich daran, dass ein Seed eine Abfolge von Bits ist. Zum Beispiel ist Ritas Seed 128 Bit lang. Was, wenn man das auf menschenfreundlichere Art codieren könnte? Man kann!

Ritas Wallet kann den Seed als Abfolge von 12 englischen Wörtern darstellen, die als mnemonic sentence oder mnemonischer Satz (Merksatz) bezeichnet werden:

Das Codieren beginnt mit dem Zufalls-Seed, wie in Abbildung 66 gezeigt. Der Seed wird mit SHA256 gehasht, und die ersten 4 Bits des Hashes–in diesem Fall 0111–werden an den Seed angehängt. Diese 4 Bits dienen as Checksum. Dann arrangieren wir die Bits in 12 Gruppen zu 11 Bit, wobei jede Gruppe eine Zahl im Bereich 0 bis 2047 codiert. Elf Bits können 2¹¹ = 2,048 verschiedene Werte darstellen, erinnerst du dich?

Die 12 Zahlen werden in einer standardisierten Wortliste aus 2048 Wörtern nachgeschaut, die von 0 bis 2047 durchnumeriert ist. Du findest diese Liste in BIP39 auf Web resource 9; sie enthält gängige englische Wörter. Nachdem du alle 12 Zahlen dort nachgeschaut hast, besitzt du den mnemonic sentence.

Der Satz bedeutet nichts besonderes. Es sind einfach 12 zufällige Wörter, so wie der hex-codierte Seed auch aus 32 zufälligen Hexziffern besteht.

Ritas Wallet zeigt ihr den mnemonic sentence, und sie schreibt die 12 Wörter auf ein Stück Papier. Sie legt das Papier in einen Safe und kümmert sich wieder um ihren Alltag.

Am nächsten Tag fällt Rita das Telefon ins Meer und verschwindet in der Tiefe. Sie hat ihr Wallet verloren! Aber Rita macht sich keine grossen Sorgen. Sie kauft ein neues Telefon und installiert die Wallet App. Sie wählt die Funktion zum Restaurieren des Seeds aus einem Backup. Das Wallet bittet um den mnemonic sentence. Sie schreibt

in die Wallet App. Die App decodiert den Satz, indem sie den Codierprozess umkehrt. Rita kann ihre Keys aus dem decodierten Seed regenerieren, wie Abbildung 67 zeigt.

Das Decodieren benutzt die 4 Bit Checksum, um sicherzustellen, dass alles stimmt. Wenn Rita versehentlich als letztes Wort deposit anstelle von depend schreibt, wird die Checksum wahrscheinlich nicht passen, weil sie das falsche Wort am Ende geschrieben hatte. Wenn sie depends statt depend schreibt, wird das Decodieren definitiv scheitern, weil es das Wort depends in der Wortliste gar nicht gibt.

Die Checksum ist ziemlich schwach–4 Bit ergeben nur 16 mögliche Checksums. Ein falsch geschriebener mnemonic sentence, in dem alle Wörter in der Wortliste vorkommen, hat daher eine 1/16 Wahrscheinlichkeit, nicht entdeckt zu werden. Das scheint ziemlich schlecht zu sein. Aber die Wahrscheinlichkeit, dass man solch einen Satz schreibt, ist ziemlich klein, denn die falsch geschriebenen Wörter müssten in der Wortliste vorkommen. Das verringert das Risiko eines ungültigen mnemonic sentence beim Wiederherstellen.

Denk zurück an vorhin, als du in Kapitel 2 einen public Key aus einem private Key hergeleitet hast. Ich habe dir da eigentlich gar nicht gesagt, wie der public Key abgeleitet wurde. Das werde ich stattdessen hier probieren.

Ein public Key in Bitcoin ist eine ganzzahlige Lösung zu folgender Gleichung:

Viele solcher Lösungen existieren, ungefähr \(2^{256}\) davon, also vereinfachen wir, indem wir stattdessen die Lösungen zu \(y^2 = x^3 + 7 \mod{11}\) (Abbildung 76) benutzen.

Die vorangegangenen Gleichungen sind Beispiele einer Klasse von Gleichungen, die als elliptische Kurven bezeichnet werden, und eine Lösung wird oft ein Punkt auf der Kurve genannt. Du kannst jetzt einen public Key, der ein Punkt auf der Kurve ist, aus einem private Key berechnen. Um dies zu tun, beginnst du an einem bestimmten Punkt, \(G=(6,5)\), auf der Kurve. \(G\) wurde mehr oder weniger willkürlich ausgesucht, ist aber allen als Ausgangspunkt für die public Key Herleitung wohlbekannt. Der public Key ist der private Key multipliziert mit \(G\).

Angenommen dein private Key ist \(5\). Dann ist dein public Key \(5G\).

Um diese Multiplikation auszurechnen, brauchst du zwei grundlegende public Key Operationen: Addition und Verdopplung, wobei Verdopplung als Addition des Punktes zu sich selbst betrachtet werden kann.

Um zwei Punkte zu addieren (Abbildung 77) ziehst du eine Gerade, die an den Rändern des Diagramms “umgebrochen” wird und die sowohl deine beiden Punkte schneidet als auch einen dritten Punkt. Dieser dritte Punkt ist das negative Resultat der Addition. Um das Endresultat der Addition zu erhalten, nimmst du den symmetrischen Punkt am selben \(x\) Wert.

Das Ergebnis von \((6, 5) + (2, 2)\) ist \((7, 8)\). Die Gerade zwischen den beiden Punkten schneidet den Punkt \((7, 3)\). Der komplementäre Punkt zu \((7, 3)\) ist \((7, 8)\), was das Ergebnis der Addition ist.

Einen Punkt zu verdoppeln (Abbildung 78) heisst, ihn zu sich selbst zu addieren, aber eine Steigung kann nicht aus einem einzigen Punkt berechnet werden. In diesem Spezialfall berechnet man die Steigung aus dem Einzelpunkt \(P=(6,5)\) durch \(3*x^2*(2y)^{-1} \mod{11} = 2\). Der Vorgang ist fast derselbe wir bei der Addition zweier unterschiedlicher Punkte, aber die Steigung wird anders berechnet.

Mit diesen zwei Grundoperationen, Addition und Verdopplung, kann man die Multiplikation von \(5\) und \(G\) herleiten. In binärer Form ist \(5\)

Der public Key ist dann

Fange bei \(G\) an und berechne den resultierenden public Key Punkt, indem du die Terme von links nach rechts durchgehst:

Kurz gesagt basiert Multiplikation auf einer Abfolge von Additions- und Verdopplungsoperationen.

Der Multiplikationsvorgang ist relativ einfach durchzuführen; es braucht ungefähr 256 Schritte für 256 Bit lange private Keys. Aber das umzukehren ist eine völlig andere Geschichte. Es gibt keinen bekannten Weg, den private Key durch Punkt-“Division” (zum Beispiel, Punkt \((6,6)\) “geteilt durch” \(G\)). Der einzige bekannte Weg besteht darin, verschiedene private Keys auszuprobieren und zu sehen, ob dessen public Key derjenige ist, den du suchst. Das macht die public Key Ableitung zu einer Einbahnfunktion.

Du hast gesehen, wie ein normaler public Key aus einem private Key durch public Key Multiplikation hergeleitet werden kann. Aber wie kann die Addition eines Parent public Keys zu einem public Key, der aus den linken 256 Bits abgeleitet wurde, den Child public Key ergeben? Siehe Abbildung 79.

Du kannst dich überzeugen, dass das funktioniert, indem du sowohl die normale public Key Herleitung als auch die Child public Key Herleitung im selben Bild betrachtest: siehe Abbildung 80.

Das Schöne an elliptischen Kurven ist, dass die spezielle public Key “Addition” Operation ein bisschen funktioniert wie eine normale Addition. Dasselbe gilt für die spezielle public Key “Multiplikation”. Man kann daher einige Gleichungen lösen:

Das Ergebnis, \(C=Gc\), ist genau wie man den public Key \(C\) vom private Key \(c\) ableiten kann.

Erinnerst du dich daran, dass Johns public Key wie eine riesige Zahl aussah?

Das sieht nicht wie ein Koordinatenpaar aus, oder? Der public Key wird auf eine bestimmte Art codiert, Aufgrund der Symmetrie existieren exakt zwei Punkte für jeden Wert von stem\:[x], einer mit einem geraden stem\:[y] Wert und einer mit einem ungeraden stem\:[y] Wert (Abbildung 81).

Man braucht die \(y\) Werte nicht zu speichern, sondern nur, ob der \(y\) Wert gerade oder ungerade it. Das geschieht, indem man dem \(x\) Wert eine 02 (gerade) oder 03 (ungerade) voranstellt. In Johns Fall ist der \(y\) Wert ungerade, also lautet das Prefix 03.

Deshalb sind public Keys 33 Bytes und nicht 32 Bytes lang. Es ist eine 256 Bit Zahl–die \(x\) Koordinate–mit einem Byte als Prefix, das die Geradzahligkeit oder Parität angibt.

Die Kurve in der Abbildung hat einen einzelnen Punkt \(x=5, y=0\). Das sieht nicht symmetrisch aus, aber es ist eine sogenannte Doppel-Wurzel der Kurve—zwei Punkte mit dem selben \(y\) von 0. Sie sind symmetrisch, weil sie dieselbe Strecke von 5.5 von der Symmetrielinie entfernt sind. In diesem Fall benutzen beide Punkte 02, weil 0 eine gerade Zahl ist.

Unsere Konzepttabelle (Tabelle 13) wird in diesem Kapitel nicht aktualisiert. Die Wallets, die hier beschrieben sind, funktionieren im Grunde genauso wie sie es in Bitcoin tun, nur schicken sie Mails an Lisa anstatt Transaktionen ans das globale Bitcoin Netzwerk zu senden. Dazu kommen wir im nächsten Kapitel.

Feiern wir eine Release Party! Cookie Tokens 4.0, frisch aus dem Labor!

Übungen 4.7 und 4.8 setzen voraus, dass du Abschnitt 4.7 gelesen hast. Wenn du das übersprungen hast, kannst du auch diese Übungen überspringen.

Wenn du Abschnitt 4.7 nicht gelesen hast, kannst du Übung 4.11 überspringen.

Tauchen wir tiefer ein und schauen, wie Johns Transaktion zusammengebaut wird.

Johns Wallet hat eine neue Transaktion generiert (Abbildung 85). Diese hat zwei Inputs und zwei Outputs. Inputs geben an, welche Outputs früherer Transaktionen ausgegeben werden sollen. Outputs geben an, wo das Geld hingehen soll.

Die Transaktion ist bereit zum Senden an Lisa. Johns Wallet schickt es als Anhang in einer Mail. Lisa schnappt sich die Transaktion und prüft, dass:

Lisa braucht das Saldo des PKH nicht mehr zu berechnen, aber sie muss noch prüfen, dass der ausgegebene Output existiert und nicht bereits ausgegeben wurde.

Wie prüft sie, ob ein Output noch unverbraucht ist? Muss sie nicht das Spreadsheet durchsuchen, um Transaktionen zu finden, die diesen Output verwenden? Ja, das muss sie. Das scheint nicht weniger mühsam als durch das Spreadsheet zu gehen, um die Salden zu berechnen. Aber keine Sorge: Lisa hat einen Plan.

Jetzt, da Johns Transaktion genauso abgespeichert wird wie er sie erzeugt hat, kann jeder mit Lesezugriff sie überprüfen. Jeder kann ein privates UTXO Set generieren und sich durch die Transaktionen durcharbeiten. Am Ende wird er dasselbe UTXO Set wie Lisa haben.

In Bitcoin heissen diese Verifikatoren Full Nodes. Lisa ist also ein Full Node (ein Verifizierer), aber sie tut mehr als ein Full Node–sie aktualisiert auch das Spreadsheet. Ein Full Node heisst auch verifizierender Node oder einfach Node in Bitcoin.

Lisa kann nicht mehr jemand anderem Geld stehlen, weil das Spreadsheet ungültig würde, wenn sie es täte. Nehmen wir zum Beispiel an, sie würde versuchen, den Output Empfänger von Johns Transaktion von PKH_C auf PKH_L abzuändern. Sie würde damit effektiv versuchen, 10 CT vom Café zu stehlen (Abbildung 90).

Weil Lisa den Inhalt von Johns Transaktion geändert hat, sind die Signaturen nicht mehr gültig. Jeder mit Zugriff auf das Spreadsheet kann dies bemerken, weil alles super transparent ist.

Reflektieren wir nochmal über die Änderungen, die wir gemacht haben. Wir sind von einem kontenbasierten System zu einem wertbasierten System übergegangen.

Ein kontenbasiertes System führt Buch darüber, wie viel Geld auf jedem Konto liegt. Diesen Typ von System hatten wir vor diesem Kapitel. Lisa musste das Saldo einer PKH ausrechnen, bevor sie entschied, ob eine Zahlung durchgeht oder nicht.

Ein wertbasiertes System verfolgt stattdessen “Coins”. In diesem Kapitel muss Lisa sicherstellen, dass spezielle Coins (UTXOs) existieren, bevor sie entscheidet, eine Zahlung zuzulassen. Sie braucht nicht den Kontostand irgendwelcher PKHs zu ermitteln. Bitcoin ist ebenfalls ein wertbasiertes System.

In dem Beispiel, das ich gerade präsentiert habe, ist das einzige akzeptable Signatur Script eine gültige Signatur, gefolgt von dem public Key, der mit dem PKH im Pubkey Script korrespondiert.

Eine Programmiersprache, Script, in den Transaktionen zu benutzen macht diese sehr flexibel. Du wirst mehrere verschiedene Typen von Script Programmen in diesem Buch zu sehen bekommen. Wenn die Transaktionen keine Programmiersprache benutzen würden, hätten alle Anwendungsfälle schon vorab erfunden werden müssen. Die Script Sprache lässt einen später nach Bedarf neue Anwendungsfälle einrichten.

Ich habe bereits erwähnt, dass “pay to PKH” nicht die einzige Art zu zahlen ist. Man kann in einem Pubkey Script beliebige Programme schreiben. Zum Beispiel kann man ein Pubkey Script schreiben, das mit OK nur dann endet, wenn das Signatur Script zwei Zahlen enthält, deren Summe 10 ist. Oder ein Programm, das nur dann mit OK endet, wenn das Signatur Script das SHA256 Pre-Image eines Hashes enthält. Schau dir folgendes Beispiel an:

Dies gestattet jedem das Ausgeben des Outputs, der einen Input für SHA256 liefert, der als Hashwert 334d016f…d42c87b7 liefert. Du weisst zufälligerweise aus Kapitel 2, der Text "Hello!" genau diesen Wert erzeugt. Angenommen, dein Signatur Script ist

Lass das Programm laufen um dich zu vergewissern, dass es funktioniert und dass alle Signatur Scripts, die kein korrektes Pre-Image enthalten, scheitern.

Du fragst dich vielleicht, warum wir den Output Script Teil Pubkey Script nennen, obwohl es doch keinen public Key enthält. Und ebenso, warum das Input Script Signatur Script heisst, obwohl es nicht nur aus einer Signatur besteht.

Das Pubkey Script in Bitcoin Transaktionen enthielt früher einen richtigen public Key, und das Signatur Script bestand nur aus der Signatur. Damals war es einfacher. Ein typisches Pubkey Script sah so aus

und das Signature Script so:

Die Dinge haben sich seitdem verändert, aber die Namen Signatur Script und Pubkey Script sind geblieben. Die meisten Entwickler betrachten das Ganze abstrakter: man kann das Pubkey Script als public Key betrachten und das Signatur Script als Signatur, aber nicht notwendigerweise als normale public Keys und Signaturen. In einer normalen Zahlung heute ist der "public Key" das Script, das durch die "Signatur" erfüllt werden muss, das Signatur Script. Natürlich enthält hier der "public Key" einige Operatoren und einen PKH, aber wir können ihn konzeptionell immer noch als public Key betrachten. Das gleiche gilt für das Signatur Script, das wir konzeptionell als Signatur betrachten können.

In p2pkh erzeugt der Empfänger eine Cookie Token Adresse, die dem Sender übergeben wird. Der Sender zahlt dann an diese Adresse.

Aber was, wenn der Empfänger sein Geld lieber mit etwas anderem absichern will als mit einem einfachen private Key? Angenommen Faiza, Ellen und John wollen Spenden von ihren Kollegen für einen guten Zweck sammeln.

Sie könnten eine normale p2pkh Adresse benutzen, an die die Spender zahlen würden. Sie könnten dann zum Beispiel Faiza den private Key geben, sadass nur sie das Geld ausgeben könnte. Dieser Ansatz hat ein paar Probleme:

In diesem Aufbau scheint eine Menge Risiko zu stecken, aber was, wenn Faiza den private Key ihren beiden Wohltätigkeits-Kollegen gibt? Dann kann jeder von denen das Geld ausgeben. Das löst Probleme 1 und 2, aber Probleme 3 und 4 würden schlimmer werden, weil jetzt jeder der drei den private Key nachlässig sichern oder mit dem Geld durchbrennen könnte.

Die Organisation besteht aus drei Leuten. Es wäre besser, wenn diese drei irgendwie die Verantwortung und Kontrolle über das Geld teilen könnten. Dank der Script Programmiersprache können sie dies tun.

Sie können je einen private Key erzeugen und verlangen, dass zwei der drei Keys die Transaktion signieren, bevor die Spenden ausgegeben werden können. (Abbildung 99).

Dies führt einige gute Eigenschaften in den Wohltätigkeits-Fonds ein:

Abbildung 100 zeigt ein Script Programm, das die zwei-aus-drei Regel umsetzt.

Der OP_CHECKMULTISIG Operator instruiert Lisa, zu prüfen, dass die zwei Signaturen im Signatur Script mit den Keys im Pubkey Script erzeugt wurden. Lisa lässt das Programm in Abbildung 101 laufen.

Die obersten acht Datenobjekte im Programm werden auf den Stack gelegt. Danach wird der einzige Operator, OP_CHECKMULTISIG, gestartet, wie in Abbildung 102 dargestellt. OP_CHECKMULTISIG nimmt eine Zahl, in diesem Fall 3, vom Stack herunter und erwartet dann diese Anzahl public Keys auf dem Stack, gefolgt von einer weiteren Zahl. Diese zweite Zahl gibt an, wie viele Signaturen zum Ausgeben des Geldes benötigt werden. In diesem Fall ist die Zahl 2. Der Operator nimmt dann die erwartete Anzahl Signaturen vom Stack, gefolgt von dem oben genannten Dummy. Das Dummy Objekt wird nicht benutzt.

OP_CHECKMULTISIG benutzt all diese Informationen und die Transaktion, um festzustellen, ob genug Signaturen erstellt wurden, und verifiziert diese Signaturen. Wenn alles OK ist, tut er OK zurück auf den Stack. Damit endet das Programm. Weil auf dem Stack oben OK liegt, ist das Ausgeben des Outputs autorisiert.

Ein Kollege, der Cookie Tokens an den wohltätigen Fonds spenden möchte, muss sein Wallet dazu bringen, das Pubkey Script in Abbildung 100 in den Transaktions-Output zu schreiben. Das erzeugt ein paar Probleme:

Man kann dies mit einer kleinen Änderung in der Weise, wie die Programme laufen, korrigieren. Ein paar der Entwickler unter deinen Kollegen erfinden etwas namens pay-to-script-hash (p2sh).

Wir haben diskutiert, wie p2pkh den public Key vor dem Sender versteckt, der anstelle des public Key nur den Hash des public Key zu sehen bekommt.

p2sh spinnt diese Idee noch weiter–es versteckt das Script Programm. Anstatt dem Sender ein grosses, kompliziertes Script Programm zu geben, gibt man ihm nur den Hash des Scripts. Der Sender bezahlt dann an diesen Hash und überlässt es dem Empfänger, später das Script zu liefern, wenn er das Geld ausgeben möchte.

Nehmen wir wieder mal an, dass Faiza, Ellen und John Geld für eine Hilfsorganisation sammeln wollen, und sie wollen ein Multisignatur Setup benutzen, um das Geld zu sichern (Abbildung 103).

Um diese Transaktion vollständig zu validieren, brauchen wir neue Software. Wir sprechen gleich darüber, wie die neue Software diese Transaktionen verifiziert. Lass uns zuerst schauen, wie die alte Software es machen würde.

Faiza, Ellen und John haben ein zwei-aus-drei Multisignatur Redeem Script erzeugt:

Sie wollen jetzt, dass Leute an den SHA256+RIPEMD160 Hash des Redeem Scripts bezahlen:

Wie sagen Faiza, Ellen und John den Leuten, wohin sie zahlen sollen? Was drucken sie auf die Flugblätter, damit die Kollegen an ihren Script Hash zahlen können? Schauen wir uns ein paar Möglichkeiten an:

In beiden Fällen, wenn der Spender irrtümlich eine p2pkh Zahlung mit dem gedruckten Hash oder der Adresse macht, kann niemand das Geld ausgeben, weil kein private Key mit diesem falschen PKH korrespondiert.

Diese zwei Optionen scheinen also weder sicher noch praktikabel. Lass uns stattdessen ein neues Adressformat für p2sh einführen, die ps2h Adresse (Abbildung 107). Dieses Format ist ähnlich wie die normalen p2pkh Adressen. Es benutzt das base58check Codierschema, genau wie normale Adressen dies tun.

Der Vorgang ist fast derselbe wie bei p2pkh Adressen. Der einzige Unterschied ist, dass die Version 05 ist statt 00. Das führt dazu, dass die Adresse mit einer 3 beginnt statt mit einer 1.

Wegen dieser Änderung und aufgrund der Funktionsweise von base58–wiederholte Integerdivision durch 58–wird der letzte Rest immer 2 sein. Wenn es dich interessiert, in Abbildung 108 siehst du die base58 Codierung des versionierten und mit Checksum versehenen Script Hashes von Faizas, Ellens und Johns Script.

Der letzte Rest 2 übersetzt sich zu 3 in der Zeichen-Lookup-Tabelle von base58. Dieses Zeichen 3 wird zum ersten Zeichen, wenn der base58 Prozess den Umkehrschritt durchführt. Daher beginnen alle p2sh Adressen mit 3. So können Benutzer sie als p2sh Adressen erkennen und nicht zum Beispiel als p2pkh Adressen.

Faiza, Ellen und John können jetzt 328qTX…wrB2ag auf die Flugblätter drucken. Wenn ein Kollege den QR code ihres Flugblattes scannt, erkennt deren Wallet die Adresse als p2sh Adresse, weil sie mit 3 beginnt.Das Wallet wird die Adresse base58check-decodieren und einen korrekten ps2h Output erzeugen:

Dies beendet unsere Diskussion über programmierbare Transaktionen. Du hast gelernt, dass Transaktionen eine Menge verschiedener Bedingungen für das Ausgeben des Geldes setzen können. Wohlgemerkt kann man nicht diktieren, wo das ausgegebene Geld hingehen soll, nur was der Input liefern muss, damit er das Geld ausgeben kann. Das Pubkey Script definiert die Regeln für das, was das Signatur Script liefern muss. Später im Buch werden wir Transaktionen noch einmal anschauen um über noch extravagantere Sachen zu reden, die man mit ihnen machen kann, wie zum Beispiel das Geld bis zu einem bestimmten Zeitpunkt einzufrieren.

Du fragst dich vielleicht, wie die Kollegen vom alten Spreadsheet–wie es in Release 4.0 war–auf das neue umstellen konnten, das mit den Transaktionen. Was ist mit den existierenden Cookie Tokens im Spreadsheet passiert?

Sie hatten sich alle auf einen Zeitslot geeinigt, an dem der Upgrade stattfinden würde. Während dieser Zeit erzeugte Lisa eine einzelne, riesige Transaktion mit einem Output pro PKH im Spreadsheet. Die Transaktion sieht aus wie eine Coinbase Transaktion, aber mit einer Menge Outputs. Jeder kann eine Version des alten Spreadsheets vorhalten und verifizieren, dass diese Transaktion exakt dieselben Outputs enthält wie das alte UTXO Set. Neue Prüfer können jedoch nicht sicher sein, ob es gut gelaufen ist - sie müssen Lisa damit vertrauen.

Bedenke, dass dies in Bitcoin, das von Anfang an für Transaktionen konzipiert wurde, überhaupt nicht so ist. Der „Initialzustand“ in Bitcoin war ein leeres UTXO Set. Niemand hatte Bitcoins.

Transaktionen und die txid hast du jetzt in deinem Werkzeugkasten. Die Konzept-Tabelle (Tabelle 15) schrumpft um zwei Zeilen: Mails an Lisa und Zeilen im Spreadsheet werden durch Transaktionen ersetzt. Wir schicken wohlgemerkt immer noch Transaktionen an Lisa, aber die Transaktionen haben dasselbe Format wie in Bitcoin. Deshalb können wir sie jetzt entfernen.

Das nächste Kapitel widmet sich dem Ersetzen des Spreadsheets, das jetzt die Transaktionen enthält, durch eine Blockchain.

Geben wir Version 5.0 des Cookie Token Systems frei (Tabelle 16).

Lisa erzeugt grob alle 10 Minuten einen neuen Block, der unbestätigte Transaktionen enthält. Sie schreibt den Block in eine neue Datei in einem geteilten Ordner, oder Share. Jeder hat die Zugriffsrechte, um neue Dateien in dem Share anzulegen, aber niemand hat die Rechte, Dateien zu ändern oder zu löschen. Wenn Lisa einen Block in eine Datei in dem Share schreibt, bestätigt sie die Transaktionen in dem Block.

Angenommen, Lisa ist dabei, einen neuen Block auf Höhe 20 zu erstellen. Sie tut folgendes:

Angenommen, Lisa will einen Keks essen, ohne dafür zu bezahlen. Sie erzeugt eine Transaktion und legt sie in den Block, an dem sie zur Zeit arbeitet, an Blockhöhe 21. Sie erzeugt den Block Header, signiert ihn und schreibt den Block in eine neue Datei (block_21.dat) im Share (Abbildung 120).

Das Café schaut im Share nach eingehenden Zahlungen. Wenn Lisa die Blockdatei in den Share schreibt, lädt das Café den Block herunter und verifiziert ihn. Zum Verifizieren eines Blockes muss Folgendes überprüft werden:

Lisa hat für den Keks bezahlt, und das Café hat den Block, der Lisas Transaktion enthält, heruntergeladen und überprüft. Das Café gibt Lisa den Keks, und sie isst ihn.

Kann Lisa die Zahlung rückgängig machen, ohne dass man ihr Betrug nachweisen kann? Ihre einzige Option ist, eine veränderte Version von Block 21 anzufertigen, der ihre Transaktion nicht enthält, und diesen neuen Block als neue Datei block_21b.dat in den Share zu schreiben (Abbildung 121).

Die neue Version gleicht der alten bis auf Lisas fehlende Transaktion. Weil sie an den Transaktionen im Block herumgepfuscht hat, muss sie den Merkle Root im Header mit einem Merkle Root aktualisieren, der zu dem neuen Satz an Transaktionen passt, die der Block jetzt enthält. Wenn sie den Header ändert, ist die Signatur nicht mehr gültig, und der Header muss neu signiert werden. Um den Block den Überprüfern zugänglich zu machen, muss sie den Block in den Share legen, zum Beispiel unter dem Dateinamen block_21b.dat.

Das Café hatte bereits die erste Version von Block 21 heruntergeladen. Wenn Lisa die neue Blockdatei schreibt, wird das Café herausfinden, dass es eine weitere Version des Blocks im Share gibt (Abbildung 122).

Jetzt sieht das Café zwei verschiedene Blocks auf Höhe 21, einen mit der 10 CT Transaktion zum Café und einen ohne. Beide Blocke sind gleichermassen gültig, und aus der Perspektive eines Prüfers ist kein Block richtiger als der andere. Aber das Gute ist, dass das Café beweisen kann, dass Lisa ein schmutziges Spiel spielt, weil sie zwei verschiedene signierte Versionen des Blocks erzeugt hat. Die Signaturen beweisen, dass Lisa gemogelt hat, und jetzt haben wir nicht mehr eine Aussage-gegen-Aussage Situation. Lisa wird gefeuert oder zumindest ihrer mächtigen Stellung als Transaktionsverarbeiterin enthoben.

Was wäre, wenn es noch weitere Blocks hinter Block 21 gegeben hätte, als Lisa gemogelt hat? Nimm an, Blocks 22 und 23 waren bereits erstellt, als Lisa sich entschieden hat, ihre Transaktion zu löschen (Abbildung 123).

Jetzt muss sie drei alternative Blocks erzeugen: 21, 22 und 23. Diese müssen alle durch gültige Blocks ersetzt werden.

Die Blockchain ist ein komplizierter Weg, einen Haufen Transaktionen zu signieren. Wäre es nicht viel einfacher, wenn Lisa schlicht alle Transaktionen, die je gemacht wurden, in einem riesigen Klumpen alle 10 Minuten signieren würde? Das würde dasselbe Ziel erreichen. Aber dieser Ansatz birgt einige Probleme:

Indem sie eine Blockchain benutzt, braucht Lisa nur den letzten Block von Transaktionen zu signieren, womit sie aber stillschweigend, indirekt über den Vorgänger Block ID Zeiger, alle historischen Transaktionen mit signiert, wie Abbildung 124 zeigt.

Die Signatur jedes Blocks erhärtet die Signaturen der Vorgängerblocks. Das wird sich als wichtig erweisen, wenn wir im nächsten Kapitel zu Proof of Work kommen werden.

Die Prüfer können auch leicht sehen, was sich seit dem letzten Block geändert hat, und ihre UTXO Sets entsprechend anpassen. Alle neuen Transaktionen stehen ja in dem neuen Block.

Die Blockchain liefert auch ein paar nette zusätzliche Features, die wir später besprechen werden, zum Beispiel den Merkle Tree.

Johns Wallet enthält die zwei Adressen @_a und @_b, aber John möchte niemandem gegenüber preisgeben, dass @_a und @_b zum selben Wallet gehören. Er hat auch Grund, misstrauisch zu sein, denn ihm ist zu Ohren gekommen, dass die Acme Versicherung viel Geld für solche Informationen bezahlt, um die Prämien auf Basis des Kekskonsums der Leute “anzupassen”.

Es wird Zeit, aufzuklären, wie Lisa den Merkle Root erzeugt hat. Nimm an, Lisa fängt gerade an, den Block Header in Abbildung 131 zu erzeugen. Sie muss den kombinierten Hash aller Transaktionen berechnen, der als Merkle Root bezeichnet wird (Abbildung 132). Man berechnet den Merkle Root, indem man eine Hierarchie von kryptografischen Hashes erzeugt, einen Merkle Tree.

Die Transaktionen werden so sortiert, wie sie im Block liegen. Wenn die Anzahl Objekte ungerade ist, wird das letzte Objekt dupliziert und am Schluss angehängt. Dieses zusätzliche Objekt wird nicht zum Block hinzugenommen; es wir nur vorübergehend dupliziert zum Zwecke der Merkle Tree Berechnung.

Jedes Objekt (in diesem Falle Transaktionen) wird mit Doppel-SHA256 gehasht. Das resultiert in vier Hashwerten von je 256 Bits.

Die Hashwerte werden paarweise concateniert, zwei Hashes werden also verbunden, indem man den zweiten Hash an den Ersten hinten anhängt. Zum Beispiel ergibt abc concateniert mit def als Ergebnis abcdef.

Die vier Hashwerte sind jetzt zu zwei concatenierten Werten geworden. Weil zwei eine gerade Zahl ist, müssen wir kein zusätzliches Objekt ans Ende hängen. Die beiden concatenierten Werte werden separat voneinander gehasht, was zu zwei 256 Bit Hashes führt.

Diese zwei Hashwerte werden zu einem einzelnen 512 Bit Wert concateniert. Dieser Wert wird gehasht, was den 256 Bit Merkle Root liefert. Der Merkle Root wird in den Block Header geschrieben. Wenn eine Transaktion dazukommt, gelöscht oder geändert wird, muss der Merkle Root neu berechnet werden (Abbildung 133).

Das ist schön, denn wenn Lisa den Block Header signiert, weisst du, dass die Signatur ungültig wird, wenn jemand an den Transaktionen darin herumpfuscht.

Der Full Node möchte die Transaktionen Tx₂ und Tx₃ an Johns Wallet schicken, weil er glaubt, dass sie für Johns Wallet interessant sein könnten. Der Full Node möchte beweisen, dass sowohl Tx₂ als auch Tx₃ in dem Block enthalten sind. Aber fangen wir mit dem Beweis für eine einzelne Transaktion an, Tx₂. Wir schauen uns später im Kapitel ein grösseres, komplexeres Beispiel an.

Wie kann der Full Node dem Wallet beweisen, dass Tx₂ im Block enthalten ist? Es kann einen partiellen Merkle Tree liefern, der Tx₂ mit dem Merkle Root im Block Header verbindet. Die Idee dabei ist, das absolute Minimum an das Lightweight Wallet zu schicken–gerade genug, um zu verifizieren, dass Tx₂ wirklich im Block enthalten ist. In diesem Beispiel schickt der Node das Zeug aus Abbildung 134 an das Lightweight Wallet.

Das Lightweight Wallet benutzt dann diese Information zur Überprüfung, ob Tx₂ in dem Block vorkommt, indem es die Zwischen-Hashes in Richtung Root berechnet und verifiziert, dass der Hash von Tx₂ unter den Hashes ist, die der Full Node geschickt hat (Abbildung 135).

Die Hashfunktionen sind aus dem Diagramm entfernt worden, damit es leichter zu lesen ist. Das Wallet kann jetzt sicher sein, dass Tx₂ in dem Block enthalten ist.

Wir haben die Blockchain eingeführt, die das Spreadsheet auf Lisas Computer ersetzt (Tabelle 18). Dieses Kapitel hat auch ein neues Konzept speziell für das Cookie Token System eingeführt: den Share. Dieser geteilte Ordner wird in Kapitel 8 durch ein Peer-to-Peer Netzwerk von Full Node ersetzt.

Die Blockchain ist jetzt fast schon so wie bei Bitcoin, aber mit einem wichtigen Unterschied: Lisa signiert die Blocks mit digitalen Signaturen, wogegen sie in Bitcoin mit Proof of Work signiert werden.

Es ist mal wieder Zeit, eine neue Version des Cookie Token Systems freizugeben. Schaut euch die tollen neuen Features in Tabelle 19 an!

Angenommen, die aktuelle Blockhöhe ist 100. Tom und Qi haben gerade ihre Blocksignier-public Keys auf dem schwarzen Brett und im Firmen-Intranet veröffentlicht. Alle Wallets fangen an, die Transaktionen an alle drei Blockproduzenten, oder Miner, zu schicken. Abbildung 144 illustriert, was passiert.

Wenn alle das tun, was Lisa tat, produziert jeder einen Block alle 10 Minuten, was zu drei verschiedenen Blocks mit ungefähr denselben Transaktionen führt. Die grössten Unterschiede zwischen den Blocks finden sich in den Coinbase Transaktionen und den Signaturen. Die Coinbase von Toms Block würde die Blockbelohnung an Toms Cookie Token Adresse zahlen, wogegen die Coinbase von Lisas Block die Belohnung an Lisas Cookie Token Adresse zahlt.

Um dieses Problem zu vermeiden, müssen die Miner irgendwie entscheiden, wer von ihnen den nächsten Block produziert. Sie könnten sich reihum abwechseln, aber das wäre kompliziert, weil vielleicht Lisas Computer einmal kaputtgeht, oder aus irgendeinem Grund sich Tom mal weigert, einen Block zu produzieren. In solch einem Szenario würde das System steckenbleiben.

Probieren wir einen anderen naiven Ansatz (Abbildung 145). Jede Sekunde zieht jeder Miner eine Zufallszahl zwischen 0 und 999.999. Wenn ein Miner zufällig eine Zahl im Bereich 0 bis 555 zieht, darf er sofort den Block signieren und veröffentlichen. Die Wahrscheinlichkeit, einen Treffer bei einem einzelnen Versuch zu landen, ist gering–556/1.000.000, oder grob 1 in 1.800 Versuchen. Die Miner ziehen sekündlich eine Zahl, also kann man für jeden Miner durchschnittlich einen Treffer in 30 Minuten (1.800 Sekunden) erwarten. Die drei Miner zusammen produzieren dann im Schnitt 1 Block alle 10 Minuten.

Wenn ein Miner einen Treffer zieht, ist die Chance gering, dass einer der anderen Miner gleichzeitig ebenfalls eine Glückszahl gezogen hat, Das bedeutet, normalerweise wird nur ein Miner den nächsten Block produzieren.

Die Miner speichern ihre Blocks als <_last-8-hexdigits-of-blockid_>.dat im Share, sodass mehrfache Block-IDs auf derselben Höhe sich nicht um Dateinamen sorgen müssen. Ein Beispiel für einen Dateinamen ist 9ce35c25.dat.

Dieses System klappt ganz gut, aber ab und zu ziehen zwei Miner gleichzeitig ein Glückslos. Sie wissen nichts davon, dass jemand anders auch einen Treffer gezogen hat, also produzieren beide einen Block auf derselben Höhe. Diese Situation kennt man als Blockchain Aufspaltung, oder Blockchain Split, weil sich die Blockchain in zwei Zweige aufspaltet. Beide Zweige sind genauso gültig, also welcher ist “korrekt”? Welcher Miner “gewinnt” den Block und bekommt die 50 CT Blockbelohnung?

Wir kennen den Gewinner noch nicht. Es kommt auf die Miner an, zu entscheiden, welchen Ast sie mit ihren eigenen Blocks verlängern wollen. In Abbildung 145 haben sowohl Tom als auch Qi einen Block auf Höhe 106 produziert. Die verschiedenen Miner denken sich wahrscheinlich folgendes:

Wenn sich die Miner den Block auf Höhe 106 ausgesucht haben, den sie verlängern wollen, bauen sie einen neuen Block auf Höhe 107 und fangen wieder an, Zahlen zu ziehen. Aus dieser Situation können sich mehrere Resultate ergeben, vorausgesetzt, alle sind ehrlich: sofortige Lösung, verzögerte Lösung, und ein Split eines Splits.

Irgendwann wird ein Zweig in einem Split gewinnen. Die Wahrscheinlichkeit, dass zwei Zweige der Länge X als nächstes passieren sinkt rapide für steigende X:

Dass ein Split von Länge 1 passiert, ist relativ wahrscheinlich, aber ein Split von Länge 2 passiert wahrscheinlich nicht mehr, solange Lisa lebt (sie ist 45). Egal wie lang Splits sind, irgendwann lösen sie sich mit einem Gewinner auf. Das sieht noch einem netten Verfahren aus. Aber es hat Probleme:

Offensichtlich kann dieses System die Anzahl Miner nicht über eine kontrollierte Gruppe von vertrauenswürdigen Teilnehmern hinaus erweitern. Man würde mit Blocks geflutet werden, wenn Miner anfangen zu mogeln, aber man könnte ihnen nicht nachweisen, dass sie mogeln. Es kann ja immer sein, dass sie einfach unheimlich viel Glück haben.

Um einen neuen Block zu erzeugen, muss ein Miner ein gültigen Proof of Work für den Block produzieren, bevor der Block als gültig durchgeht. Um einen gültigen Proof of Work zu schaffen, muss der Miner einen Block Header Hash erzeugen, der kleiner oder gleich dem Target im Block Header ist.

Eine Block-ID ist ein Doppel-SHA256 des Block Headers. Wie wir in Kapitel 2 gelernt haben, besteht der einzige Weg, ein Pre-Image für einen kryptografischen Hash zu finden darin, immer wieder verschiedene Inputs durchzuprobieren, bis man ein passendes findet. Hier gilt dasselbe; der Miner muss verschiedene Block Header ausprobieren, bis er einen findet, der zu einem Hashwert führt, der kleiner oder gleich dem Target ist.

Springen wir mal in der Zeit zurück und schauen, wie Qi ihren Block erzeugt hat. Sie erzeugt den Block, setzt das Target auf 00000000926e…, und setzt die Nonce auf 0. Dann prüft sie, ob der Proof of Work gültig ist (Abbildung 153).

Sie berechnet die Block-ID, indem sie ihren Block Header mit Doppel-SHA256 hasht. In diesem Fall ist die Block-ID aa9c614e7f50…. Diese Zahl ist grösser als das Target.

Die Regel besagt, dass die Block-ID kleiner oder gleich dem Target sein muss, damit der Proof of Work gültig ist. Qi scheitert kläglich.

Hier kommt die Nonce ins Spiel. Eine Nonce ist einfach eine alberne Zahl, die nichts bedeutet. Sie kann auf jeden beliebigen Wert gesetzt werden. Qi setzt sie anfangs auf 0, aber sie könnte sie genausogut auf 123 oder 92178237` setzen. Die Nonce hilft, den Block Header abzuwandeln, ohne irgendwelche echten Daten zu ändern, wie Transaktionen oder Vorgänger Block-ID.

Qi probiert jetzt wieder, einen gültigen Proof of Work zu erzeugen. Sie erhöht die Nonce von 0 auf 1 und prüft die Gültigkeit erneut (Abbildung 154).

Wenn Qi den Block Header durch Variieren der Nonce ändert, ändert sich die Block-ID–jede kleinste Änderung im Header führt zu einer völlig anderen Block-ID. Das ist dieselbe Eigenschaft, die in Abschnitt 2.2 in Kapitel 2 dargestellt wurde, als wir das Katzenbild geändert haben (Abbildung 155).

Die neue Block ID ist 863c9bea5fd8… Auch sie ist grösser als das Target. Qi scheitert erneut. Es tut mir leid, aber es führt kein Weg daran vorbei–Qi muss es erneut probieren. Sie erhöht die Nonce von 1 auf 2 und testet erneut (Abbildung 156).

Das Resultat ist dasselbe: ein jämmerlicher Fehlschlag. Die Block ID war diesmal 005ce22db5aa…, was immer noch grösser ist als das Target.

Sie wiederholt dies immer und immer wieder Zum Beispiel zeigt Abbildung 157 ihren 227.299.125ten Versuch.Es war knapp, aber knapp reicht nicht. Sie muss weiter probieren (Abbildung 158). Und schliesslich erhält sie das in Abbildung 159 dargestellte Ergebnis.

Die Nonce 492781982 resultiert in der Block ID 000000003c77…. Sie vergleicht dies mit dem Target:

Wow–diese Block ID ist kleiner als das Target! Qi hat einen Haufen Arbeit geleistet, um eine Nonce zu finden, die in einer Block ID kleiner als das Target resultiert. Sie hat einen Block mit einem gültigen Proof of Work erzeugt. Toll, jetzt wird sie ihren Block im Share veröffentlichen.

Es ist wichtig, sich darüber klar zu sein, dass Miner ihre eigenen Blocks individuell zusammensetzen. Tom arbeitet zum Beispiel an seinem eigenen Block gleichzeitig mir Qi (und Lisa), aber seine Menge der Transaktionen ist anders als Qis, weil seine Coinbase Transaktion die Blockbelohnung an ihn zahlt, während Qis Coinbase Transaktion die Blockbelohnung Qi zukommen lässt. Dieser Unterschied sorgt dafür, dass der Merkle Root in ihren jeweiligen Block Headern sich unterscheidet. Wenn Tom Qis gewinnende Nonce, 492781982, in seinen eigenen Block einbaut, wird er das Target vermutlich nicht erreichen. Andere Dinge, die sich wahrscheinlich unterscheiden, sind der Zeitstempel und die Liste der ausgewählten Transaktionen.

Jeder kann einen Block aus dem Share nehmen und prüfen, dass die Regeln eingehalten wurden–die Block ID ist kleiner oder gleich dem vereinbarten Target. Block Verifizierung ist jetzt ein wenig anders als vorher (Abbildung 160).

Der Unterschied zum Verifizieren eines digital signierten Blocks ist, dass der Full Node prüft, ob der Blockproduzent einen gültigen Proof of Work geliefert hat, anstatt einer digitalen Signatur.

Die Blockchain wird weiter so wachsen wie bisher, aber das Ziehen der Gewinnzahlen wird ersetzt durch das Hashen der Block Header (Abbildung 161). Tabelle 20 vergleicht die beiden Systeme.

Anstatt jede Sekunde eine Zufallszahl zu ziehen, ziehen die Miner etwa alle 0,02 Mikrosekunden eine Zahl durch einen kryptografischen Hash. Gleichzeitig wird die Grenze für die Glückszahl von 555 auf die 256 Bit Zahl 00000000926e…=926eb9*2²⁰⁰ angehoben.

Subtiler aber wichtiger Unterschied ist, dass bei Proof of Work die Chain mit dem grössten gesammelten Proof of Work als die beste Chain gilt, der man folgen soll. Im Fall der Glückszahlen folgen Nodes der längsten Chain. Der gesammelte Proof of Work für eine Blockchain ist die Summe der Schwierigkeit aller Einzelblocks der Chain.

Die Schwierigkeit oder Difficulty eines Blocks wird darin gemessen, wie viel schwieriger es ist, einen gültigen Proof of Work für diesen Block zu finden im Vergleich damit, einen für den Genesis Block zu finden.

Genauer gesagt wird die Difficulty von Block B wie folgt berechnet:

Das Target des Genesis Blocks wird durch das Target von B geteilt, was die Difficulty des Genesis Blocks zu genau 1 macht.

Das Wesentliche daran ist, dass je höher das Target eines Blocks ist, desto niedriger seine Difficulty ist, und je niedriger das Target, desto höher die Difficulty. Also summieren wir die Difficulties aller Blocks auf, und erhalten den gesammelten Proof of Work.

Von nun an werde ich den Zweig mit dem grössten gesammelten Proof of Work als den stärksten Zweig oder die stärkste Chain bezeichnen. Ein anderer gebräuchlicher Begriff ist beste Chain. Die Unterscheidung zwischen längster und stärkster Chain wird in Abschnitt 7.5.2 wichtig, wenn ich Anpassungen der Schwierigkeit, oder Difficulty Adjustments, vorgestellt haben werde.

Die Nonce ist eine 32 Bit Zahl. Das ist ziemlich klein. Wenn ein Miner alle 4.294.967.296 möglichen Zahlen erfolglos durchprobiert hat, muss er etwas anderes tun, um den Block Header zu ändern. Ansonsten würde er genau dieselben Versuche nochmal machen, die er schon probiert hat. Es gibt verschiedene Optionen für solche Änderungen (Abbildung 162):

Den Zeitstempel zu ändern ist recht geradlinig–addiere einfach eine Sekunde auf den Zeitstempel und der Header sieht anders aus. Wenn man eine der anderen Optionen benutzt, wird man den Merkle Root neu berechnen müssen, weil die Transaktionsdaten geändert wurden. Wenn der Merkle Root sich ändert, ändert sich auch der Header.

Führt man irgendeine dieser Änderungen am Block durch, so ändert sich der Header, sodass die Nonce wieder bei 0 anfangen und der Miner wieder mit dem Hashen beginnen kann.

Ein interessanter Aspekt dieses Systems ist, dass jeder ein Miner werden kann, ohne um Erlaubnis zu fragen. Jeder kann einfach einen Computer daheim aufstellen und anfangen, Blocks zu bauen. Blocks sind nicht mehr an eine Person gebunden, sondern an eine Menge an Computerleistung:

Nach Lisas und Rashids zusätzlichen Hashrate hat sich die gesamte Hashrate im Cookie Token System deutlich erhöht:

Sieh mal: wir produzieren mehr Blocks pro Tag als geplant! Das Ziel ist 144 Blocks pro Tag, und 264 ist erheblich mehr als das. Die Block Rate ist zu hoch, fast das Doppelte des gewünschten Wertes.

Eine höhere Blockrate mag vorteilhaft erscheinen, weil mit ihr die Bestätigungszeit für Transaktionen sinkt, birgt aber einige Probleme.

Wir haben auf eine interessante Weise das schwierige Problem gelöst, “ehrliche Glückszahlen” zu erzwingen . Lasst uns mal schauen, welche Probleme aus Abschnitt 7.1.3 verbleiben:

Es verbleibt nur noch ein Problem in der Liste. Das werden wir im nächsten Abschnitt ändern.

Der Block Header enthält einen Timestamp. Timestamps sind wichtig, weil das System das Target automatisch, ohne menschlichen Eingriff, so kalibrieren soll, dass alle 10 Minuten 1 Block produziert wird. Die Blockerzeugungsrate ist wichtig, weil wir eine vorhersehbare Ausgabegeschwindigkeit neuer Cookie Tokens haben wollen.

Der Miner, der einen Block erzeugt, setzt den Timestamp auf die aktuelle Zeit, bevor er einen Proof of Work produziert. Weil aber verschiedene Full Nodes auf unterschiedlichen Computern laufen, sind deren Uhren nicht unbedingt vollständig synchron.

Angenommen Lisa produziert einen Block mit Timestamp 2017-08-13 07:33:21 UTC und veröffentlicht ihn auf dem Share. Tom produziert den nächsten Block, aber seine Uhr hinkt hinter Lisas Uhr hinterher.

Tom produziert einen Block mit einem früheren Timestamp als der vorherige Block. Das ist kein Problem, solange die Timestamps sich nicht zu sehr unterscheiden (Abbildung 164).