Dezentralisierung Schritt fr Schritt zum BitcoinProtokollDesign Inhaltsverzeichnis 1

Dezentralisierung Schritt für Schritt zum Bitcoin-Protokoll-Design

Inhaltsverzeichnis 1. 2. 3. 4. 5. Bank. Coin Naive. Coin Serial. Number. Coin Signature. Chain. Coin Public. Announcement. Coin 6. Election. Coin 7. Proof-of-Work-Coin 8. Blockchain. Coin 9. Difficulty. Adjustment. Coin 10. Bitcoin

Bank. Coin Alice 1. 0 Coin an Bob Charlie Kontostände Alice: 3. 0 4. 0 Bob: 2. 0 3. 0 Charlie: 5. 0 Bob

Bank. Coin Regeln Problem • Die Bank verwaltet die Kontostände • Die Bank akzeptiert alle validen Transaktionen und aktualisiert die Kontostände • Jeder sendet Transaktionen an die Bank • Die Bank kann Transaktionen zensieren, Geld erzeugen, Zugriff auf Konten verweigern, Kontostände manipulieren, das Transaktionsgeheimnis brechen etc.

Bank. Coin Frage Könnten wir ein Protokoll designen, dass ohne einer zentralen Stelle auskommt und wenn ja, wer würde die Kontostände verwalten?

Inhaltsverzeichnis 1. 2. 3. 4. 5. Bank. Coin Naive. Coin Serial. Number. Coin Signature. Chain. Coin Public. Announcement. Coin 6. Election. Coin 7. Proof-of-Work-Coin 8. Blockchain. Coin 9. Difficulty. Adjustment. Coin 10. Bitcoin

Naive. Coin Regeln • Jeder Teilnehmer im Netzwerk (Node) hat eine Kopie der Kontostände. • Jeder Node akzeptiert alle validen Transaktionen die er bekommt und aktualisiert seine Kontostände. • Transaktionen werden an alle Nodes verteilt (broadcastet).

Naive. Coin Alice 1. 0 Coin an Bob Kontostände 4. 0 Alice: 3. 0 2. 0 Bob: 3. 0 Charlie: 5. 0 1. 0 Coin an Bob Charlie Kontostände 3. 0 Alice: 4. 0 3. 0 Bob: 2. 0 Charlie: 5. 0

Naive. Coin Fragen • Kann eine einzelne Partei nun Geld erzeugen? • Kann eine einzelne Partei eine Transaktion zensieren? • Kann eine einzelne Partei Geld stehlen?

Naive. Coin Problem: Replay-Attacke • Bob könnte Alice‘s Nachricht (1. 0 Coin an Bob) mit der dazugehörigen Signatur, die Alice mit ihrem Private Key signiert hat, nehmen, und nochmals an alle Nodes senden, solange, bis Alice‘s Kontostand leer ist.

Naive. Coin Alice Kontostände Alice: 0. 0 3. 0 1. 0 2. 0 Bob: 3. 0 5. 0 6. 0 4. 0 Charlie: 5. 0 1. 0 Coin an Bob Charlie Kontostände Alice: 0. 0 1. 0 2. 0 3. 0 Bob: 5. 0 6. 0 4. 0 3. 0 Charlie: 5. 0 Kontostände 3. 0 Alice: 0. 0 1. 0 2. 0 3. 0 Bob: 5. 0 6. 0 4. 0 Charlie: 5. 0

Naive. Coin Mögliche Lösung Was wäre, wenn man die Coins mit Seriennummern ausstatten würde, die signiert werden müssten um somit eine Replay-Attacke zu verhindern?

Inhaltsverzeichnis 1. 2. 3. 4. 5. Bank. Coin Naive. Coin Serial. Number. Coin Signature. Chain. Coin Public. Announcement. Coin 6. Election. Coin 7. Proof-of-Work-Coin 8. Blockchain. Coin 9. Difficulty. Adjustment. Coin 10. Bitcoin

Serial. Number. Coin Regeln • Jeder Coin hat eine Seriennummer. • Jede Wallet eines Nodes speichert jetzt eine Liste von Seriennummern, anstatt die Geldbeträge selber.

