Teil 1: Grundlagen — Krypto-Bausteine & Transaktionen
Verteilte Systeme — Vorlesung 4
Prof. Dr. Alexandra Mikityuk · HTW Berlin · Sommersemester 2026
Bitcoin ist nicht nur „Internet-Geld" — es ist das vollständigste real laufende Beispiel für ein verteiltes System mit echtem Vertrauensproblem.
Mehrere Parteien ohne zentrale Autorität müssen sich auf denselben Zustand einigen — trotz böswilliger Akteure und unzuverlässigem Netzwerk.
Konsens ohne Vertrauen — durch Kryptografie (Hashing, Signaturen), Proof of Work und ein P2P-Protokoll. Seit 2009 ohne Ausfall in Betrieb.
Wie kryptografische Primitiven, ökonomische Anreize und Netzwerk-Protokolle zusammenspielen, um Byzantine Fault Tolerance in der Praxis zu erreichen.
Heute legen wir das Fundament — die kryptografischen Werkzeuge, ohne die nichts in Bitcoin funktioniert.
Ein öffentliches Kassenbuch, das von tausenden Computern weltweit gleichzeitig geführt wird — und dem alle vertrauen können, ohne dass sie sich untereinander vertrauen müssen.
Jede Transaktion seit 2009 — wer hat wem wieviel überwiesen — steht drin. Öffentlich, jeder kann es lesen.
Es gibt nicht ein Kassenbuch — es gibt eine Kopie auf jedem teilnehmenden Computer (~17.000 sogenannte „Full Nodes").
Drei häufige Missverständnisse aus dem Weg räumen, bevor wir tiefer einsteigen:
Wir reden hier nicht über „BTC kaufen oder nicht". Das ist ein anderes Seminar. Hier interessiert uns die Technik.
Bitcoin-Adressen sind pseudonym, nicht anonym. Jede Transaktion ist öffentlich nachvollziehbar — für alle, für immer.
Es ist ein verteiltes Kassenbuch — keine SQL-Datenbank, kein zentraler Server, keine Tabellen. Eine neue Art Datenstruktur.
Mehrere Versuche scheiterten an genau einem Problem: dem dezentralen Konsens.
Bei physischem Geld unmöglich — bei digitalem Geld fundamental. Eine Datei ist beliebig kopierbar.
Alice hat 1 BTC. Sie schickt diesen einen Bitcoin gleichzeitig an Bob (für ein Auto) und an Carol (für ein Notebook).
Tx₁ → Bob
„1 BTC für Auto"
Tx₂ → Carol
„1 BTC für Notebook"
Eine zentrale Stelle entscheidet: „Alice hat noch 1 BTC, eine Transaktion wird abgelehnt." → vertraut die zentrale Stelle.
Kein zentraler Schiedsrichter. Stattdessen: alle Knoten einigen sich gemeinsam, welche Transaktion zuerst kam → genau die wird gültig.
Wie unterscheiden sich die beiden Ansätze strukturell?
Vertrauen: alle vertrauen dem Server.
Server-Ausfall = System down.
~17.000 gleichberechtigte Knoten weltweit
Vertrauen: niemand vertraut niemandem.
Einzelne Knoten-Ausfälle = irrelevant.
Diese drei Säulen schauen wir uns nacheinander an:
Hashing (SHA-256), digitale Signaturen, Public/Private Keys — die Bausteine, mit denen Identität und Integrität nachweisbar werden.
Eine Datenstruktur, in der jeder Block kryptografisch an seinen Vorgänger gekettet ist. Ändert man einen alten Block, brechen alle nachfolgenden.
Der Mechanismus, mit dem ein neuer Block zur Kette hinzugefügt wird. Erfordert echte Rechenarbeit — macht Manipulation extrem teuer.
Ein Hash-Algorithmus macht aus beliebig großem Input eine fixe Ausgabe (256 Bit = 64 Hexzeichen). Bitcoin nutzt SHA-256 als Universal-Werkzeug.
Egal wie groß der Input — Ausgabe ist immer fix 256 Bit (64 Hexzeichen). Ein Buchstabe Unterschied → komplett anderer Hash (Avalanche-Effekt).
Die SHA-256-Funktion ist ein universeller Baustein moderner Software. Ihr nutzt sie wahrscheinlich täglich, ohne es zu merken.
Jeder Commit hat einen Hash (Git nutzt SHA-1, wechselt zu SHA-256). Jede Code-Änderung lässt sich damit zweifelsfrei nachweisen.
Jedes SSL-Zertifikat wird mit SHA-256 signiert. Beim Aufruf von https:// prüft euer Browser die Hashes.
npm, apt, pip — alle prüfen heruntergeladene Pakete per SHA-256-Hash gegen den Server-Eintrag. Manipulation fällt sofort auf.
Server speichern Passwörter nie direkt — sondern ihre Hashes (mit Salt). Was im Datenbank-Leak landet, lässt sich nicht zurück-rechnen.
Software-Distributionen werden mit Hashes signiert — euer macOS prüft das beim ersten Start jeder neuen App.
Bitcoin nutzt SHA-256 sogar doppelt: SHA256(SHA256(input)). Zusätzliche Sicherheit gegen theoretische Schwächen.
Wie fasst man tausende Transaktionen in einen einzigen Hash zusammen, sodass jede einzelne nachprüfbar bleibt?
Idee: baum-artige Hash-Verkettung. Je zwei Hashes werden zu einem neuen Hash zusammengefasst — bis ganz oben nur noch ein Wert übrigbleibt: die Merkle Root.
Merkle Root
/ \
Hash(AB) Hash(CD)
/ \ / \
Hash(A) Hash(B) Hash(C) Hash(D)
| | | |
Tx A Tx B Tx C Tx DTx C zur Menge gehört, brauchst du nicht alle Transaktionen — sondern nur den Pfad Hash(D) + Hash(AB). Bei 1 Million Transaktionen: ~20 Hashes statt 1.000.000. Effizienz durch Logarithmus.
Aufgabe: beweise, dass Tx C wirklich im Block ist — ohne alle Transaktionen herunterzuladen.
Tx C selbst (die Transaktion, die du prüfen willst)Hash(D) (kommt vom Server)Hash(AB) (kommt vom Server)Merkle Root (steht im Block-Header — vertrauenswürdig)// Vier Schritte:
Schritt 1: Hash(C) = SHA256(Tx C) // du hashst Tx C selbst
Schritt 2: Hash(CD) = SHA256(Hash(C) + Hash(D)) // kombinieren mit Hash(D)
Schritt 3: Root_check = SHA256(Hash(AB) + Hash(CD)) // kombinieren mit Hash(AB)
Schritt 4: Root_check == Merkle Root?
↓
✓ JA → Tx C ist garantiert im Block!Wie kann Alice etwas „signieren", was alle prüfen können — aber nur sie machen kann?
Alice's Schlüssel — sie behält ihn geheim, niemand sonst kennt ihn. Damit kann sie:
Alice's offenes Schloss — sie verteilt unendliche Kopien davon. Damit kann jeder:
Wie beweist Alice, dass sie die Überweisung autorisiert hat — ohne ihr Geheimnis preiszugeben?
Eine zufällige 256-Bit-Zahl. Geheim — nur Alice kennt ihn. Damit kann sie Transaktionen signieren.
Wer den Private Key hat, hat die Bitcoins.
Wird mathematisch aus dem Private Key abgeleitet (Elliptic Curve Cryptography). Öffentlich — alle dürfen ihn sehen.
Mit ihm prüft jeder, dass eine Signatur wirklich von Alice ist.
Alice braucht ihren Private Key nie herauszugeben — der Public Key reicht zum Verifizieren.
1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa). Das ist die „Konto-Nummer", die ihr im Wallet angezeigt bekommt.
Von einer Zufallszahl bis zur „Konto-Nummer" wie 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa — fünf Schritte:
e0c5b8d3a1...4f a7f904ab32f1c8...c9e84d62e907b1a...5fbb1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNaBitcoin hat keine Konto-Stände wie eine Bank. Es hat UTXOs — Unspent Transaction Outputs.
Wenn ihr 50 € bezahlen wollt und nur einen 100-€-Schein habt: ihr gebt 100 €, bekommt 50 € zurück. Genau so funktionieren UTXOs.
// Alice hat einen UTXO über 1.0 BTC
// Sie will Bob 0.3 BTC schicken
Transaktion {
inputs: [ UTXO_alice (1.0 BTC) ], // "100-€-Schein"
outputs: [
{ to: bob_address, amount: 0.3 BTC },
{ to: alice_address, amount: 0.699 BTC } // Wechselgeld an sich selbst
],
fee: 0.001 BTC // für den Miner
signature: sig_by_alices_private_key // Beweis
}Mit den Bausteinen aus Säule 1 können wir:
➡️ Genau das löst die Blockchain + Proof of Work — Säule 2 und 3.
Drei Minuten für euch — schreibt mit:
In der nächsten Vorlesung kommt die zweite Hälfte der Bitcoin-Geschichte:
Jetzt ist die beste Zeit — bevor Teil 2 startet.
Prof. Dr. Alexandra Mikityuk
HTW Berlin · Büro Raum 308
Tel +49 30 5019-2664
Nächste Woche: Bitcoin Teil 2 — Konsens & Netzwerk