Bitcoin begreifen

Du kannst die Verschlusszeit auf zwei Weisen angeben. Erstens durch Setzen von Datum und Zeit wie im vorangegangenen Beispiel. Zweitens durch Setzen einer Blockhöhe oder Block Height.

Das frühere Beispiel zeigte einen Anwendungsfall von absoluten Time Locks auf Transaktionen. Man kann den Input einer Transaktion aber auch so lange blockieren, bis sein ausgegebener Output alt genug ist. Das wird als relativer Time Lock bezeichnet. Das geschieht auf Basis der einzelnen Inputs (Abbildung 5).

Die Folgenummer des ersten Inputs der Transaktion lautet 004013c6. Das bedeutet, dass der Input erst 30 Tage nach Bestätigung des ausgegebenen Outputs gültig wird (Abbildung 6).

Das am weitesten links stehende Bit der Folgenummer ist 0, was bedeutet, dass hier relative Time Locks benutzt werden. Das Bit an Position 9 von links ist 1, was bedeutet, dass die rechten 16 Bits interpretiert werden sollten als “Anzahl Intervalle zu je 512-Sekunden.” Die 16 rechten Bits sind 13c6, was in dezimaler Form 5.062 lautet; 5.062 Intervalle zu je 512 Sekunden entspricht rund 30 Tagen.

Der zweite Input hat eine Sequenznummer von 000003e8 (Abbildung 7). Das bedeutet, die Transaktion ist solange ungültig, bis 1.000 Blocks produziert wurden, nachdem der ausgegebene Output bestätigt wurde.

Das ganz links stehende Bit ist auch hier 0, was bedeutet, dass relative Time Locks für diesen Input eingeschaltet sind. Das Bit an Stelle 9 von links ist 0, was bedeutet, die 16 Bits ganz rechts sollen als Blocknummer interpretiert werden. Der Hex Code 03e8 entspricht 1.000 im Dezimalsystem.

Die Transaktionsversion muss mindestens 2 sein, damit relative Time Locks funktionieren. Wenn die Version 1 ist, haben die Folgenummern keine Wirkung auf die relative Lock Time, aber sie beeinflussen die absolute Lock Time und das Replace-by-Fee Feature, die wir beide später in Abschnitt 9.4 besprechen.

Angenommen, du willst deiner Tochter 1 BTC Taschengeld zum 1. Mai geben. Dann kannst du dafür eine Transaktion erzeugen wie in Abbildung 8 dargestellt.

Du kannst diese Transaktion sofort an das Bitcoin Netzwerk senden, und sie bestätigen oder minen lassen. Der erste Output ist der interessante Teil. In ihm steht, dass der Output nicht vor dem 1. Mai ausgegeben werden kann. Für die Neugierigen lautet das genaue Pubkey Script

Dieses Script garantiert, dass die Transaktion, die den Output ausgibt, zeitgebunden ist, wie Abbildung 9 zeigt.

Die ersten beiden Transaktionen werden nie gültig, weil deren Zeitschlösser nicht spät genug sind. Die erste ist gar nicht verriegelt, was laut Pubkey Script ungültig ist. Die zweite ist zwar wenigstens zeitverriegelt, aber nicht spät genug–1 Sekunde vor dem 1. Mai ist zu früh.

Die dritte Transaktion ist OK, weil das Zeitschloss mindestens so spät ist wie die Zeit im Pubkey Script, nämlich 2019-05-01 00:00:00. Diese Transaktion wird ab dem 1. Mai gültig sein. Die letzte Transaktion wird an Sylvester direkt vor dem Feuerwerk gültig. Beachte aber, dass die letzten Transaktionen nicht beide bestätigt werden können–man kann höchstens eine davon bestätigen lassen–da sie beide denselben Output ausgeben.

Das Ergebnis des Beispiels ist, dass deine Tochter den Output ab dem 1. Mai nach Belieben ausgeben kann.

Ein Relativzeit-verriegelter Output funktioniert ähnlich wie ein Absolutzeit-verriegelter Output, aber relative Locks fordern, dass eine gewisse Menge Zeit zwischen dem Block mit dem auszugebenden Output und dem Block mit der ausgebenden Transaktion vergangen ist (Abbildung 10).

