Schritt für Schritt zum Bitcoin-Protokoll-Design

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

Inhaltsverzeichnis BankCoin NaiveCoin SerialNumberCoin
SignatureChainCoin PublicAnnouncementCoin ElectionCoin Proof-of-Work-Coin BlockchainCoin DifficultyAdjustmentCoin Bitcoin

BankCoin Alice Kontostände Alice: 4.0 Bob: 2.0 Charlie: 5.0 Charlie
1.0 Coin an Bob Kontostände Alice: 4.0 Bob: 2.0 Charlie: 5.0 Charlie Bob Kontostände Alice: 3.0 Bob: 3.0 Charlie: 5.0

BankCoin Die Bank verwaltet die Kontostände
BankCoin 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.

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

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

NaiveCoin Kontostände Alice: 4.0 Bob: 2.0 Charlie: 5.0 Alice Bob
1.0 Coin an Bob Kontostände Alice: 3.0 Bob: 3.0 Charlie: 5.0 Charlie Kontostände Alice: 4.0 Bob: 2.0 Charlie: 5.0 Kontostände Alice: 3.0 Bob: 3.0 Charlie: 5.0 1.0 Coin an Bob

NaiveCoin Fragen Kann eine einzelne Partei nun Geld erzeugen?
Kann eine einzelne Partei eine Transaktion zensieren? Kann eine einzelne Partei Geld stehlen?

NaiveCoin 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.

NaiveCoin Kontostände Alice: 3.0 Bob: 3.0 Charlie: 5.0 Alice Bob
1.0 Coin an Bob 1.0 Coin an Bob Kontostände Alice: 0.0 Bob: 6.0 Charlie: 5.0 Kontostände Alice: 1.0 Bob: 5.0 Charlie: 5.0 Kontostände Alice: 2.0 Bob: 4.0 Charlie: 5.0 Charlie Kontostände Alice: 3.0 Bob: 3.0 Charlie: 5.0 Kontostände Alice: 0.0 Bob: 6.0 Charlie: 5.0 Kontostände Alice: 2.0 Bob: 4.0 Charlie: 5.0 Kontostände Alice: 1.0 Bob: 5.0 Charlie: 5.0

NaiveCoin 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?

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

SerialNumberCoin Alice Kontostände Alice: SX1,… Bob: … Charlie: … Bob
Bob: SX1,… Charlie: … SX1 Coin an Bob Kontostände Alice: … Bob: SX1,… Charlie: … Charlie Kontostände Alice: SX1,… Bob: … Charlie: … Kontostände Alice: … Bob: SX1,… Charlie: … SX1 Coin an Bob

SerialNumberCoin 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?

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

SerialNumberCoin 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.

SignatureChainCoin SignatureChainCoin 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.

SignatureChainCoin Beispiel Alice besitzt den Coin x0 und sendet ihn an Bob: x1 = „Ich, Alice, sende den Coin x0 an Bob“ Bob sendet den Coin x1 nun an Charlie: x2 = „Ich, Bob, sende den Coin x1 an Charlie“ oder ausgeschrieben: x2 = „Ich, Bob, sende den Coin (Ich, Alice, sende den Coin x0 an Bob) an Charlie“

SignatureChainCoin Alice Kontostände Alice: x0,… Bob: … Charlie: … Bob
Charlie: x2,… Kontostände Alice: … Bob: x1,… Charlie: … Coin x2 an Alice Kontostände Alice: x3,… Bob: … Charlie: … Kontostände Alice: … Bob: … Charlie: x2,… Kontostände Alice: … Bob: x1,… Charlie: … Charlie Kontostände Alice: x0,… Bob: … Charlie: … Kontostände Alice: x3,… Bob: … Charlie: … Kontostände Alice: … Bob: x1,… Charlie: … Kontostände Alice: … Bob: … Charlie: x2,… Coin x2 an Alice

SignatureChainCoin Fazit
Bob wird es nicht mehr möglich sein, eine Replay-Attacke auf Alice zu starten, da Alice den Coin x0 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: x0,… Bob: … Charlie: … Bob Kontostände Alice: x0,… Bob: … Charlie: … Kontostände Alice: … Bob: xB,… Charlie: xC,… Coin x0 an Bob Coin x0 an Charlie Kontostände Alice: … Bob: xB,… Charlie: xC,… Charlie Kontostände Alice: x0,… Bob: … Charlie: … Kontostände Alice: … Bob: xB,… Charlie: xC,…

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 x0 referenzieren, wenn sie ihn ausgeben wollen. Sie würden sich gegenseitig die Transaktion verweigern.

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?

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.

PublicAnnouncementCoin
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!

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 Ich stelle die Nachricht auf einen öffentliche Webseite die alle Teilnehmer kennen Ich sage die Nachricht allen im Klassenzimmer

