Anhang B: Antworten zu den Übungen

B.1. Kapitel 2

  1. 256 Bits.

  2. 32 Bytes.

  3. Eine kryptografische Hashfunktion.

  4. 061a ist 6*256 + (16 + 10) = 1,536 + 26 = 1,562 in dezimaler Form. Die binäre Form von 06 ist 0000 0110 und die binäre Form von 1a ist 0001 1010, sodass die volle binäre Repräsentation 0000 0110 0001 1010 ist.

  5. Nein. Wenn das möglich wäre, wäre die Funktion nicht second-Pre-Image-resistent.

  6. Eigenschaften 2 und 4 fehlen.

  7. Second-Pre-Image Resistenz stoppt den Angreifer. Der Angreifer muss einen Input finden, der denselben Hash liefert wie ein bestimmter anderer Input: das Katzenbild.

  8. Das Geldmengenwachstum verringert sich im Laufe der Zeit, weil die Belohnung an Lisa sich alle 4 Jahre halbiert. Das bedeutet, die Gesamtmenge an CT, die jemals erzeugt werden wird, wird ungefähr 21.000.000 betragen.

  9. Die Kollegen haben Lesezugriff auf das Spreadsheet. Sie können das Spreadsheet beobachten und verifizieren, dass Lisa sich nicht zu viel oder zu häufig selbst belohnt.

  10. Der private Key wird mit Hilfe irgendeiner Art von Zufallszahlengenerator erzeugt. Ein Einfacher ist eine Münze, die man 256 mal wirft, um seinen 256 Bit Key zu generieren. Du kannst auch den in deinem Betriebssystem eingebauten Zufallszahlengenerator benutzen.

  11. Der private Key.

  12. Die Message wird gehasht, weil du willst, dass die Signatur klein und von fester Grösse ist. Du willst keine grossen Signaturen haben, bloss weil die signierte Nachricht gross ist.

  13. Mallory würde Johns private Key brauchen, um von ihm Kekse zu klauen. Sie würde auch seinen Namen, John, brauchen, um ihn in die Mail an Lisa zu schreiben, aber der steht ja frei zugänglich im Spreadsheet.

  14. Fred kann deinen public Key benutzen, um die Nachricht zu verschlüsseln und dir zu schicken. Du kannst dann die Nachricht mit deinem private Key entschlüsseln.

  15. Du signierst die Nachricht mit deinem private Key und schreibst die digitale Signatur auf die Notiz in der Flasche. Fred kann dann verifizieren, dass die Signatur in der Tat mit deinem private Key angefertigt wurde. Er tut dies, indem er deinen public Key zum Entschlüsseln der Signatur benutzt und den entschlüsselten Hash mit dem Hash der Nachricht vergleicht. Wenn sie übereinstimmen, kann er sicher sein, dass die Nachricht von dir stammt.

B.2. Kapitel 3

  1. Der PKH ist kurz ausgelegt, weil es a) das Spreadsheet von der Grösse her kleiner macht und b) der Benutzer bei Cookie Token Adressen (und Bitcoin Adressen) weniger schreiben muss.

  2. Ja, du kannst. Es gibt einen base58check Dekodieralgorithmus, der das macht.

  3. Es wird von einem Zahler benutzt, um die Empfängeradresse in einen PKH zu übersetzen. Der Zahler muss den PKH des Empfängers in die Mail an Lisa schreiben.

  4. Lass uns 0047 base58-codieren, Schritt für Schritt:

    1. Entferne führende 00 Bytes. Es gibt davon nur eines, was dir 47 übrig lässt.

    2. Konvertiere da in eine Dezimalzahl: 47 in Hex ist 4 × 16 + 7 = 71 in Dezimal.

    3. Dividiere 71 durch 58: 71 = 1 × 58 + 13. Der Quotient ist 1 und der Rest ist 13.

    4. Dividiere den Quotienten, 1, durch 58: 1 = 0 × 58 + 1. Der Quotient ist 0 und der Rest ist 1.

    5. Schlage die Reste 13 and 1 nach. Resultat: E und 2.

    6. Addiere eine 1 für das entfernte 00 Byte aus Schritt 1, was in E21 resultiert.

    7. Drehe es um: 12E. Fertig.

  5. Die 4-Byte Checksumme.

  6. Er muss zwei getrennte Zahlungen machen. Zum Beispiel: Zahlung 1 zahlt 2 CT von @1 an das Café und Zahlung 2 zahlt 8 CT von @2 an das Café. Man könnte auch erst 2 CT von @1 an @2 zahlen und dann 10 CT von @2 an das Café.

  7. Ja, es ist. Base58check-codiere die PKHs, um die Adresse zu bekommen.

  8. Nein, weil das Spreadsheet PKHs enthält. Da kryptografische Hashfunktionen Einbahn-Funktionen sind, kannst du aus dem PKH nicht den public Key herleiten.

  9. Sie können die Beträge betrachten. Viele der 10 CT Zahlungen sind wahrscheinlich Käufe von Keksen.

  10. Der Bösewicht kann keine Cookie Tokens stehlen, weil er den public Key bräuchte, um den Fehler in der public Key Ableitungsfunktion auszunutzen. Das Spreadsheet enthält PKHs; der Bösewicht kann daraus nicht den public Key herleiten.

  11. Der Bösewicht braucht den private Key, um betrügerische Mails an Lisa zu schicken. Auch wenn er RIPEMD160 umdrehen kann, muss er immer noch eine Pre-Image Attacke aus SHA256 führen und die public Key Ableitungsfunktion umkehren, um zu einem funktionierenden private Key zu kommen.

