Die Bitcoin Blockchain ist sehr transparent. Über den Explorer Blockchain.info ist alles bis auf die Kontoinhaber ersichtlich:

Am Anfang steht die Coinbase Transaktion. Um 16:40 am 14. November 2014 hat ein US Miner 25 Bitcoins + Gebühren über die IP Adresse 95.246.153.98 geschürft. Da er sich dem F2 Pool angeschlossen hat, wurden die Bitcoins an die Adresse 1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY überwiesen. Der Inhaber der Adresse ist im Explorer nur ersichtlich, da es sich um einen Pool handelt. Diese Bitcoins wurden danach in 5 Transaktionen verwendet, die in einem Block enthalten sind, der durch einen polnischen Miner mit IP Adresse 84.238.140.176 geschürft wurde.
Durch eine Blockchain Analyse ist es meistens nur eine Frage der Zeit, bis feststeht, wer hinter einer Bitcoin Adresse steht. Auch Dienstleister wie Chainanalysis.com bieten solche Blockchain Analysen an. Ross Ulbricht, der Gründer des virtuellen Schwarzmarkts Silk Road wurde durch ein Datenleck in einem Rechenzentrum in Island aufgedeckt, obwohl er das dezentrale Netzwerk TOR benutzt hatte. 
​Vielleicht sagen Sie sich jetzt, dass es gut ist, dass solche Machenschaften aufgedeckt werden. Aber wie sieht es aus, wenn jemand Ihr Privatleben durchleuchten kann, indem er IHRE Bitcoin Adresse analysiert? Durch Knopfklick werden alle Ein- und Auszahlungen von einer Bitcoin Adresse ersichtlich:

Heutzutage läuft die Gesetzgebung in die Richtung, dass der Eintritt in die Kryptowelt streng reguliert werden soll. Kryptobanken wie Coinbase oder Fidor und Effektenhändler wie Bitcoin Suisse müssen ihre Kunden kennen (KYC = know your customer) und Geldwäscherei bekämpfen (AML =anti money laundering). Innerhalb der Kryptowelt wird dann Anonymität geduldet. Bei Poloniex muss nur eine E-mail Adresse angegeben werden. Zwar wird auch Vor- und Nachname verlangt, jedoch wird dies nicht kontrolliert. Nur, falls mehr als 2000 USD pro Tag abgehoben werden möchten, wird ein Foto mit ans Gesicht gehaltenem Pass (oder ID) verlangt.  
Im Folgenden soll aufgezeigt werden, wie Anonymität zurückgewonnen werden kann. Ausgangspunkt sind folgende 3 Transaktionen:

Anna bezahlt ihre Steuern, Beat kauft Medikamente in der Apotheke und Corina konsumiert im Erotikshop. Können die Bitcoin Adressen den Namen zugeordnet werden, weiss der Blockchain Analyst wieviel Steuern Anna bezahlt hat, welche Krankheit Beat und welche Vorlieben Corina hat.
Eine Möglichkeit, die Transaktionen zu anonymisieren ist ein sogenannter Mixer:

Die drei zahlen an die Mixer Adresse 1BitmixerEiyyp3eTLaCpgBbhYERs48qza und der Mixer leitet die durchwirbelten Zahlungen weiter. Die weitergeleiteten Zahlungen (rechts) stehen nicht mehr in der gleichen Reihenfolge. Es sieht nun so aus, als wenn BitMixer die Zahlungen gemacht hätte. Natürlich ist jedem Blockchain Analyst klar, dass Zahlungen an 1BitmixerEiyyp3eTLaCpgBbhYERs48qza nur der Verschleierung dienen. Die Frage stellt sich, ob die eigentliche Zahlung trotzdem noch ausfindig gemacht werden kann. Probieren Sie einmal, nur aufgrund der obigen Grafik zuzuordnen.
Sofort erkennbar ist, dass Corina (bzw. von ihrer Adresse aus) im Erotikshop für 8 BTC konsumiert hat. Der Kauf in der Apotheke und die Zahlung der Steuern können aber nicht mehr zugeordnet werden, da zweimal der gleiche Betrag von 10 BTC bezahlt wurde.
Es würde wohl ziemlich lange dauern, bis genau gleiche Zahlungen gefunden würden. Die Einzahlungen an den Mixer können jedoch auch grösser als 10 BTC sein, womit ein Wechselgeld zurückgeschickt wird:

Normalerweise werden Ein- und Auszahlungen nicht gleichzeitig erfolgen, um die Verschleierung zu verbessern. Das Wechselgeld ist insofern problematisch, da dieser Effekt wieder neutralisiert werden könnte. Im obigen Beispiel ist offensichtlich, dass das Wechselgeld an Anna fliesst. In Realität werden jedoch auch Gebühren an BitMixer bezahlt und diese können wiederum eine zusätzliche Verschleierung bewirken:

Auszahlung = Einzahlung – Wechselgeld – Gebühr
​
Bei BitMixer beträgt die Minimumgebühr 0.5%. Würden alle diese verwenden, ergibt sich kein zusätzlicher Verschleierungseffekt. BitMixer rät daher, die Gebühr zu erhöhen. Je höher, desto schwieriger die Blockchain Analyse.
Bei dieser Variante muss dem Anbieter vertraut werden. BitMixer könnte sich mit dem Geld aus dem Staub machen. Eine Alternative ist CoinJoin, das zum Beispiel bei JoinMarket eingesetzt wird. Dabei handelt es sich um einen Smart Contract, der automatisch und dezentral abläuft.
Normalerweise stehen bei Bitcoin auf der Input-Seite Bitcoin Adressen des gleichen Nutzers. Dies muss jedoch nicht so sein, was zur Verschleierung ausgenutzt werden kann. CoinJoin, das über eine API an die Bitcoin Blockchain angebunden werden kann, aggregiert Inputs von mehreren Nutzern in einer Transaktion. Da es bereits Analyse Tools gibt, die solche CoinJoin Transaktionen aufspüren, können wir gleich mal über den Bitcoin Explorer eine anschauen:

Das Wechselgeld kann relativ einfach den Einzahlungen zugeordnet werden:

Wohl kaum werden spontan gleichzeitig drei Überweisungen vorgenommen, die exakt dem Wert 70.12179985 BTC entsprechen. Daher bietet JoinMarket monetäre Anreize. Wer Überweisungen im betreffenden Betrag an sich selber vornimmt, wird dafür bezahlt. Natürlich muss der Anbieter dieser Überweisungen unterschiedliche Sender- und Empfängeradressen angeben.

Bei der DASH Blockchain ist eine verbesserte CoinJoin App direkt ins Protokoll eingebaut:

Masternodes, sind spezielle Knoten, die sich nicht als Miner betätigen, sondern andere Funktionen übernehmen. Eine davon ist die Mixfunktion. Um eine Masternode zu betreiben, müssen 1000 DASH hinterlegt werden, was zum heutigen Kurs stolzen 15000 USD entspricht. Für die Dienstleistungen bekommen die Masternodes einen Teil des Blockentgelts und der Gebühren von den Minern. Bei DASH müssen nicht Transaktionen mit gleichen Beträgen gefunden werden, sondern es werden Denominationen festgelegt. Über PrivateSend können nur Beträge von 100, 10, 1 und 0.1 DASH überwiesen werden, womit das Matching vereinfacht wird. Um eine Überweisung von 110 DASH zu tätigen, müssen zwei Transaktionen im Wert von 100 DASH und 10 DASH gemacht werden. Hier ein Beispiel:

Die 1 am Ende entspricht der Transaktionsgebühr.
Das Pfand bewirkt einen gewissen Schutz vor Attacken. Trotzdem könnte Folgendes passieren:

Falls die NSA genügend Masternodes besetzten, könnten sie eine umfangreiche Blockchain Analyse starten. Deshalb durchlaufen Transaktionen bei DASH mehrere Masternodes.
Ein anderes Problem bei DASH ist, dass die Mixfunktion freiwillig ist:

Wenn Sie die NSA wären, welche Transaktionen würden Sie sich zuerst vorknüpfen?
Genau, diejenigen, die anscheinend etwas zu verbergen haben und daher die Mixfunktion wählen. Ausserdem kann die NSA die Effizienz der Blockchain Analyse noch erhöhen, indem sie selber viele Transaktionen mit PrivateSend vornimmt:

Anna dachte, ihre Überweisung sei sicher. Die NSA sieht aber sofort, welchen Betrag Anna an die Steuerverwaltung überwiesen hat.
Je mehr Transaktionen über PrivateSend versenden werden, desto teurer wird diese Attacke und desto sicherer ist DASH.

Monero geht bei der Verscheierung viel weiter und ist meiner Meinung nach eine Liga für sich. Die Mixfunktion ist Pflicht und das System dezentraler, da es nur Miner, jedoch keine Masternodes gibt. Dadurch werden Transaktionen aber langsamer.
Gemixt werden bei Monero nicht die Münzen (XMR), sondern Sender-Adressen. Als Beispiel wird Anna`s Zahlung an die Steuerbehörden herangezogen. Die Monero Software pickt nun beliebige andere Adressen aus der Monero Blockchain und mixt daraus eine sogenannte Ringsignatur. ​

Der Miner überprüft die Ringsignatur, kann aber nur feststellen, ob einer der dreien berechtigt ist, die XMR auszugeben; er weiss aber nicht wer. Wie kann ein Miner dann aber überprüfen, ob XMR nicht doppelt ausgegeben werden?
Dazu müssen sogenannte Stealth-Adressen aus der Sender- und Empfänger Adresse generiert werden. Jede Stealth Adresse kann nur einmal verwendet werden und beinhaltet einen geheimen gemeinsamen Punkt (GGP) auf der elliptischen Kurve. Dieser GGP ist dem Empfänger unbekannt, aber er kann mit seinem Private Key nach an ihn adressierten Stealth Adressen suchen. Der GGP lässt sich wie folgt berechnen (G = Generator Point auf der elliptischen Kurve):

Daraus lässt sich die Stealth Adresse der Steuerverwaltung ableiten:

Anna`s Monero Wallet berechnet folglich aus ihrem Private Key (kA) und dem Public Key der Steuerverwaltung (Ks) den Punkt GGP und daraus über eine Hashfunktion die Stealth Adresse.
Das Wallet der Steuerverwaltung führt dann mit sämtlichen Public Keys der Monero Datenbank (Ki) folgende Umformungen durch:

Jetzt wird die Monero Datenbank nach diesen potentiellen Stealth Adressen durchforstet. Falls gefunden, wird diese Transaktion dem Wallet der Steuerverwaltung zugefügt. Damit die Steuerverwaltung weiss, wer die Transaktion geschickt hat, kann eine Payment ID an die Transaktion angehängt werden.
Den Private Key der Stealth Adresse erhalten wird durch "Division" der Stealth Adresse mit G:

Natürlich ist die "Division" mit G praktisch unmöglich, sonst wäre die ganze Kryptografie überflüssig. Aber das Wallet der Steuerverwaltung kennt den Private Key (ks) und den gefundenen GGPn.
Würde Anna im folgenden Jahr ihre Steuern von derselben Monero Adresse überweisen, entstände die gleiche Stealth Adresse. Dies muss vermieden werden, um doppelte Ausgabe zu verhindern. Darum wird in der Hashfunktion noch ein Index (i) eingebaut. 

Bei der zweiten Überweisung stünde dann:

Bei der Verifizierung von Transaktionen kontrolliert der Miner, ob das Image nicht schon einmal verwendet wurde.
Nachfolgend wird eine Transaktion aus dem Monero Explorer analysiert:

Links stehen 5 Inputs mit entsprechendem Key Image. Es ist unbekannt, ob die Überweisungen von einer oder verschiedenen Personen aufgegeben wurden. Jede Input Stealth Adresse wird hier mit 3 weiteren gemixt (Mixin = 3). Deshalb brauchen die Outputs nicht mehr wie bei DASH gleiche Beträge aufzuweisen, sondern werden einfach der Grösse nach aufgelistet.
Monero geht aber noch weiter. Sender- und Empfänger Adresse können zwar nicht mehr ausfindig gemacht werden. Jedoch kann ein Blockchain Analyst allein aus den Beträgen trotzdem noch gewisse Informationen erhalten. Deshalb hat Monero mit dem letzten Software Upgrade sogenannte CT Ringsignaturen eingeführt. CT steht für "Confidential Transaction". Damit sind nicht einmal mehr die Beträge sichtbar. Auf Ringsignaturen gehe ich in einem späteren Blog ein. Hier soll nur ein Beispiel aus dem Monero Explorer aufgezeigt werden:

Die Beträge sind überall gleich null gesetzt. Diese Option ist momentan noch freiwillig und reduziert damit etwas die Verschleierung. Mit dem nächsten Upgrade werden CT Ringsignaturen aber Pflicht.
Anfangs wurde gezeigt, welche Informationen über den Bitcoin Explorer frei zur Verfügung stehen, wenn die Bitcoin Adresse eingegeben wird. Schauen Sie doch mal nach, was für Informationen Sie erhalten, wenn meine Monero Adresse in den Monero Explorer eingegeben wird: 

46T9iYT8owaeGdSnp7Z6QBTbETGffbggDFYbPMhoxJDUH9BW5MLEqHSiqqYjdFkWnt85KoxcrFvuMSavSiqEG3dwG1rjDHu

Das genügt Monero aber immer noch nicht. Beispielsweise könnte die chinesische Regierung weiterhin feststellen, von welcher IP Adresse sich jemand bei Monero eingeloggt hat. In Zukunft soll Monero mit dem anonymen Internet Netzwerk I2P gekoppelt werden. Dieses ist dezentraler als TOR. Bei letzterem könnte passieren, dass zufälligerweise von der NSA besetzte Server die Schnittstellen Monero-TOR (Eintritt) und TOR-Monero (Austritt) besetzen. Da I2P dezentraler aufgestellt ist, geht diese Wahrscheinlichkeit dort gegen null. Regierungen können dann nicht einmal mehr feststellen, ob jemand das Monero Wallet geöffnet hat.
Damit trotzdem gerichtliche Erlasse durchgesetzt oder Revisionen durchgeführt werden können, gibt es bei Monero auch noch einen Private und Public View Key:

Der Private View Key wird vom Wallet benutzt, um die Monero Blockchain zu durchforsten und der Public View Key kann weitergereicht werden.
Die Monero Adressen ergeben sich aus einer Kombination von Private Key und Private View Key.

https://cryptonote.org/whitepaper.pdf
https://lab.getmonero.org/pubs/MRL-0003.pdf
https://lab.getmonero.org/pubs/MRL-0005.pdf
​https://steemit.com/monero/@luigi1111/understanding-monero-cryptography-privacy-part-2-stealth-addresses
https://bitmixer.io/faqs.html
​https://bitcointalk.org/index.php?topic=279249.660
​

Die Minimalgebühr, damit ein Bitcoin Core Miner eine Transaktion in einen Block aufnimmt, beträgt 0.0005 BTC (momentan ca. 40 Cents/Rappen). Damit die Transaktionsgebühren 1% nicht übersteigen, muss der transferierte Betrag also mindestens 40 EUR/CHF betragen. Mit dem Lightning Network sollen sich Überweisungen von 1 Cent/Rappen oder sogar 1 Satoshi (kleinste Bitcoin Einheit) lohnen. Gleichzeitig würde die Bitcoin Blockchain entlastet.
​Damit Lightning Network umgesetzt werden könnte, müsste der momentan zur Abstimmung frei gegebene Software Upgrade von Bitcoin (SegWit) angenommen werden. Obwohl ungewiss ist, ob und wann dies der Fall sein wird, verzichte ich im Folgenden auf den Konjunktiv.

Um einen Zahlungskanal ausserhalb der Blockchain zu kreieren, öffnen zwei Parteien (Anna und Beat) für eine bestimmte Zeit ein gemeinsames Kollektivkonto (Multisig Adresse). Zahlungen daraus können nur durch Kollektivunterschrift ausgelöst werden. 
Die beiden Parteien führen danach eine eigenständige Buchhaltung ausserhalb der Blockchain, ohne dass dabei tatsächlich Bitcoin Zahlungen ausgelöst werden. Periodisch, z. B. abends oder nach einer Veränderung von 100 EUR, wird eine provisorische Rückzahlung vom Kollektivkonto an die Bitcoin Adressen von Anna und Beat initiiert.

Diese wird sowohl von Anna als auch Beat ausgelöst und die Private Keys (Passwörter) ausgetauscht, wonach jede Partei eigenständig die Übermittlung an die Blockchain veranlassen könnte.

In der Regel werden sie dies aber nicht tun, da die Geschäftsbeziehung aufrechterhalten werden soll und bei einer Blockchain-Transaktion Gebühren anfallen.  
​Am einfachsten wäre jeweils, die alte provisorische Rückzahlung zu ersetzen. Dieser Vorgang war ursprünglich in der Bitcoin Blockchain vorgesehen, wurde von den Minern und Wallets aber nicht umgesetzt (siehe Colored Coins und Github). 
Darum gibt es viele unrechtmässige veraltete Rückzahlungen, die aber jederzeit von einer der Parteien ausgelöst werden könnte.
Lösung: Über einen Smart Contract kann eine Konventionalstrafe in der Blockchain aufgesetzt werden. Anna würde sämtliche Gelder im Zahlungskanal erhalten, falls Beat eine veraltete Rückzahlung auslöst und umgekehrt. Sie hat eine gewisse Zeit, z.B. 1000 Blöcke Zeit, die Konventionalstrafe über die Blockchain durchzusetzen, ansonsten verjährt sie. 

Ziel ist, mit bilateralen Zahlungskanälen ein ganzes Netzwerk aufzubauen. Beat könnte Drehscheibe für Anna und Corina sein. Anna könnte somit über Beat eine Zahlung von 0.01 BTC an Corina überweisen, ohne einen direkten Zahlungskanal zu Corina zu haben.

Wie kann jedoch gewährleistet werden, dass Beat das Geld auch wirklich an Corina weiterleitet?
Eine Möglichkeit wäre, dass spezialisierte, lizenzierte Banken wie Coinbase oder Fidor als vertrauenswürdige Drehscheibe eingeschaltet werden (ersetzen Beat) und Zahlungskanäle bzw. Kollektivkonten mit ihren Kunden aufsetzen. Darüber können kleinere Bitcoin-Zahlungen getätigt werden (grosse gehen direkt über die Blockchain). Abends oder nach einer 100 EUR Verschiebung in der Bilanz zugunsten der Bank oder des Kunden wird jeweils eine neue provisorische Rückzahlung aufgesetzt. Der Kunde könnte einseitig deren Übertragung in die Blockchain veranlassen, sollte die Bank gehackt werden oder aus Liquiditätsproblemen ihre Schalter schliessen. Eine Bank muss jedoch ihre Kunden identifizieren.
Um den Intermediär zu verhindern und (Pseudo-)Anonymität zu gewährleisten, kann Corina aber auch Zufallszahlen (Z) generieren und daraus einen Hash berechnen. Diesen Hash gibt sie Anna. Nun können die provisorischen Zahlungen (nicht zu verwechseln mit der Rückzahlung des Kollektivkontos) aufgesetzt werden. Diese werden nur ausgelöst, falls der Hash vorgewiesen werden kann, wozu Z bekannt sein muss. Die ausserhalb der Blockchain geführte Buchhaltung wird aktualisiert. Bei Unstimmigkeiten kann die Blockchain wieder als Schiedsrichter herangezogen werden. Corina kann Z offenlegen und damit die 0.01 BTC bei Beat abholen. Da dieser nun ebenfalls Z kennt, kann er die Zahlung von 0.01 BTC von Anna an ihn auslösen. Normalerweise werden die Kontoinhaber aber kooperieren, da der Gang zum Schiedsgericht bzw. die Blockchain Transaktion teuer ist.
Die alten Rückzahlungen vom Kollektivkonto enthalten nun mehrere verschachtelte Konventionalstrafen, worauf hier aber nicht eingegangen wird. 

https://lnmainnet.gaben.win/
​http://lnstat.ideoflux.com:3000/dashboard/db/lightning-network?refresh=5m&orgId=1

Zum besseren Verständnis sollten zuerst folgende Kapitel gelesen werden:
Bitcoin Blockchain
Definition Bitcoin

Digitale Unterschriften (siehe scriptSig in Grafik unten) werden nur von den Minern gebraucht und nur im Zeitpunkt der Kontrolle von Transaktionen. Trotzdem werden diese Daten in der Bitcoin Blockchain verewigt. Auch hat sich gezeigt, dass scriptSig Quelle für Manipulationen ist. Eine Transaktion, die eigentlich gültig ist, kann von einem Miner über scriptSig geringfügig abgeändert und in den Block eingefügt werden. Bei der Kontrolle durch die anderen Miner wird der ganze Block (tausende von Transaktionen) als ungültig erklärt. SegWit möchte diese Daten von der Transaktion segregieren bzw. abspalten, um Speicherplatz einzusparen und Manipulationen zu verhindern. Das Software Upgrade wird aber nur durchgeführt, falls 95% des Bitcoin Ökosystems die Zustimmung geben. 

Um die digitale Unterschrift zu verifizieren, wird unter scriptSig die Signatur und daran angehängt der Public Key aufgelistet. Der Miner kontrolliert, ob die digitale Unterschrift zum Public Key passt. Die Informationen stehen einmal in Assemblersprache (ASM) und darunter in Maschinensprache (HEX). In diesem Fall unterscheiden sich die Zeilen nur durch zwei Längenangaben:

ScriptSig macht einen Grossteil der Transaktion aus. Im Durchschnitt ca. 60%. Unter SegWit wurde eine Lösung gesucht, um diese Daten zu segregieren bzw. abzuspalten.
Wallets können auf scriptSig verzichten. Um zu kontrollieren, ob Bitcoins nicht doppelt ausgegeben werden (Double Spending), müssen keine SegWit Daten herbeigezogen werden. Die Blockchain Datenbank wird daher von zwei auf drei Spalten erweitert: Input und Output von Transaktionen und SegWit Daten:

Miner (Full Nodes) werden alle drei Spalten bzw. die grosse Blockchain herunterladen, Server, Wallets und leistungsstarke PCs (Mid Nodes) die kleine und die restlichen PCs und Smartphones (Light Nodes) weiterhin nur die Kopfzeilen.
Die SegWit Daten werden auch rückwirkend abgetrennt, womit die Grösse der bestehenden Blockchain für nicht-Miner merklich kleiner wird:

Obige Grafik zeigt, dass die kleine Blockchain (Basis) etwa 60% Speicherplatz einspart. Momentan heisst dies 38 GB anstatt 95 GB.
Die Block-Limite von 1 MB gilt nur für die kleine Blockchain. Um nicht eine zweite Limite für die grosse Blockchain einführen zu müssen und damit den Mining-Prozess zu erschweren, werden SegWit Bytes zu 25% berücksichtigt. Für einen Block gilt daher:

Basis Bytes + 25% x SegWit Bytes  ≤ 1 MB
​
Damit wurde ein Anreiz geschaffen, um auf SegWit umzustellen. Heutzutage erreicht nämlich praktisch jeder Block die Limite von 1 MB:

Sobald die Limite unter der alten Version erreicht wird, arbeitet der Basis Miner ohne zusätzliche Einnahmen weiter, bis in der Lotterie gewonnen wird. Er kann keine weiteren Transaktionen mehr berücksichtigen und damit keine zusätzlichen Gebühreneinnahmen generieren. Andererseits produziert er weiterhin Energiekosten, um die Hashes zu berechnen. Ein SegWit Miner kann dagegen weitere Transaktionen zufügen, da Basis Bytes in SegWit Bytes umgewandelt werden und damit die Block-Limite später erreicht wird. 
Da die Block Limite künstlich erhöht wurde, werden vorübergehend auch Kapazitätsengpässe behoben. Das Problem der Skalierung wird dadurch aber nicht behoben, sondern nur zeitlich hinausgezögert.

Eine Transaktion wie in obiger schwarzer Grafik, sieht in Maschinensprache so aus:

Der grüne Teil entspricht dem scriptSig. Unter SegWit wird der Code für Miner leicht angepasst, was aber eine grosse Wirkung hat. Die Transaktion sieht dann so aus:

0001 ist der Marker, der anzeigt, dass es sich um eine SegWit Transaktion handelt. Das grüne scriptSig (Witness) wird ans Ende der Transaktion verschoben, vor nLockTime, und damit von Input und Output segregiert. In diesem Beispiel gibt es nur einen Input bzw. ein scriptSig, was durch die rote 01 ausgedrückt wird. Bei mehreren Inputs wird der Zähler erhöht.
Ausser SegWit Minern werden die restlichen Knoten nach dem Software Upgrade weiterhin mit dem alten Code bzw. der kleinen Blockchain arbeiten:

Da in der Input-Datenbank kein scriptSig mehr enthalten sein wird, sieht die Transaktion folgendermassen aus:  

Vorteil ist, dass Transaktionen deutlich weniger Speicherplatz einnehmen werden; und dies auch rückwirkend! Nachteil ist, dass nicht SegWit Miner keine Überprüfung der digitalen Unterschrift vornehmen, sondern die Transaktion einfach durchwinken werden! Die SegWit Knoten werden zwar die Verifizierung der Blöcke samt SegWit Transaktionen vornehmen. Jedoch kann dies in der Anfangsphase eine gewisse Zeit dauern, da es erst wenige SegWit Knoten geben wird. Für das Settlement sollten also unbedingt mehrere Bestätigungen der Blöcke abgewartet werden. 
Da die Transaktion für SegWit Miner und die restlichen Knoten unterschiedlich aussieht, wird es auch zwei verschiedene Transaktions-IDs geben:

Da es nun zwei Transaktions-IDs gibt (Txid und Wtxid), müssen auch zwei Merkle Trees berechnet werden. Wo wird aber der zweite Baum in die Blockchain eingebaut?
Eine Variante wäre, dass einfach zwei Merkle Trees berechnet werden; einen für Transaktions- und einen für SegWit-Daten. 

Problem dabei ist, dass die alte Software dies nicht zulässt und somit sämtliche Knoten zwingend auf die neue Software umsteigen müssten. Ein solcher Software Upgrade wird Hardfork genannt. Falls nicht alle mitmachten, gäbe es nachher zwei Bitcoin Blockchains mit zwei Kryptowährungen. Das hört sich utopisch an, ist aber genau bei Ethereum passiert. Seit dem Hardfork gibt es Ether Classic (ETC) und Ether (ETH). Auch wird an zwei verschiedenen Ethereum Blockchains weiterentwickelt; Chaos perfekt. Da bei Bitcoin 12 Mrd. USD auf dem Spiel stehen, haben sich die meisten Teilnehmer des Ökosystems gegen eine Hardfork ausgesprochen.
Bei SegWit soll der Software Upgrade über eine Softfork durchgeführt werden. Die alte Version funktioniert danach weiterhin, auch wenn auf gewisse neue Funktionalitäten verzichtet werden muss. Dies vergleicht sich mit einem Upgrade von Windows 9 auf Windows 10.
Segwit bedient sich dabei eines Tricks. Die Anordnung des zweiten Merkle Trees sieht folgendermassen aus:

Die einzige Zahlung, die durch die Bitcoin Blockchain selbst ausgelöst wird, ist Tx1. Diese entspricht jeweils der Coinbase Transaktion, also der Zahlung des Blockentgelts an den Gewinner der Lotterie. Unter Colored Coins wurde gezeigt, wie zahlungsunabhängige Daten in die Blockchain eingebaut werden können, nämlich über OP_RETURN:

ScriptPubKey beschreibt, wer berechtigt ist, die Bitcoins auszugegeben. Unter SegWit werden zwei neue Skripte eingeführt:

P2WPKH = Pay-to-Witness-Public-Key-Hash
​
Wer im Besitz des Public Keys ist, dessen Hash mit dem scriptPubKey übereinstimmt, ist berechtigt, die Bitcoins auszugeben. Der Miner muss bei einer aufgegebenen Überweisung zuerst prüfen, ob der Hash des Public Keys des Senders mit demjenigen im Output übereinstimmt. Ist dies der Fall, wird das Passwort bzw. die digitale Unterschrift kontrolliert. 

P2WSH = Pay-to-Witness-Script-Hash
​
Wer das Redeem-Script besitzt, dessen Hash mit demjenigen im Output übereinstimmt, kann dieses ausführen. Besagt das Redeem-Script zum Beispiel, dass die Bitcoins nur mit Kollektivunterschrift ausgegeben werden können, muss der Miner danach mehrere digital Unterschriften überprüfen. 

Das Präfix 0x00 steht für ein SegWit Skript. Im Moment gibt es nur dieses. Später könnten aber weitere Standard-Transaktionen relativ einfach über einen Softfork eingeführt werden, indem ein neues Präfix zugeteilt wird, z.B. 0x01. Damit kommt Bitcoin ziemlich nahe an Smart Contracts bzw. dezentrale Apps von Ethereum. Z.B. könnte es ein Skript geben, dass besagt, dass die Bitcoins nur ausgegeben werden können, nachdem eine gewisse Anzahl anderer Kryptowährungen (Ether, Factom, Steem etc.) an das Wallet überwiesen wurden. Eine dezentrale Bitcoin Kryptobörse würde ermöglicht.
Die Zahlen 14 und 20 geben an, wie lange der nachfolgende Term ist.  Die hexadezimale 14 (= dezimale 20) kündigt den RIPEMD160 (20 Bytes = 160 Bits) und die hexadezimale 20 (=dezimale 32) den SHA256 (32 Bytes = 256 Bits) Hash an. Bei P2WSH würde die Sicherheit von 160 Bits auf 256 Bits erhöht. 

Wie aus dieser Grafik ersichtlich, steht es um SegWit nicht gut. Die Hashrate von Bitcoin Unlimited, also Miner, die für eine Erhöhung der Blockgrösse sind, überholen gerade SegWit Anhänger.

Zum besseren Verständnis sollte zuerst das Kapital "Bitcoin Blockchain" gelesen werden.

Speicherkapazität und Datendurchlauf sind bei der Bitcoin Blockchain schrecklich, wird mit herkömmlichen Datenbanken wie denjenigen von Facebook, Google, Amazon, VISA oder Netflix verglichen. Jede Full Node (Knoten) speichert sämtliche Daten der Blockchain, die bereits 85 GB gross ist. Neue Knoten brauchen über einen Tag, um eine Kopie anzulegen. Bitcoin stösst an seine Kapazitätsgrenze. Da die Blockgrösse bei 1 MB limitiert ist, steigen die Gebühren solange an, bis die Nachfrage sinkt. Im Moment kann Bitcoin betreffend Gebühren zwar noch locker mit VISA oder Mastercard mithalten. Jedoch geht der Trend in die falsche Richtung und die Bitcoin Blockchain ist nur für hochwertige Daten, wie Bitcoins, geeignet. 

