Bitcoin begreifen

Lisa leistet wertvolle Arbeit. Sie sorgt dafür, dass niemand betrügt, indem sie digitale Signaturen überprüft und nach den Guthaben von public Key Hashes (PKH) schaut, bevor sie eine Zahlung bestätigt. Sie bestätigt die Zahlungen, indem sie sie an das Cookie Token Spreadsheet anhängt.

Aber dieser Ansatz führt zu einigen Problemen:

Bedenke, dass Lisa kein neues Geld über die vereinbarten 7.200 CT pro Tag hinaus erzeugen kann. Und wenn sie mehr stiehlt als das, was auf einem PKH verfügbar ist, wird jemand beim Verifizieren des Spreadsheets feststellen, dass die Geldmenge zu gross geworden ist. Dann würde Lisa auffliegen.

Lisa gefällt es überhaupt nicht. dass ihr Leute misstrauen. Ihr ist klar, dass sie nicht viel daran ändern kann, um das Vertrauensniveau ihrer Kollegen zu erhöhen. Eine interessante Alternative ist, das notwendige Vertrauen zu minimieren. Sie beschliesst, dass der beste Weg dazu ist, den Prozess möglichst transparent zu gestalten, sodass jeder die Zahlungen verifizieren kann. Gleichzeitig wird sie das Verfahren verbessern, mit dem sie sicherstellt, dass Leute kein Geld ausgeben, das sie nicht haben, und wie man von mehreren Adressen gleichzeitig Geld ausgeben kann. Sie erfindet die Cookie Token Transaktion, um alle drei Probleme gleichzeitig zu lösen.

Transaktionen ändern sowohl die Art, wie Wallets Zahlungen an Lisa schicken, als auch das, was im Spreadsheet gespeichert wird. Sie ändern nicht, wie Wallets aus Benutzersicht funktionieren–die Wallet App wird unverändert aussehen.

Angenommen John will ein Keks im Café kaufen. Er mailt jetzt nicht mehr Lisa eine Zahlung, wie er es früher so oft gemacht hatte. Die Wallet Software benutzt jetzt Transaktionen, also wird sein Wallet stattdessen eine Transaktion erzeugen, wie in Abbildung 3 gezeigt. Der Zweck der Transaktion ist, 10 CT an die Cookie Token Adresse des Cafés zu senden.

John scannt die Zahlungs-URI des Cafés, und sein Wallet erzeugt eine Transaktion und bittet ihn, sie zu akzeptieren. Er klickt OK, und das Wallet signiert die Transaktion. Johns Wallet schickt dann die Transaktion als Attachment in einer anderweitig leeren Mail an Lisa.

Die Transaktion enthält Informationen darüber, wo das Geld hin soll. Aber auch darüber, welches Geld ausgegeben werden soll, indem es spezifische “Coins” namens unspent transaction outputs, unverbrauchte Transaktions Outputs (UTXOs), nennt, die John in früheren Transaktionen erhalten hatte.

Lisa verifiziert, dass die Coins, die in der Transaktion ausgegeben werden sollen, existieren und noch nicht anderweitig verbraucht worden sind. Sie überprüft auch, dass die Signaturen–es könnten mehrere in einer Transaktion sein–gültig sind. Wenn alle Prüfungen erfolgreich verlaufen sind, bestätigt Lisa die Transaktion, indem sie sie unverändert an das Ende des Spreadsheets hängt.

Wenn die Transaktion im Spreadsheet landet, kann jeder dieselben Überprüfungen daran vornehmen, wie Lisa dies tat. Sie können damit sicherstellen, dass Lisa kein Geld von jemandem stiehlt oder anderweitig mit anderer Leute Geld Schindluder treibt.

In den nächsten drei Abschnitten gehen wir näher auf die drei Phasen ein: Erzeugen, Bestätigen und Verifizieren.