Serial. Number. Coin Alice SX 1 Coin an Bob Kontostände SX 1, … Alice: … … Bob: SX 1, … Charlie: … Bob Kontostände Alice: SX 1, … … Bob: … SX 1, … Charlie: … SX 1 Coin an Bob Charlie Kontostände Alice: … SX 1, … Bob: SX 1, … … Charlie: …

Serial. Number. Coin Bob kann nun keine Replay-Attacke auf die Transaktion von Alice anwenden, da sie den Coin nicht mehr hat. Ist das Protokoll jetzt also sicher?

Serial. Number. Coin Antwort: Nein! Bob kann immer noch eine Replay-Attacke auf Alice starten, nämlich, falls der Coin mit der Seriennummer SX 1 später wieder bei Alice landet. Wie könnte man es also sonst machen?

Serial. Number. Coin Möglicher Lösungsansatz Was wäre, wenn wir den Coin an die Transaktion selber binden und die digitale Signatur gerade nur für diese Transaktion gültig ist, in der sich der Coin befindet. Diese Transaktion ist dann der Coin der nächsten Transaktion, die erstellt wird. Somit ergibt sich eine Kette von Transaktionen, was wiederum eine Kette von Signaturen zur Folge hat.

Inhaltsverzeichnis 1. 2. 3. 4. 5. Bank. Coin Naive. Coin Serial. Number. Coin Signature. Chain. Coin Public. Announcement. Coin 6. Election. Coin 7. Proof-of-Work-Coin 8. Blockchain. Coin 9. Difficulty. Adjustment. Coin 10. Bitcoin

Signature. Chain. Coin Regeln • Wir definieren einen Coin nun als: Transaktion, die den Coin transferiert hat. • Jede Wallet eines Nodes speichert nun eine Liste von Coins, anstatt von Seriennummern.

Signature. Chain. Coin Beispiel Alice besitzt den Coin x 0 und sendet ihn an Bob: x 1 = „Ich, Alice, sende den Coin x 0 an Bob“ Bob sendet den Coin x 1 nun an Charlie: x 2 = „Ich, Bob, sende den Coin x 1 an Charlie“ oder ausgeschrieben: x 2 = „Ich, Bob, sende den Coin (Ich, Alice, sende den Coin x 0 an Bob) an Charlie“

Signature. Chain. Coin Kontostände Alice: …x 30, … Bob: …… x 1, … Charlie: x…… 2, … Alice Kontostände Alice: … xx… 03, … Bob: …… x 1, … Charlie: …… x 2, … Coin x 2 an Alice Bob Coin x 2 an Alice Charlie Kontostände Alice: …x 30, … Bob: …… x 1, … Charlie: x…… 2, …

Signature. Chain. Coin Fazit • Bob wird es nicht mehr möglich sein, eine Replay-Attacke auf Alice zu starten, da Alice den Coin x 0 nie mehr haben wird. • Dieses Protokoll ist also sicher, ausser für ein Problem… Problem • Die Double-Spending-Attacke

Double-Spending-Attacke Alice Kontostände Alice: x… 0, … Bob: … x. B, … Charlie: … x. C, … Coin x 0 an Bob Kontostände Alice: x 0, … … Bob: x…B, … Charlie: x…C, … Bob Coin x 0 an Charlie Kontostände Alice: … x 0, … Bob: x…B, … Charlie: x…C, …

Double-Spending-Attacke Problem • Bob und Charlie denken nun, dass sie je ein Coin von Alice erhalten haben. • Das gemeine ist aber, falls z. B. Bob Charlie bezahlt, würde der Schwindel auffliegen, da beide denselben Coin x 0 referenzieren, wenn sie ihn ausgeben wollen. Sie würden sich gegenseitig die Transaktion verweigern.

Double-Spending-Attacke Das Problem wie diese Attacke vermieden wird, nennt sich das Double. Spending-Problem, das bis zum Jahr 2008 nicht gelöst wurde. Eine neue Revolution in der Informationstechnologie hat mit der Lancierung und Umsetzung des Bitcoin-Whitepapers durch Satoshi Nakamoto angefangen. Gut, wie lösen wir das nun genau?