B.3. Kapitel 4

  1. bitcoin:155gWNamPrwKwu5D6JZdaLVKvxbpoKsp5S?amount=50

  2. Jedes Zeichen korrespondiert mit 6 Bits Entropie, weil 26 = 64. Zehn solche Zeichen ergeben 60 Bits Entropie, was 60 Münzwürfen entspricht.

  3. Die vier Probleme:

    • Passwörter werden schnell vergessen.

    • Zufälligkeit ist schwierig.

    • Die Sicherheit eines Passworts sinkt mit fortschreitender Technologie.

    • Du musst zwei Dinge m Auge behalten: das Backup und das Passwort. Dies erhöht das Risiko, dass das Backup verloren ist.

  4. Der Seed wird unter Benutzung eines Zufallszahlengenerators erzeugt–zum Beispiel einer Serie von Münzwürfen oder dem Zufallszahlengenerator, den dein Betriebssystem liefert.

  5. Ein xprv besteht aus einem private Key und einem Chain Code.

  6. Ein xpub besteht aus einem public Key und einem Chain Code.

  7. Der xprv an Pfad m/2/1 und der gewünschte Index 7.

  8. Nein, du bräuchtest xprv m/2/1, um xpub M/2/1/7' abzuleiten. Du leitest erst den gehärteten xprv m/2/1/7' von m/2/1 mittels gehärteter xprv Ableitung her und berechnest dann den xpub M/2/1/7' aus m/2/1/7'.

  9. Du kannst wie folgt vorgehen, um den Master xprv zu erhalten:

    1. Benutze den Master xpub M, um den xpub M/4 abzuleiten, und merke dir den links-links Hash L4.

    2. Benutze M/4, um den links-links Hash L41 an Index 1 abzuleiten.

    3. Subtrahiere L41 vom private Key m/4/1, um den private Key m/4 zu erhalten.

    4. Subtrahiere L4 vom private Key m/4, um den private Key m zu bekommen.

    5. m zusammen mit dem Chain Code von xpub M ist der Master xprv.

  10. Ja, du wärst in der Lage, alles Geld in jeder Adresse zu stehlen, weil du den Master xprv berechnen könntest.

  11. Das Opfer hätte stattdessen Härtung benutzen können, um m/4' zu generieren. Dann könntest du nicht den Master xprv bekommen. Wenn du m/4'/1 und den Master xpub stehlen würdest, könntest du nur das Geld auf dem m/4'/1 Key stehlen. Du könntest nicht den M/4' xpub berechnen.

  12. Die Angestellten können den xpub für das Thekenverkaufskonto importieren. Dann können sie alle public Keys unter diesem Konto generieren, und daher alle Adressen, die sie brauchen, ohne jemals irgendeinen private Key kennen zu müssen.

  13. Dein (und Anitas) Wallet kann 10 Adressen im voraus generieren, und das Spreadsheet im Hinblick auf diese Adressen beobachten. Wenn Anita an einer dieser Adressen eine Zahlung empfängt–vermutlich auf der ersten der 10–, dann wird dein Wallet diese Adresse nicht erneut benutzen, wenn du eine Zahlung von einem Kunden anforderst. Es würde stattdessen die nächste unbenutzte Adresse nehmen.