Es gibt zwei Lager mit unterschiedlichen Auffassungen.
Die einen Bitcoin Entwickler meinen, dass die Blockgrösse angepasst werden sollte, um die Kapazität zu erhöhen und die Gebühren zu senken. Damit würde die Bitcoin Blockchain aber umso schneller aufgebläht, womit immer weniger Knoten sich als Miner an der Sicherung beteiligen könnten. Der Konzentrationsprozess würde sich beschleunigen.
Das andere Lager ist daher der Meinung, dass die Blockgrösse prinzipiell unangetastet bleiben soll. Über technologischen Fortschritt soll das Bitcoin Ökosystem effizienter gemacht werden. Light Clients laden nur einen Teil der Blockchain herunter. Über einen Software Upgrade (SegWit) soll ausserdem die Verifizierung der Transaktionen ausserhalb der Blockchain erfolgen, womit die Blöcke entlastet würden. Dies gleicht aber eher einem Flickwerk. Skalierbarkeit wird weiterhin ein Hauptproblem von Bitcoin, aber auch von Ethereum bleiben.
Einen schönen Überblick über diese Debatte gibt es hier.
BigchainDB wählt daher einen anderen Weg: Ausgangspunkt sind herkömmliche dezentrale Datenbanken, die um die Vorteile der Blockchain (keine mächtige Mittlerinstitution, nicht manipulierbar und Token System) erweitert werden. Die bestehenden Datenbanken können ca. 1 Mio. Transaktionen pro Sekunde (TPS) ausführen und die Speicherkapazität beträgt etwa 1’000’000 GB, was dem 10’000-fachen der Bitcoin Blockchain entspricht. Damit können ganze Dokumente anstelle des Fingerabdrucks (Hash) gespeichert werden.
1 Mio. TPS entspricht dem theoretischen Wert der Experimente mit der BitShares oder HEAT Blockchain. Ein weiteres Indiz, dass dies in ein paar Jahren möglich ist. Das Settlement bzw. die Abwicklung von Transaktionen könnte dann wenige Sekunden in Anspruch nehmen – verglichen mit Tagen beim heutigen Bankensystem und 10-60 Minuten bei Bitcoin.
Herkömmliche Datenbanken speichern pro Knoten nur einen Bruchteil der Daten. Im Endeffekt braucht es nur wenige Kopien. Moderne Datenbanken wie Cassandra von Netflix speichern 3 davon. Falls ein Server aussteigt, kann sofort eine neue Kopie angelegt werden. Dass drei Kopien gleichzeitig verloren gehen, ist praktisch unmöglich. Steigt die Anzahl Knoten können mehr Daten gespeichert werden, womit das System skalierbar ist.
Bei Bitcoin beteiligen sich ca. 10’000 Knoten als Full Node. Es gibt damit auch 10’000 vollständige Kopien der Blockchain. Damit fallen im Durchschnitt alle 5’000 Mrd. Jahren sämtliche Kopien aus. Dies ist doch etwas zu grosszügig und macht das System langsam.
Bei BigchainDB beteiligen sich nur eine begrenzte vorbestimmte Anzahl Knoten an der Sicherung. Zu Beginn werden es 5 Institutionen sein, die hauptsächlich nicht gewinnorientiert arbeiten und am Aufbau eines dezentralen, demokratischen Internets interessiert sind. Diese föderierten Knoten stimmen über Transaktionen ab. Sofern eine Mehrheit der Föderationsmitglieder eine Transaktion als gültig ansieht, wird sie in der Blockchain verewigt. Entscheidend ist, dass die Föderation aus unabhängigen Mitgliedern besteht. ​Dabei soll über Gerichtsbarkeit, Regionen, Webhoster (Amazon, Rackspace etc.), Programmiersprachen (Python, Go etc.) und Betriebssysteme (Microsoft, Linux etc.) hinweg diversifiziert werden.
Bei der BigchainDB gibt es zwei Datenbanken (siehe Grafik unten). Im Backlog werden einkommende Transaktionen ungeordnet gespeichert. Dann werden sie verifiziert und – falls fehlerfrei - der Blockchain zugefügt. 

Im Unterschied zu Bitcoin arbeiten alle Knoten an derselben Blockchain. Eine Gabelung (Fork) wie bei herkömmlichen Blockchains ist nicht möglich und die Wahrscheinlichkeit der doppelten Ausgabe von Tokens ist sehr gering. Trotzdem werden Blöcke weiterhin verwendet. Hauptgrund ist, dass in der Datenbank für jedes Föderationsmitglied nur ein Haken (positiv/negativ) und eine digitale Unterschrift pro 1’000 Transaktionen bzw. Block gespeichert werden muss.
Jedes Föderationsmitglied kontrolliert nun die Blöcke. Sofern eine Transaktion fehlerhaft ist oder Output von einem Block ist, der noch nicht abgeschlossen wurde, wird sie wieder in den Backlog zurückgeschoben. Der fehlerhafte Block bleibt jedoch bestehen, da sowieso genügend Speicher zu Verfügung steht und die Löschung der Daten nur Zeit kosten würde. 
​Blöcke werden selbst dann verifiziert, falls eine Mehrheit bereits entschieden hat. Es ist nämlich zeitlich effizienter, zu kontrollieren, statt nachzuforschen, ob eine Verifizierung überhaupt noch nötig ist.
Bei der BigchainDB können mehrere Token parallel in derselben Blockchain nachgeführt werden. Colored Coins sind überflüssig. Sämtliche Token werden auf doppelte Ausgabe überprüft und die Transaktions-Gebühren können in derselben Kryptowährung bezahlt werden.  
BigchainDB baut auf herkömmlichen Datenbanken auf. In der engeren Auswahl standen Cassandra, HBase, Redis, Riak, MongoDB, RethinkDB und ElasticSearch. Alle diese Datenbanken brauchen den Paxos Algorithmus bzw. dessen Abwandlung Raft. Kriterien waren Zuverlässigkeit der Blockanordnung und automatische, schnelle Benachrichtigung von Änderungen der Blockchain. RethinkDB erfüllt die Kriterien am besten. 

Falls alle Föderationsmitglieder auf Amazon Web Services laufen würden, könnten 48’000 GB Speicher pro Knoten zur Verfügung stehen. Bei 25 Mitgliedern käme man schon auf über 1 Petabyte (1’000’000 Mrd. GB). Falls 3 Kopien der Blockchain in der dezentralen Datenbank gespeichert werden, entspricht dies 1/3 Petabyte Speicherplatz. 

Die Zeit, die eine Transaktion braucht, um von einem Föderationsmitglied zum anderen zu wandern, hängt vom Abstand der Knoten ab. Bei einem globalen System beläuft sie sich auf durchschnittlich 150 Millisekunden.
Löst ein Wallet eine Transaktion aus, wird diese an ein Föderationsmitglied gesendet. Dieses prüft, ob keine Coins doppelt ausgegeben werden, indem eine Anfrage an die dezentrale BigchainDB gestartet wird. Je mehr Föderationsmitglieder, desto dezentraler sind die Kopien gespeichert, desto länger dauert eine Anfrage. Falls ok, wird die Transaktion an ein zweites Föderationsmitglied gesendet, das zufällig ausgewählt wird. Dieses schreibt die Transaktion in den Backlog und das Netzwerk wird benachrichtigt. Fehlerfreie Transaktionen werden nun dem lokal gespeicherten Block zugefügt. Dort muss gewartet werden, bis der Block gefüllt ist. Dies ist der Fall nach 1’000 zugefügten Transaktionen oder spätestens nach 5 Sekunden. Erst wenn das Mitglied alle vorgängigen Blöcke kontrolliert hat, wird der Block in die Blockchain geschrieben und wiederum das Netzwerk informiert. Nun können die anderen Föderationsmitglieder den Prüfprozess starten. Jeder Knoten muss für die Verifizierung Anfragen an die Datenbank starten, die digitale Unterschrift berechnen und das Resultat (positiv/negativ) in die Blockchain schreiben. Transaktionen können parallel geprüft werden, weshalb dieser Schritt von der Prozessorleistung abhängt. Sobald eine Verifizierung zu einem Mehrheitsentscheid führt, wird dies dem Netzwerk inklusive Wallet weitergeleitet.
Insgesamt dauert es ca. 1.5 Sekunden bis das Wallet eine definitive Bestätigung der Ausführung bekommt.  
Mit RethinkDB wurden Transaktionen pro Sekunde (TPS) in Abhängigkeit der Anzahl Revisionsknoten getestet (siehe Grafik unten). Bei 32 Knoten wird bereits die Zielgrösse von 1 Mio. TPS erreicht.  

Quellen:
https://www.bigchaindb.com/whitepaper/
​

Ethereum ist das Android der Blockchain. Darüber können dezentrale Apps programmiert und über den Ethereum App Store, MIST Browser genannt, laufengelassen werden. Der MIST Browser ist für dezentrale Apps, was Google Chrome und Mozilla Firefox für herkömmliche Apps sind.
​Jeder Miner lässt die gleichen Apps auf der Ethereum Virtual Machine (EVM) laufen. Fällt ein Computer aus, laufen die Programme auf den anderen weiter. Ethereum kann daher auch als Welt Computer beschrieben werden, an den man sich andocken kann.
Die parallele Ausführung von Apps ist auf den ersten Blick nicht effizient. Der Vorgang ist teurer und langsamer als über traditionelle Computer. Jedoch sind dezentrale Apps fehlertolerant, unabänderlich, erleiden keine Verbindungsunterbrüche und die Daten werden in der Blockchain verewigt. Apps müssen determiniert ablaufen und können keine Zufallszahlen generieren, weil Knoten sonst zu unterschiedlichen Ergebnissen kämen und kein Konsens entstehen könnte. Über Transaktionen können aber Zufallszahlen von aussen in die EVM eingeschleust werden. Die Kryptowährung von Ethereum heisst Ether.

Untenstehende Grafik zeigt eine vereinfachte Darstellung der Ethereum Blockchain. Rechts steht ein Block. Die Kopfzeile des Blocks sieht ähnlich aus wie bei Bitcoin.
In der obersten Zeile stehen die Block Nummer, Zeitpunkt der Entstehung des Blocks und Kopfzeilen-Hash des vorherigen Blocks über den die Blockchain gebildet wird.
​Die zweite Zeile beschreibt die relevanten Daten des Mining Prozesses: Schwierigkeitsgrad (Difficulty) der Lotterie, Adresse des Gewinners und Zahl (Nonce), die zum gesuchten Kopfzeilen-Hash geführt hat.  

In der dritten Zeile stehen die Gas Limite und der Gasverbrauch. Die Gas Limite kann auch mit der Blockgrösse bei Bitcoin verglichen werden, jedoch gibt es ein paar relevante Unterschiede. Bei Ethereum wird nicht nur für Speicher (Bytes), sondern auch für Nutzung des Prozessors und von Bandbreite bezahlt. Es wird definiert, wie viel Gas für Speicherung oder Rechenschritte gebraucht wird. Angebot und Nachfrage bestimmen den Gaspreis. Gas wird nicht an einer Kryptobörse gehandelt, sondern muss mit Ether gekauft werden. Der Preis zwischen Ether und Gas variiert. Wie Transaktionskosten bei Bitcoin wird Gas benötigt, um DOS-Attacken gegen die Software abzuwehren. Auch wird dadurch gewährleistet, dass fehlerhafte Apps nicht unendlich weiterlaufen, sondern nach einer gewissen Anzahl Rechenschritten stoppen (Halting Problem). Die Programme können nicht einfach nach einer gewissen Zeit gestoppt werden, da die Uhr auf verschiedenen Computern nicht exakt gleich ist und darum kein Konsens zustanden kommen könnte. 

Unter der Kopfzeile sind Merkle Bäume dargestellt. Wie bei der Bitcoin Blockchain gezeigt, werden diese für Light Wallets gebraucht. Diese laden nicht die ganze Blockchain, sondern nur die Kopfzeilen herunter und fragen die fehlenden Daten dann von den Minern an. Über den Merkle Tree kann schnell und einfach geprüft werden, ob die angefragten Daten mit den Hashes in der Blockchain übereinstimmen.
Der grüne Transaktionsbaum ist schon von der Beschreibung der Bitcoin-Technologie bekannt. Neu gibt es bei Ethereum auch einen Bestandesbaum (orange). Darin werden Ethereum Adressen mit Kontostand oder App Code gespeichert. Ein Unterbaum dessen ist der Speicherbaum (dunkelrot). Hier werden Daten gespeichert, die von den Apps generiert wurden. Schliesslich gibt es den Baum der Ausführungsprotokolle (grau). Diese Protokolle zeigen auf, wer eine App ausführen liess und wie der Zustand der Blockchain danach aussah. Da eine Beendigung einer App meistens nicht mit der Finalisierung eines Blocks zusammenfällt, ist diese Unterscheidung nötig. In diesem Baum können aber auch beliebige (Log) Daten günstig gespeichert werden, da diese durch die Miner nicht verifiziert werden müssen. Die Root-Hashes werden ebenfalls in der Kopfzeile des Blocks gespeichert. Siehe Appendix für eine genauere Spezifikation des Ethereum Merkle Trees.

Mit Transaktionen können entweder Nachrichten gesendet (message call) oder der Code einer App gespeichert (contract creation) werden. Nachrichten können eine Überweisung oder sonstige Daten sein. Wird eine Nachricht an eine App Adresse gesendet, wird der jeweilige Code ausgeführt.
​
Hier ein Beispiel einer Transaktion:

Der Sender (0xa94…) steuert eine App (0x629…) an. Für diese wird maximal 314159 Gas zur Verfügung gestellt und Input sind Daten in hexadezimaler Form, die von der App gebraucht werden. Zum Beispiel könnte die App ein Namens- oder Domainregister führen und Input der Name bzw. die Domain und deren Besitzer bezeichnen (ein Beispiel folgt weiter unten). 

 Das Ausführungsprotokoll sieht so aus:

Die Transaktion (0x9fc…) hat die App (0xa94…) aufgerufen. Für die Ausführung wurden 30234 Gas konsumiert und inklusive dieser Transaktion wurden im Block bis dahin 314159 Gas verbraucht. In Logs können irgendwelche Daten gespeichert werden, die ein Wallet braucht. Auf diese haben Apps keinen Zugriff; dies im Unterschied zu Daten, die im Speicherbaum enthalten sind.
Wie bei Bitcoin gelangen Transaktionen zuerst in den Mempool und werden dort verifiziert. Unter anderem wird die digitale Signatur des Senders überprüft. Falls der Empfänger einer Transaktion eine App Adresse ist, führt der Miner diese aus, erstellt ein Ausführungsprotokoll und aktualisiert die Kontostände. Falls das Gas nicht ausreicht, wird die Transaktion bis auf die Kosten rückgängig gemacht. Überschüssiges Gas wird schliesslich an den Sender zurückgeschickt. 

Die Ethereum Virtual Machine (EVM) führt die App aus, die durch eine Transaktion ausgelöst wurde. Die App wird deterministisch ausgeführt, so dass alle Knoten zum selben Ergebnis kommen und die Blöcke damit kontrolliert werden können.
Jeder Rechenschritt und jede RAM Speicherung kostet GAS. Es muss vorbestimmt werden, wieviel GAS die Ausführung maximal kosten darf. Ein Zähler behält die Kosten im Auge. Im RAM Arbeitsspeicher können Strings à 32 Bytes gespeichert werden.  Dies ist das Minimum, um in einem Schritt Ethereum Adressen (20 Bytes) inklusive ein paar Daten zu laden.

In der EVM gibt es 3 verschiedene Speichermedien:
​
​1.) Der Stapelspeicher (engl. Stack):
Dieser wird direkt von den Mikroprozessoren unterstützt. Die beiden Hauptfunktionen heissen PUSH für drauflegen und POP für wegnehmen. Die Code Rechenschritte werden darin einer nach dem anderen ausgeführt. Eine Ebene hat Platz für einen 32 Bytes String. 

2.) RAM Arbeitsspeicher (engl. Memory):
Sobald eine App Adresse aufgerufen wird, speichert die EVM eine Kopie davon im Arbeitsspeicher.
​3.) ROM Speicher: App Adresse, wo Code und dazugehörige Daten gespeichert sind. Da es Read Only Memory ist, kann der Code nicht abgeändert werden. 

Der Vorteil vom Stapelspeicher ist, dass die Länge des in der App-Adresse gespeicherten Codes viel kürzer ist.

​Beispiel:

Auf der linken Seite steht der Code für den Stapelspeicher und auf der rechten derjenige für den Arbeitsspeicher.
​ADD = 32 Bytes
3xM + Gleichheitszeichen = 128 Bytes

Die Maschinensprache von EVM gleicht derjenigen von Bitcoin (FORTH), aber beinhaltet auch Schleifen. Damit kann universell programmiert werden. Nachträglich wird ein Beispiel einer App gezeigt, die ein Namensregister führen soll. Die Transaktion, die die App aufruft, wurde schon oben besprochen. Konkrete Inputs sind nun die Zahl 54 und der Name "Reto". Reto soll an der Stelle 54 im Namensregister eingetragen werden.

Der aufgerufene Code in der App-Adresse ​0x6295ee1b4f6dd65047762f924ecd367c17eabf8f sieht folgendermassen aus:

Der erste Teil enthält die Anleitung, den eigentlichen Code aus dem Stapelspeicher in den Arbeitsspeicher zu laden. Dort kann die Software die Ausführung übernehmen. 

Der Stapelspeicher sieht nun folgendermassen aus:

CODECOPY nimmt nun die letzten zwei Zahlen (12,16) und speichert die Strings 12-28 (12+16) vom Code im Arbeitsspeicher: 

Die Operatoren im Arbeitsspeicher sind vielfältiger und werden durch die Software gesteuert: 

Die Ausführung hat also 23 Rechenschritte gebraucht und hat 18 Strings im RAM gespeichert (16 als Code + 2 als Daten aus der Transaktion).  Dafür muss mit GAS bezahlt werden. 
​Diese Maschinensprache ist natürlich nicht sehr benutzerfreundlich. Deshalb gibt es anwenderfreundlichere (höhere) Programmiersprachen. Dies geht von JIT über Serpent bis Solidity. Letztere wurden extra für Ethereum geschrieben. Mit JIT können mehrere Schritte jeweils zusammengefasst werden, womit bis zu 75% Rechenschritte und GAS eingespart werden. 
Spezielle Operatoren, die extra für die EVM definiert wurden, finden sich hier.
       

Im Unterschied zu Bitcoin, wo das Block-Intervall bei ca. 10 Minuten liegt, werden Blöcke bei Ethereum in ca. 14 Sekunden finalisiert. Transaktionen können damit viel schneller abgewickelt werden. Allgemein gilt aber: Je kürzer das Block-Intervall, desto weniger Knoten werden die Blockchain in der nächsten Runde aktualisiert haben. Damit sind zwei Probleme verbunden:
​
Double Spending:
​
Falls ein Miner die Blockchain und damit die Kontostände noch nicht aktualisiert hat, könnte jemand sein Kryptogeld doppelt ausgeben. Sobald die Aktualisierung jedoch erfolgt, wird die fehlerhafte Transaktion sofort rückgängig machen. Ein Problem besteht nur, falls in der Zwischenzeit Waren geliefert oder Dienstleistungen ausgeführt wurden und die Zahlung storniert wird. Um dies zu verhindern, kann mehrere Bestätigungen bzw. Blöcke abgewartet werden, was vor allem bei grösseren Beträgen der Fall sein wird.

Konzentrationsprozess:

Solange ein Miner seine Blockchain nicht aktualisiert hat, arbeitet er weiterhin am alten Block, obwohl dieser eigentlich schon abgeschlossen wurde. Diese Arbeit wird verschwendet. Bei Bitcoin kostet ihn das Geld, ohne dass er Aussicht auf Erfolg hat. Falls er die gesuchte Zahl errät, hat er Pech, weil ein anderer schneller war. Es ist auch so, dass ein Miner mit hohem Hashpower seltener verschwenderische Arbeit leisten wird, einfach darum, weil er ja öfters selber den Block abschliesst. Dies verschafft grossen Minern einen Vorteil, womit eine Tendenz zur Konzentration besteht.

Beispiel:
​
Mining Pool 1 hat 10% Hashpower und Mining Pool 2 30%. Bei ersterem ist 90% der Zeit möglich, dass er an einem Block arbeitet, der schon abgeschlossen wurde. Bei letzterem besteht dieses Risiko nur 70% der Zeit. Damit wird der grössere Pool tendenziell profitabler sein und könnte den kleineren zur Stilllegung zwingen. Es gibt eine Tendenz zur Konzentration, was gefährlich ist.

Um dies zu vermeiden, bekommen bei Ethereum auch "Onkel" Blöcke einen Teil des Blockentgelts. So werden Blöcke genannt, die die gesuchte Zahl innerhalb der folgenden 6 regulären Blöcke noch finden. Die glücklichen erhalten 7/8 des Blockentgelts (4.375 Ether) und der Miner, der den "Onkel" zur Blockchain hinzufügt 1/8 zusätzlich. Jedoch erhalten "Onkel" Blöcke keine Transaktionsgebühren. Dieses Protokoll wird GHOST genannt und wurde 2013 vorgestellt. 

Neben dem oben beschriebenen GHOST Protokoll führt auch Ethash Proof-of-Work, der Mining Algorithmus von Ethereum dazu, dass dem bei Bitcoin gesehenen Konzentrationsprozess entgegengewirkt wird. Bei Bitcoin hängt die Wahrscheinlichkeit in der Lotterie das Blockentgelt zu gewinnen leider nicht nur davon ab, wieviel Revisionsarbeit für die Blockchain erbracht wird, sondern auch wie leistungsfähige Prozessoren eingesetzt werden. Forschung wurde in spezielle Mikrochips (ASICs) investiert, um sich einen Wettbewerbsvorteil zu verschaffen. Ethereum wirkt dem mit Ethash Proof-of-Work entgegen, indem auch der RAM Arbeitsspeicher einbezogen wird (siehe Grafik unten). Mit dem Bitcoin-Hash muss sozusagen eine Extrarunde eingelegt werden. Der Hash ist Input für einen Zufallsgenerator, der 64 Hashes bestimmt, die entweder berechnet oder aus einer Datei, genannt DAG, gelesen werden müssen. Da das Lesen 750x schneller ist als die Berechnung der Hashes, verwenden alle Knoten den DAG. Nach jeder Epoche, momentan definiert als 30’000 Blöcke oder ca. 5 Tage, muss eine Datei von unzähligen Hashes berechnet werden. Der DAG ist 1.7 GB gross, wächst jedoch pro Epoche um ca. 8.3 Mio. Bytes an.
Entscheidend ist nicht so sehr der Speicherplatz, der dafür gebraucht wird, sondern, dass 64 Hashes daraus gesucht und gelesen werden müssen. Der Arbeitsspeicher wurde durch die Forschung der Computerindustrie bereits zum äussersten optimiert, weshalb sich kein Miner für diesen Extraschritt einen Wettbewerbsvorteil verschaffen kann. Findet er eine Möglichkeit heraus, den Arbeitsspeicher zu optimieren, wäre es lukrativer, das Patent an die Computerindustrie zu verkaufen.  

Da der App Code einmal gespeichert nicht mehr abgeändert werden kann, wirken sich Fehler fatal aus. So geschehen bei "The DAO", dem grössten Crowdfunding aller Zeiten, über das 160 Mio. USD finanziert wurden. Ein DAO (Dezentrale Autonome Organisation) ist eine Ethereum App, die die Verwaltung einer Unternehmung übernimmt. Diese wird danach demokratisch über einen Abstimmungsmechanismus geführt. Management gibt es keines.
Investoren konnten mit Hilfe der unten stehenden Funktion jederzeit aussteigen. Ein cleverer Angreifer hat eine Fehlkonstruktion im Code benutzt, um wiederholt Gelder aus dem DAO abzuziehen; wohlgemerkt, nicht nur seine Investition. Dadurch konnte er 50 Mio. USD stehlen.
Der gefährliche Teil des App-Codes hat etwa so ausgesehen:

Das Problem bestand darin, dass die DAO App eine zweite App aufrief (Zeile 3), bevor die Anfangsinvestition des Senders = 0 gesetzt wurde (Zeile 4). Der Angreifer hat nun die zweite App so programmiert, dass wieder zu Zeile 2 gesprungen wurde und konnte so wiederholt Gelder abziehen. Wären Zeilen 3 und 4 vertauscht gewesen, hätte dies nicht passieren können.
Da die App nicht gestoppt werden konnte, hätte der Angreifer sämtliche 160 Mio. USD stehlen können. Die Ethereum Software-Entwickler haben darauf zu einem extremen Mittel gegriffen. Sie haben die Blockchain über einen Hardfork auf den Zeitpunkt vor dem Angriff zurückgesetzt. Sämtliche Gelder aus dem DAO wurden darauf sofort an eine Ethereum Adresse überwiesen. Investoren konnten später darüber ihre Gelder zurück verlangen.  
Nun gab es aber viele Ethereum Wallet Anbieter, die mit dem Hardfork nicht einverstanden waren. Sie argumentierten damit, dass das Besondere der Blockchain genau darin besteht, dass Daten unabänderlich gespeichert würden. Ein Hardfork dürfe nur für einen Software Upgrade benutzt werden.
Diese Wallet-Anbieter haben beide Versionen der Software installiert und damit neue Ether geschöpft. Es lässt sich darüber streiten, ob die Ether auf der alten Software (ETC = Ether Classic) oder der neuen Software (ETH) neu geschaffen wurden. Jeder hatte nun in seinem Wallet die doppelte Menge an Ether. Beide Währungen sanken aber im Wert. ETC ist heute nur noch etwa 1/10 wert.
Der Angreifer konnte die ETC stehlen, jedoch sind diese momentan "nur" noch 5 Mio. USD wert. Insgesamt haben "The DAO" Investoren nur wenig Geld verloren. Der Wert von ETH und ETC zusammengenommen liegt leicht unter dem Wert vor der Attacke. Das Image von Ethereum hat darunter aber arg gelitten.
In Zukunft braucht es wohl spezialisierte Firmen, die neue Apps zuerst auf Fehler überprüfen. Ethereum lernt aus vergangenen Fehlern (wie Bitcoin) und wird dadurch robuster. Software Fehler und Angriffe lassen sich jedoch nie ganz vermeiden – auch nicht bei Microsoft. 

Der Transaktionsbaum muss für jeden Block komplett neu berechnet werden. Hingegen bleibt beim Bestandesbaum ein Grossteil von Block zu Block gleich. Nur von Transaktionen tangierte Kontostände verändern sich. Um Speicherplatz einzusparen, wird eine Abwandlung des Merkle Trees, der sogenannte Patricia Merkle Tree, berechnet. Dieser wurde erstmals im Ripple Protokoll eingesetzt. Ein vereinfachtes Beispiel davon ist in der unten stehenden Grafik links dargestellt. Im Viereck oben rechts stehen 4 Ethereum Adressen mit den entsprechenden Kontoständen. Tatsächlich sind Ethereum Adressen viel länger, wie bei Bitcoin. In diesem Beispiel beginnen alle Adressen mit "a7". Diese Sequenz wird nur einmal in den Baum geschrieben. Da Ethereum Adressen wie Bitcoin Adressen in hexadezimaler Form dargestellt werden, gibt es für die dritte Stelle 16 Zeichen, 0-9 und a-f. Bei den folgenden Stellen gibt es wieder zwei Adressen mit "d3", die gebündelt werden können usw. Rechts in der Grafik steht der einfache Merkle Tree. Über den Patricia Tree (links) müssen bei einer Veränderung der Kontostände markant weniger Hashes neu berechnet werden (dies kommt aus der Grafik nicht zum Ausdruck, da nur 4 Konten angezeigt werden). Die Präfixe werden übrigens benötigt, um die hexadezimalen Zeichen in binäre Computersprache umzuwandeln. 

Quellen:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgettransactionreceipt
https://github.com/ethereum/wiki/wiki/Ethereum-Development-Tutorial
https://medium.com/@jeff.ethereum/optimising-the-ethereum-virtual-machine-58457e61ca15#.1sxy42559
https://medium.com/@jeff.ethereum/go-ethereums-jit-evm-27ef88277520#.o840gcou7
http://www.hashcash.org/papers/dagger.html
https://github.com/ethereum/wiki/wiki/Ethash
http://ethereum.stackexchange.com/questions/6415/eli5-how-does-a-merkle-patricia-trie-tree-work
https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/
https://github.com/ethereum/wiki/wiki/Design-Rationale
http://ethereum.stackexchange.com/questions/2286/what-diagrams-exist-to-illustrate-the-ethereum-blockchain-creation-process
http://ethereum.stackexchange.com/questions/6400/what-is-the-exact-data-structure-of-each-block
http://ethdocs.org/en/latest/introduction/what-is-ethereum.html
http://gavwood.com/Paper.pdf
​

Einleitung

Die Blockchain Technologie ist ein dezentrales Buchhaltungssystem. Zwischen den Nutzern steht kein Intermediär wie zum Beispiel eine Bank. Im Fachjargon wird ein solches System Peer-to-Peer (P2P) genannt. Die Blockchain wird alleine durch die Software gesteuert und muss von den beteiligten PCs und Handys, den Knoten des Netzwerks, heruntergeladen werden. Jeder Knoten führt Buch über sämtliche Daten, die über das Netzwerk transferiert werden. Im Endeffekt gibt es hunderttausende von Kopien der Buchhaltung. Zwar ist dies eine sehr ineffiziente Speicherung. Jedoch ist die Blockchain dadurch auch das sicherste Medium überhaupt, um hochwertige elektronische Daten zu speichern. 
​Die Blockchain wird für verschiedene Anwendungen benutzt und die meisten haben ihre eigene Währung. Angefangen hat alles mit einem Zahlungssystem - BITCOIN. Überweisungen werden alleine über die Software gesteuert. Bank und Clearinghaus fallen weg (siehe Grafik oben). Zahlungen sind dadurch sehr schnell und günstig. 
Unter der Bitcoin Blockchain kann man sich also eine Art dezentrale Online Bank ohne Firma, Sitz und Mitarbeiter vorstellen. Jeder elektronische Bankschalter ist mit ungefähr 100 anderen verknüpft. 
Löst ein Knoten eine Zahlung aus, wird diese Information sogleich an das Netzwerk weitergeleitet. Damit diese elektronischen Bankschalter genug Zeit haben, um ihre Datenbanken zu aktualisieren, werden Transaktionen in Blöcken zusammengefasst. Da es kein Clearinghaus gibt, könnten Betrüger ansonsten noch nicht belastete Bitcoins doppelt ausgegeben. Dies würde zwar von der Software sofort nach der Aktualisierung erkannt und die zweite Zahlung storniert. Jedoch könnte in der Zwischenzeit bereits eine Dienstleistung erfüllt oder eine Ware übertragen worden sein, womit der Dienstleister bzw. Händler geprellt wäre. 

Es gibt verschiedene Knoten. Je nach Funktion, Speicher, Prozessorleistung und Bandbreite des Computers laden diese die ganze Blockchain (full) oder nur einen Teil davon (light) herunter.  

1. Miner
   Sichern die Blockchain und kontrollieren den Zahlungsverkehr und laden daher die ganze Blockchain herunter. Es muss gewährleistet sein, dass stets eine gewisse Anzahl rund um die Uhr im Einsatz ist, damit die Blockchain nicht zusammenbricht. Deshalb werden die Miner für ihre Dienstleistung bezahlt. 
2. Wallet 
   Ist eine App, die Zahlungen auslöst und mehrere Bitcoin Adressen zusammengefasst als ein Konto darstellt. Darin werden auch die "IBAN" Nummern und die Passwörter gespeichert. Ein Wallet, das die ganze Blockchain herunterlädt, ist zwar etwas sicherer. Jedoch wird Speicherkapazität von bereits 85 GB benötigt und der ganze Download kann mehrere Tage in Anspruch nehmen. Spätestens über ein Handy ist dies nicht mehr möglich. Meistens genügt die abgespeckte (light) Version, die etwa 1000x weniger Speicherplatz benötigt.
   
   

 Jeder, der Transaktionen mit Bitcoins tätigen möchte, braucht:

-    Kontonummer (Bitcoin Adresse)                         160 Bits
-    Public Key ("IBAN" Nummer)                               520 / 264 Bits
-    Private Key (Passwort)                                          256 Bits
-    Signatur (digitale Unterschrift, Hilfspasswort)