Double-Spending-Attacke Lösungsansatz Was wäre, wenn man die Möglichkeit hätte, eine Nachricht so ins Netzwerk zu schicken, dass jeder dieselbe Nachricht bekommt. Eine Art öffentliche Ankündigung, also ein „public announcement“ auf Englisch.

Inhaltsverzeichnis 1. 2. 3. 4. 5. Bank. Coin Naive. Coin Serial. Number. Coin Signature. Chain. Coin Public. Announcement. Coin 6. Election. Coin 7. Proof-of-Work-Coin 8. Blockchain. Coin 9. Difficulty. Adjustment. Coin 10. Bitcoin

Public. Announcement. Coin Public Announcements • Eine öffentliche Ankündigung ist eine Nachricht, sodass jeder Teilnehmer im Netzwerk sichergehen kann, dass jeder andere Teilnehmer diese ebenfalls erhalten hat. • Das ist nicht einfach eine Nachricht die an alle gesendet wurde: Wenn du die Nachricht erhalten hast, weisst du nicht, ob jemand anders diese auch erhalten hat!

Public. Announcement. Coin Beispiel Ich habe die Nachricht „Die Klausur ist nächsten Freitag“. Frage Sind die folgenden Wege wirklich öffentliche Ankündigungen? • Ich sende die Nachricht allen via E-Mail • Ich stelle die Nachricht auf einen öffentliche Webseite die alle Teilnehmer kennen • Ich sage die Nachricht allen im Klassenzimmer

Public. Announcement. Coin Regeln • Anstatt einfach eine Transaktion jedem einzeln zu senden, wird sie öffentlich angekündigt. • Jeder Node im Netzwerk akzeptiert nur noch Transaktionen, die öffentlich angekündigt wurden. Das löst das Double-Spending Problem: • Bob wird keine Transaktion mehr akzeptieren, die Charlie nicht auch erhalten hat. Problem • Wie implementieren wir eine öffentliche Ankündigung im Internet?

Public. Announcement. Coin Lösungsansatz Wir bräuchten eine Art zentrale Instanz, welche diese öffentlichen Ankündigungen macht. Wir wollen aber keinem Node im Netzwerk zu viel Macht geben. Was wäre, wenn wir einfach ab und zu einen Leader (Führer) wählen, der die öffentlichen Ankündigungen macht? Der sollte aber zufällig gewählt werden, dass alle im Netzwerk eine Chance hätten. Eine Art Election (eine Wahl von Leadern).

Inhaltsverzeichnis 1. 2. 3. 4. 5. Bank. Coin Naive. Coin Serial. Number. Coin Signature. Chain. Coin Public. Announcement. Coin 6. Election. Coin 7. Proof-of-Work-Coin 8. Blockchain. Coin 9. Difficulty. Adjustment. Coin 10. Bitcoin

Election. Coin Regeln Jeder Node speichert alle erhaltenen, gültigen Transaktionen in seinem eigenen Transaktionspool (auch Mempool genannt, ja, jeder Node hat seinen eigenen Mempool) Alle Nodes wählen einen Leader nach dem Zufallsprinzip aus. Der Leader broadcastet seinen Transaktionspool (Mempool) an alle anderen Nodes im Netzwerk Jeder Node validiert den Transaktionspool des Leaders und aktualisiert seinen eigenen Ledger dementsprechend (und verwirft seinen eigenen Transaktionspool)

Election. Coin x 0 an Bob Alice Juhu! Ich wurde als Leader gewählt. Ich werde jetzt meinen Tx Pool broadcasten. Bob Coin x 0 an Charlie Kontostände Alice: … x 0, … Bob: x…B, … Charlie: … Tx Pool: … x. B, … Kontostände Alice: … x 0, … Bob: x…B, … Charlie: … Tx Pool: … x. C, …

Election. Coin Problem • Wie wählt man einen Leader? • Traditionelle Protokolle sind anfällig für Sybil-Attacken. Sybil-Attacke • Ist eine Attacke auf ein Peer-to-Peer Netzwerk, indem der Angreifer mehrere falsche Identitäten erstellt, um eine Mehrheitsabstimmung zu beeinflussen. • Wahrscheinlichkeit ist also grösser, dass der Angreifer zum Leader gewählt würde.

