Segregated Witness Explained [Segwit] (Litecoin/Bitcoin) - YouTube

Segregated Witness Erklärt. Ein Dankeschön an Luke Dashjr & Tom Zander. Verfasst von Franklyn. Deutsche Übersetzung von Bay6 Translations, Maik Beyer.

Segregated Witness. (Abgesonderter Zeuge)

Es ist als Bitcoin's großartige Lösung, zum Beheben einer Vielzahl an Problemen, gefeiert worden.

Von der Behebung nachträglicher Änderungen an Transaktionen bis hin zur Skalierung.

Allerdings nicht, ohne den Widerstand von 'Minern' gezürnt zu haben,

die momentan dessen Aktivierung bedrohen, auf Grund geäußerter Sorge, um die technische und wirtschaftliche Komplexität.

Sie hoffen eine bessere Lösung finden zu können.

Bei "Segregated Witness" oder auch "Segwit" genannt, handelt es sich um eine tiefgehende Änderung,

welche die Struktur, der Blöcke auf der "Blockchain" verändert.

Blöcke sind aus mehreren Bestandteilen zusammengesetzt, diese sind:

Die Block-Kopfzeile. Sie enthält die Version des Blocks, den Hash des vorherigen Blocks, Hash Ursprung,

Zeitstempel, Ziel und die Nonce. Hinzu kommt der Transaktions-Zähler und schließlich eine Auflistung einzelner Transaktionen.

Ein Block ist im Moment auf eine Größe von 1 Megabyte begrenzt und jeder Bestandteil nimmt etwas davon in Anspruch.

Den Großteil dieses Platzes, weit über 99 Prozent, ist aufgehoben für die Transaktionen,

die wiederum ihre eigenen Bestandteile haben, und zwar Eingänge und Ausgänge:

Eingänge sind wo die Geldeinheiten herkommen und Ausgänge wo sie hingehen.

Die Signatur benötigt dabei den meisten Platz, sie befindet sich innerhalb der Eingänge.

Diese Signatur macht 65 Prozent des Platzbedarfs, innerhalb einer Transaktion, aus und ist Beweis dafür,

dass der Versender steuert, wie hoch der zu sendende Betrag sein soll.

Segregated Witness sondert und verschiebt diese Signatur von dem Eingang in ihre eigene Struktur, auch "Zeuge" genannt.

Dies macht eine Berechnung der Transaktions ID viel vorhersehbarer und verhindert in manchen Fällen,

jedoch nicht allen, die nachträgliche Änderung von Transaktionen, falls eine Person versuchen sollte die Transaktions ID zu ändern.

Außerdem ermöglicht dies eine Erweiterung der Blockgröße, von einem Megabyte. zu etwas unter 4 Megabytes.

Jedes Byte, in einem "Zeugen", in einer Segwit Transaktion, zählt als eine Einheit,

während jedes andere Byte aus der Transaktion als 4 Einheiten zählt.

Da die Blöcke jedoch nicht aus 100 Prozent dieser "Zeugen"-Daten bestehen und noch weitere

Erhöhungen in der Datengröße, bei Segwit Transaktionen hinzukommen, erreicht man niemals 4 Megabytes.

Stattdessen landet man effektiv bei einer Obergrenze von 2 Megabytes oder doppel BB-Code Kapazitäten.

Das Entfernen der Signaturen, aus den Transaktions-Eingängen, führte allerdings zu Inkompatibilitäts-Problemen.

Der Hash-Ursprung, aus der Block-Kopfzeile, erlaubt es dem Block, Transaktionen zu bestätigen,

ohne den Hauptteil, also die Transaktionsinformationen, zu kennen.

Sie entsteht, indem man jede Transaktions-ID des Blocks nimmt und sie zweifach zerlegt und zu einem "Hash-Baum" zusammenführt.

Dies geschieht so lange, bis nur noch eine Zahl übrig bleibt. Der Hash-Ursprung.

Die Daten des "Zeugen" sind dann zwar nicht mehr teil der Transaktions ID, müssen allerdings immer noch in der Transaktion enthalten sein.

Sonst wird der Block nicht gültig sein.

Daher benötigt man einen gesonderten Hash-Baum, für die kompletten Daten der Transaktion.

Indem man dies an die erste Transaktion anhängt, lassen sich die Daten des Zeugen erfolgreich mit der Transaktion verbinden.

Und somit ist Segregated Witness (Abgesonderter Zeuge) auch Abwärtskompatibel.

Auf Grund dieser neuen Blockstruktur, werden ältere Knoten diese weiterhin als gültig anerkennen,

trotzdem, wie mit jeder Aktualisierung von Bitcoin selber, werden diese Blöcke nicht vollständig zu verstehen sein.

Jedoch werden neue Segwit Knoten in der Lage sein, diese Blöcke ordnungsgemäß bestätigen zu können,

da sie mit den neuem Regelwerk vertraut sind und wissen wie diese neue Blockstruktur zu erkennen ist.

Segregated Witness wird durch einen "Soft Fork" implementiert, dass bedeutet, 95 Prozent aller "Miner" müssen Segwit kompatible Software am laufen haben, damit es aktiviert werden kann.

Wir wissen zwar nicht wie viele "Miners" Segwit am laufen haben, wenn wir uns aber auf diese Statistiken beziehen,

sehen wir, dass lediglich 85% des Netzwerks "Core" Knoten benutzen, welche als Hauptbefürworter von Segwit gelten.

Dies hat zu Prognosen vieler Leute geführt, die keinen erfolgreichen Konsens für Segwit sehen.

Auf der anderen Seite vorsichtig optimistische Leute, die einen Konsens zur Segwit Aktivierung für Ende des Jahres oder 2017 vorhersehen,

denn dessen Befürwortung wird momentan unterschätzt.

Es ist nur fair darauf hinzuweisen, dass es sich bei Segwit, sehr wohl, um eine tiefgehende Änderung handelt,

doch es legt, im Endeffekt, den Grundstein für weitere Änderungen.

Und das nicht nur bezüglich nachträglicher Änderungen und der Netzkapazität.

Wegen dieser tiefgreifenden Änderungen, gibt es eine Reihe von Risiken, darunter:

Erstens, die Einführung von Programmfehlern in das System, entweder durch Fehler in der Entwicklung oder bei der Implementierung.

Es besteht ebenso die Möglichkeit eines Benutzerfehlers, durch Verwirrung in der Benutzung dieses Systems.

Zusammen mit Wechselwirkungen in der Bitcoinumgebung, wo es möglicherweise schon feste Annahmen gibt,

gegen die, durch diese Aktualisierung, dann verstoßen werden könnten.

Zweitens, Transaktions-Gebühren. Sehr häufig ist es heutzutage der Fall, dass Nachfrage das Angebot übersteigt.

Als solches erhalten diejenigen, die mehr bezahlen, Priorität gegenüber denen, die weniger zahlen.

Mit der Zunahme an Netzwerkkapazität, zumindest kurzfristig, könnten es eine Verringerung der Transaktions-Gebühren geben.

Daraus folgt, weniger Verdienst für "Miner" und weniger Sicherheit im Netzwerk,

sollten sie nicht mehr in der Lage sein mit Profit zu "minen" und dazu gezwungen sein, einige Maschinen vom Netz zu nehmen.

Obwohl es sich vermutlich so entwickeln wird, dass die Transaktions-Gebühren entweder weiterhin steigen oder zumindest gleich bleiben,

da sich die zusätzliche Kapazität, geboten von Segwit, zügig durch die stetige Nachfrage decken wird.

Drittens, Serialisierung.

Transaktionen und Blöcke sind momentan so angeordnet, dass ihre Informationen später neu aufgebaut werden können, falls notwendig.

Dies hilft auch dabei, die Blockchain hinzuhallten und erneut Daten über das Netzwerk zu übertragen.

Segwit geht die Sache an, indem es eine Nachricht an die Basis Transaktion des Blocks hängt, welche 32 bis 47 zusätzliche Bytes in der Transaktion verursacht.

Und in Abhängigkeit von der Transaktionsart, weitere -1 bis 19 Prozent, an Informationen pro Transaktion, anhängt.

Viertens, Block-Bestätigungszeit

Die Zeit, zur Bestätigung von Blöcken, wird sich ebenfalls erhöhen, da mehr Rechenleistung zum

Berechnen, von den neuen Segwit Transaktionen und den neuen Zeugen-Daten des Hash-Ursprungs, benötigt wird.

Allerdings sollte dies zu vernachlässigen sein und den Block, um höchstens 7 Kilobyte, erweitern.

Also etwa eine Zehntel Sekunde auf üblicher Hardware.

Fünftens, Technische Verschuldung

Segwit könnte möglicherweise, zur bereits vorhandenen Technischen Verschuldung von Bitcoin, beitragen.

Technische Verschuldung bezieht sich auf Programmcode, der zwar heute Probleme behebt, jedoch in der Zukunft schwere Probleme verursachen könnte,

es sei denn man schreibt ihn neu, was die Entwicklungszeit verlangsamt.

In eingen Fällen bliebe es auch permanent erhalten, als ein schlechtes Design,

da eine spätere Änderung dazu führen kann, dass die Nutzer zugriff auf Ihre Geldeinheiten verlieren würden.

Sechstens, Größere Blöcke (UTXO) haben eine schneller wachsende UTXO Datenbank, bzw. nicht getätigte Transaktionen zur Folge.

Diese Datenbank ist wichtig, da es die Knoten vollständig bestätigt und Transaktionen überprüft.

Wenn ein Eingang nicht in der Datenbank vorhanden ist, dann bedeutet es, dass die Transaktion nicht gültig ist.

Es ist zu erwarten, dass die UTXO Datenbank auch ohne Segwit wachsen wird. Sie hat im Moment eine Größe von 1,5 Gigabyte bzw. 10 Gigabyte unkomprimiert im Speicher.

Mit Segwit würde diese Datenbank doppelt so schnell wachsen. Das klingt nach keinem so großem Problem,

bis man sich darüber Gedanken macht, wie jeder sich diese Hardware, zum Speichern, besorgen muss.

Deswegen kann es möglicherweise langfristig, für viele Nutzer, unmöglich sein, diese Informationen zu speichern und zu der größten Zentralisierung im Netzwerk führen.

Siebtens, Langfristige Skalierung.

Während Segwit einmalig die Netzkapazität erhöht, handelt es sich nicht um eine langfristige oder mittelfristige Lösung zu dem Skalierung-Problem.

Es ermöglicht allerdings eine Layer-2 Netzwerklösung und behebt einen schwerwiegenden Quadratisch wachsenden Hash-Skalierungs Bug.

Dies könnte zukünftige negative Auswirkungen in der Entwicklung, im Bereich der Skalierung, entgegenwirken, sobald sie auftauchen.

Begutachtungen und Tests sind selbstverständlich, von vielen Personen und Gruppen, durchgeführt worden, um Probleme in der Veröffentlichung zu finden.

Die Core Entwickler sind sehr offen darin gewesen, all diese Probleme, auf ihrer Seite, aufzuführen und wie sie planen jede einzelne dieser anzusprechen.

Unabhängig davon, wie unwahrscheinlich sie sein mögen.

Jedoch existieren immer noch Core-Entwickler und bekannte Personen, die in dieser Angelegenheit auf der einen oder anderen Seite stehen

und jede dieser Personen hat ihre eigene Begründung, für die vertretenden Ansichten.

Einschließlich Jameson Lopp, von BitGo, der argumentiert, dass das Netzwerk so zu laufen hat, wie eine gut geölte Maschine.

Andere wollen Leute, die hartnäckig auf Segwit beharren, zurücklassen und stattdessen keine Abstimmung daraus machen,

sondern eine Methode zur Aktualisierung wählen, die sich nicht Rückgängig machen lässt, auch bekannt als "Hard Fork".

Obwohl es noch viele weitere Gründe gäbe einen "Hard Fork" über einen "Soft Fork" zu wählen, in dieser Situation.

Dennoch ist es eine gemeinsame Überzeugung, unter einigen Entwicklern, dass keine Einzelperson oder Gruppe das Recht hat, solch eine Änderung im Netzwerk zu erzwingen.

Ein "Hard Fork" hätte dies zur Folge, es sei denn, eine erhebliche Anzahl von Nutzern würde dieser Änderung zustimmen.

Bitcoin Entwickler Jeff Garzik argumentiert, dass Segwits Beharrlichkeit, sich über einen "Soft Fork" einzuführen,

zu einem übermäßig komplexen System führt, welches nicht genügend Vorteile für die Nutzer bietet.

Demgegenüber argumentiert Bitcoin Entwickler Luke Dashjr, dass ein "Hard Fork" für Segwit, nur dann eine deutliche Verbesserung darstellt,

wenn es vorhandene "Wallet"'s inkompatibel macht, inklusive der Vernichtung aller Bitcoins, die möglicherweise noch im Netzwerk festhängen, bis nach eines geplanten "Hard Forks".

Es gibt selbstverständlich Alternativen, an denen gearbeitet wird.

Besonders anzumerken wären hier "Flexible Transaktionen" oder das "Bitcoin Verbesserungsprotokoll 134" von Tom Xander.

Wiederum nicht ganz ohne Kritiker, aber auch nicht ganz ohne Befürworter. Wir beschäftigen uns mit diesem Thema eventuell ein anderes Mal.

Sollte Segwit letztendlich Probleme in dessen Unterstützung haben, kann es sich eher als eine mögliche Antwort für Bitcoin's Probleme erheben.

Und dann gibt es noch den Vorschlag, Segwit so umzufunktionieren, dass man die Änderung der Blockgröße außen vor lässt und sich auf willkommenere Änderungen konzentriert.

Die Abstimmung über Segwits Implementierung sollte vom 18. November an beginnen. Von da an hat es ein Jahr zeit einen Konsens zu finden.

Wenn sich in dieser Zeit kein Konsens finden lässt, wird Segwit, in dieser Art und Weise, nicht aktiv

und das Bitcoin-Netzwerk würde sich in der gleichen Position, wie vor einem Jahr, wiederfinden. Jedoch nun, mit der Suche nach einer neuen Lösung.

Einen recht herzlichen Dank an Luke Dashjr von "Bitcoin Core" und Tom Zander von "Bitcoin Classic", für die Hilfe beim Schreiben dieses Videos und den Quellenangaben.

Sie waren eine große Hilfe, auch wenn sie zwei Seiten der gleichen Münze repräsentieren. Dennoch wusste ich, deren Einsichten, sehr zu schätzen zu wissen.

Sie können Verlinkungen zu denen, als auch anerkannten Projekten in der Beschreibung unten finden.

Darunter "Bitcoin Knots", bei der es sich um Luke's Version von Bitcoin handelt, mit seinen eigenen Verbesserungen.

und Tom's "Flexibles Transaktionen Modell", sowie alle Quellen dieses Videos.

Werfen Sie bitte einen Blick darauf, Abonnieren Sie uns und wir sehen uns beim nächsten Mal wieder.