B.4. Kapitel 5

  1. Du würdest die 4 CT und die 7 CT Outputs verwenden. Die neuen Outputs wären 10 CT an das Café und 1 CT an Change an eine Adresse, die dir gehört.

  2. Sie werden in Inputs benutzt, um Transaktionen zu referenzieren, von denen Outputs ausgegeben werden sollen.

  3. Weil du nicht einen Teil eines Transaktionsoutputs ausgeben kannst. Du gibst den Output entweder komplett aus oder gar nicht. Wenn der ausgegebene Output mehr Wert enthält als du zahlst, musst du Wechselgeld, also Change, an dich zurück zahlen.

  4. In den Signatur Scripts in den Inputs.

  5. Weil die Prüfenden wissen müssen, mit welchem public Key du die Signatur verifizierst. Du kannst die Signatur nicht mit einem PKH überprüfen, also musst du den public Key im Signatur Script explizit preisgeben.

  6. Die Signatur Scripts werden bereinigt, so dass die Prüfer die Reihenfolge, in denen die Inputs signiert wurden, nicht kennen müssen.

  7. Jeder Output einer Transaktion enthält ein Pubkey Script. Es enthält den zweiten Teil des Script Programms. Der erste Teil wird später geliefert, wenn der Output ausgegeben wird.

  8. Das Script Programm muss mit einem OK ganz oben auf dem Stack enden.

  9. Eine p2sh Adresse beginnt stets mit einer 3. Du kannst sie auch dadurch erkennen, dass du sie base58check-decodierst und dir das erste Byte anschaust. Wenn das Byte 05 ist, ist es eine p2sh Adresse.

  10. Du erzeugst eine Transaktion mit einem Input und drei Outputs:

    appb 01

  11. 10.003 UTXOs. Du entfernst zwei UTXOs, indem du deren Outputs ausgibst, und du fügst fünf neue UTXOs hinzu. Der Nettoeffekt auf das UTXO Set beträgt somit +3 UTXOs.

  12. Das Pubkey Script kann zum Beispiel 1 ` sein. Der ausgebende Input kann ein leeres Signatur Script haben. Das volle Script Programm legt nur eine `1 auf den Stack. Ein Ergebnis-Stack mit einem Wert ungleich Null oben auf dem Stack bedeutet OK.

  13. OP_ADD 10 OP_EQUAL. Dies wird erst die beiden obersten Elemente auf dem Stack addieren und das Resultat wieder oben ablegen. Dann schiebst du die Zahl 10 auf den Stack und vergleichst die beiden Elemente. Wenn sie gleich sind, wird OK auf den Stack gelegt.

  14. Ja. Dein Full Node verifiziert alles im Spreadsheet von der allerersten Transaktion bis zu der Transaktion, die dein Geld von Faiza enthält. Es verifiziert (unter anderem) das Folgende:

    • Lisa hat die erwartete Anzahl Coinbase Transaktionen mit den korrekten Beträgen darin erzeugt.

    • Für jede Transaktion im Spreadsheet überschreitet der Wert der Summe der Outputs nicht den Wert der Summe der Inputs.

    • Alle Signaturen von Faizas Zahlung zurück bis zu allen Coinbase Transaktionen sind OK.

  15. Wenn mehrere UTXOs für dieselbe PKH vorhanden sind, wird die Sicherheit der anderen UTXOs für dieselbe PKH beeinträchtigt, sobald eine davon ausgegeben wird. Dies liegt daran, dass du eine Sicherheitsebene entfernst, die kryptografische Hash-Funktion. Ab diesem Zeitpunkt verlässt du dich ausschließlich auf die Funktion zur Ableitung des public Keys, um sicher zu sein. Du kannst dieses Problem vermeiden, indem du für alle eingehenden Zahlungen eindeutige Adressen verwendest. Dann haben alle deine UTXOs unterschiedliche PKHs.

