Bitcoin begreifen

Um Transaktions-Umformbarkeit zu erklären, gehen wir zurück zu dem Beispiel in [ch09], in dem du deiner Tochter eine time-locked Transaktion gegeben hast. Wenn knapp ein Jahr vergangen ist, seitdem du deine time-locked Transaktion erzeugt hast, musst du die Transaktion ungültig machen und eine neue time-locked Transaktion generieren, wie in Abbildung 1 dargestellt.

Es ist wichtig, deiner Tochter die neue zeitgesperrte Transaktion Tx₃ zu geben, bevor du Tx₂ sendest, die die vorhergehende zeitgesperrte Transaktion Tx₁ ungültig macht. Ansonsten kann deine Tochter, wenn du es andersherum machst und zwischen den beiden Schritten von einem Bus überfahren wirst, ihren Anspruch auf das Geld nicht anmelden.

Angenommen du machst das korrekt und gibst zunächst Tx₃ deiner Tochter und sendest dann Tx₂. Tx₃ gibt den Output von Tx₂ aus, was bedeutet, Tx₃ enthält die txid von Tx₂ in einer ihrer Inputs. Schauen wir mal, was passiert, wenn du Tx₂ sendest (Abbildung 2).

Qi will Ärger machen. Wenn sie deine Transaktion Tx₂ bekommt, ändert sie sie auf eine bestimmte Weise zu Tx_2M ab, sodass Tx_2M zwar immer noch gültig ist und denselben Effekt hat wie die originale Transaktion Tx₂. (Du siehst gleich ein paar verschiedene Wege, wie sie das erreichen kann.) Das Ergebnis ist, dass jetzt zwei verschiedene Transaktionen durch das Netzwerk laufen, die dieselben Outputs ausgeben und dasselbe Geld in derselben Höhe an die selben Empfänger schicken–aber sie haben unterschiedliche txids.

Weil Tx₂ und Tx_2M dieselben Outputs ausgeben, stehen sie im Konflikt miteinander, und höchstens einer von beiden wird bestätigt. Nehmen wir an, Tx_2M gewinnt und findet Eingang in den nächsten Block. Was passiert mit der Erbschaft deiner Tochter? Siehe Abbildung 3.

Die umgeformte Transaktion, Tx_2M, wird in der Blockchain gespeichert. Dadurch wird Tx₂ ungültig, weil die denselben Output wie Tx_2M ausgibt. Der erste Input der zeitgesperrten Transaktion, Tx₃, referenziert Tx₂ mittels txid, wenn also der 30. April 2020 vorbei ist, wird deine Tochter nicht in der Lage sein, ihr Erbe anzutreten: Sie würde versuchen, einen Output einer ungültigen Transaktion auszugeben.

Wenn ein Transaktions Script signiert wird, hasht der Signatur Algorithmus die Transaktion auf eine bestimmte Weise.

Erinnere dich an [sign-transaction] und wie du alle Signatur Scripts vor dem Signieren bereinigt hast. Wenn du aber nur das tätest, dann würden alle Signaturen genau denselben Hash benutzen. Wenn die Transaktion zwei verschiedene Outputs ausgibt, die an dieselbe Adresse zahlen, könnte die Signatur von einem der Inputs in dem anderen Input wiederverwendet werden. Diese Eigenschaft könnte von einem Bösewicht ausgenutzt werden.

Um dieses Problem zu vermeiden, lässt Bitcoin jede Signatur sich an eine leicht veränderte Version der Transaktion binden, indem es das ausgegebene Pubkey Script in das Signatur Script des Inputs kopiert, der gerade signiert wird.

Zoomen wir ein bisschen in das hinein, was da vor sich geht. Nimm an, du willst eine Transaktion mit zwei Inputs signieren. Der erste Input wird signiert wie in Abbildung 5 dargestellt.

Die Signatur Scripts aller Inputs sind leer, aber du kopierst das Pubkey Script des ausgegebenen Outputs und fügst es in das Signatur Script des ausgebenden Inputs ein. Dann erzeugst du die Signatur für den ersten Input und machst mit dem zweiten Input weiter (Abbildung 6).

Hier sind alle Signatur Scripts ausser dem zweiten leer. Das zweite Signatur Script wird mit dem Pubkey Script des ausgegebenen Outputs gefüllt. Dann wird die Signatur erstellt.

