Der BIP-Prozess

Neugier

1. Wenn ein BIP nur ein Dokument ist, wie verändert es dann das Verhalten von Millionen von Computern?
2. Warum vergeben die Editoren Nummern an Vorschläge, ohne jemals über deren Qualität abzustimmen?
3. Was hindert einen einzelnen Entwickler daran, eine Änderung der Regeln für das gesamte Netzwerk durchzusetzen?

Erkunden

1. Amir Taaki führte im August 2011 die Bitcoin Improvement Proposals (BIPs) ein, direkt nach dem Vorbild der PEPs von Python. BIP1 schuf den Rahmen für die Dokumentation von Protokolländerungen und allgemeinen Informationen. Luke Dashjr überarbeitete ihn 2016 mit BIP2, und 2025 ersetzte BIP3, „Updated BIP Process“ von Mark Erhardt, BIP2. Ursprünglich in einem Wiki gehostet, liegen die BIPs heute in einem versionierten Repository auf GitHub, sodass jede Änderung nachverfolgt und überprüft werden kann.
2. Nach BIP3 gibt es drei Typen. Specification-BIPs beschreiben Änderungen am Protokoll oder an interoperabler Software, etwa neue Transaktionsregeln, Wallet-Standards oder Netzwerknachrichten. Informational-BIPs bieten Orientierung oder Kontext, ohne etwas vorzuschreiben. Process-BIPs beschreiben, wie die Entwicklung selbst abläuft, einschließlich des BIP-Prozesses. Ältere BIPs behalten die Bezeichnung „Standards Track“, unter der sie verfasst wurden; sie entspricht dem heutigen Typ Specification.
3. Jeder Vorschlag wird von seinen Autoren vorangetrieben: Sie verfassen ihn, verteidigen ihn auf der Mailingliste und in Reviews und überarbeiten ihn als Reaktion auf Kritik. Die Autorschaft verleiht keine Macht, die Übernahme durchzusetzen. Ein BIP bleibt ein Dokument, bis Node- oder Wallet-Software es implementiert und Menschen sich entscheiden, diese Software zu betreiben. Es gibt keine Abstimmung; eine Konsensänderung tritt nur ein, wenn ein ausreichend großer Teil des Netzwerks aktualisiert.
4. Diskutiert wird auf der bitcoin-dev-Mailingliste, in Pull Requests im Rahmen des Code-Reviews und auf Konferenzen. Es gibt keine formelle Autorität und keine bindende Abstimmung. Die Editoren vergeben Nummern und prüfen die Form, entscheiden aber nicht über die Übernahme. Nach BIP3 durchläuft ein Vorschlag den Status „Draft“, dann „Complete“, sobald seine Autoren ihn für fertig halten, und schließlich „Deployed“, sobald er im Einsatz ist; aufgegebene oder ersetzte Vorschläge werden als „Closed“ markiert. Das Statusfeld im Repository bildet diesen Lebenszyklus ab.
5. Bekannte BIPs veranschaulichen die Wirkung des Prozesses. BIP16 führte 2012 Pay-to-Script-Hash (P2SH) ein. BIP32 definierte hierarchisch-deterministische Wallets (HD-Wallets), und BIP39 standardisierte Seed-Phrasen zur Wiederherstellung. BIP141 ermöglichte Segregated Witness (SegWit), das im August 2017 bei Block 481.824 aktiviert wurde. Die BIPs 340–342 führten Schnorr-Signaturen und Taproot ein, die im November 2021 aktiviert wurden. Jede dieser Änderungen erforderte eine sorgfältige Koordination zwischen Entwicklern, Minern und Nutzern, um Rückwärtskompatibilität oder einen sauberen Fork sicherzustellen.
6. Öffnen Sie das BIPs-Repository auf GitHub. Suchen Sie drei BIPs heraus: eines vom Typ Standards Track (z. B. BIP141), eines vom Typ Informational (z. B. BIP50) und eines vom Typ Process (z. B. BIP3). Lesen Sie jeweils das Statusfeld. Notieren Sie, wann jedes erstellt wurde und wie sich sein Status verändert hat. Diese Übung zeigt, dass technische Qualität allein nicht ausreicht; sozialer Konsens und wirtschaftlicher Interessengleichklang sind die eigentlichen Torwächter der Weiterentwicklung von Bitcoin.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• Amir Taaki, Bitcoin Improvement Proposal #1 (2011)
• Luke Dashjr, BIP2: BIP Process, revised (2016); M. Erhardt, BIP3: Updated BIP Process (2025)
• github.com/bitcoin/bips