B.5. Kapitel 6

  1. Über die Block ID des Vorgängerblocks, welcher der Hash des Block Headers des Vorgängerblocks ist.

  2. Der Merkle Root bindet sich an alle Transaktionen in diesem Block.

  3. Lisas Block Signatur bindet sich an den Timestamp, den Merkle Root (und damit indirekt an alle Transaktionen in diesem Block) und die Vorgänger-Block-ID (und damit indirekt an die gesamte Blockchain vor diesem Block).

  4. Die erste Transaktion in jedem Block ist die Coinbase Transaktion. Diese Coinbase Transaktion erzeugt 50 neue Cookie Tokens und schickt diese an Lisas Cookie Token Adresse.

  5. Alle Transaktionen. Die Hashfunktionen resultieren alle in einem Index, der 1 enthält, weil es keine Nullen im Bloom Filter gibt. Jedes Element in der Transaktion, die du prüfst, wird ein Treffer sein.

  6. Das Folgende wird geprüft:

    • Die txid zusammen mit dem Index, der den auszugebenden Output identifiziert.

    • Alle Datenobjekte in den Signatur Scripts.

    • Alle Datenobjekte in den Pubkey Scripts.

    • Die txid der Transaktion

  7. Sie sind nicht Pre-Image resistent, kollisionsresistent oder second-Pre-Image resistent. Der Output-Raum ist klein–typischerweise nur ein paar hundert bis ein paar tausend Zahlen. Es würde nur einen Bruchteil einer Sekunde dauern, um ein Pre-Image für, zum Beispiel, 172 zu finden.

  8. Das am weitesten rechts stehende Blatt muss kopiert werden, um zu einer geraden Anzahl Blätter zu kommen. Dasselbe gilt für die nächste Ebene, wo der dritte Hash kopiert werden muss.

    appb 02

  9. Wenn Lisas privater Block-Signatur-Key gestohlen wird, kann der Dieb Blocks in Lisas Namen erzeugen. Und wenn ein Bösewicht Lisas Block-Signatur-publik-Key an einer oder mehreren Stellen ersetzt, zum Beispiel am schwarzen Brett oder im Intranet, kann der Bösewicht die Leute dazu bekommen, Blocks zu akzeptieren, die nicht von Lisa signiert wurden.

  10. Lisa kann Transaktionen zensieren, und der Administrator des Shared Folders kann Blocks zensieren.

  11. a) Ja, ein neuer Node, der alle Blocks vom Shared Folder herunterlädt, wird merken, dass es zwei Versionen des Blocks gibt. b) Ja, ein alter Node, der den Originalblocks bereits heruntergeladen hat, wird merken, dass es eine alternative Version des Blocks gibt.

  12. Die Bits an den Indizes 1, 5, 6 und 7 werden auf 1 gesetzt und die anderen auf 0. Der Full Node würde seine Transaktion nicht an das Lightweight Wallet schicken. Nichts, das getestet wird, hasht nur zu Indizes, wo die Bits 1 sind. Das war ein bisschen eine Trickfrage, weil die ausgegebene txid und der Output Index der ausgegebenen Transaktion nicht einzeln getestet werden, sodass 1,6,6 nie vom Full Node in Betracht gezogen wird.

    appb 03

  13. Der partielle Merkle Tree ist

    Anzahl TX: 3
Flags: ✔✔✘✔✔✔
Hashes 3 4 6

  14. Die interessanten Transaktionen sind die Nummern 7 and 13, oder Blattnummern 6 und 10 von links. Du hast die Lösung in [bigger-trees] bereits gesehen, aber ich liefere sie hier nochmal als Referenz.

    appb 04

  15. Du musst das Folgende verifizieren:

    • Die txid der Transaktion befindet sich in der Liste der Hashes.

    • Der Root des partiellen Merkle Trees passt zum Merkle Root im Block Header.

    • Der Block Header ist korrekt signiert.

