Core veröffentlich Version 0.12.1

Wenn Core eine neue Version des Standardclient veröffentlicht, ist dies in der Regel eine erfreuliche Nachricht. Nach dem “Monster-Release” von Core 0.12 folgt mit 0.12.1 ein auf den ersten Blick kleines Update, das aber einige Softforks implementiert und insgesamt von geradezu monströser Komplexität ist. Ein Versuch, zu erklären, was die in 0.12.1 implementierten BIPS 9, 68, 112 und 113 bedeuten.

Wenn man sich die Release-Notes zu Core 0.12.1 anschaut, wird man dürre Beschreibungen der BIPs finden, die für die wenigsten Menschen verständlich sein sollten. Um ehrlich zu sein, finde ich dieses Update extrem verwirrend, da es Änderungen einpflegt, die mir nicht unwichtig scheinen, aber ziemlich intransparent dokumentiert sind. Um zu verstehen, was in Core 0.12.1 passiert, muss man den Links zu den BIPs folgen und diese studieren. Ich selbst verstehe im besten Fall nur einen kleinen Teil. Letztens Endes scheint Core 0.12.1 jedoch eine Kaskade von Softforks zu sein, die die Grundlagen schaffen, um das Lightning-Netzwerk zu implementieren.

Zunächst wird BIP9 eingeführt. Dies ist ein neuer “Entfaltungs-Mechanismus” (deplayment mechanism), um Softforks zu aktivieren. Softforks meinen Forks, die im Gegensatz zu Hardforks abwärtskompatibel sind, d.h. Knoten, die noch die alte Version benutzen, sind nach einer Softfork weiterhin kompatibel mit dem Rest des Netzwerkes, auch wenn sie nicht mehr alle Features nutzen und alle Transaktionen verifizieren können. Um eine Softfork zu aktivieren, muss eine bestimmte Prozentzahl der Miner – in der Regel 95% – ihre Zustimmung über die Versions-Felder in den Blöcken geben. BIP9 ändert nun die Semantik im Version-Field eines Blocks und erlaubt so die parallele Abstimmung über mehrere Softforks. Ich habe mal gehört über bis zu 28 Softforks gleichzeitig, bin mir aber nicht sicher.

Core möchte nun BIP9 nutzen, um gleich drei Softforks zu aktivieren. BIP68, BIP112 und BIP113. BIP68 und BIP112 sind wohl essenziell für komplexere Skripte und Verträge, wie sie das Lightning-Netzwerk benötigt, und BIP113 gleicht ein Problem, das durch diese Verträge entsteht, aus. Wenn ich es richtig verstehe.

Beginnen wir mit BIP68. Über dieses schreibt Core in den Release Notes, es führe “relative lock-time consensus-enforced semantics” des Sequenze-Nummer-Feldes ein. Wenn das, was Ihnen datz einfällt, vor allem ein “Hääää?” ist, kann ich Sie beruhigen: Mir und vermutlich 99% der Bitcoin-Community geht es genauso. Also:  Mit BIP68 soll man sogenannte nLockTime Transaktionen schreiben dürfen, die erst von Minern in Blöcke gebracht werden können, wenn die Outputs dieser Transaktion eine bestimmte Anzahl von Blöcken tief liegen. Zumindest verstehe ich es so. Dies ermöglicht es bi-direktionale Payment-Channels einzurichten, wie sie für das Lightning-Netzwerk und BIP112 notwendig sind.

Dementsprechend ergibt die BIP112 Softfork mit BIP68 Sinn. Sie aktiviert mit einer Softfork OP_CHECKSEQUENCEVERIFY. Und das bedeutet? Dieses CSV abgekürzte Update definiert einen bestehenden Code im Script-System des Bitcoins um, so dass unter bestimmten Umständen die Ausführung des Scripts eine Fehlermeldung auslöst. Auf diese Weise können Scriptpfade implementiert werden, die nur nach Ablauf einer bestimmten Zeit aktiviert werden können. Wenn BIP68 mit nLockTime Transaktionen einfriert, friert BIP112 die Skripte von Transaktionen ein. So kann das Skript beispielsweise sagen, dass ein Output erst ausgegeben werden kann, wenn eine Transaktion seit 100 Blöcken bestätigt ist. Zumindest verstehe ich es so. Auch dies hilft, das Lightning-Netzwerk zu ermöglichen.

BIP113 hingegen schwächt “perverse Anreize” für Miner, die durch das Einfrieren von Transaktionen entstehen. Denn aufgrund recht komplizierter Gründe kann es für Miner lohnenswert sein, ihre Zeitangaben für die Blockheader in die Zukunft zu verlegen, um zeitlich eingefrorene (locktimed) Transaktionen mitzunehmen, obwohl diese erst in beispielsweise 2 Stunden gemined werden dürften. Indem BIP113 per Softfork neue Konsens-Richtlinien für die Blockheader einführt, kann dieser “perverse Anreiz” geschwächt werden.

Diese Kaskade von Softforks scheint vor allem dazu zu dienen, die Grundlagen für das Lightning-Netzwerk zu schaffen. Daneben ist noch bemerkenswert, dass das Alert-System, also der interne Messenger von Core, ab 0.12.1 standardmäßig abgeschaltet wird. Das Alert-System dient dazu, in Krisenfällen eine Nachricht an alle Teilnehmer des Netzwerkes zu schicken. Die Schlüssel für das System haben Satoshi Nakamoto, Gavin Andresen, Theymos und eventuell Mark Karpeless. Ob das Alarm-System abgeschaltet wird, um Gavin Andresen daran zu hindern, im Falle einer Fork die User zu benachrichtigen, oder weil Mark Karpeless seine Schlüssel womöglich an die japanische Polizei übergeben hat, ist nicht bekannt.

Wie so oft, wenn es tief in die Technik geht, möchte ich diesen Beitrag mit der Bemerkung abschließen, dass ich Laie bin und nur versuche, mir aus Dingen einen Reim zu machen, die ich bestenfalls zu Bruchteilen verstehe. Für Fehler entschuldige ich mich präventiv und fordere Sie als Leser auf, sich die BIPs und Release Notes selbst zu Gemüt zu führen.

About Christoph Bergmann (959 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

18 Comments on Core veröffentlich Version 0.12.1

  1. abgeschalten => abgeschaltet

    Und “Entfaltungs-Mechanismus” kommentiere ich gar nicht erst.

    Ich finde deinen Blog toll und sehr hilfreich, aber diese Stilblüten sind manchmal … erwähnenswert! 😉

    • Humm … Freitag-Nacht und ich denke über Worte nach … dein letzter Satz wärmt mir das Herz … Entfaltungs-Mechanismus ist in Gänsefüßchen mit englisch-Original in Klammern, weil ich die Übersetzung selbst suboptimal finde, mir aber nichts besseres einfiel … und “abgeschaltet” ist korrigiert, dafür vielen Dank!

  2. Nattydraddy // 15. April 2016 at 20:33 // Reply

    Guter Artikel, nur die letzten bei Absätze kann man weglassen. Der letzte Absatz beginnt mit “möchte ich dieextrem verwirrend dokumentiert sindsen Beitrag mit der Bemerkung abschließen”. Spätestens hier lest man eh nicht mehr mit wegen der fielen Rextshreipfeler.

    Der Absatzt davor beginnt gut (Diese Kaskade von Softforks scheint vor allem dazu zu dienen, die Grundlagen für das Lightning-Netzwerk zu schaffen.)
    Nur danach: “Daneben ist noch bemerkenswert, dass das Alert-System, also der interne Messanger von Core, ab 0.12.1 standardmäßig abgeschalten wird”
    Instant Messaging wird durch einen Messenger betrieben, mit 2 “e” geschrieben. Danach die Vermutungen über Satoshi Nakamoto, Gavin Andresen, Theymos und eventuell Mark Karpeless bringen kein Leser weiter. Außer denjenigen, die schon alle 100 Verdächtigungen über LN kennen.

    • hinzu kommt, dass ich (obwohl bavarophil) für “abgeschalteT” plädiere 😉

    • Guter Artikel, nur die letzten bei Absätze kann man weglassen. Der letzte Absatz beginnt mit “möchte ich dieextrem verwirrend dokumentiert sindsen Beitrag mit der Bemerkung abschließen”. Spätestens hier lest man eh nicht mehr mit wegen der fielen Rextshreipfeler.

      Ja, stimmmt. Da sind ein paar Worte unnötig und dementsprechend gelöscht. Danke!

      Der Messanger wurde verdientermaßen zu einem Messenger (auch wenn das Wort weiterhin sehr blöd aussieht)…

  3. Schon klar, zuerst kommt Lightning und erst danach Segwit. Die haben wohl Angst dass nach Segwit auf Classic gewechselt werden könnte…

    • Nattydraddy // 16. April 2016 at 3:21 // Reply

      Das Lightning Netzwerk wird erst nach SegWit kommen. Ohne SegWit sind Transaktionen “Malleable” und damit ungeeignet für das Lightning Netzwerk. Aus dem Whitepaper von LN, Appendix A: Resolving Malleability
      In order to create these contracts in Bitcoin without a third party trusted
      service, Bitcoin must fix the transaction malleability problem. If transac-
      tions can be mutated, then signatures can be invalidated, thereby making
      refund transactions and commitment bonds invalidated. This creates an
      opportunity for hostile actors to use it as an opportunity for a negotiating
      tactic to steal coins, in effect, a hostage scenario.

      Leider ist das Whitepaper von LN 59 Seiten lang und noch ein Provisorium. Dementsprechend habe ich keine Lust, es durch zu lesen. Dafür haben wir ja Christoph Bergmann ❤
      Leider hat er den letzten Absatz nicht gelöscht und "fordert Sie als Leser auf, sich die BIPs und Release Notes selbst zu Gemüt zu führen."
      Also wenn Bitcoin so kompliziert ist, ist das nur was für Studenten. Man könnte meinen SegWit und LN wurden nur eingeführt um die ungewaschenen Massen von Bitcoin fernzuhalten. Ich finde noch nicht mal jemanden der mir SegWit und LN erklären kann.

      • Hehe .. steht seit Monaten auf meiner To-2-Liste … Mit SegWit bin ich schon relativ weit, LN beginne ich gerade, im Ansatz zu verstehen. Aber warum man die hier beschriebenen Änderungen braucht, damit LN funktioniert, liegt noch weit jenseits meines Horizonts.

        Ich hoffe, ich kann euch in den kommenden Wochen den fälligen Lightning-Artikel liefern.

  4. Edgar Selzer // 16. April 2016 at 21:15 // Reply

    Sehr geehrter Herr Bergmann, wenn Sie die erwähnten Aspekte der Änderungen im Code nicht in allen Details verstehen, warum schreiben Sie nicht einfach eine Mail an die Autoren mit der Bitte, eine kurze und prägnante Erklärung zu liefern. Ich glaube, dass diese dazu doch sicher bereit wären.
    Ansonsten Gratulationen zu Ihren interessanten Beiträgen!
    Herzliche Grüsse
    Edgar Selzer

  5. Das Ende der Neutralität naht und wenn Lightning kommt, dann kann man davon ausgehen, dass es nicht lang dauern wird und die Mehrzahl der Tx ( die ja nunmal aus geringen Beträgen besteht ) über Lightning abgewickelt werden. Am Ende steht da lediglich noch ein Bitcoin-Gerüst als Settlement, doch die Tx selbst finden außerhalb der Blockchain statt.
    Quasi erodiert man Bitcoin damit zu einem Settlement-Netzwerk bei denen sich die “Kleinen” es nicht mehr leisten können auf der Bitcoin-Blockchain zu transferieren und lediglich noch die “Großen” die volle Sicherheit der Bitcoin-Blockchain genießen dürfen.

    Die Geldeliten werden sich darüber sicherlich freuen.

  6. Lightning ist die schrittweise Disqualifizierung des Bitcoin als Alternative zum Geld. Sollte dies so kommen, so werde ich meine Bitcoins besser wieder gegen Geld tauschen oder auf andere Coins überwechseln.

1 Trackback / Pingback

  1. Das Lightning-Netzwerk – BitcoinBlog.de – das Blog für Bitcoin und andere virtuelle Währungen

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