Indem man diese Übung für alle Inputs durchführt, stellt man sicher, dass Signaturen nicht für andere Inputs wiederverwendbar sind, auch wenn sie vom selben private Key signiert wurden. Aber das führt auch ein neues Problem ein: Signaturverifikation wird ineffizient.

Angenommen du willst die Signaturen der oben genannten Transaktion verifizieren. Dann musst du im Grunde für jeden Input dasselbe Vorgehen abarbeiten wie als die Transaktion signiert wurde: alle Signatur Scripts aus der Transaktion bereinigen und dann, eins nach dem anderen, die Pubkey Scripts in das Signatur Script des Inputs, den du verifizieren willst, einfügen. Und danach die Signatur für diesen Input verifizieren.

Das mag harmlos erscheinen, aber wenn die Anzahl Inputs zunimmt, wächst die Menge an Daten, die für jede Signatur gehasht werden müssen. Wenn du die Anzahl Inputs verdoppelst wirst du grob

Wenn die Zeit zur Verifikation der Transaktion mit zwei Inputs in Abbildung 7 1 ms beträgt, dann dauert es 4 ms um eine Transaktion mit vier Inputs zu verifizieren. Verdopple die Anzahl Inputs erneut, und du bekommst 16 ms. Eine Transaktion mit 1.024 Inputs würde über 4 Minuten brauchen!

Diese Schwäche kann ausgenutzt werden, indem eine grosse Transaktion mit einer Menge Inputs erzeugt wird. Alle Nodes, die verifizieren, werden minutenlang blockiert, wodurch sie während dieser Zeit nicht mehr in der Lage sind, andere Transaktionen und Blocks zu verifizieren. Das Bitcoin Netzwerk als Ganzes verlangsamt sich dadurch.

Es wäre viel besser, wenn die Transaktions-Verifikationszeit linear wachsen würde statt quadratisch.: die Zeit zur Verifikation einer Transaktion würde sich verdoppeln, wenn sich die Anzahl Inputs verdoppelt. Dann würde es nur ungefähr 512 ms dauern, die 1024 Inputs zu verifizieren, anstatt 4 Minuten.

Wenn ein Full Node eine Transaktion an ein Lightweight Wallet sendet, schickt er die komplette Transaktion, die alle Signaturdaten enthält. Aber ein Lightweight Wallet kann die Signaturen nicht verifizieren, weil es die ausgegebenen Outputs nicht kennt.

Die Signatur Scripts machen einen erheblichen Teil der Transaktionsgrösse aus. Ein typisches Signatur Script, das einen p2pkh ausgibt, belegt 107 Bytes. Betrachten wir ein par verschiedene Transaktionen mit zwei Outputs, wie in Tabelle 1 gezeigt.

Wäre es nicht schön, wenn ein Full Node nicht die Signatur Script Daten an das Lightweight Wallet schicken müsste? Du würdest vermutlich über 50% an Datenvolumen einsparen. Es gibt nur ein Problem: diese Daten werden benötigt, um die txids zu berechnen. Wenn du das Senden von Signatur Scripts von Transaktionen überspringst, kann das Lightweight Wallet nicht mehr verifizieren, dass die Transaktion im Block enthalten ist, weil sie den Merkle Proof nicht verifizieren kann (Abbildung 8).

Wir würden das wirklich gerne irgendwie lösen.

Gelegentlich wollen wir die Script Sprache mit neuen Operationen erweitern. Zum Beispiel wurden OP_CHECKSEQUENCEVERIFY (OP_CSV) und OP_CHECKLOCKTIMEVERIFY (OP_CLTV) der Sprache 2015 and 2016 hinzugefügt. Schauen wir uns an, wie OP_CLTV eingeführt wurde.

Wir beginnen damit, was OP_ Codes sind. Sie sind nichts als ein einzelnes Byte. OP_EQUAL wird zum Beispiel durch den Hex Code 87 repräsentiert. Jeder Node weiss, dass er, wenn er Byte 87 im Script Programm sieht, die beiden obersten Elemente auf dem Stack vergleichen und das Ergebnis auf dem Stack ablegen muss. OP_CHECKMULTISIG ist auch nur ein einzelnes Byte, ae. Alle Operatoren werden durch verschiedene Bytes repräsentiert.

