BIP (Bitcoin Improvement Proposal)

Anna bereitet eine Zahlung am Computer vor, möchte sie aber mit einer Hardware-Wallet eines anderen Herstellers digital signieren. Beide Programme müssen die ausgetauschten Angaben verstehen. Genau hier setzt BIP 174 an: Es beschreibt PSBT, ein gemeinsames Format für eine noch nicht fertig signierte Transaktion und die zum Signieren benötigten Daten. Entwickler können sich auf dasselbe Dokument stützen, statt unabhängig voneinander unvereinbare Formate zu erfinden. Darin liegt ein praktischer Nutzen von BIPs. [8]

Hinter verschiedenen Nummern stehen unterschiedliche Aufgaben. BIP39 beschreibt die Erzeugung von Wiederherstellungswörtern und deren Umwandlung in einen Seed, die Ausgangsdaten zur Ableitung von Wallet-Schlüsseln. BIP 141 beschreibt SegWit, eine Änderung der Transaktionsregeln, die durch Aktivierung im Netzwerk wirksam wurde. BIP 174 erleichtert die Übergabe von Transaktionen zum Signieren, ohne die Blockgültigkeit zu ändern. BIP 50 dokumentiert Ursachen und Behebung des Vorfalls vom März 2013, als sich das Netzwerk vorübergehend spaltete. Nicht jedes BIP schlägt also eine neue Bitcoin-Regel vor. [6] [7] [8] [9]

Eine Lösung zu beschreiben, sie zu programmieren und sie zu verwenden sind getrennte Schritte. Die Beschreibung heißt Spezifikation, der Code Implementierung. Eine Wallet kann mit einem Entwurf experimentieren; zu einem anderen Dokument existiert womöglich noch keine genutzte Software. Bei Änderungen der Blockgültigkeitsregeln kommt die Aktivierung hinzu: Ab diesem Zeitpunkt setzt die betreffende Software die Regeln durch. Die Veröffentlichung aktualisiert Ihren Node, den Computer zur Prüfung der Netzwerkregeln, nicht von selbst. [7] [10]

Die Nummer hilft vor allem, das richtige Dokument zu finden und sich auf dieselbe Diskussion zu beziehen. Eine höhere Nummer bedeutet weder einen besseren Vorschlag noch ein empfohlenes Upgrade. Auch ein nummerierter Text kann unfertig bleiben oder beiseitegelegt werden. Wirbt ein Dienst mit der Unterstützung eines BIP, müssen Sie weiterhin prüfen, welche Funktion gemeint ist und ob die konkrete Softwareversion sie tatsächlich bietet. [2]

Autoren sichten zunächst frühere Arbeiten und diskutieren die Idee auf der Bitcoin Development Mailing List, einer öffentlichen E-Mail-Diskussion für Entwickler. Rückmeldungen können Probleme aufdecken, bevor ein langer Text entsteht. Ein hinreichend ausgearbeiteter Vorschlag wird anschließend als Pull Request, also als Antrag auf Aufnahme, im gemeinsamen GitHub-Repository bitcoin/bips eingereicht. Die Nummer wählen Autoren nicht selbst: Ein Editor vergibt sie nach Prüfung von Thema, Format und Reife des Vorschlags. [1]

BIP Editors betreuen die veröffentlichten Dokumente: Sie prüfen vorherige Diskussionen, Verständlichkeit, Format und Lizenz, vergeben Nummern und pflegen die Einträge. Damit entscheiden sie weder über Ihre Software noch über die Regeln Ihres Nodes. Ein Eintrag im Repository garantiert weder Sicherheit noch Zustimmung der Gemeinschaft. Über die tatsächliche Nutzung entscheiden einzelne Projekte und Teilnehmer des Netzwerks. [1]

Heißt es, ein neues BIP sei genehmigt worden, öffnen Sie das Dokument und prüfen Sie, was geschehen ist. Wurde nur eine Nummer vergeben, haben die Autoren ihre Arbeit abgeschlossen oder wird die Funktion bereits genutzt? Bei einer Wallet helfen Dokumentation und veröffentlichte Versionen; bei Netzwerkregeln müssen auch Aktivierungsbedingungen und Verlauf geprüft werden. So unterscheiden Sie einen interessanten Vorschlag von einer bereits nutzbaren Funktion. [10] [2]

Das aktuelle Verfahren beschreibt BIP 3, Updated BIP Process, mit dem Status Deployed. Es ersetzte BIP 2 und vereinfachte Dokumenttypen und Statusangaben. Ältere Artikel nennen deshalb möglicherweise Standards Track oder Final, obwohl diese Begriffe nicht mehr zur heutigen Einteilung passen. Maßgeblich sind die aktuelle Datei und ihre Änderungshistorie. Das Repository veröffentlicht und bewahrt Vorschläge; es ist kein Abstimmungssystem über Bitcoins Zukunft. [1] [5]

Specification beschreibt technische Regeln, anhand derer miteinander kompatible Programme entstehen können. Vor dem Abschluss sind auch eine funktionierende Referenzimplementierung, also ein Beispielprogramm zur Umsetzung des Vorschlags, und Testvektoren nötig, also Beispieleingaben mit erwarteten Ergebnissen. Informational liefert Informationen, Analysen oder Empfehlungen. Process regelt einen Arbeitsablauf, etwa die Veröffentlichung von BIPs. Zu dieser letzten Gruppe gehört BIP 3; es beschreibt kein neues Bitcoin-Transaktionsformat. [1]

Draft bezeichnet einen Entwurf in Arbeit. Complete bedeutet, dass die Autoren ihre geplante Arbeit abgeschlossen haben und die Übernahme empfehlen. Deployed steht für nachgewiesene aktive Nutzung; bei Process kann der erforderliche rough consensus gemeint sein, eine breite Einigung nach Diskussion und Klärung sachlicher Einwände statt bloßem Stimmenzählen. Closed kennzeichnet historisches Material, das weder aktiv weiterentwickelt noch vorangetrieben oder genutzt wird. Es bleibt archiviert. Selbst Deployed bedeutet nicht, dass jede Wallet den Vorschlag unterstützt. [1]

Im Kopf des Dokuments stehen Autoren, Typ, Status, Datum der Nummernvergabe, Lizenz und Diskussionslinks. Requires nennt benötigte andere BIPs, Replaces die zu ersetzenden Vorschläge und Proposed-Replacement einen möglichen Nachfolger. Nach Erreichen des Status Complete werden weitere Änderungen mit Datum und Versionsnummer im Changelog, dem Änderungsprotokoll, festgehalten. Das Feld Version im Dokumentkopf nennt die aktuelle Fassung. Eine mit der bisherigen Lösung unvereinbare Änderung sollte im Regelfall ein neues BIP erhalten, damit dieselbe Nummer nicht stillschweigend etwas anderes bezeichnet. [1]