Bitcoin begreifen

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 3 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 4). 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 4 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 [ch02] 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 12).

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 13).

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 [cryptographic_hashing] in [ch02] dargestellt wurde, als wir das Katzenbild geändert haben (Abbildung 14).

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 15).

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 16 ihren 227.299.125ten Versuch.Es war knapp, aber knapp reicht nicht. Sie muss weiter probieren (Abbildung 17). Und schliesslich erhält sie das in Abbildung 18 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 19).

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 20). Tabelle 1 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 21):

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 23).

Der Timestamp muss ein paar Regeln folgen. Angenommen der Full Node des Cafés ist dabei, Toms Block zu verifizieren:

Diese Regeln garantieren, dass niemand die Timestamps seiner Blocks manipuliert, um die nächste Target Berechnung zu beeinflussen. Stell dir vor, der letzte Block vor einem Retarget hätte einen Timestamp sechs Wochen in der Zukunft. Das würde dazu führen, dass das nächste Target um den Faktor 4 erhöht wird, wie Tabelle 2 zeigt.

Der letzte Timestamp ist sechs Wochen später als die Zeit, zu der der Block tatsächlich erzeugt wurde. Alle Full Nodes werden den Block zurückweisen, weil er die Timestamp Regeln verletzt. Jemand will das Target manipulieren. Würde dieser Block akzeptiert werden, wäre das nächste Target viermal so gross wie das jetzige, womit das Finden eines Proof of Work viermal so leicht wäre. Diese Art von Fehlverhalten wird wie beschrieben durch die Timestamp Regeln verhindert. Dadurch, dass man mit dem Timestamp nicht um mehr als zwei Stunden schummeln kann, kann das nächste Target höchstens marginal manipuliert werden.

Kommen wir zurück zu der Diskussion über Chain Stärke und darüber, weshalb es wichtig ist, nicht einfach auf die Länge der Chain zu schauen. Es ist intuitiv plausibel, dass je schwerer die Chain Historie zu ändern ist, desto besser, sodass man der stärksten Chain folgen sollte. Aber wann unterscheiden sich die stärkste und die längste Chain voneinander?

Sie können sich aus verschiedenen Gründen unterscheiden:

Wir betrachten hier nur die erste Option. Angenommen ein natürlicher Split passiert (Abbildung 24).

Es ist ein unwahrscheinliches Szenario, aber wir müssen es betrachten, weil es passieren kann. Ein Split geschieht direkt vor einem Retarget, und die Timestamps der 2 Blocks unterscheiden sich um vier Stunden. Als nächstes werden gleichzeitig 2 neue Blocks produziert, einer auf jedem Zweig. Diese Blocks wurden auf Basis ihrer unterschiedlichen Historien mit neuen Targets versehen. Die letzten Timestamps in den jeweiligen Retarget Perioden unterscheiden sich um vier Stunden, was zu Unterschieden in den neuen Targets führt. Erinnern wir uns an die Retarget Formel:

Weil die neuen Targets sich unterscheiden ist die neue Difficulty im letzten Block jedes Zweiges verschieden. Das bedeutet, die Chain Stärke unterscheidet sich, weil die beiden Zweige nun einen unterschiedlichen akkumulierten Proof of Work haben.

Angenommen Lisa ist gerade dabei, einen Keks im Cafe zu bezahlen. Aber gleichzeitig mit der Zahlung bereitet sie auch eine Double-Spend Transaktion vor (Abbildung 25).

C ist die Transaktion zum Café. L ist Lisas Double-Spend Transaktion, die sie benutzen wird, um ihr Geld zurück zu stehlen. Beide Transaktionen sind für sich gesehen vollkommen gültig, aber beide können nicht gleichzeitig gültig sein, weil beide den gleichen Output ausgeben. Ein Output kann nur einmal ausgegeben werden.

List schickt die ehrliche Zahlung, C, an alle Miner. Während die anderen Miner versuchen, ihre ehrliche Transaktion in einen Block zu stecken und einen gültigen Proof of Work zu berechnen, tut Lisa die Double-Spend Transaktion in einen eigenen, geheimen Block und fängt an, auf diesem zu arbeiten (Abbildung 26).