Relative Zeitschlösser werden am häufigsten in Digitalen Verträgen verwendet. Ein digitaler Vertrag kann als herkömmlicher Vertrag angesehen werden, der aber mit Hilfe der Regeln des Bitcoin Netzwerks durchgesetzt wird und nicht durch nationale Gesetze. Verträge werden als Bitcoin Pubkey Scripts ausgedrückt. Wir verdeutlichen die Verwendung von zeitverriegelten Outputs bei einem atomaren Tauschgeschäft, einem atomic Swap, im nächsten Abschnitt. Ein atomic Swap bedeutet, zwei Leute tauschen Coins miteinander über verschiedene Kryptowährungen hinweg aus.

Ein häufig erwähnter digitaler Vertrag ist der atomic Swap, bei dem zwei Parteien Coins über Blockchains hinweg miteinander tauschen wollen.

Angenommen, John chattet mit Fadime auf einem öffentlichen Forum im Internet. Sie kennen einander nicht und haben keine gemeinsame Vertrauensbasis. Aber sie wollen miteinander handeln.

Sie einigen sich darauf, dass John 2 BTC gegen 100 von Fadimes namecoins (NMC) eintauscht. Namecoin ist eine Alt-Coin, die als dezentralisiertes Namenssystem, ähnlich DNS, benutzt wird. Wir haben Alt-Coins schon kurz in [ch01] besprochen. Es ist jetzt nicht wichtig zu wissen, wofür Namecoin eigentlich benutzt wird; wir belassen es dabei, dass es eine andere Kryptowährung auf einer anderen Blockchain als der von Bitcoin ist.

Die Unterhaltung zwischen John und Fadime fängt etwa so an:

John: Möchtest du 100 NMC gegen meine 2 BTC eintauschen? Mein Namecoin public Key ist 02381efd…88ca7f23. Ich habe eine geheime Zufallszahl erzeugt, die den SHA256 Hashwert H hat. Ich sage dir aber die Geheimzahl noch nicht.

Fadime: Klar John, machen wir! Mein Bitcoin public Key ist 02b0c907…df854ee8.

Wir nennen die Geheimzahl S. Nur John kennt momentan S, aber er gibt den Hash von S–das ist H–an Fadime weiter. Jetzt haben beide genug Information, um loszulegen.

Sie erzeugen jeder eine Transaktion (Abbildung 11). John erzeugt eine Bitcoin Transaktion, die 2 BTC ausgibt. Fadime erzeugt eine Namecoin Transaktion, die 100 NMC ausgibt. Sie übermitteln ihre Transaktionen noch nicht.

Der Output von Johns Vertragstransaktion kann in einer von zwei Weisen ausgegeben werden:

Ebenso kann der Output von Fadimes Transaktion auf zwei Arten ausgegeben werden:

Die relative Lock Time wird durch den Script Operator OP_CHECKSEQUENCEVERIFY erzwungen. Der Operator stellt sicher, dass der Output von Johns Transaktion durch John nicht ausgegeben werden kann, bevor 48 Stunden nach Bestätigung der Vertragstransaktion vergangen sind. In Fadimes Vertragstransaktion garantiert der Operator, dass Fadime den Output nicht ausgibt, bevor 24 Stunden abgelaufen sind.

Fadime weiss, dass John die Geheimzahl kennt. Wenn Fadime jetzt ihre Vertragstransaktion übermittelt, kann John das Geld nehmen und seinen Teil des Vertrags unerfüllt lassen. Deshalb sendet sie ihre Transaktion nicht, bis sie gesehen hat, dass Johns Transaktion sicher in der Blockchain bestätigt wurde. Weil Fadime die Geheimzahl S nicht kennt, kann John seine Vertragstransaktion beruhigt übermitteln, ohne dass Fadime sich das Geld schnappen kann.

