Segregated Witness – die kurzfristige Skaling-Lösung von Core
Da müssen wir jetzt durch. Für die Kernentwickler ist Segregated Witness die bessere Alternative zur Erhöhung der Blocksize. Wie funktioniert das – und warum bevorzugen es die Core-Entwickler?
Segregated Witness wurde zuerst bekannt, als Pieter Wuille es auf dem zweiten Scaling-Bitcoin-Workshop vorstellte und erklärte, man könnte mit Segregated Witness die Kapazität um das 2- bis 4fache erhöhen. Und das per Softfork, und zugleich mit anderen wünschenswerten Vorteilen.
Einige Tage später schlug Gregory Maxwell in einer Mail vor, Segregated Witness so schnell wie möglich (ASAP) zu implementieren, um sich Zeit für die weitere Skalierung zu verschaffen. Gregory Maxwell zog sich kurz danach aus der Kernentwicklung zurück, doch die anderen Kernentwickler haben seine E-Mail zum offiziellen Fahrplan für die Kapazitätserhöhung gemacht. Segregated Witness ist damit die einzige kurzfristige Antwort von Core auf das Scalability-Problem.
Was aber bedeutet Segregated Witness?
Kurz und schmerzhaft: Man entfernt die Signaturen aus den Transaktionen und stopft sie in ein separates Paket. Das spart an sich zwar keine Bandbreite – da die Signaturen ja doch durchs Netz geschickt werden müssen – aber man kann mehr Transaktionen in die Blöcke packen, ohne deren Größe formal zu erhöhen. Es is quasi ein Hack.
Etwas genauer: Schauen wir uns hierfür kurz an, was eine Transaktion ist. Sie besteht aus zwei Teilen: dem Input, der die Herkunft der Bitcoins angibt, und dem Output, der das Ziel der Bitcoins angibt. Beide bestehen aus Scripten. Das Script scriptPubKey für den Output gibt etwa den öffentlichen Schlüssel des Ziel an sowie in der Regel die Bedingung, dass die Bitcoins künftig nur als Input gültig sind, wenn man in das scriptSigs eine oder mehrere Signaturen der privaten Schlüssel einfügt. Daher braucht man den privaten Schlüssel, um Bitcoin zu versenden. Man kann nun aber – das ist der Hack – in das Output-Script hineinschreiben, dass jeder der Lust hat die Bitcoins ausgeben darf. Das nennt sich „anyonecanspend“, und davon ist, aus leicht verständlichen Gründen, im Normalbetrieb abzuraten.
Interessant an „anyonecanspend“ ist jedoch, dass die Bitcoins danach ausgegeben werden können, ohne dass man eine Signatur in einer Transaktion speichert. Clienten, die Segregated Witness nicht aktiviert haben, sehen eine „anyonecanspend“-Transaktion. Clienten mit Segregated Witness hingegen finden im Script eine weitere kleine Info, die sie darauf hinweist, dass die Signatur im Segregated Witness zu speichern ist. So können die alten Clienten die Transaktionen mehr oder weniger ignorieren, während die, die Segregated Witness bereits aktiviert haben, Transaktionen mit ausgelagerter Signatur empfangen und versenden können. Da eine Signatur relativ lang ist, wird so zumindest die Transaktion deutlich kleiner und man spart Transaktionsgebühren – die abhängig von der Größe in Kilobyte berechnet werden.
Alles soweit klar?
Es sollte offensichtlich sein, dass man mit Segregated Witness die Kapazität eines Blocks erhöht, indem man darauf verzichtet, die Signaturen reinzustopfen. Laut Pieter Wuille sparen gewöhnlichen Transaktionen etwa 50% und multi-sig-Transaktionen bis zu 75%. Dies entspräche einer Blockgröße von 2-4MB (bzw. 1,75-4mb, je nach Quelle). Die Blöcke sind offiziell maximal 1 MB groß, es werden aber 2 bis 4 MB durchs Netzwerk geschickt.
Segregated Witness kann, anders als eine Erhöhung der Blockgröße, als Softfork eingeführt werden. Das bedeutet, dass nur 95% der Miner updaten müssen, damit die Funktion aktiviert wird, während Clients, die nicht updaten, einfach eine Funktion weniger haben, aber ansonsten weiter funktionieren. Voraussichtlich wird es also etwas dauern, bis sich Segregated Witness im Netzwerk ausbreitet und seine volle Stärke entfaltet. Für Core ist das ein Vorteil, da man so ohne gefährliche Hard-Fork – die alle alten Clients rauswirft – die Kapazität erhöhen kann.
Wenn es nur ums Skalieren geht, ist Segregated Witness allerdings eine sehr unpraktische Methode. Nicht nur, dass man mit relativ großem Aufwand eine relativ kleine, einmalige Kapazitätserhöhung erreicht – Segregated Witness bringt im Alltagsgeschäft maximal eine Erhöhung auf 2 MB, birgt aber dieselben Gefahren wie 4MB. Wenn man bestimmte Multi-Sig-Transaktionen baut, kann man einem Block die Kapazität vo 4 MB verleihen. In diesem Fall kommen alle Angriffe – Spam oder Riesentransaktionen – mit derselben Wucht daher wie mit 4 MB Blöcken.
D.h. wir brauchen ein Niveau der Sicherheit, dass nur in den seltensten Fällen nötig ist. Das ist etwa so, als würde man eine 4-Liter-Flasche kaufen um 2 Liter Wodka zu verschenken. Wenn wir später, nach SegWit, noch einmal die Kapazität erhöhen wollen, brauchen wir eventuell größere Blöcke. Um die normale Kapazität von 1,75 auf sagen wir 7 MB zu erhöhen, müssen wir gegen Angriffe bis zu 16 MB gewappnet sein. Und so weiter. Das ist sicherlich keine Katastrophe, aber auch nicht eben hilfreich.
Die Kernentwickler haben sich jedoch nicht ohne Grund für Segregated Witness entschieden. Zum einen, weil es per Softfork anstatt Hardfork einsetzbar ist. Damit kann man skalieren, ohne befürchten zu müssen, das Netzwerk zu zerbrechen. Zum anderen ist die Kapazitätserhöhung eher ein Nebeneffekt von Segregated Witness, das viele weitere Vorteile hat:
- Es beseitigt Malleable Transaktionen. Das ist kein brennendes Problem, eher ein Ärgernis, stört aber auch die Einführung des Lightning-Netzwerkes oder anderer Schichten um die Blockchain herum
- Es ermöglicht weitere Scriptarten über das Segregated Witness. Möglicherweise ebenso flexible, Turing vollständige Tranaktionsscripte wie in Ethereum.
- Über das Segregated Witness kann man sogenannte „Fraud Proofs“ einführen, die helfen, Light Wallets sicherer zu machen
Ich will – und kann – hier nicht auf jedes dieser Dinge im Detail eingehen. Das Lightning-Netzwerk soll die Kapazität des Bitcoins durch Payment-Channels anstatt die Blockgröße erhöhen und ist, daran zweifelt keiner, eine der Methoden, die notwendig sind, um Bitcoin irgendwann „wirklich“ zu skalieren (ein Niveau wie Visa zu erreichen, ein echtes großes Mikropayment zu ermöglichen). Man kann einfach nicht alle Transaktionen der Welt in die Blockchain packen.
Segregated Witness ist also durchaus sinnvoll im Kontext der Skalierung. Es ist auch möglich, dass der Kapazitätsanstieg, den es dem Netzwerk verleiht, fürs Erste ausreicht, sofern das Wachstum der Transaktionen etwas abflaut. Wenn man jedoch Bitcoin wirklich über die Blockgröße skalieren möchte, stellt Segregated Witness allerdings eher ein Hindernis dar. Von daher ende ich hier mit gemischten Gefühlen.
Wie sie schon schreiben, man kann nicht alle Transaktionen der Welt in die Blockchain packen.
Punkt. – Das ist eine Tatsache.
Segregated witness beginnt die Entwicklung eines zweiten Kanals, vielleicht einer Sidechain, fur micropayments, von mir aus nenn es lightning-netzwerk…
–
DAS ist ein ursaechliche, duchdachte und langfristige Lösung.
Wenn man schreiben muss, dass etwas eine Tatsache/Fakt ist, ist das nicht sonderlich überzeugend. Fakten sprechen für sich und müssen nicht extra als Tatsachen erkenntlich gemacht werden. Dass nicht alle Transaktionen in die Blockchain passen ist eine These, die aber außer Acht lässt, dass zukünftige Technologie besser sein wird als heutige. Zudem müssen momentan nicht alle Transaktionen in die Blockchain passen, da das Bitcoin-Netzwerk winzig ist und noch weit entfernt von einer Mainstream-Nutzung ist.
Beissen Sie sich bitte nicht an daran fest, dass ich etwas einen Fakt genannt habe.
Um ein Volumen wie Visa zu prozessieren, benötigen wir Blöcke von mehreren Gigabyte. Dies liegt sowohl was CPU, Arbeitsspeicher, Festplatte als auch – und vor allem – Upload angeht, nicht nur ein Stück, sondern meilenweit über allem, was derzeitige Systeme hergeben. Ich wage es stark zu bezweifeln, dass der Fortschritt auf diesen allen Gebieten entsprechend weit mitgeht. Man denke nur einmal daran, dass die Prozessorgeschwindigkeit derzeit beinahe schon stagniert und Quanten/Bioprozessoren weiterhin in weiter Ferne sind. Oder was es für ein Geschieß ist, bis hier in Deutschland einmal ein Infrastrukturprojekt wie Glasfaserkabel angegangen wird.
All das heißt aber nicht, dass wir nicht so weit wie es möglich ist den Bedarf nach Transaktionen onchain decken sollten. Und da ist meiner Meinung nach das LImit noch lange nicht erreicht.
Ich denke vom VISA-Level sind wir mindestens noch 10 bis 20 Jahre entfernt. Was die Rechenleistung für große Blöcke anbelangt, mache ich mir keine Sorgen. Die Berechnung ist gut parallelisierbar und kann somit von mehreren CPU-Kernen gut gepackt werden. Zudem sind Softwareoptimierungen in der Pipeline, die die Effizienz deutlich steigern. Ich betreibe eine Node auf einem Raspberry PI 2 und der wird schon kaum gefordert.
Die Netzwerkkapazitäten werden sich auch deutlich steigern lassen, insbesondere da auch der Bedarf nach schnellen Anschlüssen deutlich steigt in Zeiten von Netflix und Co. Zwar mag der einfache Internetnutzer zu Hause wahrscheinlich eher nicht die schnellsten Anschlussmöglichkeiten erhalten, aber das Bitcoin-System derart zu verkrüppeln, dass theoretisch jeder mit „Dorf-Internet“ eine Node betreiben kann, halte ich für falsch.
Was die Festplattenkapazität anbelangt, so muss man ja nicht alle Transaktionen der Welt auf seinem Rechner speichern. Die eigenen reichen völlig aus und das funktioniert schon heute mittels Pruning sehr gut. Nicht jeder kann und wird eine Full-Node betreiben. Solange man seine eigenen Transaktionen über eine SPV-Node verifizieren kann, ist der einfache Nutzer ausreichend abgesichert.
Danke! Wieder was gelernt 🙂
Wer kann mir mal erklären wie das mit dem Lightning-Netzwerk funktioniert ?
Kommt noch, gemach :/
Da hat sich aber einer eingelesen 🙂 Ehrlicher Respekt.
Irgendwo gab es das Gerücht, dass Segwit, entgegegen erster Behauptungen, nun doch viel schneller verfügbar sein soll, sogar „demnächst“ implementiert werden könnte. Weißt du da was? Quelle: https://bitcointalk.org/index.php?topic=796276.new;topicseen#new (runterscrollen)
Herr Bergmann, ich bin enttäuscht. Sie stellen Thesen hier als Fakten dar, was man als guter Journalist nicht tut.
Zum einen stellen Sie Hardforks als Gefahr dar, was sie aber nicht sind. Hardforks sind die einzige Möglichkeit im Bitcoinnetzwerk für Features zu stimmen. Hardforks sind schlimmstenfalls riskant, wenn keine überwältigende Mehrheit dahinter steht.
Softforks erlauben keine Wahlmöglichkeit. Falls man neue Funktionen, welche durch einen Softfork eingeführt werden, nicht unterstützt, so kann man nicht dagegen stimmen. Die Node, welche man betreibt, wird Transaktionen neuerer Regeln trotzdem akzeptieren und weiterleiten, da sie auch unter den alten Regeln valide erscheinen. Dies schwächt meiner Meinung nach die Sicherheit des Netzwerkes. Zudem verkomplizieren Softforks den Softwarecode ungemein, da diese nur als „dreckige Hacks“ implementierbar sind. Komplizierter Code ist aber schlecht wartbar und ermöglicht so das vermehrte Einschleichen von kritischen Bugs.
Zum zweiten sagen Sie, dass man nicht alle Transaktionen in die Blockchain packen kann. Dies lässt aber außer Acht, dass zukünftige Technologie deutlich besser sein wird als heutige. Heute wird man nicht alle Transaktionen der Welt mit Bitcoin bewältigen können, aber das müssen wir auch nicht, da das Bitcoinnetzwerk noch winzig ist und noch meilenweit davon entfernt ist, Transaktionsraten von VISAs Level zu erreichen. Zukünftige Technologie wird aber diese Möglichkeit bieten können, da bin ich mir sicher.
Das Lightning Netzwerk ist noch Monate, wenn nicht gar Jahre davon entfernt, nutzbar zu sein. Falls es dann irgendwann mal kommt, wird es auch einige Zeit brauchen, bis jeder die Möglichkeiten des Lightning Netzwerks nutzt – wenn es denn überhaupt in der Praxis funktioniert. Ich empfehle hierzu auch diesen Artikel zu lesen:
http://codesuppository.blogspot.de/2016/01/the-lightning-network-reality-check.html
Fassen wir zusammen: Segregate Witness ist noch Monate von der Fertigstellung entfernt und benötigt zudem die Unterstützung des gesamten Ökosystem (alle Wallet-Entwickler müssen ihre Software anpassen). SW bringt nur wenig bezüglich der Skalierung. Das Lightning Netzwerk ist noch nicht einmal am Horizont erkennbar. Währenddessen sind aber bereits jetzt die Blöcke voll und Transaktionen verzögern sich und werden teurer. Dies bewirkt eine Veränderung des gesamten ökonomischen Systems. Die einzige Möglichkeit den Druck aus dem System zu nehmen, stellen momentan nur größere Blöcke dar.
Hallo Jan,
größtenteils stimme ich dir zu – aber ich finde, sowohl SW als auch LN verdienen eine unvoreingenommene Würdigung, die auch die Stärken zeigt, selbst wenn es gute und in diesem Blog oft darestellte Gründe für eine sofortige Erhöhung der Blocksize gibt.
Wie du sagst – eine Hardfork ist sauberer, hält den Code schlanker und gibt dem Netzwerk die Möglichkeit, über ein neues Feature abzustimmen. Aber sie ist auch gefährlicher, da sie das Netzwerk im Endeffekt in ungültig/gültig zerreisst udn es eine – wenn auch kleine – Gefahr gibt, dass man am Ende für eine gewisse Zeit zwei konkurrierende Blockchains hat … was katastrophale Folgen hätte … von daher ist eine Softfork in der Tat sicherer …
Dass nicht alle Transaktionen in die Blockchain passen – dabei bleibe ich, auch wenn ich es schade finde. Die einzige Möglichkeit, langfristig „wirklich“ zu skalieren, wäre es, wenn jeder Node ein Datenzentrum ist. Da es momentan noch keinen Anreiz dafür gibt, einen Node zu betreiben, und (abgesehen von Lightning) auch keiner absehbar ist, halte ich das für extrem unrealistisch.
Aber an sich haben Sie recht. Wie ich geschrieben habe – wenn es ums Skalieren geht, ist SW eher eine Verlegenheitslösung. Und die Blöcke sind derzeit in der Tat voll, weswegen man besser gestern als morgen gehandelt hätte.
SW und Lightning sind tolle Lösungen. Ich bin nur dagegen, alles auf ein Pferd zu setzen, so wie es Bitcoin Core derzeit macht.
Was die Nodes angeht: Zunächst einmal haben natürlich alle Miner ein Bedürfnis, eine Node zu betreiben. Dazu kommen Zahlungsanbieter und Börsen, die auch ein Interesse daran haben, alle Transkationen vollständig zu verifizieren. Vielleicht später auch Versicherungen und Banken, wenn die Blockchain entsprechend nicht nur für monetäre Zwecke genutzt wird. Da kommen dann schon einige Nodes zusammen. Ich las neulich ein Interview (leider weiß ich nicht mehr wo und von wem), wo der Interviewte meinte, dass der Sicherheitsgewinn von bspw. einer Zunahme von 2 auf 3 Nodes in einem Netzwerk deutlich höher ist, als die Zunahme von 500 auf 5000. Die Frage ist, wie sicher muss das Netzwerk sein. Brauchen wir 5000 Nodes, die alle das gleiche machen? Reichen nicht auch 100, um das Netzwerk abzusichern?
Die meisten Nutzer nutzen ja heute schon keine Full-Nodes mehr, sondern verlassen sich auf SPV-Wallets (wie Electrum, Multibit,…) und Webwallets (Blockchain.info, Coinbase,…). Es gibt schlicht kaum Anreize für den normalen Nutzer eine Full-Node zu betreiben.
Vergleicht man das ganze mit dem Email-Protokoll, so könnte jeder seinen eigenen Email-Server betreiben – aber kaum einer tut das. Die allermeisten Emails werden zwischen den großen Email-Anbietern verschickt. Aber ich denke kaum einer wird sagen, dass die Email zu zentralisiert ist.
Zum Schluss nochmal kurz zum Hardfork: Ich mag schlicht diese „Panikmache“ nicht (Sie sind ja nicht der einzige), die vor einem Hardfork betrieben wird. Solange eine ausreichend große Mehrheit hinter dem Hardfork steht, so gibt es kaum Anreize für die anderen Marktteilnehmer, bei der alten Blockchain zu bleiben. Was nützt es einem Miner, wenn er seine Bitcoins nicht auf den Börsen verkaufen kann, weil sie nicht akzeptiert werden? Was nützt es den normalen Nutzern, wenn ihre Transaktionen kaum noch bestätigt werden? Die Minderheit muss sich dem Markt anpassen oder sie wird Verluste erleiden. (Natürlich ist ein Hardfork mit 50/50 Verteilung katastrophal, aber das wird ja nirgendwo forciert.)
PS: Man, das ist wieder ein Menge Text geworden. Sie sehen, das Thema packt mich enorm 🙂
Ich sehe es. Ist ja mittlerweile auch ein hoch-emotionales Thema :/
Sie – du? – hast schon recht. Es ist auch vorstellbar, dass irgendwann nur noch Zahlungsdienstleister, Börsen etc. Nodes betreiben und wir mit ein paar hundert weltweit auskommen und das Netzwerk weiterhin dezentral ist. Ist zwar eine ganz andere Vision als die, die wir heute haben, aber – wer kann schon vorschreiben, welche Vision die richtige ist?
Ich finde auch, dass vor einer HArdfork zu viel Panik ist. Die „Panikmache“ in dem Text stammt nicht von mir, sondern gibt die Argumente der Befürworter von SW wieder. Es stimmt aber, dass in einer Hardfork gewisse Risiken liegen, und wenn man diese vermeiden kann, so die Argumentation, ist es besser als sie einzugehen. Allerdings ist es auch wieder murks, wenn man aus Furcht vor einer Hardfork die richtige Lösung vermeidet und dafür schlechtere, kompliziertere Lösungen hernimmt.
Wenn die Softfork Lösungen sich als nicht sinnvoll herausstellen, kann man ja später immernoch hardforken. Aber ein Hardfork bedeutet ziemlich sicher zwei Arten Bitcoins, von denen vermutlich mindestens einer stirbt. Die Guthaben selbst sind bei einem Hardfork nicht in Gefahr, wohl aber der Wechselkurs.
ich glaube, dass der Wechselkurs eher unter dem aktuellen rumgeeiere leided. Das ganze Drama wird nur wegen der aktuellen Flucht aus Fiat in Cryptos überdeckt. Ein klarer Hardfork mit mindesten 75% ist eine eindeutige Sache. Dann ist die Sache ausgestanden und es gibt keine elendigen Diskussionen. Investoren wollen klare Aussagen, eine Strategie und kein rumgefrickel, wie SW.
Ausserdem: Das nerdige grumgewiesel der Core-Developer ist auch Gift für den Kurs. Irgenwie überzeugen ihre Argumente nicht und die vorgeschlagenen Lösungen tragen höchstens mittelfristig. Also, was ist die Strategie? Wie soll BTC die Anforderungen in 3+Jahren erfüllen? Irgenwelche klaren und verlässlichen Ansagen?
Sorry, das aktuelle Verhalten von Core und der dazugehörigen Communitiy ist totaler Kindergarten und imho werden die wichtigen Investoren zu einem Coin mit tragbaren Konzept wechseln. Wer solche Nummern, wie die Zensur eines der grössten Anbieters bei Bitcoin.org in seiner Rolle als Core-Developer nicht widerspricht, hat in meinen Augen jedes Vertrauen verloren.
Da sich scheinbar selbst nach dem Warnschuss von Hearn nichts an der grundlegenden Einstellung geändert hat, ist für mich BTC gestorben. Als Proof of Concept war BTC der absolute Winner! Aber scheinbar sind die Verantwortlichen nicht fähig aus Fehlern zu lernen.
Siehe Ethereum: Selbst mit den aktuellen finanziellen Problemen machen die einen wesentlich professionelleren Eindruck.