Lisas Ziel ist, einen gültigen Proof of Work für ihren betrügerischen Zweig mit L zu finden, der grösser ist als der Proof of Work der ehrlichen Chain. Wenn sie das geschafft hat, wird sie alle Blocks in ihrem Zweig veröffentlichen und alle Miner werden auf ihren Zweig umschwenken und beginnen, ihren Zweig zu verlängern statt den bisherigen. Der Einfachheit halber nehmen wir an, dass all dies ohne Retargets (Difficulty Adjustments) geschieht; wir sind mitten in einer Retarget Periode. Das bedeutet, alle Blocks haben dasselbe Target (bzw. dieselbe Difficulty), sodass wir einfach die Zweiglänge betrachten anstatt der Zweigstärke (den akkumulierten Proof of Work).

Eine Gruppe Miner versuchen, Lisas ehrliche Transaktion C zu bestätigen, während Lisa am Proof of Work für ihren Block mit der Double-Spend Transaktion L arbeitet. Das Café wartet auf eine gültige Transaktion, bevor es den Keks herausgibt.

Irgendwann wird die ehrliche Transaktion auf der ehrlichen Chain bestätigt. Das Café sieht den Block, verifiziert ihn und gibt Lisa den Keks. Lisa isst ihn auf. Während sie die letzten Krümel herunterschluckt, findet ihr Computer zufällig einen gültigen Proof of Work für ihren Block. Sie veröffentlicht ihren Block noch nicht, weil ihr das nichts nützen würde. Die Miner sind auf der ehrlichen Chain bereits am weiterarbeiten, weil sie dort zuerst einen Block gesehen haben.

Die kombinierte Hashrate aller Miner auf der ehrlichen Chain ist 350 MHash/s, wogegen Lisa nur 200 MHash/s besitzt. Das bedeutet, die ehrliche Chain sollte Blocks häufiger finden als Lisa.

Aber jeder hat einmal Glück. Lisa hat glücklicherweise den Proof of Work für einen weiteren Block in ihrem betrügerischen Zweig gefunden. Jetzt hat sie 2 Blocks auf ihrem Zweig, wogegen der ehrliche Zweig nur 1 Block lang ist. Lisa hat mehr gesamten Proof of Work auf ihrer Chain als die ehrlichen Miner auf deren Zweig. Lisa veröffentlicht die 2 Blocks auf dem Share.

Andere Miner werden diese 2 Blocks sehen, und dass Lisas Zweig mehr Proof of Work als der ehrliche Zweig hat, und werden auf Lisas Zweig herüber schwenken. Die Miner, die schwenken, können nicht sehen, dass ein Betrug stattfand, oder wer den Block erzeugt hat; sie springen neutral auf die längste gültige Chain.

Das Resultat ist, dass Transaktion C an das Café effektiv annulliert wurde. Sie gehört nicht mehr zu der Chain mit dem meisten Proof of Work. Das Café hat die 10 CT verloren, die es glaubte bekommen zu haben, als es Lisa einen Keks gab.

Von diesem Punkt an werden neue Blocks Lisas Zweig verlängern und die Dinge werden normal weiterlaufen. Der Block mit Transaktion C wird verfallen.

Obwohl die Chancen gegen Lisa stehen, könnte sie Glück haben und mit einer Double-Spend Attacke erfolgreich sein, wie in dem vorigen Beispiel. Einen Double-Spend von 10 CT durchzuziehen ist aus Lisas Sicht ökonomisch nicht plausibel. Sie riskiert, enorme Mengen Energie zu verbrauchen und ihren eigenen Block verfallen zu sehen, falls es nicht klappt. Sie würde die Blockbelohnung aus diesen verfallenen Blocks verlieren.

Aber was, wenn sie versucht, einen grösseren Betrag als 10 CT doppelt auszugeben, sagen wir 100.000 CT? Dann wäre es für Lisa die Sache wert, einen Double-Spend zu versuchen. Stell dir vor, sie würde das ganze Café kaufen und dabei eine Double-Spend Attacke abziehen. Dann würde sie das Café besitzen und hätte immer noch ihre 100.000 CT.

Der Cafébesitzer ist gewillt, Lisa das Café für 100.000 CT zu verkaufen. Aber das Café weiss natürlich um die Gefahr einer Double-Spend Attacke. Also sagt der Cafébesitzer, dass er bei so viel Geld Lisa das Café erst nach sechs Bestätigungen überschreiben wird.