Als Bitcoin erfunden wurde, wurden mehrere NOP Operatoren spezifiziert, OP_NOP1–OP_NOP10. Diese werden durch die Bytes b0–b9 repräsentiert. Sie sind dafür gemacht, nichts zu tun. Der Name NOP kommt von No OPeration, was im Grunde bedeutet “Wenn diese Instruktion auftaucht, ignoriere sie und mach weiter.”

Diese NOPs können zur Erweiterung der Script Sprache verwendet werden. Der OP_CLTV Operator ist eigentlich OP_NOP2, oder Byte b1. OP_CLTV wurde durch Freigabe einer neuen Bitcoin Core Version eingeführt, die neu definiert, wie OP_NOP2 funktioniert. Aber es musste auf eine kompatible Art geschehen, damit wir nicht die Kompatibilität mit alten, nicht aktualisierten Nodes kaputtmachen.

Gehen wir zurück zum Beispiel von [absolute-time-locked-outputs], wo wir deiner Tochter im voraus ein Taschengeld gegeben haben, das sie ab dem 1. Mai einlösen konnte (siehe Abbildung 9).

Das Pubkey Script für diesen Output ist

So interpretiert ein neuer Node–der die neue Bedeutung des Byte b1 kennt–das Script. Er macht folgendes:

Ein alter Node andererseits wird das Script wie folgt interpretieren:

Er wird

ALte Nodes behandeln OP_NOP2 wie bisher–indem sie nichts tun und weitermachen. Die wissen nichts von den neuen Regeln, die mit dem Byte b1 assoziiert sind.

Die alten und neuen Nodes werden sich gleich verhalten, wenn der OP_CLTV auf dem neuen Node gelingt. Aber wenn er auf dem neuen Node fehlschlägt, wird er das auf dem alten Node nicht tun, da "tu nichts" nie fehlschlägt. Die neuen Nodes schlagen häufiger fehl als die alten Nodes, weil die neuen Nodes strengeren Regeln folgen. Die alten Nodes beenden das Script immer erfolgreich, wenn die neuen Nodes das Script erfolgreich beenden. Dies wird als Soft Fork bezeichnet_ein System Upgrade, das nicht von allen Nodes verlangt wird. Wir sprechen mehr über Forks, System Upgrades und alternative Währungen, die von Bitcoins Blockchain abstammen, in [ch11].

Du fragst dich vielleicht, wozu die OP_DROP Instruktion da ist. OP_DROP nimmt das oberste Element vom Stack und wirft es weg. OP_CTLV ist so gemacht, dass es sich genau wie OP_NOP2 benimmt, wenn es erfolgreich ist. Wenn OP_CTLV ohne Rücksicht auf alte Nodes entworfen worden wäre, dann würde es vermutlich das oberste Element vom Stack nehmen. Aber weil wir an die anderen Nodes denken müssen, tut OP_CTLV dies nicht. Wir brauchen den zusätzlichen OP_DROP hinter OP_CTLV, um das oberste Element auf dem Stack loszuwerden.

Dies war ein Beispiel dafür, wie alte Script Operatoren so umfunktioniert werden können, dass sie etwas Eingeschränkteres tun, ohne das ganze Netzwerk zu stören.

Diese Methode für Script Upgrades wurde bis jetzt für zwei Operatoren verwendet:

Nur 10 OP_NOP Operatoren sind für Script Upgrades verfügbar, und solche Upgrades sind darauf beschränkt, im Erfolgsfalle genau das Verhalten von OP_NOP nachzubilden.

Früher oder später werden wir einen weiteren Script Upgrade Mechanismus benötigen, sowohl weil wir irgendwann keine OP_NOPs mehr haben als auch weil wir wollen, dass die neuen Script Operatoren sich anders benehmen als OP_NOP, wenn sie erfolgreich sind.

Angenommen, dein Wallet benutzt SegWit und du verkaufst einen Laptop an Amy. Dein Wallet muss eine Adresse erzeugen, die du Amy geben kannst. So weit nichts Neues.

Aber SegWit definiert einen neuen Adresstyp, der mittels Bech32 statt base58check codiert wird. Nimm an, dein Wallet erzeugt die folgende SegWit Adresse:

Dieses Adressformat bietet im Vergleich zu den bereits geläufigen base58check Adressen mehrere Verbesserungen:

Deine SegWit Adresse besteht aus zwei Teilen. Die ersten beiden Zeichen, bc (kurz für bitcoin) sind der menschenlesbare Teil. Die 1 ist ein begrenzer zwischen dem menschenlesbaren Teil und dem Datenteil, der die eigentliche Information codiert, die Amy benuzten wird, um den Transaktionsoutput zu erzeugen.

Wir klären ein bisschen später, was das Witness Programm ist. Stell es dir im Moment einfach als PKH vor. Die Version und das Witness Programm lassen sich aus der Adresse nicht direkt herausziehen, denn sie sind mittels bech32 codiert. Du gibst die Adresse bc1qeqzj…ag6jdmkj Amy, indem du ihr einen QR Code zeigst. Sie hat ein modernes Wallet, das dieses Adressformat versteht, also scannt sie deine Adresse und extrahiert Version und Witness Programm, wie Abbildung 12 illustriert.

Dies geschieht in mehreren Schritten:

Amy erzeugt eine Transaktion mit einer neuen Art von Pubkey Script, das du noch nicht gewöhnt bist (Abbildung 13).

Sie sendet diese Transaktion an das Bitcoin Netzwerk. Das Netzwerk wird die Transaktion akzeptieren, weil sie auf die herkömmliche Weise korrekt signiert ist. Irgendwann wird sie in einen Block eingebaut. Dein Wallet wird bestätigen, dass du das Geld bekommen hast, und du gibst Amy den Laptop.

Jetzt wo du das Geld bekommen hast, möchtest du es für eine gebrauchte Popcorn Maschine ausgeben. Sie kostet nur 0,09 BTC. Es ist ein Schnäppchen! Nehmen wir an, der Besitzer der Popcorn Maschine hat die SegWit Adresse bc1qlk34…ul0qwrqp.

Deine Transaktion schickt das Geld an die SegWit Adresse des Besitzers der Popcorn Maschine und zahlt eine 0,01 BTC Transaktionsgebühr (Abbildung 14). Der Input hat ein leeres Signatur Script; die Signaturdaten sind stattdessen als Witness Feld im angehängten Witness eingetragen.

Wären mehrere Inputs in dieser Transaktion gewesen, gäbe es mehrere Witness Felder im Witness, eines für jeden Input. Du kannst SegWit Inputs und herkömmliche Inputs mischen, in diesem Fall sind die Witness Felder für die herkömmlichen Inputs leer, weil deren Signaturen im jeweiligen Signatur Script liegen, so wie sie das immer taten.

Du hast deine Transaktion für die Popcorn Maschine an das Bitcoin Peer-to-Peer Netzwerk zur Verarbeitung geschickt. Schauen wir, wie ein aktueller Full Node diese Transaktion verifiziert, bevor er sie an andere Nodes weiterleitet (Abbildung 15). Weil er die letzte und tollste Softwareversion benutzt, weiss er, wie man mit SegWit Transaktionen umgehen muss.

Der Full Node, der SegWit kennt, sucht nach einem Muster im Pubkey Script, das mit einem einzelnen Versionsbyte beginnt und von einem 2- bis 40-Byte Witness Programm gefolgt wird. In diesem Fall passt das Muster, was bedeutet, es ist ein SegWit Output.

Der nächste Schritt für den Full Node ist, zu verstehen, welche Art von SegWit Output es ist. Zum Zeitpunkt des Schreibens gibt es nur eine Version von SegWit Output: Version 00. Diese Version kommt in zwei verschiedenen Geschmacksrichtungen:

In diesem Fall haben wir das Versionsbyte 00, gefolgt von genau 20 Bytes, was bedeutet, dies ist eine p2wpkh Zahlung. Wenn dem Node das Versionsbyte unbekannt ist, akzeptiert er diesen Input sofort, ohne weitere Bearbeitung. Diese Akzeptanz unbekannter Versionen wird bei späteren, vorwärtskompatiblen Upgrades der Script Sprache nützlich sein. Alle SegWit Nodes erkennen Version 00.

Das p2wpkh ist der einfachste der beiden Typen, weil es ähnlich dem bekannten p2pkh ist. Schauen wir uns an, wie die beiden funktionieren:

Am Ende ist es augenscheinlich genau dasselbe Programm, das für beide Typen abläuft. Der Unterschied liegt darin, woher die Komponenten kommen. Aber es gibt andere Unterschiede zwischen SegWit Scripts und herkömmlichen Scripts–zum Beispiel hat sich die Bedeutung von OP_CHECKSIG geändert, wie wir in Abschnitt 10.2.6 sehen.

Warum überhaupt p2wpkh benutzen, wenn wir sowieso dasselbe Programm laufen lassen wie bei p2pkh? Denk daran, dass wir Transaction Malleability reparieren wollen. Wir tun dies, indem wir die Signaturdaten aus den Transaktion Inputs herausnehmen, sodass niemand die txid durch subtile Änderungen am Signatur Script verändern kann.

Der Full Node hat diese Transaktion verifiziert und schickt sie an seine Peers. Es gibt nur ein Problem: einer der Peers hat keine Ahnung, was SegWit ist. Es ist ein alter Node, der schon eine ganze Weile nicht aktualisiert wurde.

Deine SegWit Transaktion hat sich über das Netzwerk verbreitet und alle Nodes haben sie auf dem Weg verifiziert. Jetzt will ein Miner die Transaktion in einen neuen Block einfügen. Angenommen, der Miner benutzt moderne Software und weiss daher von SegWit. Schauen wir, wie die Transaktion in den Block eingetragen wird (Abbildung 17).

Der Block ist wie zuvor gebaut, aber mit einem wichtigen Unterschied. Eine neue Blockregel wird mit SegWit eingeführt: wenn es SegWit Transaktionen in dem Block gibt, dann muss die Coinbase Transaktion einen Output mit einem Witness Commitment enthalten. Dieses Witness Commitment ist der kombinierte Hash vom Witness Root Hash und einem Reservierten Witness Wert. Der Witness Root Hash ist der Merkle Root der Witness txids (wtxids) aller Transaktionen in dem Block. Die wtxid ist der Hash der Transaktion einschliesslich Witness, wenn es einen gibt. Es gibt eine Ausnahme für die Coinbase, deren wtxid immer als 32 Nullbytes definiert ist. Der reservierte Witness Wert ist für zukünftige Systemerweiterungen vorgesehen.

Das Witness Commitment wird in einen OP_RETURN Output geschrieben (Abbildung 18).

Der reservierte Witness Wert kann ein beliebiger Wert sein. Aber ein Full Node, der den Block verifiziert, muss eine Methode haben, diesen Wert herauszufinden. Wenn der Node den reservierten Witness Wert nicht kennen würde, dann könnte er das Witness Commitment nicht rekonstruieren, um es mit dem OP_RETURN Output des Witness Commitments zu vergleichen. Der Witness der Coinbase Transaktion enthält den reservierten Witness Wert, damit Full Nodes das Witness Commitment verifizieren können.

Erinnerst du dich daran, wie wir p2sh in [pay-to-script-hash] eingeführt haben? p2sh schiebt den Pubkey Script Teil des Programms in den ausgebenden Output. Schauen wir uns nochmal das Wohlfahrts-Wallet an, das John, Ellen und Faiza eingerichtet haben (Abbildung 20).

Ihre Idee war, dass der Zahler–in diesem Falle der Spender–keine höhere Gebühr für ein grosses, komplexes Script zahlen sollte. Stattdessen sollte der Empfänger, der dieses extravagante Modell benutzen will, für die Komplexität bezahlen.

Mit SegWit kannst du ungefähr dasselbe mittels pay-to-witness-script-hash erledigen, was die SegWit Version von p2sh ist. Ist die Namensvergabe in Bitcoin nicht fantastisch?

Angenommen, John, Ellen und Faiza benutzen SegWit für ihr Wohlfahrts-Wallet, und dass der vorherige Popcornmaschinenbesitzer das Geld, das er für die Popcornmaschine bekommen hat, der Wohlfahrt spenden möchte.

John, Ellen und Faiza müssen dem Popcorntypen eine p2wsh Adresse geben. Ihr Witness Script ist dasselbe wie das p2sh Redeem Script war als sie p2sh verwendet haben (Abbildung 21).

Sie verwenden diesen Witness Script Hash zur Erzeugung einer p2wsh Adresse auf die gleiche Weise, wie du deine p2wpkh Adresse generiert hast. Sie codieren

mittels bech32 und bekommen die p2wsh Adresse:

Diese Adresse wird dem Popcorntypen übergeben, der eine Transaktion erzeugt und sendet, so wie sie in Abbildung 22 steht.

An der Transaktion hängt der Witness dran, genau wie bei deiner Transaktion mit dem Popcorn Typen. Der einzige Unterschied zwischen deiner Transaktion und der des Popcorn Typen ist, dass deren Outputs eine unterschiedliche Witness Programm Länge haben. Deine Transaktion hatte ein 20 Byte Witness Programm, weil es der SHA256+RIPEMD160 Hash eines public Keys war, und die Transaktion des Popcorn Typen hat ein 32 Byte Witness Programm, weil es der SHA256 eines Witness Scripts ist.

Diese Transaktion wird verifiziert und eventuell in einen Block integriert.

Ein Problem, das mit SegWit gelöst wird, ist das ineffiziente Hashing von Signaturen. Wie in Abschnitt 10.1.2 erklärt, führt eine Verdopplung der Inputs zu einer runden Vervierfachung der Verifikationszeit der Transaktion. Das liegt daran, dass man

Wenn du die Anzahl berechneter Hashes und die Datenmenge verdoppelst, die jeder Hash verarbeiten muss, vervierfacht man effektiv die Gesamtzeit, die für das Hashen gebraucht wird.

Die Lösung ist, die Signaturen schrittweise zu machen. Nimm an, du willst alle vier Inputs einer Transaktion signieren, wie in Abbildung 26 gezeigt.

Zuerst generierst du einen Zwischenhash der kompletten Transaktion. Wenn die Transaktion non-SegWit Inputs enthält, werden diese Signatur Scripts vor dem Hashen bereinigt. Der Zwischenhash bindet sich an alle Inputs und Outputs dieser Transaktion. Dann fügst du für jeden Input den Zwischenhash zu bestimmten Input-spezifischen Daten hinzu:

Der Grossteil der Transaktion wird nur einmal gehasht, um einen Zwischenhash zu erzeugen. Das reduziert den für das Hashen benötigten Aufwand drastisch. Wenn die Anzahl Inputs sich verdoppelt, verdoppelt sich lediglich der benötigte Aufwand für das Hashen. Das lässt den den Aufwand des Hash-Algorithmus linear mit der Anzahl Inputs wachsen anstatt quadratisch. Die Zeit, eine Transaktion mit 1.024 Inputs zu verifizieren, wie es in Abbildung 7 besprochen wurde, wird von 262.144 ms auf 512 ms verringert.

SegWit entfernt die Signaturdaten aus der Transaktion, sodass immer dann, wenn ein Lightweight Wallet eine Transaktion von einem Full Node anfordert, der Full Node die Transaktion ohne die Witness Daten schicken kann. Das bedeutet, pro Transaktion wird weniger Datenvolumen verbraucht. Diese Tatsache kann verwendet werden, um entweder

Das Versionsbyte wird für künftige Scriptsprachen-Upgrades benutzt. Vor SegWit mussten wir OP_NOPs benutzen, um der Sprache neue Features hinzuzufügen–zum Beispiel OP_CSV. Das war aus folgenden Gründen nicht optimal:

Das Versionsbyte erlaubt viel leistungsfähigere zukünftige Upgrades. Wir können alles machen, von leichten Modifikationen bestimmter Operatoren bis zur Implementation vollständig neuer Sprachen.

Im Jahr 2010 wurde die Bitcoin Software auf ein Blockgrössenlimit von 1.000.000 Bytes erweitert. Es ist nicht vollkommen klar weshalb dies geschah, aber die meisten nehmen an, dass die Begrenzung eingeführt wurde, um den Effekt bestimmter Denial-of-Service (DoS) Attacken zu verringern. DoS Attacken zielen darauf ab, Bitcoin Nodes zu verlangsamen oder abstürzen zu lassen, sodass das Netzwerk nicht ordentlich funktionieren kann.