Vorteil ist, dass sich aus dem Private Key über Verschlüsselungstechnik sowohl Kontonummer wie auch IBAN und Signatur berechnen lassen, jedoch nicht umgekehrt. Nachteil ist, dass falls der Private Key verloren geht, kein Kontozugang mehr besteht und somit auch alle Bitcoins verloren sind. Private Keys müssen sehr sicher aufbewahrt werden. Am besten druckt man sich eine Kopie davon aus und legt sie in einen Safe.
Um einen Private Key zu generieren, braucht man keinen Computer oder Internetzugang, sondern lediglich eine Münze (Kopf = 0, Zahl = 1). Nun wird die Münze 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 (einfacher geht es über bitaddress.org ). Diese binäre Darstellung kann dann in die hexadezimale umgeformt werden. Mehrere Münzwürfe entscheiden also über sämtliche Kontodaten! Der Private Key ist damit nicht etwa besetzt. Würde jemand anderes den gleichen Key wählen, könnte er das Konto leeren. Jedoch gibt es 2^256 (bzw. 10^77) mögliche Kombinationen, was etwa sämtlichen Atomen im sichtbaren Universum entspricht, weshalb die schiere Grösse dafür sorgt, dass es extrem unwahrscheinlich ist, dass zweimal der gleiche Private Key gewählt wird.

Public Key

Der Public Key entspricht einer Koordinate auf der elliptischen Kurve. Die Koordinaten müssen in eine Zahl umgewandelt werden. Das dekomprimierte Format (Präfix 04) erhält man, indem dem Präfix die x und y Koordinate angehängt wird. Der dekomprimierte Public Key ist 520 Bits (2x256 + 8 für Präfix) lang. Über die Funktion der elliptischen Kurve kann aber y aus x berechnet werden, weshalb die x Koordinate eigentlich überflüssig ist. Der Komprimierte Public Key erhält nur noch die x Koordinate und ein Präfix (02 = positiv, 03 = negativ), da für jedes x sowohl eine positive als auch eine negative y Koordinate möglich ist. Die komprimierte Form ist 264 Bits lang und wurde erst kürzlich bei Bitcoin implementiert, um Speicherplatz einzusparen.

Bitcoin Adresse

Durch doppeltes anwenden einer Hashfunktion wird aus dem Public Key schliesslich die Bitcoin Adresse erstellt, die eine Länge von 160 Bits aufweist.
Da der Public Key in verschiedenen Formaten auftaucht (dekomprimiert und komprimiert) gibt es auch verschiedene Formate für Bitcoin Adressen, was etwas verwirrend ist. Damit die Geldbörse (Wallet) weiss, in welcher Form die Adressen importiert werden sollen, wird dem Private Key ein Suffix 01 angehängt, falls es sich um das komprimierte Format handelt (siehe unten Hex-compressed). Natürlich ergibt sich dadurch auch ein komplett anderer Private Key in Base58Check Format (WIF-compressed). Als totale Verwirrung ist dieser sogar länger als der dekomprimierte, was auf das Suffix zurückzuführen ist!

Signatur
​
Die 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. 

Zusammenfassung

Durch ECC-Multiplikation mit dem Private Key erhält man den Public Key und daraus durch doppeltes Hashing die Bitcoin Adresse. Diese wird wie oben beschrieben kompakt in Base58 dargestellt. Damit Tippfehler von Bitcoin Adressen nicht Folgen haben, wird noch eine sogenannte Prüfsumme angehängt. Auf Base58 wird eine Hashfunktion angewendet und die ersten vier Stellen des Hashes an Base58 angehängt. Resultat ist eine kompakte Bitcoin Adresse im Base58Check Format. 

Hier ein Beispiel der verschiedenen Darstellungsweisen:

Transaktionen
​
Um Kapazitäten zu schonen, werden bei Bitcoin keine Kontostände gespeichert (dies im Unterschied zu RIPPLE und HEAT). Wird in einem Wallet ein Bestand angezeigt, so wurde dieser durch eine App ausserhalb der Blockchain generiert. Erfolgt eine Überweisung, werden so viele frühere Einzahlungen (UTXO) als ausgegeben markiert, bis Betrag und Gebühren gedeckt sind. Ein etwaiger Überschuss wird als Wechselgeld an den Sender zurückbezahlt. Dies lässt sich am besten am Bespiel einer älteren Transaktion zeigen:

Links steht der Input oder die Sender Bitcoin Adresse und rechts der Output oder die Empfänger Bitcoin Adressen. Etwas irritierend steht links, also auf der Inputseite, "3.7057 BTC - Output". Dies hängt mit den Transaktionsgebühren zusammen. Input und Output müssen gleich hoch sein. Der Verweis auf der linken Seite gibt an, wie hoch der zu verteilende Gesamtbetrag ist. Die Differenz zum grünen Output Feld gibt an, wie hoch die Gebühr ist.
Die eine Adresse steht sowohl links als auch rechts, da das Wechselgeld an die gleiche Adresse zurückgeschickt wird. Das Wechselgeld wurde in der Zwischenzeit bereits wieder ausgegeben, weshalb der Betrag mit "spent" (ausgegeben) markiert wurde. 
Da jeder Input einem früheren Output entspricht, können Transaktionen bis zur Entstehung der Bitoins (Genesis, Coinbase) zurückverfolgt werden. Bei der Genesis (Entgelt des ersten Blocks) oder Coinbase Transaktion gibt es nur einen Output, da dabei neue Bitcoins geschaffen werden:

Hier hat gerade jemand die 12.5 BTC + Gebühren in der Lotterie gewonnen.

Im Unterschied zu Kreditkarten enthalten Bitcoin Transaktionen keine heiklen Daten, weshalb sie unverschlüsselt über irgendein Netz verschickt werden können. Es ist für eine Regierung daher praktisch unmöglich, Bitcoin abzuschalten.
​
 
Sicherung der Transaktionsliste

Bei Bitcoin ist keine zentrale Bank involviert. Die Transaktionsliste wird dezentral auf vielen unbekannten Servern gespeichert. Zwei Probleme ergeben sich:

1. Die Transaktionsliste könnte gefälscht werden
2. Die Zeit, in der die Transaktionsliste aktualisiert wird, könnte ein Krimineller nutzen, um das Geld doppelt auszugeben

 
Um Manipulationen zu verhindern, könnte die ganze Transaktionsliste einfach mit einem Hash versehen werden. Würde bei irgendeiner Transaktion etwas abgeändert, wäre dies sofort im falschen Hash ersichtlich.
Um Light Wallets zu ermöglichen, die keine Transaktionen speichern, sondern diese bei anderen Knoten anfragen, wird jedoch der sogenannte Merkle Tree (Baum) aufgestellt. Für jede einzelne Transaktion wird ein Hash berechnet und danach, wie in der Abbildung dargestellt, pyramidenförmig weitergerechnet, bis zuoberst nur noch die Merkle Root (Wurzel) übrig bleibt. 

Block
 
Bisher gab es keinen Anlass, Blöcke aufzustellen. Wieso wird dann von Blockchain gesprochen?
Nehmen wir vorerst an, dass derjenige Server, der eine Transaktion als erster geprüft und akzeptiert hat, diese an seine Transaktionsliste anhängt und die Information übers Internet an die anderen Server sendet. Diese aktualisieren dann ebenfalls ihre Listen. Bis die Information übers Internet verbreitet wurde, vergeht eine gewisse Zeit. Es wäre möglich, dass ein Gauner dazwischen die gleiche Transaktion nochmals ausführt (double spending), obwohl sein Konto nun eigentlich leer ist. Geht ein anderer Server seine noch nicht aktualisierte Transaktionsliste durch, geht er fälschlicherweise davon aus, dass noch Geld auf dem Konto ist und gibt die Überweisung frei.
Um dies zu vermeiden, werden Blöcke gebildet. Jeder Server kontrolliert erhaltene Transaktionen und fügt sie falls einwandfrei einem Zwischenspeicher (Mempool) zu. Bei Knoten, die sich als Miner betätigen, entspricht der Mempool dem potentiellen Block. Ein Block wird im Durchschnitt alle 10 Minuten generiert. Damit haben die Knoten genügend Zeit, um ihre Version der Blockchain zu aktualisieren. Die anderen Knoten streichen die im neuen Block enthaltenen Transaktionen von ihrem Zwischenspeicher. 
Der Merkle Tree wird in den Block versetzt. Tatsächlich gibt es jetzt so viele Merkle Trees wie Blöcke. Damit an der Reihenfolge der Blöcke nicht manipuliert werden kann, wird in die Kopfzeile des Blocks auch der Hash des vorherigen Blocks geschrieben. 

Die Nonce zählt die im Merkle Tree berechneten Hashes. Nach jedem Hash wird die Nonce um 1 erhöht, womit ein neuer Kopfzeilen-Hash berechnet werden kann. Je schneller ein Computer Transaktionen verifiziert und Merkle Tree Hashes produziert, desto öfter kann an der Lotterie teilgenommen werden, desto grösser die Gewinnchance. Deshalb wird von Proof-of-Work gesprochen.
​Der Gewinner der Lotterie erhält momentan 12.5 Bitcoins Blockentgelt (ca. 7`400 USD) plus die Gebühren der im Block enthaltenen Transaktionen. Diese neu geschaffenen Bitcoins in Form von Blockentgelt werden Coinbase genannt, da sie nicht durch Überweisung von einer anderen Bitcoin Adresse entstanden sind. Alle 4 Jahre wird dieses Entgelt halbiert. Aufgrund der Halbierung wird die Belohnung im Jahr 2140 unter die kleinste Bitcoin Einheit (1 Satoshi) fallen. Danach werden keine neuen Bitcoins mehr geschaffen und der Gewinner der Lotterie erhält einzig die Gebühren. Total werden 21 Mio. entstanden sein. Das Angebot wird jedoch etwas tiefer sein, da einige Nutzer ihren Private Key verlieren und die Bitcoins damit für immer verloren sind.
​Während des Proof-of-Work Prozesses werden laufend neue verifizierte Transaktionen an den Merkle Tree angehängt. Ein Block ist momentan aber auf 1 Megabyte limitiert. Danach werden keine zusätzlichen Transaktionen mehr zugelassen. Was passiert nun, falls die Kapazitätsgrenze erreicht wird, der ganze Merkle Tree bis zur Merkle Root berechnet wurde, aber noch niemand in der Lotterie gewonnen hat? Dann gibt es noch eine extraNonce, die im Merkle Tree selbst eingebaut ist (in der Coinbase Transaktion). Sobald die extraNonce um 1 erhöht wird, muss der ganze Baum wieder von vorne berechnet werden. Dasselbe geschieht, sobald die Nonce die Zahl 4294967296 erreicht. Dies ist die grösste Zahl, die sich mit 4 Bytes oder 32 Bits darstellen lässt (2^32).  
Da der Kopfzeilen-Hash auf den Kopfzeilen-Hash des vorherigen Blocks verweist, entsteht eine Kette, die Blockchain. 

Hier eine Zusammenfassung der Daten von Block 427254. Die meistens Kennziffern wurden im Text beschrieben. 

Die Priorisierung von Transaktionen hängt neben der Gebühr aber auch vom Alter ab, wofür die ersten 50 Kilobytes im Block reserviert sind. Grosse Beträge, die sich schon lange im Zwischenspeicher (Mempool) befinden, werden bevorzugt. Dies gilt umso mehr, je weniger Speicherplatz die Transaktion benötigt. Insgesamt ergibt sich folgende Formel:

Priorisierung = (Bitcoin Betrag * Zeit seit Aufgabe der Überweisung) / Transaktionsgrösse

Konsensus-Algorithmus
​
Im Schnitt wird die Lotterie alle 10 Minuten gewonnen und damit ein Block generiert. Dabei geht es jedoch immer um Wahrscheinlichkeiten. Es ist möglich, dass per Zufall zwei Server ungefähr gleichzeitig den gesuchten Hash finden. Die beiden Knoten speichern nun zwei verschiedene Blockchains und kommunizieren ihre Version ans Internet. Dies wird Gabelung oder Fork genannt. Welche soll nun weiterverwendet werden?
Bei der Bitcoin Blockchain gilt die Regel, dass die längste Kette beibehalten wird. Also heisst es, abzuwarten, bis der nächste Block generiert wird. Es ist sehr unwahrscheinlich, dass diesmal wieder zwei gleichzeitig Erfolg in der Lotterie haben. Die Software des Gewinners wird den neuen Block an ihre Version der Blockchain anhängen und diese ans Internet weitergeben. Da es jetzt nur noch eine längste Blockchain gibt, wird diese auf den anderen Knoten gespeichert. Pech für denjenigen, der in der vorherigen Runde ebenfalls in der Lotterie gewonnen hat; er geht leer aus. Bei kürzeren Block-Intervallen (z.B. bei Ethereum mit 15 Sekunden) hat dieser Effekt Auswirkung auf die Sicherheit einer Blockchain, sofern nicht gegengesteuert wird.  
Im Schnitt gibt es pro Tag eine Fork mit Länge von 1 Block, all Monat eine mit 2 Blöcken und solche mit 3 Blöcken sind schon sehr selten.
Neue Blöcke werden von den anderen Minern akzeptiert, sofern eine Mehrheit (sagen wir 51%) diese als korrekt verifiziert. 

Doppelte Ausgabe (Double Spending)
​
Je grösser der Anteil eines Miners, desto grösser die Gefahr, dass Bitcoins doppelt ausgegeben werden könnten (double spending), trotz Blöcken. Dies soll an einem extremen Beispiel gezeigt werden.
​​Nehmen wir an, Hans gehört die riesige Mining Farm, die im Bild zu sehen ist. Er sichert damit 49% der Blockchain (49% Hashpower).

Er möchte ein Bild im Gegenwert von 5000 Bitcoins in einer Galerie kaufen und initiiert die Zahlung. In der Blockchain werden die Bitcoins mit der Hash-ID X als "ausgegeben" markiert, die Transaktion dem Block X zugeführt. Hans bedankt sich und macht sich mit dem Bild aus dem Staub. Ein Miner gewinnt in der Lotterie, sendet den Block an die anderen Miner und die Zahlung von Hans wird bestätigt.
Die Miner wenden sich nun dem Block X+1 zu, da sie das Rennen um Block X verloren haben und dort nichts mehr zu gewinnen ist. Hans jedoch manipuliert die Transaktion an den Galeristen, indem er als Zieladresse neu seine eigene angibt und arbeitet am Block X weiter, bis er ebenfalls in der Lotterie gewinnt, obwohl der Topf für diesen Block geleert wurde. Sein Ziel ist ja nicht das Blockentgelt, sondern die Manipulation von Transaktionen.
Die anderen Knoten werden diesen Block akzeptieren, da er alle Voraussetzungen erfüllt. Nun gibt es 2 Blockchains mit unterschiedlichen Köpfen (Fork). Hans gewinnt  in der Lotterie für Block X+1 und fügt diesen der manipulierten Blockchain bei. Diese wird nun als längste Kette vom Netzwerk akzeptiert.
Die anderen 51% Miner bemerken bei der Verifizierung der Transaktionen und Blöcke, dass die Bitcoins mit Hash-ID X bereits ausgegeben wurden und stornieren mit Konsensus von 51% die ursprüngliche Zahlung an den Galeristen. Pech nur, dass Hans mit dem Bild schon über alle Berge ist. Der Galerist wurde geprellt.

51% Attacke

Wie oben gesehen, kann sich Hans zwar mit dem unbezahlten Bild aus dem Staub machen, da er aber nur 49% Hashpower hatte, konnte er keine doppelte Ausgabe tätigen. Hat Hans aber 51% Hashpower kann er auch die Transaktionen selber zumindest vorübergehende manipulieren. 
Bitcoin rät, dass für grössere Zahlungen 6 Blöcke oder Bestätigungen abgewartet werden sollte. Nun müsste Hans 6x hintereinander in der Lotterie gewinnen, um Blöcke und Transaktionen zu manipulieren. Auch wenn er 51% der Blockchain kontrolliert, beträgt die Wahrscheinlichkeit dafür bei tiefen 1.7% (0.51^6). Jedoch wird es ihm jedes 59te Mal gelingen (100%/1.7%=58.8). Und sobald er gewinnt, bringt er die manipulierten Blöcke durch, da er mit 51% die Mehrheit und den Konsensus stellt.
Statt doppelter Ausgabe könnte Hans überhaupt keine Transaktionen in die Blöcke aufnehmen oder überhaupt keine Verifizierung vornehmen und somit alle Transaktionen zulassen. Beides würde zu Chaos und einem Kursverfall von Bitcoin führen.
Eine Aufteilung der Hashpower findet sich hier. ​

GHash.io hat 2014 knapp 50% Anteil erreicht und einmal 6 Blöcke hintereinander gewonnen. Aufgrund des folgenden Bitcoin Crashs, haben Mitglieder freiwillig den Pool verlassen. Jedoch gibt es Organisationen (Staat, Geheimdienst, Bankenkonsortium etc.), die eventuell nicht gewinnorientiert agieren und ein Interesse daran haben könnten, Bitcoin zu Fall zu bringen.
Im April 2013 gab es für ein paar Stunden 2 Ketten. Eine davon war maximal 26 Blöcke länger, womit die meisten Überweisungen bereits ausgelöst waren. Der Grund dafür war ein Software Upgrade. Bei der älteren Version konnte ein Block maximal 1024 Transaktionen enthalten. Diese Restriktion wurde bei der neuen Version aufgegeben. Nun geschah einer der täglichen Forks. Es hiess also abzuwarten, bis Block X+1 über die längste Kette entscheidet. Dieser wurde von einem Knoten generiert, der bereits auf die neue Version umgestellt hatte und daher mehr als 1024 Transaktionen besass. Block X+1 wurde ans Netzwerk kommuniziert, jedoch von vielen Knoten nicht akzeptiert, da sie noch nicht auf die neue Software Version umgestellt hatten. Und so ging es weiter. Block X+2 wurde bestätigt, aber auch teilweise abgelehnt. Spätestens nach einem Fork von 6 Blöcken gingen die Alarmglocken los und die Bitcoin Community rief über Nacht eine Gipfelkonferenz ein. Innerhalb weniger Stunden war der Fehler behoben und der Spuk vorbei.
Um auf 100% sicher zu gehen, darf die Coinbase erst nach 100 Blöcken ausgegeben werden. Schliesslich handelt es sich bei der Coinbase nicht um eine Überweisung, weshalb Zeit keine grosse Rolle spielt.
Es  liegt im Ermessen des Händlers oder Ladenbesitzers, wie viele Block Bestätigungen abgewartet werden soll. Kleine Beträge können akzeptiert werden, ohne überhaupt auf einen Block zu warten.
Meistens werden für Käufe von Bitcoins keine Kreditkarten bzw. nur kleine Beträge akzeptiert, da Kreditkartentransaktionen oft rückgängig gemacht werden.   

Wie anonym ist Bitcoin? 

Viele Leute glauben, dass Bitcoin anonym sei. Dies hat zu Marktplätzen wie Silk Road geführt, die illegale Güter und Dienstleistungen anbieten (Waffen, Mord etc.). Anonymität ist jedoch ein Mythos. Die ganze Blockchain ist öffentlich; jede Transaktion kann zurückverfolgt werden. Die Namen der Kontoinhaber sind zwar nicht ersichtlich, jedoch laufen die Transaktionen übers Internet und von irgendwo muss man sich einloggen. Zumindest in Zukunft wird es für die NSA ein leichtes sein, Identitäten festzustellen. Etwas anders könnte es aussehen mit alternativen Währungen wie Monero. 

Quellen und Links:
CSBreakdown
Mastering Bitcoin 
CuriousInventor
wbn
Michael Nielsen
Bitcoin Wiki
www.imponderablethings.com
​

​

​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):

• Counterparty (XCP)               (Counterparty)
• Bitcrystals (BCY)                    (Counterparty)
• OMNI                                       (OMNI Layer)
• Synereo (AMP)                       (OMNI Layer)
• Maidsafe (MAID)                    (OMNI Layer)

 
Beispiel für einen verbrieften Colored Coin:

• Tether (TUSD)                       (OMNI Layer, USD bei Bank Trust hinterlegt)

 
 
Colored Coin Softwareprogramme:

• Counterparty
• OMNI Layer
• OpenAssets
• Colored Coins
• CoinSpark
• EPOBC
• PeerAssets

 
Colored Coin Wallets (in Klammer Software):

• Counterparty                         (Counterparty)
• OMNI                                       (OMNI Layer)
• CoinPrism                               (OpenAssets)
• Colu                                         (Colored Coins)
• CoinSpark                               (CoinSpark)
• Chromaway                           (EPOBC)
• Lykke                                       (Open Assets)
• NASDAQ                                 (Open Assets Testphase)

 
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:
                                                      

1. Emission oder Genesis von neuen Colored Coins
2. Transfer

​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

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:

1. Pay-to-Public-Key-Hash (P2PKH)
2. Multi Signature (Multisig)
3. ​Pay-to-Script-Hash (P2SH)
4. Data Output (OP_RETURN)

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). ​

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:
​

1. Das Feld muss durch eine Primzahl p begrenzt sein.
2. Die Funktion y^2 mod p muss möglichst viele Lösungen bzw. Wurzeln N aufweisen (Schoff Algorithmus anwenden).
3. Über das Lagrange Theorem wird K bestimmt. K muss eine Primzahl sein, ansonsten müssen obige Parameter geändert werden.
4. Über den Kofaktor N/K wird G gewählt.
   
   

Um eine Sicherheit von 128 Bits zu haben, muss das Feld ungefähr 2^(2x128) = 2^256 Bits gross sein. In der hexagonalen Schreibweise entspricht die grösste Zahl aus 256 Bits:

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:

Die 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) ​

Exponentialfunktion

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