Bitcoin-Technik einfach erklärt: So funktionieren Code, Nodes, Mining und Sicherheit

Home / FINANZIELLE INTELLIGENZ / Crypto
Update: Freitag, 24. Juli 2026

Bitcoin-Technik für Dummies: Was passiert eigentlich im Hintergrund, wenn jemand Bitcoin versendet? Wo liegt der Quellcode? Wer entscheidet über Änderungen? Und könnten Quantencomputer das gesamte System eines Tages knacken? Dieser ausführliche Überblick erklärt die technischen Grundlagen von Bitcoin verständlich – ohne vorauszusetzen, dass du Kryptografie studiert oder bereits eine eigene Blockchain programmiert hast.

Bitcoin ist weit mehr als eine digitale Münze oder ein spekulatives Anlageobjekt. Hinter dem Netzwerk steckt ein Zusammenspiel aus Open-Source-Software, Kryptografie, dezentraler Datenverarbeitung, wirtschaftlichen Anreizen und gemeinsam durchgesetzten Regeln. Gerade diese Kombination macht Bitcoin technisch so ungewöhnlich.

Wer zunächst die allgemeinen Grundlagen verteilter Datenbanken kennenlernen möchte, findet im Artikel über die Blockchain-Technologie und ihre Funktionsweise eine zusätzliche Einführung.

Bitcoin-Technik einfach erklärt mit Quellcode, Blockchain, Full Node, Wallet und Mining

Inhalt:

 

Was ist Bitcoin technisch gesehen?

Im Alltag wird der Begriff „Bitcoin“ für verschiedene Dinge verwendet. Gemeint sein können die digitale Werteinheit BTC, das weltweite Netzwerk, das technische Protokoll oder eine bestimmte Software wie Bitcoin Core. Für ein besseres Verständnis sollten diese Ebenen voneinander getrennt werden.

Bitcoin als Werteinheit

BTC ist die Recheneinheit des Systems. Ein Bitcoin lässt sich in 100 Millionen Satoshis unterteilen. Der Begriff Satoshi wird häufig mit „sat“ abgekürzt.

Die Bitcoin befinden sich jedoch nicht als Dateien auf einem Computer oder Smartphone. Technisch existieren Einträge in einer gemeinsam nachvollziehbaren Transaktionshistorie. Diese Einträge bestimmen, unter welchen Bedingungen bestimmte Beträge künftig ausgegeben werden dürfen.

Bitcoin als Netzwerk

Das Bitcoin-Netzwerk besteht aus vielen voneinander unabhängigen Computern. Diese sogenannten Nodes tauschen Transaktionen und Blöcke über ein Peer-to-Peer-Netzwerk aus. Es gibt keinen zentralen Server, der alle Konten verwaltet oder Überweisungen freigibt.

Jeder vollständig validierende Node kann selbst prüfen, ob eine Transaktion den Bitcoin-Regeln entspricht. Er muss sich dabei nicht darauf verlassen, dass eine Bank, Börse, Mining-Firma oder andere zentrale Stelle korrekte Informationen liefert.

Bitcoin als Protokoll

Das Bitcoin-Protokoll ist eine Sammlung von Regeln. Sie legen beispielsweise fest:

  • wie Transaktionen aufgebaut sind,
  • wie digitale Signaturen geprüft werden,
  • wie neue Blöcke aussehen dürfen,
  • wie viele neue Bitcoin erzeugt werden,
  • welche maximale Geldmenge möglich ist,
  • wie Proof of Work kontrolliert wird,
  • wie Nodes miteinander kommunizieren und
  • unter welchen Bedingungen ein Transaktionsausgang ausgegeben werden darf.

Bitcoin Core als Software

Bitcoin Core ist die bekannteste und am weitesten verbreitete vollständige Node-Implementierung. Die Software lädt Blöcke und Transaktionen aus dem Bitcoin-Netzwerk, überprüft sie anhand der Konsensregeln und verwaltet den aktuellen Zustand der Blockchain.

Bitcoin Core enthält außerdem eine optionale Wallet, eine grafische Benutzeroberfläche, Kommandozeilenprogramme sowie Schnittstellen für andere Anwendungen. Bitcoin Core ist jedoch nicht mit dem gesamten Bitcoin-Netzwerk gleichzusetzen. Auch andere Programme können das Bitcoin-Protokoll implementieren, solange sie dieselben Konsensregeln korrekt anwenden.

 

Wo gibt es den Bitcoin-Code?

Der Quellcode von Bitcoin Core ist öffentlich zugänglich. Das Hauptrepository befindet sich auf GitHub unter github.com/bitcoin/bitcoin. Bitcoin Core wird unter der freizügigen MIT-Lizenz veröffentlicht.

Du darfst den Code daher ansehen, herunterladen, untersuchen, verändern und unter Beachtung der Lizenzbedingungen auch für eigene Projekte verwenden. Kenntnisse der wichtigsten Git-Grundlagen für Entwickler helfen dabei, bestimmte Versionen auszuchecken, Änderungen nachzuvollziehen oder einen eigenen Entwicklungszweig anzulegen.

Welche Programmiersprache verwendet Bitcoin Core?

Der zentrale Bitcoin-Core-Code ist überwiegend in C++ geschrieben. Hinzu kommen unter anderem Python-Skripte für funktionale Tests, C-Code und optimierter Code in kryptografischen Bibliotheken sowie Qt-Komponenten für die grafische Benutzeroberfläche.

Im Repository befinden sich nicht nur die ausführbaren Programme. Dort findest du ebenfalls:

  • Unit-Tests und funktionale Tests,
  • Build-Skripte für verschiedene Betriebssysteme,
  • Dokumentationen für Entwickler,
  • Konfigurationsbeispiele,
  • Benchmark- und Fuzzing-Werkzeuge,
  • Release Notes älterer und aktueller Versionen,
  • die integrierte Bibliothek für secp256k1-Kryptografie und
  • Quellcode für Node, Wallet, Netzwerk, RPC-Schnittstellen und Benutzeroberfläche.

Ist der Quellcode gleichzeitig die Bitcoin-Spezifikation?

Nicht vollständig. Bei Bitcoin gibt es kein einzelnes Dokument, das allein und abschließend als offizielle Spezifikation dient. Mehrere Quellen ergänzen sich:

Quelle Bedeutung
Bitcoin-Whitepaper Beschreibt die ursprüngliche Idee und das grundlegende System.
Bitcoin-Quellcode Enthält die tatsächlich implementierten Regeln und Funktionen einer Softwareversion.
Bitcoin Improvement Proposals Dokumentieren technische Vorschläge, Standards und Protokollerweiterungen.
Entwicklerdokumentation Erklärt Datenformate, Schnittstellen, Build-Prozesse und interne Strukturen.
Ausgeführte Nodes Bestimmen praktisch, welche Regeln die jeweiligen Netzwerkteilnehmer akzeptieren.
Historische Blockchain Zeigt, welche Transaktionen und Blöcke tatsächlich akzeptiert wurden.

Das ursprüngliche Bitcoin-Whitepaper von Satoshi Nakamoto umfasst nur wenige Seiten. Es beschreibt die zentrale Idee erstaunlich präzise, enthält aber nicht alle Regeln und Erweiterungen der heutigen Implementation.