B.6. Kapitel 7

  1. Sie entscheidet allein drüber, welche Transaktionen bestätigt werden.

  2. Die Wahrscheinlichkeit für Zensur verringert sich, weil alle Miner, um Erfolg zu haben, kooperativ entscheiden müssten, eine Transaktion zu zensieren. Ansonsten würden deine Transaktionen irgendwann von einem nicht dabei mitspielenden Miner bestätigt.

  3. Miner können mit Zufallszahlen schummeln. Und du kannst nicht beweisen, dass einer geschummelt hat.

  4. Verifiziere, dass die Block-ID eines Blocks niedriger ist als das Target im Block Header, und dass das Target dem vereinbarten Target entspricht.

  5. Durch wiederholtes Ändern der Nonce und Hashen (Doppel-SHA256) des Block Headers, bis die Block-ID (der Block Header Hash) kleiner als das Target ist.

  6. Der Zweig mit dem meisten gesammelten Proof of Work. Das ist nicht notwendigerweise der Zweig mit den meisten Blocks.

  7. Ein Miner mit einer Hashrate von 100 MHash/s kann 100.000.000 Versuche pro Sekunde durchführen, um einen gültigen Proof of Work zu finden.

  8. Das Target wird zunehmen. Wenn die 2.016 Block 15 Tage brauchen anstatt des Ziels von 14 Tagen, dann ist es zu schwierig, Blocks zu finden, also muss die Difficulty verringert werden, was bedeutet, das Target zu erhöhen.

  9. 50%. Aber wenn du vorhast, irgendwann aufzugeben, sinken deine Chancen.

  10. Der kleine Block erreicht die anderen Miner schneller als der grosse Block, weil sich ein kleiner Block schneller durch ein Computernetzwerk fortpflanzt als ein grosser Block. Der kleine Block wird vermutlich auch schneller verifiziert als der grosse Block. Miner werden den kleinen Block wohl schneller herunterladen als den grossen Block, und ihre Mining Aktivität auf dem kleinen Block aufbauen, was dem kleinen Block eine höhere Wahrscheinlichkeit gibt, Teil der stärkeren Chain zu werden.

  11. Das Target wird sich um einen Faktor 3/4 verringern. Die Zeit, um 2.016 Blocks zu produzieren, ist 1,5 Wochen; die ersten 1.008 Blocks brauchen 1 Woche und die nächsten 1.008 Blocks brauchen 0,5 Wochen. Also wird das nächste Target

    \[N= O*\left\{ \begin{array}{ll} \frac{1}{4} & \mbox{if } T \lt 0.5 \\ \frac{T}{2} & \mbox{if } 0.5 \leq T \leq 8 \\ 4 & \mbox{if } 8 \lt T \end{array} =O*\frac{1.5}{2}=O*\frac{3}{4} \right.\]

  12. Selma hat die Mehrheit der Hashrate. Solange sie sich an dieselben Regeln hält wie alle anderen, verdient sie eine Menge Geld. Wenn sie die Regeln bricht, indem sie das Target verfrüht ändert, werden alle Full Nodes ausser Selmas eigenem ihre Blocks verwerfen. Selma wird auf ihrem eigenen Zweig der Blockchain weiterarbeiten, während der Rest des Netzwerks auf dem Zweig mit den alten Regeln weiterarbeitet. Die Zweige sind nicht miteinander kompatibel. Die Hashrate des alten Zweigs wird auf 48% fallen, aber das System wird weiterlaufen und jeder wird weitermachen wie bisher. Andererseits wird Selma eine Menge Strom und Zeit auf ihrem Zweig verbrauchen, und niemand wird ihre Block Rewards kaufen. Der Wert ihrer produzierten Coins wird vermutlich nah bei Null liegen, weil sie den Regeln nicht folgt. Selma ist die Verliererin.

  13. Die von den meisten Minern verwendete Fee-pro-Byte Metrik wird sehr niedrig sein. Für jedes Byte an Transaktionsdaten, das der Miner in einen Block einbringt, verliert er ein kleines bisschen an Wettbewerbsfähigkeit, weil der Block grösser wird und es daher länger dauert, ihn durch das Netzwerk zu transportieren und zu verifizieren. Wenn die Fee pro Byte für die Transaktion nicht ausreichend hoch ist, um den Verlust an Konkurrenzfähigkeit zu kompensieren, wird der Miner sie vermutlich nicht in den Block einbinden.

B.7. Kapitel 8

  1. Der Shared Folder ist eine schlechte Idee, weil sie dem Shared Folder Administrator absolute Macht darüber gibt, welche Blocks erlaubt sind. Und wenn der Administrator anfängt zu minen, kann er alle Konkurrenz ausschalten und hat dann absolute Macht über das System.

  2. Blocks oder Transaktionen zu relayen heisst, sie an Peers weiterzuleiten.

  3. Eine inv Message wird benutzt, um Peers darüber zu informieren, dass du eine bestimmte Transaktion oder einen bestimmten Block hast; inv steht für Inventory oder Inventar.

  4. Er lässt die Transaktion durch den Bloom Filter laufen, den er vom Wallet bekommen hat. Wenn eines der getesteten Elemente in der Transaktion zu dem Filter passt, schickt der Node die Transaktion an das Wallet.

  5. Der Full Node schickt ein inv an das Lightweight Wallet, nachdem er den Bloom Filter konsultiert hat. Das Wallet kann dann die Transaktion abholen, wenn es sie nicht bereits kennt.

  6. Der Block Header

  7. Weil das Café gegenüber seinem vertrauten Node nicht verschleiern muss, welche Adressen zum Wallet gehören. Es schickt einen sehr grossen Bloom Filter, um Datenvolumen auf seinem Mobiltelefon zu sparen; ein Bloom Filter, der fast nur Nullen enthält, schickt fast keine Fehltreffer.

  8. Sie würde die Signatur des Programms anhand des public Keys, von dem sie weiss, dass er dem Bitcoin Core Entwicklerteam gehört, verifizieren. Sie tut dies, damit sie nicht auf versteckte Malware hereinfällt.

  9. Einen DNS Server benutzen, um eine Liste von IP Adressen für einen in Bitcoin Core konfigurierten DNS Seed (ein DNS Name) zu bekommen, vertrauenswürdige Freunde fragen, und die festcodierten Adressen benutzen, die mit Bitcoin Core ausgeliefert werden.

  10. Die Peers des Nodes kündigen neue Blocks an, indem sie headers Messages an den Node schicken, sogar während des Synchronisationsprozesses.

  11. Du musst das Café, Qi und Tom überzeugen, Blocks vor Lisa zu verbergen. Du kannst sie bestechen oder bedrohen.

  12. Sie schickt eine inv Message an Rashids Node mit den zwei Transaktions-IDs.

  13. Dein Node beginnt den Synchronisationsprozess, der so aussehen wird:

    appb 06

B.8. Kapitel 9

  1. Mindestens einer der Inputs muss eine Sequenznummer kleiner als ffffffff besitzen.

  2. Der Median der Timestamps der 11 Vorgängerblocks muss später sein als 2019-12-25 00:00:00.

  3. In den am weitesten rechts stehenden 16 Bits der Sequenznummer.

  4. Zwei Transaktionen auf jeder Blockchain: eine für die Vertragstransaktion und eine für die Swaptransaktion.

  5. Die Daten von Transaktionen mit ausgedachten PKHs müssen auf ewig im UTXO Set gespeichert werden, weil Bitcoin Nodes nicht zwischen echten und falschen PKHs unterscheiden können. Die Nodes können also nicht wissen, ob ein Output unbenutzbar ist oder nicht. Bei einem OP_RETURN Output weiss der Node, dass der Output unbenutzbar ist, und muss ihn daher nicht im UTXO Set mitführen.

  6. Wenn deine erste Transaktion eine zu kleine Fee bezahlt hat und im Zustand pending hängengeblieben ist. Du möchtest sie durch eine neue Transaktion ersetzen, die eine höhere Fee zahlt.

  7. Absolute Lock Time: eine Transaktion ist ungültig bis zu einer bestimmten Block Height oder Zeit. Relative Lock Time: ein Input einer Transaktion ist ungültig, bis der auszugebende Output seit einer bestimmten Anzahl Blocks oder einer bestimmten Zeit bestätigt, oder confirmed, ist.

  8. Das Redeem Script enthält zwei Code-Zweige. Der erste Zweig verlangt, dass du und Ruth signieren, um die 2 BTC auszugeben. Das kann jederzeit geschehen. Die 2 BTC mit dem anderen Zweig auszugeben verlangt, dass alle folgenden Bedingungen erfüllt sind:

    • Du hast bis Neujahr gewartet.

    • Beth hat die Transaktion signiert.

    • Du oder Ruth signieren die Transaktion.

    Um genau zu sein, können du und Ruth den ersten Zweig mit dem folgenden Signatur Script (ohne das Redeem Script) ausgeben:

    0 <your sig> <ruth sig> 1

    Der zweite Zweig kann frühestens an Neujahr ausgegeben werden mit

    0 <your or ruths sig> <beth sig> 0

    Die äusserst rechte Ziffer in diesen Signatur Scripts gibt an, welcher Zweig zu verwenden ist; der Rest erfüllt die Voraussetzungen des jeweiligen Zweiges.

    Der time-locked Zweig stellt sicher, dass Beth keine Möglichkeit hat, mit dir oder Ruth vor Neujahr zu kollaborieren.

  9. Nein. Das Redeem Script kennen die Nodes erst, wenn der Output ausgegeben wird. Und weil man ein OP_RETURN Redeem Script nicht ausgeben kann, werden die Nodes das Redeem Script nie sehen. Die Nodes werden daher nie feststellen können, dass es ein unbenutzbarer Output ist.

  10. Ein Full Node, der eine Transaktion bekommt, behält diese im Speicher, bis sie in einen Block eingebaut wird. Kommt eine zweite Transaktion herein, die mit der bereits vorhandenen Transaktion in Konflikt steht, lässt der Node die zweite Transaktion fallen und leitet sie nicht weiter. Er betrachtet die zuerst gesehene Transaktion als die “echte” und die zweite als einen Double-Spend Versuch. Nodes (einschliesslich Miner) müssen dieser Policy nicht folgen, weil es nur eine Policy ist.

  11. Miner können immer wählen, welche gültigen Transaktionen sie in ihren Block tun wollen. Daher sind alle Transaktionen irgendwie ersetzbar. Ein Miner kann Ersetzen als Service anbieten–das heisst, du lädst eine Double-Spend Transaktion mit einer hohen Fee über die Webseite des Miners hoch und lässt ihn die Transaktion im nächsten Block bestätigen, den er gewinnt.

    Es ist natürlich einfacher für normale Benutzer, eine Transaktion zu ersetzen, die für Opt-in-RBF markiert ist. Aber Dienste wie den oben erwähnten zu benutzen, ist für einen motivierten Dieb einfach genug. Der Unterschied in der Sicherheit ist also nicht so gross, wie du vielleicht denkst.

B.9. Kapitel 10

  1. Die Signatur Scripts

  2. Eine Transaktion T2, die den Output einer unbestätigten Transaktion T1 ausgibt, kann ungültig werden, wenn T1 während des Sendens zu T1M abgeändert wird und T1M bestätigt wird. Das verursacht eine Menge Kopfzerbrechen bei Verträgen.

  3. Die Zeit, eine herkömmliche Transaktion zu verifizieren, wächst um das Vierfache, wenn sich die Anzahl Inputs verdoppelt. Das liegt an folgendem

    • Du musst doppelt so viele Signaturen verifizieren.

    • Jede Signatur braucht die doppelte Zeit zum Verifizieren, weil die zu hashende Transaktion sich in der Grösse verdoppelt hat.

  4. Um zu verifizieren, dass die Transaktion in einem Block enthalten ist, muss das Lightweight Wallet die txid der Transaktion berechnen. Dafür braucht das Wallet die Signaturen, denn diese sind in der txid enthalten.

  5. Das neue Verhalten von OP_NOP5 muss im Erfolgsfalle genau das alte Verhalten von OP_NOP5 nachbilden. Ds heisst, es sollte keinen Effekt auf den Stack haben, wenn es erfolgreich ist.

  6. a (p2wpkh) und c (p2wsh) sind SegWit Adressen. d ist eine p2sh Adresse, aber es könnte eine eingebettete p2wpkh oder p2wsh Zahlung im Redeem Script enthalten. Das können wir nicht mit Sicherheit sagen. Aber die Adresse ist eine p2sh Adresse, keine SegWit Adresse.

  7. Die Witness Version dient der Vereinfachung von künftigen Upgrades. Die Regel ist, dass unbekannte Witness Versionen akzeptiert werden. Wenn eine neue Witness Version ausgerollt wird, akzeptieren alte Nodes alle Zahlungen, die Outputs mit dieser neuen Witness Version ausgeben. Das verhindert, dass alte und neue Nodes unterschiedlichen Zweigen der Blockchain folgen.

  8. Alle Datenelemente im Signatur Script werden auf den Stack gelegt. Das Signatur Script enthält keine solchen Elemente, sodass hier nichts zu tun ist. Dann wird 00 auf den Stack gelegt, gefolgt von c805…cba8. Das Script Programm ist dann zu Ende, und das oberste Element auf dem Stack wird geprüft. Es ist nicht Null, was bedeutet, die Zahlung ist gültig.

  9. Der neue Node wird merken, dass der Output dem SegWit Muster entspricht. Er wird ausserdem merken, dass die Witness Version 00 ist und das das Witness Programm 20 Bytes lang ist. Das bedeutet, es ist ein p2wpkh Output. Um einen solchen Output auszugeben, muss das Signatur Script leer sein, und der Witness muss genau eine Signatur und das zum Witness Programm passende Pubkey Script PKHY enthalten. Die p2wpkh Schablone wird mit der Signatur und dem public Key aus dem Witness Feld sowie mit dem PKH aus dem Pubkey Script (dem Witness Programm) ausgefüllt. Die ausgefüllte Schablone wird dann normal als Script Programm gestartet.

  10. Der Fee Merkle Root kann in den rechten Zweig unter das Witness Commitment gehängt werden. Aber du musst den Fee Merkle Root auch in den Witness für den Coinbase Input einbetten, sodass alte SegWit Nodes den Witness Root Hash verifizieren können.

  11. Ein alter SegWit Node wird den Block genau wie vorher verifizieren. Der Reservierte Witness Wert wird dem Witness im Coinbase Input entnommen. Mit dem Hash aus dem Witness kann der alte Node das Witness Commitment bauen und mit dem Hash im OP_RETURN Output vergleichen, aber er kann nicht feststellen, ob der Reservierte Witness Wert ein Merkle Root ist. Alte Nodes werden daher den Merkle Tree nicht verifizieren können.

    Ein neuer Node führt dieselbe Verifikation durch wie ein alter, wird aber zusätzlich den Fee Merkle Root berechnen und mit dem Hash im Coinbase Witness vergleichen.

B.10. Kapitel 11

  1. Ein Soft Fork engt die Konsensregeln ein. Das bedeutet, von Bitcoin NEU Nodes erzeugte Blocks werden von Bitcoin ALT Nodes garantiert akzeptiert.

  2.  

    1. Der NEU Zweig wird vom ALT Zweig ausgelöscht.

    2. Er wird irgendwann ausgelöscht, wenn der ALT Zweig zum NEU Zweig aufholt und ihn überholt. Das kann eine ganze Menge Blocks dauern, je nach dem initialen Defizit.

    3. Bitcoin NEU könnte mit Wipeout Protection ausgerüstet werden–zum Beispiel durch erzwungene Eigenschaften des ersten Blocks im Split, die in der ALT Chain nicht gültig sind. Bitcoin Cash verlangte zum Beispiel, dass der erste Block > 1.000.000 Bytes ist.

  3. Nein, er wird vom NEU Zweig überwältigt und der ALT Zweig wird ziemlich schnell ausgelöscht oder reorganisiert werden.

  4. 2.016 Blocks. Der LOCKED_IN Zustand dauert immer eine Retarget Periode.

  5. Beide. ALT Nodes können einen Block erzeugen, der gemäss der NEU Regeln nicht gültig ist. Umgekehrt können NEU Nodes einen Block erzeugen, der auf den ALT Nodes nicht gültig ist.

  6. Wenn die NEU Nodes keine Mehrheit der Hashrate haben, können die ALT Nodes einen dauerhaften Blockchain Split verursachen. Das würde im Effekt zu zwei Kryptowährungen führen.

  7. Replay Protection ist wünschenswert, weil eine für einen Zweig des Splits gedachte Transaktion nicht Gefahr laufen sollte, auf dem anderen Zweig zu enden.

  8. Ja. Angenommen, die 11 Timestamps vor B1, nach Wert sortiert, lauten

    a ≤ b ≤ c ≤ d ≤ e ≤ MTP1 ≤ g ≤ h ≤ i ≤ j ≤ k

    Um MTP2 von Block B2, der auf B1 folgt, zu berechnen, fügt man T1 dieser Liste hinzu. Weil der Timestamp eines Blocks strikt hinter der MTP des Blocks liegen muss, muss T1 in der Liste rechts von MTP1 einsortiert werden. Zum Beispiel:

    a ≤ b ≤ c ≤ d ≤ e ≤ MTP1 ≤ g ≤ h ≤ T1 ≤ i ≤ j ≤ k

    Man muss ausserdem den Timestamp des Blocks mit der niedrigsten Height aus der Liste der Timestamps entfernen. Egal welchen Timestamp man entfernt, MTP2 wird entweder MTP1 sein (wenn man einen Timestamp rechts davon entfernt), oder der Timestamp direkt rechts von MTP1 (wenn man einen Timestamp links davon entfernt) was entweder g oder T1 sein kann:

    Wenn MTP2 = MTP1, dann MTP2 < Timeout weil MTP1 < Timeout.

    Wenn MTP2 = g, dann MTP2 ≤ T1 < Timeout.

    Wenn MTP2 = T1, dann MTP2 < Timeout weil T1 < Timeout.

    Die MTP von B2 ist also in jedem Falle kleiner als der Timeout, und alle Blocks (>95%) der letzten 2.016 Blocks signalisieren Support, was bedeutet, das Deployment geht in LOCKED_IN über und—2.016 Blocks später—in ACTIVE.

  9. Ein Teil (<30%) der Wirtschaft beginnt, Blocks abzulehnen, die nicht den Regeln deines Soft Forks folgen. Das bedeutet, du verursachst einen Blockchain Split, der so lange bleibt, wie die Mehrheit der Miner den ALT Zweig unterstützt.

  10. Wenn der Grossteil der Wirtschaft anfängt, ALT Blocks abzulehnen, werden Miner wahrscheinlich nicht weiter ALT Blocks minen, denn die Block Rewards werden fast wertlos. Es wäre schwer für die Miner, ihre ALT Coins auf einer Exchange zu verkaufen oder ihren Strom damit zu bezahlen. Schwenken sie ihre Produktion dagegen auf NEU Blocks über, haben sie eine Menge Optionen, ihre Block Rewards gegen Güter, Dienstleistungen und andere Währungen einzutauschen.

  11. Die nicht minenden Benutzer, die die ALT Software benutzen, werden automatisch auf den NEU Zweig schwenken, sobald dieser stärker ist als der ALT Zweig. Das kommt daher, dass der NEU Zweig gemäss den ALT Regeln gültig ist.