John übermittelt seine Vertragstransaktion. Denke daran, dass der Output der Vertragstransaktion in diesem Beispiel ein pay-to-script-hash (p2sh) Output ist. Der Output enthält eine p2sh Adresse, die nichts darüber sagt, dass dies Johns Vertragsoutput ist. Damit Fadime Johns Vertragstransaktion auf der Bitcoin Blockchain findet, wird sie dasselbe Redeem Script bauen, das John für seine Vertragstransaktion generiert hat, und erzeugt die p2sh Adresse, an die Johns Vertragstransaktion gezahlt hat. Sie kann dann in der Bitcoin Blockchain nach der p2sh Adresse schauen.

Wenn Fadime sieht, dass Johns Transaktion bestätigt wurde, übermittelt sie ihre eigene Transaktion. John wartet, bis Fadimes Transaktion hinreichend tief in der Namecoin bestätigt wurde. Dann geschieht der eigentliche Tausch in zwei Schritten. Abbildung 12 zeigt den ersten Schritt.

John übermittelt seine Swap Transaktion. Johns Swap Transaktion gibt Fadimes Vertragstransaktions Output aus, indem es das Geheimnis S und seine Signatur liefert. Beachte wieder, dass John einen p2sh Output ausgibt. Das bedeutet, dass während der Script-Validierung als erstes das Redeem Script, das John im Signatur Script geliefert hat, gehasht und mit dem Hash im Pubkey Script verglichen wird. Danach läuft das eigentliche Redeem Script.

Wir gehen das Programm nicht detailliert durch. Aber wenn das Redeem Script zu laufen anfängt, liegt oben auf dem Stack eine 1. Das bedeutet true in Namecoin ebenso wie in Bitcoin. Dieser Wert führt dazu, dass das Programm den Teil des Scripts laufen lässt, der das Pre-Image und Johns Signatur benötigt. Der andere Teil läuft überhaupt nicht ab.

Das Script hinterlässt true auf dem Stack, weil John beide benötigten Objekte in der richtigen Reihenfolge geliefert hat–seine Signatur und das Pre-Image S. Er holt sich erfolgreich die 100 NMC.

Sobald Fadime Johns Swap Transaktion auf dem Namecoin Netzwerk sieht, kann sie ihre eigene Swap Transaktion für das Bitcoin Netzwerk erzeugen (Abbildung 13).

Sie nimmt das Pre-Image, S, aus Johns Swap Transaktion, und tut es in ihre eigene Swap Transaktion, die 2 BTC an Fadimes public Key Hash PKH_F zahlt. Mit Bestätigung der beiden Swap Transaktionen ist der Atomic Swap erledigt. Der Effekt all dessen ist, dass John 2 BTC an Fadime unter der Bedingung geschickt hat, dass Fadime ihm 100 NMC schickt, und dass Fadime 100 NMC an John schickt, sofern er + 2 BTC an sie schickt.

Weil die PKHs erfunden sind, haben sie keine bekannten Pre-Images. Das bedeutet auch, dass keine bekannten public/private Key Paare mit ihnen assoziiert sind, sodass niemand jemals diese Outputs wird ausgeben können. Sie sind nicht verwendbar, oder unspendable. Die Bitcoin Adresse des letzten PKHs ist 157sXYpj…QnHB6FGU. Jeder, der Geld an diese Adresse zahlt, wirft dieses Geld in den Mülleimer. Das Geld ist für immer verloren. Es entspricht dem Verbrennen eines Dollarscheins.

Unspendable Outputs wie diese sind von normalen, verwendbaren Outputs nicht zu unterscheiden. Man kann nicht beweisen, dass sie unspendable sind. Full Nodes müssen sie als verwendbar betrachten, was bedeutet, sie müssen auf ewig diese unspendable Outputs in ihrem Unausgegebenen Transaktions Output (UTXO) Set halten. Das belastet die Nodes unnötig, weil sie all diese Outputs im Speicher halten müssen.

Bitcoin Entwickler haben eine partielle Lösung für dieses Problem entwickelt- Statt Geld an nicht beweisbar unspendable Outputs zu schicken, können Benutzer beweisbar unspendable Outputs erzeugen. Wenn ein Full Node feststellen kann, ob ein Output unspendable ist + dann muss er diesen nicht zum UTXO Set hinzufügen.