Was bedeutet dies? Lisa muss dem Cafébesitzer 100.000 CT bezahlen und dann warten, bis die Transaktion in einem Block bestätigt wird und 5 weitere Blocks auf diesem Block aufbauend produziert worden sind. Erst dann wird der Besitzer das Café an Lisa übergeben.

Um eine Double-Spend Attacke durchzuziehen, muss Lisa insgeheim einen alternativen Zweig aufbauen, genau wie in ihrer vorherigen Attacke, während das Café sechs Bestätigungen abwartet. Wenn der Cafébesitzer sechs Bestätigungen gesehen und Lisa das Café übergeben hat, muss sie irgendwann einen stärkeren Double-Spend Zweig in den Share hochladen. Das bedeutet, Lisa muss eine längere Zeit Glück haben als im vorangegangenen Beispiel.

Schauen wir mal, wie es läuft (Abbildung 27).

Der Ausgang ist der Erwartete. Lisa konnte auf die Dauer nicht mehr Blocks als die ehrliche Chain produzieren. Sie hat bei 7–4 aufgegeben.

Die folgende Tabelle zeigt die Abfolge der Ereignisse in diesem Beispiel:

Lisa gibt aus verschiedenen Gründen auf:

Das Entscheidende ist hier, dass das Café sechs Confirmations verlangt hatte. Je mehr Confirmations verlangt werden, desto schwieriger ist es für Lisa, einen stärkeren Zweig als die ehrlichen Miner zu bauen. Sie bräuchte mehr Glück.

Als das Café seine sechs Confirmations bekommen hatte, lag Lisa 2 Blocks zurück. Sie hätte schneller als die ehrliche Chain wachsen und 1 Block länger als die ehrliche Chain werden müssen. Ihre Chancen waren gering. Je mehr Blocks sie aufholen musste, desto geringer wurden die Chancen, wie Tabelle 3 zeigt.

Die Wahrscheinlichkeit \(q_z\) ergibt sich aus

Schauen wir in die Spalte für die 36% Hashrate, die Lisa hat. Wenn sie 3 Blocks zurück liegt, muss sie in der nächsten Zeit 4 Blocks mehr als die ehrlichen Miner produzieren. Damit hat sie eine 0,10 Chance, mit diesem Double-Spend jemals durchzukommen–sofern sie bereit ist, die Attacke unbegrenzt fortzuführen. Sie wird aber wahrscheinlich nicht ewig weiter probieren, was ihre Aussichten auf Erfolg weiter schmälert.

Angenommen, Lisa und Tom finden gleichzeitig einen gültigen Proof of Work für ihren jeweiligen Block. Lisas Block ist 200 KB gross und enthält 400 Transaktionen, wohingegen Toms Block 100 KB gross ist und 200 Transaktionen enthält. Beide wollen, dass ihr Block Teil der stärksten Chain wird, aber nur einem der beiden kann das gelingen. Sie beginnen genau gleichzeitig damit, ihre jeweiligen Blocks in den Share hochzuladen (Abbildung 31).

Toms Block ist kleiner als Lisas. Das bedeutet, Tom wird seinen Block schneller in den Share hochladen als Lisa ihren. Es ist auch schneller für Qi, Toms Block herunterzuladen als Lisas. Und schliesslich muss Qi die Blocks, die sie herunterlädt, verifizieren, bevor sie darauf aufbaut. Ein kleiner Block ist typischerweise schneller zu verifizieren als ein grosser, sodass auch hier Toms Block schneller ist als Lisas.

Das Ergebnis ist, dass Qi zur Zeit T Toms Block als aktuell beste Chain Tip auswählt und beginnt, auf Basis von Toms Block zu minen. Lisas Block existiert für Qi zum Zeitpunkt T eigentlich gar nicht, weil sie ihn noch nicht verifiziert hat. Sie lädt Lisas Block immer noch vom Share herunter. Wenn Qi zum Zeitpunkt L endlich Lisas Block verifiziert, hat sie bereits entschieden, Toms Block zu benutzen und Lisas Block wird für den Fall einer späteren Chain Reorganisation abgespeichert.

Miner haben einen klaren Anreiz, ihre Blocks klein zu halten. Für jede zusätzliche Transaktion, die sie zu ihren Blocks hinzunehmen, verlieren sie ein wenig an Wettbewerbsfähigkeit im Block Rennen.

