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