Die teilweise Lösung involviert einen neuen Script Operator namens OP_RETURN. Dieser Operator bricht die Ausführung des Scripts sofort ab. Ein typisches OP_RETURN Script kann zum Beispiel so aussehen:

Wenn jemand versucht, diesen Output auszugeben, wird das Script abbrechen, sobald es auf den OP_RETURN Operator trifft. Wenn das Pubkey Script diesen Operator enthält, kann ein Full Node feststellen, dass der Output nicht verwendbar ist und ihn ignorieren, um zu verhindern, dass das UTXO Set für immer von diesem Unsinn aufgebläht wird. Ein typischer OP_RETURN Outpus zahlt 0 BTC, aber er kann auch einen Wert grösser als 0 BTC zahlen, um Geld zu “verbrennen.”

Es gibt ein paar Policies hinsichtlich OP_RETURN:

Diese beiden Policies sind genau das–Policies, also Grundsätze. Full Nodes, die sich an diese Policies halten, relayen keine Transaktionen, die die Policies verletzen. Aber wenn sie einem Block begegnen, der Transaktionen enthält, die die Policies verletzen, dann wird der Block akzeptiert und weitergeleitet. Ich spreche mehr über Policies und Konsensregeln, strenge Regeln, die für Blocks gelten, in [ch10] und [ch11].

Ich bin in [ch01] kurz auf das Protokollieren von Eigentumsrechten auf der Blockchain eingegangen. Angenommen ein Autohersteller, nennen wir ihn mal Ampere, beschliesst, dass er die Eigentumsrechte an seinen Autos auf digitalem Wege auf der Bitcoin Blockchain verfolgen will. Dies kann durch Erzeugung eines Tokens in Bitcoin erreicht werden.

Angenommen Ampere möchte für ein neu hergestelltes Auto mit der Fahrgestellnummer 123456 ein Token erzeugen. Es übermittelt dazu eine Bitcoin Transaktion wie in Abbildung 14 gezeigt.

Das “Ampere Token Protokoll” spezifiziert, dass ein neues Token generiert wird, wenn

Ampere hat eine wohlbekannte Webseite auf https://www.ampere.example.com, wo es seinen public Key, der mit PKH_A korrespondiert, veröffentlicht hat. Die Firma verbreitet ausserdem den public Key durch Werbung und über Facebook und Twitter. Es tut all dies, damit Leute sicherstellen können, dass PKH_A tatsächlich Ampere gehört.

Angenommen Ampere verkauft dieses Auto an einen Händler. Der Händler hat einen public Key Hash, PKH_D. Abbildung 15 zeigt, wie Ampere das digitale Eigentum an den Händler übergibt.

Gemäss unserem einfachen Protokoll wird das Eigentum am Auto übertragen, indem der Output des alten Besitzers ausgegeben wird. Hierbei gelten folgende Regeln:

Der Autohändler ist nun der neue Besitzer, weil PKH_D der erste Output der ausgebenden Transaktion ist. Das ist alles. Wenn der Händler das Auto an eine Kundin verkauft, Fadime, überträgt er die Eigentumsrechte auf Fadimes Adresse PKH_F (Abbildung 16).

Nun, da Fadime die rechtmässige Besitzerin des Autos ist, wäre es da nicht toll, wenn sie es anlassen könnte, indem sie beweist, dass sie die Eigentümerin ist? Das kann sie. Der Wagen ist mit einem Zündschloss versehen, das den Motor startet, wenn Fadime den Beweis des Eigentums, den Proof of Ownership, an das Auto schickt (Abbildung 17).

Fadime bittet zunächst den Wagen, zu starten. Das Auto startet aber nicht, wenn es nicht weiss, dass Fadime den private Key hat, der zu PKH_F gehört. Daher erzeugt das Auto eine sehr grosse Zufallszahl und schickt sie an Fadime, welche diese Zufallszahl mit ihrem private Key signiert und die Signatur und ihren public Key an das Auto zurückschickt. Man nennt diese Zufallszahl eine Challenge.

