BIPs – Bitcoin als Community gemeinsam verbessern

Bitcoin Improvement Proposals („Bitcoin-Verbesserungsvorschläge“, abgekürzt BIPs) bringen viele Neuerungen für Bitcoin. Dazu zählen unter anderem SegWit, Schnorr-Signaturen oder MAST (Merklized Abstract Syntax Trees). Sie sind der offizielle Weg, um Änderungen am Bitcoin-Protokoll vorzunehmen. Was letztendlich implementiert wird, entscheidet dank BIPs die Community, also Miner und Betreiber von Full Nodes. Unser CTO Daniel Weigl war bereits 2017 an einer BIPs beteiligt.

Alle BIPs werden hier gesammelt: https://github.com/bitcoin/bips

Die Geschichte der BIPs beginnt mit den letzten Zeilen des Whitepapers 2008:„Sie (Anm.: die Miner) stimmen mit ihrer CPU-Leistung ab. Sie erklären, dass sie gültige Blöcke akzeptieren, indem sie an der Verlängerung der Kette nach diesen Blöcken arbeiten, und ungültige Blöcke ablehnen, indem sie sich weigern, an ihnen zu arbeiten. Alle erforderlichen Regeln und Anreize können mit diesem Konsensmechanismus durchgesetzt werden.“ (Satoshi Nakamoto, 2008)

Dieser Absatz wird meist so interpretiert, dass Miner mit dem Annehmen bzw. Ablehnen von Blöcken auch ihre Zustimmung bzw. Ablehnung in Bezug auf Dinge, die nicht die Transaktion selbst betreffen, ausdrücken können. Somit kann dies als Voting-Möglichkeit für Änderungen im Bitcoin-Protokoll (und damit im Programmcode) gesehen werden. Im Laufe der Jahre wurden verschiedene Methoden entwickelt, um einen Konsens über Protokolländerungen zu finden, insbesondere BIP-34 im Jahr 2012 und BIP-9 im Jahr 2015.

Wie funktionieren die BIPs genau?

Das erste BIP wurde 2011 von Amir Taaki eingereicht. Hier ist ein Link zur Datei selbst: https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki. Amirs BIP-1 definierte die Struktur für einen solchen Vorschlag im Detail. Seitdem wurden weit über 100 BIPs verfasst. (Hier eine Liste aller bisherigen BIPs: https://github.com/bitcoin/bips/blob/master/README.mediawiki)

Den BIPs wird, wie in der Liste oben angezeigt, ein Status zugewiesen. Ein BIP muss danach einem RedakteurIn übergeben werden, um zu einem Entwurf zu werden. Dieser Entwurf kann dann vom AutorIn des BIPs zurückgestellt oder zurückgezogen bzw. von der Community akzeptiert oder abgelehnt werden.

Wie in BIP-1 definiert, folgt hier die Grafik zu diesem Prozess:

Quelle:  https://github.com/bitcoin/bips/blob/master/bip-0001/process.png

Damit ein BIP akzeptiert und als endgültig gekennzeichnet wird, muss jede der folgenden Bedingungen erfüllt sein:

  • Folgt dem von BIP-1 angegebenen korrekten Format (https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki)
  • Enthält Codeimplementierungen der vorgeschlagenen Änderungen am Protokoll
  • Hat 95 % Unterstützung von den letzten 2.016 Minern (ca. die letzten 14 Tage Mining mit 10-Minuten-Blöcken)
  • Miner können für oder gegen ein BIP stimmen, indem sie die entsprechenden Daten in den Hash ihres Blockes aufnehmen.

Abhängig von der BIP-„Layer“-Spezifikation kann eine BIP-Annahme in ein „Soft-Fork“-Upgrade münden, bei dem die Community-Mitglieder (Börsen, Zahlungsdienstleister, Miner usw.) ihre Protokollversionen aktualisieren müssen, um die neu im Code eingebaute Funktion zu ermöglichen.

Ein bekannteres BIP in Form eines Soft Forks stellt beispielsweise das im August 2017 erfolgte Upgrade auf SegWit dar, in dessen Rahmen auch der Hard Fork von Bitcoin Cash stattfand.

Im Allgemeinen kann ein Soft Fork nur Änderungen vornehmen, die mit früheren Versionen der Software kompatibel sind, sodass ältere Versionen weiterhin normal funktionieren. Im Fall von SegWit haben die Entwickler zwar die Art und Weise, in der Transaktionen erstellt und ausgegeben werden sollen, erheblich geändert, jedoch auf eine Weise, durch die davor vorhandene Transaktionen nicht betroffen sind.

Fazit

Zusammenfassend gibt es folgende übergeordnete Kontrollstruktur:

  • Jede/r kann ein BIP einreichen, das das Bitcoin-Protokoll ändern soll.
  • Das BIP muss von einem RedakteurIn genehmigt werden.
  • Das BIP muss mit 95%iger Zustimmung der Miner abgesegnet werden.
  • Die Community muss ein Upgrade auf die neue Softwareversion durchführen.
  • Das oben beschriebene Konsensmodell stellt sicher, dass kein „böser“ Akteur oder eine Minderheitengruppe das Schicksal von Bitcoin steuern kann.

Im Grunde kann natürlich jede/r Bitcoin ändern, da jede/r ein BIP einreichen kann. Da BIPs jedoch im Ermessen der RedakteureIn zensiert werden können, könnte man argumentieren, dass sie die Kontrolle haben. Aber in diesem Falle könnte eine Person, die ein BIP vorschlägt, sich einfach an andere RedakteurInnen wenden bzw. das BIP veröffentlichen, um durch Zustimmung der Community das BIP durchzusetzen. 

Das zweite Gegenargument: Da Miner jede Änderung mit 95%igem Vertrauen bestätigen müssen, könnte man argumentieren, dass Miner die RedakteureIn zensieren können. Es scheint also, als hätten die Miner die ultimative Kontrolle. Dies ignoriert jedoch die letzte Ebene: die Community.

Am Ende kann die Community als Ganzes niemals dazu gezwungen werden, unerwünschte Änderungen an Bitcoin vorzunehmen. Sollte ein „böser“ Akteur oder eine Gruppe Bitcoin in eine unerwünschte Richtung bringen wollen, kann sich die Community hinter die mehrheitlich unterstützte Version des Projekts begeben und ihre Software auswählen. Mit der wirtschaftlichen Aktivität der Community in der mehrheitlich erwünschten Version des Projekts würden die „bösen“ Akteure eine leere Blockchain beibehalten, während sie Rechenressourcen beim Minen von praktisch wertlosen Coins verschwenden.

Wir sehen also, dass Bitcoin in wirtschaftlicher Hinsicht grundsätzlich von der Mehrheit der Community kontrolliert wird. Wie in jeder Community müssen die Mitglieder jedoch selbstverständlich wachsam sein und sich selbst Gedanken zu Änderungen im Protokoll machen, um zu vermeiden, dass sie den Ratschlägen anderer unreflektiert folgen.


Unser CTO Daniel Weigl hat an dem BIP #49 mitgearbeitet.