Bitcoin Kernentwickler einigen sich auf Fahrplan für Skalierbarkeit

31 Bitcoin-Kernentwickler haben gestern einen “Fahrplan zur Skalierbarkeit” unterzeichnet. Damit ist, zumindest aus Sicht der Kernentwickler, die Debatte um die Blockgröße beendet.

31 der aktivsten Kernentwickler haben gestern Gregory Maxwells Vorschlag zugestimmt, wie Bitcoin besser skalierbar gemacht werden soll. Damit kann eine für die Kernentwickler zunehmend anstrengende und zermürbende Debatte, ob man die Größe der Blöcke erhöhen soll, als beendet betrachtet werden. Der “Fahrplan zur Skalierbarkeit” entspricht Maxwells Zusammenfassung der zweiten Scaling Bitcoin Konferenz. Er umfasst:

  • Die Nutzung von libsecp256k1 für die Verifizierung, was die Synchronisierung der Clienten um 400% bis 700% beschleunigen und die CPU-Belastung für Knoten deutlich senken soll
  • Eine Soft Fork für Segregated Witness (SG). SG soll die historischen Signaturen aus den Transaktionen entfernen und damit die Kapazität eines Blocks um 50-200% erhöhen. SG soll im Lauf der nächsten 3-6 Monate in den Clienten implementiert werden.
  • Anschließend sollen weitere Updates wie IBLT und Weak Blocks (die die Gefahr von verwaisten Blöcken reduzierem) eingerichtet werden. Diese sind hilfreich, falls künftig eine Erhöhung der Blockgröße notwendig ist.
  • Zunächst jedoch soll es für mindestens 1 Jahr keine Hardfork für größere Blöcke geben
  • Stattdessen sollen noch 2016 sämtliche Updates implementiert werden, die die Einrichtung des Lightning-Nezwerkes ermöglichen. Dieses soll dann der Kanal sein, um kleine und schnelle Transaktionen zu versenden. Lightning ist laut den Kernentwicklern die echte Lösung für das Problem der Skalierbarkeit.

An dieser Stelle muss ich mich entschuldigen. Ich knalle euch Wörter um die Ohren – libsecp256k1, Segregated Witness, IBLT, Weak Blocks, Lightning – die ich selbst nicht vollständig verstehe. Ich werde jedoch diese Begriffe in den kommenden Wochen bzw. Monaten ausführlich erklären.

Eine technische Bewertung dieses Fahrplans kann ich nicht liefern. Dazu fehlt es mir an Kompetenz. Ich freue mich, dass die Kernentwickler zu einer Einigung gekommen sind und nun die Arbeit an einer Lösung den fruchtlosen, die Community trennenden Streit um die richtige Blockgröße ablöst. Zudem ist zu begrüßen, dass die Kernentwickler nicht einfach “nur” die Größe der Blöcke erhöhen, sondern daran arbeiten, so viele Transaktionen wie möglich in die Blöcke zu pressen und den Weg bereiten, um gefahrlos die Größe der Blöcke zu erhöhen, falls notwendig. Man könnte es damit vergleichen, energiesparsamere Technologien zu entwickeln, anstatt ein neues Kraftwerk zu bauen.

Allerdings wird der Fahrplan von vielen kritisiert, und das meiner Ansicht nach nicht ohne Grund. Von allen genannten Updates wird lediglich Segregated Witness (SG) die Kapazität des Netzwerkes erhöhen. Da es für SG noch keinen Code gibt und auch noch keine Tests durchgeführt wurden, ist mit einer Implementierung frühestens Mitte 2016 zu rechnen. Zudem steht noch nicht fest, ob ein so tiefer Eingriff in den Kerncode des Bitcoins wie der Verzicht auf historische Transaktionen nicht unangenehme Nebenwirkungen haben kann.

