Bitcoin-Verschlüsselung
Bitcoin-Verschlüsselung ist eine informelle Bezeichnung für die kryptografischen Verfahren in Bitcoin und Bitcoin-Wallets. Das öffentliche Hauptbuch ist nicht allgemein verschlüsselt: Transaktionen und Blöcke werden offen repliziert. Bitcoin nutzt vor allem Hashfunktionen und digitale Signaturen für Autorisierung und Prüfung. Verschlüsselung schützt in engeren Bereichen etwa eine Wallet-Datei oder Netzwerkverbindung.
Signaturen, Hashes und Verschlüsselung
Eine digitale Signatur belegt, dass der Inhaber eines privaten Schlüssels die abgedeckten Daten autorisierte; sie verbirgt sie nicht. Eine Hashfunktion bildet Daten auf einen festen Digest ab. Bitcoin verwendet Hashes für Transaktionskennungen, Blockheader, Proof of Work, Merkle-Bäume, Adressbildung und Commitments. Ein Hash ist keine umkehrbare Verschlüsselung. Verschlüsselung erzeugt Chiffretext für Parteien mit Entschlüsselungsschlüssel, entscheidet aber nicht über die Ausgabeberechtigung eines Bitcoin-Outputs.
Ein Datensatz ist nicht allein wegen eines Hashes unveränderlich; der Widerstand gegen Umschreiben folgt aus Konsens und Proof of Work. Eine Signatur zeigt Schlüsselkontrolle, aber nicht automatisch eine bürgerliche Identität oder die Wahrheit aller Begleitaussagen.
Schlüssel und Transaktionsautorisierung
Der private Schlüssel ist geheimes Signiermaterial. Ein öffentlicher Schlüssel ermöglicht die Prüfung. Bitcoin-Adressen kodieren Ausgabebedingungen oder Witness-Programme; sie sind nicht immer öffentliche Schlüssel und keine Konten, die Coins „enthalten“. Das Ledger speichert unspent transaction outputs mit Skriptbedingungen.
Viele ältere und SegWit-Ausgänge nutzen ECDSA über Secp256k1, Taproot verwendet BIP-340-Schnorr-Signaturen. Die Wallet erzeugt einen Digest, signiert ihn und sendet Transaktion und Autorisierungsdaten. Full Nodes prüfen Signaturen und übrige Konsensregeln.[1][2]
Der Public Key lässt sich aus dem Private Key ableiten; der umgekehrte Weg gilt für klassische Rechner bei korrekter Implementierung als unpraktikabel. Sichere Zufallswerte, Nonces, Geräte und Backups bleiben entscheidend.
Hashing im Ledger
Bitcoin wendet SHA-256 zweimal auf Blockheader an und nutzt weitere Hashkonstruktionen. Der Merkle-Root bindet Transaktionen, der Header verweist auf den vorherigen Block. Eine Änderung verändert die Hashes; ein Angreifer muss zusätzlich Proof-of-Work- und Kettenauswahlregeln erfüllen. Gehashte Public Keys sind keine dauerhafte Quantenabsicherung, weil Ausgaben Schlüsselmaterial offenlegen können und ein Protokollwechsel dennoch nötig wäre.
Wallet-Verschlüsselung und Backups
Walletsoftware kann Schlüssel oder Seed im Ruhezustand mit einem passwortabgeleiteten Schlüssel verschlüsseln. Das schützt die gesperrte Datei, nicht aber gegen schwache Passwörter, Malware bei geöffneter Wallet, verratene Recovery-Phrasen oder unverschlüsselte Kopien.
Ein Wallet-Passwort ist nicht zwingend ein Wiederherstellungsweg. HD-Wallets leiten viele Schlüssel aus einem Seed ab. Ein korrektes Seed-Backup kann wiederherstellen; die Verschlüsselung eines Geräts schützt keine Screenshots, Cloudkopien oder exportierten Schlüssel. Hardware-Wallets isolieren Schlüssel, verlangen aber weiterhin die Prüfung von Ziel, Betrag und Gebühr sowie ein geschütztes Backup.
Netzwerktransport und Datenschutz
Das Bitcoin-P2P-Protokoll übertrug Nachrichten historisch unverschlüsselt. BIP 324 definiert verschlüsselten Transport Version 2 gegen passive Beobachtung und unbemerkte Manipulation einer Verbindung. Dadurch werden öffentlich ausgestrahlte Transaktionen nicht privat.[3]
Die öffentliche Transaktionsstruktur erlaubt Graphanalyse. Adresswiederverwendung, zusammengeführte Inputs und Börsenkonten können Beziehungen sichtbar machen, ohne dass Schlüssel gestohlen werden.
Bedrohungen und Migration
Praktische Verluste entstehen meist durch gestohlene Recovery-Phrasen, Phishing, manipulierte Adressen, Malware, schwache Zufallswerte und defekte Backups. Kryptografie kann eine vom gestohlenen Schlüssel gültig signierte Transaktion nicht rückgängig machen.
Ein großer fehlertoleranter Quantencomputer könnte secp256k1 mit Shors Algorithmus angreifen. Heutige Rechner können das nicht. Kleinere logische Schaltungen verändern Ressourcenschätzungen, demonstrieren aber keinen Live-Angriff.[4] Eine spätere Migration bräuchte geprüfte Signaturvorschläge, Wallet-Unterstützung und Regeln für bereits offengelegte Public Keys.
Siehe auch
Einzelnachweise
- ↑ BIP 340, implementiert.
- ↑ Bitcoin Developer Guide, „Transactions“, geprüft am 16. September 2026.
- ↑ BIP 324, implementiert.
- ↑ Long et al., „ECDSA.Fail“, 9. September 2026.