Segregated Witness (SegWit)

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

Einführung

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.

Implementierung

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:

Merkle Tree

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:

Script PubKey

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. 

Stand Segwit:

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.

Quellen:
https://bitcoincore.org/en/segwit_wallet_dev/
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
https://petertodd.org/2016/segwit-consensus-critical-code-review
https://programmingblockchain.gitbooks.io/programmingblockchain/content/other_types_of_ownership/p2wsh_pay_to_witness_script_hash.html
https://www.reddit.com/r/Bitcoin/comments/5ar38a/can_someone_explain_segwit_transaction_composition/
https://news.bitcoin.com/segregated-witness-concept-turning-point-bitcoin/