PublicAnnouncementCoin 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?

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

ElectionCoin ElectionCoin 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)

ElectionCoin Alice Bob Kontostände Alice: x0,… Bob: … Charlie: …
Tx Pool: … Kontostände Alice: … Bob: xB,… Charlie: … Tx Pool: … Kontostände Alice: x0,… Bob: … Charlie: … Tx Pool: xB,… Coin x0 an Bob Coin x0 an Charlie Juhu! Ich wurde als Leader gewählt. Ich werde jetzt meinen Tx Pool broadcasten. Charlie Kontostände Alice: x0,… Bob: … Charlie: … Tx Pool: … Kontostände Alice: … Bob: xB,… Charlie: … Tx Pool: … Kontostände Alice: x0,… Bob: … Charlie: … Tx Pool: xC,…

ElectionCoin 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.

ElectionCoin 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.

SignatureChainCoin PublicAnnouncementCoin ElectionCoin Proof-of-Work-Coin BlockchainCoin DifficultyAdjustmentCoin IncentiveCoin

Proof-of-Work-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! Ich habe eine Lösung gefunden. Werde meinen Tx Pool jetzt zusammen mit der Lösung broadcasten!

BlockchainCoin Die Regeln für das BlockchainCoin-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

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

Hash: dac7a234d0a6274969e0425289532ac7275c7a547ce9c0cf1ff40b18cd82092c
BlockchainCoin - Tx Pool - prevHash - Nonce (6) Block #1337 - Tx Pool - prevHash - Nonce (7) Block #1337 - Tx Pool - prevHash - Nonce (4) Block #1337 - Tx Pool - prevHash - Nonce (5) Block #1337 - Tx Pool - prevHash - Nonce (3) Block #1337 - Tx Pool - prevHash - Nonce (2) Block #1337 - Tx Pool - prevHash - Nonce (1) Block #1337 SHA-256 BINGO Hash: dac7a234d0a e ac7275c7a547ce9c0cf1ff40b18cd82092c

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

BlockchainCoin Zusätzliche Regeln für das BlockchainCoin-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)

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

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

BlockchainCoin Alice Bob 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. Block #1337 Block #1334 Block #1335 Block #1336 Block #1337 Block #1338

BlockchainCoin Alice Bob 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. Block #1337 Block #1334 Block #1335 Block #1336 Block #1337 Block #1338 Block #1339

BlockchainCoin Alice Bob 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. Block #1337 Block #1334 Block #1335 Block #1336 Block #1337 Block #1338 Block #1339

BlockchainCoin 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.

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

BlockchainCoin Problem gelöst
Die Wahrscheinlichkeit einer erfolgreichen Double-Spending-Attacke sinkt exponentiell, je mehr Bestätigungen eine Transaktion erhält In BlockchainCoin verwerfen wir nun die Annahme eines ehrlichen Leaders und ersetzen es mit der Annahme, dass: Nodes genügend Bestätigungen abwarten, bevor sie eine Transaktion akzeptieren. 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.

DifficultyAdjustmentCoin
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.

DifficultyAdjustmentCoin Regeln Der Block ist aufgebaut wie in BlockchainCoin, beinhaltet jetzt aber zusätzlich noch einen Timestamp. - Tx Pool - prevHash - Nonce (7) Block #1337 - Timestamp - Nonce (10) alt neu

Das DifficultyAdjustmentCoin Puzzle Gegeben ist ist der Transaktionspool (txp) der Hashwert des vorherigen Blocks (prevHash) 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(prevHash ‖ txp ‖ timestamp ‖ nonce)

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 +/ 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 Stunden ist Block-Zeiten können um mehrere Stunden falsch sein Blöcke sind deshalb nicht immer chronologisch.

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 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?

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 (DoS) Attacken ausführen. Mit DoS-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.

Hauptkette (Mainchain)
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. Block #1335 Block #1334 Hauptkette (Mainchain) WhoCaresChain Block #1336 Block #1336 Block #1337 Block #1337 Block #1338 Block #1338 Block #1339 Block #1339 Hauptkette (Mainchain) Alice’s lokale Blockchain Block #1334 Block #1335 Block #1335 Block #1336 Block #1336 Block #1336 Block #1337 Block #1337 Block #1337 Block #1338 Block #1338 Block #1338 Block #1339 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 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 kWh, was ungefähr 7 Millionen $ pro Tag kosten würde.

Schritt für Schritt zum Bitcoin-Protokoll-Design

Ähnliche Präsentationen

Präsentation zum Thema: "Schritt für Schritt zum Bitcoin-Protokoll-Design"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Schritt für Schritt zum Bitcoin-Protokoll-Design

Ähnliche Präsentationen

Präsentation zum Thema: "Schritt für Schritt zum Bitcoin-Protokoll-Design"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback