Wie SegWit ein Netzwerk im Netzwerk erschafft

Uniform: Schaufenster Calvin Klein Mönckebergstrasse. Bild von Klaus Friese via flickr.com. Lizenz: Creative Commons

Es wurde ja schon viel Gutes über Cores Release 0.13.1 und die Vorteile von SegWit geschrieben. Diesmal stelle ich ein weniger bekanntes und weniger positives Feature von SegWit vor: Ein 0.13.1 Node bevorzug die Verbindung zu anderen 0.13.1 Nodes. Aus diesem Grund meint Peter Todd auch, dass die SegWit Softfork ähnliche Eigenschaften hat wie eine Hardfork. 

Einen Node zu starten, bedeutet, sich mit einem Netzwerk von Nodes zu verbinden. Das ist ein wenig so, wie wenn man in eine fremde Stadt zieht und sich dort Freunde sucht. ;ithilfe eines öffenlichen DNS-Seed findet der Knoten seine ersten Kontakte. Die erzählen ihm dann die Adressen ihrer peers, und er verbindet sich mit diesen. So baut sich der Node nach und nach ein Netzwerk von Freunden auf, um die Blockchain herunterzuladen und Transaktionen zu propagieren.

In der Regel freundet sich ein Knoten mit einer Vielzahl verschiedener Knoten an. Knoten aus alle Ländern dieser Erde, neue Knoten, alte Knoten, Knoten verschiedener Implementierungen von Bitcoin, Core-Knoten, BitcoinJ-Knoten, Classic-Knoten, Unlimited-Knoten … In einer idealen Welt repräsentiert die Liste von Verbindungen eines Knoten die mehr als 100 verschiedenen Implementierungen des Protokolls, die das Bitcoin-Netzwerk derzeit bevölkern.

Multikulti rules: Eine Liste mit den Peers, mit denen mein Knoten normalerweise Kontakt aufnimmt.

Multikulti rules: Eine Liste mit den Peers, mit denen mein Knoten normalerweise Kontakt aufnimmt.

Der Knoten, der gelernt hat, einen Unterschied zu machen

All das ändert sich, wenn man einen Knoten mit der neuesten Version von Core, 0.13.1, startet. Dieser Release kann das lang erwartete Upgrade SegWit aktivieren. User, die ihn benutzen, werden jedoch erleben, dass der Knoten fortan Schluss mit der Vielfalt macht. Er ändert sein Vernetzungs-Verhalten und sucht nur noch Freunde, die so sind wie er. Zwar akzeptiert der Knoten weiterhin eingehende Verbindungen von anderen Knoten, doch bei der Suche nach anderen Knoten – den ausgehenden Verbindungen – toleriert er nur noch 0.13.1 Knoten.

Manche Knoten sind halt gleicher als die anderen: Sämtliche acht ausgehenden Verbindungen gehen an 0.13.1 Knoten.

Manche Knoten sind halt gleicher als die anderen: Sämtliche acht ausgehenden Verbindungen gehen an 0.13.1 Knoten.

SegWit hat viele großartige Eigenschaften, von denen die Erhöhung der Kapazität nur eine ist. Mir persönlich gefällt die Beseitigung der Anreize, die Blockchain mit vielen outputs zu verstopfen, vielleicht am besten. Oder dass SegWit per Softfork eine Erhöhung der Kapazität ermöglich.

Die Präferenz beim Verbinden gehört jedoch nicht zu erfreulichen Eigenschaften. Wenn ein SegWit-Knoten nur zu anderen SegWit-Knoten verbindet, dann wird dies bei steigender Verbreitung von 0.13.1-Knoten dazu führen, dass mehr und mehr nicht nur die ausgehenden, sondern auch die eingehenden Verbindungen von 0.13.1 Nodes belegt werden. Schließlich ist jede ausgehende Verbindung des einen Nodes die eingehende Verbindung eines anderen. Es bildet sich ein Netzwerk im Netzwerk, das immer weniger Kontakt zu den anderen Teilen des Netzwerks hat.

Das ist nicht nur problematisch, wenn man aus ideologischen Gründen meint, ein Knoten solle wie der andere sein. Es ist auch problematisch, weil es das Risiko birgt, das Netzwerk zu partitionieren und womöglich Sybill-Angriffe zu vereinfachen. Da all dies nichts ist, was im allgemeinen erwünscht ist, sollte man erwarten, dass es ernsthafte Gründe dafür gibt, warum sich die Knoten so verhalten.

Und ja, die gibt es.

Paritionieren, um die Partitionierung zu verhindern?

Ein Grund kann man in den Release Notes auf bitcoincore.org finden. Hier erklären die Core Entwickler, dass SegWit als Softfork einige spezifische Risiken mit sich bringt. Eine Softfork bedeutet, dass nicht jeder Node upgraden muss, wie bei einer Hardfork, sondern nur jeder Miner, während das Upgrade der Nodes freiwillig bleibt. Wer will, trägt das Extra-Päckchen, wer nicht will, lässt es. Dies ist eines der stärksten Argumente, um die Kapazitätserhöhung per SegWit durchzuführen. Aber es birgt auch das Risiko, dass, wie Core erklärt, “ein schlecht gemachtes Upgrade ein Scheitern des Systems in verschiedene Arten verursachen kann.”

Ohne näher ins Detail zu gehen, erklärt Core, dass dies unter anderem dadurch vermieden wird, dass man ein Netzwerk im Netzwerk aufbaut: “Eine signifikante Arbeit wurde darin investiert, sicherzustellen, dass Peers, die SegWit aktiviert haben, einen stark verbundenen Subgraphen des Bitcoin P2P Netzwerkes bilden. Dies beinhaltet die Bereitstellung eines speziellen Service Bits für diese Knoten und die Präferenz, sich mit solchen Knoten zu verbinden.”

Warum nun was genau, wird nicht richtig klar. Wenn wir jedoch weiter zurückgehen, an den Anfang des Jahres, finden wir eine etwas weitergehende Erklärung von Peter Todd in der Mailing-List: “SegWit Nodes können nicht durch Nicht-SegWit-Knoten synchronisieren und danach vollständig validieren,” so der Entwickler. Nur SegWit Knoten speichern und verifizieren die Signaturen von SegWit-Transaktionen; um vollständig zu synchronisieren, muss sich ein SegWit-Knoten daher mit anderen SegWit-Knoten verbinden. Und Todd weiter: “Wenn einmal die SegWit Softfork aktiviert ist, brauchen Full Nodes die Witness Daten, um zu arbeiten. Dies führt zum Problem, dass, wenn die Miner Adoption hinter der Full-Node-Adoption zurückbleibt, das SegWit-P2P-Netzwerk sich partitionieren kann und den Konsens verliert.”

SegWit als Softfork kommt also mit dem Risiko daher, dass SegWit-Knoten womöglich Probleme haben, die Daten zu finden, die sie brauchen, um sich mit dem Netzwerk zu synchronisieren. Um dieses Risiko zu vermeiden, schlug Todd vor, dass “Peers sich nur mit Peers verbinden, die SegWit unterstützen.” Aus diesem Grund “hat die SegWit Softfork Eigenschaften, die einer Hardfork nicht unaähnlich sind, hinsichtlich des Drucks auf Nodes, ein Upgrade durchzuführen.”

Um vernünftig zu funktionieren, müssen es SegWit-Knoten also bevorzugen, sich mit anderen SegWit-Knoten zu verbinden. Während Peter Todd dies als Lösung vorschlug, um eine Partitionierung des Netzwerkes zu verhindern, droht dies selbst in einer Art Partitionierung zu enden. Zumindest wird es es erschweren, dass sich SegWit-Knoten mit anderen Knoten verbinden, wenn die Verbreitung von SegWit-Knoten zunimmt.

Erste Probleme …

Bisher verursacht dieses Feature nur Probleme für diejenigen, die einen 0.13.1 Node betreiben. Obwoh SegWit noch nicht aktiviert ist, verbinden sich diese Knoten fast ausschließlich mit 0.13.1 Nodes. Ein Nachteil ist, dass diese begrenzte Vielfalt an ausgehenden Verbindungen es schwieriger machen kann, sich mit einem Mining-Pool zu verbinden, wodurch die Bestätigung von Transaktionen verzögert werden kann.

Ein anderer Nachteil ist eine erhöhte Aktivivtät der Festplatte. Einige User beschwerten sich, dass sie seit dem Update auf 0.13.1 “eine nachhaltige höhere IO Rate für das Lesen der Festplatte” sowie “plötzliche Spitzen der IO Rate” bemerkten. Core Entwickler Matt Corallo erklärt, “dass dies von anderen Knoten zu kommen scheint, die die Chain von dir herunterladen, weil sie deinen Knoten aufgrund der Vernetzungs-Präferenz gewählt haben.” Aufgrund dieser (kleinen) Probleme hat ein Entwickler vorgeschlagen, “die Peer Selektion zu fixen, so dass man weiterhin zu nicht-Witness-Nodes Kontakt aufnimmt.” Sein Vorschlag, diese Präferenz der Vernetzung erst nach der Aktivierung von SegWit zu aktivieren, wurde von Gregory Maxwell jedoch abgelehnt: “NACK. Dies untergräbt eine absichtliche Design-Entscheidung. Es ist nicht akzeptabel, dass sich die Netzwerk-Topologie plötzlich verändern, wenn SegWit aktiviert wird.”

Dieses Thema sieht zwar eher wie ein technisches Detail aus. Die damit verbundenen Probleme sind überschaubar, und es scheint eine Notwendigkeit zu sein, um SegWit funktionsfähig zu machen. Allerdings zeigt es auch, dass SegWit nicht eine reine Softfork ist, sondern auch Eigenschaften einer Hardfork hat. Vielleicht könnte man es eine Mischung aus beiden Forks nennen.

About Christoph Bergmann (1006 Articles)
Das Bitcoinblog wird von bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder. Wenn Ihnen das Blog gefällt, freuen wir uns über Spenden an 1BvayiASVCmGmg4WUJmyRHoNevWWo5snqC. Jeder Satoshi wird dazu verwendet, um das Blog besser zu machen. Weitere Infos, wie Sie uns unterstützen können, finden Sie HIER. Gastbeiträge sind ebenfalls willkommen. Meinen öffentlichen PGP-Schlüssel sowie den Bitmessage-Schlüssel finden Sie HIER

11 Comments on Wie SegWit ein Netzwerk im Netzwerk erschafft

  1. Ist doch klar, dass eine full node auch sämtliche SegWit-Extensions beziehen muss und daher die Blöcke und Transaktionen nur von SegWit-unterstützenden Nodes beziehen sollte.

    Es wäre doch eine Schwächung des Netzwerks, wenn eine Node die vollständigen Daten nur noch von 2 statt 8 Peers bezieht.

    Es stimmt nicht ganz, dass 0.13.1 nur zu 0.13.1 verbindet. In der Tat präferiert 0.13.1 nicht Verbindungen zu anderen 0.13.1 Core Nodes, sondern zu Nodes, die ihrerseits Unterstützung für SegWit signalisieren.

    Ansonsten sehe ich in dem Artikel noch einiges, was für mich unter den Begriff Bikeshedding fällt.

    Mit nur ein wenig Böswilligkeit kann man deine ganze Coverage zum Thema Core / Unlimited / SegWit als traurig und kurzsichtig bezeichnen.

    • Hmm … das ist das erste Mal, dass ich etwas schlechtes über SegWit schreibe. Bisher war jeder meiner Artikel zum Thema SegWit durchgehend positiv. Dass ich auch Aspekte erwähne, die ich nicht gänzlich glänzend finde – und dabei auch noch erkläre, weshalb sie notwendig sind – oder auch Alternativen nicht vollständig unerwähnt lasse, sollte sich eigentlich von selbst verstehen. Mit Böswilligkeit hat das nichts zu tun.

    • Nattydraddy // 26. November 2016 at 3:22 // Reply

      “Ansonsten sehe ich in dem Artikel noch einiges, was für mich unter den Begriff Bikeshedding fällt.”

      Man kann SegWit als “Bikeshedding” ansehen. Anstatt die Blöcke größer zu machen, werden die Signaturen in einen “Bikeshed” ausgelagert.

      Solange Wallets noch keine SegWit-Transaktionen erzeugen, bleibt der “Bikeshed” leer. Aber egal, soviel mehr Platz im Block für Transaktionen erhält man eh nicht.

      • Genau darum geht es doch. Hier wird ein Popanz aufgebaut, um mit Bikeshedding einen Nebenkriegsschauplatz zu eröffnen und von der eigentlichen Diskussion abzulenken.

        SegWit, immerhin der (vorläufig) kleinste gemeinsame Nenner zur Kapazitätserhöhung, wird als fauler Kompromiss betrachtet und aus politischen (nicht aus technischen) Gründen blockiert.

      • Wovon lenke ich ab? Davon?

        > SegWit, immerhin der (vorläufig) kleinste gemeinsame Nenner zur Kapazitätserhöhung, wird als fauler Kompromiss betrachtet und aus politischen (nicht aus technischen) Gründen blockiert.

        Das habe ich eigentlich hier
        https://bitcoinblog.de/2016/11/22/die-grosse-wahl-ueber-bitcoins-zukunft-hat-begonnen/
        deutlich thematisiert.

        An sich stimme ich dir nämlich mit diesem Satz zu. SegWit ist ein guter gemeinsamer kleiner Nenner zur Kapazitätserhöhung, und es wird weniger aus technischen denn aus politischen Gründen blockiert.

        Wir können gerne erörtern, welche dies sind. Darüber wollte ich demnächst schreiben. Ich würde sagen
        – Folge des Agreements, weil Miner meinen, von einigen Entwicklern den Code für eine Hardfork in einem Core Release zu bekommen
        – Furcht davor, dass eine Aktivierung von SegWit zum Grund genommen wird, einen Blocksize Increase weiter (für immer) hinauszuschieben.

        Wenn dir noch etwas einfällt, nehme ich es gerne zur Kenntnis.

      • Ich glaube, es geht auch viel um Symbolik.

        Die BU-Miner leisten symbolischen Widerstand. Sie stecken in der Zwickmühle. Am Ende wollen sie nicht als Spalter und auch nicht als Blockierer dastehen und versuchen den Preis hochzutreiben, der eine gesichtswahrende Zustimmung ermöglicht.

        Auch den Core-Ohne-SegWit-Minern geht es um Symbolik. Sie demonstrieren Unabhängigkeit und Selbstbestimmtheit. Sofortige “Gefolgschaft” gegenüber Core käme nicht überall gut an und wäre auch das falsche Signal für diese gespaltene Community.

  2. Wenn sich der Client eingehenden Verbindungen anderer Clients verweigern würde, könnte ich das Problem nachvollziehen. Aber daß sich Core 0.13.1 bei den 8 ausgehenden Verbindungen bevorzugt mit solchen Clients verbindet, bei denen er seine Möglichkeiten voll nutzen kann, scheint mir naheliegend.

  3. ..wes Brot ich ess, des Lied ich sing !?

  4. SegWit ist böse, größere Blöcke sind gut. Verstanden. Weiter im Text.

  5. Screenshot mit Gegenstellen:
    Welchen Client verwendest du bzw. welcher kann die Gegenstellen wie in deinem Screenshot anzeigen? wie kommen ich bei dem Client zu dieser Anzeige?

  6. Andreas Schindler // 7. January 2017 at 8:45 // Reply

    M.E. geht SegWit nicht weit genug. Die letzten paar Tage haben gezeigt, daß die Warteschlange an Transaktionen am überlaufen ist. Mit dem zunehmenden Transaktionsaufkommen wird eine Verdopplung der Blockgröße nicht ausreichen. Vielleicht sollte über eine Hardfork gesprochen werden. D.h. Blockgröße auf 100 MB erhöhen und von mir aus bei der Gelegenheit das Komma um drei Stellen nach rechts verschieben. Damit gäbe es dann 21 Mrd. Coins aber der Bedarf würde ähnlich wie bei Aktiensplits dramatisch ansteigen. Die 100MB erscheinen aus heutiger Sicht viel zu hoch, aber Moores law greift auch hier. a) wären wir dann immerhin bei 700 Transaktionen pro Sekunde (immer noch wenig) und b) ist bei der wachsenden Geschwindigkeit der Sysytemlandschaften wird ein DoS Angriff immer unwahrschienlicher c) die 100 MB müssen nicht sofort befüllt werden, sondern bieten einen Puffer auf das was bald kommen wird. Schaut Euch die Durchschnittsblockgrößen der vergangenen Tage an. Die Blöcke lagen meist bei 950+ KB.
    Nachteil: Die Blockchain wird irgendwann mit einer Geschwindigkeit von 500 GB pro Monat wachsen. Ein geschicktes, konsensorientiertes Archivmanagement wäre sinnvoll (z.B. bezahlen von Archivinstitutionen (ähnlich wie ein Mining reward)) der Rest würde z.B. nur die Blöcke der letzten 12 Monate & die reinen Blockhashes der älteren Transaktionen bewahren.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s