Ich war nicht ganz ehrlich mit dem, was in einer Transaktion enthalten ist. Ein Transaktions-Output enthält keinen PKH, sondern einen Teil eines Computerprogramms, das den PKH enthält. Dieser Teil des Programms wird als Pubkey Script bezeichnet. Der Input, der den Output ausgibt, enthält den anderen Teil dieses Programmes. Dieser andere Teil, die Signatur und der public Key in Johns Transaktion, heisst das Signature Script (Abbildung 11).

Dieses winzige Programm, in einer Programmiersprache namens Script geschrieben, enthält die Befehle für Lisa dazu, wie sie verifizieren kann, dass die ausgebende Transaktion authentisch ist. Wenn Lisa alle Instruktionen in dem Programm fehlerfrei ausführt und das Endergebnis ist OK, dann ist die Transaktion authentisch.

Die Fähigkeit, ein Computerprogramm innerhalb einer Transaktion zu schreiben, ist für verschiedene Anwendungsfälle nützlich. Wir werden diverse Fälle von massgeschneiderten Programmen im Laufe dieses Buches besprechen.

Angenommen, Lisa möchte Input 0 von Johns Transaktion verifizieren. Sie wird dazu das Programm von oben nach unten durchlaufen lassen. Dabei wird ein Stack oder Stapelspeicher benutzt, um die Zwischenergebnisse zu verwalten. Dieser Stack ist wie ein Stapel Zeug. Man kann oben etwas drauflegen oder von oben etwas wegnehmen.

Fangen wir an: schaue dir Abbildung 12 an. Das erste (Top) Element in dem Programm ist eine Signatur, was einfach nur Daten sind. Wenn du normalen Daten begegnest, dann tust du sie oben auf den Stack. Lisa legt die Signatur auf den anderweitig leeren Stack. Dann sieht sie einen public Key, was auch nur Daten sind. Sie tut den ebenfalls auf den Stack. Der Stack enthält jetzt eine Signatur und einen public Key, mit dem public Key oben.

Das nächste Element im Programm ist OP_DUP (Abbildung 13). Das sind jetzt nicht nur Daten–das ist ein Operator. Ein Operator führt Berechnungen durch auf Basis der Elemente auf dem Stack und, in manchen Fällen, der zu verifizierenden Transaktion. Dieser spezielle Operator ist einfach: er sagt “Kopiere das oberste Element auf dem Stack (aber lasse es dort liegen), und lege die Kopie obendrauf”. Lisa befolgt den Befehl und kopiert den public Key auf dem Stack. Jetzt liegen zwei public Keys und eine Signatur auf dem Stack.

Das nächste Element ist ebenfalls ein Operator, OP_HASH160 (auch dargestellt in Abbildung 13). Dies bedeutet “Nimm das oberste Element vom Stack herunter, berechne dessen Hash mittels SHA256+RIPEMD160, und lege das Ergebnis wieder auf den Stack.”

Cool. Lisa nimmt den oberen public Key vom Stack, hasht ihn und legt den resultierenden PKH oben auf den Stack. Das ist natürlich gerade Johns PKH₁, weil es ja Johns public Key war, den Lisa gehasht hat.

Das nächste Element ist wieder nur Daten (Abbildung 14): es ist PKH₁, was der rechtmässige Empfänger der 8 CT ist. Lisa legt PKH₁ auf den Stack.

Als Nächstes kommt ein weiterer Operator, OP_EQUALVERIFY. Das bedeutet “Nimm die beiden obersten Elemente vom Stack und vergleiche sie miteinander. Wenn sie gleich sind, dann fahre beim nächsten Element mit dem Programm fort; ansonsten brich das Programm mit einem Fehler ab.” Lisa nimmt die beiden PKH Elemente von der Spitze des Stacks und prüft, ob sie identisch sind. Sie sind identisch, was bedeutet, der public Key, den John im Signature Script seiner Transaktion mitgeliefert hatte passt zu dem PKH, der als Empfänger im Output gesetzt worden war.