Viele spätere Funktionen wie Segregated Witness, Taproot, hierarchisch-deterministische Wallets, neue Adressformate oder verschlüsselte Peer-to-Peer-Verbindungen wurden erst nach der Veröffentlichung des Whitepapers entwickelt.

Was sind Bitcoin Improvement Proposals?

Bitcoin Improvement Proposals werden als BIPs bezeichnet. Ein BIP ist ein technisches Dokument, das eine neue Funktion, einen Standard, eine Prozessänderung oder eine wichtige Designentscheidung beschreibt.

Die BIPs befinden sich in einem eigenen öffentlichen Repository unter github.com/bitcoin/bips.

Wichtig ist: Die Aufnahme eines Vorschlags in das BIP-Repository bedeutet nicht automatisch, dass dieser Vorschlag akzeptiert, aktiviert oder von der Mehrheit unterstützt wird. Ein BIP kann jahrelang diskutiert werden, verändert werden oder dauerhaft im Entwurfsstatus bleiben.

Welche Bitcoin-Core-Version ist aktuell?

Zum Zeitpunkt der Erstellung dieses Artikels im Juli 2026 gehört Bitcoin Core 31.1 zur aktuellen stabilen Versionsreihe. Neue Versionen erscheinen regelmäßig und enthalten Fehlerkorrekturen, Leistungsverbesserungen, neue Schnittstellen und gelegentlich größere funktionale Änderungen.

Für Downloads sollten Nutzer die offizielle Seite unter bitcoincore.org verwenden und nach Möglichkeit die veröffentlichten Signaturen beziehungsweise Prüfsummen kontrollieren.

Der Entwicklungszweig „master“ auf GitHub wird laufend verändert. Er wird zwar automatisch getestet, ist aber nicht als stabile Produktivversion gedacht. Wer den Code lediglich ausführen möchte, sollte normalerweise ein offizielles Release verwenden.

 

Wie funktioniert Bitcoin grundsätzlich?

Das zentrale Problem, das Bitcoin löst, ist die Vermeidung von Doppelzahlungen ohne zentrale Kontoführung. Eine digitale Information lässt sich normalerweise beliebig kopieren. Bei digitalem Geld muss jedoch verhindert werden, dass derselbe Betrag mehrfach ausgegeben wird.

Bitcoin löst dieses Problem durch eine öffentlich überprüfbare Transaktionshistorie, digitale Signaturen, ein Peer-to-Peer-Netzwerk und Proof of Work.

1. Private Schlüssel und öffentliche Schlüssel

Am Anfang steht ein zufällig erzeugter privater Schlüssel. Dabei handelt es sich vereinfacht gesagt um eine sehr große geheime Zahl. Aus ihr lässt sich mit elliptischer Kurvenkryptografie ein öffentlicher Schlüssel berechnen.

Der private Schlüssel muss geheim bleiben. Mit ihm können Transaktionen digital signiert werden. Der öffentliche Schlüssel oder ein daraus berechneter Wert wird verwendet, um die Signatur zu überprüfen.

Aus einem öffentlichen Schlüssel oder einem Skript können unterschiedliche Bitcoin-Adressformate abgeleitet werden. Die Adresse ist eine nutzerfreundlich kodierte Darstellung bestimmter Ausgabebedingungen. Sie ist nicht mit dem privaten Schlüssel identisch.

Bei der praktischen Aufbewahrung der Schlüssel entstehen viele zusätzliche Sicherheitsfragen. Der Ratgeber zur Auswahl eines sicheren Krypto-Wallets erläutert Unterschiede zwischen Software-Wallets, Hardware-Wallets und anderen Aufbewahrungsmethoden.

2. Bitcoin verwendet keine klassischen Kontostände

Bitcoin arbeitet nicht wie eine Bankdatenbank mit einem Kontostand pro Kunde. Stattdessen verwendet das System sogenannte Unspent Transaction Outputs, kurz UTXOs.

Ein UTXO ist ein noch nicht ausgegebener Ausgang einer früheren Transaktion. Er enthält einen bestimmten Betrag und eine Bedingung, die für eine spätere Ausgabe erfüllt werden muss.

Wenn eine Wallet einen Kontostand von 0,5 BTC anzeigt, kann sich dieser Betrag beispielsweise aus drei verschiedenen UTXOs zusammensetzen:

  • 0,10 BTC,
  • 0,15 BTC und
  • 0,25 BTC.

Möchtest du 0,30 BTC versenden, kann deine Wallet zwei oder mehrere passende UTXOs als Eingänge verwenden. Falls die Summe der Eingänge größer als der zu zahlende Betrag zuzüglich Gebühr ist, erstellt die Wallet einen Wechselgeldausgang an eine eigene neue Adresse.

3. Eine Wallet erstellt eine Transaktion

Eine Bitcoin-Transaktion enthält unter anderem:

  • Verweise auf vorherige Transaktionsausgänge,
  • die neu zu erzeugenden Ausgänge,
  • die jeweiligen Beträge,
  • Entsperrdaten oder Signaturen,
  • eine Versionsnummer und
  • gegebenenfalls Zeit- oder Sequenzbedingungen.

Die Wallet wählt geeignete UTXOs aus, berechnet eine Gebühr, erzeugt die Ausgänge und signiert die Transaktion mit dem privaten Schlüssel. Anschließend übermittelt sie die Transaktion an einen Bitcoin-Node.

4. Nodes prüfen und verteilen die Transaktion

Ein empfangender Node kontrolliert beispielsweise:

  • ob die referenzierten UTXOs existieren,
  • ob sie noch nicht ausgegeben wurden,
  • ob die Signaturen gültig sind,
  • ob die Skriptbedingungen erfüllt werden,
  • ob kein neuer Bitcoin-Betrag aus dem Nichts entsteht und
  • ob die Transaktion den lokalen Weiterleitungsregeln entspricht.

Eine gültige, noch nicht bestätigte Transaktion kann in den Mempool des Nodes aufgenommen werden. Der Mempool ist ein temporärer Speicher für Transaktionen, die noch in keinem Block enthalten sind.

Jeder Node besitzt seinen eigenen Mempool. Deshalb gibt es streng genommen nicht „den einen Bitcoin-Mempool“. Verschiedene Nodes können je nach Konfiguration, Gebührenanforderungen und Empfangszeitpunkt leicht unterschiedliche Transaktionen gespeichert haben.

5. Miner stellen Blockkandidaten zusammen

Miner beziehungsweise Mining-Pools wählen Transaktionen aus ihren Mempools aus und stellen daraus einen möglichen neuen Block zusammen. In der Regel werden Transaktionen mit attraktiven Gebühren bevorzugt.

Zusätzlich enthält der Block eine sogenannte Coinbase-Transaktion. Mit ihr werden die erlaubte Blocksubvention und die Transaktionsgebühren dem Miner zugeordnet.

6. Proof of Work sichert die Reihenfolge

Ein Miner verändert bestimmte Daten im Blockheader und berechnet immer wieder einen SHA-256-basierten Hash. Das Ergebnis muss kleiner als ein vom Netzwerk vorgegebener Zielwert sein.