Ein Weg, mit dem Netzwerk herumzupfuschen ist, einen sehr grossen Block zu erzeugen, der schon bei einer guten Internetverbindung 10 Sekunden zum Herunterladen braucht. Das mag schnell genug erscheinen, aber den Block an fünf Peers zu schicken würde 50 Sekunden dauern. Das führt dazu, dass sich der Block sehr langsam über das Peer-to-Peer Netzwerk verbreitet, was das Risiko eines unabsichtlichen Chain Splits vergrössert. Unabsichtliche Splits lösen sich im Laufe der Zeit von selbst, wie in [draw-lucky-numbers] gezeigt, aber die Sicherheit von Bitcoin verringert sich während solcher Splits.

Ein weiteres potentielles Problem mit grossen Blocks, das Angreifer ausnutzen könnten, ist, dass Leute mit schlechter Internetverbindung völlig aussen vor bleiben, weil sie mit dem Netzwerk nicht mithalten können oder nicht das benötigte Mindestmass an Rechenleistung, RAM oder Massenspeicher zum Betrieb eines Full Nodes haben. Diese Leute werden auf Systeme umschwenken müssen, die weniger Sicherheit bieten, wie Lightweight Wallets, was die Sicherheit für das gesamte Netzwerk verringert.

Egal weshalb, dieses Limit ist gesetzt.

Die Begrenzung der Signaturoperationen wurde eingeführt, weil Signaturverifikationen relativ langsam sind, besonders in non-SegWit Transaktionen. Ein Angreifer könnte eine Transaktion mit einer ungeheuren Menge von Signaturen vollstopfen, was die verifizierenden Nodes dann für eine lange Zeit beschäftigt halten würde. Das Limit von 20.000 solcher Operationen pro Block wurde mehr oder weniger willkürlich getroffen, um eine solche Attacke zu verhindern.

Die Entfernung oder Vergrösserung solcher Limits benötigt eine Hard Fork. Eine Hard Fork ist eine Regeländerung, die zu Meinungsverschiedenheiten zwischen alten und neuen Nodes darüber führt, was die stärkste Chain ist. Wir betrachten Forks und Upgrades in [ch11]. Für den Moment, lass uns annehmen, dass neue Nodes beschliessen, dass 8.000.000 Bytes pro Block OK sind. Wenn ein Miner einen Block veröffentlicht, der grösser als 1.000.000 Byte ist, dann akzeptieren die neuen Nodes diesen, aber die alten Nodes tun dies nicht. Ein permanenter Chain Split würde passieren, und wir hätten im Effekt zwei Kryptowährungen.

SegWit bietet eine Gelegenheit, die Limits ohne eine Hard Fork zu erhöhen.

Durch das Verschieben der Signaturdaten aus der Basistransaktion heraus, sind diese Daten nicht mehr Teil der txid.

Wenn die Signatur umgeformt wird, betrifft das nicht mehr die txid. Unbestätigte Verkettungen von Transaktionen werden unzerbrechlich.

Ein neuer Signatur-Hashing-Algorithmus wird benutzt, der für ein lineares Anwachsen der für die Verifikation benötigten Zeit bei wachsender Anzahl Inputs sorgt. Der alte Signatur-Hashing-Algorithmus hasht die gesamte Transaktion für jede Signatur.

Signaturen in Witnesses hashen die Transaktion nur einmal.

Der Zwischenhash wird für jede Signatur wiederverwendet, was den Gesamtaufwand für das Hashen stark verringert.

Die Bandbreite, die Lightweight Wallets brauchen, verringert sich, weil sie die Witnesses nicht herunterladen müssen, um zu verifizieren, dass die Transaktion Teil eines Blocks ist. Sie können die Ersparnisse pro Transaktion zur Verbesserung ihrer Privacy verwenden, indem sie ihren Bloom Filter verkleinern, oder bei gleichbleibender Privacy ihren Datenverbrauch verringern.

Die Witness Version im Pubkey Script erlaubt zukünftige Upgrades der Script Sprache. Diese Upgrades können beliebig komplex werden, ohne Einschränkungen der Funktionalität.

Neue Regeln gelten für Blocks, die SegWit Transaktionen enthalten. Ein Output in der Coinbase Transaktion muss sich an alle Witnesses des Blocks binden.

Alte Nodes funktionieren weiter, weil sie von dem Commitment in der Coinbase Transaktion nichts wissen. Das lässt uns SegWit einführen, ohne die Blockchain in zwei verschiedene Kryptowährungen aufzuspalten.