Das Auto benötigt den public Key, um zu prüfen, dass er mit dem in der Blockchain gespeicherten PKH_F korrespondiert. Das Fahrzeug bleibt über die Eigentumsrechte an ihm im Bilde, indem es ein Lightweight Wallet beherbergt, welches das Ampere Token Protokoll versteht.

Wenn der Wagen überprüft hat, dass die Signatur gültig ist und vom korrekten private Key stammt, startet es die Maschine.

Im Jahre 2016 wurde eine Policy für das Ersetzen von Transaktionen ausgerollt. Sie wird im Allgemeinen als opt-in replace-by-fee, oder opt-in RBF bezeichnet (Abbildung 20). Sie funktioniert durch Verwendung der Sequenznummern in den Transaktionsinputs.

Wieder einmal angenommen, dass du ein Buch in einem Online Buchladen kaufen willst. Wenn du die Transaktion erzeugst, sorgst du dafür, dass einer der Inputs (in diesem Beispiel gibt es nur einen) eine Folgenummer kleiner als fffffffe besitzt. Dies signalisiert den Nodes, dass du diese Transaktion als ersetzbar markieren möchtest.

Wenn ein Node diese Transaktion empfängt, behandelt er sie wie eine normale Transaktion, aber er merkt sich die Ersetzbarkeit.

Wenn dir später klar wird, dass die Transaktion wegen zu geringer Gebühren nicht bestätigt wird, erzeugst eine neue Ersatztransaktion mit einer höheren Gebühr. Wenn du diese Ersatztransaktion sendest, werden die Nodes, die diese empfangen–sofern sie die opt-in RBF Policy umgesetzt haben–die alte Transaktion freundlicherweise durch die neue ersetzen und die neue an ihre Peers weiterleiten. Die alte Transaktion wird verworfen. Auf diesem Weg wird die Ersatztransaktion irgendwann bei allen Nodes ankommen und hoffentlich innerhalb einer vernünftigen Zeit bestätigt werden.

In diesem Beispiel setzt du die Folgenummer des Transaktionsinputs auf ffffffff. Das bedeutet, die Ersatztransaktion ist nicht selbst wieder ersetzbar. Wenn du die Ersatztransaktion wiederum ebenfalls ersetzbar haben willst, musst du ihre Folgenummer auf fffffffd oder weniger setzen, genau wie du es mit der ersetzten Transaktion getan hast.

Du magst dich vielleicht fragen, wo diese Folgenummern herkommen. Die Intention mit den Folgenummern oder Sequenznummern war von Anfang an, eine andere Art von Transaktionsersatz zu erlauben. Dieses Feature wurde in Bitcoin früh disabled, aber die Folgenummern in den Transaktionsinputs blieben. Diese Nummern wurden seitdem zur Benutzung für absolute und relative Lock Time und replace-by-fee umgewidmet, wie im Laufe dieses Kapitels besprochen. Wenn du jetzt verwirrt bist, mach dir keine Sorgen; Ich summiere die verschiedenen Anwendungen von Folgenummern in Abschnitt 9.6 auf.

Es gibt noch eine Art, eine Gebühr nachträglich zu erhöhen. Angenommen du hast die in Abbildung 18 beschriebene Situation und merkst, dass die Transaktion steckenbleibt (Abbildung 21).

Du kannst eine weitere Transaktion erstellen, die dein Wechselgeld, deine Change, ausgibt und eine extra hohe Gebühr zahlt, um die zu geringe Gebühr in der originalen Transaktion zu kompensieren (Abbildung 22).

Angenommen, ein Miner sieht diese beiden Transaktionen. Wenn der Miner die Fee von der Child Transaktion einsammeln will, muss er sowohl Parent als auch Child Transaktion in seinen Block einbringen. Versucht er, nur die Child Transaktion einzubringen, wäre der Block ungültig, weil die Child Transaktion Geld ausgibt, das in der Blockchain nicht existiert.

Sowohl du als auch der Buchladen können diesen Trick anwenden. Wenn du die Gebühr nicht hochschraubst, kann der Buchladen seinen Output von 10 BTC ausgeben und sich selbst davon 9,9998 BTC schicken, was 0,0002 BTC zu der gesamten Gebühr der beiden Transaktionen hinzufügt.