 Zum einfacheren Verständnis sollte zuerst das Kapitel "Definition Bitcoin" gelesen werden Der Begriff Colored Coins wird unterschiedlich gebraucht. Hier wird folgende Definition verwendet: Colored Coins werden über eine bestehende Blockchain emittiert, transferiert und gehandelt. Es wird nur auf Colored Coins eingegangen, die auf der Bitcoin Blockchain aufbauen. Colored Coins verkörpern selbst Vermögenswerte (Aktien, Anleihen, Kryptowährungen), Gutscheine (Tickets, Flugmeilen) oder sind Verbriefungen von Eigentumsrechten (Gold, USD, EUR) oder Nutzungsrechte (Auto, Mietwohnung). Verbriefungen sind das Versprechen, bei vorweisen, den Colored Coin in den Basiswert umzutauschen. Es besteht ein Gegenparteirisiko, da darauf vertraut wird, dass die Pfandstelle auch jederzeit fähig ist, diesen Austausch vorzunehmen. Für einige Blockchain Hardliner sind Verbriefungen daher verpönt. Nutzungsrechte könnten Wohnpunkte wie bei Hapimag sein, womit Ferienwohnungen gemietet werden können. Beispiele für Colored Coins als Vermögenswerte (in Klammer Software):
Beispiel für einen verbrieften Colored Coin:
Colored Coin Softwareprogramme: Colored Coin Wallets (in Klammer Software):
Was macht Colored Coins attraktiv? Colored Coins können auf einer bereits etablierten Blockchain aufgebaut und gesichert werden, ohne dass für die beteiligten Firmen dadurch grosse Zusatzkosten entstehen. Der Übertrag von Eigentumsrechten ist kostengünstig, transparent und schnell. Alle Protokolle beinhalten zwei Haupttransaktionen:
Leider konnten sich die Colored Coins Anbieter bisher auf keinen Standard einigen. Früher war www.ColoredCoins.org die Internetseite für einen gemeinsamen Auftritt. Seit 2014 wird diese jedoch von Colu gesponsort und ist damit nicht mehr unabhängig. Es ist auch noch nicht erkennbar, welches Protokoll sich schliesslich durchsetzen wird. Die Dokumentation ist oft ziemlich wirr. Am einfachsten ist Colored Coins zu verstehen, wenn die historische Entwicklung verfolgt wird. Das Prinzip von Colored Coins ist in der Grafik dargestellt:  Colored Coins (rot) werden über die Bitcoins gestülpt (gelb, weiss). Hier werden zum Beispiel 10 Counterparty Token (XCP) von Bitcoin Adresse A zu B überwiesen. Bitcoin Wallets und Miner sehen aber nur folgendes:  Für das Bitcoin Ökosystem wurden 0 Bitcoins transferiert und dafür 0.0001 Gebühr bezahlt. Colored Coin Wallets halten hingegen in ihren Datenbanken auch die XCP Daten fest:  Hier ein Einblick in das Colored Coins Wallet von Counterparty:  Für jede neue XCP Adresse muss eine entsprechende Bitcoin Adresse generiert werden. Auch sollte jederzeit ein kleiner Betrag Bitcoins vorhanden sein, damit überhaupt Transaktionen von XCP durchgeführt werden können. Ziel ist aber, die Colored Coin Transaktion auch auf der dezentralen Bitcoin Blockchain einzubauen, um nicht einer zentralen Stelle, hier Counterparty, vertrauen zu müssen. Die verschiedenen Softwareprogramme von Colored Coins Anbietern unterscheiden sich vor allem darin, wo diese Daten in der Bitcoin Blockchain "versteckt" werden. Sehen wir uns in der folgenden Grafik wieder die Bitcoin Transaktion an, die hier besprochen wurde. Wo könnten die Colored Coin Daten eingebaut werden, damit auf der Bitcoin Blockchain keine Fehlermeldung provoziert wird?  Das Sequenzfeld («sequence») Die Ausführung von Bitcoin Transaktionen kann über die Funktion "locktime" auf einen späteren Zeitpunkt datiert werden (siehe Grafik oben). Die Transaktion befindet sich dann zwar im Mempool, kann aber bis zum Ausführungszeitpunkt noch abgeändert werden. Dazu muss der gleiche Input mit einer erhöhten Sequenznummer nochmals überwiesen werden. Dies ist gebührenfrei. Damit befinden sich zwei Transaktionen mit dem gleichen Input im Mempool. Ziel wäre gewesen, dass automatisch die angepasste Transaktion mit der höheren Sequenznummer von den Minern bevorzugt würde. Komischerweise erzwang dies Bitcoin Core jedoch nicht über eine zusätzliche Regel zur Verifizierung einer Transaktion. Miner sind aber Gewinnmaximierer. Wer in der Lotterie gewinnt, darf die Gebühren für sich einsacken. Logischerweise wurde die angepasste, gebührenfreie Transaktion ignoriert. De facto konnte der Nutzer damit eine vorgesehene Anpassung nicht durchführen, weshalb die Wallet Betreiber diese Funktion sofort stoppten. "Locktime" erhielt nun immer den Wert 0, womit das Sequenzfeld vom Protokoll links liegengelassen wurde. Darauf hat EPOBC im Jahr 2012 aufgebaut. Da stand ein 32 Bits Feld, das keine Bedeutung hatte, weshalb es zur Speicherung der Colored Coin Daten verwendet werden konnte. Im Sequenzfeld wurden die Emission und der Transfer von Colored Coins kodiert. Erstaunlicherweise kam Bitcoin erst kürzlich auf die Idee, dass einfach die Gebühr auf der angepassten Transaktion gegenüber der ursprünglichen erhöht werden muss und schon wird die Funktion "locktime" wieder vom Ökosystem akzeptiert. Das Sequenzfeld dürfte schon bald ein Revival in den Wallets erhalten und EPOBC den Gnadenstoss versetzen (BIP 0068, BIP 0125). Ein weiterer Nachteil von EPOBC ist, dass Colored Coins jeweils der kleinsten Bitcoin Einheit, also 1 Satoshi, entsprechen. Will man eine Emission von 1 Mio. Colored Coins durchführen, heisst dies, dass mindestens 55 Bitcoins transferiert werden müssen, was heute 33’000 USD entspricht! Verschleierung von Bitcoin Adressen Ende Juli 2013 führte Mastercoin (heute OMNI) ein ICO über die Blockchain durch. Dabei wurde umgerechnet 500’000 USD Kapital aufgenommen. Im Januar 2014 folgte Counterparty mit 1.8 Mio. USD. Ziel: Colored Coin Daten auf der Bitcoin Blockchain zu speichern. Für einfache Übertragungen wurden gefälschte, verschleierte Bitcoin Adressen generiert, in denen die Daten als Code eingebaut wurden. Das Prinzip ist in der Grafik dargestellt:  Es werden jeweils 0 Bitcoins von der Bitcoin Adresse A nach B und C überwiesen. Bitcoin Adresse C ist eine gefälschte Adresse. Sie wird aus den Colored Coin Daten künstlich kreiert, damit diese vom Bitcoin Protokoll akzeptiert werden. Bedingung ist nämlich, dass die Bitcoin Adresse einem Punkt auf der elliptischen Kurve entspricht. Anhand eines Beispiels soll gezeigt werden, wie die Colored Coin Daten in die gewünschte Form gebracht werden: Transaktion: "Übertrage 10 XCP von Bitcoin Adresse A auf Bitcoin Adresse B". Code: 0000100002000100000000000000000000000000000000000000000000 32 Bytes 00001: Transaktions-Typ (Sende) 00002: Token ID (XCP) 00010 Betrag (10) Ein guter Ausgangspunkt für die Verschleierung ist die echte Bitcoin Adresse B, die auf der elliptischen Kurve liegt. Aus dieser muss zuerst ein gefälschter Public Key geformt werden. Bitcoin Adresse: 1CdighsfdfRcj4ytQSskZgQXbUEamuMUNF Darauf wird eine erste Hashfunktion (SHA 256) angewendet: 1D9A3DE5C2E22BF89A1E41E6FEDAB54582F8A0C3AE14394A59366293DD130C Dies sieht schon mal gut aus; gleicht einem Public Key. Jetzt wird der Colored Coin Code über eine zweite Hashfunktion (XORing) eingebaut und es resultiert: 1C9A3DE5C2E22BF89B1E41E6FED84FB502F8A0C3AE14394A59366293DD130C Dies weicht nur geringfügig vom ersten Public Key ab, weil im Colored Coin Code viele Nullen enthalten sind. Vorne wird das Präfix 02 angehängt, damit das Bitcoin Protokoll annimmt, dass es sich um einen komprimierten Public Key handelt. Hinten wird ein zweistelliges Suffix angehängt. 021C9A3DE5C2E22BF89B1E41E6FED84FB502F8A0C3AE14394A59366293DD130C03 Mit dem Suffix wird nun solange herumgepröbelt, bis der gefälschte Public Key mit einem Punkt auf der elliptischen Kurve übereinstimmt. Wohlgemerkt: Der Punkt wird niemals dem Private Key entsprechen. Diesen kennt nicht einmal das Colored Coin Wallet! Damit wird das Bitcoin Ökosystem überlistet. Über eine Bitcoin Transaktion können mehrere Colored Coins transferiert werden. Damit diese sowohl auf der Input- wie auch auf der Output Seite in der richtigen Reihenfolge stehen, wird vor dem Code noch ein Index aus 1 Byte eingebaut. 0100001000020001000000000000000000000000000000000000000 Da der Index in hexadezimaler Form steht, reicht 1 Byte für 256 Zahlen (16^2 = 256). 00 darf aber nicht verwendet werden, da der Public Key sonst nicht mit einem Punkt auf der elliptischen Kurve übereinstimmen würde. Somit können maximal 255 gefälschte Bitcoin Adressen pro Transaktion kreiert werden. Dies reicht, um insgesamt 7’680 Bytes (255x30) Colored Coin Daten pro Bitcoin Transaktion zu speichern (ohne Index). Da kein Private Key mit den gefälschten Bitcoin Adressen übereinstimmt, wird der Output ewig vom Bitcoin Protokoll als UTXO behandelt. Gesendete Bitcoins wären verloren, weshalb für die Datenspeicherung null Bitcoins transferiert werden. Die zweckentfremdeten UTXO blähen die Blockchain markant auf und verstopfen den Arbeitsspeicher. Verstopfung der Blockchain und an der Nase herumgeführt zu werden, war Bitcoin Core zu viel und sie begannen zurück zu schiessen. Zuerst wurde ein minimaler Output Wert (Dust Limite) von ca. 0.00006 Bitcoins eingeführt, was momentan etwa 10 USD für die maximal 255 Überweisungen pro Transaktion ausmacht:  Zusätzliche Drohgebärden zwangen die Colored Coin Anbieter auf das MultiSig Skript zu wechseln. MultiSignatur / Kollektivunterschrift Bei diesem Skript braucht es mehrere digital Unterschriften, um Zugriff auf die Bitcoins zu erhalten. Dementsprechend werden mehrere Bitcoin Adressen im Output aufgelistet. Mehrere Bitcoin Adressen heisst mehr Speicherplatz. Da Bitcoin Core maximal 3 Adressen zulässt, wird ein 1-von-3 MultiSig verwendet. Das heisst, dass 1 Private Key aus den 3 angegebenen Bitcoin Adressen für den Zugriff genügt. 2 Adressen können nun, wie oben beschrieben, gefälscht und für Datenspeicherung verwendet werden.  Vorteil ist, dass die 0.00006 Bitcoins nicht verloren sind, sondern wieder ausgegeben werden können, da Bitcoin Adresse B echt ist und deren Private Key Zugriff auf die Bitcoins erhält. Die 0.00006 Bitcoins werden rezykliert und weniger UTXO verstopfen den Arbeitsspeicher. Da über MultiSig doppelt so viele Colored Coin Daten in einer Transaktion gespeichert werden können (2x30x255=15’300 Bytes), und dies sogar noch günstiger ist, wurde die Blockchain noch stärker aufgebläht. Anfangs 2014 hat Bitcoin Core daher ein neues Skript (OP_RETURN) extra für Datenspeicherung eingeführt. OP_RETURN Mit der Einführung dieses Operators wurde eine begrenzte Menge an Datenspeicherung pro Transaktion von Bitcoin Core geduldet. Es müssen also keine Bitcoin Adressen mehr gefälscht werden. Das Bitcoin Ökosystem erkennt, dass es sich um Datenspeicherung handelt und fügt diesen UTXO nicht mehr dem Arbeitsspeicher zu. Pro Transaktion wurden anfänglich nur 1 OP_RETURN mit maximal 40 Bytes erlaubt, womit gewisse Anbieter wie Counterparty arg unter Druck kamen. Eine hässige Diskussion entstand, wovon hier eine Kostprobe gegeben wird: Bitcoin Core "Counterparty nutzt offensichtlich eine Anwendung (MultiSig), die nicht für Datenspeicherung gedacht war. Es ist naiv, zu glauben, dass Bitcoin stillschweigend einer Nutzung zugestimmt hat, die nicht vorausgesehen werden konnte". "Die Frage lautet: Sollen wir weiterhin erlauben, dass Daten im MultiSig Skript gespeichert werden oder ist es nicht besser, dafür ein geeigneteres Skript in Form von OP_RETURN zu benutzen". "40 Bytes ist mehr als genug, um Daten mit einer Transaktion zu verknüpfen. Dies reicht für einen Hash mit 32 Bytes (SHA 256) und einen Index aus 8 Bytes". Counterparty "Die Bitcoin Software Entwickler werfen mit gefährlichen Wörtern wie "Missbrauch", "Opfer", "Parasiten" und "Trittbrettfahren" umher und treffen alleine Protokoll-Entscheidungen, welche sämtliche Teilnehmer des Ökosystems Bitcoin einbinden sollten". "Die Arroganz von Bitcoin Core ist unbeschreiblich. Counterparty erweitert den Anwendungsbereich, womit Bitcoin mit neueren Ökosystemen wie NXT, BitShares und Ethereum konkurrieren kann". Als Kompromiss wurde im Juli 2015 bei der Bitcoin Version 0.11 die maximale Menge Bytes pro OP_RETURN auf 80 Bytes erhöht und ein Grossteil des Ökosystems hat diese Version bereits umgesetzt. Auch die meisten Colored Coin Anbieter haben seither fast gänzlich auf OP_RETURN umgestellt, wie aus der folgenden Grafik ersichtlich ist:  Hier sind die grössten OP_RETURN Nutzer aufgelistet:  Colu ist mit Abstand der grösste (51.2%), gefolgt von vermutlich Counterparty (13,3%, verwendet kein Präfix), Omni Layer (10,1%) und Open Assets (6,2%). Open Assets Protokoll Stellvertretend für Colored Coin Protokolle soll hier näher auf Open Assets eingegangen werden. Dieses basiert heute vollständig auf OP_RETURN und ist relativ einfach zu implementieren. Deshalb wird es häufig angewendet. So testet die Technologiebörse NASDAQ momentan anhand des Open Assets Protokolls, ob Emission, Kotierung und Handel von Aktien in der Zukunft über die Blockchain laufen könnten. Das offizielle Open Assets Wallet heisst Coinprism. Am einfachsten ist, wenn das Protokoll an einem Beispiel erklärt wird. Colored Coins Emission (Genesis) Nehmen wir an, dass Firma X eine Emission von 1000 neuen Colored Coins durchführen möchte. Dazu wird ein kleiner Betrag von 0.001 Bitcoins von Adresse A auf B überwiesen. Dieser Betrag soll die minimal zulässige Überweisung von 0.00006 BTC und die Gebühr decken. In diesem Fall war die Gebühr 0.0001 BTC. Das Wechselgeld von 0.00084 BTC wird zurückgeschickt.  Auf das Skript (P2PKH) wird eine Hashfunktion angewendet. Der resultierende Hash entspricht der Colored Coin ID. Diese muss nicht gespeichert werden, da Colored Coins jeweils bis zur Genesis zurückverfolgt werden können (wie bei Bitcoin). Der Private Key von Bitcoin Adresse B kann später für eine Erhöhung der Colored Coin Menge verwendet werden. Soll dies ausgeschlossen werden, muss der Private Key vom Wallet zerstört werden. Bitcoin Adresse B könnte auch ein MultiSig Skript haben, womit die Menge nur durch ein Gremium (z.B. Notenbankausschuss) erhöht werden kann. Im OP_RETURN steht das Kürzel OA für Open Assets in hexadezimaler Form (0x4f 0x41). Über diesen Marker erkennt das Open Assets Protokoll sofort, dass in dieser Bitcoin Transaktion Colored Coins involviert sind. Da die 1000 über dem Marker stehen, handelt es sich um eine Emission (Transaktionen würden unter dem Marker stehen). Der Marker ist auch als M auf einem Bitcoin bzw. UTXO ersichtlich. Mit gerade mal 20 Cents wurden neue Colored Coins emittiert. Auch eine Emission von 1 Mio. hätte nicht mehr gekostet. Colored Coins transferieren Nehmen wir nun an, dass die Firma X Geld über ein Initial Coin Offering (ICO) aufnehmen möchte. Investoren können Bitcoins auf Adresse B einzahlen und erhalten dafür proportional Colored Coins. Da Bitcoins heute noch selten als Zahlungsmittel akzeptiert wird, kann die Firma die Bitcoins später wieder in EUR oder USD umtauschen, um ihre Projekte voranzutreiben. ICO In der folgenden Darstellung werden Gebühren vernachlässigt:  Distribution Da 1000 Bitcoins aufgenommen wurden, erhalten die Investoren 1 Colored Coin pro einbezahltem Bitcoin.  Im OP_RETURN befinden sich sämtliche Colored Coins unterhalb des Markers. Das heisst, dass hier keine Colored Coin Emission involviert ist. Über einen normalen Bitcoin Transfer von 0.00006 Bitcoins an Adresse A, die auch der Firma X gehört und oben Ausgangspunkt war, wird der Marker eingebaut. Nochmals zur Erinnerung: Alles rot markierte wird über OP_RETURN definiert und ist hier nur zur Illustration eingefärbt. Ein normales Bitcoin Wallet kann den OP_RETURN Text nicht interpretieren und sieht nur folgendes:  Darum dürfen Colored Coins nie an ein normales Bitcoin Wallet gesendet werden; sie wären verloren. Open Assets verhindert dies, indem die Bitcoin Adressen in ein spezielles Format umgewandelt werden, das mit dem Buchstaben a anfängt (Bitcoin Adressen beginnen mit der Zahl 1). Jetzt soll noch eine komplexe Transaktion dargestellt werden:  Über dem Marker steht 100. Grün ist also ein neu emittierter Colored Coin. Unter dem Marker stehen die Transaktionen vom roten Colored Coin und das Wechselgeld. Metadaten Da das Open Assets Protokoll simpel ist, bleiben im OP_RETURN ein paar Bytes übrig, die für Metadaten benutzt werden können. Wie dies verwendet wird, bleibt dem Wallet Anbieter überlassen. Coinprism verwendet den Speicherplatz, um einen Link zu einer Webseite herzustellen, wo sich die genaue Definition der Colored Coins oder ein Vertrag befinden. Hier noch ein Wallet Auszug von Lykke, die eine dezentrale Börse aufbauen und deren Colored Coin ICO zurzeit gerade läuft:  Abschliessend noch eine Anleitung, wie über Coinprism konkret Colored Coins generiert werden können. Ethereum Mit Ethereum wird von Grund auf eine programmierbare Blockchain aufgebaut. Alles soll viel einfacher als mit Colored Coins werden. Jedes Ethereum-Wallet kann Token erkennen und überweisen. Ein Wallet fragt eine Adresse, ob ihr neben Ether auch noch Token zugeordnet sind und zeigt sie allenfalls automatisch an. Auch können Verträge bzw. Programme über eine Adresse gespeichert und dann aufgerufen werden. Colored Coin Token kann man sich vorstellen, als würde man eine 5 EUR Note nehmen und darauf schreiben: “Diese Note entspricht auch einer Hapimag Aktie”. Bei Ethereum könnte über eine Vertragsadresse ein Programm gestartet werden, das Hapimag Aktien emittiert und in einer anderen Ethereum Adresse ein dezentral gespeichertes Aktienregister führt (anstatt auf der Colored Coin Datenbank). In einer weiteren Adresse würde dann ein Programm gespeichert, mit der Anleitung, wie das Register bei Übertragungen von Aktien zu aktualisieren sei. Counterparty reagiert jedoch bereits und versucht eine geklonte Version von Ethereum auf der eigenen Colored Coin Plattform anzubieten. Quellen:
https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki https://github.com/OmniLayer/spec https://github.com/Colored-Coins/Colored-Coins-Protocol-Specification/wiki/Coloring-Scheme https://www.youtube.com/watch?v=8fBSvN2aqjI&index=21&list=PLWNXOxeBlQ1o75WgSaJ89v4eUPggD38W http://www.multichain.com/developers/ https://docs.google.com/document/d/1NYEYGI7oCRCjtbxRTLXes7M_-PeOwBF_SmwgmV1z78k/edit# https://counterparty.io/news/counterparty-community-update-feb-4/ http://opreturn.org/ http://www.forbes.com/sites/kashmirhill/2014/06/03/mastercoin-maidsafe-crowdsale/#437acdbe6423 https://en.bitcoin.it/wiki/BIP_0068 https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit#heading=h.wxrvzqj8997r https://github.com/chromaway/ngcccbase/wiki/EPOBC_simple http://documentation.colu.co/ https://bitcoil.co.il/BitcoinX.pdf https://www.quora.com/How-do-Bitcoin-colored-coins-work
0 Kommentare
UTXO = Unspent Transaction Output = angesparte Bitcoins
Eine Transaktion besteht immer aus einem oder mehreren Inputs (Sender) und Outputs (Empfänger). Vereinfacht zeigt der Bitcoin Explorer diese Transaktion wie folgt an: 
Der Input ist selbst wiederum ein Output einer früheren Transaktion. Dies ist aus dem unten stehenden Bitcoin Protokoll ersichtlich. Auf der Inputseite "vin" steht ein Output "vout".
Nun kann definiert werden, was eine elektronische Bitcoin Münze (Token) ist:
Bitcoin Münze = txid, vout txid: Hash der Transaktion vout: wievielter Output der Transaktion Input "vin" der obigen Transaktion ist die Bitcoin Münze mit der ID: d3c7e022ea80c4808e64dd0a1dba009f3eaee2318a4ece562f8ef815952717d7, 0 Output "vout" sind die zwei Münzen mit den IDs: 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3, 0, Wert 0.05 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3, 1, Wert 1.0336 Eine elektronische Bitcoin Münze im Wert von 1.0836 wurde sozusagen "eingeschmolzen" und daraus zwei Münzen "geschmiedet". Unten ist eine zweite Transaktion aufgeführt. Die kleine Differenz zwischen Output und Input entspricht der Gebühr von 0.0006 BTC. Damit Bitcoins nicht doppelt ausgegeben werden können, werden sie mit "Spent = ausgegeben" oder " Unspent = nicht ausgegeben" markiert: 
Jetzt kann definiert werden, was ein UTXO (Unspend Transaction Output) bzw. eine angesparte Bitcoin Münze ist:
UTXO = txid, vout, unspent In der obigen Transaktion ist eine UTXO ersichtlich. Diese hat die ID: 576f41a82f58ce5ef7f8d761d8ddbd1a8f62f7d05b3188836964cfde2bc930d0, 1, Unspent Zur Finanzierung von Zahlungen müssen immer ganze UTXO herhalten. Ein eventuelles Wechselgeld wird als neue Einzahlung an die Ausgangsadresse zurückgeschickt. Dies ist aus der ersten obigen Transaktion ersichtlich. Auf der Input- und Outputseite steht die gleiche Bitcoin Adresse. Eine Transaktion soll möglichst wenige UTXO verwenden, um Speicherplatz einzusparen. Daher wird die Blockchain bis zum Genesis-Block auf UTXO durchsucht, die dann in einer Datenbank aufgelistet und sortiert werden. Bei jedem Neustart des Computers wird dieser Vorgang wiederholt.
Programmiersprache
UTXO oder eben Bitcoins werden über die Programmiersprache Forth gesperrt und entsperrt. Diese Sprache, die Ende der 1960er Jahre entstand, ist sehr einfach aufgebaut, indem sie keine Schleifen (Loops) verwendet. Sie ist daher wenig anfällig für DOS-Attacken und braucht wenig Prozessorleistung und Speicherplatz. Das Skript beschreibt, wie UTXO entsperrt und damit konsumiert werden können. Aus der Grafik ist ersichtlich, dass der Skript Text einen Grossteil der Transaktion ausmacht und dementsprechend auch Gebühren verursacht, die pro Byte verrechnet werden. Zu den wichtigsten Standard-Transaktionen gehören:
Pay-to-Public-Key-Hash (P2PKH)
Die digitale Unterschrift muss mit dem Public Key und der Bitcoin Adresse übereinstimmen. Multisig Multi Signature benötigt mehrere digitale Unterschriften und daher müssen mehrere Public Keys in der Transaktion aufgelistet werden. Dies bläht den Speicherbedarf der Transaktion und damit die Blockchain auf und lässt dementsprechend die Gebühren steigen. Multisig wird daher nur noch bei Colored Coins, Counterparty und Omni (ehemals Mastercoin) Protokollen gebraucht. Dabei wird nur eine Unterschrift verlangt, womit es sich eigentlich um eine P2PKH Transaktion handelt. Der Grund für diese Zweckentfremdung liegt darin, dass die restlichen Bytes für zahlungsunabhängige Datenspeicherung gebraucht werden können. Pay-to-Script-Hash (P2SH) Wurde 2012 von Bitcoin Core eingeführt, um komplexere Transaktionen wie Multi Signature einfacher durchzuführen. Seither kann ein Wallet an Stelle eines langen Skripts dessen Hash verwendet. Das eigentliche Redeem Skript samt Hash bzw. Bitcoin Adresse liegt in der Wallet Datenbank. P2SH Bitcoin Adressen werden nicht wie üblich über ECC Verschlüsselung kreiert, sondern über den Hash des Redeem Skripts. Diese Bitcoin Adresse entspricht bis auf nachfolgendes dem Hash des Redeem Skripts. Bei der BaseCheck58 Umformung wird vorne eine 5 angehängt, womit die Bitcoin Adresse mit einer 3 beginnt; im Unterschied zu gewöhnlichen Bitcoin Adressen, die mit 1 beginnen. Wird nun eine Auszahlung von einer Bitcoin Adresse mit einer 3 am Anfang gemacht, fügt das Wallet das entsprechende Redeem Skript aus der Blockchain Datenbank der digitalen Signatur bei. Danach wird das Redeem Skript ausgeführt und die entsprechenden Signaturen verifiziert. Z.B. könnte das Redeem Skript eine Kollektivunterschrift fordern, womit der Miner mehrere digitale Unterschriften abwarten und kontrollieren müsste, bevor die Transaktion bestätigt würde. Das Redeem Skript kann irgendeinen Code enthalten, womit im Prinzip auch Apps oder Smart Contracts wie bei Ethereum ermöglicht werden. Segregated Witness (SegWit) plant auch, dieses Skript zu benutzen. Data Output (OP_RETURN) Weiterhin werden Bitcoin Adressen für kostengünstige Datenspeicherung zweckentfremdet. Da diese Adresse wohl kaum auf der elliptischen Kurve ist, existiert kein dazugehöriger Private Key, weshalb der UTXO nie mehr ausgegeben werden kann. Da die Bitcoins verloren wären, werden für die Datenspeicherung null Bitcoins transferiert. Die UTXO blähen die Blockchain auf und verstopfen über die UTXO Datenbank den Arbeitsspeicher. In der Version 0.9 wurde ein Kompromiss gefunden und ein neuer Operator OP_RETURN eingeführt. Dieser erlaubt seit Version 0.11 pro Transaktion 80 Bytes zahlungsunabhängige Daten zu speichern. Dies genügt für einen 32 Bytes (SHA256) Hash und gewisse Metadaten. Factom speichert zum Beispiel einen Hash mit Kürzel FA in die Blockchain. Diese UTXO werden von vornherein als nicht konsumierbar gekennzeichnet. Zwar wird die Blockchain weiterhin aufgebläht, aber der RAM Arbeitsspeicher entlastet. Der Operator OP_RETURN ist sehr wichtig für Colored Coins. Dies sind Verbriefungen von Vermögenswerten (Aktien, Anleihen, Währungen usw.), die über die Blockchain transferiert werden können. In der Grafik ist eine OP_RETURN Transaktion schematisch dargestellt. Ein minimaler Betrag 0.001 Bitcoins wird überwiesen, damit der minimal zu transferierende Betrag von 0.00006 BTC und die Gebühr von hier 0.0001 BTC gedeckt sind. Das Wechselgeld ist 0.00084 BTC. Die umgerechnet 9.5 Cents wurden nur ausgegeben, damit das Textfeld mit 80 Bytes aufgefüllt und auf der Blockchain gespeichert werden kann. Unter dem Betrag steht das Skript, also die Anleitung, wie man Zugriff auf die Bitcoins erhält. P2PKH sind normale Transaktionen, die die digitale Unterschrift als Zugriff benötigen. Bei OP_RETURN gibt es keinen Zugriff, weshalb dorthin keine Bitcoins gesendet werden dürfen, ansonsten sie verloren sind. Die Textkugel wird ewig in der Blockchain als UTXO enthalten sein. 
Ethereum
Forth ist nicht universell programmierbar. Auch können UTXO nicht teilweise ausgeben (wertblind) werden und nur begrenzt Information aus der Blockchain verarbeiten (blockchainblind). Ethereum hat eine eigene Programmiersprache entwickelt. Schleifen (Loops) sind möglich, was prompt zu Sicherheitslücken bei Applikationen führte. Bei "The DAO" wurden 50 Millionen USD gestohlen. Um dieses Diebesgut im Nichts auflösen zu lassen, wurde die Software umgeschrieben und die Blockchain zurückgesetzt (Hard Fork), was zu einer kontroversen Diskussion führte. Konsequenz war, dass viele den Software Upgrade nicht durchgeführt haben. Damit gibt es nun sozusagen zwei Universen und Währungen: Ether (ETH) und Ether Classic (ETC).  Die zwei gängigsten Verschlüsselungsverfahren sind RSA (Rivest/Shamir/Adleman, 1977) und ECC (Elliptic Curve Cryptography, 1985). Sicherheit ist eine Funktion der Länge des Public Keys (IBAN) und der Wahl des Verschlüsselungsverfahrens. Mit gleichem Zeitaufwand (Security Bits = 80 entspricht erraten einer 48-stelligen Zahl) kann bei RSA ein 1024-stelliger Code geknackt werden, bei ECC jedoch nur ein 160-stelliger (siehe Tabelle oben). Da der Speicheraufwand viel kleiner ist, verwendet die Blockchain ECC. Sowohl bei RSA also auch bei ECC sieht die mathematische Funktion etwa wie folgt aus: Public Key = Z x Private Key Die Umkehrfunktion ist: Private Key = Public Key / Z Für die Division durch Z gibt es aber (noch) keine effizienten Algorithmen, mit denen Computer den Private Key finden könnten. Wenn die Zahl Z sehr gross gewählt wird, ist es mit der heutigen Computertechnik praktisch unmöglich, den Private Key zu finden. ECC ist etwas kompliziert und es wird hier nur schematisch gezeigt, worum es geht. Zuerst sollen die Bestandteile der unten stehenden Grafik beschrieben werden, die wiederum nur eine spezielle stetige elliptische Kurve darstellt, die zur Veranschaulichung dient:  Rot: Elliptische Kurve, mathematisch y^2 = x^3 + 7 G (Generator Point): Ausgangspunkt auf der Kurve, x und y Koordinaten sind sehr gross Grün: Sprünge von einer Seite der Kurve auf die andere, Vorzeichenwechsel Blau: Tangente zur Kurve beim Ausgangspunkt, Differenzieren ECC-Multiplikation: Multiplikation bei ECC bedeutet im Unterschied zur herkömmlichen Mathematik, dass man die Tangente zum Ausgangspunkt G nimmt und schaut, wo sich diese mit der Kurve kreuzt (-2G). Dann springt man auf die andere Seite der Kurve und erhält 2G. Weitere Multiplikation ergibt 4G, 8G usw. ECC-Addition: Dabei wird durch zwei Punkte (z.B. 2G und 4G) eine Linie gelegt. Diese Linie ergibt einen neuen Punkt auf der Kurve. Es gilt: Public Key = Private Key x G oder K = kG Der Private Key gibt also an, wie oft ECC-Multiplikationen durchgeführt werden müssen, um den Public Key zu erhalten. Beispiele: Private Key = 2 führt zu Public Key = 4G Private Key = 3 = 8G Private Key = 10^77 = k = 2^kG Für die Multiplikation gibt es einen effizienten Algorithmus. Dies soll an einem Beispiel gezeigt werden:  Welche Schritte braucht es, um dies zu berechnen (von hinten nach vorne):  Im Endeffekt braucht es also nicht 151 Additionen, sondern nur 7 Multiplikationen und 4 Additionen. Es gibt heute noch keinen effizienten Algorithmus, der in umgekehrter Richtung wieder zu k führt. Dies wird in der Kryptografie "Problem des diskreten Logarithmus" genannt; analog zur Exponentialfunktion (siehe Anhang), obwohl die Umkehrfunktion hier eigentlich eine Division ist. Obige Kurve wurde nur zur Veranschaulichung herangezogen. In der Kryptografie werden nur ganzzahlige Werte (integers) benutzt und das Feld der möglichen Zahlen wird über eine Primzahl begrenzt. Dies nennt sich mod p. Diese Funktion kann am besten anhand einer Uhr erklärt werden. Eine Wanduhr ist mod 12. Wieso? Da die Stunde 13 als 1 Uhr dargestellt wird. 13 mod 12 = 1. Stunde 34 ist folglich 10 Uhr usw. Genau gleich verhält es sich mit dem kryptografischen Feld. Das Feld oben links ist durch die Primzahl 19 abgesteckt. x und y Werte ausserhalb des Feldes werden mod 19 dargestellt, 21 ist also 2. Die Null entspricht der 19 bzw. 19 mod 19. Die drei anderen Felder werden durch die Primzahlen 97, 127 und 487 abgegrenzt.   Über oben stehende Funktion sollen nun ein paar Punkte für das Feld F(p=19) berechnet werden:  Aufgrund der Wurzel, die genommen werden muss, um y zu berechnen, gibt es zu jedem x zwei y. Die Symmetrieachse entspricht y=p/2. Die meisten Blockchains, inklusive Bitcoin, verwenden folgende Kurve (ein paar wenige benutzen schon Edwards Curve):  Als Beispiel sollen Punkte für p = 17 berechnet werden. Dies ist etwas komplizierter. Nehmen wir x = 1. Die rechte Seite ergibt 8. Es gibt aber keine ganzzahlige Wurzel von 8. Darum muss solange 17 dazu addiert werden, bis eine ganzzahlige Wurzel innerhalb des Feldes resultiert. 8 + 17 = 25, Wurzel 25 = 5. Für x = 4 gibt es keine Lösung. Schliesslich ist x = 17 = 17 mod 17 = 0.  Das Feld sieht folgendermassen aus:  Und Feld F(p=19) sieht für diese Kurve so aus:  Für F(p=19) können 12 Punkte und für F(p=17) 18 Punkte berechnet werden. Für die anderen existiert die Wurzel nicht. Im Feld F(p=19) wurde ein Punkt G (x=12, y=14) eingezeichnet. Davon ausgehend werden nun erste Multiplikationen und damit Public Keys grafisch dargestellt (hier möchte ich speziell darauf hinweisen, dass das von Andrea Corbellini aufgestellte Programm einfach fantastisch ist. Spielen Sie damit herum und Sie bekommen ein gutes Gefühl, wie ECC funktioniert):  Bei weiteren Multiplikationen geschieht etwas Merkwürdiges:  Es herrscht Zyklizität vor. Von den 12 Punkten N kommen nur 6 als Key in Frage. Wird als Ausgangspunkt G (x = 0, y = 8) gewählt erhält man sogar nur 3 mögliche Keys. 6G entspricht dem Nullpunkt (im Programm wird dies mit inf = infinity angegeben). Erstaunlich ist auch, dass wenn p keine Primzahl ist, zwar Punkte, aber keine Public Keys berechnet werden können! Zum guten Glück gibt es effiziente Algorithmen, womit die Anzahl Punkte N (Schoff Algorithmus) und daraus die Anzahl Keys K (Lagrange Theorem) berechnet werden können. Auf den Schoff Algorithmus wird hier nicht eingegangen, sondern nur auf das Lagrange Theorem. Dieses besagt, dass K dem kleinsten ganzzahligen Divisor von N entspricht, der mit G multipliziert Null ergibt. Dies hört sich kompliziert an, daher sofort ein Beispiel: Oben hatten wir F(p=19) und N = 12. Divisoren von 12 sind: 1,2,3,6,12. Durch Anwendung der Formel für die Multiplikation zeigt sich, dass 6G = 0. Der gleiche Wert (k=6, 6G=0) wurde oben grafisch gefunden. Den geeigneten Ausgangspunkt G findet man wiederum über einen Algorithmus. Dazu muss der sogenannte Kofaktor (h) berechnet werden. Dieser entspricht N/K und ist in diesem Fall 2. Nun wählt man einen beliebigen Punkt (P) auf der Kurve. G=hP = 2P ist geeignet, falls er nicht dem Nullpunkt entspricht. Ansonsten muss mit einem anderen P ausprobiert werden. Hier soll noch erwähnt werden, dass in der Kryptografie K eine Primzahl sein muss, ansonsten die Verschlüsselung nicht sicher ist. Damit sollten für eine effiziente Public Key Verschlüsselung folgende Punkte erfüllt sein:
 Mit dieser Zahl erhält man aus 256 Bits das grösstmögliche Feld. Jedes F besteht aus 4 Bits (1111). 4x8x8=256. Dies ist jedoch keine Primzahl. Es muss also eine geeignete Primzahl gefunden werden, die möglichst nahe unter diesem Wert liegt. Bitcoin wählt folgende:  Das Ende sieht in binomialer Schreibweise so aus:  Wir müssen also von 2^256 folgende Terme abziehen (überall, wo eine Null steht):  Zum Beispiel entspricht eine 1 an der vierter Stelle von links: 2^32. Zuletzt muss noch 1 abgezogen werden, da das binomiale System bei 0 statt 1 beginnt. Ausgangspunkt G ist bei Bitcoin in komprimierter und dekomprimierter Form:  Anwendung: Signatur bei der Bitcoin BlockchainDie digitale Unterschrift wird gebraucht, um Transaktionen vornehmen zu können. Der Private Key kann als Ausgangspasswort und die Signatur als Hilfspasswort angesehen werden. Die Signatur beweist, dass jemand den Private Key hat, ohne diesen offen zu legen. Hier wurde beschrieben, wie bei Banken Passwörter als Hash auf einem zentralen Server gespeichert werden. Bei der Blockchain beteiligen sich aber viele unbekannte Server, weshalb die Sicherheit durch ECC nochmals erhöht wird. Zur Erstellung der Signatur werden folgende drei Koordinaten auf der elliptischen Kurve benötigt: zG = Zufalls-Koordinaten (x1, y1), z ist grosse Zufallszahl kG = Public Key-Koordinaten (x2, y2), k ist Private Key hG = Nachrichten-Koordinaten (x3, y3), h ist Hash der Transaktion Die digitale Unterschrift sieht wie folgt aus: s = (h + x1 k)/z wobei x1 mitgeliefert wird Schlaue Mathematiker haben herausgefunden, dass zG = s/s zG = (h + x1 k)/s G = (hG + x1 kG)/s zG = (hG + x1 Public Key)/s Die Zufalls-Koordinate hängt vom Hash (h) der Transaktion, dem Public Key, der digitalen Unterschrift (s) und x1 ab, jedoch wird der Private Key nicht mehr benötigt und muss daher zur Verifizierung nicht mehr offen gelegt werden. In den Transaktionsdaten stehen unter Scriptsig der Public Key sowie die digitale Unterschrift, der Hash kann aus der Transaktion berechnet werden und z (damit auch x1) steht in der Blockchain Datenbank. Miners überprüfen die Echtheit der Signatur, indem sie berechnen, ob die beiden Seiten gleich sind. Als Resultat liefert der Algorithmus true oder false bzw. richtig oder falsch. Da die digitale Unterschrift auch vom Hash abhängt, ist sie für jede Transaktion verschieden, was die Sicherheit zusätzlich erhöht. Niemand kann die Transaktion bis zur Verifizierung durch die Miner abändern, ansonsten die digitale Unterschrift nicht korrekt wäre. Jedoch beinhaltet der Hash (h) nicht das Scriptsig selber. Arglistige Miner haben darin minimale Manipulationen vorgenommen, so dass die digitale Signatur weiterhin stimmte, die Transaktions-ID aber komplett anders aussah, als vom Wallet prognostiziert. Diese Sicherheitslücke soll unter SegWit behoben werden. Die Zufalls-Koordinate muss bei jeder Transaktion neu berechnet werden und wirklich zufällig gewählt werden. Ansonsten kann aus zwei Transaktionen der Private Key herausgefunden werden! SONY hat früher eine statische Zufalls-Koordinate gewählt, womit die Playstation gehackt werden konnte. Wallet AufbauDie folgende Beziehung ist wichtig bei der Konstruktion von Wallets: (k + i)G = kG + iG = Public Key + iG i = ganze Zahl, k = Private Key Aus einem Public Key können somit beliebig viele zusätzliche Public Keys und damit Bitcoin Adressen mit Index i gebildet werden. Dafür braucht es den Private Key nicht. Dieser kann offline gespeichert werden und wird nur gebraucht, um kurz Überweisungen zu signieren. Zum Beispiel kann ein Online Webshop für jede Zahlung eine neue Bitcoin Adresse verwenden, um diese einzelnen Kunden zuweisen zu können.  Extended Keys Es würde jedoch keinen Sinn machen, wie hier einfach die Zahlen 1,2,3... zu nehmen. Gelangt trotz Vorsichtsmassnahmen ein Private Key in falsche Hände, können über den Index i sämtliche anderen Private Keys berechnet werden. Deshalb wird noch zusätzlich ein Passwort (Chain Code) verwendet, das nur dem Benutzer bekannt ist. Dieses setzt sich meistens aus 12-24 Wörtern zusammen und ist damit sehr sicher. Oft wird dieses daher gleichzeitig als Wallet Passwort gebraucht. Dann wird der folgende Hash berechnet: h = h (i, Chain Code, Public Key) Anstelle von i wird jetzt der dazugehörige Hash eingesetzt:  Kommt nun einer der Private Keys in falsche Hände, können die anderen Private Keys daraus nicht abgeleitet werden, weil der Chain Code fehlt. Hardened Keys Als zusätzliche Sicherheit kann auf der obersten Ebene im Hash der Private Key anstelle des Public Keys verwendet werden: h = h (i, Chain Code, Private Key) Anhang: Exponentialfunktion und Problem des diskreten LogarithmusExponentialfunktion  In der Kryptografie werden für k ganze Zahlen verwendet, womit die Funktion diskret (nicht stetig) ist. Beispiel:  Für die Exponentialfunktion gibt es einen effizienten Algorithmus, sprich Quadrieren. Dies soll an einem Beispiel gezeigt werden (k steht für Private Key und K für Public Key):  Um herauszufinden, wie viel Mal quadriert werden muss (y), kann die folgende Formel angewendet werden:  y für gerade ganze Zahl abrunden und für ungerade ganze Zahl aufrunden. Im Beispiel haben wir also:  Dies stimmt mit der Berechnung überein:  Um aus dem Public Key (K) den Private Key (k) zu erhalten, muss folgende Gleichung gelöst werden:  Für den Logarithmus einer diskreten Funktion gibt es zum heutigen Zeitpunkt keinen effizienten Algorithmus (für zukünftige Quantencomputer gäbe es einen). Die Differenz an Rechenschritten zwischen Funktion und Umkehrfunktion nimmt mit k exponentiell zu. Diese Differenz ist noch grösser für elliptische Kurve Kryptografie (ECC), weshalb dort kürzere Keys verwendet werden können. Quellen:
http://chimera.labs.oreilly.com/books/1234000001802/ch04.html#hd_wallets https://bitcoin.org/en/developer-guide#hierarchical-deterministic-key-creation http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/ https://cdn.rawgit.com/andreacorbellini/ecc/920b29a/interactive/modk-mul.html https://en.wikipedia.org/wiki/Discrete_logarithm Um einen Private Key zu generieren, bräuchte es keinen Computer oder Internetzugang, sondern lediglich eine Münze (Kopf = 0, Zahl = 1). Die Münze wird 256x geworfen und jeweils aufgeschrieben, ob das Resultat Kopf (0) oder Zahl (1) ist. Somit erhält man eine 256 Ziffern lange Zahl, den Private Key. Diese binäre Darstellung kann offline in die hexadezimale umgeformt werden. Aus dem Private Key lässt sich der Public Key und die Bitcoin Adresse ableiten. Ohne dass diese ans Internet gemeldet wird, können nun Einzahlungen getätigt werden. Die Blockchain akzeptiert alle Zahlungen, die an eine gültige Bitcoin Adresse überwiesen werden. Sämtliche Private Keys - und damit auch Bitcoin Adressen - sind sozusagen bereits vorhanden und durch den Münzwurf wird lediglich zufällig einer davon gewählt. Da es aber mehr Private Keys als Atome im sichtbaren Universum gibt, ist es praktisch unmöglich, dass zweimal der gleiche ausgewählt wird. Würde dies trotzdem mal geschehen, hätten zwei Personen Zugriff auf dasselbe Konto. Einzahlungen können zwar getätigt werden, ohne mit dem Internet verbunden zu sein. Jedoch keine Auszahlungen. Dafür wird ein Wallet benötigt. Ein Wallet ist eine App und Datenbank. Darin werden die Private Keys gespeichert, die zum Auslösen einer Überweisung benötigt werden. Im Wallet ist auch die Blockchain (oder Teile davon) gespeichert. Daraus kann die Wallet Software Kontostände berechnen. Die Bestände der einzelnen Bitcoin Adressen können dann zu einem Wallet Kontostand zusammengefasst werden. Es gibt unterschiedliche Wallets:
Offline Wallet, Cold Storage Diese bieten die höchste Sicherheit. Zwei Computer Wallet Hierbei wird das Offline Wallet auf einem Computer erstellt, der danach keine Verbindung mehr zum Internet hat. Die einzige Funktion besteht darin, eine online erstellte Transaktion offline mit der digitalen Signatur zu versehen. Diese beweist den Besitz des Private Keys, ohne dass dieser preisgegeben wird. Die signierte Transaktion kann dann vom Online-Wallet ausgeführt und durch die Miners bestätigt werden. Der online-offline Transfer kann über einen USB-Stick oder QR-Code geschehen. Wichtig ist, dass vom Offline-Wallet eine Sicherungskopie erstellt wird.  Papier Wallet Dieses kann zum Beispiel bei bitaddress.org kreiert werden. Dabei sollte der Computer offline sein. Um die Sicherheit zusätzlich zu erhöhen, können mehrere Adressen generiert und zusätzlich ein Passwort für die Verschlüsselung (BIP0038) angegeben werden. In der Grafik ist ein verschlüsselter Private Key dargestellt, daher die Farbe blau und das Kürzel 6P. Wiederum auf bitaddress.org kann der Private Key entschlüsselt werden. Ausgedruckt kann das Papier Wallet dann in einen Safe gelegt werden. Falls der Safe bei einer Bank liegt, würde ich keine Verschlüsselung vornehmen. Sie könnten das Passwort verlieren, womit Ihre Bitcoins verloren wären! Der Private Key könnte auch direkt durch Münzwurf auf Papier aufgeschrieben werden. Um langfristig Bitcoins zu halten, ist dies eine sehr sichere Variante. Sobald diese aber ausgegeben werden sollen, kommt man an einem digitalen Wallet nicht vorbei. Um nur den Kontostand abzurufen, importieren Sie nur die Bitcoin Adresse (siehe unten Load & Verify). Sollen Zahlungen getätigt werden, muss aber auch der Private Key ins Wallet transferiert werden (Spend). Der Import kann von Hand oder über den QR-Code erfolgen.  Hardware Wallet Dieses bieten den besten Kompromiss aus sehr hoher Sicherheit und einfacher Handhabung. Es ist sozusagen ein grosser USB-Stick, der nur dafür entworfen wurde, ein Wallet zu sein. Keine Software kann auf ihm installiert werden (nicht einmal ein Zufallsgenerator), was ihn sehr sicher macht. Ein verloren gegangenes Gerät kann ersetzt und das Wallet wiederhergestellt werden. Dazu braucht es den Seed (Keim), ein Passwort bestehend aus 12-24 Wörtern, das an einem sicheren Ort aufbewahrt werden muss. Es ist heute üblich, längere Passwörter zu wählen, die einfach zu merken sind, als kürzere mit Sonderzeichen. Beispiel: Trezor  Obiger TREZOR speichert nur die Private Keys und signiert Transaktionen. Kein Private Key wird an den Computer gesendet. Bei einer Transaktion wird das Template von der Bitcoin Software an den TREZOR geschickt. Dieser zeigt auf dem Bildschirm die Empfänger Bitcoin Adresse und den Betrag an. Durch drücken der ok Taste, wird die Transaktion bestätigt und TREZOR schickt die signierte Transaktion zurück an den Computer. Selbst wenn letzterer durch einen Virus befallen ist, hat dies keinen Einfluss auf die Sicherheit der Transaktion. Der TREZOR selber ist durch einen PIN gesichert. Die PIN Tastatur auf dem Computer sieht so aus:  Die Anordnung der Tastatur wird auf dem TREZOR angezeigt:  Nun kann der PIN auf dem Computer eingegeben werden. Ohne TREZOR nützt der PIN nichts, da die Anordnung der Tastatur nicht bekannt ist. Bei jeder PIN Fehleingabe wird die Zeit, die abgewartet werden muss, exponentiell erhöht; nach dem 20-ten Versuch sind dies bereits 2 Tage. Da der PIN praktisch nicht geknackt werden kann, nützt auch der TREZOR alleine nichts. Online Wallet Dieses befindet sich im Browser auf dem eigenen Computer. Installation und Sicherungskopien geschehen automatisch. Sicherheit ist nun zentral. Der Anbieter muss vertrauenswürdig und technisch auf dem neuesten Stand sein. Der Private Key wird verschlüsselt im Wallet gespeichert und nur zum Signieren von Transaktionen kurze Zeit entschlüsselt. Zusammen mit dem sogenannten Chain Code oder Seed (=Keim) können viele Bitcoin Adressen generiert werden (der technische Teil befindet sich hier im hinteren Teil). Sicherheitshalber besteht der Chain Code meistens aus 12-24 Wörtern und ist daher sehr schwierig zu knacken. Er entspricht häufig dem Passwort für den Wallet Zugriff. Ein Hacker oder Virus könnte über elektronisches Beobachten der Tastatur in den Besitz des Chain Codes gelangen, warten bis der Private Key entschlüsselt wird und die Bitcoins stehlen. Deshalb empfiehlt sich, zusätzlich die 2-Faktor-Authentifizierung (2FA) zu benutzen, welche die Sicherheit signifikant erhöht. Eine Drittpartei, sozusagen ein Treuhänder, generiert dabei über Google Authenticator einen zufälligen 2FA Code, der auf dem Handy abrufbar ist. Zum Auslösen von Transaktionen werden 2 von 3 digitalen Unterschriften gebraucht.
Eine signierte Transaktion wird zusammen mit dem 2FA Code, jedoch ohne Private Key, an die Drittpartei geschickt, dort überprüft und ans Internet weitergeleitet. Falls das Handy verloren geht, kann das 2FA Passwort auf einem neuen manuell eingegeben werden. Light Wallet Ein Wallet, das die ganze Blockchain herunterlädt, betätigt sich als sogenannte "Full Node". Pro Block werden sowohl Kopfzeile wie auch Merkle Tree und Transaktionen benötigt. Dafür wird Speicherkapazität von bereits 85 GB benötigt und der ganze Download kann mehrere Tage in Anspruch nehmen. Für normale Computer kann das Anhängen von neuen Blöcken länger brauchen als deren Entstehungen, womit die lokale Blockchain laufend im Rückstand ist. Spätestens über ein Handy ist dieser Vorgang sowieso nicht mehr möglich.  Transaktionen benötigen 99.9% des Speicherbedarfs. Meistens genügt die abgespeckte (light) Version, die etwa 1000x weniger Speicherplatz benötigt. Ein Light Wallet lädt keine Transaktionen (Tx1, Tx2...), sondern nur die Kopfzeilen der Blockchain (blau) herunter.  Falls nun jemand eine Zahlung tätigen möchte, muss das Light Wallet erstmals prüfen, wie hoch der Kontostand der tangierten Bitcoin Adresse ist. Da es selbst keine Transaktionsliste führt, muss es die UTXO von den Full Nodes anfordern, die die ganze Blockchain herunterladen und überwachen. Wie kann das Light Wallet aber wissen, dass die Daten nicht manipuliert sind? Dazu muss der Miner auch den Merkle Tree Weg von der Transaktion bis zum Root-Hash mitliefern.
Beispiel: Das Light Wallet erhält Tx3 von einem Miner. Damit das Light Wallet sich vergewissern kann, dass die Daten stimmen, muss er auch Hash4 und Hash12 mitliefern. Wieso? Die TransaktionsID von Tx3 entspricht bereits Hash3. Damit kann über Hash4 Hash 34 und in einem weiteren Schritt über Hash12 die Root-Hash berechnet werden. Nur wenn die Daten stimmen, wird der berechnete Root-Hash mit dem vom Light Wallet gespeicherten Root-Hash übereinstimmen. Falls der Kontostand genügt, kann das Light Wallet nun die Transaktion auslösen, sagen wir Tx5. Wie gezeigt wurde, sollten bei grösseren Beträgen mehrere Blöcke abgewartet werden, bevor das Settlement abgeschlossen wird. Dazu muss das Light Wallet etwas später Tx5 und zugehörige Hashes anfordern, um zum Root-Hash zu gelangen. Damit weiss das Light Wallet, in welchen Block Tx5 aufgenommen wurde. Nachdem die Blockzugehörigkeit geklärt ist, wartet das Wallet mit dem Settlement der Zahlung noch ab, bis die nachfolgenden 5 Blöcke bestätigt wurden und die Transaktion nicht mehr rückgängig gemacht werden kann. Bleibt zu sagen, dass natürlich auch Drittfirmen eine Kombination dieser Wallets anbieten. Dabei ist die Vertrauenswürdigkeit entscheidend. Einen guten Ruf hat die US Firma Coinbase, die eine Banklizenz besitzt und Bitcoin Einlagen teilweise gegen Diebstahl versichert. https://bitcoin.org https://bitcointrezor.com/ |