Hier kommen die Transaktionsgebühren ins Spiel. Wenn die Miner ein bisschen extra Geld für jede Transaktion bekommen, die sie in den Block mit hineinnehmen, würden sie dadurch für den Verlust an Wettbewerbsfähigkeit entschädigt werden.

Zahlende Kunden möchten ihre Transaktionen gern in der Blockchain bestätigt bekommen. Wäre es nicht schön, wenn John ein bisschen Geld in der Transaktion hinterlegen würde für den Miner, der sie einbaut? Auf diese Weise könnte der Zahlende den Miner für den Verlust an Wettbewerbsfähigkeit entschädigen.

Wenn wir die Transaktionen ein bisschen anders verwenden, können wir diese Eigenschaft anbieten. Sagen wir mal, John will einen Keks kaufen. Um den Minern einen Anreiz zu geben, seine Transaktion einzubetten, fügt er eine Transaktionsgebühr hinzu. Er konstruiert seine Transaktion wie in Abbildung 32 dargestellt.

Als John eine ähnliche Transaktion in [ch05] erzeugt hat, war die Summe der Inputs gleich der Summe der Outputs. Er hatte keine Transaktionsgebühr bezahlt.

Diesmal will John eine kleine Transaktionsgebühr zu seiner Transaktion hinzunehmen. Er gibt zwei Inputs im Wert von zusammen 13 CT aus, und fügt der Transaktion einen Output von 10 CT an das Café und einen Change Output von 2,5 CT an sich selbst hinzu. Dann signiert er die Transaktion ganz wie gewohnt und schickt sie an alle Miner.

Lisa, die Minerin, erhält die Transaktion von John. Sie bemerkt, dass eine Transaction Fee von 0,5 CT darin ist. Sie möchte diese Fee haben und beschliesst, dass diese Gebühr sie mehr als genug für den winzigen Verlust an Wettbewerbsfähigkeit im Blockrennen entschädigt, der durch die Vergrösserung ihres Blockes um diese Transaktion entsteht.

Wir sprechen mehr über Fees und darüber, wie man die Gebühr einer Transaktion ändern kann, wenn sie im Zustand ausstehend, oder pending, hängen bleibt–das wird auch als fee bumping bezeichnet—in [ch09].

Das einzige, was Lisa interessiert, wenn sie entscheidet, ob sie eine Transaktion in den aktuellen Block mit hineinnehmen soll, ist die Grösse der Transaktion und die Fee, die sie ihr zahlt. Im Grunde ist es die Fee pro Byte, die sie interessiert. Johns Transaktion ist etwa 400 Bytes gross und bezahlt eine Gebühr von 0,5 CT. Das sind 0,00125 CT/Byte. Das ist für Lisa einfach zu rechnen, und sie tut dasselbe mit allen Transaktionen. Wenn die Fee pro Byte oberhalb eines gewissen Schwellwerts liegt, nimmt sie die Transaktion in den Block mit hinein.

Sie kann sich auf beliebigem Wege die Transaktionen heraussuchen, wie in [transaction-selection] beschrieben. Zum Beispiel kann sie ihre eigene Transaktion ohne Fee mit dazu nehmen, oder sie kann alle Transaktionen ausschliessen, mit denen Kekse bezahlt werden, egal wie hoch die Fee auch sein mag. Andere Miner werden andere Strategien für die Transaktionsauswahl benutzen. Die meisten werden wohl auf Basis der Fee pro Byte entscheiden.

Wie bekommt Lisa die Fee? Indem sie ihre Coinbase Transaktion benutzt (Abbildung 33).

Lisa summiert alle Gebühren von allen Transaktionen in ihrem Block auf und erhöht den Coinbase Output um diesen Betrag. Der Betrag in diesem Coinbase Output–der Block Reward–ist die Summe aus der Block Subvention, also die 50 neuen Cookie Tokens, die dieser Block erzeugt, und allen Transaction Fees der Transaktionen in diesem Block. Merke, dass wir den Begriff Block Reward so erweitert haben, dass er sowohl die Block Subvention (das neu geschaffene Geld) als auch die Transaction Fees enthält.

Wenn der Block korrekt vorbereitet ist, beginnt Lisa damit, einen gültigen Proof of Work für den Block zu suchen.