Election. Coin Lösungsansatz Es muss deshalb irgendwie ein Mechanismus her, wo der Angreifer eine Art ökonomischen Aufwand betreiben muss und somit in seinem Handeln limitiert wird. Der Angreifer müsste einen Beweis dafür geben, dass er Arbeit geleistet hat, um seinen Tx Pool broadcasten zu dürfen, also einen Proof-of-Work.

Inhaltsverzeichnis 1. 2. 3. 4. 5. Bank. Coin Naive. Coin Serial. Number. Coin Signature. Chain. Coin Public. Announcement. Coin 6. Election. Coin 7. Proof-of-Work-Coin 8. Blockchain. Coin 9. Difficulty. Adjustment. Coin 10. Incentive. Coin

Proof-of-Work-Coin-Protokoll Regeln • Alle Nodes arbeiten an einem Hashcash Puzzle • Der Node, der das Puzzle zuerst löst, wird der Leader sein • Der Node broadcasted (öffentlich ankündigen) seinen Tx Pool zusammen mit der Puzzle Lösung im Netzwerk • Ein Node akzeptiert die Tx Pool nur, wenn er die Puzzle Lösung verifizieren kann.

Proof-of-Work-Coin Erkenntnis Durch Proof-of-Work wird nicht mehr eine Stimme pro Node, sondern eine Stimme pro CPU-Rechenkapazität vergeben und somit werden Sybil. Attacken sehr erschwert werden. Problem: Inkonsistenz Was, wenn zwei Puzzle-Lösungen von zwei unterschiedlichen Nodes zur selben Zeit gefunden werden?

Netzwerk Inkonsistenz Ich habe eine Lösung gefunden. Werde meinen Tx Pool jetzt zusammen mit der Lösung broadcasten!

Inhaltsverzeichnis 1. 2. 3. 4. 5. Bank. Coin Naive. Coin Serial. Number. Coin Signature. Chain. Coin Public. Announcement. Coin 6. Election. Coin 7. Proof-of-Work-Coin 8. Blockchain. Coin 9. Difficulty. Adjustment. Coin 10. Bitcoin

Blockchain. Coin Die Regeln für das Blockchain. Coin-Protokoll sind dieselben wie beim Proof-of-Work-Coin, nur, dass der Leader jetzt einen Block ins Netzwerk broadcastet, der folgende Daten enthält: • Den Transaktionspool (Tx Pool) • Die Puzzle-Lösung (auch Nonce genannt) • Den Hashwert des vorherigen Blocks

Blockchain. Coin Das Blockchain. Coin Puzzle Gegeben ist der Transaktionspool (txp) und der Hashwert des vorherigen Blocks (prev. Hash). Finde nun eine Nonce (eine Zahl), sodass der resultierende Block Hash mit einer gewissen Anzahl Nullen beginnt: hash(txp ‖ prev. Hash ‖ nonce)

Blockchain. Coin 3377 3 1 3 kk ##1 c c o l o BBl ooll o P o -- TTxx P Haasshh eevv. H (67345)) r p r -- p cee (12 oonnc -- N N SHA-256 B I N G O Hash: dac 7 a 234 d 0 a 6274969 e 0425289532 ac 7275 c 7 a 547 ce 9 c 0 cf 1 ff 40 b 18 cd 82092 c

Blockchain. Coin Block #1334 - Tx Pool - prev. Hash - Nonce (18) Block #1335 - Tx Pool - prev. Hash - Nonce (9) Block #1336 - Tx Pool - prev. Hash - Nonce (11) Block #1337 - Tx Pool - prev. Hash - Nonce (7) So entsteht dann eine Kette von Datenblöcken, eine Hash. Linked-List als Datenstruktur, was ein wesentlicher Bestandteil einer Blockchain ist.

Blockchain. Coin Zusätzliche Regeln für das Blockchain. Coin-Protokoll • Jeder Node validiert und speichert alle Blöcke, die er bekommt. • Diese Blöcke sind mit dem Hash des jeweilig vorhergehenden Blocks verknüpft und formen eine Baumstruktur. • Jeder Node arbeitet nur an Puzzle-Lösungen, wo die längere Blockkette gebildet wurde (der Node akzeptiert also implizit die längere Kette als die richtige Kette)