Da ein kryptografischer Hash nicht gezielt vorhergesagt werden kann, müssen Miner sehr viele Versuche durchführen. Wer einen gültigen Hash findet, verteilt den Block an andere Nodes.

Die Nodes kontrollieren den Block vollständig. Sie prüfen nicht nur den Proof of Work, sondern auch jede einzelne enthaltene Transaktion und sämtliche weiteren Konsensregeln.

7. Bestätigungen entstehen durch weitere Blöcke

Wird eine Transaktion in einen gültigen Block aufgenommen, besitzt sie eine Bestätigung. Jeder weitere gültige Block, der auf diesem Block aufbaut, erhöht die Anzahl der Bestätigungen.

Je mehr Proof of Work nach einer Transaktion aufgebaut wurde, desto aufwendiger wäre eine nachträgliche Änderung der Historie. Eine Bestätigung ist jedoch nicht mit einer absoluten mathematischen Unumkehrbarkeit gleichzusetzen. Das Risiko einer Reorganisation sinkt vielmehr mit zusätzlichen Blöcken stark ab.

Ablauf einer Bitcoin-Transaktion von Wallet über Node und Mempool bis zum Miner und Block

 

Welche Algorithmen und technischen Verfahren verwendet Bitcoin?

Bitcoin basiert nicht auf einem einzigen geheimen Super-Algorithmus. Das System kombiniert mehrere bekannte kryptografische und informatische Verfahren.

SHA-256

SHA-256 ist eine kryptografische Hashfunktion. Sie verarbeitet Daten beliebiger Länge und erzeugt daraus einen 256 Bit langen Hashwert.

Schon eine minimale Änderung der Eingabedaten erzeugt normalerweise ein völlig anderes Ergebnis. Aus dem Hash lässt sich die ursprüngliche Eingabe praktisch nicht zurückberechnen.

Bitcoin verwendet SHA-256 unter anderem für:

  • Proof of Work,
  • Block- und Transaktionskennungen,
  • Merkle-Bäume,
  • verschiedene Skriptoperationen und
  • weitere interne Datenstrukturen.

Beim Proof of Work wird der serialisierte Blockheader zweimal mit SHA-256 verarbeitet. Deshalb wird häufig von SHA-256d oder Double-SHA-256 gesprochen.

RIPEMD-160 und HASH160

Bei älteren und weiterhin verbreiteten Konstruktionen wird ein öffentlicher Schlüssel zunächst mit SHA-256 und anschließend mit RIPEMD-160 verarbeitet. Diese Kombination wird als HASH160 bezeichnet.

Sie kommt beispielsweise bei klassischen Pay-to-Public-Key-Hash- und Pay-to-Witness-Public-Key-Hash-Ausgaben zum Einsatz.

Elliptische Kurven und secp256k1

Bitcoin verwendet für klassische digitale Signaturen die elliptische Kurve secp256k1. Aus einem privaten Schlüssel kann ein öffentlicher Schlüssel berechnet werden. Der umgekehrte Weg gilt mit heutigen klassischen Computern als praktisch nicht durchführbar.

Für ältere Bitcoin-Ausgabetypen werden ECDSA-Signaturen verwendet. Taproot führte zusätzlich Schnorr-Signaturen nach BIP 340 ein. Beide Verfahren basieren auf derselben elliptischen Kurve und wären grundsätzlich von einem ausreichend leistungsfähigen Quantencomputer bedroht.

Merkle-Bäume

Die Transaktionen eines Blocks werden in einer Merkle-Baum-Struktur zusammengefasst. Paarweise Hashwerte werden erneut gehasht, bis nur noch eine sogenannte Merkle Root übrig bleibt.

Diese Merkle Root befindet sich im Blockheader. Dadurch kann effizient nachgewiesen werden, dass eine bestimmte Transaktion zu einem Block gehört, ohne für jeden Nachweis alle anderen Transaktionen übertragen zu müssen.

Bitcoin Script

Bitcoin Script ist eine kleine, stackbasierte Skriptsprache. Sie definiert, unter welchen Bedingungen ein UTXO ausgegeben werden darf.

Typische Bedingungen sind:

  • eine gültige Signatur für einen bestimmten Schlüssel,
  • mehrere Signaturen aus einer Gruppe von Schlüsseln,
  • das Erreichen einer bestimmten Blockhöhe oder Zeit,
  • die Offenlegung eines geheimen Wertes zu einem bekannten Hash oder
  • eine Kombination mehrerer Bedingungen.

Bitcoin Script ist bewusst eingeschränkter als viele Programmiersprachen für allgemeine Smart-Contract-Plattformen. Es enthält beispielsweise keine frei verwendbaren Schleifen. Das erleichtert eine deterministische Ausführung und begrenzt bestimmte Fehlerklassen.

Weitere Hintergründe zu programmierbaren Blockchain-Bedingungen bietet die Einführung in Smart Contracts und digitale Verträge. Dabei sollte allerdings beachtet werden, dass sich Bitcoin Script deutlich von umfangreichen Smart-Contract-Systemen wie der Ethereum Virtual Machine unterscheidet.

Schwierigkeitsanpassung

Das Bitcoin-Protokoll passt die Mining-Schwierigkeit regelmäßig an. Ziel ist, dass im langfristigen Durchschnitt ungefähr alle zehn Minuten ein neuer Block entsteht.

Steigt die gesamte Rechenleistung des Netzwerks, werden gültige Blockhashes entsprechend schwieriger zu finden. Sinkt die Rechenleistung, kann die Schwierigkeit reduziert werden.

Halving und begrenzte Geldmenge

Die Blocksubvention wird nach jeweils 210.000 Blöcken halbiert. Dadurch nimmt die Menge neu erzeugter Bitcoin schrittweise ab.

Aus den festgelegten Regeln ergibt sich langfristig eine maximale Geldmenge von knapp 21 Millionen Bitcoin. Diese Zahl wird nicht durch einen einzelnen Datenbankeintrag erzwungen. Jeder vollständig validierende Node kontrolliert bei jedem Block, ob die erlaubte Subvention eingehalten wurde.

 

Wie ist die aktuelle Bitcoin-Core-Implementation aufgebaut?

Bitcoin Core ist über viele Jahre gewachsen. Die Software besteht aus mehreren Bereichen, die unterschiedliche Aufgaben übernehmen. Neuere Entwicklungsarbeiten versuchen, Schnittstellen zwischen Node, Wallet und Benutzeroberfläche klarer zu trennen.

Vereinfachte Architektur von Bitcoin Core mit Peer-to-Peer-Netzwerk, Validierung, Chainstate, Mempool, Wallet, RPC und Benutzeroberfläche

Peer-to-Peer-Netzwerk

Die Netzwerkkomponente stellt Verbindungen zu anderen Bitcoin-Nodes her. Sie empfängt und versendet unter anderem:

  • Transaktionen,
  • Blockheader,
  • vollständige Blöcke,
  • Peer-Adressen und
  • weitere Protokollnachrichten.

Beim ersten Start kennt ein Node noch keine aktiven Gegenstellen. Er kann unter anderem vorkonfigurierte DNS-Seeds verwenden, um erste mögliche Peers zu finden. Danach lernt er weitere Adressen direkt aus dem Netzwerk.