Blocks dürfen nicht beliebig gross werden. Einfach gesagt ist die maximale Blockgrösse 1.000.000 Bytes, aber wir diskutieren die Feinheiten in [block-size-limit]. Wenn mehr Transaktionen auf Bestätigung warten als Blockplatz, oder Block Space, verfügbar ist, müssen die Miner aussuchen, welche Transaktionen sie in einen Block hereinnehmen und welche sie aussen vor lassen.

Die Transaktionsgebühr spielt hierbei eine wichtige Rolle, weil eine höhere Transaktionsgebühr den Minern mehr Anreiz gibt, diese Transaktion gegenüber anderen bevorzugt in den Block zu integrieren. Die Gebühr dient, zusätzlich zu seiner Funktion als Kompensation für verringerte Wettbewerbsfähigkeit, auch zum Wettbewerb mit den anderen Transaktionen um den Blockplatz. Diese Situation wird als Gebührenmarkt oder Fee Market (Abbildung 34). bezeichnet.

Steht mehr Block Space zur Verfügung, als Transaktionsdaten auf Bestätigung warten, konkurrieren Transaktionen nicht im gleichen Sinne miteinander (Abbildung 35).

In dieser Situation wird jede Transaktion bestätigt, die die Kosten für verlorene Wettbewerbsfähigkeit zahlt.

Wie wir in [ch02] besprochen haben, halbiert sich die Block Subvention ungefähr alle vier Jahre. Irgendwann wird die Blocksubvention allein nicht mehr ausreichen, um den Minern einen Anreiz zum Minen zu geben. Wenn der Wert des Block Rewards unter der Stromrechnung liegt, wozu soll man dann minen?

Transaction Fees werden mit abnehmender Blocksubvention eine immer grössere Rolle spielen. Der typische Miner will, dass seine Einkünfte vom Minen mindestens die Stromkosten abdeckt (Abbildung 36).

Beachte, dass der Wert der Blocksubvention im Laufe der Zeit nicht unbedingt abnehmen muss. Tabelle 4 zeigt ein paar Beispiele.

Dies zeigt, dass die Blocksubvention allein kein Mass des Mining Einkommens darstellt. Wir müssen den Wert der Blocksubvention und den Wert der Transaktionsgebühren betrachten. Eines ist sicher: Wenn die Subvention auf Null fällt, ist der Wert der Subvention auch Null. An irgendeinem Punkt wird die Bocksubvention nicht mehr genug Ansporn sein, zu minen.

Wenn das passiert, werden die Transaction Fees den effizienten Minern helfen, Umsatz zu machen. Wenn John seine Transaktion bestätigt haben will, muss er eine Gebühr zahlen, die hoch genug ausfällt, dass einer oder mehrere Miner sie in ihren Block aufnehmen. Das ist ein Markt für Blockplatz in Aktion.

Wir können über die zukünftigen Gebührenhöhen nur spekulieren. Manche argumentieren, dass die Gebühren von Bitcoin bereits zu hoch sind für die Art und Weise, wie sie es benutzen wollen. Wenn Transaction Fees steigen, dann werden einige Anwendungsfälle für Bitcoin–zum Beispiel Zahlungen von Kleinbeträgen–andere Wege finden müssen, um zu funktionieren. Derzeit werden auf Basis von Bitcoin neue Systeme entwickelt, die es ermöglichen, nahezu unbegrenzte Mengen von Zahlungen zu nur ein oder zwei Transaktionen zusammenzufassen. Ein solches System, Lightning Network, ist besonders interessant. Wenn mit einer einzigen Bitcoin Transaktion eine Million Zahlungen abgewickelt werden können, dann teilen sich alle Transaktionen die Kosten für die Transaktionsgebühr.

Proof of Work ersetzt die Block Signaturen, die wir in [ch06] eingeführt hatten, und wir können diese aus der Konzept-Mapping-Tabelle entfernen (Tabelle 5).

Lisa erledigt exakt dieselben Arbeiten wie ein Bitcoin Miner, weshalb wir Lisa ebenfalls aus der Tabelle entfernt haben. Der Shared Folder wird das letzte Stück vom Cookie Token System sein, dessen wir uns annehmen. Das kommt im nächsten Kapitel.

Es ist Zeit, eine schillernde neue Version des Cookie Token Systems vorzustellen (Tabelle 6).