Blockchain. Coin Alice und Bob haben nun beide gleichzeitig einen Block gefunden. Es kommt zu einem kurzfristigen Fork (Vergabelung) in der Blockchian. Alice Block #1337 Block #1334 Block #1335 Block #1336 Block #1337 Bob

Blockchain. Coin Das rote Netzwerk, das Alice umgibt, wird jetzt an der Kette von Alice weiter rechnen, während das blaue Netzwerk an Bobs Kette weiterrechnet. Alice Block #1337 Block #1334 Block #1335 Block #1336 Block #1337 Bob

Blockchain. Coin Jetzt hat jemand aus Bobs Netzwerk schneller einen Block gefunden als jemand aus Alice‘s Netzwerk. Derjenige fügt deshalb den Block an Bobs Blockchain an. Alice Block #1337 Block #1334 Block #1335 Block #1336 Block #1337 Block #1338 Bob

Blockchain. Coin Nun erkennen die Nodes aus Alice‘s Netzwerk, dass es eine längere Blockchain irgendwo im Netzwerk gibt. Alle Nodes wechseln deshalb sofort auf die längere Kette und rechnen dort am Block #1339 weiter. Alice Bob Block #1337 Block #1334 Block #1335 Block #1336 Block #1337 Block #1338 Block #1339

Blockchain. Coin Währenddessen wird der ursprüngliche Block #1137 von Alice zu einem sogenannten orphan block, also ein Weisenkind. Dieser Block wird von den anderen Nodes verworfen und ist nicht mehr Teil der korrekten Blockchain. Alice Bob Block #1337 Block #1334 Block #1335 Block #1336 Block #1337 Block #1338 Block #1339

Blockchain. Coin Block Propagierungszeit (Ausbreitungszeit) Die Blockpropagierungszeit ist die Differenz zwischen dem ein neuer Block errechnet wurde und der Zeit bis der Block dem gesamten Netzwerk bekannt ist. Diese Zeit ist abhängig von der Blockgrösse und der Internet-Infrastruktur und beträgt ca. 15 Sekunden. Zwischen-Block-Zeit Die Zwischen-Block-Zeit wird durch den Schwierigkeitsgrad der Puzzle-Lösung bestimmt und wird auf 10 Minuten festgelegt. Somit sollte es seltener vorkommen, dass zwei Blöcke zur selben Zeit gefunden werden und dadurch Blockchain-Forks seltener vorkommen.

Blockchain. Coin Anzahl Blockbestätigungen Zero-Conf Transaktionen • Eine Transaktion hat eine gewisse Anzahl von Bestätigungen (Confirmations). Sobald eine Transaktion in einem Block ist, hat sie 1 Bestätigung. • Eine Transaktion die sich erst im Transaktionspool (0 Bestätigungen), aber nicht in einem Block befindet, ist anfälliger gegen Double-Spending-Attacken. • Je höher die Anzahl Bestätigungen, desto geringer die Wahrscheinlichkeit, dass die Transaktion rückgängig gemacht werden kann. • Das mag aber Okay sein, wenn man dem Sender vertraut. Bestätigungen: Tx Pool x 1 x 2 x 3 x 4 x 5 Block #1334 Block #1335 0 1 2 Block #1336 3

Blockchain. Coin Problem gelöst • Die Wahrscheinlichkeit einer erfolgreichen Double-Spending-Attacke sinkt exponentiell, je mehr Bestätigungen eine Transaktion erhält • In Blockchain. Coin verwerfen wir nun die Annahme eines ehrlichen Leaders und ersetzen es mit der Annahme, dass: 1. Nodes genügend Bestätigungen abwarten, bevor sie eine Transaktion akzeptieren. 2. Niemand die Kontrolle von mehr als 50 % der Rechenkapazität des Netzwerks hat. Nächstes Problem Die Rechenkapazität des Netzwerks ändert sich ständig (in der Regel steigend). Lösungsansatz Wir müssten eine Art Schwierigkeitsanpassungsmechanismus einführen.

