Kryptowährungen – Eine Alternative zu SWIFT - Informatik

Kryptowährungen – Eine Alternative zu S.W.I.F.T. ?
Diplomarbeit
im Studiengang Informatik
Universität Bremen
vorgelegt von
Sascha Dückers
Matr.-Nr.: 1126262
am 30.06.2015
Gutachter:
Zweitgutachter:
Prof. Dr. Karl-Heinz Rödiger
Prof. Dr. Frieder Nake
Inhaltsverzeichnis
Inhaltsverzeichnis ........................................................................................................... 2
1 Einleitung .................................................................................................................... 5
1.1
Problemstellung .................................................................................................. 5
1.2
Motivation .......................................................................................................... 6
1.3
Ziele und Aufbau der Arbeit ............................................................................... 7
1.4
Schwierigkeiten bei der Bearbeitung .................................................................. 8
2 Grundlagen und Stand der Technik......................................................................... 9
2.1
S.W.I.F.T. ........................................................................................................... 9
2.1.1 Entstehungsgeschichte ............................................................................ 9
2.1.2 Ziele ......................................................................................................... 9
2.1.3 Technische Grundlagen ......................................................................... 10
2.1.3.1 Adressformate........................................................................... 10
2.1.3.2 SWIFT Dienstleistungen .......................................................... 11
2.1.3.3 Nachrichtenaustausch ............................................................... 12
2.1.3.4 Aufbau der SWIFT Nachrichtentypen ...................................... 13
2.1.3.5 Netzstruktur .............................................................................. 17
2.1.3.6 Operating Center (OPC) ........................................................... 18
2.1.3.7 Konzentratoren ......................................................................... 19
2.1.4 Sicherheitsrelevante Grundlagen ........................................................... 20
2.1.4.1 Implementierte Sicherheitsvorkehrungen ................................. 20
2.1.4.2 Nachteile des SWIFT-Systems ................................................. 21
2.2
Kryptowährungen ............................................................................................. 22
2.2.1 Eigene Definition Kryptowährung ........................................................ 22
2.2.2 Entstehungsgeschichte .......................................................................... 23
2.2.3 Ziele ....................................................................................................... 24
2.2.4 Technische Grundlagen ......................................................................... 24
2.2.4.1 Netzwerk ................................................................................... 25
2.2.4.2 Adressen ................................................................................... 26
2
2.2.4.3 Wallet ....................................................................................... 28
2.2.4.4 Transaktionen ........................................................................... 28
2.2.4.5 Blockchain ................................................................................ 31
2.2.5 Erzeugungsverfahren ............................................................................. 32
2.2.5.1 Mining ...................................................................................... 33
2.2.5.2 Erzeugung neuer Blöcke........................................................... 33
2.2.5.3 Berechnung der Schwierigkeit.................................................. 35
2.3
Eigenschaften und Probleme ............................................................................ 36
2.3.1 Byzantinische Generäle ......................................................................... 36
2.3.2 51% Attacke .......................................................................................... 38
2.3.3 Doppelte Zahlungen .............................................................................. 38
2.3.4 Hashleistung und Stromverbrauch ........................................................ 40
2.3.5 Blockgröße ............................................................................................ 42
2.4
Transparenz und Anonymität ........................................................................... 43
3 Praktischer Einsatz von Kryptowährungen .......................................................... 44
3.1
Beschaffung von Bitcoin .................................................................................. 44
3.1.1 Bitcoin als Gehalt / Einnahme ............................................................... 44
3.1.2 Börsen und Marktplätze ........................................................................ 44
3.1.2.1 Bitcoin.de.................................................................................. 45
3.1.2.2 Kraken.com............................................................................... 46
3.1.2.3 Coinbase.com ........................................................................... 48
3.1.3 Geldautomaten ...................................................................................... 49
3.2
Bitcoin-Programme .......................................................................................... 49
3.2.1 Full-Node-Clients .................................................................................. 50
3.2.2 SPV-Clients ........................................................................................... 51
3.2.3 Serverabhängige-Clients ....................................................................... 51
3.3
Sicherung der Bitcoin ....................................................................................... 51
3.3.1 Zugriffskontrolle ................................................................................... 52
3.3.2 Two-Factor- Authentication .................................................................. 52
3.3.2.1 Google Authenticator ............................................................... 52
3.3.2.2 Authy ........................................................................................ 53
3.3.2.3 Yubikey .................................................................................... 53
3.3.3 Hardware-Wallets.................................................................................. 53
3
3.3.4 Paperwallets .......................................................................................... 53
4 Ergebnisse der Arbeit .............................................................................................. 55
4.1
Alternative zum Transport der SWIFT-Nachrichten ........................................ 55
4.2
Alternative als internationales Zahlungsmittel ................................................. 57
5 Fragen und Ausblicke .............................................................................................. 58
6 Literaturverzeichnis................................................................................................. 59
6.1
Bücher und Zeitschriften .................................................................................. 59
6.2
Online-Quellen ................................................................................................. 59
6.3
Abkürzungsverzeichnis .................................................................................... 66
7 Abbildungsverzeichnis ............................................................................................. 67
Anhang ........................................................................................................................... 68
A Kryptografische Funktionen ................................................................................... 68
A.1 Digitale Signaturen ........................................................................................... 68
A.1.1 DSA ....................................................................................................... 69
A.1.2 Erweiterung des DSA auf elliptische Kurven ....................................... 70
A.2 Hashfunktionen ................................................................................................. 73
A.2.1 SHA-256................................................................................................ 74
A.2.2 RIPEMD-160 ........................................................................................ 76
B Alternative Kryptowährungen................................................................................ 78
B.1 Litecoin ............................................................................................................. 78
B.2 Peercoin ............................................................................................................ 78
B.3 DASH ............................................................................................................... 79
B.4 Weitere Kryptowährungen ............................................................................... 79
Eidesstattliche Erklärung............................................................................................. 80
4
1
1.1
Einleitung
Problemstellung
Das wichtigste Instrument des Zahlungsverkehrs ist die Übermittlung von Nachrichten,
welche bis zur Einführung des S.W.I.F.T.- Projekts im Juli 1977 per Brief, Telegramm
oder Fernschreiber erfolgte ([Loh 1983], S. 8) und nicht nur lange Laufzeiten hatte,
sondern zudem sehr fehleranfällig war. Die nach ersten Anlaufschwierigkeiten festgelegte Standardisierung der benötigten Adress- und Nachrichtenformate ist bis heute einer der Grundpfeiler des internationalen Zahlungsverkehrs. Im Jahr 2013 wurden über
SWIFT mehr als 22 Millionen Nachrichten täglich übermittelt. ([SWIFT 2014], S. 2)
Die Definition und Überwachung der Standards erfolgt durch die 1973 gegründete Organisation „Society for Worldwide Interbank Financial Telecommunication“, umgangssprachlich SWIFT. Der Aufsichtsrat setzt sich aus den Notenbanken Belgiens, Deutschlands, Frankreichs, Großbritanniens, Italiens, Japans, Kanadas, der Niederlande,
Schwedens, der Schweiz und den Vereinigten Staaten zusammen. Neben der Übermittlung von Finanztransaktionen an Behörden der Vereinigten Staaten im Rahmen „Krieg
gegen Terror“ nach den Terroranschlägen am 11. September 2001 in den USA wurde
am 17. März 2012 der internationale Datenverkehr zwischen SWIFT und iranischen
Banken blockiert [Bale 2012]. Nachdem durch Edward Snowden bekannt wurde, dass
Geheimdienste der Vereinigten Staaten mehrere Kanäle des SWIFT-Netzwerkes überwacht und Transaktionen abgefangen hatten, forderte das Europaparlament am 23. Oktober 2013 die Aussetzung des SWIFT-Abkommens zwischen der EU und den USA.
Dieses Abkommen erlaubt US-amerikanischen Terrorfahndern seit 2010 unter strengen
Auflagen zum Datenschutz und dem Schutz der Privatsphäre den gezielten Zugriff auf
Kontobewegungen von Verdächtigen innerhalb der EU [Feld 2013].
Wie SWIFT in einem Statement am 06. Oktober 2014 mitteilte wurde die Organisation
aufgefordert, Russland und Israel von allen internationalen Zahlungsströmen abzuschneiden [SWIFT 2014a]. Russlands stellvertretender Premierminister Igor
Schuwalow erklärte bereits am 10. September 2014, dass Russland zusammen mit China an einer Alternative arbeite, um die Abhängigkeit vom Finanzmarkt zu reduzieren.
Russische Banken benutzen aktuell bereits das UnionPay-System des gleichnamigen
Kreditkarteninstitutes für Transfers zwischen den Banken [Nikolsky 2014], [BÜSO
2014].
Neben der Abhängigkeit von Zentralbanken müssen nicht nur die Länder, sondern muss
jede juristische oder natürliche Person einer Bank Vertrauen entgegenbringen und darauf hoffen, dass Geld nicht nur entsprechend transferiert wird, sondern auch nicht ent5
wertet und zudem sicher aufbewahrt wird. Um diese Sicherheit und damit auch das Vertrauen zu gewährleisten, sind hohe Investitionen seitens der Banken notwendig und somit kleinere Zahlungen aufgrund von Zusatzkosten unwirtschaftlich.
An dieser Stelle setzt die erste Idee zur kryptographischen Währung Bitcoin an, deren
Konzept 2008 in einem Whitepaper von Satoshi Nakamoto beschrieben wurde.
Nakamoto schreibt in seiner Einleitung: “What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to
transact directly with each other without the need for a trusted third party. Transactions
that are computationally impractical to reverse would protect sellers from fraud, and
routine escrow mechanisms could easily be implemented to protect buyers” ([Nakamoto
2008], S. 1).
Es ist ein System notwendig, das auf kryptografischen Beweisen und nicht mehr auf
Vertrauen beruht und jeder Person auch unabhängig von Banken oder sonstigen Vertrauten die Übermittlung von Währungen ermöglicht. Wenn diese Übermittlung eindeutig erfolgt, nicht manipulierbar und auch nicht reversibel wäre, dann könnten komplexe
Systeme eingespart und Banken überflüssig werden oder zumindest kostengünstiger
arbeiten, wenn modernere Verfahren eingesetzt werden würden. Das Zitat aus dem Jahr
2000 von Microsoftgründer Bill Gates „Banking is neccessary, banks are not“, wie im
Buch von Markus Miller ([Miller 2005], S. 149) erwähnt, deutet ebenfalls bereits in
diese Richtung. Ob eine Kryptowährung wie Bitcoin und die damit verbundenen Protokolle und Algorithmen ein durchdachtes Nachrichtensystem wie SWIFT ersetzen oder
ergänzen können, werde ich im Folgenden näher beschreiben.
1.2
Motivation
Das Internet der Dinge fasziniert mich und ich informiere mich regelmäßig über neue
Ideen, Projekte und entsprechende Hardware. Auf der Suche nach neuen Projekten für
meinen Einplatinencomputer Raspberry PI stieß ich auf einen Artikel, der sich mit dem
Mining, also dem Schürfen der virtuellen Währung Bitcoin beschäftigte. Hierbei können über den Computer selber, aber auch über Spezialhardware elektronische Einheiten
erzeugt werden, die einen realen Gegenwert besitzen. Hierbei kamen mir die zahlreichen Werbeanzeigen zu Bitcoin in den Sinn, die ich bis dahin als unangenehme und
auch unseriöse Werbung angesehen hatte. Da ich zur selben Zeit ein geeignetes Thema
für meine Diplomarbeit suchte, beschäftigte ich mich intensiver mit dem Thema und
stellte schnell fest, das hinter dem Ganzen doch viel mehr steckt als ein weiteres System
ohne Nutzen, das wie so viele andere zuvor wieder an Aufmerksamkeit verlieren würde.
6
Zu diesem Zeitpunkt im September 2014 gab es bereits eine gewisse Akzeptanz der
Kryptowährung Bitcoin und es waren zwischenzeitlich mehrere Hundert alternative
Kryptowährungen auf Basis des frei zugänglichen Bitcoin-Programmcodes implementiert. Diese Währungen werden auch als Altcoins bezeichnet und können wie Bitcoin
über entsprechende Handelsplattformen in andere Währungen getauscht werden. Zu
diesem Zeitpunkt gab es darüber hinaus die Möglichkeit reale Produkte zu kaufen oder
die Bitcoin gegen US Dollar oder Euro zu tauschen.
Hierbei faszinierte mich vor allem die Idee, die Kryptowährung unabhängig von virtuellen oder realen Grenzen einzusetzen und -ohne die Kontrolle einer weiteren Organisation- digitale Einheiten zwischen den Anwendern auszutauschen und hierfür entsprechend einen realen Gegenwert zu erhalten. So könnte sich ein Computerspieler in Asien
in einem über das Netz verbundenen Computerspiel Rohstoffe wie Wolle erzeugen,
daraus Waren wie Kleidung produzieren und diese dann innerhalb des Spiels mit einer
Kryptowährung an einen Spieler in Europa verkaufen. Der Erlös kann dann leicht über
eine Handelsplattform in reales Geld getauscht oder über angeschlossene Unternehmen
Waren wie z.B. reale und tragbare Kleidung gekauft werden.
Ebenso könnte man ohne hohe Kosten den internationalen Zahlungsverkehr umgehen
und Geldbeträge zu Freunden, Familie oder Bekannten in andere Länder übertragen.
Öffnungszeiten von Banken oder Buchungszeitpunkte spielen für eine Kryptowährung
keine Rolle. Richtig implementiert sind Manipulationen nicht möglich, und kostenintensive Überwachung könnte wegfallen.
Da ich die Planung und Umsetzung mehrerer eCommerce-Lösungen begleitet habe und
die Schwierigkeiten, Voraussetzungen und Kosten für den Einsatz von Bezahlsystemen
kenne, bieten sich nun mit den Kryptowährungen und bereits implementierten Lösungen
diverser Zahlungsanbieter nicht nur auf privater Basis weitere Motivationsgrundlagen.
1.3
Ziele und Aufbau der Arbeit
Zunächst werde ich auf die Grundlagen der einzelnen Systeme eingehen und versuchen,
die Herausforderungen zu erörtern. Es ist die Frage zu klären, ob ein System, das über
Jahre den Anforderungen des internationalen Zahlungsverkehrs angepasst wurde und
über das fast alle Anwendungsfälle abgedeckt werden können, durch ein neues System
ergänzt oder womöglich abgelöst werden kann.
Basierend auf den bisher vorhandenen Implementierungen werde ich die gewonnenen
Erkenntnisse zusammenfassen und eine mögliche Umsetzung beschreiben.
Abschließend werde ich Fragen, die im Rahmen der Arbeit entstanden sind, erläutern
und einen Ausblick auf die folgenden Monate und Jahre verfassen.
7
1.4
Schwierigkeiten bei der Bearbeitung
Sowohl die Informationen zu SWIFT und dem aktuell eingesetzten SWIFTNet, als auch
die Quellen zu Kryptowährungen sind als nahezu tagesaktuell zu bezeichnen. Fachliteratur zu SWIFT ist rar, und es wird meist auf bereits veraltete Strukturen eingegangen.
Hier muss auf Publikationen einzelner Unternehmen zurückgegriffen werden, die teilweise nicht einmal in druckbaren Dokumentationen vorliegen. Viele Informationen zu
der Kryptowährung Bitcoin sind selbst auf offiziellen Webseiten unvollständig und
auch nicht mehr auf dem aktuellen Stand. Diese haben für die Betrachtung, ob Kryptowährungen eine Alternative zum bestehenden SWIFT-System darstellen, jedoch keine
Relevanz.
Es werden im Rahmen der Arbeit einige englische Bezeichnungen und Wörter verwendet, welche so auch in deutschen Pressemeldungen und Fachliteratur eingesetzt werden.
Aufgrund der Aktualität sind diese nicht Bestandteil der deutschen Rechtschreibung und
weder vom Pons-Verlag (PONS GmbH, Stuttgart) noch im Duden (Bibliographisches
Institut GmbH, Berlin) erfasst. Hierzu gehören Bezeichnungen zu Algorithmen und
Fachbegriffen, aber vor allem um das im Kapitel 2.2.4.3 beschriebene „Wallet“, also der
bei Kryptowährungen eingesetzten Brieftasche bzw. Geldbörse, und die „Blockchain“,
einer Aneinanderreihung von Blöcken, die in wenigen Fachartikeln auch als Blockkette
bezeichnet und die im Kapitel 2.2.4.5 genauer beschrieben wird.
8
2
2.1
Grundlagen und Stand der Technik
S.W.I.F.T.
2.1.1 Entstehungsgeschichte
Um den Zahlungsverkehr über Länder- und Währungsgrenzen hinweg zu ermöglichen,
ist es nötig, dass ein Auftraggeber (Schuldner) die Möglichkeit bekommt, dem Zahlungsempfänger (Gläubiger) mitzuteilen, dass ein bestimmtes Guthaben zur Verfügung
steht und übertragen werden soll. Hierbei ist es nicht entscheidend, woraus genau dieses
Guthaben besteht, sondern lediglich, dass die benötigte Menge bereitsteht und getauscht
wird. Vor der Realisierung des SWIFT-Projektes geschah dies sehr ineffizient per
Briefpost, Telegramm oder Fernschreiber ([LOH 1983], S. 8). Auf dem Kommunikationswege konnten Nachrichteninhalte verlorengehen oder waren nicht mehr eindeutig.
Deshalb war es nötig, diese Nachrichten mehrfach zu übertragen. Für diese Übertragung
und die Auswertung der Nachrichten wurden teils immense personelle Ressourcen in
eigens eingerichteten Abteilungen der Banken benötigt. Hierdurch wurde die Rentabilität der Banken erheblich reduziert; im Zusammenhang mit der damaligen Wachstumsrate im Zahlungsverkehr war dies ökonomisch kaum noch vertretbar.
Um diese Probleme in den Griff zu bekommen und ein effizienteres System zu schaffen, wurde das S.W.I.F.T.-Projekt ins Leben gerufen und am 03. Mai 1973 die Society
for Worldwide Interbank Financial Telecommunication (SWIFT) mit Unterstützung von
239 Banken aus 15 Ländern in Brüssel als Gesellschaft belgischen Rechts ([Loh 1983],
S. 18) gegründet.
2.1.2 Ziele
Die wesentlichen Ziele von S.W.I.F.T. sind die Beschleunigung des Nachrichtenaustausches durch beleglose Abwicklung des Zahlungsverkehrs und die Reduzierung der Risiken und Kosten. Um Fehler und Manipulationen besser zu erkennen und die Belege
schneller und kosteneffizienter bearbeiten zu können, wurden die Nachrichten standardisiert.
Aufgrund der unterschiedlichen Organisation der verschiedenen Banken der einzelnen
Länder dauerte diese Standardisierung deutlich länger als geplant; der Betrieb des neuen
Systems konnte erst mit mehr als anderthalb Jahren Verspätung im Juli 1977 aufgenommen werden. Bereits zum Jahresende 1977 waren mehr als 500 Banken aus 22 unterschiedlichen Ländern am Nachrichtenaustausch beteiligt, und es wurden mehr als 3
Millionen Nachrichten ausgetauscht.
9
2.1.3 Technische Grundlagen
2.1.3.1 Adressformate
Damit Nachrichten auch der richtigen Bank zugestellt werden können, bedarf es zunächst einer klaren Bezeichnung des beteiligten Finanzinstitutes. Dieser Business Identifier Code (kurz: BIC) wird auch SWIFT-Code genannt und ist in der ISO 9362 beschrieben.
Der BIC besteht aus 8 oder 11 Stellen und beinhaltet folgende Informationen:
1. Bankcode (bank code)
4 Stellen von der Bank frei gewählte alphanumerische Zeichen
2. Ländercode (country code)
2 Stellen alphanumerischer ISO-Code des Landes (ISO 3166-1)
3. Ortsangabe (location code)
2 Stellen alphanumerisch zur Ortsangabe
4. Filiale oder Abteilung (branch code)
3 Stellen alphanumerisch zur Bezeichnung der unterschiedlichen Filialen.
Dieser Code kann auch weggelassen werden.
Bei der Ortsangabe darf das erste Zeichen nicht die Ziffer 0 oder 1 sein und als zweites
Zeichen ist der Buchstabe O nicht erlaubt. Das zweite Zeichen hat zudem noch eine
besondere Bedeutung, wenn es sich hierbei um eine Ziffer handelt.
0 - die eingesetzte BIC dient nur Testzwecken
1 - der SWIFT-Teilnehmer ist passiv
2 - die Transaktionskosten werden vom Empfänger übernommen
Der BIC kann auch zur Identifikation von Betrieben außerhalb des Finanzsektors eingesetzt werden; er wird dann als Business Entity Identifier bezeichnet. Für Überweisungen
innerhalb der Europäischen Union wird der BIC nicht mehr benötigt, da das Routing
komplett über die IBAN1 erfolgen kann.
Die IBAN besteht aus maximal 34 Stellen und setzt sich aus der Länderkennung, Kontonummer und der Bankleitzahl zusammen. Um Fehler bei der Eingabe oder Übertragung zu verhindern, wird zusätzlich eine zweistellige Prüfziffer eingefügt.
1
IBAN steht für International Bank Account Number
10
Es ergibt sich folgender Aufbau für eine IBAN
1. Länderkennung
2 Stellen alphanumerischer ISO-Code des Landes
2. Prüfziffer
2 Stellen numerisch
3. Bankleitzahl
8 Stellen numerisch
4. Kontonummer
10 Stellen numerisch. Wenn die Kontonummer aus weniger als 10 Stellen besteht, dann
wird diese linksbündig mit Nullen aufgefüllt.
Für die Adressierung innerhalb des SWIFT-Netzes werden Logical Terminal IDs (LT)
verwendet, die nicht Teil des beschriebenen ISO 9362 Standards sind. Diese sind immer
12-stellig und setzen sich aus dem acht- oder elfstelligen BIC zusammen. Der achtstellige BIC wird mit vier X aufgefüllt und bei dem elfstelligen BIC ein X an der neunten
Stelle vor dem Branch Code eingefügt. Mit Hilfe der neunten Stelle können innerhalb
des SWIFT-Systems die logischen Verbindungskanäle identifiziert werden. Einzelne
Computerterminals können mit mehreren Logical Terminal IDs eingerichtet sein, die
mit A, B, C usw. an der neunten Stelle der ID referenziert werden.
Kombiniert mit dem Tag, der Sitzungs- und Sequenznummer ergibt die Logical Terminal ID eine Message Input Referenz (MIR) für eingehende und eine Message Output
Reference (MOR) für ausgehende Nachrichten.
2.1.3.2 SWIFT Dienstleistungen
Die beiden wichtigsten von SWIFT angebotenen Dienste sind General Purpose Application (GPA) und Financial Application (FIN).
GPA erlaubt es, Systemmeldungen bzw. Nachrichten von einem Anwender zum
SWIFT-System zu übermitteln und auch zu empfangen. Die Kommunikation von Anwendern untereinander ist ausgeschlossen.
FIN ist der für Endanwender wichtigste SWIFT-Dienst. Die Finanzanwendung stellt
alle notwendigen Nachrichtentypen zur Verfügung, um die relevanten Finanzangelegenheiten der Anwender untereinander zu ermöglichen. Hierzu gehören neben Systemmeldungen MT0nn auch alle Anwender-zu-Anwender Nachrichtentypen MT1nn bis
M9nn [SWIFT 2014c] und Wartungsmeldungen wie Empfangsbestätigungen.
11
2.1.3.3 Nachrichtenaustausch
Die von SWIFT standardisierten Datenformate für den Nachrichtenaustausch werden
Message Types (MT) genannt und kontinuierlich mit jährlichen Veröffentlichungen den
neuen Anforderungen des Finanzmarktes angepasst.
Nachrichten werden innerhalb des SWIFT-Systems auf korrekten Aufbau und Manipulationen geprüft, eindeutig referenziert und verschlüsselt übertragen, so dass die Sicherheit der Nachrichten gewährleistet werden kann. Die Teilnehmer des Netzwerkes können darüber hinaus individuelle Schlüssel austauschen, um Ihre Nachrichten zu signieren. Bis 2009 wurde dies durch das SWIFT-Verschlüsselungsschema Bilateral Key Exchange (BKE) realisiert, bei dem der Anwender entweder über die SWIFT-Software
oder ein zertifiziertes Kartenlesegerät einen BKE-Key erzeugen konnte. Für die Verschlüsselung innerhalb der Lesegeräte werden seit 1994 Authentifizierungsschlüssel mit
1024bit RSA eingesetzt. Mit der Umstellung auf SWIFTNet Phase 2 wurde BKE am
01. Januar 2009 komplett durch das neue Softwaresystem „Relationship Management
Application (RMA)“ ersetzt.
SWIFT Nachrichten werden über ein festgelegtes Schema identifiziert. Sie beginnen
alle mit den Zeichen „MT“ für Message Type, gefolgt von einer dreistelligen Nummer.
Über die erste Ziffer ist die Kategorie der Nachricht festgelegt. Kategorien fassen Nachrichten aus zusammengehörenden Finanzinstrumenten und -diensten zusammen
[SWIFT 2014c].
MT0nn
System Messages
Systemnachrichten
MT1nn
Customer Payments
Zahlungen von Endkunden
z.B. MT103 Kundenüberweisung
MT2nn
Financial Institution Transfers
Übertrag zwischen Finanzinstituten
z.B. MT202 Bankenauftrag
MT3nn
FX, Money Market & Derivatives
Devisen- und Geldhandel
z.B. MT300 Bestätigung Devisengeschäft
MT4nn
Collections and cash letters
Inkasso und Kreditbriefe
z.B. MT400 Zahlungsanzeige
MT5nn
Securities Markets
Wertpapier-Transaktionen
MT6nn
Precious Metals & Syndications
Edelmetall- und Konsortialgeschäfte
MT7nn
Documentary Credits & Guarantees
Dokumentenakkreditive und Garantien
MT8nn
Travellers Cheques
Reisescheck-Transaktionen
MT9nn
Cash Management & Customer Status
Kassenführung und Kundeninformationen
12
Die letzten beiden Ziffern kennzeichnen den Nachrichtentyp. Hier wurde von SWIFT
zusätzlich eine spezielle Teilmenge, die „Common Group“ festgelegt, die auf gleiche
Ziffern enden und die gleiche Nachricht in jeder Kategorie referenziert.
MTn90
Advice of Charges, Interest and Other
Adjustments
Informationen für den Kontoinhabers zu Gebühren, Zinsen
und Änderungen zu seinem Konto
MTn91
Request for Payment of Charges, Interest and Other Expenses
Anfrage zur Zahlung von Gebühren, Zinsen oder anderen
Kosten
MTn92
Request for Cancellation
Anfrage zur Löschung einer Nachricht
MTn95
Queries
Anfragen
MTn96
Answers
Antworten
MTn98
Proprietary Message
Formatvorlagen für eigene Anwendungen und noch nicht
vorhandene Definitionen
MTn99
Free Format Message
Freie Nachricht
Jede Nachricht bekommt eine eindeutige Kennung. Diese setzt sich aus einer vierstelligen Sitzungsnummer, die beim Einloggen am Terminal erzeugt wird, und einer
sechsstelligen Sequenznummer zusammen. Wird die Nachricht vom Anwender in das
SWIFT-System geschickt, dann bezeichnet man diese Kennung als Input Sequence
Number (ISN). Eine Nachricht vom SWIFT-System zum Anwender wird mit einer
Output Sequence Number (OSN) versehen. Innerhalb des SWIFT-Systems wird geprüft,
ob die vorgeschriebene Nummernreihenfolge der OSN oder ISN eingehalten wurde.
Wenn die Prüfung fehlschlägt, dann wird die entsprechende Nachricht abgewiesen und
nicht weitergeleitet.
2.1.3.4 Aufbau der SWIFT Nachrichtentypen
Im Jahr 2007 wurde mit der Umstellung der MT-Nachrichtenformate auf XML-basierte
Definitionen (MX Nachrichten) nach dem Standard ISO 20022 begonnen. Dieser Standard kommt auch bei SEPA-Überweisungen zum Einsatz. Hier stellt SWIFT aber lediglich sein Leitungsnetz zur Verfügung. Für Erstellung von Implementierungsspezifikationen und weiterführenden Standardisierungen ist der European Payments Council
(EPC) zuständig.
Da bereits Ende des Jahres 1990 erkannt wurde, dass die ursprünglich eingesetzten
Nachrichtentypen nach ISO 7775 zu restriktiv für die Ansprüche des modernen Finanzmarktes waren, wurden ab 1999 die neuen Nachrichtentypen nach ISO 15022 ein13
gesetzt. Alle alten ISO 7775 Nachrichtentypen wurden im Jahr 2002 komplett aus dem
Netzwerk entfernt.
Eine Nachricht (MT) gliedert sich in fünf Blöcke, die jeweils in geschweiften Klammern eingeschlossen sind:
1.
2.
3.
4.
5.
Basic Header Block
Application Header Block
User Header Block
Content Block
Trailer Block
Der Basic Header Block hat eine feste Länge
a
b
c
d
e
f
1:
F
01
BANKEURXXXX
1234
123456
a)
b)
c)
d)
e)
f)
Blockkennung, immer „1“
Anwendungskennung, F=FIN, A=GPA oder L=GPA (Logindaten)
Dienstkennung, 01 = FIN/GPA, 21=ACK/NAK (Positive bzw. negative Rückmeldung)
BIC der Bank mit dem eingesetzten Terminal
Vom Computerterminal generierte vierstellige Sitzungsnummer (mit Nullen aufgefüllt)
Vom Computerterminal generierte sechsstellige Sequenznummer (mit Nullen aufgefüllt)
Der Application Header hat je nachdem, ob die Nachricht ins SWIFT-System gesendet
oder vom SWIFT-System empfangen wird, einen unterschiedlichen Aufbau.
Eingabestruktur für Nachrichten an das SWIFT-System
a
b
c
d
e
f
g
2:
I
102
BANKEURXXXX
U
1
003
a)
b)
c)
d)
e)
f)
Blockkennung, immer „2“
I = Input (Eingabe)
Nachrichtentyp
BIC des Empfängers
Nachrichtenpriorität, S=System, N=Normal und U=Dringend (Urgent)
Sendeüberwachung, 1= MT010 (Non Delivery Warning), 2=MT011 (Delivery Notification) und 3=Beide. Gültige Angaben: U1, U2, N2 oder nur N
g) Zeitangabe, wann eine Warnung zu einer nicht übermittelten Nachricht erzeugt wird.
Gültige Werte: für U = 003 (15 Minuten), für N = 020 (100 Minuten)
14
Ausgabestruktur für Nachrichten vom SWIFT-System
a
b
c
d
e
f
2:
O
102
1000
031234BANKEURXXXX123456
150103
a)
b)
c)
d)
e)
f)
g)
g
Blockkennung, immer „2“
O = Output (Ausgabe)
Nachrichtentyp
Eingabezeit des Absenders
Eingabenachrichtenkennung des Absenders (MIR)
Ausgabedatum des Empfängers
Nachrichtenpriorität
Der User Header und der Content Block können weitere Unterblöcke oder Nachrichtenfelder beinhalten, welche durch entsprechende Tags gekennzeichnet sind. Die definierten Nachrichtenfelder werden in sechs Gruppen untergliedert ([Loh 1983], S. 46).
1.
2.
3.
4.
5.
6.
Sicherheitsfelder
Referenzfelder
Daten- und Wertfelder
Bank- und Kundenadressfelder
Buchungsfelder
Informationen und Instruktionen
Einige Beispiele für Nachrichtenfelder (Auszug)
Security
Sicherheitsfelder
10
Copy of Header
Kopie des Nachrichtenkopfes
15
Test Key
Testschlüssel
References
Referenzfelder
20
Transaction Reference Number (TRN)
Transaktionsnummer
21
TRN Supplement
Zusatz zur Transaktionsnummer
22
Reference to Related Message/Transaction
Referenz zur zugehörigen Nachricht/Transaktion
25
Statement Number/Page Number
Kontoauszugsnummer / Seitennummer
28
Account Identification
Kontoidentifikation / Kontonummer
Data and Values
Daten- und Wertfelder
30
Date
Datum
32
First Amount Field
Erste Menge
33
Second Amount Field
Zweite Menge
36
Exchange Rate
Umrechnungskurs
15
37
Interest Rate
Zinskurs
Banks and Customers
Bank- und Kundenadressfelder
50
Ordering Customer (By Order of)
Auftraggeber
52
Ordering Bank
Bank des Auftraggebers
53
Sender’s Correspondent Bank
(Reimbursement)
Korrespondenzbank des Auftraggebers
(für Rückzahlungen)
54
Receiver’s Correspondent Office
Korrespondenzbank des Empfängers
Der User Header Block ist optional
a
b
c
3:
{113:xxxx}
{108:abcdefg1234567}
Der Content Block enthält die eigentliche MTnnn Nachricht und die Information, die
die meisten Endanwender sehen. Alle anderen Blöcke werden in der Regel vor der Darstellung entfernt und sind nicht sichtbar. Ein typischer Content Block hat folgenden
Aufbau:
{4:<CrLf>
:20:MT101-Beispiel<CrLf>
:28D:00001/00001<CrLf>
:30:040403<CrLf>
:21:Start B-Seq<CrLf>
:32B:EUR1, <CrLf>
:23E:CMTO<CrLf>
:50G:/Kontonummer<CrLf>
BANKDEM0XXX<CrLf>
:59A:/Kontonummer<CrLf>
BANKDEM0XXX<CrLf>
:71A:SHA <CrLf>
-}
Der den Umschlag (Envelope) abschließende Trailer Block hat immer die Blockkennung 5: und wird nach dem Content Block am Ende der Nachricht angefügt. Dieser enthält unterschiedliche Nachrichtenfelder, die durch entsprechende Schlüsselwörter bezeichnet werden.
MAC
Der Message Authentification Code (MAC) wird auf Basis der Gesamtinformation der
Nachricht und einem dem Empfänger bekannten Schlüssel berechnet. Der hierzu ver-
16
wendete Algorithmus ist geheim. Der MAC wird in den Nachrichtenkategorien
Nachrichtenkategorien 1, 2, 3,
4, 5, hauptsächlich in 6, 7 und 8 und bei MT304 verwendet.
CHK
Eine Prüfsumme wird für alle Nachrichtentypen berechnet und dem Trailer Block hinhi
zugefügt.
PDE
Ein „Possible
Possible Duplicate Emission“-Hinweis,
Emission“ Hinweis, wird der Nachricht hinzugefügt,
hinzug
wenn der
Anwender vermutet, die Nachricht bereits versendet zu haben.
PDM
Ein „Possible
Possible Duplicate Message”-Hinweis,
Message” Hinweis, wird der Nachricht vom SWIFT-System
SWIFT
hinzugefügt, wenn angenommen wird, dass die Nachricht bereits übermittelt wurde.
DLM
Wenn eine dringende
ringende Nachricht nicht innerhalb von 15 Minuten oder eine normale
Nachricht nicht innerhalb von 100 Minuten übermittelt wurde, dann fügt das SWIFTSWIFT
System der Nachricht ein DLM-Nachrichtenfeld
DLM
hinzu.
2.1.3.5 Netzstruktur
Das SWIFT-System
System wurde von 2001 bis 2005
005 von einem paketvermitteltem Netz (X.25
Protokoll), welches über das Telefonnetz betrieben wurde, auf ein Internet basiertes IPIP
Netzwerk umgestellt. Das System wird seit diesem Zeitpunkt als SWIFTNet bezeichbezeic
net. Alle Nachrichten werden als XML-Datei
XML
übertragen
ertragen und in unterschiedliche KomKo
munikationsprotokolle untergliedert.
Abbildung 1: Architektur des SWIFT-Systems [C24 2014]
17
Das SWIFT-Netzwerk besteht aus drei Rechenzentren (Operating Center), die in
Zoeterwoude (Niederlande), Culpeper, Virginia (USA) und seit Anfang 2013 in Diessenhofen (Schweiz) betrieben werden. Der Bau des neuen Rechenzentrums in der
Schweiz wurde Anfang 2010 beschlossen, da vom EU-Parlament eine Lösung gefordert
wurde, um die Überwachung des digitalen Zahlungsverkehrs durch amerikanische Behörden zu verhindern [NZZ 2013].
Bis zum Anschluss des Operating Centers (OPC) in der Schweiz wurden alle Daten in
den Rechenzentren gespiegelt, so dass bis dahin bei den vorhandenen Rechenzentren
alle Daten abgefragt werden konnten. Aktuell werden die Operation Center fest definierten Zonen zugeordnet und die Daten für den europäischen Zahlungsverkehr werden
ausschließlich in den Niederlanden und der Schweiz verarbeitet. Alle beteiligten Banken sind innerhalb Ihres Landes über nationale Rechenzentren, den so genannten Konzentrationen, mit speziell eingerichteten Standleitungen verbunden. Jeder Konzentrator
ist über eine Hauptleitung mit seinem zuständigen OPC und über eine Reserveleitung
mit einer anderen Zentrale verbunden.
Der Anwender teilt seiner Bank A entsprechend über ein geeignetes Terminal mit, dass
er einen bestimmten Betrag zu einer Firma C bei der Bank B im Ausland überweisen
möchte. Bank A erzeugt die entsprechende SWIFT-Nachricht und leitet diese über den
zuständigen Konzentrator an das entsprechende Operation Center weiter, von dem die
absendende Bank eine Antwort bekommt. Anschließend sendet das Operation Center
die Nachricht über den entsprechenden Konzentrator des Empfängerlandes und von dort
ohne weitere Verzögerung an die Empfängerbank weitergeleitet, wo sie je nach Priorität
in die Datenausgabeschlange für die Bank des Zahlungsempfängers gestellt wird
([Schimansky/Bunte/Lwowski 2011], § 51a). Die Nachricht wird in der Regel innerhalb
von 5 Minuten, bei dringenden Nachrichten innerhalb von 1 Minute übermittelt und
nach Empfang auf einem Terminal angezeigt oder ausgedruckt und der kontoführenden
Stelle zur Disposition zur Verfügung gestellt. Hier steht nun der angewiesene Betrag der
Empfängerfirma C zur Verfügung.
2.1.3.6 Operating Center (OPC)
Von den drei Schaltzentralen des SWIFT-Netzwerkes wird jeweils eins für die Datenverarbeitung und eins als Backuplösung implementiert. Bei dem Ausfall des ersten Rechenzentrums wird die Verarbeitung umgehend von einem zweiten übernommen, wobei
beide auch zum Spiegeln der Daten des jeweils anderen zur Verfügung stehen. Hier gab
es bis 2013 für den europäischen Zahlungsverkehr nur das Rechenzentrum in den USA
als Ausweichmöglichkeit bei Ausfall und zur Spiegelung der Daten.
18
Zu den Aufgaben der Operating Center gehört: ([Loh 1983], S. 61)
1.
2.
3.
4.
5.
6.
7.
8.
9.
Nachrichtenempfang und -verarbeitung
Senden von Statusmitteilungen (z.B. Empfangsbenachrichtigungen)
Verifizierung der Nachrichten
Speicherung der Nachrichten (bis zu 124 Tage)
Weiterleiten der Nachrichten an den Empfänger, sobald eine Leitung zur Verfügung
steht
Wiederauffinden von Nachrichten
Überwachung des gesamten Nachrichtennetzes
Absicherung gegen Übertragungsfehler
Absicherung gegen Manipulation und Betrugsversuche
Das Operating Center verarbeitet die empfangenen Daten der Konzentratoren und leitet
diese an andere Konzentratoren im Netzwerk weiter. Bei einem Komplettausfall kann
eine der beiden verbliebenen Schaltzentralen die Arbeit übernehmen.
2.1.3.7 Konzentratoren
Die nationalen Rechenzentren des SWIFT-Netzes werden als Konzentratoren bezeichnet und sind ein Bindeglied zwischen den Eingabeterminals der angeschlossenen Banken und den Schaltzentralen. Während die Schaltzentralen direkt von S.W.I.F.T. geplant
und betrieben werden, kommen für die Konzentratoren auch beliebige nationale Rechenzentren in Frage, die den Standardanforderungen bezüglich Sicherheit und Verfügbarkeit genügen.
Zu den Aufgaben der Konzentratoren zählen:
1. Konzentration der eingehenden Leitungen auf eine Leitung zur Übermittlung an die
Schaltzentralen (OPC)
2. Verteilung der von der Schaltzentrale empfangenen Nachrichten an die entsprechenden
Banken
3. Pufferung der Übermittlungsgeschwindigkeit der eingehenden Leitungen
4. Übersetzung der Nachrichten in XML-Dateien für SWIFTNet
Die Konzentratoren verarbeiten nicht den Inhalt der Nachrichten sondern passen gegebenenfalls deren Struktur an die Voraussetzungen von SWIFTNet an und sorgen für die
ordnungsgemäße Übermittlung. Im Rahmen der Umstellung von X.25 auf die im IPNetz verwendeten XML-Dateien konnten die Konzentratoren die entsprechende Umwandlung bzw. Erweiterung vornehmen. Wenn über eine Absenderbank eine Nachricht
versendet werden soll, muss zunächst die Verfügbarkeit der Leitung geprüft werden.
Der Status wird der Bank gemeldet und die Nachricht gegebenenfalls zur Weiterleitung
in eine Warteschlage gestellt und der Vorgang entsprechend protokolliert.
19
2.1.4 Sicherheitsrelevante Grundlagen
Jedes an das SWIFT-System angeschlossene Rechenzentrum muss mindestens die
Standardanforderungen bezüglich Zugangskontrolle, Verfügbarkeit und Ausfallsicherheit erfüllen. Hierzu gehören neben der Überwachung der begehbaren Bereiche und der
Luftfeuchtigkeit auch ein Brandschutz und eine entsprechende Ausweichlösung. Eine
genauere Spezifizierung kann im Rahmen dieser Arbeit aufgrund von fehlenden Quellen nicht aufgeführt werden.
Neben den sicherheitsrelevanten Hardwareanforderungen wurde insbesondere während
der Planung des Netzwerkes auf Sicherheitsmechanismen innerhalb des Systems geachtet und diese implementiert.
2.1.4.1 Implementierte Sicherheitsvorkehrungen
Login
Jeder Anwender, der Nachrichten in das SWIFT-System eingeben oder empfangen
möchte, muss sich am entsprechenden Terminal des angeschlossenen Unternehmens
bzw. der kontoführenden Bank authentifizieren. Hierzu werden unterschiedliche Verfahren eingesetzt um einen gültigen Autorisierungscode zu übermitteln, hierdurch den
Anwender eindeutig zu identifizieren und somit den unbefugten Zugriff zu verhindern.
Beim Login wird eine Sitzungs- und eine Sequenznummer zur geöffneten Leitung erzeugt und der Vorgang so eindeutig identifizierbar.
Sequenznummern
Um zu gewährleisten, dass keine Nachricht verloren geht, werden Nachrichten mit unterschiedlichen Sequenznummern ausgestattet. Hierbei unterscheidet man zwischen
Eingangsnummern, die bei der Eingabe am Terminal ins System erzeugt werden und
solche die aus dem System erzeugt werden und somit abgehend sind. Diese ISN und
OSN wurden bereits im Kapitel 2.1.3.3 (Nachrichtenaustausch) beschrieben und jeder
SWIFT-Nachricht am Ende des Basic Header Blocks eingefügt. Das System prüft bei
jeder Nachricht, ob die angegebene Nummer zur aktuellen Nummernreihenfolge passt.
Nachrichten mit fehlerhaften ISN werden abgewiesen und nicht weitergeleitet. Taucht
eine Nachricht mit einer OSN außerhalb der Nummernreihenfolge auf, muss die betroffene Bank eigenverantwortlich den Sachverhalt aufklären und entsprechende Maßnahmen ergreifen.
Authentikator
Der Message Authentication Code (MAC) dient zur Absicherung der Nachrichten zwischen zwei angeschlossenen Banken, die hierzu bilateral Schlüssel austauschen. Diese
Schlüssel werden verwendet, um eine Prüfsumme über den gesamten Nachrichteninhalt
zu erzeugen, welche im Trailer Block mit dem entsprechenden Schlüsselwort versehen
20
und übertragen werden. Innerhalb des SWIFT-Systems wird der MAC nicht weiter berücksichtigt, eine Manipulation würde bei der empfangenden Bank sofort auffallen.
Verschlüsselung
Damit die Nachrichten zwischen den Konzentratoren und den OPC nicht von jedem
abgefangen und gelesen werden können, werden am Ende jeder Leitung spezielle Verschlüsselungseinheiten installiert. Vor jedem Senden werden hier aus jeder Nachricht
arithmetische Funktionen gebildet. Somit ergeben sich für jede Übertragung der Nachricht ganz unterschiedliche Zeichenfolgen. Durch den Austausch der eingesetzten Funktionen zwischen dem Konzentrator und dem korrespondierenden OPC, kann der Nachrichtentext beim Empfänger wieder komplett rekonstruiert werden.
2.1.4.2 Nachteile des SWIFT-Systems
Monopolisierung
Mit mehr als 22 Millionen übermittelten Nachrichten täglich ([SWIFT 2014], S. 2) wird
der größte Anteil der internationalen Geldtransfers über die SWIFT-Systeme abgewickelt. Sollte aus irgendeinem Grund ein Land aus dem SWIFT-Netzwerk ausgeschlossen werden, dann ist meist keine alternative Zahlungsmöglichkeit einsetzbar. Obwohl
im Oktober 2014 SWIFT den geforderten Ausschluss von Israel und Russland aus dem
System ablehnte mit dem Hinweis unabhängig zu sein und ausschließlich europäischem
Recht zu unterliegen [SWIFT 2014a], bleibt nach dem Ausschluss des Irans in 2012
eine begründete Furcht bei den angeschlossenen Ländern, ihre internationalen Zahlungen nicht mehr ausführen zu können. So ist es nicht verwunderlich, dass Länder wie
Russland ein großes Interesse an Alternativen haben und neue Partnerschaften eingehen.
Datenschutz
Innerhalb des SWIFT-Systems wird sorgfältig darauf geachtet, dass Daten nicht in die
Hände von Dritten gelangen und dass das System nicht ausspioniert werden kann. Das
SWIFT-Abkommen von 2010 zeigt jedoch, dass in Absprache mit einzelnen Behörden
ein Zugriff auf Daten verdächtiger Personen möglich ist.
Fehlende Alternativen
Es gibt bei einem Totalausfall des Systems keine Möglichkeit, kurzfristig auf ein alternatives System umzustellen, welches die Anzahl der Transaktionen bewältigen könnte.
Auch eine manuelle Bearbeitung und die Übermittlung der Daten über andere Kommunikationswege, wie zu der Zeit vor SWIFT, ist nicht mehr realisierbar. Hierfür fehlt es
an Fachpersonal, da im Rahmen der jeweiligen Ausbildungsgänge praktisch keinerlei
Wissen vermittelt wird, um solche Szenarien abzudecken. Doch auch unter Anleitung
wäre es nicht -mehr- möglich, die große Anzahl der täglichen Daten manuell abzuwi21
ckeln. Ein Großteil der Transaktionen ist zeitkritisch und also an Termine gebunden.
Ein Ausfall des Systems könnte ganze Wirtschaftszweige zum Erliegen bringen. Die
Suisse Bank beziffert auf Ihrer Website das tägliche Transaktionsvolumen auf 7,5 Billionen Euro [SUISSE BANK 2014]. Der wirtschaftliche Schaden, der allen beteiligten
Banken und Unternehmen schon bei einem Teilausfall des Systems entstehen würde, ist
kaum abschätzbar und lässt sich in Anbetracht der hohen Transfersummen nur erahnen.
2.2
Kryptowährungen
Unter einer Währung versteht man die Zusammenfassung der unterschiedlichen Geldsorten eines Staates ([Schricker/Rubin 1992], S. 134). Welche Geldsorten es gibt, wie
diese aussehen, heißen und wie viele Banknoten oder Münzen im Umlauf sind, wird
über eine Geldverfassung bzw. Geldordnung des jeweiligen Landes oder des Gültigkeitsbereiches geregelt. Ziel einer Währung ist es, ein akzeptiertes Tauschmittel bereitzustellen, mit dem Waren gekauft werden können. Die zum Tausch eingesetzten Banknoten und Münzen haben bis auf das eventuell eingesetzte Material (Papier, Metall,
Gold etc.) keinen intrinsischen Wert und werden deshalb als Fiatgeld bezeichnet. Eine
kryptografische Währung ist entsprechend eine elektronische Einheit, die von Personen
innerhalb einer Gemeinschaft akzeptiert wird. Jede Person mit Zugriff auf einen Computer, der mit dem Internet verbunden ist, kann diese Einheit als Tauschmittel akzeptieren. Die Bezeichnung Kryptowährung kann entsprechend auf jedes elektronische Verfahren angewandt werden, das Einheiten besitzt, die als Tauschmittel akzeptiert werden.
Um die Akzeptanz, die Verbreitung und den Wert der einzelnen Währung zu bestimmen, werden in den folgenden Kapiteln geeignete Systeme und Verfahren vorgestellt.
2.2.1 Eigene Definition Kryptowährung
Ich werde in der Arbeit hauptsächlich die aktuell noch stärkste Kryptowährung Bitcoin
(BTC) behandeln und Besonderheiten einiger alternativer Kryptowährungen im Anhang
zusammenfassen. Aufgrund unterschiedlicher Betrachtungsweisen ist es schwierig zu
bestimmen, ob eine bestimmte Kryptowährung als äquivalente Alternative für ein bestehendes System wie SWIFT in Frage kommt.
Die Europäische Zentralbank (EZB) unterscheidet beispielsweise in Ihrer Veröffentlichung zu virtuellen Währungen drei unterschiedliche Typen ([ECB 2012], S. 15).
Typ 1: Geschlossene Systeme, wie sie in Online-Games verwendet werden.
Typ 2: Systeme, die nur in eine Richtung laufen, wobei es einen Umrechnungskurs zum
Ankauf von virtuellem Geld gibt, um Waren und Dienstleistungen danach erwerben zu
können.
22
Typ 3: Systeme, die in beide Richtungen gehen, wie jede andere frei konvertierbare
Währung, für die es einen Kurs für den Ankauf und einen anderen für den Verkauf gibt.
Damit können dann auch virtuelle oder reale Waren und Dienste gekauft werden.
Neben der Kryptowährung Bitcoin stuft die Europäische Zentralbank auch ein System
der im San Francisco ansässigen Firma Linden Labs (Linden Research, Inc.) als Typ 3System ein. Hierbei handelt es sich um eine Währung, die innerhalb der virtuellen
Spielwelt „Second Life“ eingesetzt wird. Die Spieler haben die Möglichkeit, eigene
virtuelle Welten und Gegenstände zu erschaffen und diese innerhalb des Spiels für Linden Dollar zu verkaufen. Aufgrund der Eigendynamik des Systems und der Tatsache,
dass auch einige Unternehmen die virtuelle Welt als Werbe- und Wahlkampfplattform
entdeckten [Stöcker 2007], entstanden eigene Handelsplattformen und Börsen zum
Tausch und Verkauf von Währungen und geschaffenen Gegenständen. Die Deutsche
Post AG ermöglichte von Mai 2007 bis Anfang 2008 den Versand von Postkarten aus
der virtuellen Welt an reale Adressen. [Marwan 2008]
Da die gesamte virtuelle Welt zentral über die Server der Firma Linden Labs betrieben
wird, können alle Gegenstände und Konten jederzeit von einzelnen Personen kontrolliert und das ganze System abgeschaltet werden. Das Fundament von Kryptowährungen
wie Bitcoin sind jedoch die Dezentralität des Gesamtsystems und die Unabhängigkeit
von dritten Vertrauenspersonen, weshalb Systeme wie Second Life mit Linden Dollar
oder jede andere Art von zentral gesteuertem System in dieser Arbeit nicht als Kryptowährung betrachtet werden.
Entsprechend definiere ich im Rahmen dieser Arbeit als Kryptowährung nur dezentrale
Systeme, die auf den technischen Grundlagen von Bitcoin basieren.
2.2.2 Entstehungsgeschichte
Bereits 1983 veröffentlichte David Chaum seine Idee vom anonymen elektronischen
Geld [Chaum 1983] und gründete 1989 das Unternehmen DigiCash. Mit dem Zahlungssystem „eCash“ gab es erstmals ein System, das kryptografische Protokolle zum anonymen Transfer kleinerer Geldbeträge nutzte und von mehreren Banken, auch in Europa
eingesetzt wurde. Trotz der genialen Idee und aller Bemühungen Chaums, ausreichend
Händler zu finden, wollte niemand das System einsetzen, und die Verbraucher wählten
stattdessen lieber Kreditkartensysteme wie Visa und Master Card [Pitta 1999]. Diese
Entwicklung führte 1998 zum Bankrott der Firma DigiCash.
Ein weiteres Konzept, welches als direkter Vorgänger zum heute bekannten Bitcoin gilt,
ist „b-money“. Diese Idee von Wai Dai [Dai 1998] beschrieb erstmals ein Proof-ofWork Verfahren zur Gelderzeugung.
23
Erst 10 Jahre später stellte Satoshi Nakamoto sein „Peer-to-Peer Electronic Cash System“ mit dem Namen Bitcoin vor. Auch hier wird Proof-of-Work zur Erzeugung von
Bitcoin genutzt. Die erste Implementierung des Open-Source Bitcoin-Netzwerkes entstand 2009, ist noch heute im Betrieb und dient als Grundlage für viele weitere Kryptowährungen.
Bitcoin wird von Entwicklern aus der ganzen Welt weiter verbessert. Satoshi Nakamoto
hat sich bereits Mitte 2010 komplett aus dem Projekt zurückgezogen und die Kontrolle
unterschiedlichen und bekannten Personen der Bitcoin-Community überlassen. Zu Ihnen zählte auch Gavin Andresen, dem die Kontrolle über die QuellcodeVersionsverwaltung überlassen wurde und der seitdem zu den Hauptentwicklern von
Bitcoin zählt.
Bis heute ist nicht bekannt, wer sich hinter dem Namen Satoshi Nakamoto verbirgt.
Denkbar ist auch durchaus, dass es sich um das Pseudonym einer ganzen Gruppe von
Entwicklern handelt.
2.2.3 Ziele
Kryptowährungen bieten dem Nutzer ein dezentrales und sicheres elektronisches Zahlungssystem, das ohne die Verifizierung durch eine vertrauenswürdige dritte Partei auskommt. So wird über alle an das System der Kryptowährung angeschlossenen Rechner
verifiziert, ob der Absender den entsprechenden Betrag besitzt und dieser auch nicht
mehrfach überwiesen wird. Hierdurch ist es möglich, hohe Investitionen für die Infrastruktur zu umgehen, Gebühren für Transaktionen zu reduzieren und so auch die Überweisung von Kleinstbeträgen zu ermöglichen.
2.2.4 Technische Grundlagen
Das wichtigste Element für die Kommunikation innerhalb eines KryptowährungNetzwerkes sind Transaktionen. Transaktionen werden mit Schlüsseln signiert und vom
Absender an eine Adresse des Empfängers gesendet. Dieser Vorgang geschieht ähnlich
wie bei einer Banküberweisung. Alle Transaktionen werden in einem Block gespeichert, der in die Blockchain eingehängt wird. Da es bei den unterschiedlichen Währungen Unterschiede bei der Speicherung der Daten in der Blockchain gibt, werde ich im
Weiteren lediglich auf die Speicherung von Bitcoin (BTC) eingehen und Abweichungen
sowie nähere Beschreibungen bzgl. anderer Währungen im Text kenntlich machen.
24
2.2.4.1 Netzwerk
Bei dem Bitcoin-Netzwerk handelt es sich um ein dezentrales Peer-to-Peer-Netzwerk,
bei dem jeder Teilnehmer über ein Programm, den Bitcoin-Client, direkt mit anderen
Teilnehmern verbunden ist. Die Informationen werden über Netzwerkknoten (Nodes)
ausgetauscht, so dass jeder Knoten alle Daten der Bitcoin-Buchhaltung speichert und
über eine entsprechend große Festplatte verfügen muss.
Größe der Bitcoin-Datenbank in Gigabyte
30
25
20
15
10
5
0
01.01.2012
01.01.2013
01.01.2014
01.01.2015
Abbildung 2: Größe der Bitcoin-Datenbank (Quelle: blockchain.info)
Der eingesetzte Standard Bitcoin-Client, ist ein Full-Node-Client, also ein Programm,
das über die gesamte Datenbank mit allen Transaktionen, genutzten Adressen und Beträgen verfügt. Weitere Bitcoin-Clients und Möglichkeiten, um über einzelne Knoten
auf die gespeicherten Daten zuzugreifen, werden im Kapitel 3.2 näher beschrieben. Alle
Netzteilnehmer haben die gleichen Zugriffsrechte innerhalb des Gesamtsystems. Ein
einzelner Teilnehmer wird als Peer bezeichnet und kann neue Informationen bereitstellen, die umgehend über die Knoten an alle angeschlossenen Peers verteilt werden. Je
nach Netzgeschwindigkeit hat jeder Teilnehmer schon nach kurzer Zeit das Wissen über
die gesamte Datenbasis.
25
Abbildung 3: Modell eines dezentralen Peer-to-Peer Netzwerks
2.2.4.2 Adressen
Um überhaupt eine Information wie beispielsweise einen Zahlungsvorschlag zu übermitteln, müssen der Absender und der Empfänger über eine eigene Adresse verfügen.
Jeder Teilnehmer kann sich beliebig viele Adressen erzeugen und ist nicht, wie beim
SEPA-Zahlungsverkehr, an eine festgelegte IBAN gebunden.
Um eine Adresse zu erzeugen, werden zunächst ein privater und ein öffentlicher Schlüssel auf Basis des „Elliptic Curve Digital Signature Algorithm“ (ECDSA) erzeugt [Bitcoin Wiki 2015a]. Eine detaillierte Beschreibung dieses kryptografischen Verfahrens ist
im Anhang A zu finden. Im Anschluss sind mehrere Einzelschritte notwendig, um als
Ergebnis eine gültige Bitcoin-Adresse zu erzeugen.
Privater Schlüssel
18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725
Öffentlicher Schlüssel
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522C
D470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
Ausgehend vom öffentlichen Schlüssel wird über die SHA-265 Hashfunktion (siehe
Anhang A.1) ein Hashwert erzeugt.
SHA-256(öffentlicher Schlüssel)
ded9f375c0da2ed759eafd278fe56f476702ebc6f16f5b1ea42131cd766f458c
600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408
26
Danach wird nun auf diesen Hashwert
H
die RIPEMD-160
160 Hashfunktion angewandt und
dem Ergebnis die Versionsnummer des Netzwerkes, in unserem Fall des Hauptnetzes
(0x00), hinzugefügt. (siehe Anhang A.2.2)
Version + RIPEMD-160(SHA
160(SHA-256(öffentlicher Schlüssel))
00010966776006953D5567439E5E39F86A0D273BEE
010966776006953D5567439E5E39F86A0D273BEE
Auf diesen Hashwert wird nun die SHA-256
SHA 256 Hashfunktion zweimal angewendet und die
ersten vier Bytes des Ergebnisses als Prüfsumme an den Hashwert angehängt.
SHA-256(SHA-256(00010966776006953D5567439E5E39F86A0D273
010966776006953D5567439E5E39F86A0D273BEE))
BEE))
D61967F63C7DD183914A4AE452C9F6AD5D462CE3D277798075B107615C1A8A30
3C7DD183914A4AE452C9F6AD5D462CE3D277798075B107615C1A8A30
Version + RIPEMD-160(SHA
160(SHA-256(öffentlicher Schlüssel)) + Prüfsumme
00010966776006953D5567439E5E39F86A0D273BEE
010966776006953D5567439E5E39F86A0D273BEED61967F6
Als letzter Schritt wird nun auf den nun erzeugten Hashwert eine abgewandelte
a
Form
des Base64-Kodierungsverfahrens
Kodierungsverfahrens angewendet, dass im Bitcoin Netzwerk als BaB
se58Check bezeichnet wird [Bitcoin Wiki 2015a]. Hierbei wird ein Hashwert erzeugt,
der zur besseren Lesbarkeit auf die Großbuchstaben "O“ und „I“, sowie das kleine „i“
und die „0“ verzichtet und die Versionskennung vorangestellt wird. Typische BitcoinBitcoin
Adressen beginnen mit einer 1 oder einer 3. Im Rahmen der Weiterentwicklung gibt es
mittlerweile eine größere Anzahl von Präfixen für Adressen [Bitcoin Wiki 2015b].
Bitcoin-Adresse
16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM
Abbildung 4: QR-Bild zur generierten Bitcoin-Adresse
Bei Bitcoin-Adressen
Adressen die mit einer 3 beginnen, handelt es sich um Adressen zu denen es
mehrere Schüssel gibt und eine Transaktion
Transaktion von mehreren Teilnehmern und deren pripr
vaten Schlüsseln unterschrieben werden kann. Bei diesem MehrfachunterschriftenMehrfachunterschriften
27
Verfahren wird beim Erzeugen der Adresse festgelegt, wie viele unterschiedliche Teilnehmer Zugriff auf das zugeordnete Guthaben haben und die Anzahl der privaten
Schlüssel bestimmt, die benötigt werden, um eine Überweisung durchzuführen.
2.2.4.3 Wallet
Um eine Kryptowährung einsetzen zu können, benötigt der Benutzer ein Wallet, also
eine elektronische Brieftasche, die innerhalb der Bitcoin-Software angelegt werden
kann und alle dem Teilnehmer zugeordneten Bitcoin-Adressen mit den dazugehörigen
öffentlichen und den korrespondierenden privaten Schlüsseln beinhaltet. Im StandardProgramm „Bitcoin Core“ wird hierzu eine Datei (wallet.dat) im Programmverzeichnis
abgelegt. Um einen Zugriff weiter abzusichern ist es möglich, diese Datei zusätzlich
noch zu verschlüsseln und mit einem Passwort zu versehen. Jede gespeicherte Adresse
ist einem bestimmten Bitcoin-Guthaben zugeordnet, über das nur der Besitzer des korrespondierenden privaten Schlüssels verfügen kann.
Jeder Teilnehmer kann beliebig viele Adressen erzeugen und diese wie eine Kontonummer oder E-Mail-Adresse an andere Teilnehmer weitergeben.
Um Beträge innerhalb des Netzwerkes zu überweisen, wird ein Zahlungsvorschlag erzeugt und einer Transaktion hinzugefügt.
Jede Transaktion wird mit dem privaten Schlüssel unterschrieben und in das Netz der
entsprechen Währung eingespeist. Der an diese Transaktion gebundene öffentliche
Schlüssel des Absenders wird durch den öffentlichen Schlüssel des Empfängers getauscht und von allen anderen Teilnehmern bestätigt.
Im Allgemeinen wird zwischen Hot- und Cold-Wallets unterschieden, auf die der Inhaber unterschiedlich Einfluss nehmen kann. Während Hot-Wallets immer eine Onlineverbindung benötigen, speichern Cold-Wallets die Schlüsselpaare auch außerhalb des
Internets. Die Speicherung von Schlüsseln erfolgt auf unterschiedliche Arten, auf die
ich im Rahmen der Arbeit weiter eingehen werde.
2.2.4.4 Transaktionen
Eine Transaktion der Kryptowährung Bitcoin enthält neben einer Versionsnummer und
eines Zeitstempels auch Listen der Ein- und Ausgänge, wodurch sich folgender Aufbau
ergibt.
1.
2.
3.
4.
5.
6.
Versionsnummer (aktuell 1)
Anzahl der Eingänge
Liste der Eingänge
Anzahl der Ausgänge
Liste der Ausgänge
Zeitstempel
28
Die erste Eingabe der jeweils ersten Transaktion neu erzeugter Bitcoin wird als
Coinbase bezeichnet und entsteht als „Belohnung“ eines Erzeugungsverfahrenes, das im
Kapitel 2.2.5 näher beschrieben wird.
Möchte nun Alice einen Betrag von 50 Bitcoin an Bob überweisen und somit eine neue
Transaktion erzeugen, dann werden alle zu diesen 50 Bitcoin gehörenden Transaktionseingänge in einer Liste zusammengefasst.
Abbildung 5: Alice möchte Bob 50 BTC überweisen
Alice hat vorher jeweils 20 Bitcoin von Carol und David und 25 Bitcoin von Eve erhalten, woraus sich für die Transaktion der 50 Bitcoin erzeugen lässt. Die Eingangsliste hat
einen Gesamtwert von 65 Bitcoin besteht aus folgenden Transaktionen.
Abbildung 6: Schematische Darstellung der Eingänge
29
Da immer der gesamte Betrag in der Ausgangsliste verwendet werden muss, wird der
Restbetrag von Alice an sich selbst zurücktransferiert. Zusätzlich akzeptiert Alice eine
Gebühr von 0,5 Bitcoin, die beim Erzeugungsverfahren der neu generierten Bitcoin hinzugerechnet werden, wodurch sich folgende Ausgangsliste ergibt:
Anzahl Ausgänge: 3
Abbildung 7: Schematische Darstellung der Ausgänge
Diese drei Ausgänge bestehen aus den zwei Adressen (Hashwerte der öffentlichen
Schlüssel) von Alice und Bob und der Transaktionsgebühr, die demjenigen gutgeschrieben wird, der den Block verifiziert in den diese Transaktion eingefügt wird.
Die gesamte Transaktion wird mit den privaten Schlüsseln unterschrieben, die zu der
jeweiligen Eingangstransaktion gehören. Da die entsprechenden öffentlichen Schlüssel
in die Transaktion eingebettet werden, können diese über die dazugehörige Hashfunktion mit der angegeben Adresse verglichen und somit verifiziert werden. Für jede Transaktion wird ein eigener Hashwert über einen doppelten SHA-256 Hash erzeugt.
30
Abbildung 8:: Anwendung der Schlüssel bei Transaktionen [Nakamoto 2008]
Die Transaktion wird nun von Alice an alle angeschlossenen Teilnehmer (Peers) weiwe
tergegeben und weiter im gesamten Netzwerk verteilt. Ist die Transaktion erzeugt und
übermittelt, ist es unmöglich,
unmöglich diese rückgängig zu machen.
2.2.4.5 Blockchain
Die gesamte Wissensbasis des Bitcoin-Netzwerkes
Bitcoin
ist in der Blockchain gespeichert.
Jeder angeschlossene Teilnehmer hat Zugriffsmöglichkeit auf diese gemeinsame BuchBuc
haltung sowie die Möglichkeit,
Möglichkeit die Gültigkeit jedes einzelnen Bestandteils dieser zu
überprüfen und alle Daten zu jeder Zeit einzusehen. Damit die Gesamtmenge der Daten
dieser gemeinsamen Buchhaltung nicht immer wieder neu geprüft werden muss, wird
diese in einzelne Blöcke unterteilt.
Um einen neuen Block zu erzeugen,
erzeugen müssen ein oder mehrere Teilnehmer gemeinsam
eine kryptografische Aufgabe lösen, zu
zu der ca. alle 10 Minuten ein sehr leicht überprüfüberprü
bares Ergebnis errechnet wird. Dieses Verfahren wird als Mining bezeichnet und im
folgenden Kapitel beschrieben. Der neu erzeugte Block erzeugt eine neue festgelegte
Menge Bitcoin, die dem Teilnehmer zusammen
zusammen mit den Transaktionsgebühren gutgegutg
schrieben wird und folgende Informationen beinhaltet:
1. den Arbeitsbeweis (Proof-of-Work)
(Proof Work) als Ergebnis des Erzeugungsverfahrens in Form eie
nes neuen Hashwertes
2. den ebenfalls leicht überprüfbaren Bezug (Hashwert) zum vorherigen
vorherigen Block
3. alle Transaktionen die dem Netzwerk seit dem letzten Block gemeldet wurden
Der erste Block (Nummer 0) wurde am 03.01.2009 von
on Satoshi Nakamoto erzeugt und
wird als Genesisblock bezeichnet.
31
Abbildung 9: Aneinanderreihung von Blöcken ([Platzer 2014], S.21)
2.2.5 Erzeugungsverfahren
Für alle Kryptowährungen wird mathematisch eine bestimmte Anzahl von Einheiten
(Coins) festgelegt, die je nach System innerhalb eines bestimmten Zeitrahmens erzeugt
werden können.
Bei Bitcoin werden laut Spezifikation [Bitcoin Wiki 2015c] bei jedem neu gefundenen
Block zunächst 50 neue Bitcoin erzeugt. Diese Anzahl wird alle 210000 Blöcke um die
Hälfte reduziert. Diese Halbierung findet auf der Grundlage, das alle zehn Minuten ein
neuer Block erzeugt wird, ca. alle 4 Jahre statt.
⋅
ö
⋅
⋅
≈ Die kleinste einsetzbare Einheit eines Bitcoin ist 1 Satoshi was einer 0,00000001 Bitcoin (BTC) entspricht. Die Gesamtmenge an Bitcoin lässt sich über folgende Formel
berechnen:
⋅
=
⋅
⋅
=
⋅
⋅
=
Da n in der Formal gegen unendlich strebt, ergibt sich ein Grenzwert von 21000000
Bitcoin, der in endlicher Zeit erreicht wird. Unter Berücksichtigung aller Halbierungen
und der kleinsten Einheit Satoshi, werden die letzten Bitcoin im Jahr 2040 mit Block
Nummer 6929999 erzeugt.
32
2.2.5.1 Mining
Das Mining (zu Deutsch „schürfen“) ist essentieller Bestandteil des Bitcoin-Systems.
Jeder Teilnehmer hat die Möglichkeit, einen neuen Block zu generieren und somit die
Chance, neue Bitcoin die seine angegebene Adresse zugeteilt zu bekommen. Die Teilnehmer, die neue Blöcke generieren und Ihre Arbeitsleistung einbringen, werden Miner
genannt.
Um einen neuen Block zu erzeugen muss ein neuer Hashwert errechnet werden, der auf
einem festgelegten Schema basiert und das Ergebnis einer einfachen mathematischen
Funktion ist. Hierbei wird nach dem Hashwert des aktuellen Blocks gesucht. Entsteht
dabei eine gewisse Anzahl von Nullen am Anfang des neu erzeugten Hashwertes ist die
Aufgabe gelöst. Über den nun neu erzeugten Block und den dazugehörigen Hashwert,
können nun alle seit dem letzten Block übermittelten Transaktionen verifiziert werden.
Da die zur Berechnung herangezogenen Blockheader immer unterschiedlich sind, gibt
es auch mehrere Lösungen und die Berechnung gleicht mehr einer Lotterie, bei derjenige gewinnt, der durch Ausprobieren zuerst einen gültigen Hashwert erzeugt. Der damit
verbundene Arbeitsaufwand ist abhängig von der Gesamtleistung des Netzwerkes, und
die Schwierigkeit wird alle 2016 Blocke angepasst, was ca. 14 Tagen entspricht.
Der Block wird von dem Miner als neue über die Netzwerkknoten (Nodes) an alle Teilnehmer (Peers) gemeldet und von diesen betätigt.
2.2.5.2 Erzeugung neuer Blöcke
Um einen neuen Bitcoin-Block zu erzeugen wird, wie bereits beschrieben, ein neuer
Hashwert benötigt. Zur Erzeugung dieses Hashwertes wird der im Jahr 1997 von Adam
Black erfundene Hashcash-Algorithmus verwandt [Black 1997]. Die ursprüngliche Idee
des Hashcash-Algorithmus war es, E-Mail-Nachrichten mit einem Hashwert zu versehen, dessen Erzeugung eine gewisse Rechenleistung beanspruchen würde. Gleichzeitig
sollte der Empfänger der Nachricht jedoch schnell die Gültigkeit überprüfen können.
Ziel war es, mit dieser virtuellen Gebühr ähnlich einer Briefmarke das Versenden von
unerwünschten Werbe-/Massenmails (Spam) und andere Netzwerkangriffe zu reduzieren. So würde das Versenden von mehreren tausend Mails nicht mehr in Sekunden
möglich sein, sondern würde je nach gewünschter Hashlänge Minuten, Stunden oder
sogar Tage dauern.
Um nun einen gültigen Hashwert für den neuen Block zu erzeugen, werden alle Elemente des Blockheaders miteinander verknüpft:
33
Feld
Inhalt / Änderungsintervall
Versionsnummer
Die Versionsnummer wird durch die eingesetzte Client-Software bestimmt.
4
Hashwert des
letzten Blocks
Der 256-bit Hashwert ändert sich, wenn ein neuer Block erzeugt wurde.
32
Hashwert der
Hash-Baums
Der 256-bit Hashwert des Elternknotens (Merkle Root) im Hashbaum ändert
sich, sobald eine neue Transaktion akzeptiert wurde.
32
Zeit
Bei jedem Versuch wird ein neuer Zeitstempel gesetzt. Hierzu werden die
Sekunden seit 01.01.1970 - 00:00 Uhr (UTC2) verwendet.
4
Bits
Verkürzte Speicherung der Schwierigkeit, die ca. alle 14 Tage angepasst
wird (Kapitel 2.2.5.3).
4
Nonce
Inkrementeller Zähler, der nach jedem Versuch erhöht wird.
4
Größe (Bytes)
Der Hash-Baum wird im Bitcoin-System als Merkle-Tree [Merkle 2012] bezeichnet ist
ein Binärbaum aus Hashwerten. Die Hashwerte der Kinderknoten werden indirekt über
den Hashwert des Elternknotens berechnet. Der Hashwert des Elternknotens wird im
Blockheader gespeichert. Das die Transaktionen nicht direkt gehasht werden, ist der
Aufwand zur Berechnung des Hashwertes für einen Block mit einer Transaktion genauso groß die bei einem Block mit 10000 Transaktionen. [Bitcoin 2012]
Aus all diesen Informationen wird nun mit einem doppelten SHA-256 ein Hashwert
errechnet und mit der festgelegten Schwierigkeit vergleichen.
"#
( "#
(
%
))
Ist das Resultat größer oder gleich der Schwierigkeit, dann gilt dies als gültiger Arbeitsbeweis, und der erzeugte Hashwert wird für den neuen Block verwendet.
Mit dem erzeugten Hashwert ist der Block komplett und besteht aus folgenden Teilen:
Feld
Inhalt / Änderungsintervall
Fester Wert
(Magic Number)
Die „Magic Number“ hat im Hauptnetz (main) den Wert 0xD9B4BEF9
Blockgröße
Die Größe des Blocks.
4
Blockheader
(siehe oben)
80
Anzahl der
Transaktionen
Positive ganze Zahl, die als Integer mit variabler Länge gespeichert
wird.
Transaktionsliste
Eine nicht leere Liste mit Transaktionen.
2
Größe (Bytes)
4
Der Wert ergibt sich aus einer BloomFilter Implementierung um
einzelne Netzwerke zu unterscheiden.
UTC ist die gültige Weltzeit
34
1-9
(max 1000000)3
Der neu erzeugte Block nun in die Blockchain eingehängt und der neue Block den Teilnehmern bereitgestellt.
Es kann vorkommen, dass zwei Blöcke nahezu zeitgleich erzeugt werden und somit
zwei unterschiedliche Blockchain entstehen. Hier entscheidet immer die Mehrheit der
angeschlossenen Miner welches die gültige Blockchain ist. Da die Mehrheit die größere
Arbeitsleistung einbringt, wird die Blockchain bei gleicher Schwierigkeit entsprechend
länger und die kürzere Kette wird verworfen und es entstehen verwaiste Blöcke. Aus
diesem Szenario ergeben sich unterschiedliche Manipulations- und Angriffsmöglichkeiten, die im Kapitel 2.3 näher beschrieben werden.
2.2.5.3 Berechnung der Schwierigkeit
Die Schwierigkeit der Blockerzeugung wird alle 2016 Blöcke neu berechnet und richtet
sich nach der Gesamtleistung des Netzwerkes. Da laut Definition alle 10 Minuten ein
neuer Block erzeugt wird, ergibt sich so für jede Schwierigkeit ein Zeitraum von durchschnittlich 14 Tagen.
⋅
=
⋅ ⋅ '
Starke Leistungsschwankungen, wie der Verkauf von leistungsfähiger Hardware oder
die Abschaltung ganzer Rechenzentren können den Zeitraum zur nächsten Schwierigkeit verlängern oder verkürzen4.
Die Schwierigkeit wird über eine einfache Formel berechnet, die im Quellcode von Bitcoin unter /src/pow.c zu finden ist [Bitcoin Quellcode 2015]
#
8 9
* = (
:
: )A
;=
(
) = * (+,-./012345670+)
(
) = ;(+<=>[email protected]+)
D
%
−(
: )A
%
C
(1420@5/4@5?5-ℎ+5.3+H5I/+J5+)
3
Die Blockgröße ist auf maximal 1000000 Bytes festgelegt (Siehe Kapitel Fehler! Verweisquelle konnte nicht gefunden werden.)
4
Die letzen Veränderungen der Schwierigkeit und der Gesamtleistung des Netzwerkes, können auf der
Webseite https://bitcoinwisdom.com/bitcoin/difficulty nachgelesen werden.
35
Um zu große Sprünge zu verhindern, wird die Berechnung noch eingeschränkt:
;
;
* < ⇒ * = * < ; ⋅ ⇒ * = ; ⋅ Nun kann die neue Schwierigkeit berechnet werden:
9
2.3
=
9
*
⋅ ;
Eigenschaften und Probleme
Beim Entwurf von Bitcoin [Nakamoto 2008] berücksichtigte Satoshi Nakamoto bereits
einige Probleme, wie doppelte Zahlungen und löst mit der Erfindung des Blockchain
auch das Problem der Byzantinischen Generäle, welches im Kapitel 2.3.1 genauer beschrieben wird. Bei der Einschätzung von Speicherbedarf und Rechenleistung hat Nakamoto vermutlich die Eigendynamik des Bitcoin-Systems und die bevorstehende
Transaktionsmenge und somit auch Blockgröße unterschätzt. Hierdurch entstehende
Probleme könnten das System scheitern lassen. Die Bitcoin-Entwickler müssen sich
neuen Herausforderungen stellen und Lösungen erarbeiten. Eine der wichtigsten Aufgaben für die Entwickler ist die Erhöhung der im Quellcode festgelegten maximalen
Blockgröße, die im Kapitel 0 genauer betrachtet wird und einige Lösungswege vorgestellt werden.
2.3.1 Byzantinische Generäle
Eine Herausforderung bei verteilten Systemen ohne zentrale Steuerungsmechanismen
besteht darin, bei unterschiedlichen Ergebnissen oder Meinungen eine Entscheidung
durch eine Mehrheitsentscheidung zu treffen. Dies ist allerding nur dann möglich, wenn
alle Komponenten fehlerfrei funktionieren oder im Bitcoin-System alle Teilnehmer die
Regeln befolgen.
Diese Problematik wird als Situation einer Byzantinischen Armee beschrieben
[Lamport/Shostak/Pease 1982] und als Problem der Byzantinischen Generäle oder Problem der interaktiven Konsistenz beschrieben.
Die Autoren beschreiben das Problem mit drei Generälen der byzantinischen Armee,
die mit Ihren Soldaten eine Stadt belagern und Ihre Nachrichten über Boten austauschen. Für eine erfolgreiche Übernahme müssen mindestens zwei Generäle die Stadt
angreifen. Sind alle Generäle ehrlich, dann einigen sie sich auf eine bestimmte Zeit für
einen Angriff und die Stadt wird erfolgreich eingenommen. Ebenso könnten sich alle
Generäle auch darauf einigen abzuwarten, die Bevölkerung somit zu Schwächen und
36
zum Aufgeben zu zwingen. Beide Vorgehensweisen führen zum Erfolg und zur Übernahme der Stadt.
Das Problem entsteht nun, wenn sich unter den drei Generälen ein Verräter befindet, der
falsche Information weitergibt, oder wenn Informationen von dem übermittelnden Boten geändert werden.
Abbildung 10: Problem der Byzantinischen Generäle
Wie in Abbildung 10: Problem der Byzantinischen Generäle erkennbar, gibt B die Information von A falsch an C weiter. In diesem Fall kann C nicht entscheiden, welche
Aktion ausgeführt werden soll. Auch ein Nachfragen würde in diesem Szenario das
gleiche Ergebnis liefern.
Wird dieses Problem nun auf das Bitcoin-Netzwerk übertragen, dann entsprechen die
Nachrichten den Blöcken, deren Gültigkeit durch einen Arbeitsbeweis und Erzeugung
eines neuen Blockes (alle 10 Minuten) zu errechnen ist. Die Generäle sind die Miner,
also die Teilnehmer des Netzwerkes, die durch Rechenleistung einen neuen Block erzeugen. Sobald einer der Miner einen neuen gültigen Hashwert gefunden hat, wird ein
neuer Block erzeugt und in die Blockchain eingehängt. Die neue Information wird allen
anderen Minern mitgeteilt und dient als Grundlage zur Errechnung des nächsten Blocks.
Wenn nun ein Miner zwei unterschiedliche Ketten empfängt, dann nimmt er immer die
längste Blockchain als Grundlage für seine weitere Berechnung, da er davon ausgehen
kann, das die Mehrheit der Miner zusammen die größte Rechenleistung besitzen und
somit schneller neue Blöcke berechnen. Mit der längsten Blockchain ist in diesem Zu-
37
sammenhang nicht die mit den meisten Blöcken, sondern die mit insgesamt der größten
Arbeitsleistung gemeint5.
Besitzt ein Miner mehr als 50% der Rechenleistung, dann kann dieser alleine das gesamte System kontrollieren und man spricht von einer 51% Attacke, die im folgenden
Kapitel beschrieben wird.
2.3.2
51% Attacke
Wenn mehr als 50% der Rechenleistung des gesamten Bitcoin-Systems von einem Angreifer kontrolliert wird, dann kann er [Bitcoin Wiki 2015e]
•
•
•
alle Transaktionen rückgängig machen, die er selber erzeugt,
verhindern, dass Transaktionen bestätigt werden sowie
verhindern, dass Miner neue Blöcke erzeugen.
Nicht möglich ist es:
•
•
•
•
•
fremde Transaktionen rückgängig zu machen
Transaktionen grundsätzlich zu verhindern
das Protokoll und somit die Anzahl der erzeugten Bitcoin zu manipulieren
Bitcoin ohne einen neuen Block erzeugen
Bitcoin zu verschicken, die der Angreifer nicht besitzt
Da die Rechenleistung des Systems sehr hoch ist, ist die Wahrscheinlichkeit für einen
gezielten Angriff für einzelne Miner oder Organisationen sehr gering. Durch den Zusammenschluss mehrerer Miner könnte eine solche Mehrheit jedoch erreicht werden
und der Betreiber eines solchen Miningpools könnte diesen Zustand für seine Zwecke
ausnutzen. Im Juni 2014 wurde eine solche Mehrheit für ca. 12 Stunden bei dem Miningpool-Betreiber Ghash.IO erreicht, der daraufhin erklärte die Situation nicht ausgenutzt zu haben und dies auch zukünftig nicht zu tun [Kannenberg 2014][Ghash.IO
2014]. Im Juli 2014 stand der Ghash.IO erneut kurz davor mehr als 50% Rechenleistung
zu erreichen und verpflichtete sich auf Reaktion darauf, zukünftig Sorge dafür zu tragen
das eine Gesamtleistung von 39,99% nicht überschritten wird [Danova 2014].
Eine Übersicht der aktuellen Verteilung der gesamten Rechenleistung ist auf der Webseite https://blockchain.info/de/pools zu finden.
2.3.3
Doppelte Zahlungen
Da es keine Repräsentation einzelner Bitcoin gibt, sondern das Guthaben auf Basis aller
Transaktionen berechnet wird, könnte nun versucht werden einen bestimmten Betrag
mehrmals zu überweisen. Alle Transaktionen werden in das Netzwerk übertragen und
5
Ein Angreifer könnte sehr schnell eine lange Kette mit geringer Schwierigkeit erzeugen
38
von den angeschlossenen Teilnehmern bestätigt. Bei der Verifizierung der Transaktionen wird die ältere Transaktion verworfen. Da sich alle Teilnehmer auf die gleiche
Blockchain einigen, ist nur die Transaktion gültig, die beim Erzeugen eines neuen
Blocks in diesen aufgenommen wurde. Zusätzlich muss sichergestellt sein, dass die
verwendete Blockchain gültig ist. Es wird empfohlen mehrere Bestätigungen der Transaktion abzuwarten, um das Risiko, Opfer einer doppelten Zahlung zu werden zu reduzieren. In der Praxis ist dies jedoch nicht umsetzbar, da ein Händler nicht mehrere Minuten warten kann bis er seine Ware ausliefert. Als mögliche Lösung kann hier die Infrastruktur eines Zahlungsanbieters helfen, die Risiken zu reduzieren und den möglichen
Verlust abzusichern.
Es sind neben der bereits im vorangegangenen Kapitel beschrieben 51% Attacke folgende Angriffe denkbar [Bitcoin Wiki 2015f]
Wettlauf-Angriff
Ein Zahlungsempfänger akzeptiert eine Überweisung auch ohne weitere Bestätigung
und der Angreifer überweist die gleichen Bitcoin an einen weiteren Empfänger oder an
sich selbst. Einer der Empfänger erhält nun keine Bitcoin, da bei der Validierung eines
neuen Blocks die neueste Transaktion verworfen wird. Die Erfolgsaussichten für einen
solchen Angriff sind wie von Ghassan O. Karame, Elli Androulaki und Srdjan Capkun
beschrieben sehr hoch [Karame/Androulaki/Capkun 2012].
Finney-Angriff
Der Angreifer arbeitet mit einem Miner zusammen oder erzeugt selber einen gültigen
Block, der bereits eine gewünschte Transaktion enthält. Dieser neue Block wird jedoch
noch nicht veröffentlicht, sondern der Betrag der bereits akzeptierten Transaktion wird
erneut ausgegeben. Ein Zahlungsempfänger, der wieder unbestätigte Transaktionen zulässt hat keine Möglichkeit sich zu schützen. Nachdem der Angreifer die gewünschte
Leistung oder Ware vom Zahlungsempfänger erhalten hat, wird der Block veröffentlicht.
Vector76-Angriff
Eine Kombination aus dem Wettlauf- und dem Finney-Angriff ermöglicht eine doppelte
Zahlung bei Transaktionen, die bereits bestätigt wurden. Beim Vector76-Angriff wird
entsprechend wieder ein gültiger Block benötigt, der erst zu einem späteren Zeitpunkt
veröffentlicht wird.
Brute-Force-Angriff
Wenn der Zahlungsempfänger mehrere Bestätigungen M einer Transaktion abwartet,
dann kann der Angreifer versuchen eine zweite Transaktion in eine alternative gültige
39
Blockchain einzubauen, auf dieser Basis selber oder kollektiv zu Minen und diese
Blockchain nach Erzeugung von M gültigen Blöcken veröffentlichen. Wenn die Mehrheit nun auf dieser Basis weitere Blöcke erzeugt, erhält der Angreifer seine Bitcoin zurück. Gelingt dies nicht, kann der Angreifer versuchen den Hauptblockchain zu überholen. Sollte dies gelingen, ist der Angriff erfolgreich. Die hierzu benötigte Rechenleistung ist sehr hoch. So liegt die Wahrscheinlichkeit eines erfolgreichen Angriffs bei b=6
Bestätigungen und einer Rechenleistung von 10% des Gesamtnetzwerkes bei weniger
als 0,1% ([Rosenfeld 2012], S.10)
2.3.4
Hashleistung und Stromverbrauch
In der Vergangenheit war es möglich, dass ein einzelner Miner über die Rechenleistung
des Hauptprozessors (CPU)6 seines Computers einen neuen Block erstellen konnte. Da
im Laufe der Zeit immer mehr Miner neue Bitcoin erzeugen wollten, stieg auch die benötigte Rechenleistung stetig an. Dies hatte wiederum zur Folge, dass die alle 2016 Blöcke berechnete neue Schwierigkeit ebenfalls anstieg. Somit mussten einzelne Miner
noch mehr Rechenleistung aufbringen um die gleiche Belohnung, wie vor der Erhöhung
der Schwierigkeit zu erhalten. Die Rechenleistung wird in diesem Zusammenhang als
Anzahl der errechneten doppelten SHA-256 Hashwerte pro Sekunde ausgedrückt und
im Folgenden auch als Hashrate bezeichnet.
Zunächst wurde eine höhere Hashrate erzeugt, indem die Miner statt des CPU ihre Grafikkartenprozessoren (GPU)7 einsetzten und ihre Rechenleistung in „Pools“ mit anderen
Minern gebündelt haben. Wurde ein neuer Block erzeugt, dann wurde nach unterschiedlichen Verfahren und eingebrachter Rechenleistung der Wert der neu erzeugten Bitcoin
unter den Poolteilnehmern aufgeteilt.
2011 wurden dann leistungsfähige Grafikarten in „Rigs“ verbunden und aufwendig gekühlt um eine maximale Rechenleistung zu erzielen. Zu dieser Zeit war das Minen mit
normalen Prozessoren oder einfachen Grafikarten schon nicht mehr besonders profitabel.
Spätestens ab Mitte 2013 brach eine neue Ära im Bitcoin-Mining an, denn nun wurde
erstmals ein spezialisierter Chip eingesetzt, der nichts anderes kann als SHA-256
Hashwerte zu berechnen. Diese Anwendungsspezifische Integrierte Schaltung, englisch
„Application-specific integrated circuit“ (ASIC) zwang nun Miner zur Anschaffung
spezieller Hardware und das Erzeugung von Bitcoin war fortan nur mit entsprechender
Investition profitabel.
6
7
CPU ist die Abkürzung für Central Processing Unit
GPU ist die Abkürzung für Graphics Processing Unit
40
Am 01. Mai 2015 betrug die Hashrate des Bitcoin-Netzwerks
Netzwerks 347909897 GH/s
(Gigahash pro Sekunde).
Sekunde) Vergleicht man diese Zahl mit der Hashrate eines Intel i77970k Prozessors [Bitcoin Wiki 2015g],
2015g] dann ist die Hashrate der CPU mit
m bis zu 825
MH/s verschwindet gering. Aufgrund der errechneten Schwierigkeit werden einzelne
Blöcke trotz der hohen Hashrate weiterhin durchschnittlich alle 10 Minuten erzeugt.
Im Laufe der Zeit wurde die Spezialhardware mit den ASICS weiter verbessert und
u mit
eigenem Betriebssystem ausgestattet. Die Geräte benötigen lediglich einen Anschluss
an das Internet und die Angabe eines Miningpools (siehe Abbildung 12),
12 ausreichend
Stromzufuhr
fuhr und eine gute Kühlung. Da für Berechnung der Hashwerte sehr viel Strom
verbraucht wird, werden die Spezialchips sehr heiß und benötigen eine entsprechend
leistungsfähige Kühlung.
Abbildung 11:: Grafische Benutzungsschnittstelle eine Antminer S3 zur Einstellung eines Miningpools
Eines der leistungsfähigsten
gsfähigsten Geräte, der Antminer S5 von der chinesischen Firma
Bitmain, schafft eine Gesamthashrate von 1155 MH/s bei einem Stromverbrauch von
nur 0,51 Watt pro GH [Bitcoin Wiki 2015g].
2015g] Auch der Preis von ca. 400 € (Stand: Mai
2015) ist verhältnismäßig günstig.
gün
Umgerechnet auf die Hashrate vom 01.05.2015
01.0
bräuchte man 311886954
31188695 Geräte mit einem Gesamtwert von rund 124
12 Milliarden €, um
diese Leistung zu erzeugen.
41
Eine beispielhafte Umrechnung auf den Stromverbrauch ergibt bei der Leistungsaufnahme des Antminer mit 0,51 Watt pro Gigahash:
⋅
'D DND'
≈ N
,
'
DP
Dies entspricht ungefähr der halben Leistung des Atomkraftwerks Grohnde in Niedersachsen, das mit einer Leistung von 1360 Megawatt zu einem der leistungsfähigsten
Atomkraftwerke in Deutschland zählt.
2.3.5
Blockgröße
Wie bereits im Kapitel 2.2.5.2 beschrieben ist aktuelle Blockgröße auf 1000000 Bytes
festgelegt. Betrachtet man nun beispielsweise Block #350000 vom 30.03.2015, dann hat
dieser bereits eine Größe von 972850,586 Bytes bei insgesamt 1795 Transaktionen8.
Hierbei können einzelne Transaktionen aufgrund der unterschiedlichen Ein- und Ausgänge auch unterschiedliche Größen haben. Um nun zukunftssicher arbeiten zu können
und eine adäquate Anzahl von Transaktionen pro Tag zu bewältigen, muss die Größe
der einzelnen Blöcke angehoben werden. Dies bedeutet aber eine Änderung im Protokoll, und alle Teilnehmer des Netzwerkes müssten sich eine neue Version des Bitcoin
Core Clients installieren.
Man spricht bei einer so entscheidenden Änderung am Protokoll, die nicht abwärtskompatibel ist, von einem Hard Fork. Ab dem Zeitpunkt dieser Änderung wird es zwei
Blockchain geben. Eine Blockchain, die alle alten Clients verstehen und einen neuen
Blockchain mit den entsprechend größeren Blöcken, die von den neuen Clients und
Servern als gültig erkannt werden. Hierbei müssen die neuen Versionen der BitcoinProgramme beide Blockchain verarbeiten. Zukünftig werden so noch größere Datenmengen entstehen; die einzelnen Teilnehmer müssen sich entscheiden, ob sie dieses
Datenvolumen auf Ihre Festplatte laden werden. Vermutlich fällt dann die Entscheidung
zugunsten von Clients, die mit einem Bitcoin-Server kommunizieren oder auf solche,
die nur die Header der Blöcke verarbeiten. Hierdurch verliert das System eine große
Anzahl von Teilnehmern, die mit Ihrem Full-Node-Clients zur Verifikation und Verteilung der Informationen beitragen, was zu einer weiteren Zentralisierung des Netzwerkes
führt.
Entscheidend ist bei einer solchen Änderung, dass sich alle Teilnehmer möglichst
schnell auf die neue Blockchain einigen, eine große Mehrheit bilden und keine zwei
unterschiedlichen Währungen entstehen.
8
Die Informationen zu einzelnen Blöcken können über Blockexplorer wie beispielsweise auf der Webseite http://blockchain.info eingesehen werden.
42
2.4
Transparenz und Anonymität
Das Bitcoin-System bietet für jeden die Möglichkeit, alle bisher getätigten Transaktionen zu verfolgen, wodurch zahlreiche neue Möglichkeiten entstehen. So könnten Spenden für bestimmte Organisationen an eine bestimmte Adresse überwiesen und von dort
an wiederum bekannte Adressen weitergeleitet werden. Eine Unterschlagung von Geldern ist unmöglich, und alle Ausgaben können problemlos offengelegt werden.
Tatsächlich gab es einen bedeutenden Fall in der Bitcoin Geschichte, einer Auktion von
beschlagnahmten Bitcoin. Diese stammten von dem Silk-Road-Server einer Handelsplattform des Entwicklers Ross Ulbricht über die Nutzer beispielsweise Drogen, Waffen
und gefälschte Ausweise kaufen konnten. Ulbricht wurde am 29. Mai 2015 zu lebenslanger Haft verurteilt [Wendt 2015], ein Teil der beschlagnahmten Bitcoin wurden zwischenzeitlich von den U.S. Marshals versteigert und an den Investor Tim Draper überwiesen. Diese Transaktion über 29685,7984 BTC kann im Blockchain nachverfolgt
werden.
Sendeadresse der U.S. Marshals
QC D
CC) R)(S PAQC T
U
AVW
Empfängeradresse des Investors Tim Draper
NXY
Z [
U# \SC
] N9 Q8
S
So ist jede beliebige Zahlung nachvollziehbar und folgendes Szenario denkbar:
Eine Firma zahlt Ihrer Angestellten Alice monatlich das Gehalt als Bitcoin. Alice kauft
nun bei einem Händler ein neues Telefon und überweist Ihre fällige Stromrechnung an
die Bitcoin-Adresse der Stadtwerke. Der Händler und die Stadtwerke haben nun beide
die Möglichkeit, sich näher über den Ursprung der überwiesenen Bitcoin zu informieren. Demnach ist es ohne großen Aufwand möglich, die Gehaltshöhe, Zahlungen für
Strom und jedes beliebige Kaufverhalten nachzuvollziehen.
Alice hat die Möglichkeit, jede neue Zahlung an eine neue Adresse schicken zu lassen
und ebenso die Möglichkeit sich selber die Bitcoin an beliebige andere eigene Adressen
zu transferieren. Diese neuen Adressen nutzt Alice zur Zahlung im Onlineshop. Aber
auch in diesem Fall kann der Onlineshop-Betreiber die gesendeten Bitcoin nachverfolgen, da die ursprüngliche Adresse in der Liste der Eingänge der Transaktion gespeichert
wird. Zusammen mit weiteren Informationen wie der IP Adresse oder der angegebenen
Rechnungsadresse könnte sich der Betreiber nun genaues Bild von der Kundin machen.
Wie von Fergal Reid und Martin Harrigan beschrieben ist Anonymität im BitcoinSystem nicht möglich und eine starke Anonymität auch kein prominentes Entwick-
43
lungsziel [Reid / Harrigan 2012]. Das Verwenden unterschiedlicher Adressen und Systeme verschiedener Zahlungsanbieter ermöglicht dennoch einen gewissen Schutz.
3
Praktischer Einsatz von Kryptowährungen
Damit die Kryptowährung Bitcoin als Alternative für die bisherigen Zahlungs-und
Überweisungsverfahren in Frage kommt, muss gewährleistet sein, dass sie im täglichen
Einsatz intuitiv eingesetzt werden kann und kein Spezialwissen vorausgesetzt werden
muss.
Die Netzteilnehmer und somit potentielle Anwender von Bitcoin brauchen einfach einsetzbare Programme und zugeteilte Einheiten von Bitcoin. Welche Möglichkeiten es
gibt, an Bitcoin zu gelangen (Kapitel 0), wie Guthaben eingesetzt und gesichert werden
kann (Kapitel 3.2 und 3.3) und welche neuen Einsatzzwecke und Chancen durch eine
Kryptowährung gegeben sind, wird in den folgenden Kapiteln beschrieben.
3.1
Beschaffung von Bitcoin
Ziel der Kryptowährung Bitcoin war es, dass jeder Teilnehmer des Netzwerkes die
Möglichkeit haben sollte, durch Einbringung einer gewissen Arbeitsleistung eigene Bitcoin zu erzeugen. Dies ist, wie im Kapitel 2.3.4 beschrieben, heute nur noch mit sehr
großem Aufwand und Spezialhardware möglich, weshalb hier Alternativen zum Einsatz
kommen müssen.
3.1.1 Bitcoin als Gehalt / Einnahme
Eine Möglichkeit an Bitcoin zu gelangen, ist seinen Arbeit- oder Auftraggeber zu bitten,
den Lohn für die Arbeitsleistung oder fällige Aufwandsentschädigungen komplett oder
teilweise in der Kryptowährung zu bezahlen. Dies gilt vor allem für Länder, in denen
Überweisungen aufgrund fehlender Bankkonten nicht möglich sind.
Bitcoin können als Zahlungsmittel im eigenen Unternehmen oder Webshop akzeptiert
werden, und dank einer Vielzahl kostenloser Programme ist auch das Empfangen auf
mobilen Geräten, wie dem Smartphone oder speziellen Hardwarewallets (Kapitel 0),
sehr einfach.
3.1.2 Börsen und Marktplätze
Die einfachste Möglichkeit an Bitcoin zu gelangen ist es, Bitcoin zu kaufen. Hierzu gibt
es diverse Marktplätze und Börsen (Exchanges), die es ermöglichen, andere Währungen
einzutauschen. Marktplätze stellen eine Plattform zur Verfügung, über die Ihre Nutzer
mit Bitcoin kaufen oder verkaufen können. Bei Bitcoin-Börsen ist es nötig, eine Wäh44
rung einzuzahlen und diese gegen eine andere zu tauschen. Hierbei ist es nicht relevant,
ob es sich um eine Krypto- oder eine Fiatwährung (Kapitel 2.2) handelt. Bis Ende 2014
war es deutschen Nutzern außerdem möglich, über die Plattform localbitcoins.com andere Nutzer zu finden und sich dann mit diesen direkt zu Treffen um Bitcoin gegen
Bargeld zu tauschen. Das dort eingesetzte Verfahren wird in dieser Arbeit nicht weiter
betrachtet. Im Folgenden werden ich drei Plattformen näher vorstellen.
3.1.2.1 Bitcoin.de
Bei Bitcoin.de handelt es sich im einen Marktplatz der Bitcoin Deutschland AG, die als
vertraglich gebundener Vermittler der Fidor Bank AG (Webseite: http://www.fidor.de)
auftritt. Durch die Bindung mit der Fidor Bank AG ist dem Nutzer höchste Sicherheit
beim Handel mit Bitcoin geboten.
Abbildung 12: Übersicht der möglichen An- und Verkäufe von Bitcoin
Um auf dem Marktplatz mit Bitcoin zu handeln, wird zunächst ein kostenloses Konto
vorausgesetzt. Hierzu werden zunächst ein Benutzername und ein Passwort festgelegt
und der Nutzer über eine gültige E-Mail-Adresse verifiziert. Als nächstes wird die Postanschrift abgefragt und zwingend eine gültige Mobilfunknummer angegeben, die über
ein SMS-Verifizierungsverfahren zu bestätigen ist. Als letzte Voraussetzung muss eine
gültige Kontoverbindung angegeben oder alternativ direkt über die Seite von bitcoin.de
45
ein Konto bei der Fidor Bank AG erstellt werden. Sollte ein bereits vorhandenes Konto
angegeben werden, dann ist dieses über ein Verifizierungsverfahren der
SOFORT GmbH (Webseite: www.sofort.com) zu bestätigen. Bei der SOFORT GmbH
handelt es sich um ein Unternehmen, das mit nahezu allen deutschen Banken zusammenarbeitet und in Deutschland Marktführer für Direktüberweisungsverfahren ist. Zur
Verifizierung des Bankkontos bucht bitcoin.de nun einen geringen Geldbetrag von dem
angegebenen Konto des Nutzers ab, der dieses durch die Eingabe seiner PIN bestätigt
und danach sofort verifiziert ist.
Ist die Mobilfunknummer und das Bankkonto bestätigt, steht dem Handel mit Bitcoin
nichts mehr im Wege. Bitcoin.de stellt dem Nutzer hierzu die nötige Infrastruktur bereit
und vermittelt und moderiert die Geschäfte zwischen den angemeldeten Nutzern.
Grundsätzlich sind alle verifizierten Nutzer, die die o.g. Bedingungen erfüllen, für den
Handel mit Bitcoin zugelassen. Allerdings ist das Handelsvolumen zunächst auf 2500 €
pro Jahr und 1000 € pro einzelnen Handel beschränkt. Um höhere Beträge handeln zu
können und eine vollständige Identifikation zu erreichen, bietet Bitcoin.de drei unterschiedliche Möglichkeiten an:
1. Es wurde in den letzten 12 Monaten ein Handelsvolumen (An- und Verkauf) von mindestens 10,5 Bitcoin erreicht.
2. Ein kostenloses Bankkonto wurde bei der Fidor Bank AG eingerichtet
3. Der Nutzer lässt sich um der SOFORT GmbH und einem kostenpflichtigen PostIdentVerfahren verifizieren.
Der Verifikationsstatus des Nutzers wird auf der Marktplatzseite angezeigt und bietet
zusätzliche Sicherheit beim Handel. Für eine Transaktion berechnet botcoin.de dem
Nutzer 1% Gebühr auf die Gesamtsumme, die zu jeweils der Hälfte vom Käufer und
Verkäufer getragen wird.
3.1.2.2 Kraken.com
Das bereits 2011 gegründete und in San Francisco/USA ansässige Unternehmen ermöglicht den Handel mit US Dollar, Euro, britischen Pfund und japanischen Yen. Hierbei
kann neben Bitcoin auch die alternative Kryptowährung Litecoin (LTC) eingesetzt werden. Zusätzlich können die Kryptowährungen Litecoin (LTC), Dogecoin (XDG). Ripple
(XRP), Namecoin (NMC), Stellar (STR) und Ven (XVN) gegen Bitcoin getauscht oder
mit Bitcoin gekauft werden. Litecoin und Namecoin werden im Anhang B vorgestellt.
Wie auch bitcoin.de ist kraken.com eine strategische Partnerschaft mit der von der
BaFIN9 überwachten Fidor Bank AG eingegangen und schafft somit eine erhöhte Vertrauensbasis für deutsche Nutzer.
9
BaFIN steht für Bundesanstalt für Finanzdienstleistungsaufsicht
46
Die Anmeldung gestaltet sich wie auch bei bitcoin.de mit Angabe eines Benutzernamens und E-Mail-Adresse einfach, und nach Verifizierung der E-Mail-Adresse kann ein
erster Blick auf das System geworfen werden. Ein Handel bzw. An- und Verkauf ist in
diesem Status, der von Kraken als Tier 0 bezeichnet wird, noch nicht möglich. Je nach
Verifikationsstufe ist ein festgelegtes Volumen für Ein- und Auszahlungen möglich.
Verifikation
Tageslimit
Monatliches Limit
Voraussetzung
Tier 0
0$
0$
Tier 1
1.000 $
5.000 $
2.
3.
4.
•
Kompletter Name
Geburtsdatum
Land (Staatsangehörigkeit und Aufenthalt)
Telefonnummer
Tier 2
2.000 $
10.000 $
•
•
Tier 1
Verifizierte gemeldete Adresse
Tier 3
20.000 $
100.000 $
•
•
•
Tier 2
Ausweisnummer
Nachweis des Aufenthalts an der gemeldeten Adresse (z.B. neueste Telefonrechnung)
Sozialversicherungsnummer (nur USA)
Foto eines Ausweises (nur Deutschland, z.B. Personalausweis, Reisepass oder Führerschein)
1. Benutzerkonto
•
•
Tier 4
100.000 $
500.000 $
•
Nur auf Anfrage möglich
Als Gebühren verlangt Kraken pro Transaktion von Bitcoin zu Euro (und umgekehrt)
lediglich 0.35% des gehandelten Betrages. Zusätzlich sind die Gebühren gestaffelt und
sinken je nach Handelsvolumen auf bis zu 0,1%. Als Berechnungsgrundlage werden
hierbei alle Ein- und Ausgänge innerhalb der letzten 30 Tage berücksichtigt. Der aktuelle Gebührensatz wird dem Nutzer auf seiner Übersichtseite angezeigt (siehe Abbildung
11).
Auszahlungen sind vom jeweiligen Partner abhängig und betragen bei einer SEPAÜberweisung der verfügbaren Euro auf das Referenzkonto 0,09 €. Hierbei ist es nicht
möglich, fremde Bankkonten anzugeben, und der Name des Zahlungsempfängers muss
immer dem des beim Benutzerkonto hinterlegten und verifizierten Kontakts entsprechen. Eine Auszahlung ist zudem als SWIFT-Überweisung möglich; allerdings sind
Auszahlungen hier deutlich teurer: Kraken berechnet eine Gebühr von 5,00 € für Zahlungen an SEPA-Konten oder an Bankkonten innerhalb von den USA und Kanada. Für
alle anderen Länder werden 40,00 € EUR berechnet. Als weitere Einschränkung sind
47
aufgrund
grund der Bankenrichtlinien der Fidor Bank AG Zahlungen per SWIFTÜberweisung nur an Banken möglich, die sich in dem Land befinden, in dem der Nutzer
gemeldet ist.
Abbildung 13: Übersichtsseite der Bitcoin-Börse
Börse Kraken.com
3.1.2.3 Coinbase.com
oinbase.com
Eine weitere Handelsplattform
lattform für Bitcoin ist Coinbase.com. Das Unternehmen wurde
im Juni 2012 gegründet und hat ebenfalls in San Francisco seinen Hauptsitz. Coinbase
legt seinen Schwerpunkt auf die Verwaltung der Bitcoin in einem Online-Wallet
Online
in der
jeweiligen Landeswährung. Auch Coinbase benötigt ein Benutzerkonto mit entspreentspr
chender Verifizierung
rung der E-Mail-Adresse
E
Adresse und zur weiteren Absicherung des Kontos
eine Empfangsmöglichkeit
lichkeit für SMS. Coinbase ermöglicht aktuell (Juni 2015) den Anund Verkauf
kauf in der Landeswährung des Nutzers in 25 unterschiedlichen Ländern und ist
in deutscher Sprache verfügbar. Auszahlungen in Euro werden in Deutschland alleralle
dings noch nicht unterstützt
terstützt und so ist lediglich das Wallet nutzbar. Hier bietet Coinbase
als besonderen
onderen Service einen Tresor,
Tresor um die Bitcoin sicher aufzubewahren,
aufzubewahren sowie die
Möglichkeit, jede Transaktion aus dem Tresor zu einer beliebigen Adresse innerhalb
von 48 Stunden abzubrechen. Der Tresor verfügt zudem über ein MehrfachsignaturenMehrfac
Wallet um das eigene
igene Guthaben
Gu
zu schützen.
48
In den Ländern, die von Coinbase unterstützt werden, hat der Nutzer lediglich eine
Ausweiskopie hochzuladen und über eine Einzahlung sein eigenes Bankkonto zu verknüpfen.
3.1.3 Geldautomaten
Eine besonders komfortable Möglichkeit um Bargeld gegen Bitcoin zu tauschen sind
Geldautomaten. Hierbei wird zwischen 1-Way-Geldautomaten, also Automaten, die nur
eine Richtung ermöglichen und die die eingezahlte Landeswährung in Bitcoin umrechnen und dem Betrag an das angegebene Wallet übertragen und 2-Way-Geldautomaten
unterschieden. 2-Way-Automaten ermöglichen zusätzlich die Auszahlung von Bargeld,
was vor allem für Reisende interessant ist, die somit Ihr Bargeld nicht mitführen müssen, sondern bequem an einem Automaten im Zielland den benötigten Bargeldbetrag in
der Landeswährung abheben können.
Beim Abhebungsprozess ist es jedoch notwendig, dass sich der entsprechende Anwender ausreichend verifiziert und der entsprechende Bitcoin-Betrag auch von anderen
Netzteilnehmern bestätigt wird. Je nachdem, wann der nächste Block gefunden wird
(Kapitel 2.2.5.2), kann die Freigabe des Geldbetrages ein paar Minuten dauern.
Zu den ersten in Deutschland aufgestellten Bitcoin-Automaten gehört der am 05. Februar 2014 von Jörg Patzer in seiner Burgerbar „Room 77“ in Berlin Kreuzberg aufgestellte
1-Way-Automat der Firma Lamassu [Kannenberg 2012]. Schon ein Jahr zuvor überzeugte Patzer unterschiedliche Einzelhändler in der näheren Umgebung, die neue Währung für ihre Waren und Dienste zu akzeptieren [Weiss 2012].
Der günstigste verfügbare 1-Way-Automat ist bereits für 999 $ zu bekommen10; jedoch
gestaltet sich das Aufstellen eines Automaten aufgrund der rechtlichen Voraussetzungen
in Deutschland sehr schwierig. Auf zwei Monate begrenzte Testaufstellungen mit einem
maximalen Transaktionsvolumen von 100 € werden von der zuständigen Bundesanstalt
für Finanzdienstleistungsaufsicht (BaFin) als nicht kommerzielle Nutzung eingestuft.
Soll der Einsatz jedoch ausgeweitet werden, ist eine entsprechende Lizenz notwendig
[Bock 2014].
3.2
Bitcoin-Programme
Um verfügbare Bitcoin einsetzen zu können, den Überblick über Adressen zu behalten
und um die privaten Schlüssel zu schützen, wird ein Client benötigt, der ein oder mehrere Wallets (Kapitel 2.2.4.3) verwalten kann. Im folgenden Abschnitt werden einige
Möglichkeiten und die Unterschiede verschiedener Clients näher beschrieben.
10
Projekt Skyhook – Webseite http://www.projektskyhook.com
49
3.2.1 Full-Node-Clients
Clients
Als Full-Node-Client
Client wird ein Programm bezeichnet, das als vollwertiger NetzwerkknoNetzwerkkn
ten fungiert. Der Client bezieht beim ersten Programmstart die gesamte Blockchain aus
dem Netz und speichert diese auf der Festplatte des Computers. Da die Blockchain eine
Größe von mehreren Gigabyte einnimmt, dauert das Laden je nach Netzanbindung einiein
ge Stunden
tunden oder sogar Tage.
T
Ein Full-Node-Client
Client ist ein wichtiger Bestandteil des Bitcoin-Systems
Systems und dieses,
dieses indem der Transaktionen und Blöcke verifiziert und an angeschlossene Peers weiterleitet
weiterle
werden.
Abbildung 14: Überweisungsdialog
ungsdialog des Bitcoin Core Clients
Der Referenzclient Bitcoin Core ist übersichtlich gestaltet und bietet
etet die wichtigsten
Funktionen wie:
•
•
•
•
•
Verwalten von EinEin und Ausgangsadressen
Übersicht der EinEin und Ausgangstransaktionen
Sicherung und Verschlüsselung des
d Wallets
Nachrichten Signieren und Verifizieren
Kommandozeilenfunktionen zur Abfrage
Abfr ge und Aktualisierung der Blockchain
50
Bei der Installation erstellt Bitcoin Core bereits 100 Adressen mit dazugehörigen
Schlüsseln, die in einer Wallet.dat gespeichert werden. Um diese Datei vor Fremdzugriffen zu schützen, ist im Client eine Verschlüsselungsoption eingebaut und der Anwender kann das Wallet und alle darin enthaltenen Schlüssel mit einem extra Passwort
sichern.
3.2.2
SPV-Clients
Steht wenig Speicherkapazität zur Verfügung und kann nicht der komplette Blockchain
geladen werden, dann ist es möglich eigene Zahlungen zu verifizieren, indem lediglich
die Blockheader gespeichert werden. Nakamoto beschreibt dieses Verfahren als
Simplified Payment Verification, kurz SPV [Nakamoto 2008]. Die Clients können über
aktive Full-Node-Clients auf die Blockchain zugreifen und anhand der Header feststellen, ob die jeweils längste und somit gültige Blockchain verwendet wird. Der im Header
gespeicherte Hashwert des Merkle-Trees ermöglicht dem SPV-Client alle Transaktionen herauszufiltern, in denen eigene Adressen gespeichert sind und ermöglichen somit
die Gültigkeit eigener Zahlungen zu überprüfen [Bitcoin 2015].
3.2.3 Serverabhängige-Clients
Programme, die von einem Server abhängig sind, werden auch als Thin-Clients bezeichnet. Der große Vorteil solcher Programme besteht darin, dass diese sehr ressourcenschonend arbeiten. Alle Informationen und Funktionen werden von einem Server
bereitgestellt, der wiederrum als Full-Node-Client fungier.
Die Wallets und somit auch die Schlüssel, werden nicht auf dem Server gespeichert,
sondern verbleiben auf dem Endgerät. Der quelloffene Client Copay11 bietet zusätzlich
die Möglichkeit Wallets zu verwalten, auf die bis zu sechs Anwender mit unterschiedlichen Schlüsseln zugreifen können. Zusätzlich kann bei einem gemeinsamen Wallet die
Anzahl der benötigten Unterschriften festgelegt werden. Eine Transaktion muss zunächst von bis zu vier unterschiedlichen Teilnehmern unterschrieben werden, bevor
diese ausgeführt wird [Buterin 2014].
3.3
Sicherung der Bitcoin
Damit verfügbare Bitcoin nicht von dritten Personen für eigene Zahlungen verwendet
werden, ist es notwendig Sicherheitsvorkehrungen zu treffen um dies zu verhindern.
Hierzu muss der Zugriff auf die privaten Schlüssel ausgeschlossen sein, was über unterschiedliche Methoden realisiert werden kann.
11
Webseite: https://copay.io
51
3.3.1 Zugriffskontrolle
Der Bitcoin Core Client bietet bereits die Möglichkeit, das Wallet mit einem Passwort
zu versehen und verschlüsselt abzuspeichern. Ein Angreifer, der Zugriff auf den Computer mit dem installierten Client erlangt, hat nun keine Möglichkeit Zahlungen durchzuführen und auf die privaten Schlüssel zuzugreifen. Gelingt es einem Angreifer jedoch
Schadsoftware zu installieren, dann ist beispielsweise über einen Keylogger12 möglich,
das Passwort zur Entschlüsselung des Wallets auszulesen und so Zugriff auf die Bitcoin
zu erlangen. Werden höhere Beträge über ein Wallet verwaltet, dann sind unbedingt
weitere Sicherheitsvorkehrungen zu treffen, um den Zugriff auf dieses zu verhindern.
3.3.2 Two-Factor- Authentication
Als Two-Factor-Authentication werden Verfahren bezeichnet, die neben der Eingabe
eines Passwortes noch einen weiteren Schritt voraussetzen, um Zugriff auf das System
zu erlangen. Hierzu wird ein externes Gerät eingesetzt, welches über eine spezielle
Software, einen zeitlich begrenzten PIN-Codes13 erzeugt. Dieser Code wird über die
Tastatur des Zielsystems eingegeben und verifiziert. Zu den bekanntesten Systemen, die
im Zusammenhang mit Kryptowährungen eingesetzt werden, gehören der Google
Authenticator, Authy und Yubikey.
3.3.2.1 Google Authenticator
Bei dem Google Authenticator handelt es sich um ein System, welches auf Basis des
hinterlegten Benutzernamens und aus dem aktuellen Zeitstempel, eine 6- oder 8stelligen nummerischen Code erzeugt. Dieser Code wird als zweiter Schritt, nach der
bereits erfolgten Bestätigung des Passwortes, in den Eingabedialog des entsprechenden
Programms eingegeben. Die Übermittlung des 6-stelligen Codes erfolgt über den Kurznachrichtendienst des Mobilfunknetzes (englisch für Short Message Service, Abk.
SMS) oder über eine spezielle mobile Anwendungssoftware. Diese hat den Vorteil, dass
der Anwender keine Netzverbindung benötigt und auch seine Mobilfunknummer nicht
bereitstellen muss. Der Google Authenticator berechnet den Code mit einer speziellen
Funktion, die den hinterlegten Benutzernamen und einen Zeitstempel benötigt. Zur Verifikation wird mit Hilfe einer mathematischen Formel, die Gültigkeit des Codes überprüft. Besitzt der Anwender kein mobiles Gerät, dann erfolgt die Verifikation über 8stellige Codes. Diese können auf der Google Webseite14 erzeugt werden. Der Anwender
kann jeweils 10 Codes ausdrucken, die solange Ihre Gültigkeit behalten, bis alle aufge-
12
Ein Keylogger ist ein Programm, das Tastaturanschläge aufzeichnet.
PIN ist die Abkürzung für Persönliche Identifikationsnummer
14
https://www.google.com/landing/2step
13
52
braucht wurden. Der freie Quelltext der Anwendung
https://github.com/google/google-authenticator zu finden.
ist auf der Webseite
3.3.2.2 Authy
Wie bei dem Google Authenticator, werden auch bei Authy Codes erzeugt und per SMS
oder einer speziellen App übermittelt. Authy erzeugt jedoch 7-stellige Codes mit einer
Gültigkeit von jeweils 20 Sekunden und benötigt für die Überprüfung der Gültigkeit
eine Netzverbindung. Bei diesem Verfahren sendet der Client, nach Eingabe des bereitgestellten Codes, diesen zusammen mit einer hinterlegten Kennung an den Server
des Anbieters. Dieser überprüft die Gültigkeit und sendet das Ergebnis als Antwort an
den Client. Eine entsprechende
http://docs.authy.com zu finden.
Dokumentation
ist
auf
der
Webseite
3.3.2.3 Yubikey
Der Yubikey15 ist ein spezielles Hardwaregerät, welches über den Universal Serial Bus
(USB) an den Computers angeschlossen wird und individuelle Codes erzeugt. Die Erzeugung eines neuen Codes übernimmt die Hardware und übermittelt diesen, nach Betätigung eines Tasters, direkt an den Eingabedialog des Clients. Die FIPS 140-2 Zertifizierung der NIST bestätigt, das Yubikey höchste Sicherheitsstandards erfüllt [NIST
2015].
3.3.3
Hardware-Wallets
Einen besonderen Schutz bieten Hardware-Wallets, da keine dauerhafte Verbindung mit
anderen Knoten existiert und Hardware-Wallets selber über keine Netzanbindung verfügen. Hardware-Wallets sind kleine Geräte, welche persönliche Schlüssel speichern
und Transaktionen erzeugen können. Um eine Transaktion zu erzeugen, muss das Gerät
an einen Computer angeschlossen werden, um so mit einem speziellen Bitcoin-Client
kommunizieren zu können. Die zu überweisenden Beträge und die dazugehörigen Adressen werden an das Gerät übermittelt und in diesem die notwendigen Transaktionen
generiert. Die Transaktionen werden im Anschluss an den Client übermittelt und von
diesem an das Netzwerk weitergeleitet. Die Besonderheit bei diesem Verfahren ist die
Tatsache, dass Transaktionen innerhalb des Gerätes unterschrieben werden. Der private
Schlüssel verlässt niemals das Gerät und wird zu keiner Zeit irgendeiner Person sichtbar
gemacht wird [Bitcoin Wiki 2015i].
3.3.4 Paperwallets
Wenn die Bitcoin Adressen und private Schlüssel nicht online gespeichert werden, dann
wird dieses Verfahren als Cold-Storage bezeichnet [Bitcoin Wiki 20015j]. Das Drucken
15
Webseite des Herstellers: http://www.yubico.com
53
der Adresse und des privaten Schlüssels auf ein Blatt Papier ist hierbei eine besondere
Art der Speicherung, da die Daten nach der Erzeugung nicht mehr digital vorliegen.
Wie in Kapitel 2.2.4.2 beschrieben, werden Adressen und private Schlüsseln mit kryptografischen Funktionen erzeugt, wodurch ein möglich ist, diese auf einem Computer
ohne Verbindung zum Netzwerk zu erzeugen.
Es existiert mit dem Entropy, ein USB-Stick der Firma Mycelium16 aus Luxembourg,
über den alle notwendigen Algorithmen und Verfahren von einem Atmel® ARM® Cortex®-M Mikroprozessor berechnet werden und direkt als Bild an einen angeschlossenen
Drucker ausgegeben werden [Mycelium 2015].
Die ausgedruckte Adresse kann dazu verwendet werden, um Bitcoin zu empfangen. Zur
Überweisung von Bitcoin, wird der private Schlüssel über einen Dialog in den BitcoinClient übertragen. Dies geschieht entweder per Tastatureingabe oder über eine angeschlossene Kamera, die einen QR-Code verarbeitet, der bei der Erzeugung des
Paperwallets ausgedruckt wurde.
16
Webseite: https://mycelium.com
54
4
Ergebnisse der Arbeit
Nach Betrachtung der Möglichkeiten, die eine Kryptowährung wie Bitcoin bietet, ist
vor allem viel Potenzial bei der Blockchain –Technologie zu erkennen. Der große Vorteil gegenüber anderen Systemen, ist die Tatsache, dass keine dritte Partei mehr benötigt
wird, der die Kommunikationspartner bei der Abwicklung Ihrer Zahlungen oder Geschäfte vertrauen müssen. Transaktionen werden von allen Teilnehmern, die sich gegenseitig nicht vertrauen müssen, überprüft und dezentral gespeichert. Viele Projekte
befinden sich bereits in der Entwicklung (Stand Mai 2015) und verifizieren Besitzrechte
oder intelligente, digitale, automatische Verträge über die Blockchain. Smart Contracts
ermöglichen bestimmte Ereignisse, die durch Programmcode in Form von Wenn-DannBedingungen ausgelöst und über die Blockchain verifiziert werden. Banken, Anwälte,
Notare oder Vermittler werden überflüssig [Keuper 2015]. Mögliche Szenarien sind
Kaufverträge, die nach Eingang einer Zahlung digitale Dokumente freischalten oder
Vereinbarungen, die erst zu bestimmten Zeiten eintreffen und den Zugriff auf festgelegte Beträge erst zu einem bestimmten Datum freigeben. Alle möglichen Szenarien,
kommen ohne einen Vermittler aus und die Gültigkeit der einzelnen Aktionen wird mit
mathematischen Formeln bewiesen.
In dieser Arbeit wird auch deutlich, dass Kryptowährungen noch einige Schwächen haben. Hierzu gehört vor allem die notwendige Erhöhung der Blockgröße und somit die
Möglichkeit mehr Transaktionen pro Tag zu überprüfen. Die Datenmenge wird immer
größer und es werden immer weniger Teilnehmer die ganze Blockchain speichern. Dies
hat zur Folge, dass die Dezentralität verloren geht und beschriebene Angriffsszenarien
möglich werden. Es gibt bisher noch keine Aussagen zur Belastbarkeit des Systems und
was passiert, wenn die Transaktionen nicht mehr abgearbeitet werden können.
Ausgehend von der Fragestellung der Arbeit, ob Kryptowährungen auch eine Alternative sein können, werden im Folgenden zwei mögliche Szenarien betrachtet.
4.1
Alternative zum Transport der SWIFT-Nachrichten
Das SWIFT-System bietet einen gesicherten Austausch von Nachrichten, deren Aufbau
im Laufe der Jahre und in Zusammenarbeit mit den Teilnehmern entwickelt wurde. Das
SWIFT-System ist hier lediglich ein Transportkanal um diese Nachrichten zu übermitteln. Die einzelnen Nachrichten werden dabei verschlüsselt über festgelegte Kommunikationswege übertragen und von den Konzentratoren und Operating Centern überprüft.
55
Der zentrale Aufbau des SWIFT-Systems könnte durch die Nutzung der dezentral gespeicherten Blockchain abgelöst werden. Die Eingabeterminals könnten direkt über die
Blockchain mit dem Empfänger kommunizieren und Konzentratoren und teure Operating Center könnten eingespart werden.
Der verschlüsselte Nachrichteninhalt könnte weiterhin das festgelegte Format behalten
und in einer oder in mehreren Transaktionen gespeichert werden. Die Daten wären nicht
für andere lesbar und können nur vom Empfänger entschlüsselt werden. Die Speicherung erfolgt dabei über speziell für diesen Zweck erzeugte Adressen, deren Hashwert
jeweils einen Teil der Nachricht bilden. Größere Nachrichten könnten über mehrere
Transaktionen in der Blockchain gespeichert werden. Ein 2,5 MB großes Dokument
wurde bereits erfolgreich über 120 Transaktionen in der Blockchain gespeichert.
[Bergmann 2014]. Der Überweisungsbetrag für eine solche Transaktion sollte nicht zu
gering gewählt werden. Erfolgreiche Transaktionen wurden mit jeweils 5500 Satoshi =
0,000055 BTC verschickt17.
Eine Umstellung der aktuellen SWIFT-Transportkanäle auf die Blockchain-Technologie
ist unter Berücksichtigung der aktuellen technischen Möglichkeiten momentan nicht
realisierbar. Das Bitcoin-System kann momentan die Anzahl der täglichen Nachrichten
des SWIFT-Systems nicht bewältigen. Dies kann anhand einer kleinen Beispielrechnung verdeutlicht werden.
Transaktionen mit jeweils einem Eingang und einem Ausgang haben eine Größe von
134 Bytes. Wird die Größe des Blockheaders vernachlässigt und die maximal mögliche
Blockgröße durch die Größe einer Transaktion geteilt, dann ist das Ergebnis die maximal mögliche Anzahl der Transaktionen pro Block. Ausgehend von einer durchschnittlichen Blockanzahl von 144 pro Tag, kann so die maximale Anzahl an Transaktionen
errechnet werden:
⋅
≈
'
Bei dieser Rechnung wird die kleinstmögliche Transaktionsgröße als Grundlage genommen und liefert eine Anzahl von etwa 1 Million möglichen Transaktionen pro Tag.
Tatsächlich kommen solche kleinen Transaktionen nur noch vor, wenn ein einzelner
Miner alleine einen Block erzeugt. Aus diesem Grund die tatsächliche Anzahl der möglichen Transaktionen wesentlich geringer.
Würden wir eine Blockgröße von 20 MB zur Berechnung heranziehen, dann würde das
Bitcoin-System bei 134 Bytes großen Transaktionen immerhin 21492537 Transaktionen
pro Tag ermöglichen. Dieses Ergebnis von ca. 21,5 Millionen Transaktionen liegt unter
17
Siehe Hilfeseite der Webseite http://cryptograffiti.info
56
der Anzahl der Nachrichten, die vom SWIFT-System pro Tag verarbeitet werden und
die im Jahresbericht 2013 mit 22 Millionen angegeben wurde ([SWIFT 2014], S. 2).
Der Einsatz der Blockchain-Technologie des Bitcoin-Systems kommt auf Grundlage der
beschriebenen Erkenntnisse als Alternative für den Transport der Nachrichten nicht in
Frage.
4.2
Alternative als internationales Zahlungsmittel
Das SWIFT-System ermöglicht über den Austausch von Nachrichten den Transfer von
Geld oder andern Werten. Als zentral gesteuertes System mit festgelegten Regeln, entscheiden die beteiligten Banken darüber, wer dieses System nutzen darf. Wie in Kapitel
2.1.4.2 (Nachteile des SWIFT-Systems) beschrieben, könnten ganze Länder unter bestimmten Umständen ausgeschlossen werden und wären somit in Ihrer Handlungsfähigkeit stark eingeschränkt. Innerhalb des jeweiligen Landes sind Zahlungen weiterhin
möglich, für internationale Zahlungen gibt es jedoch nur wenige Alternativen.
Desweiteren existieren eine unbestimmte Anzahl von Menschen in den jeweiligen Ländern, die aus unterschiedlichen Gründen über kein eigenes Konto verfügen, woraus sich
eine starke Abhängigkeit von anderen ergibt.
Ausgehend von diesen Tatsachen, ist feststellbar, dass Kryptowährungen nicht nur eine
Alternative für das SWIFT-System sind, sondern darüber hinaus sogar für viele die einzige Möglichkeit Geldbeträge zu erhalten oder zu verschicken.
Um eine Kryptowährung wie Bitcoin zu nutzen, bedarf es lediglich einer Internetverbindung. Zum Empfang wird lediglich eine Adresse benötigt. Hierbei sind keine
Höchstbeträge oder sonstige Limitierungen zu berücksichtigen und es ist auch kein besonderes Dokument nötig, um sich auszuweisen. Bestimmte Zahlungen könnten darüber
hinaus besonders gekennzeichnet werden, um so beispielsweise Transparenz beim
FairTrade-Handel zu ermöglichen.
Es sind spontane Zahlungen möglich um kurzfristig Familienangehörige oder Freunde
im Ausland zu unterstützen, die eventuell gerade Ihr Taxi nicht bezahlen können oder
beim Einkauf neuer Kleidung nicht das passende Kleingeld dabei haben. Hierbei spielt
es keine Rolle an welchem Ort der Welt sich diese Person aufhält. Bitcoin können ohne
großen Zeitaufwand und mit geringen Kosten übermittelt werden.
57
5
Fragen und Ausblicke
Kryptowährungen befinden sich noch in der Betaphase und werden kontinuierlich weiterentwickelt. Doch täglich werden neue Nachrichten und Pläne veröffentlicht. Es können bereits heute eine große Zahl unterschiedlicher Waren mit Bitcoin bezahlt werden.
Täglich kommen neue Möglichkeiten hinzu, die den Besitz und die Verwendung von
Bitcoin sinnvoller machen.
Es sind noch einige Hürden zu bewältigen, die den Einsatz hemmen. Hierzu gehört, das
fehlende Verständnis des Bitcoin Systems. Rechtliche und steuerliche Grundlagen sind
nicht geklärt, um Bitcoin sinnvoll einsetzen zu können. Hier sind die Institutionen gefordert Regeln aufzustellen und für die nötige Aufklärung zu sorgen.
Bitcoin steht vor großen Aufgaben, allen voran die Erhöhung der Blockgröße. Auch in
diesem Fall gibt es noch keine Erfahrungswerte, wie sich das Gesamtnetzwerk verhält
und welche Schwierigkeiten durch die neuen Datenmengen entstehen.
Smart Contracts zeigen nur eine Möglichkeit, eine Kryptowährung zu nutzen, wie es
bisher nicht möglich war. Bitcoin liefert eine neue Transportmöglichkeit für Vertrauen
und Regeln. Die Blockchain kann Prozesse steuern und erleichtert eine Vielzahl von
Entscheidungen. Die Teilnehmer bestimmen, wie Ihr Vermögen eingesetzt wird und
können Ihre Zahlungen in einer neuen Dimension verfolgen.
Ob ein System wie SWIFT zukünftig ersetzbar ist, kann zum heutigen Zeitpunkt nicht
beantwortet werden. Fest steht aber: Kryptowährungen wie Bitcoin gehören schon jetzt
für viele Menschen zum Alltag und das wird es auch so bleiben.
58
6
6.1
Literaturverzeichnis
Bücher und Zeitschriften
[Dobberin/Bosselaers/Preneel 1996]
H. Dobbertin, H., Bosselaers, A. und B. Preneel: RIPEMD-160: a strengthened version
of RIPEMD, Fast Software Encryption, Lecture Notes in Computer Science 1039,
Heidelberg 1996
[Etzkorn 1991]
Etzkorn, J.: Rechtsfragen des internationalen elektronischen Zahlungsverkehrs durch
S.W.I.F.T, Berlin 1991
[Ladig 2006]
Ladig, P.: S.W.I.F.T.- Eine Strukturanalyse des internationalen Datennetzes der Banken,
Seminararbeit, Berlin 2006.
[Loh 1983]
Loh, W. W.: Das S.W.I.F.T.-System. Die moderne Datenübertragung im internationalen
Zahlungsverkehr, Frankfurt 1983.
[Miller 2005]
Miller, M.: Geopolitische Vermögenssteuerung: Vermögensanlage rund um den Globus
- von Andorra über Panama und Singapur bis Zypern, München 2005.
[Platzer 2014]
Platzer, J., Bitcoin - kurz & gut: Banking ohne Banken, Köln 2014
[Schimansky/Bunte/Lwowski 2011]
Schimansky, H., Bunte H.-J. und H.-J. Lwowski, Bankrechts-Handbuch; 4. Aufl.,
München 2011
[Schmeh 2013]
Schmeh, K.: Kryptografie: Verfahren, Protokolle, Infrastrukturen; 5. Aufl. Heidelberg
2013.
[Schricker/Rubin 1992]
Schricker, W. und E. Rubin: Geld & Kredit & Währung; 6. Aufl., München 1992.
[Wahlers 2013]
Wahlers, K.: Die rechtliche und ökonomische Struktur von Zahlungssystemen innerund außerhalb des Bankensystems, Berlin 2013
6.2
Online-Quellen
[Bale 2012]
Bale, S.: SWIFT ist nach Beschluss des EU-Rats angewiesen, von Sanktionen betroffene iranische Banken von seinen Services auszuschließen, SWIFT-Pressemitteilung, 15.
März 2012,
http://www.swift.com/resources/documents/PR_Iran_BIC_disconnection_de.pdf
[29.11.2014]
59
[Barth 2012]
Barth, M. und Bundesverband Bitcoin e.V.: SEPA-Leitfaden, Berlin 2012.
http://www.bitkom.org/files/documents/BITKOM_SEPA-Leitfaden.pdf [17.09.2014]
[Bergmann 2014]
Bergmann, Ch.: Versteckte Botschaften in der Blockchain, August 2014
http://bitcoinblog.de/2014/08/27/versteckte-botschaften-in-der-blockchain [24.04.2015]
[Bitcoin 2015]
Bitcoin Wiki (diverse Autoren): Bitcoin Developer Guide
https://bitcoin.org/en/developer-guide [23.05.2015]
[Bitcoin Quellcode 2015]
Bitcoin Quellcode (diverse Autoren): Branch 0.11
https://github.com/bitcoin/bitcoin/tree/0.11 [22.04.2015]
[Bitcoin Wiki 2015]
Bitcoin Wiki (diverse Autoren): Technical background of version 1 Bitcoin addresses,
https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
[09.03.2015]
[Bitcoin Wiki 2015a]
Bitcoin Wiki (diverse Autoren): Base58Check encoding,
https://en.bitcoin.it/wiki/Base58Check_encoding [09.03.2015]
[Bitcoin Wiki 2015b]
Bitcoin Wiki (diverse Autoren): List of address prefixes,
https://en.bitcoin.it/wiki/List_of_address_prefixes [09.03.2015]
[Bitcoin Wiki 2015c]
Bitcoin Wiki (diverse Autoren): Controlled Supply,
https://en.bitcoin.it/wiki/Controlled_supply [09.03.2015]
[Bitcoin Wiki 2015d]
Bitcoin Wiki (diverse Autoren): Block hashing algorithm,
https://en.bitcoin.it/wiki/Block_hashing_algorithm [10.04.2015]
[Bitcoin Wiki 2015e]
Bitcoin Wiki (diverse Autoren): Weaknesses
https://en.bitcoin.it/wiki/Weeknesses [10.04.2015]
[Bitcoin Wiki 2015f]
Bitcoin Wiki (diverse Autoren): Double spending
https://en.bitcoin.it/wiki/ Double-spending [10.04.2015]
[Bitcoin Wiki 2015g]
Bitcoin Wiki (diverse Autoren): Mining hardware comparison,
https://en.bitcoin.it/wiki/Mining_hardware_comparison [23.05.2015]
[Bitcoin Wiki 2015h]
Bitcoin Wiki (diverse Autoren): Non specialized hardware comparison,
https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison [23.05.2015]
[Bitcoin Wiki 2015i]
Bitcoin Wiki (diverse Autoren): Hardware wallet,
https://en.bitcoin.it/wiki/Hardware_wallet [23.05.2015]
[Bitcoin Wiki 2015j]
Bitcoin Wiki (diverse Autoren): Cold storage,
https://en.bitcoin.it/wiki/Cold_storage [23.05.2015]
60
[Black 1997]
Black, A.: hash cash postage implementation, 1997
http://www.hashcash.org/papers/announce.txt [09.03.2015]
[Black 1997a]
Black, A.: Hashcash, 1997
http://www.cypherspace.org/hashcash/docs/hashcash.html [10.04.2015]
[Bock 2014]
Bock, T.: Eröffnung des ersten Bitcoin Automaten in Süddeutschland , München 2014
http://satoshibay.com/de/bitcoin-automaten-in-muenchen/ [10.04.2015]
[Brzoska 2014]
Brzoska, M.: Neues Geld, neue Sorgen, Hamburg 2014.
http://www.zeit.de/2014/02/bitcoin-digitale-waehrung [07.09.2014]
[BÜSO 2014]
Bürgerrechtsbewegung Solidarität: Russland und China schaffen Alternative zum
SWIFT-System, Mainz 2014.
https://www.bueso.de/node/7671 [18.09.2014]
[Bundesverband Bitcoin 2014]
Bundesverband Bitcoin e.V.: Das Bundesministerium für Finanzen droht Deutschland
zum Innovationsverlierer zu machen, Pressemitteilung, Berlin 2014.
http://www.bundesverband-bitcoin.de/wpcontent/uploads/2014/05/PressemitteilungUmsatzsteuer.pdf [07.09.2014]
[Buterin 2014]
Buterin, V.: Pybitcointools Multisig Tutorial, 2014
https://bitcoinmagazine.com/11113/pybitcointools-multisig-tutorial [10.05.2015]
[C24 2014]
C24 Technologies: Learn More About SWIFT, 2014
https://www.c24.biz/what-is-swift.html [20.12.2014]
[Chaum 1983]
Chaum, D.: Blind signatures for untraceable payments, Santa Barbara 1983
http://www.hit.bme.hu/~buttyan/courses/BMEVIHIM219/2009/Chaum.BlindSigForPay
ment.1982.PDF [20.12.2014]
[Dai 1998]
Dai, W.: b-money, 1998
http://www.weidai.com/bmoney.txt [20.12.2014]
[Danova 2014]
Danova, H.: Official statement on 51% threat and closed round table, London 2014
http://blog.cex.io/news/official-statement-on-51-threat-and-closed-round-table-6619
[10.04.2015]
[EBA 2014]
European Banking Authority, EBC Opinion on ‘virtual currencies’, London 2014
http://www.eba.europa.eu/documents/10180/657547/EBA-Op-201408+Opinion+on+Virtual+Currencies.pdf [20.12.2014]
[EBICS 2014]
SIZ GmbH, EBICS - Electronic Banking Internet Communication Standard, Bonn 2014
http://www.ebics.de/fileadmin/unsecured/anlage3/anlage3_spec/Anlage_3_Datenformat
standards-V2.8_Final.pdf [20.12.2014]
61
[ECB 2012]
European Central Bank, Virtual Currency Schemes, Frankfurt am Main 2012
http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf
[20.12.2014]
[Feld 2013]
Feld, C. : Reaktion des EU-Parlaments auf NSA-Aktion – Wird SWIFT-Abkommen
ausgesetzt? Tagesschau.de, Brüssel 23. Oktober 2013.
http://www.tagesschau.de/ausland/swift180.html [29.11.2014]
[Fennen 2013]
Fennen, N.: Netzpolitik.org: Bundesregierung erkennt Bitcoin als privates Geld an, Berlin 2013.
https://netzpolitik.org/2013/deutsche-bundesregierung-erkennt-bitcoin-als-privatesgeld-an [07.09.2014]
[GHash.IO 2014]
(unbekannter Autor): GHash.IO is open for discussion, London 2014
http://www.pressat.co.uk/releases/ghashio-is-open-for-discussion93ee9eeb66b80e94bbe31705d451780e/ [10.04.2015]
[Kannenberg 2014]
Kannenberg, A.: Bitcoin: Erstmals gefährliche Konzentration der Mining-Leistung,
Hannover 2014
http://www.heise.de/newsticker/meldung/Bitcoin-Erstmals-gefaehrliche-Konzentrationder-Mining-Leistung-2224113.html [10.04.2015]
[Karame/Androulaki/Capkun 2012]
Karame, G.O., Androulaki, E. und S. Capkun: Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Payments in Bitcoin, Heidelberg/Zürich 2012
http://eprint.iacr.org/2012/248.pdf [10.04.2015]
[Keuper 2015]
Keuper, R.: Wie Smart Contracts Banken überflüssig machen, 2014
http://www.it-finanzmagazin.de/blockchain-bitcoins-wie-smart-contracts-bankenueberfluessig-machen-werden-9078 [04.05.2015]
[King/Nadal 2012]
Sunny King, S. und S. Nadal: PPCoin: Peer-to-Peer Crypto-Currency with Proof-ofStake, 2012
www.peercoin.net/assets/paper/peercoin-paper.pdf [10.05.2015]
[Koschyk 2013]
Koschyk, H.: Antwortschreiben auf Frage Nr. 409 für Juli 2013, Berlin 2013.
http://www.frank-schaeffler.de/wp-content/uploads/2013/08/2013_08_07-AntwortKoschyk-Bitcoins-Umsatzsteuer.pdf [07.09.2014]
[Krieger 2001]
Krieger, U.: Elliptische Kurven – Basis für ein alternatives Public Key Kryptosystem,
Gelsenkirchen 2001
http://www.ecc-brainpool.org/art_it.pdf [abgerufen am 20.05.2015]
[Lamport/Shostak/Please 1982]
Lamport, L., Shostak, R. und M. Please: The Byzantine Generals Problem, 1982
http://research.microsoft.com/en-us/um/people/lamport/pubs/byz.pdf [10.04.2015]
62
|Marwan 2008]
Marwan, P.: Deutsche Post macht Filiale in Secon Life zu, München 2008.
http://www.zdnet.de/39186538/deutsche-post-macht-filiale-in-second-life-zu
[18.03.2015]
[Merkle 2012]
R. C. Merkle, Comments in 2012 about the 1979 paper: A Certified Digital Signature,
2012
http://www.merkle.com/papers/Certified1979.pdf [10.04.2015]
[Mock/Theil 2014]
Mock, M. und S. Theil: Bitcoins – eine virtuelle Währung, Berlin 2014.
https://www.bundestag.de/blob/284592/dd2ebc5320cf5af551cfff024871c7e1/bitcoins--eine-virtuelle-waehrung-data.pdf [06.09.2014]
[MPPRR 2013]
Matusiewicz, K, Pieprzyk J., Pramstaller, N., Rechberger, Ch. und V. Rijmen: Analysis
of simplified variants of SHA-256*, Sydney/Graz 2013
http://subs.emis.de/LNI/Proceedings/Proceedings74/GI-Edition74.-12.pdf [10.04.2015]
[Mycelium 2015]
(unbekannter Autor): Mycelium Entropy User Manual, Luxembourg 2015
https://mycelium.com/assets/entropy/me.html [20.05.2015]
[Münzer 2013]
Münzer, J.: Bundesanstalt für Finanzdienstleistungsaufsicht: Bitcoins: Aufsichtliche
Bewertung und Risiken für Nutzer, Bonn 2013.
http://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Fachartikel/2014/fa_bj_1401
_bitcoins.html [07.09.2014]
[Nakamoto 2008]
Nakamoto, S.: Bitcoin: A Peer-to-Peer Electronic Cash System, Whitepaper.
https://bitcoin.org/bitcoin.pdf [21.10.2014]
[Nikolsky 2014]
Nikolsky, A.: Russia, China in talks to make alternative to SWIFT — Pressemitteilung,
Moskau (Russland) 2014.
http://en.itar-tass.com/economy/748916 [18.09.2014]
[NIST 2009]
National Institute of Standards and Technology: FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION: Digital Signature Standard (DSS),
Gaithersburg 2009
http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf [20.05.2015]
[NIST 2012]
National Institute of Standards and Technology: FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION: Secure Hash Standard (SHS), Gaithersburg
2012
http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf [24.05.2015]
[NIST 2015]
National Institute of Standards and Technology: Cryptographic Module Validation Program, 2015
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm [20.05.2015]
63
[NZZ 2013]
Neue Züricher Zeitung: Swift bestreitet NSA-Spionage
http://www.nzz.ch/aktuell/schweiz/swift-bestreitet-nsa-spionage-1.18151215
[28.12.2014]
[Percival 2009]
Percival, C.: Stronger Key derivation via sequential memory-hard Functions, 2009
http://www.tarsnap.com/scrypt/scrypt.pdf [20.05.2015]
[Pitta 1999]
Pitta, J.: Forbes: Requiem of a Bright Idea, Jersey City 1999
http://www.forbes.com/forbes/1999/1101/6411390a.html [20.12.2014]
[Raid/Harrigan 2012]
Raid, F. und M. Harrigan: An Analysis of Anonymity in the Bitcoin System, 2012
http://arxiv.org/pdf/1107.4524v2.pdf [10.05.2015]
[Ripple Labs 2014]
Ripple Labs Inc.: The Ripple Protocol Primer, San Francisco 2014.
https://ripple.com/ripple_primer.pdf [20.09.2014]
[Riverst 1992]
Request for Commits 1320: The MD4 Message-Digest Algorithm, 1992.
http://www.rfc-editor.org/rfc/rfc1320.txt [20.03.2014]
[Riverst 1992a]
Request for Commits 1321: The MD5 Message-Digest Algorithm, 1992.
http://www.rfc-editor.org/rfc/rfc1321.txt [20.03.2014]
[Rosenfeld 2012]
Mosenfeld, M.: Analysis of hashrate-based double-spending, 2012.
https://bitcoil.co.il/Doublespend.pdf [10.04.2015]
[Rudlof 2006]
Rudlof, C.: Handbuch Software-Ergonomie, Tübingen 2006.
http://www.ukpt.de/pages/dateien/software-ergonomie.pdf [10.09.2014]
[Sokolov 2014]
Sokolov, D.: Schallplatte als Wallet für Bitcoins und andere Kryptowährungen, Hannover 2014.
http://www.heise.de/security/meldung/Schallplatte-als-Wallet-fuer-Bitcoins-undandere-Kryptowaehrungen-2305829.html [08.09.2014]
[Stöcker 2007]
Stöcker, C.: "Second Life"-Wahlkampf: Sarkozy geht ins Netz, Hamburg 2007.
http://www.spiegel.de/netzwelt/spielzeug/second-life-wahlkampf-sarkozy-geht-insnetz-a-468836.html [18.03.2015]]
[SUISSE BANK 2014]
O.V.: SWIFT, London 2014.
https://www.suissebank.com/de/organisation-und-berichte/lexikon/swift.html
[17.09.2014]
[SWIFT 2014]
O.V.: Creating confidence in a changing world. Annual Review 2013, La Hulpe
(Belgien) 2014.
http://www.swift.com/assets/swift_com/documents/about_swift/2013_SWIFT_Annual_
Review.pdf [17.09.2014]
[SWIFT 2014a]
64
S.W.I.F.T.: User Handbook, La Hulpe 2014.
https://www2.swift.com/uhbonline/books/a2z/a2z.htm [17.09.2014]
[SWIFT 2014b]
O.V.: SWIFT Sanctions Statement, La Hulpe 2014.
http://www.swift.com/about_swift/shownews?param_dcr=news.data/en/swift_com/201
4/PR_swift_sanctions_statement.xml [29.11.2014]
[SWIFT 2014c]
S.W.I.F.T.: List of SWIFT Standards MT and SWIFT Standards MX
http://www.swift.com/resources/documents/standards_inventory_of_messages.pdf
[20.12.2014]
[Wang/Yao/Yao 2004]
Wang, X., Yao, A.C. und F. Yao: Cryptanalysis on SHA-1, Tsinghua 2004
http://csrc.nist.gov/groups/ST/hash/documents/Wang_SHA1-New-Result.pdf
[20.03.2015]
[Wendt 2015]
Wenddt, J.:Silk-Road-Gründer muss lebenslang hinter Gitter
http://www.zeit.de/digital/internet/2015-05/ross-ulbricht-silk-road-strafmass-urteil
[30.03.2015]
[Wikipedia 2015]
Wikipedia (Diverse Autoren): Kernkraftwerk Grohnde, 2015
https://de.wikipedia.org/wiki/Kernkraftwerk_Grohnde [10.04.2015]
65
6.3
Abkürzungsverzeichnis
ASIC
BIC
BTC
CPU
DSA
ECC
ECDSA
GPA
FIN
IBAN
LTC
NIST
NSA
MD
MT
MX
PIN
PoW
PoS
S.W.I.F.T.
SPV
SHA
XML
XRP
CBT
LT
MIR
MOR
MUR
OPC
TRN
Application-specific integrated circuit
Business Identifier Code
Bitcoin (Kryptowährung)
Central processing unit
Digital Signature Algorithm
Elliptic Curve Cryptography
Elliptic Curve Digital Signature Algorithm
General Purpose Application
Financial Application
International Bank Account Number
Litecoin (Kryptowährung)
National Institute of Standards and Technology
National Security Agency
Message Digest
SWIFT-Nachrichtentyp (Message Type)
SWIFT-Nachrichtentyp auf XML-Basis
Persönliche Identifikationsnummer
Proof of Work (deutsch Arbeitsnachweis bzw. beweis)
Proof of Stake (deutsch Anteilsnachweis)
Society for Worldwide Interbank Financial Telecommunication
Simplified Payment Verification
Secure Hash Algorithm
Extensible Markup Language
Ripple (Kryptowährung)
Computer Based Terminal
Login Terminal
Message Input Reference
Message Output Reference
Message User Reference
Operating Center (Schaltzentrale des SWIFT-Netzwerkes)
Transaction Reference Number
66
7
Abbildungsverzeichnis
Abbildung 1: Architektur des SWIFT-Systems [C24 2014] .......................................... 17
Abbildung 2: Größe der Bitcoin-Datenbank (Quelle: blockchain.info) ......................... 25
Abbildung 3: Modell eines dezentralen Peer-to-Peer Netzwerks ................................... 26
Abbildung 4: QR-Bild zur generierten Bitcoin-Adresse ................................................ 27
Abbildung 5: Alice möchte Bob 50 BTC überweisen .................................................... 29
Abbildung 6: Schematische Darstellung der Eingänge .................................................. 29
Abbildung 7: Schematische Darstellung der Ausgänge ................................................. 30
Abbildung 8: Anwendung der Schlüssel bei Transaktionen [Nakamoto 2008] ............. 31
Abbildung 9: Aneinanderreihung von Blöcken ([Platzer 2014], S.21) .......................... 32
Abbildung 10: Problem der Byzantinischen Generäle ................................................... 37
Abbildung 11: Grafische Benutzungsschnittstelle eine Antminer S3 zur Einstellung
eines Miningpools............................................................................................. 41
Abbildung 12: Übersicht der möglichen An- und Verkäufe von Bitcoin ....................... 45
Abbildung 13: Übersichtsseite der Bitcoin-Börse Kraken.com...................................... 48
Abbildung 14: Überweisungsdialog des Bitcoin Core Clients ....................................... 50
Abbildung 15: Addition von Punkten auf einer elliptischen Kurve ............................... 72
67
Anhang
A
Kryptografische Funktionen
Kryptowährungen nutzen unterschiedliche kryptografische Verfahren, um das jeweilige
System vor Manipulationen zu schützen. Bitcoin wendet zur Erzeugung der Schlüssel
das ECDSA-Verfahren an, bei dem der DSA (Kapitel A.1) um elliptische Kurven erweitert wird. Zudem werden unterschiedliche Hashfunktionen eingesetzt um Blocke
und Adressen zu verifizieren und Manipulationen zu erschweren.
A.1
Digitale Signaturen
Eine digitale Signatur ist eine Prüfsumme, die entsteht, wenn ein elektronisches Dokument mit einem geheimen privaten Schlüssel erzeugt wird. Dieser Schlüssel ist nur
demjenigen bekannt, der das Dokument unterscheibt. Möchte nun ein Dritter die Gültigkeit dieser Signatur auf diesem elektronischen Dokument prüfen, dann benötigt er
einen korrespondierenden öffentlichen Schlüssel. Verfahren, die einen öffentlichen
Schlüssel zur Verifikation eines Dokumentes bereitstellen, werden auch als asymmetrische Systeme bezeichnet und bestehen laut Definition aus mindestens drei aufeinander
aufbauenden Algorithmen.
•
•
•
Erzeugung der Schlüssel (Generate)
Unterschreiben des Dokumentes (Sign)
Überprüfung des Dokumentes (Verify)
Der erste Generate-Algorithmus erzeugt einen privaten und einen öffentlichen Schlüssel. Es ist darauf zu achten, dass der private Schlüssel nicht aus dem öffentlichen
Schlüssel erzeugt werden kann.
Aus dem Dokument und dem öffentlichen Schlüssel, wird mit dem Sign-Algorithmus
eine digitale Unterschrift erzeugt und diese der Nachricht angehängt.
Der Empfänger des Dokumentes benötigt nun den bereitgestellten öffentlichen Schlüssel um die Gültigkeit mit dem Verify-Algorithmus festzustellen.
Mathematisch ergibt sich folgende Formulierung: Alice besitzt einen öffentlichen
Schlüssel
und einen geheimen Schlüssel * mit welchem sie das Dokument ) signie-
ren will. Hierzu wendet sie zum Unterschreiben die Funktion (), *)an und erzeugt so
die digitale Signatur :.
68
: = (), *)
Der Empfänger Bob verwendet nun zur Überprüfung der digitalen Unterschrift die
Funktion ]( , :) und berechnet
)^ = ]( , :)
Wenn nun )‘ = ) entspricht, dann ist die Unterschrift gültig ([Schmeh 2013], S. 202).
A.1.1
DSA
Der Digital Signature Algorithm (DSA) ist ein asymmetrisches Verfahren zur Erzeugung und zur Verifikation von digitalen Signaturen. Der DSA wurde 1991 von der National Security Agency (NSA) veröffentlicht und von dem NIST18 im Jahr 1994 standardisiert. DSA ist eine Variante des im Jahr 1985 von Taher ElGamal entwickelten
ElGamal-Verfahren, das auf einer zyklischen Gruppe basiert. Um eine DSA-Signatur zu
erzeugen, wird ein Schlüsselpaar benötigt. Hierzu wählt möglichst große Primzahl
Aund eine PrimzahlZ, die p-1 teilt. Nun wählt man einen Generator , ein Element der
Gruppentheorie. Für eine Gruppe ((A,⋅) gelten folgende Voraussetzungen ([Schmeh
2013], S. 182):
•
•
•
Es können zwei beliebige Elemente der Gruppe über eine mathematische Funktion miteinander verknüpft werden und das Ergebnis ist wiederrum ein Element der Gruppe (Abgeschlossenheit).
Es gibt ein neutrales Element der Gruppe, welches verknüpft mit einem weiteren Element
der Gruppe als Ergebnis dieses weitere Element erhält.
In jeder Gruppe gibt es ein inverses (entgegengesetztes) Element.
Als Untergruppe einer solchen Gruppe bezeichnet man eine Teilmenge der Gruppe, die
zusammen mit der gleichen Verknüpfungsfunktion und dem gleichen neutralen Element
eine neue abgeschlossene Gruppe bildet.
Bei dem angewendeten Verfahren ist
ein Generator der Gruppe und die Verknüp-
fungsfunktion ist eine Modulo-Multiplikation)% .
` ,
,
,
,…,
Ab
()% A)c
Der private Schlüssel * ergibt sich aus dem Generator
menten und einer beliebigen Zahl * < d
der Untergruppe mit Z Ele-
Einen öffentlichen Schlüssel erzeugt man nun über die Funktion
*
18
()% A)
NIST steht für National Institute of Standards and Technology
69
Für den Signatur-Algorithmus benötigt man nun für jede digitale Unterschrift eine Zufallszahl ; < dund berechnet daraus die Zahl
=(
;
()% A))()% Z)
Zusammen mit dem zu unterschreibenen Dokument m ergibt sich hieraus eine Gleichung mit einer unbekannten Variable :
) = ; ⋅ :– * ⋅ ()% Z)
: ist von den bekannten Zahlen *, ;, ), , und
anhängig und kann durch algebraische
Umformung berechnet werden. Die digitale Signatur von ) ergibt sich aus den beiden
Zahlen
und :.
Zur Verifikation wird nun der öffentliche Schlüssel
aufgestellt.
)
=
:
/
*
*
benötigt und folgende Gleichung
⋅ ()% A)
Die Signatur ist echt, wenn die Gleichung stimmt. Das DSA-Verfahren funktioniert mit
unterschiedlichen Bitlängen. Im DSS19 dem vom NIST festgelegten Standard hat A eine
Länge von 512, 1024, 2048, 3078, 7680 und 15360 Bit. Die Länge der zweiten Primzahl
Zmuss 140, 224, 256, 384 oder 512 betragen [FIPS 2009].
A.1.2
Erweiterung des DSA auf elliptische Kurven
In den vergangenen Jahren stieg die Rechenleistung der eingesetzten Maschinen stetig
an, und diese Entwicklung wird sich in den nächsten Jahren weiter fortsetzen. Auch
hardwaretechnische Grenzen, wie beispielsweise die Anzahl der möglichen Schaltungen
pro Prozessor spielen hierbei keine Rolle mehr, da Rechenleistung ohne großen Aufwand gebündelt werden kann. Es ist möglich, gebündelte Rechenleistung, wie beispielsweise Amazon Elastic Compute Cloud20 (Amazon EC2), auf Minutenbasis zu erschwinglichen Preisen zu mieten. Auch fertige Lösungen, die ich in dieser Arbeit nicht
weiter benenne, sind leicht für jedermann zu nutzen und stellen ganze Wörterbücher
und fertige Entschlüsselungsalgorithmen zur Verfügung. Diese Entwicklung erfordern
immer sicherere Verschlüsslungen und somit auch Längere Schlüssel. Asymmetrische
Verfahren benötigen sehr viel Rechenleistung und die Erzeugung ausreichend sicherer
Schlüssel ist vor allem auf kleineren Geräten wie einem Smartphone nicht mehr realisierbar [Krieger 2001].
19
20
DSS steht für Digital Signature Standard
Cloud Computing ist die nutzungsabhängige Bereitstellung von IT-Resourcen
70
Ein Ansatz diese Problematik zu lösen, sind Kryptografische-Systeme auf Basis von
elliptischen Kurven, kurz ECC21. Besonderes Merkmal von ECC-Verfahren ist es, das
nicht direkt mit Zahlen sondern mit Objekten, in diesem Fall Punkten auf der elliptischen Kurve gerechnet wird. Hierbei ist es nicht notwendig neue Algorithmen zu entwickeln, sondern es werden bereits bekannte Verfahren auf Basis diskreter Logarithmen,
die der im Kapitel A.1.1 beschriebene DSA, angewandt.
Eine elliptische Kurve E wird durch eine Weierstraß-Gleichung definiert.
Q:; = * + * + M
Elliptische Kurven können über unterschiedliche Körper, wie komplexe oder rationale
Zahlen, betrachtet werden. Ein Körper ist hierbei eine Menge von Zahlen auf die zwei
Verknüpfungen, der Addition und der Multiplikation, definiert sind. Ein endlicher Körper mit dem sich ECC-Verfahren am besten realisieren lassen, sind die Galois-Felder.
T = 8U(A)
In dieser Gleichung ist p eine Primzahl und alle Elemente von 8U(A) sind die Restklassen )%
%A.
kkkkkkk
8U(A) = `i, i, i, i, . . . , A
− c
Fügt man einer elliptischen Kurve einen Punkt
hinzu, der in der Unendlichen liegt,
kann man folgende Gleichung aufstellen.
; +
*; +
; = * +
* +
*+
Mit dieser Gleichung lässt sich die besondere und interessante Eigenschaft von elliptischen Kurven beweisen, die besagt das eine Gerade, die eine solche Kurve schneidet
immer genau drei Schnittpunkte mit dieser hat (vergleiche Abbildung 12). Hierbei treten die folgenden drei Fälle auf:
21
ECC steht für Elliptic Curve Cryptography
71
1. Wenn die Gerade parallel zur y-Achse verlauft, dann ist der dritte Schnittpunkt der Punkt .
2. Berührt die Gerade die Kurve an einem Punkt,
Punkt, dann wird der Berührungspunkt dieser Tangente als doppelter Schnittpunkt gezählt.
3. Alle anderen beliebig auf der Fläche definierten Geraden haben immer drei Schnittpunkte.
Schnittpunkte
Abbildung 15:: Addition von Punkten auf einer elliptischen Kurve
Auf Basis dieser Eigenschaften, lässt sich nun eine
ein Gruppe Q(T)definieren.
definieren. Elemente
dieser Gruppe sind alle Punkte auf der elliptischen Kurve und der Punkt 0 in der UnbeUnb
kannten. Für die Addition zweier Punkte auf der Kurve legt man eine Gerade durch sie.
Gemäß oben genannten Fällen, muss nun ein dritter Schnittpunkt auf der Kurve existieexisti
ren. Wird dieser Punkt an der x-Achse gespiegelt, dann erhält man das Resultat der Addition (vergleiche Abbildung
Abbildun 12). Hierbei ist
gilt für alle Punkte P der elliptischen Kurve:
Kurve
das
as neutrale Element der Gruppe und es
R + = + R = R
Die
ie Spiegelung von Punkt 0 ergibt somit 0. Das inverse Element der Gruppe erhält man
indem man einem Punkt auf der Kurve eine Gerade anlegt, die parallel
parallel zu y-Achse
y
verläuft. Wenn diese Gerade die Kurve berührt, dann ist dieser Berührungspunkt sein ini
72
verses Element. Ist die Gerade keine Tangente, dann ist der weitere Schnittpunkt das
inverse Element.
Kryptografische Systeme verwenden elliptische Kurven der Form Q(8U(A)) und
Q(8U(
)). Diese werden im Folgenden als Q(8U())) bezeichnet.
Die mehrfache Anwendung der Addition von Punkten aus Q(8U())) kann als Potenzfunktion bezeichnet werden und die Umkehrung dieser Rechenart als Logarithmus.
Es gibt effektive Algorithmen für die Berechnung von Potenzfunktionen, für die Berechnung von diskreten Logarithmen jedoch nicht. Für die Erweiterung eines asymmetrischen Verfahrens wie DSA, das auf einem diskreten Logarithmus basiert, werden statt
der Rechenoperationen in 8U(A) nun Rechenoperationen in Q(8U())) angewandt.
Zur weiteren Berechnung müssen sich die Teilnehmer statt auf einen Modulus auf eine
bestimmte elliptische Kurve aus dem Körper 8U()) und daraus aufgebauter Gruppe
Q(8U())) verständigen.
Da sich die Addition zweier Punkte aus Q(8U())) aus mehreren Rechenoperationen
von 8U()) zusammensetzen ist die Exponentiationüber 8U()) weniger aufwendiger
ist als über Q(8U()))
Da für die Berechnung des diskreten Logarithmus über 8U(A) effektivere Algorithmen
existieren als bei elliptischen Kurven, sind bei gleicher Sicherheit kürzere Schlüssellängen beim Einsatz von elliptischen Kurven möglich. Dies hat zur Folge, dass die benötigte Rechenleistung zur Erzeugung der notwendigen Schlüssel um Faktor zehn eingespart
werden kann ([Schmeh 2013], S. 215).
Bei dem ECDSA-Verfahren ist zunächst das Problem zu lösen, das die Zahl
;
ein
Punkt auf der elliptischen Kurve ist, aber auch im Exponenten steht. An dieser Stelle
muss jedoch eine natürliche Zahl stehen. Hier wird nun in der Regel eine natürliche
Zahl aus
A.2
;
abgeleitet indem man die x-Koordinate des Punktes
;
verwendet.
Hashfunktionen
Das Unterschreiben kompletter Nachrichten oder eines kompletten Blockes innerhalb
der Blockchain mit einer digitalen Signatur würde sowohl beim Absender als auch beim
Empfänger zu viel Zeit in Anspruch nehmen und zudem wäre die erstellte Signatur
mindestens genau so lang wie die Nachricht oder Block selber. Um dies zu vermeiden,
wird aus der Nachricht oder bei einem Block, wie im Kapitel 2.2.5.2 beschrieben, dem
Blockheader eine Prüfsumme gebildet, auf die das Signaturverfahren angewandt werden
kann. Diese Prüfsumme wird als Hashwert bezeichnet.
Es gibt unterschiedliche Funktionen, um einen Hashwert zu erzeugen. Grundsätzlich
wird eine beliebig lange Bitfolge m (z.B. der Nachricht) über eine Hashfunktion H, eine
73
Bitfolge h (dem Hashwert) mit begrenzter Länge abgebildet. Die Bitfolge mit beliebiger
Menge wird auch als Urbild bezeichnet. Mathematisch lässt sich dies wie folgt darstellen:
= "())
Da Hashwerte nur eine begrenzte Länge haben, ist es möglich, dass aus zwei unterschiedlichen Urbildern die gleichen Hashwerte erzeugt werden. Wenn dieser Fall eintritt
spricht man von einer Kollision.
Als stark kollisionssicher werden kryptografische Hashfunktionen bezeichnet, bei denen es nach aktuellem Kenntnisstand nicht möglich ist, über zwei beliebige Urbilder
eine Kollision zu erzeugen. Hierbei spielen der Inhalt und die Länge keine Rolle.
Wenn es nicht möglich ist ein zweites Urbild zu finden, wenn ein Hashwert oder ein
Urbild vorgegeben ist, dann bezeichnet man die Hashfunktion als schwach kollisionssicher ([Schmeh 2013], S. 228).
Bei Bitcoin werden die stark kollisionssicheren kryptografischen Hashfunktionen SHA256 und RIPEMD-160 eingesetzt.
A.2.1
SHA-256
SHA-256 ist eine Weiterentwicklung der vom der NSA erstellten SHA Hashfunktion.
Die Abkürzung SHA steht für Secure Hash Algorithm (deutsch: sicherer HashAlgorithmus) und ist eine von der US-amerikanischen Standardisierungsbehörde NIST
in Auftrag gegebene kryptografische Hashfunktion, die lange Zeit zu den wichtigsten
Funktionen gehörte.
Entwickelt von der NSA wurde SHA-1 zusammen mit DSA (siehe Kapitel A.1.1) im
Jahr 1991 der Öffentlichkeit vorgestellt. SHA-1 liefert einen Hashwert der Länge 160
Bit und basiert auf MD4 (Message Digest 4), einer von Ronald L. Riverst [Riverst
1992] entwickelten Hashfunktion, die Hashwerte mit einer Länge von 128 Bit erzeugen.
Wie bereits in Kapitel A.1.2 beschrieben, werden aufgrund höherer Rechenleistung und
Cloud Computing die Schlüssellängen von MD4 (128 Bit) und SHA-1 (160 Bit) den
aktuellen Sicherheitsanforderungen nicht mehr gerecht. Im Jahr 2004 gelang es zudem
der chinesischen Kryptografin Xiaoyun Wan und ihren beiden Kollegen Andrew C. Yao
und Frances Yao eine Methode zur Generierung einer Kollision zu entwickeln die lediglich
Funktionsaufrufe benötigt [Wan/Yao/Yao 2004].
Angriffe auf SHA-256 (mit einer Hashwertlänge von 256 Bit) sind wesentlich aufwendiger. SHA-256 wurde bereits im Jahr 2000 vom NIST veröffentlich und verarbeitet wie
auch SHA-1 das Urbild mit Blöcken in einer Länge von 512 Bit. Da das erzeugte Urbild
meist nicht durch 512 Bit teilbar ist, muss zunächst der letzte Block mit Null-Bits aufge74
füllt werden. Dieses Verfahren wird als Padding bezeichnet und geschieht folgendermaßen:
1. Wenn weniger als 64 Bit aufzufüllen sind, dann wird ein weiterer Block an das Urbild angehängt.
2. Das Urbild wird beginnend mit einer 1 und darauffolgenden Null-Bits aufgefüllt, bis im
letzten Block genau 64 Bit übrig bleiben.
3. Die letzten 64 Bit werden nun mit der Bit-Länge der ursprünglichen Nachricht beschrieben.
Wenn das Urbild größer als
ist, dann werden nur die 64 niederwertigsten Bits verwendet. Um nun einen SHA-256 Hashwert zu berechnen, benötigt man zunächst 8 Kettenvariablen mit einer Länge von 32-Bit ([NIST 2012], S. 15):
# = Q = D
',
= MM '
'l, U = DM
N , C= NN , 8 = lN
l ' , Y = D M, " = M
ll
D
Auf einen 512-Bit Block des Urbilds wird nun eine Kompressionsfunktion angewendet, die den aktuellen Inhalt der Kettenvariablen entgegennimmt und einen neuen Wert
zurückliefert.
Die Kompressionsfunktion wird zunächst auf das Urbild mn und dann auf alle folgenden
Urbilder angewendet
Die SHA-256-Kompressionsfunktion läuft in 4 Runden mit jeweils 16 Teilrunden ab.
Hierbei hat jede Runde eine eigene Funktion
und für jede Teilrunde wird eine andere
Konstante T [NIST 2012] und ein 32 Bit großer Teil des Urbildes verwendet. Errechnet
man nun die benötigte Länge pro Urbild, dann ergibt sich aus eine benötigte Länge von
2048 Bit.
⋅
⋅
=
N
Da jedes Urbild nur 512 Bit lang ist, gibt es für jedes Urbild auch nur genau 16 32-BitTeilblöcke
,…,
Der restliche Block wird über eine Expansion um die fehlenden
32-Bit-Blöcke en Bit
,…,
erweitert.
Für die Formeln wird folgende Notation verwendet:
⊕ p3.>53656Sq\(exklusivesoder)
∧ p3.>53656#VY
∨ p3.>53656q\
¬p3.>53656€=471545+.
+4=J2‚ƒ ,JJ3.3=+
\q \ „=.0.3=++0-ℎ?5-ℎ.6/4+p3.6
"\
Verschiebung nach rechts um n p3.6
75
Die einzelnen Funktionen
der Runden lassen sich über zwei boolesche Formeln und
zwei S-Boxen wie folgt beschreiben []:
22
…(#, , [) = (# ∧ ) ∨ (# ∧ [) ∨ ( ∧ [)
[ (Q, U, 8) = (Q ∧ U) ∨ (¬Q ∧ 8)
∑ (‡) = ˆ‰Šˆ (‡) ⊕ ˆ‰Šˆ (‡) ⊕ ˆ‰Šˆ (‡)
∑ (‡) = ˆ‰Šˆ (‡) ⊕ ˆ‰Šˆ (‡) ⊕ ˆ‰Šˆ (‡)
Die Expansion der einzelnen Urbilder funktioniert nach folgender Formel:
Q=
‹ü?3•=+0p3615
Q = • (Q b ) + Q b' + • (Q b ) + Q b
‹ü?3•=+16p3664
Bei den Funktionen • (*)und • (*)handelt es sich erneut um S-Boxen mit Rotationen nach rechts (ROTR) und Verschiebungen nach rechts (SHR)
• (‡) = ˆ‰Šˆ' (‡) ⊕ ˆ‰Šˆ N (‡) ⊕ ’“ˆ (‡)
• (‡) = ˆ‰Šˆ ' (‡) ⊕ ˆ‰Šˆ D (‡) ⊕ ’“ˆ (‡)
Der Inhalt der Kettenvariablen ändert sich bei jedem Durchlauf der Kompressionsfunktion. Der Hashwert entsteht durch Aneinanderhängen der letzten 8 erzeugten Kettenvariablen.
A.2.2
RIPEMD-160
Wie im Kapitel 2.2.4.2 beschrieben, wird im Bitcoin-System die Hashfunktion
RIPEMD-160 zur Erzeugung von Adressen verwendet. Die 1996 von Hans Dobbertin,
Antoon Bosselaers und Bart Preneel in Europa entwickelte Hashfunktion ist eine Weiterentwicklung von RIPEMD23 [Dobbertin/Bosselaers/Preneel 1996].
Wie SHA-256 als Weitentwicklung von SHA-1, hat auch RIPEMD-160 als Weiterentwicklung von RIPEMD seinen Ursprung in der MD4 Hashfunktion, weshalb sich diese
Funktionen in der Funktionsweise sehr ähneln. RIPEMD-160 verwendet 5 Kettenvariablen und wie SHA-256 512-Bit-Blöcke, die nach der gleichen Methode aufgefüllt werden. Für die Kompressionsfunktion nutzt RIPEMD-160 zwei voneinander unabhängi22
Eine S-Box (englisch: substitution Box) erstsetzt eine m-stellige Binärzahl durch eine n-stellige Binärzahl um eine Konfusion zu erzeugen.
23
RIPEMD steht für RACE Integrity Primitives Evaluation Message Digest
76
gen Ablaufsträngen die am Ende miteinander verknüpft werden. Jeder Strang verarbeitet 80 32-Bit-Blöcke, die über eine Expansion aufgefüllt werden müssen. Hierbei wird
eine Erweiterungstabelle verwendet und zur Erweiterung die ersten 15 Urbildblöcke in
einer festgelegten Reigenfolge eingesetzt. Jeder Ablaufstrang durchläuft 5 Runden, die
aus 16 Teilrunden bestehen. Für jede Runde wird eine andere Funktion
Teilrunde eine neue Konstante T verwendet.
RIPEMD-160 erzeugt einen 160 Bit Hashwert.
77
und für jede
B
Alternative Kryptowährungen
Alle in dieser Arbeit betrachteten alternativen Kryptowährungen basieren auf der gleichen technischen Grundlage, sind jedoch aus unterschiedlichen Ideen entstanden und
verfolgen meist einen guten und sinnvollen Einsatzweck. Aufgrund der Tatsache, dass
alle Quelltexte zur freien Verfügung stehen kann theoretisch jeder Anwender mit geringem technischem Verständnis des Gesamtsystems eine eigene Währung erschaffen und
anderen zur Verfügung stellen. Hierdurch wird eine große Anzahl unterschiedlicher
Währungssysteme erschaffen, die oft nur auf Profit und Anerkennung innerhalb der
eigenen Interessengemeinschaft entstehen und häufig wieder von der Bildfläche verschwinden. Im Folgenden werde ich einige sinnvolle Projekte vorstellen und abschließend einige Kryptowährungen mit größerer Marktkapitalisierung auflisten.
B.1
Litecoin24
Bei Litecoin handelt es sich um die ersten Klon zu Bitcoin, der direkt aus dem Quellcode abgeleitet wurde. Litecoin nutzt statt der SHA-256 Hashfunktion, eine Passwortbasierte Schlüsselableitungsfunktion mit dem Namen Scrypt. Diese wurde von Colin
Percival für die Firma Tarsnap entwickelt und 2009 vorgestellt [Percival 2009]. Da
Scrypt eine höhere Speicherkapazität als SHA-256 benötigt, war das Ziel der Entwickler, das Minen mit Hilfe von Hardware-Chips (ASICS) zu erschweren. Die Blockerzeugung wurde auf 2,5 Minuten festgelegt, wodurch das Netzwerk viermal so schnell arbeitet wie Bitcoin.
B.2
Peercoin25
Die Kryptowährung Peercoin wurde 2009 von dem Entwickler Sunny-King vorgestellt
und benutzt zur Verifizierung neuer Blöcke ebenfalls die SHA-256 Hashfunktion. Neben des in Kapitel 2.2.5 beschriebenen Verfahrens Blöcke durch einen Arbeitsbeweis
(Proof-of-Work) zu erzeugen, wurde von King ein Besitzschaftsprinzip (Proof-of-Stake)
eingeführt. Die Belohnung des Miners wird auf Basis der Menge, der im Besitz der
Miners befindlichen Coins berechnet. Als weiterer Parameter wird zudem das Alter dieser Coins berücksichtigt, also der Zeit, die bestimmte Peercoin im Besitz des Miners
sind [King/Nadal 2012].
24
25
http://www.litecoin.org
http://www.peercoin.net
78
B.3
DASH26
Das Problem der ASICS und der fehlenden Anonymität des Bitcoins-System versuchen
die Entwickler von DASH zu umgehen. Das erst am 25 März 2016 in DASH umbenannte Darkcoin-System nutzt für den Arbeitsbeweis statt des SHA-256 die X11 Hashfunktion. Transaktionen werden über das eingeführte Darksend-Verfahren im Client des
gemischt um so die Nachverfolgbarkeit zu erschweren. Zusätzlich werden die Transaktionen über Masternodes geleitet. Über diese speziellen Server, werden mehrere Transaktionen vermischt bevor diese in die Blockchain gespeichert werden. Masternodes
können von jedem Teilnehmer installiert werden, der 1000 DASH an einer Adresse hinterlegt. Die gemeldeten Masternodes werden über das Netzwerk verifiziert. Wie bei
allen Kryptowährungen ist der DASH-Quellcode verfügbar und kann auf der GithubWebsite27 geladen werden.
B.4
Weitere Kryptowährungen
Es existieren hunderte Kryptowährungen, die zum größten Teil auf dem Quellcode von
Bitcoin aufbauen. Die Entwickler versuchen Schwächen zu umgehen und eigene Ideen
in das System einfließen zu lassen. Einige Kryptowährungen entstehen nur in der Hoffnung eine kurzeitige Akzeptanz zu erzeugen und somit einen gewissen Wert zu erzielen.
Da der Quellcode immer offengelegt wird, um eine ausreichende Vertrauensbasis zu
schaffen, entstehen immer mehr Kryptowährungen mit neuen Möglichkeiten und Ideen.
26
27
http://www.dashpay.io
https://github.com/dashpay/dash
79
Eidesstattliche Erklärung
Hiermit erkläre ich, dass ich diese Diplomarbeit selbstständig ohne Hilfe Dritter und
ohne Verwendung anderer als der angegebenen Quellen und Hilfsmittel verfasst habe.
Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder unveröffentlichten
Quellen entnommen wurden, sind als solche kenntlich gemacht.
Diese Arbeit ist bisher in gleicher Form oder auszugsweise keiner anderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht worden.
Ich bin mir dessen bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird.
______________________________________________________________________
Ort, Datum, Unterschrift
80