Bitcoin Core kann neben normalen Internetverbindungen auch mit Technologien wie Tor oder I2P eingesetzt werden. Neuere Protokollerweiterungen verbessern außerdem den Schutz der Kommunikation zwischen Nodes.

Validierung

Die Validierungskomponente überprüft Transaktionen und Blöcke. Dieser Bereich ist besonders sicherheitskritisch, weil schon kleine Abweichungen bei Konsensregeln zu einer Aufspaltung des Netzwerks führen könnten.

Zu den Prüfungen gehören unter anderem:

  • Syntax und Datenformate,
  • Blockgröße beziehungsweise Blockgewicht,
  • Proof of Work,
  • Signaturen,
  • Skriptbedingungen,
  • zulässige Eingabe- und Ausgabebeträge,
  • Blocksubvention und
  • Vermeidung von Doppelzahlungen.

Chainstate und UTXO-Datenbank

Für die laufende Validierung muss Bitcoin Core nicht jedes Mal sämtliche alten Transaktionen neu durchsuchen. Der aktuelle Zustand aller noch nicht ausgegebenen Transaktionsausgänge wird kompakt im sogenannten Chainstate gespeichert.

Die Chainstate-Datenbank enthält das aktuelle UTXO-Set. Wird ein gültiger Block verarbeitet, werden ausgegebene UTXOs entfernt und neu erzeugte UTXOs hinzugefügt.

Diese Datenbank ist für die schnelle Prüfung neuer Transaktionen entscheidend. Die vollständigen historischen Blöcke werden separat in Blockdateien gespeichert.

Blockdateien und Blockindex

Bitcoin Core legt vollständige Blöcke in Dateien wie blk00000.dat, blk00001.dat und weiteren fortlaufenden Dateien ab. Ergänzende Undo-Daten ermöglichen es, einen Block bei einer Blockchain-Reorganisation wieder rückgängig zu machen.

Der Blockindex enthält Metadaten über bekannte Blöcke, ihre Vorgänger, ihren Status und den zugehörigen Proof of Work.

Ein Node kann im Pruning-Modus betrieben werden. Dabei werden ältere Blockdateien nach erfolgreicher Validierung teilweise gelöscht. Der Node kontrolliert die Blockchain weiterhin selbst, stellt anderen Teilnehmern aber nicht mehr die vollständige historische Blockkette zur Verfügung.

Mempool und Weiterleitungsregeln

Der Mempool enthält noch nicht bestätigte Transaktionen. Dabei muss zwischen Konsensregeln und lokalen Policy-Regeln unterschieden werden.

Konsensregeln bestimmen, ob eine Transaktion innerhalb eines Blocks grundsätzlich gültig ist. Policy-Regeln bestimmen zusätzlich, welche unbestätigten Transaktionen ein bestimmter Node in seinen Mempool aufnimmt oder an andere Nodes weiterleitet.

Eine Transaktion kann daher theoretisch konsensgültig sein, aber von vielen Nodes nicht automatisch weitergeleitet werden. Miner könnten sie trotzdem in einen Block aufnehmen. Sobald sie Teil eines gültigen Blocks ist, müssen vollständig validierende Nodes sie entsprechend der Konsensregeln akzeptieren.

Wallet

Die Bitcoin-Core-Wallet verwaltet Schlüssel, Ausgabebedingungen, Adressen und bekannte eigene Transaktionen. Moderne Wallets arbeiten zunehmend mit sogenannten Output Descriptors.

Ein Descriptor beschreibt nicht nur einen einzelnen Schlüssel, sondern die Struktur einer ganzen Gruppe möglicher Ausgabeskripte. Dadurch lassen sich Wallet-Konfigurationen genauer und nachvollziehbarer sichern.

Die Wallet ist optional. Bitcoin Core kann ohne Wallet kompiliert und als reiner Node betrieben werden. Umgekehrt können externe Wallets einen Bitcoin-Core-Node für Blockchain-Daten und das Versenden von Transaktionen verwenden.

RPC-, REST- und ZMQ-Schnittstellen

Bitcoin Core stellt verschiedene Schnittstellen für andere Programme bereit:

  • JSON-RPC: Steuerung des Nodes und der Wallet über Befehle.
  • REST: Abruf bestimmter Blockchain- und Netzwerkdaten.
  • ZMQ: Benachrichtigungen über neue Blöcke und Transaktionen.
  • Kommandozeile: Bedienung über bitcoin-cli beziehungsweise die neueren Bitcoin-Unterbefehle.

Entwickler können darüber eigene Wallets, Blockexplorer, Zahlungssysteme, Monitoring-Werkzeuge oder Analyseprogramme anbinden. Allgemeine Grundlagen der Softwareentwicklung und Programmierung sind hilfreich, bevor man direkt mit den internen Bitcoin-Schnittstellen arbeitet.

Grafische Benutzeroberfläche

Bitcoin Core enthält eine mit Qt entwickelte Benutzeroberfläche. Sie kann beim Kompilieren aktiviert oder vollständig weggelassen werden.

Für einen Server oder eine Node auf einem Einplatinencomputer ist häufig nur der Hintergrunddienst bitcoind erforderlich. Desktop-Nutzer können dagegen bitcoin-qt verwenden.

Komponente Aufgabe
bitcoind Bitcoin-Node als Hintergrunddienst ohne grafische Oberfläche
bitcoin-qt Node und optionale Wallet mit grafischer Benutzeroberfläche
bitcoin-cli Kommandozeilenkommunikation mit einem laufenden Node
Chainstate Speichert den aktuellen Bestand aller UTXOs
Mempool Speichert lokal akzeptierte, noch unbestätigte Transaktionen
Wallet Verwaltet Schlüssel, Descriptors, Adressen und eigene Transaktionen
P2P-Komponente Kommuniziert mit anderen Bitcoin-Nodes
Validierung Prüft Transaktionen, Blöcke und Konsensregeln

 

Wer pflegt den Bitcoin-Code?

Hinter Bitcoin Core steht keine klassische Firma mit Geschäftsführung, Produktmanager und verbindlicher Entwicklungsroadmap. Der Code wird von einer internationalen Open-Source-Gemeinschaft entwickelt.

Am Projekt beteiligen sich unter anderem:

  • Programmierer,
  • Code-Reviewer,
  • Tester,
  • Kryptografen,
  • Dokumentationsautoren,
  • Übersetzer,
  • Wallet- und Infrastrukturentwickler und
  • Forscher aus unterschiedlichen Organisationen.

Einige Entwickler arbeiten unabhängig, andere werden von Unternehmen, Forschungsorganisationen oder gemeinnützigen Einrichtungen finanziert. Daraus folgt jedoch nicht automatisch, dass die jeweiligen Geldgeber das Bitcoin-Protokoll kontrollieren.

Was machen die Bitcoin-Core-Maintainer?

Bestimmte erfahrene Entwickler besitzen die technische Berechtigung, geprüfte Änderungen in das Bitcoin-Core-Repository zu übernehmen. Sie werden häufig als Merge Maintainer bezeichnet.

Ein Maintainer kann entscheiden, ob ein Pull Request ausreichend geprüft wurde und den Qualitätsanforderungen des Projekts entspricht. Er kann jedoch nicht allein bestimmen, welche Bitcoin-Regeln weltweit gelten.