Der letzte Operator, OP_CHECKSIG (Abbildung 15), bedeutet “Verifiziere, dass der public Key oben auf dem Stack und die Signatur darunter die Transaktion korrekt signieren. Lege true oder false oben auf den Stack, abhängig vom Ergebnis der Verifikation.” Lisa nimmt Johns Transaktion und löscht alle Signaturen aus allen Inputs. Sie benutzt die beiden obersten Objekte, was Johns public Key und seine Signatur sind, um zu verifizieren, dass die Signatur die bereinigte Transaktion signiert. Als John seine Transaktion signierte, hat er das ohne Signaturdaten in den Inputs getan. Deshalb muss Lisa erstmal die Signatur-Scriptdaten aus der Transaktion entfernen, bevor sie die Transaktion verifiziert. Die Signatur war in Ordnung, also legt Lisa true, was so viel heisst wie `OK´, zurück auf den Stack.

Schau, das Programm ist jetzt leer! Es gibt nichts mehr zu tun. Nachdem das Programm durchgelaufen ist, enthüllt das oberste Element auf dem Stack, ob das Ausgeben des Outputs authentisch ist. Wenn true–OK–dann ist das Ausgeben autorisiert. Wenn false–nicht OK– dann muss die Transaktion abgewiesen werden. Lisa schaut auf das oberste Stack-Element, und das ist ein OK. Lisa weiss jetzt, dass Johns Input mit Index 0 in Ordnung ist (Abbildung 16).

Lisa führt dieselben Checks für den anderen Input von Johns Transaktion durch, den mit Index 1. Wenn dieses Programm ebenfalls mit OK endet, dann ist die Transaktion gültig und sie kann die Transaktion an das Ende des Spreadsheets hängen.

Johns Transaktion hat gerade zwei pay-to-public-key-hash (p2pkh) Outputs ausgegeben. Aber wie vorher erwähnt, gibt es auch andere Arten zu zahlen–zum Beispiel pay-to-hash, wobei man an einen SHA256 Hash bezahlt. Um einen solchen Output auszugeben, muss man das Pre-Image des Hashes im Signatur Script des ausgebenden Inputs mitliefern. Wir untersuchen noch einige weitere interessante und nützliche Wege, Transaktionen zu authentisieren.

Wir haben immer noch nicht alle Bestandteile einer Transaktion besprochen. Ein paar weitere Brocken Information gehören noch in Transaktionen, inklusive Version, Verwahrdauer und Sequenznummern.

Ich nenne diese knappe Information hier der Vollständigkeit halber. Wir diskutieren diese Features näher in [ch09], wenn du mehr über die Grundlagen von Bitcoin weisst.

Du fragst dich vielleicht, wo all die Cookie Tokens überhaupt erst herkommen. Erinnerst du dich an [ch02], als ich beschrieben hatte, wie Lisa täglich mit 7.200 CT belohnt wird? Sie trägt jeden Tag eine Zeile ins Spreadsheet ein, die 7.200 an sie selbst zahlt.

Jetzt belohnt sie sich immer noch mit 7.200 CT täglich, allerdings auf eine etwas andere Weise. Jeden Tag fügt sie eine neue Transaktion an das Spreadsheet an, die sie Coinbase Transaktion nennt (Abbildung 28).

Der Input der Coinbase-Transaktion heisst coinbase. Die einzige Möglichkeit, neue Coins zu generieren, besteht darin, dem Spreadsheet eine Coinbase-Transaktion hinzuzufügen. Neue Coins werden an Lisa ausgeschüttet, als Belohnung für ihre wertvolle Arbeit.

Johns Transaktion stammt von vier verschiedenen Coinbase Transaktionen ab. Um Johns Transaktion zu verifizieren, muss man allen txids von Johns Transaktion zurück folgen und alle Transaktionen entlang des Weges prüfen, bis man bei den vier Coinbase Transaktionen angekommen ist. Das ist der Teil, wo das UTXO Set den Prüfern hilft. Es enthält alle bereits geprüften UTXOs. Die Prüfer müssen nur den txids folgen (normalerweise nur ein Schritt), bis sie an einen Output kommen, der schon im UTXO Set liegt.

Die Coinbase Transaktionen müssen ebenfalls verifiziert werden, damit es nur genau eine coinbase pro 24 Stunden gibt, und jede coinbase genau 7.200 neue Cookie Tokens erzeugt.

In diesem Kapitel haben wir den Bezahlvorgang formalisiert–zum Beispiel muss die Transaktion aus dem Wallet als Anhang in einer Mail an Lisa geschickt werden. Lisa kann diese Formalisierung zur Automatisierung aller ihrer Aufgaben nutzen. Sie schreibt ein Computerprogramm, das die Transaktionen aus ihrer Mailbox holt und automatisch überprüft, das UTXO Set verwaltet und Transaktionen ans Spreadsheet anhängt. Lisa kann entspannt zuschauen, wie ihr Computerprogramm ihr die Routinearbeit abnimmt. Schön.

Aber jetzt fragt man sich vielleicht, ob Lisa die 7.200 CT Belohnung pro Tag noch wert ist. Sie arbeitet nicht mehr aktiv an den Überprüfungen; sie sitzt nur da und dreht Däumchen. Überlegen wir mal kurz, wofür Lisa eigentlich bezahlt wird. Sie wird nicht bezahlt, um langweilige, manuelle Arbeit zu verrichten, sondern um korrekte, ehrliche Bestätigungen von Transaktionen durchzuführen und sie nicht zu zensieren. Das ist es, was für dich und deine Kollegen wertvoll ist. Wenn Lisa ein Computerprogramm schreibt, um die Hauptarbeit zu erledigen, dann macht dies die Zahlungsabwicklung nicht weniger korrekt oder ehrlich.

Transaktionen lösen das Problem, dass Lisa beliebig Zeug im Spreadsheet ändern könnte. Das einzige, womit wir Lisa noch trauen müssen, ist, dass sie

Wenn es Lisa einfällt, dass sie Faiza eigentlich nicht mag, und sie ausserdem zufälligerweise Kenntnis über Faizas UTXOs hat, kann sie sich weigern, Faizas Transaktionen abzuarbeiten, die versuchen, diese UTXOs auszugeben. Das bedeutet, Faiza kann ihr Geld nicht ausgeben. Lisa zensiert Faizas Transaktionen.

Wenn Lisa eine Transaktion aus dem Spreadsheet entfernt, deren Outputs alle unverbraucht sind, dann könnte das von bereits laufenden Prüfern festgestellt werden. Aber Prüfer, die nach dem Rückabwickeln angefangen haben zu verifizieren, werden es nicht feststellen, weil das Spreadsheet immer noch regelkonform gültig ist.

Angenommen, Lisa revertiert Johns Transaktion aus Abschnitt 5.2. Lisa entfernt Johns Transaktion aus dem Spreadsheet. Niemand hat einen der Output aus Johns Transaktion bisher ausgegeben, sodass das Spreadsheet keine Transaktionen enthält, die ungültig werden, wenn Johns Eintrag gelöscht wird.

Ein bereits laufender Verifizierer–zum Beispiel das Café– merkt davon nichts, weil es nur nach neuen Transaktionen am Ende des Spreadsheets schaut. Es hat bereits Johns Transaktion überprüft und sein UTXO Set aktualisiert. Das Café vertraut darauf, dass Lisa keine Transaktionen löscht und überprüft daher das Spreadsheet nicht immer wieder.

Weiter, angenommen eine neue Kollegin, Vera, fängt an ihr eigenes UTXO Set aus dem Spreadsheet aufzubauen, das jetzt Johns Transaktion nicht mehr enthält. Das UTXO Set wird sich von dem des Cafés unterscheiden. Aus Veras Perspektive hat John immer noch das Geld und hat nicht 10 CT an das Café bezahlt. Die Outputs, die John in der jetzt gelöschten Transaktion ausgegeben hatte, erscheinen Vera unverbraucht, weil sie in Veras UTXO Set liegen.

Wir haben jetzt Vera, die glaubt, dass John immer noch das Geld hat; Lisa, die die Transaktion gelöscht hat; und das Café, das glaubt es hat 10 CT von John bekommen. Bisher hat niemand das Vergehen von Lisa bemerkt. Es wird auch niemand bemerken, bis jemand versucht, einen Output von Johns Transaktion auszugeben. Das könnte das Café sein, das seine 10 CT ausgibt, oder John, der seine 3 CT Change ausgibt.

Sagen wir, das Café will die Miete an die Firma zahlen. Es muss dazu unter anderem die Outputs von Johns Transaktion benutzen. Das Café erzeugt eine Transaktion, die den Output ausgibt, signiert sie und schickt sie an Lisa. Lisa weiss, dass sie Johns Transaktion gelöscht hatte und dass ihr Vergehen bemerkt werden wird. Wenn Lisa sich entscheidet, die Transaktion des Cafés zu bestätigen, dann macht sie damit das ganze Spreadsheet ungültig, und Vera und alle anderen Verifikatoren werden das Spreadsheet komplett verwerfen. Nicht gut. Wenn Lisa sich entscheidet, die Transaktion abzuweisen, was das vernünftiger für sie ist, dann wird es das Café merken, weil die Transaktion nie bestätigt werden wird.

Wenn das Café das merkt, dann kann es nicht beweisen, dass Johns Transaktion je in dem Spreadsheet war. Lisa kann nicht beweisen, dass Johns Transaktion nie in dem Spreadsheet war. Es steht Aussage gegen Aussage. Wir lösen dieses Problem in [ch06].

Es ist nicht klar, weshalb Lisa Johns Transaktion löschen sollte. Vielleicht bezahlt John Lisa dafür, dass sie es tut. Es wäre aber vermutlich vernünftiger, wenn Lisa stattdessen mit ihrem eigenen Geld betrügen würde. Sagen wir, sie kauft einen Keks im Café, und wenn das Café die Transaktion im Spreadsheet gesehen hat, gibt es Lisa den Keks. Lecker. Dann läuft Lisa zurück zu ihrem Arbeitsplatz und löscht ihre Transaktion. Jetzt hat sie einen Keks und behält das Geld. Das wird natürlich bemerkt, wenn das Café versucht, den Output von der gelöschten Transaktion auszugeben. Aber wie bei Johns Transaktion steht hier Aussage gegen Aussage. Lisa kann behaupten, dass die Transaktion nie im Spreadsheet war, und das Café kann behaupten, dass sie darin war. Niemand kann irgendetwas beweisen.

Transaktionen machen es Lisa unmöglich, Cookie Tokens von anderen zu stehlen. Sie lösen dieses Problem dadurch, dass alle Signaturen öffentlich im Spreadsheet stehen. Die Wallets der Benutzer erzeugen und signieren Transaktionen, die Lisa verifiziert und an das Spreadsheet hängt.

Transaktionen haben Inputs und Outputs. Ein Output einer Transaktion enthält den zweiten Teil eines Script Programms. Wenn der Output ausgegeben werden soll, muss der Input, der den Output ausgeben will, den ersten Teil des Programms liefern.

Lisa lässt das Programm laufen. Wenn das Programm mit OK endet, dann ist das Ausgeben dieses Outputs autorisiert. Wenn die Programme aller Inputs einer Transaktion mit OK enden, ist die gesamte Transaktion gültig, und Lisa hängt sie hinten an das Spreadsheet an.

Wenn die Transaktion einmal im Spreadsheet ist, kann jeder genau dieselben Checks machen, wie sie Lisa gemacht hat, weil sie die Transaktion genau so in das Spreadsheet eingetragen hat, wie sie sie bekommen hatte. Wenn Lisa die Transaktion verändern würde, würde man bemerken, dass das Spreadsheet nicht mehr gültig ist, weil es eine ungültige Transaktion enthält. Das einzige, was man nicht überprüfen kann ist, ob Transaktionen zensiert (nicht an das Spreadsheet angehängt) oder gelöscht werden. Mit diesen beiden Sachen muss man Lisa noch trauen.