Inhaltsverzeichnis 1. 2. 3. 4. 5. Bank. Coin Naive. Coin Serial. Number. Coin Signature. Chain. Coin Public. Announcement. Coin 6. Election. Coin 7. Proof-of-Work-Coin 8. Blockchain. Coin 9. Difficulty. Adjustment. Coin 10. Bitcoin

Difficulty. Adjustment. Coin Problem Das Netzwerk muss abhängig von der Rechenkapazität den Puzzle. Schwierigkeitsgrad anpassen können. Aber wie misst das Netzwerk die Rechenleistung? Lösungsansatz Es könnte die Zeit messen, die das Netzwerk benötigt, um eine gewisse Anzahl Blöcke zu berechnen. Frage Wie wird aber die Zeit in einem dezentralen Netzwerk gemessen? Vergesst nicht, dass das Netzwerk mit dem Schwierigkeitsgrad im Konsens sein muss, andernfalls splittet sich das Netzwerk.

Difficulty. Adjustment. Coin Regeln Der Block ist aufgebaut wie in Blockchain. Coin, beinhaltet jetzt aber zusätzlich noch einen Timestamp. alt Block #1337 - Tx Pool - prev. Hash - Nonce (7) neu Block #1337 - Timestamp - Tx Pool - prev. Hash - Nonce (10)

Difficulty. Adjustment. Coin Das Difficulty. Adjustment. Coin Puzzle Gegeben ist der Transaktionspool (txp) der Hashwert des vorherigen Blocks (prev. Hash) und jetzt noch eine Zeitangabe (timestamp), wann der Block erstellt wurde. Finde nun eine Nonce (eine Zahl), sodass der resultierende Block Hash mit einer gewissen Anzahl Nullen beginnt: hash(prev. Hash ‖ txp ‖ timestamp ‖ nonce)

Difficulty. Adjustment. Coin Median-time-past: Ist der Median Timestamp von den letzten 11 Blöcken Network-adjusted-time: Ist die Median-Zeit von allen umgebenden Nodes eines Nodes, ausser diese Zeit weicht von der lokalen Zeit des Nodes um 70 Minuten ab, dann würde man die lokale Zeit +/70 Minuten nehmen. Block-Zeit-Regel • Ein Node akzeptiert Blöcke nur, wenn der Timestamp • grösser als der Median-time-past ist • kleiner als die Network-adjusted-time + 2 Stunden ist • Block-Zeiten können um mehrere Stunden falsch sein • Blöcke sind deshalb nicht immer chronologisch.

Difficulty. Adjustment. Coin Schwierigkeitsgrad Neuausrichtung Immer nach 2016 Blöcken, was ca. alle 2 Wochen sind, passt jeder Node im Netzwerk den Schwierigkeitsgrad des Hashcash-Puzzles an. Dabei schaut der Node die Timestamps der letzen 2016 Blöcke an: • Wenn die Blöcke weniger als 2 Wochen brauchten, um errechnet zu werden, steigt der Schwierigkeitsgrad. • Andernfalls wenn sie länger als 2 Wochen brauchten, sinkt der Schwierigkeitsgrad. Problem gelöst: Nun sind die Zwischen-Block-Zeiten halbwegs Konstant. Nächstes Problem: Was ist mit der 51%-Attacke. Wird das Netzwerk genug Hash-Power haben um sie zu verhindern?

Inhaltsverzeichnis 1. 2. 3. 4. 5. Bank. Coin Naive. Coin Serial. Number. Coin Signature. Chain. Coin Public. Announcement. Coin 6. Election. Coin 7. Proof-of-Work-Coin 8. Blockchain. Coin 9. Difficulty. Adjustment. Coin 10. Bitcoin

Bitcoin Begriffserklärung 51%-Attacke Eine 51%-Attacke ist eine Attacke, wobei ein Node oder eine kooperierende Gruppe mehr als 50% der Hash-Power des gesamten Netzwerks besitzt. Mit dieser Macht könnte der Angreifer die Geschichte und Zukunft der Bitcoin-Blockchain verändern. Der Angreifer könnte vermehrt Double-Spending- oder Denial-of-Service (Do. S) Attacken ausführen. Mit Do. S-Attacken kann zum Beispiel das Zensieren einer Transaktion möglich sein, wobei der Miner (Blockerzeuger) eine bestimmte Transaktion immer wieder verwirft und diese somit nie die Chance bekommt, in einen Block aufgenommen zu werden.