Wird eine Änderung in Bitcoin Core aufgenommen, bedeutet das zunächst nur, dass sie Bestandteil einer bestimmten Softwareversion ist. Jeder Nutzer entscheidet selbst, ob er diese Version installiert und ausführt.

Wie gelangt eine Änderung in Bitcoin Core?

Der typische Ablauf sieht vereinfacht so aus:

  1. Ein Entwickler beschreibt ein Problem oder eine neue Idee.
  2. Größere Protokolländerungen werden häufig vorab öffentlich diskutiert.
  3. Gegebenenfalls entsteht ein BIP mit technischer Spezifikation.
  4. Ein Entwickler programmiert eine konkrete Implementation.
  5. Die Änderung wird als Pull Request auf GitHub eingereicht.
  6. Andere Entwickler prüfen Code, Tests, Sicherheit und Auswirkungen.
  7. Automatisierte Tests laufen auf mehreren Betriebssystemen.
  8. Offene Kritikpunkte müssen geklärt werden.
  9. Bei ausreichender Unterstützung kann ein Maintainer die Änderung übernehmen.
  10. Die Funktion erscheint möglicherweise in einem späteren Release.

Gerade bei sicherheitskritischen Änderungen kann dieser Prozess lange dauern. Bitcoin Core weist ausdrücklich darauf hin, dass Code-Review und Tests häufig der Engpass der Entwicklung sind.

Wer entscheidet über Konsensänderungen?

Bei normalen Verbesserungen der Benutzeroberfläche oder der Leistungsfähigkeit reicht der übliche Entwicklungsprozess aus. Änderungen der Konsensregeln sind deutlich komplizierter.

Mehrere Gruppen spielen dabei eine Rolle:

  • Entwickler entwerfen und implementieren Änderungen.
  • Reviewer prüfen die technische Qualität.
  • Maintainer können Code in ein Repository übernehmen.
  • Node-Betreiber entscheiden, welche Regeln ihre Nodes durchsetzen.
  • Wallets und Börsen entscheiden, welche Funktionen sie unterstützen.
  • Miner entscheiden, welche gültigen Transaktionen sie in Blöcke aufnehmen.
  • Wirtschaftliche Nutzer entscheiden, welche Bitcoin-Version sie als werthaltig akzeptieren.

Keine dieser Gruppen kann jede Änderung allein durchsetzen. Miner können beispielsweise keine beliebig hohe Blocksubvention erzeugen, wenn die vollständig validierenden Nodes solche Blöcke ablehnen.

Umgekehrt können Entwickler zwar neuen Code veröffentlichen, aber niemanden zwingen, diesen Code zu installieren.

Soft Fork und Hard Fork

Eine Soft Fork verschärft die Regeln so, dass Blöcke nach den neuen Regeln auch von älteren Nodes grundsätzlich als gültig angesehen werden können. Alte Nodes prüfen die neue Funktion jedoch nicht vollständig.

Eine Hard Fork lockert oder verändert Regeln in einer Weise, durch die ältere Nodes neue Blöcke ablehnen würden. Ohne nahezu vollständige Koordination kann dadurch eine dauerhafte Aufspaltung in zwei Netzwerke entstehen.

Aus diesem Grund werden grundlegende Bitcoin-Änderungen besonders vorsichtig diskutiert und häufig so entworfen, dass sie als Soft Fork aktiviert werden könnten.

 

Wie kannst du Bitcoin Core selbst kompilieren?

Da der Bitcoin-Core-Quellcode offen verfügbar ist, kannst du aus den Quelldateien eigene ausführbare Programme erstellen. Dieser Vorgang wird als Kompilieren oder Bauen bezeichnet.

Für die meisten normalen Bitcoin-Nutzer ist das nicht erforderlich. Offizielle Binärdateien sind wesentlich bequemer. Das eigene Kompilieren kann trotzdem sinnvoll sein.

Wann lohnt es sich, Bitcoin Core selbst zu bauen?

  • Du möchtest den Quellcode besser verstehen.
  • Du willst eigene Änderungen testen.
  • Du entwickelst eine Funktion oder Fehlerkorrektur.
  • Du möchtest eine bestimmte Build-Konfiguration verwenden.
  • Du benötigst einen Node ohne Wallet oder Benutzeroberfläche.
  • Du willst einen Pull Request prüfen.
  • Du möchtest reproduzierbare Builds untersuchen.
  • Du willst eine noch nicht veröffentlichte Funktion in Regtest oder Signet testen.

Wann ist das eigene Kompilieren nicht sinnvoll?

Das eigenständige Kompilieren erhöht nicht automatisch die Sicherheit. Wer den verwendeten Code, die Abhängigkeiten und das Build-System nicht überprüft, gewinnt gegenüber einer verifizierten offiziellen Binärdatei nur begrenzt zusätzliche Sicherheit.

Ein selbst gebauter Entwicklungsstand sollte außerdem nicht sofort mit einer Wallet verwendet werden, die bedeutende Guthaben enthält. Erste Versuche gehören in eine isolierte Testumgebung.

Welche Voraussetzungen brauchst du?

Für einen einfachen Linux-Build werden unter anderem benötigt:

  • Git,
  • ein moderner C- und C++-Compiler,
  • CMake,
  • Python für Skripte und Tests,
  • Boost und
  • SQLite, falls die Wallet aktiviert werden soll.

Für die grafische Benutzeroberfläche werden zusätzlich Qt 6 und weitere Bibliotheken benötigt. Funktionen wie ZMQ, IPC oder QR-Code-Erzeugung besitzen ebenfalls optionale Abhängigkeiten.

Beispiel: Bitcoin Core unter Ubuntu oder Debian kompilieren

Das folgende Beispiel zeigt einen vereinfachten Build ohne zusätzliche Spezialkonfiguration. Die benötigten Pakete können sich bei späteren Bitcoin-Core-Versionen ändern. Deshalb solltest du immer auch die Build-Dokumentation der verwendeten Version lesen.

sudo apt update
sudo apt install git build-essential cmake python3 libboost-dev libsqlite3-dev

git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin

git checkout v31.1

cmake -B build
cmake --build build -j 4

ctest --test-dir build

Mit git checkout v31.1 wird im Beispiel ein bestimmtes stabiles Release ausgewählt. Wer lediglich master verwendet, kompiliert den aktuellen Entwicklungsstand.

Die Zahl hinter -j bestimmt, wie viele parallele Build-Aufgaben ausgeführt werden. Ein höherer Wert kann den Build beschleunigen, benötigt aber mehr Arbeitsspeicher und Prozessorleistung.

Bitcoin Core ohne Wallet bauen

Für einen reinen Netzwerk-Node kann die Wallet deaktiviert werden:

cmake -B build -DENABLE_WALLET=OFF
cmake --build build -j 4

Dadurch entfällt auch die SQLite-Abhängigkeit für die Wallet.

Grafische Oberfläche aktivieren

Nachdem die benötigten Qt- und QR-Code-Bibliotheken installiert wurden, kann die grafische Oberfläche explizit aktiviert werden:

cmake -B build -DBUILD_GUI=ON
cmake --build build -j 4

Alle verfügbaren Konfigurationsoptionen lassen sich anzeigen mit:

cmake -B build -LH

Funktionale Tests starten

Neben den kompilierten Unit-Tests enthält Bitcoin Core zahlreiche funktionale Python-Tests:

build/test/functional/test_runner.py

Die vollständige Testsuite kann einige Zeit benötigen. Für konkrete Änderungen lassen sich auch einzelne Tests starten.

Eine lokale Regtest-Blockchain starten

Regtest ist ein privates Bitcoin-Testnetz, das ausschließlich auf deinem eigenen Rechner oder in deiner lokalen Testumgebung läuft. Du kannst dort Blöcke sofort erzeugen und Funktionen ausprobieren, ohne echte Bitcoin zu verwenden.

./build/bin/bitcoind -regtest -daemon

./build/bin/bitcoin-cli -regtest createwallet "testwallet"

ADDRESS=$(./build/bin/bitcoin-cli -regtest getnewaddress)

./build/bin/bitcoin-cli -regtest generatetoaddress 101 "$ADDRESS"

./build/bin/bitcoin-cli -regtest getblockchaininfo

Die ersten 101 Blöcke sorgen dafür, dass die erzeugten Coinbase-Ausgänge nach den Regtest-Regeln ausgabefähig werden. Danach kannst du lokale Transaktionen erstellen, Blöcke generieren und RPC-Befehle untersuchen.

Bitcoin Core unter Windows kompilieren

Unter Windows gibt es mehrere Möglichkeiten:

  • Kompilieren innerhalb des Windows Subsystem for Linux,
  • Cross-Kompilieren mit MinGW-w64 oder
  • nativer Build mit Microsoft Visual Studio und MSVC.

Für Einsteiger ist WSL häufig praktisch, weil viele Schritte den Linux-Anweisungen ähneln. Für einen echten Windows-Build werden zusätzliche Toolchains und Abhängigkeiten benötigt.

Die aktuelle offizielle Anleitung befindet sich im Repository in den Dateien doc/build-windows.md und doc/build-windows-msvc.md.

Bitcoin Core unter macOS kompilieren

Unter macOS werden normalerweise die Xcode Command Line Tools und ein Paketmanager wie Homebrew verwendet. Für einen grundlegenden Build nennt die offizielle Dokumentation unter anderem CMake, Boost und Cap’n Proto.

xcode-select --install
brew install cmake boost capnp

git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
git checkout v31.1

cmake -B build
cmake --build build
ctest --test-dir build

Für die grafische Oberfläche können zusätzlich Qt 6 und libqrencode installiert werden.

Bitcoin-Core-Quellcode von GitHub herunterladen und mit Git, CMake und C++ kompilieren

 

Wie findest du dich im Bitcoin-Quellcode zurecht?

Bitcoin Core besteht aus sehr vielen Dateien. Wer direkt bei der Konsensvalidierung beginnt, kann schnell den Überblick verlieren. Sinnvoller ist eine schrittweise Annäherung.

Wichtige Verzeichnisse im Repository

Verzeichnis oder Datei Inhalt
src/ Zentraler Quellcode der Bitcoin-Core-Programme
src/net.cpp Grundlegende Netzwerkverbindungen und Peer-Verwaltung
src/net_processing.cpp Verarbeitung von Bitcoin-P2P-Nachrichten
src/validation.cpp Große Teile der Block- und Transaktionsvalidierung
src/txmempool.cpp Verwaltung unbestätigter Transaktionen
src/consensus/ Definitionen und Code in Verbindung mit Konsensregeln
src/script/ Bitcoin Script und Signaturprüfung
src/wallet/ Wallet-Funktionen
src/qt/ Grafische Benutzeroberfläche
src/rpc/ JSON-RPC-Befehle
src/secp256k1/ Kryptografische Bibliothek für secp256k1
test/functional/ Funktionale Python-Tests
doc/ Build-, Entwicklungs- und Schnittstellendokumentation

Ein sinnvoller Lernpfad

  1. Lies zunächst das Bitcoin-Whitepaper.
  2. Verstehe Transaktionen, UTXOs, Blöcke und Proof of Work.
  3. Starte Bitcoin Core im Regtest-Modus.
  4. Probiere einfache RPC-Befehle aus.
  5. Erzeuge Transaktionen und dekodiere sie.
  6. Untersuche einen kleinen funktionalen Test.
  7. Setze Haltepunkte in einer Debug-Version.
  8. Verfolge den Weg einer Regtest-Transaktion durch Mempool und Blockvalidierung.
  9. Lies passende BIPs zu dem untersuchten Feature.

Nicht sofort die Konsensregeln verändern

Eine lokal geänderte Bitcoin-Core-Version kann beliebige andere Regeln verwenden. Sie wird dadurch aber nicht automatisch mit dem öffentlichen Bitcoin-Netzwerk kompatibel.

Akzeptiert dein Programm einen Block, den reguläre Bitcoin-Nodes ablehnen, befindet es sich anschließend auf einer eigenen inkompatiblen Blockchain. Eine lokale Codeänderung verändert also nicht die Regeln aller anderen Teilnehmer.

 

Bitcoin und Quantencomputer: Wie groß ist die Gefahr?

Quantencomputer werden häufig entweder als unmittelbar bevorstehendes Ende von Bitcoin oder als völlig irrelevante Science-Fiction dargestellt. Beide Positionen greifen zu kurz.

Ein ausreichend leistungsfähiger, fehlertoleranter Quantencomputer könnte bestimmte heute verwendete kryptografische Verfahren tatsächlich gefährden. Ein solcher Angriff wäre jedoch technisch außerordentlich anspruchsvoll. Wann entsprechende Systeme verfügbar sein könnten, lässt sich derzeit nicht seriös vorhersagen.

Bitcoin und Quantencomputer mit digitalem Schlüssel, Blockchain und quantenresistenter Kryptografie

Welche Bitcoin-Kryptografie wäre betroffen?

Bei Bitcoin müssen zwei Bereiche getrennt betrachtet werden:

  • digitale Signaturen auf Basis elliptischer Kurven und
  • kryptografische Hashfunktionen wie SHA-256.

Shor-Algorithmus gegen ECDSA und Schnorr

Ein ausreichend leistungsfähiger Quantencomputer könnte mit dem Shor-Algorithmus das Problem des diskreten Logarithmus effizient lösen.

Vereinfacht bedeutet das: Ist der öffentliche Schlüssel bekannt, könnte ein solcher Computer möglicherweise den zugehörigen privaten Schlüssel berechnen. Damit ließen sich gültige Signaturen erzeugen und betroffene Bitcoin ausgeben.

Davon wären sowohl klassische ECDSA-Signaturen als auch die bei Taproot verwendeten Schnorr-Signaturen betroffen, da beide auf secp256k1 basieren.

Grover-Algorithmus gegen SHA-256

Für Hashfunktionen ist die Situation weniger dramatisch. Der Grover-Algorithmus kann eine unstrukturierte Suche theoretisch quadratisch beschleunigen.

Eine idealisierte 256-Bit-Preimage-Sicherheit würde dadurch grob auf ein Sicherheitsniveau von etwa 128 Bit sinken. Das wäre weiterhin ein sehr hohes Sicherheitsniveau. Außerdem erfordert die praktische Umsetzung enorme Quantenressourcen.

Quantencomputer würden SHA-256 daher nicht einfach augenblicklich unbrauchbar machen.

Was passiert mit dem Bitcoin-Mining?

Auch beim Mining könnte der Grover-Algorithmus theoretisch Vorteile ermöglichen. Daraus folgt jedoch nicht automatisch, dass ein einzelner Quantencomputer sofort alle Blöcke findet.

Die praktische Geschwindigkeit hängt von Fehlerkorrektur, Taktfrequenz, Parallelisierung, Energieverbrauch und verfügbarer Quantenhardware ab. Erhöht sich die effektive Mining-Leistung dauerhaft, würde das Bitcoin-Netzwerk außerdem seine Schwierigkeit anpassen.

Für die langfristige Sicherheit sind digitale Signaturen deshalb voraussichtlich die dringendere Quantenfrage als der reine SHA-256-Proof-of-Work.

Wann ist ein Bitcoin-Public-Key sichtbar?

Ob ein Quantenangriff möglich wäre, hängt unter anderem davon ab, ob der öffentliche Schlüssel bereits bekannt ist.

Ausgabetyp Public Key vor der Ausgabe sichtbar? Vereinfachte Quantenbewertung
P2PK Ja Langfristig direkt angreifbar, sobald ein geeigneter Quantencomputer existiert
P2PKH Normalerweise erst beim Ausgeben Vor der ersten Ausgabe teilweise durch den Hash geschützt
P2WPKH Normalerweise erst beim Ausgeben Vor der ersten Ausgabe teilweise durch den Hash geschützt
P2SH oder P2WSH Abhängig vom verwendeten Skript Schutz hängt von der konkreten Konstruktion ab
P2TR beziehungsweise Taproot Ja, der Output enthält einen öffentlichen Schlüssel Bei einem leistungsfähigen Quantencomputer langfristig angreifbar

Bei einer P2PKH- oder P2WPKH-Ausgabe befindet sich zunächst nur ein Hash des öffentlichen Schlüssels auf der Blockchain. Erst beim Ausgeben wird der vollständige Schlüssel veröffentlicht.

Dieser Schutz gilt allerdings nicht zuverlässig, wenn dieselben Schlüssel oder Adressen mehrfach verwendet wurden oder der öffentliche Schlüssel bereits auf anderem Weg bekannt ist.

Taproot-Ausgaben enthalten dagegen einen öffentlichen Schlüssel direkt im Output. Sie bieten viele Vorteile bei Effizienz, Privatsphäre und komplexen Ausgabebedingungen, sind aber gegenüber einem hypothetischen langfristigen Quantenangriff anders zu bewerten.

Long-Exposure- und Short-Exposure-Angriffe

In aktuellen Diskussionen werden häufig zwei Szenarien unterschieden.

Long Exposure: Der öffentliche Schlüssel liegt bereits lange sichtbar auf der Blockchain. Ein Quantenangreifer hätte ausreichend Zeit, daraus den privaten Schlüssel abzuleiten.

Short Exposure: Der öffentliche Schlüssel wird erst beim Versenden einer Transaktion veröffentlicht. Der Angreifer müsste den privaten Schlüssel berechnen und eine konkurrierende Transaktion veröffentlichen, bevor die ursprüngliche Transaktion ausreichend bestätigt wurde.

Ein früher Quantencomputer könnte möglicherweise zuerst langfristig sichtbare Schlüssel gefährden, während ein erfolgreicher Short-Exposure-Angriff noch erheblich höhere Geschwindigkeit erfordern würde.

Wie ist der Stand der Quantencomputer?

Im Juli 2026 ist kein öffentlich bekannter Quantencomputer verfügbar, der secp256k1 in einer für einen realen Bitcoin-Angriff ausreichenden Geschwindigkeit brechen könnte.

Aktuelle Systeme arbeiten noch mit begrenzten und fehleranfälligen physikalischen Qubits. Für umfangreiche kryptografische Berechnungen wären große fehlertolerante Systeme mit Quantenfehlerkorrektur notwendig.

Vorhersagen reichen von wenigen Jahren bis zu mehreren Jahrzehnten. Solche Zeitangaben sind mit großer Unsicherheit verbunden. Fortschritte bei Algorithmen können die benötigten Ressourcen reduzieren, während der Bau stabiler und skalierbarer Hardware weiterhin eine große Herausforderung darstellt.

Post-Quantum-Kryptografie existiert bereits

Post-Quantum-Kryptografie bezeichnet klassische Algorithmen, die auch Angriffen durch leistungsfähige Quantencomputer widerstehen sollen. Sie laufen auf normalen Computern und benötigen keinen Quantencomputer.

Das US-amerikanische National Institute of Standards and Technology hat 2024 erste Post-Quantum-Standards veröffentlicht. Für digitale Signaturen sind insbesondere ML-DSA und das hashbasierte SLH-DSA relevant.

Solche Signaturen besitzen jedoch andere Eigenschaften als heutige Bitcoin-Signaturen. Öffentliche Schlüssel und Signaturen können erheblich größer sein. Das wirkt sich bei einer Blockchain unmittelbar auf Speicherbedarf, Bandbreite, Gebühren und Verifikationszeit aus.

Bitcoin kann daher nicht einfach eine bestehende Signatur durch einen beliebigen Post-Quantum-Algorithmus ersetzen. Eine Einführung müsste sorgfältig auf Konsensregeln, Blockkapazität, Hardware-Wallets, Multisignaturverfahren und langfristige Sicherheit abgestimmt werden.

BIP 360: Pay-to-Merkle-Root

BIP 360 ist ein aktueller Entwurf für einen neuen Ausgabetyp namens Pay-to-Merkle-Root, kurz P2MR. Er orientiert sich an Taproot, entfernt jedoch den durch elliptische Kurven geschützten Key-Path.

Ein P2MR-Output würde stattdessen direkt an die Wurzel eines Skriptbaums gebunden. Dadurch soll ein langfristig sichtbarer, mit elliptischer Kurvenkryptografie geschützter Ausgabeschlüssel vermieden werden.

BIP 360 führt allein noch keine vollständige Post-Quantum-Signatur in Bitcoin ein. Der Vorschlag soll vielmehr eine Struktur bereitstellen, in die später quantenresistente Skriptbedingungen eingebaut werden könnten.

Stand Juli 2026 befindet sich BIP 360 im Entwurfsstatus. Es ist keine aktivierte Bitcoin-Konsensregel.

BIP 361: Migration alter Signaturen

BIP 361 beschäftigt sich mit einer möglichen Migration von heutigen ECDSA- und Schnorr-Ausgaben zu späteren Post-Quantum-Ausgabetypen.

Der Entwurf schlägt langfristige Phasen vor, in denen zunächst neue Zahlungen an quantenverwundbare Ausgabetypen eingeschränkt und später alte Signaturverfahren schrittweise aus dem aktiven System entfernt werden könnten.

Ein solcher Schritt wäre wirtschaftlich, technisch und politisch äußerst weitreichend. Schließlich könnten nicht rechtzeitig migrierte Bitcoin möglicherweise nicht mehr unter den bisherigen Bedingungen ausgegeben werden.

Auch BIP 361 ist lediglich ein Entwurf. Es besteht derzeit kein Konsens darüber, ob, wann oder in welcher Form ein solches Verfahren umgesetzt werden sollte.