Betrachtet man zudem, dass Bitcoin bereits jetzt am Limit kratzt und kontinuierlich 5.000 bis 15.000 Transaktionen auf eine Bestätigung warten, ist es zweifelhaft, ob eine kleine Erhöhung der Kapazität Mitte 2016 ausreichend ist. Möglich, dass der enge Flaschenhals bis dahin einen großen Schaden anrichtet. In jedem Fall begrenzt er das weitere Wachstum der Bitcoin-Anwendung. Viel mehr als derzeit wird bis Mitte 2016 nicht möglich sein. Ob das Lightning-Netzwerk am Ende tatsächlich die ersehnte totale, dezentrale und freie Skalierbarkeit bietet und gleichzeitig Betreibern von Bitcoin-Knoten einen finanziellen Anreiz gibt, oder ob es Bitcoin damit zu einer semi-dezentralen Währung wie Ripple macht, kann ich derzeit noch nicht entscheiden. Eventuell schaut ihr euch das Whitepaper an.

Ungünstig scheint mir auch, dass diese Lösung die Verfechter größerer Blöcke vor den Kopf stößt. Nachdem Gavin Andresen zuerst 20 MB und dann 8 MB vorgeschlagen und damit die Unterstützung von unter anderem Mike Hearn, Coinbase, BitPay, Slushs Pool und Bitstamp gefunden hat, brachte Jeff Garzik kürzlich BIP202 mit 2 MB und einem sehr langsamen weiteren Wachstum ins Spiel. Eine Erhöhung der Blocksize auf 2 MB wäre weit unter den ursprünglichen Vorschlägen gelegen, hätte die Zustimmung von Minern, Börsen, Zahlungsdienstleistern und Entwicklern gefunden und wäre ein Entgegenkommen gewesen, das die so stark geteilte Community dringend benötigt hätte. Dieses Zeichen der Einheit und des Kompromisses wurde mit dem Fahrplan leider verschenkt.

Update: Mittlerweile gibt es ein sehr aufschlussreiches FAQ zum Fahrplan. Mich als Autor beeindurckt die Balance zwischen Verständlichkeit und Tiefgang. Bitte unbedingt lesen.

Update 2: Heute erschien Bitcoin Unlimited, ein konkurrierender Client, der auf ein Blocksize-Limit vollkommen verzichtet. Seine Entwickler vertreten die Ansicht, der Markt würde das Limit von selbst setzen. Könnte auch interessant für alle sein, die mit der Lösung von Core nicht einverstanden sind.

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

17 Comments on Bitcoin Kernentwickler einigen sich auf Fahrplan für Skalierbarkeit

  1. das whitepaper würde ich mir gern ansehen, aber der link führt zum coinforum…

  2. Das Lightning-Nezwerk wird in der Zukunft eventuell unabdingbar sein, sind damit nach deren Aussage eine Milliarde und mehr Transaktionen pro Tag möglich. Allerdings kommt man bei dieser Anzahl Transaktionen ebenfalls nicht um eine Erhöhung der Blockgrösse (Whitepaper, Seite 19, Abschnitt 10: Conclusions). Ich glaube dass die Kernentwickler letztlich die Einzigen sind welche die Skalierbarkeit von Bitcoin einleiten sollten, was aber jetzt ansteht ist absolut fahrlässig. Die Blockgrösse bei stetiger Steigerung der Transaktionen bei 1 MB zu belassen, wird zwar zu höheren Transaktionsgebühren führen, aber ganz sicher nicht zu weniger Transaktionen. Es kann zu einem gewaltigen Imageschaden führen, und dies gerade jetzt da Bitcoin fahrt aufnimmt. Eine Erhöhung der Blockgrösse mit Fahrplan über 8 MB wäre gegenwärtig wegen des China-Problems genauso fahrlässig, aber sich irgendwo dazwischen zu einigen…? Miner, Börsen und Zahlungsdienstleister welche allsamt für grössere Blöcke einstehen, sollten jetzt aufstehen und geschlossen die Umseztung eines BIP fordern. Selbst wenn es nur der kleinste gemeinsame Nenner BIP 102 (Erhöhung auf fix 2 MB) ist, oder BIP 248 (die 2-4-8 Lösung). Ansonsten kann der Schuss ganz krass nach hinten losgehen.

  3. Das hier hört sich für einen Bitcoin-Laien wie mich recht schlüssig an:

    http://www.coindesk.com/eating-the-bitcoin-cake/

    Demnach sollte mit der Erhöhung der Blockgröße sehr vorsichtig umgegangen werden (“transaction supply constraint”).

    • Das in dem Bericht vorgetragene Argument ist Käse, denn die Höhe der Gebühren spielt beim Miningreward momentan eine sehr geringe Rolle.
      Zudem greift egal wie hoch oder niedrig die Kosten sind der Markt, d.h. der ineffektive Miner hat unabhängig der Gebühren keinerlei Vor- oder Nachteile, weil je höher die Gebühren ausfallen, desto höher wird die Schwierigkeit steigen um einen neuen Block minen zu können, desto mehr Druck werden die effektiven Miner ausüben bedingt der höheren Margen.
      Am Ende ist und bleibt Mining tendenziell ein Nullsummenspiel, weil die Eintrittsbarrieren vergleichsweise niedrig sind.
      Das ist wie beim Goldrausch damals, die die Gold geschürft haben, haben die Einnahmen in Form von Ausrüstung und Existenzsicherung gleich wieder verprassen müssen. Die die beim Mining profitieren sind am Ende nur die die die Ausrüstung stellen.

  4. Lightningnetzwerk finde ich generell keine gute Lösung, weil damit das Prinzip Bitcoin ausgehebelt wird und Micropayments Beispielsweise nicht rückverfolgbar sind, was letztendlich bedeutet, dass die Offenheit nicht mehr gewährleistet ist und sich diverse funktionale Dinge nicht realisieren lassen.

    Da fände ich Sidechains a la Blockstream eine bessere Lösung, so wie die Entfernung alter Signaturen.

    Eine weitere Möglichkeit wäre aber auch, die Ressourcen unter den Nodes zu verteilen. Nicht jede Node muss die volle Blockchain laden, dies liese sich auch auf mehrere Nodes verteilen und wird übrigens in dezentralen Netzwerken auch getan.

    Generell betrachtet finde ich, betrachtet man Bitcoin viel zu sehr als Alternatives Geld, übersieht dabei aber, dass Bitcoin wesentlich mehr als Geld ist und eine Vielzahl von Aufgaben bereits darüber laufen und von niedrigen Gebühren leben.

    Man sollte daher nicht den großen Fehler machen und anfangen Bitcoin zum Ersatzgeld machen zu wollen und damit Bitcoin in seiner freien Entwicklung hindern, denn damit würde man Projekte wie Ethereum wirklich zum Bitcoin 2.0 aufsteigen lassen.

  5. Daniel Nimtsch // 23. December 2015 at 18:42 // Reply

    Eventuell auch passend zu der Thematik:

    Seit einiger Zeit bemühen sich die Entwickler von “Btcsuite” eine modulare Codebase der “BitcoinCore” Referenzimplementation in “Go” (“C” Alternative von Google) zu etablieren und als Full Node zum Einsatz kommen zu lassen.

    Da sie genau der Referenzimplementation von Bitcoin folgen, müssen sie auch zwangsläufig Fehler im Code 1:1 abbilden und halten sich mit kleinen Verbesserungen zurück um einen Hard Fork der Blockchain zu vermeiden, welcher durch den Einsatz von “Btcd” aus der “Btcsuite” ausgelöst werden könnte.

    Um den Fortschritt in der Entwicklung von Bitcoin zu befruchten und positive Impulse durch Anwendung von konzeptionellen Verbesserungen, welche die BitcoinCore Entwickler dem System nicht aufbürden möchten, zu liefern wollen sie eine Art Proof-of-Concept in Form von “Degred” im Januar 2016 starten.

    Das primäre Ziel scheint tatsächlich nicht die Etablierung eines weitereren Altcoin zu sein, sondern Mängel des Bitcoin-Systems aufzuzeigen und durch proaktives Vorgehen praxiserprobte Lösungen zu finden welche ihrerseits Eingang in “BitcoinCore” finden könnten, da die Core Developer sehen könnten, dass sie funktionieren.

    Das sekundäre Ziel von “Degred” dürfte natürlich auch die Finanzierung ihrer Arbeit an der “Btcsuite” sein, jedoch wäre das legitim denn die Core Entwickler stehen vor dem gleichen Problem, dass sie von irgendetwas leben müssen.

    Links:

    Btcsuite –> https://blog.companyzero.com/2015/11/btcsuite-announcing-btcd-0-12-0-release/
    Bitcoin’s biggest challenges –> https://blog.companyzero.com/2015/11/bitcoins-biggest-challenges/
    Iterating Bitcoin –> https://blog.companyzero.com/2015/12/iterating-bitcoin/
    Decred: Rethink Digital Currency –> https://blog.companyzero.com/2015/12/decred-rethink-digital-currency/

  6. weitere alternative Lösung und besser als dieses unsinnige Lightningnetzwerk halte ich rootstock.io

    http://www.rootstock.io/

    Im Whitepaper findet man die Vorzüge von rootstock.io, ein System für Smart-Contracts vergleichbar mit Ethereum über eine Sidechain auf die Bitcoin-Blockchain aufgesetzt.
    http://www.rootstock.io/#white-paper

  7. Ich denke, über eines sollte weitgehend Konsens herrschen, auch wenn die sonstigen Einschätzungen auseinander laufen:

    Wenn die Bitcoin-Entwicklung dem Plan der Core-Devs folgt, wird der Bitcoin in 6-12 Monaten nicht mehr derselbe sein wie zuvor.

    Die Gebühren für Überweisungen werden steigen. Das ist jetzt schon so und wird noch deutlich schlimmer werden. Mit den neuen Default-Einstellungen für Miner werden kostenlose Überweisungen seltener werden. Mit dem “Replace By Fee” steigt das Risiko , Bitcoins ohne Confirmations anzunehmen (zero-conf). Das alles zusammen macht es für Händler erheblich unattraktiver, Bitcoin als Zahlungsweise anzubieten, und für Kunden, damit zu bezahlen.

    Die Lösung für diese so geschaffenen Probleme soll das Lightning Netzwerk werden. Die Theorie dazu ist ziemlich cool – leider kann aber niemand derzeit so richtig abschätzen, welche Probleme in der Praxis auftauchen werden. Eine Erklärung wie LN funktioniert zusammen mit einer kritischen Betrachtung gibt es z.B. hier: https://chrispacia.wordpress.com/2015/12/23/lightning-network-skepticism/

    Ich persönlich sehe die Entwicklung kritisch. Ich habe seit Frühjahr 2011 Bitcoins und habe in den vergangenen Monaten festgestellt, dass die Vision der Core-Devs und meine immer weiter auseinander laufen. Das LN ist ein theoretisch interessantes Konzept, aber es hat eigentlich nichts mit dem Bitcoin zu tun. Man könnte ein LN auch mit Bank-Überweisungen oder Goldbarren aufbauen. Warum ausgerechnet die Entwicklung des Bitcoins so gesteuert werden muss, dass ein LN auf Basis des Bitcoin ein neues Geschäftsmodell ergibt, erschließt sich mir nicht. Zumal das mit dem Risiko geschieht, den Bitcoin an die Wand zu fahren.

    Aus dem Grund habe ich in den letzten Tagen Bitcoins verkauft und werde jetzt gemütlich die kommende Entwicklung abwarten.

    Einen guten Rutsch und ein spannendes 2016 wünscht Mauline🙂

    • glücklicherweise gibt es mit BitcoinXT eine bereits getestete und verfügbare Lösung, sollte es wirklich zu einer Eskalation kommen. Lightning wird meiner Meinung nach nicht den Effekt bringen, weil es die Blockchain-Funktionsweise/System untergräbt.

      Jede Transaktion, mag sie auch noch so klein und unwichtig sein, sollte in der Blockchain ihren Platz finden und genauso behandelt werden wie jede andere Transaktion, so wie auch jedes Bit und Byte im Internet gleich behandelt werden sollte.

      Wer bitteschön soll auch darüber entscheiden, welche Transaktion wichtig und welche unwichtig ist?

      Angenommen man führt einen Automatismus ein, welcher anhand der Betragshöhe die Tx im Lighning-Netzwerk abwickelt, halte ich für sehr gefährlich, weil es Anwendungen gibt, welche über Microtransaktionen laufen. Z.B. wenn ich Eintrittskarten, Wertpapiere, Bestellaufträge, usw. an Tx binden möchte, so könnten diese zum Opfer fallen, weil jene von den öffentlich zugängigen Daten in der Blockchain leben.

      Automatisch lässt sich dies daher nicht bestimmen, so dass es am Ende auf die Kategorisierung des Nutzers hinauslaufen müsste.

      Egal wie man die Sache dreht und wendet, Lighningnetzwerk ist einfach Mist und schädlich für den Bitcoin, so wie bereits die Unterscheidung von Transaktionen schädlich ist.

      Solange man aber nicht über die beschränkte Sicht eines alternativen Zahlungsmittels hinauskommt, werden wir wohl weiter mit solch irrsinnigen Ideen leben müssen.

      Viele Leute haben scheinbar noch nicht begriffen, dass das Thema Zahlungsmittel nur einen kleinen Teil des Bitcoin ausmacht und man Bitcoin auch nicht auf diesen Teil beschränken kann, sofern man nicht die Absicht hegt, Bitcoin beerdigen zu wollen.

  8. Diese Liste ist eine Farce. Viele der Unterzeichner haben nicht eine einzige Zeile Code zu Bitcoin Core beigetragen und sind zum Teil Entwickler von Altcoins (Interessenskonflikte sind daher nicht auszuschließen). Durch die Liste ist nicht ersichtlich, wie viele Entwickler diesem Fahrplan nicht zugestimmt haben. Zudem haben 2 der mittlerweile nur noch 4 Entwickler mit “Push-Access” nicht unterschrieben (Jeff Garzik und Gavin Andresen). Dies zeigt, dass die Debatte noch lange nicht beendet ist und zum Beispiel auf Reddit weiterhin erbittert geführt wird. Auch testet Coinbase mittlerweile Bitcoin XT. Coinbase könnte damit den Stein in dieser Debatte richtig ins Rollen bringen.

  9. Ich schliesse mich Tony`s Meinung an, das Lightning Network ist total unsinnig.
    Joseph Poon und Thaddeus Dryja sind die Hauptinitiatoren des Vorschlags eines Lightning-Nezwerkes, Dryja kann ich noch nachvollziehen aber Poon ?
    Es gibt ein passenden Spruch dazu:

    Vines kill Trees,
    Bitcoin is like a Tree
    and Lightning Network is like a VINE INFESTATION.

    NO GO FOR LIGHTNING NETWORK.

  10. Wir dürfen gespannt sein,

    entweder kann man sich demnächst dann mal nen Inselkatalog bestellen, oder man hat eine Ansammlung von Bits & Bytes die nix Wert sind.

    Wenn der Markt dies nicht reguliert bekommt, innerhalb der nächsten 1-2 Jahre hat es sich wohl ausgecoint.

  11. Never change a winning team…😉

4 Trackbacks / Pingbacks

  1. Der kleine Weihnachtscrash: Was war los? | BitcoinBlog.de – das Blog für Bitcoin und andere virtuelle Währungen
  2. Segregated Witness – die kurzfristige Skaling-Lösung von Core – BitcoinBlog.de – das Blog für Bitcoin und andere virtuelle Währungen
  3. Core bekommt Ultimatum, Ethereum im Höhenflug – BitcoinBlog.de – das Blog für Bitcoin und andere virtuelle Währungen
  4. Scaling Bitcoin in Mailand – 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