Bitcoin Beispiel – Double-Spending-Attacke Double Spending (Doppelte Ausgabe) bedeutet, dass ein Bitcoin zweimal ausgegeben wurde. Das passiert, wenn jemand eine Bitcoin-Transaktion tätigt und gleichzeitig den gleichen Bitcoin noch einmal kauft. Danach muss das Netzwerk davon überzeugt werden, nur eine Transaktion zu bestätigen, indem sie in einem Block gehasht wird. Double Spending ist aufgrund des intelligenten Bitcoin-Netzwerks nicht einfach und sehr riskant für diejenigen, die eine Transaktion ohne Bestätigung (Zero-Confirmation) akzeptieren. Hauptkette Who. Cares. Chain (Mainchain) Block #1334 Block #1335 Block #1336 Block #1337 Block #1338 Block #1339 Alice’s lokale Hauptkette Block #1334 Block #1335 Block #1336 Block #1337 Block #1338 Block #1339 Blockchain (Mainchain) Block #1340 Block #1341

Bitcoin Frage Wie können wir aber nun eine solche 51%-Attacke verhindern? Lösungsansatz Wir müssen etwas finden, dass den Minern einen Anreiz gibt, genügend Hash. Power aufzuwenden, um eine solche Attacke für einen Angreifer ökonomisch unrentabel zu machen. Lösung Wir schütten den Minern eine Belohnung aus wenn sie ein solches Hashcash-Puzzle gelöst haben, was bedeutet, dass sie hohe Energie- und Hardwarekosten hatten. Stichwort: Proof-of-Work.

Bitcoin-Protokoll Regeln • Jeder Block enthält neu eine Transaktion, die neue Bitcoins kreiert. • Diese Transaktion nennen wir coinbase transaction und die Bitcoins die daraus entstehen nennen wir block reward (Blockbelohnung). • Der block reward ist die einzige Möglichkeit, neue Bitcoins zu erschaffen. • Der Node, der einen neuen Block errechnet hat, integriert eine coinbase transaction, die den block reward an sich selber ausschüttet. Block Reward Plan • Die Anfangsbelohnung bei Bitcoin war 50 Coins pro Block. • Diese halbiert sich immer nach 210’ 000 Blöcken (ca. alle 4 Jahre) • Das heisst, im Jahr 2140 wird der letzte Bitcoin resp. Satoshi erschaffen worden sein. Nächstes Problem Der block reward wird es eines Tages nicht mehr geben, was wiederum Double. Spending-Attacken lohnenswert macht.

Bitcoin Lösung Transaktionsgebühren einführen. Erweiterte Bitcoin-Protokoll-Regeln • Jeder Transaktion können neu Transaktionsgebühren angehängt werden. • Die coinbase transaction beinhaltet jetzt nicht mehr nur den block reward, sondern auch noch die gesamten Transaktionsgebühren aller Transaktionen im Block. • Zusätzlich wird die Blockgrösse limitiert. Transaktionsgebühren • Nodes können nun anhand der Transaktionsgebühr wählen, ob sie eine Transaktion in einen Block aufnehmen möchten oder nicht. • Aufgrund der Blockgrössenlimitierung herrscht ein Gebühren-Druck.

Bitcoin Fazit Durch dieses Belohnungssystem werden 51%-Attacken sehr schwierig. Wir können sie zwar nicht vermeiden, aber wir können solche Angriffe sehr teuer und unrentabel für den Angreifer machen. Es wurde geschätzt, dass wenn ein Angreifer mit einer Hash-Power von 51% die ganze Bitcoin-Blockchain vom Genesis-Block (der erste Block) an versucht neu zu errechnen, Hardwarekosten von mehr als 9 Milliarden $ entstünden. Dazu kommt noch der tägliche Stromverbrauch von ca. 132 Millionen k. Wh, was ungefähr 7 Millionen $ pro Tag kosten würde.