Mögliche Bitcoin-Strategien gegen Quantencomputer

Eine zukünftige Quantenstrategie könnte mehrere Schritte umfassen:

  1. Auswahl und intensive Prüfung geeigneter Post-Quantum-Signaturen.
  2. Einführung eines neuen optionalen Ausgabetyps.
  3. Unterstützung durch Bitcoin Core, Wallets und Hardware-Wallets.
  4. Eine lange freiwillige Migrationsphase.
  5. Beobachtung der tatsächlichen Quantenentwicklung.
  6. Gegebenenfalls Einschränkung neuer quantenverwundbarer Ausgaben.
  7. Entscheidung über den Umgang mit dauerhaft nicht migrierten Guthaben.

Besonders der letzte Punkt ist schwierig. Würde man alte Ausgaben dauerhaft zulassen, könnten sie von einem Quantenangreifer gestohlen werden. Würde man sie sperren, könnten auch rechtmäßige Eigentümer den Zugriff verlieren.

Was können normale Bitcoin-Nutzer heute tun?

  • Aktuelle und seriöse Wallet-Software verwenden.
  • Bitcoin-Adressen nicht unnötig mehrfach verwenden.
  • Private Schlüssel und Seed-Phrasen sicher aufbewahren.
  • Keine überstürzten Transaktionen aufgrund spekulativer Quantenmeldungen ausführen.
  • Technische Entwicklungen und zukünftige Wallet-Updates beobachten.
  • Bei einer späteren Migration rechtzeitig auf neue Ausgabetypen wechseln.

Adresswiederverwendung ist bereits unabhängig von Quantencomputern aus Datenschutz- und Sicherheitsgründen problematisch. Weitere praktische Gefahren beschreibt der Artikel über typische Bitcoin-Risiken und Möglichkeiten zur Vermeidung von Problemen.

 

Häufige Missverständnisse über die Bitcoin-Technik

„Die Bitcoin liegen in meiner Wallet“

Eine Wallet enthält beziehungsweise verwaltet hauptsächlich die Schlüssel und Informationen, mit denen passende UTXOs ausgegeben werden können. Die eigentlichen Transaktionsdaten werden im Bitcoin-Netzwerk beziehungsweise in der Blockchain verwaltet.

„Miner entscheiden über alle Bitcoin-Regeln“

Miner entscheiden, welche gültigen Transaktionen sie aufnehmen und welchen gültigen Block sie aufbauen möchten. Sie können vollständig validierende Nodes jedoch nicht dazu zwingen, ungültige Blöcke zu akzeptieren.

„GitHub kontrolliert Bitcoin“

GitHub stellt die Infrastruktur für die öffentliche Codeverwaltung bereit. Das Bitcoin-Netzwerk funktioniert unabhängig davon weiter. Kopien des Quellcodes befinden sich auf sehr vielen Rechnern und könnten bei Bedarf auf andere Plattformen verschoben werden.

„Die Bitcoin-Core-Maintainer können Guthaben verändern“

Maintainer können Änderungen in ein Software-Repository übernehmen. Sie besitzen dadurch keine privaten Schlüssel fremder Wallets und können keine bestehenden Bitcoin beliebig verschieben.

Eine Softwareänderung, die fremde Guthaben umverteilen soll, müsste außerdem von den Netzwerkteilnehmern freiwillig installiert und akzeptiert werden.

„Wenn ich Bitcoin Core kompiliere, erzeuge ich Bitcoin“

Durch das Kompilieren entsteht lediglich eine ausführbare Software. Neue Bitcoin entstehen nur innerhalb gültiger Blöcke nach den festgelegten Regeln für die Blocksubvention.

„Jeder Node speichert immer die komplette Blockchain“

Ein normaler Archival Node speichert die vollständigen Blöcke. Ein Pruned Node validiert ebenfalls die Blockchain selbst, löscht danach aber ältere Blockdateien bis auf einen konfigurierten Restbestand.

„Bitcoin ist vollständig anonym“

Bitcoin ist pseudonym. Adressen enthalten nicht automatisch einen Namen, sämtliche Transaktionen sind jedoch öffentlich nachvollziehbar. Durch Börsendaten, Adresswiederverwendung und Blockchain-Analyse können Zusammenhänge hergestellt werden.

„Quantencomputer können Bitcoin schon heute knacken“

Dafür gibt es keine belastbaren Hinweise. Das theoretische Risiko ist real, die notwendige leistungsfähige und fehlertolerante Quantenhardware steht derzeit jedoch nicht zur Verfügung.

„Bitcoin kann niemals aktualisiert werden“

Bitcoin wurde bereits vielfach weiterentwickelt. Änderungen müssen allerdings kompatibel, sicher, ausführlich geprüft und von ausreichend vielen Beteiligten akzeptiert werden. Die hohe Hürde ist kein Fehler, sondern ein wichtiger Teil des Sicherheitsmodells.

 

Fazit: Bitcoin ist Software, Netzwerk und gemeinsames Regelwerk zugleich

Bitcoin funktioniert nicht deshalb, weil eine zentrale Stelle jede Transaktion kontrolliert. Das System funktioniert, weil tausende unabhängige Teilnehmer dieselben transparenten Regeln selbst überprüfen können.

Der öffentliche Bitcoin-Core-Code bildet einen wichtigen Teil dieser Infrastruktur. Er verwaltet Netzwerkverbindungen, prüft Signaturen, verarbeitet Blöcke, pflegt das UTXO-Set und stellt Schnittstellen für Wallets und andere Anwendungen bereit.

Änderungen entstehen in einem offenen, oft langsamen Entwicklungsprozess. Entwickler können Vorschläge programmieren und Maintainer können Code übernehmen. Welche Regeln tatsächlich Bedeutung erhalten, hängt jedoch davon ab, welche Software von Nodes, Unternehmen, Minern und Nutzern ausgeführt und wirtschaftlich akzeptiert wird.

Das Thema Quantencomputer zeigt besonders deutlich, warum dieser vorsichtige Prozess notwendig ist. Die heutige elliptische Kurvenkryptografie könnte langfristig angreifbar werden. Gleichzeitig sind konkrete Zeitpläne unsicher, und ein überhasteter Austausch der Signaturen könnte neue Risiken erzeugen.

Bitcoin ist deshalb weder technisch unveränderlich noch beliebig veränderbar. Es ist ein lebendes Open-Source-System, bei dem Kompatibilität, Dezentralität und überprüfbarer Konsens wichtiger sind als eine schnelle Produktentwicklung.

Wer sich neben der Technik auch mit Kauf, Handel und wirtschaftlichen Risiken beschäftigt, findet weitere Grundlagen in den Artikeln über das Funktionieren von Krypto-Börsen und das Investieren in Kryptowährungen.

 

Offizielle technische Quellen und weiterführende Dokumentation

Technischer Stand: Juli 2026. Bitcoin Core, BIPs und Post-Quantum-Verfahren werden laufend weiterentwickelt. Vor dem Kompilieren oder Testen sollten deshalb immer die Dokumentation und Release Notes der konkret verwendeten Version geprüft werden.

Kommentare 0

 

Neuen Kommentar schreiben: