aus dem Englischen von https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki, Stand Juli 2019

  BIP: 2
  Title: BIP process, revised
  Author: Luke Dashjr <luke+bip@dashjr.org>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0002
  Status: Active
  Type: Process
  Created: 2016-02-03
  License: BSD-2-Clause
           OPL
  Replaces: 1

Zusammenfassung

Ein Bitcoin Improvement Proposal (BIP) ist ein Designdokument, das Informationen für die Bitcoin-Community bereitstellt oder eine neue Funktion für Bitcoin oder seine Prozesse oder Umgebung beschreibt. Das BIP sollte eine präzise technische Spezifikation des Features mit nachvollziehbareren Argumenten dafür enthalten.

Es ist beabsichtigt, dass die BIPs der primäre Mechanismus für 

  • das Vorschlagen neuer Funktionen, 
  • das Sammeln von Community-Beiträgen zu einem Thema und 
  • für die Dokumentation der Designentscheidungen sind.

Der BIP-Autor ist dafür verantwortlich, einen Konsens innerhalb der Community zu schaffen und abweichende Meinungen zu dokumentieren.

Da die BIPs als Textdateien in einem versionierten Repository verwaltet werden, ist ihr Revisionsverlauf der historische Datensatz des Feature-Vorschlags.

Dieses spezielle BIP ersetzt BIP 1 durch einen besser definierten und klareren Prozess.

Urheberrecht

Dieses BIP ist unter der Open Publication License und der BSD-2-Clause Lizenz doppelt lizenziert.

BIP-Workflow

Jeder BIP-Prozess beginnt mit einer neuen Idee für Bitcoin. Jedes potenzielle BIP muss einen Champion haben – jemand, der das BIP in dem unten beschriebenen Stil und Format schreibt, die Diskussionen in den entsprechenden Foren leitet und versucht, einen Community-Konsens über die Idee zu schaffen.

Der BIP-Champion (auch Autor) sollte zunächst versuchen festzustellen, ob die Idee BIP-fähig ist. Kleine Verbesserungen oder Patches für eine bestimmte Software erfordern häufig keine Standardisierung zwischen mehreren Projekten. Solche Änderungen benötigen kein BIP und sollten in den relevanten projektspezifischen Entwicklungsworkflows mit einer Patch-Übermittlung an den entsprechenden Issue-Tracker eingefügt werden.

Man sollte auch bedenken, dass darüber hinaus schon viele Ideen für die Änderung von Bitcoin vorgeschlagen und aus verschiedensten Gründen abgelehnt wurden. Einer der erten Schritte sollte es also sein, die bisherigen Diskussionen zu erforschen, um zu sehen, ob eine Idee bereits in Betracht gezogen wurde, und wenn ja, welche Fragen dabei aufgekommen sind. Nach der Analyse vergangener Arbeiten, wird empfohlen, die neue Idee auf der Bitcoin-Entwicklungs-Mailingliste vorzustellen.

Eine Idee öffentlich zu diskutieren, bevor man anfängt, ein BIP zu schreiben, soll helfen Zeit zu sparen, nicht nur dem potenziellen Autor als auch der breiteren Community. Die Bitcoin-Community zuerst zu fragen, ob eine Idee wirklich neu ist, hilft zu verhindern, dass viel Zeit für etwas aufgewendet wird, das aufgrund früherer Diskussionen garantiert abgelehnt würde (Einzelarbeit allein reicht nicht!). Es hilft auch sicherzustellen, dass die Idee auf die gesamte Community und nicht nur auf den Autor anwendbar ist. Nur weil eine Idee für den Autor gut klingt, bedeutet das nicht, dass sie für die meisten Menschen in den unterschiedlichen Bereichen, in denen Bitcoin verwendet wird, funktioniert.

Sobald der Champion die Bitcoin-Community gefragt hat, ob eine Idee eine Chance auf Akzeptanz hat, sollte ein Entwurf des BIP der Bitcoin-Entwicklungs-Mailingliste vorgelegt werden. Dies gibt dem Autor die Möglichkeit, den Vorschlag des BIP zu konkretisieren, um ihn ordnungsgemäß und qualitativ hochwertig zu gestalten und zusätzliche Bedenken bezüglich des Vorschlags auszuräumen. Nach einer Diskussion sollte der Vorschlag als Pull-Request an das GIT-Repository der BIPs übermittelt werden. Dieser Vorschlag muss wie unten beschrieben im BIP-Stil geschrieben und mit einem alias wie „bip-johndoe-infinitebitcoins“ benannt werden, bis der Editor ihm eine BIP-Nummer zugewiesen hat (Wichtig: Autoren dürfen BIP-Nummern nicht selbst zuweisen).

BIP-Autoren sind dafür verantwortlich, Community-Feedback sowohl zur ursprünglichen Idee als auch zum BIP zu sammeln, bevor sie es zur Überprüfung einreichen. Wo immer möglich, sollten jedoch lange offene Diskussionen über öffentliche Mailinglisten vermieden werden. Folgende Strategien werden empfohlen, um die Diskussionen effizient zu halten: 

  • Einrichtung einer separaten SIG-Mailingliste für das Thema, 
  • BIP-Autor akzeptiert private Kommentare in den frühen Vorschlagsphasen, 
  • Einrichten einer Wiki-Seite oder eines Git-Repositorys usw. 

BIP-Autoren sollten hier ihr nach eigenem Ermessen handeln.

Es wird dringend empfohlen, dass ein einzelnes BIP genau einen einzelnen konkreten Vorschlag oder eine neue Idee enthält. Je fokussierter das BIP, desto größer die Chancen auf Erflog. Teilen Sie Ihr BIP im Zweifelsfall in mehrere konkrete Einzelteile auf.

Wenn der BIP-Entwurf abgeschlossen ist, weist der BIP-Editor dem BIP eine Zahl zu, und typisiert es als

  • Standards Track, 
  • Informational oder 
  • Process 

und führt den Pull-Request mit dem BIPs-Git-Repository zusammen. Der BIP-Editor darf ein BIP nicht willkürlich ablehnen.

Damit ein BIP akzeptiert werden kann, muss es bestimmte Mindestkriterien erfüllen. Es muss eine klare und vollständige Beschreibung der vorgeschlagenen Verbesserung sein. Die Verbesserung muss eine Netto-Verbesserung darstellen. Die vorgeschlagene Umsetzung muss, falls zutreffend, solide sein und darf das Protokoll nicht übermäßig verkomplizieren.

Gründe für die Ablehnung von BIPs können sein:

  • Redundanz, 
  • Missachtung von Formatierungsregeln, 
  • zu unkonkret oder zu breit, 
  • technisch unsolide, 
  • keine angemessene Motivation oder 
  • fehlende Adressierung der Abwärtskompatibilität oder 
  • nicht im Einklang mit dem Bitcoin-Philosophie. 

Der BIP-Autor kann den Entwurf bei Bedarf im Git-Repository aktualisieren. Aktualisierungen des Entwurfes sollten auch vom Autor als Pull-Request eingereicht werden.

Übertragen der BIP-Autorenrechts

Gelegentlich kann es notwendig sein, die Leitung über BIPs auf einen neuen Champion zu übertragen. Im Allgemeinen möchten wir den ursprünglichen Autor als Co-Autor des übertragenen BIP behalten, aber das liegt wirklich beim ursprünglichen Autor. Ein guter Grund für die Eigentumsübertragung liegt darin, dass der ursprüngliche Autor nicht mehr die Zeit oder das Interesse hat, ihn zu aktualisieren oder dem BIP-Prozess zu folgen, oder dass er vom „Netz“ gefallen ist (d. h. nicht erreichbar ist oder nicht auf E-Mails reagiert). Ein schlechter Grund für die Übertragung des Autorenrechts ist, dass man mit der Richtung des BIP nicht einverstanden ist. Es soll versucht werden, einen Konsens über ein BIP zu erzielen, aber wenn das nicht möglich ist, kan man immer ein konkurrierendes BIP einreichen.

Wenn man daran interessiert ist, den Besitz eines BIP zu übernehmen, sendet man eine Nachricht mit der Bitte, das BIP zu übernehmen, und richtet sie sowohl an den ursprünglichen Autor als auch an den BIP-Editor. Wenn der ursprüngliche Autor nicht rechtzeitig auf die E-Mail reagiert, trifft der BIP-Editor eine einseitige Entscheidung (natürlich kann eine solche Entscheidungen auch wieder rückgängig gemacht werden :).

BIP-Editoren

Der aktuelle BIP-Editor ist Luke Dash Jr., der unter luke_bipeditor@dashjr.org kontaktiert werden kann.

Verantwortlichkeiten & Workflow für den BIP-Editor

Der BIP-Editor ist immer auch Abonnent der Bitcoin-Entwicklungs-Mailingliste. Off-List BIP-bezogene Korrespondenz sollte an luke_bipeditor@dashjr.org direkt gesendet werden.

Für jedes neue BIP, das erscheint, macht der Editor folgendes:

  • Er liest das BIP durch, um zu überprüfen, ob es vollständig ist. Der Vorschlag muss technisch sinnvoll sein, auch wenn er womöglich nicht akzeptiert wird.
  • Der Titel sollte den Inhalt genau beschreiben.
  • Der BIP-Vorschlag muss zur Diskussion an die Bitcoin-Entwicklungs-Mailingliste gesendet worden sein.
  • Motivation und Abwärtskompatibilität (falls zutreffend) müssen angesprochen werden.
  • Der definierte Layer-Header muss für die angegebene Spezifikation korrekt zugewiesen werden.
  • Lizenzbedingungen müssen für BIPs akzeptabel sein.

Wenn das BIP noch nicht vollständig ist, sendet der Editor es zur Überarbeitung an den Autor mit den nötigen Anweisungen zurück.

Sobald das BIP für das Repository bereit ist, sollte es als „Pull-Request“ an das BIPs-Git-Repository übermittelt werden, wo es weiteres Feedback erhalten kann.

Der BIP-Editor wird:

  • dem Vorschlag eine BIP-Nummer für den Pull-Request zuweisen.
  • den Pull-Request durchführen, wenn alle Bedingungen erfüllt sind.
  • das BIP in die README.mediawiki eintragen

Die BIP-Editoren sollen administrative und redaktionelle Aufgaben erfüllen. Die BIP-Editoren überwachen BIP-Änderungen und aktualisieren BIP-Header entsprechend.

BIP-Format und Struktur

Spezifikation

BIPs müssen im mediawiki-Format geschrieben werden.

Jedes BIP sollte die folgenden Teile haben:

  • Präambel – Header, die Metadaten zum BIP enthalten.
  • Abstract – Eine kurze Beschreibung des technischen Problems, das angegangen wird.
  • Copyright – Das BIP muss explizit unter akzeptablen Copyright-Bedingungen lizenziert werden.
  • Spezifikation – Die technische Spezifikation sollte die Syntax und Semantik jedes neuen Features beschreiben. Die Spezifikation sollte detailliert genug sein, um konkurrierende, interoperable Implementierungen für jede der aktuellen Bitcoin-Plattformen zu ermöglichen.
  • Motivation – Die Motivation ist entscheidend für BIPs, die das Bitcoin-Protokoll ändern möchten. Es sollte klar erklären, warum das bestehende Protokoll nicht ausreicht, um das Problem anzugehen, das das BIP löst.
  • Begründung – Die Begründung konkretisiert die Spezifikation, indem beschrieben wird, was das Design motiviert hat und warum bestimmte Designentscheidungen getroffen wurden. Es sollte alternative Vorschläge und die zugrundeliegenden Untersuchungen beschreiben, die berücksichtigt wurden. Die Begründung sollte einen Konsens innerhalb der Community liefern und wichtige Einwände oder Bedenken diskutieren, die während der Diskussion vorgebracht werden.
  • Abwärtskompatibilität – Alle BIPs, die Rückwärtsinkompatibilitäten einführen, müssen einen Abschnitt enthalten, in dem diese Inkompatibilitäten und deren Schweregrad beschrieben werden. Das BIP muss erklären, wie der Autor diese Inkompatibilitäten zu behandeln gedenkt.
  • Referenzimplementierung – Die Referenzimplementierung muss abgeschlossen sein, bevor ein BIP den Status „Final“ erhält, aber sie muss nicht abgeschlossen sein, bevor das BIP akzeptiert wird. Es ist besser, die Spezifikation und die Begründung zuerst abzuschließen und einen Konsens darüber zu erzielen, bevor Code geschrieben wird. Die endgültige Version muss Testcode und eine Dokumentation enthalten, die für das Bitcoin-Protokoll geeignet sind.

BIP-Headerpräambel

Jedes BIP muss mit einer Headerpräambel im RFC 822-Stil beginnen. Die Kopfzeilen müssen in der folgenden Reihenfolge angezeigt werden. Header, die mit „*“ gekennzeichnet sind, sind optional und werden unten beschrieben. Alle anderen Header sind erforderlich.

  BIP: <BIP-Nummer oder "?", bevor sie zugewiesen wird>
* Layer: <Konsens (Soft Fork) | Konsens (Hard Fork)|
Peer-Services | API/RPC | Anwendungen>
  Title: <BIP-Titel; maximal 44 Zeichen>
  Autor: <Liste der echten Namen und E-Mail-Addr der
Autoren>
* Diskussions-to: <E-Mail-Adresse>
* Comments-Summary: <Community-Einschätzung>
  Comments-URI: <links zur Wiki-Seite für Kommentare>
  Status: <"Draft" | “Aktiv” | "Proposed" | “Deferred” |
"Rejected" | "Withdrawn" | “Final” |
“Replaced” | “Obsolete”>
  Type: <Standards Track | Informationen | Prozess>
  Created: <Datum erstellt am, im ISO 8601 (yyyy-mm-dd)
Format>
  License: <Abkürzung für genehmigte Lizenzen>
* License-Code: <Abkürzung für Code unter verschiedenen
genehmigten Lizenzen>
* Post-History: <Datum der Postings auf Bitcoin-
Mailingliste, oder Link zu Thread im
Mailinglisten-Archiv>
* Requires: <BIP-Nummer(n)>
* Replaces: <BIP-Nummer>
* Superseded-by: <BIP-Nummer>

Der Layer-Header (nur für Standards Track BIPs) dokumentiert, auf welche Bitcoin-Ebene das BIP angewendet wird. Definitionen der verschiedenen BIP-Layer finden Sie unter BIP 123. Die Aktivierung dieses BIP impliziert die Aktivierung von BIP 123.

Der Author-Header listet die Namen und E-Mail-Adressen aller Autoren/Besitzer des BIP auf. Das Format des Author-Headerwerts ist:

Zufälliger J. Benutzer <adresse-dom.ain>

Wenn mehrere Autoren vorhanden sind, sollte sich jeder in einer separaten Zeile nach “RFC 2822-continuation line convention” befinden.

Während sich ein BIP in privaten Diskussionen befindet (in der Regel während der ersten Vorschlagsphase), zeigt ein Discussions-To-Header die Mailingliste oder URL an, in der das BIP diskutiert wird. Kein Discussions-To-Header ist notwendig, wenn das BIP privat mit dem Autor oder auf den Bitcoin-E-Mail-Mailinglisten besprochen wird.

Der Type-Header gibt den Typ des BIP an: Standards Track, Informational oder Process.

Der Created-Header zeichnet das Datum, an dem dem BIP eine Nummer zugewiesen wurde. Die Datumsangaben sollten im yyyy-mm-dd-Format vorliegen, z. B. 2001-08-14.

Post-History wird verwendet, um aufzuzeichnen, wann neue Versionen des BIP in der Bitcoin-Mailingliste verkündet wurden. Post-History ist als Link zu einem bestimmten Thread in einem Mailinglistenarchiv zulässig.

BIPs verfügen möglicherweise über einen Requires-Header, der die BIP-Nummern angibt, von denen dieses BIP abhängt.

BIPs können auch einen Superseded-By-Header haben, der angibt, dass ein BIP durch einen späteren Vorschlag ersetzt wurde. Der Wert ist die Nummer des BIP, die das aktuelle Dokument ersetzt. Das neuee BIP muss über einen Replaces-Header verfügen, der die Nummer des BIP enthält, das es obsolet gemacht hat.

Hilfsdateien

BIPs können Hilfsdateien wie Diagramme enthalten. Hilfsdateien sollten in ein Unterverzeichnis für dieses BIP aufgenommen werden oder BIP-XXXX-Y.ext heißen, wobei „XXXX“ die BIP-Nummer, „Y“ eine Seriennummer (ab 1) und „ext“ durch die tatsächliche Dateierweiterung (z. B. „png“) ersetzt werden muss.

BIP-Typen

Es gibt drei Arten von BIP:

  • Ein Standard Track BIP beschreibt jede Änderung, die sich auf die meisten oder alle Bitcoin-Implementierungen auswirkt, z. B. eine Änderung des Netzwerkprotokolls, eine Änderung der Block- oder Transaktionsgültigkeitsregeln oder jede Änderung oder Ergänzung, die die Interoperabilität von Anwendungen beeinflusst, die Bitcoin benutzen. Standards Track BIPs bestehen aus zwei Teilen, einem Vorschlagsdokument und einer Referenzimplementierung.
  • Ein Informational BIP beschreibt ein Bitcoin-Design-Problem oder stellt der Bitcoin-Community allgemeine Richtlinien oder Informationen zur Verfügung, schlägt aber keine neue Funktion vor. Informations-BIPs stellen nicht unbedingt einen Konsens oder eine Empfehlung der Bitcoin-Community dar, sodass es Benutzern und Entwicklern freisteht, Informations-BIPs zu ignorieren oder ihren Ratschlägen zu folgen.
  • Ein Prozess-BIP beschreibt einen Prozess, der Bitcoin umgibt, oder schlägt eine Änderung (oder ein Ereignis) in einem Prozess vor. Prozess-BIPs sind wie Standards Track BIPs, gelten aber für andere Bereiche als das Bitcoin-Protokoll selbst. Sie können eine Implementierung vorschlagen, aber nicht auf Bitcoins Codebasis; sie erfordern oft einen Konsens der Community; Im Gegensatz zu Informations-BIPs sind sie mehr als Empfehlungen, und Benutzer können sie in der Regel nicht ignorieren. Beispiele hierfür sind Verfahren, Richtlinien, Änderungen am Entscheidungsprozess und Änderungen an den Tools oder der Umgebung, die bei der Bitcoin-Entwicklung verwendet werden. Jedes Meta-BIP wird auch als Prozess-BIP betrachtet.

BIP-Statusfeld

Spezifikation

Die typischen Pfade von BIPs sind wie folgt:

Dabei bedeutet:

  • „Draft“ – Entwurf
  • „Deferred“ – Zurückgestellt
  • „Withdrawn“ – Zurückgezogen
  • “Proposed” –  Vorgeschlagen
  • “Final/Activ” – Fertig gestellt/Aktiv
  • “Replaced” – Ersetzt
  • “Obsolete” – Obsolet

Champions eines BIP können selbst entscheiden, den Status zwischen „Draft“, „Deferred“ oder „Withdrawn“ zu ändern. Der BIP-Editor kann auch den Status zu „Deferred““ ändern, wenn beim BIP offensichtlich kein Fortschritt erzielt wird.

Ein BIP kann seinen Status nur dann von „Draft“ (oder „Rejected“) zu „Proposed“ ändern, wenn

  • der Autor es für abgeschlossen hält,
  • es über eine funktionierende Implementierung verfügt (sofern zutreffend) und
  • die Community plant, ihn auf den „Final“-Status zu überführen.

BIPs können auf Antrag von jedem vom „Draft“ oder „Proposed“ nach „Rejected“ geändert werden, wenn in drei Jahren keine Fortschritte erzielt wurde. Ein solches BIP kann zurück in den Status „Draft“ geändert werden, wenn der Champion Überarbeitungen vorlegt, die die öffentliche Kritik am Vorschlag sinnvoll behandeln, oder zurück in den „Proposed“ Status, wenn es die im vorherigen Absatz geforderten Kriterien erfüllt.

Ein „Proposed“ BIP kann nur dann “Final/Active” werden, wenn bestimmte Kriterien, die die reale Umsetzung widerspiegeln, zustande gekommen sind. Dies ist für jedes BIP unterschiedlich, je nach Art der vorgeschlagenen Änderungen, und wird weiter unten genauer beschrieben. Die Bewertung dieser Statusänderung sollte objektiv überprüfbar sein und/oder auf der Entwicklungs-Mailingliste diskutiert werden.

Wenn ein “Final” BIP nicht mehr relevant ist, kann sein Status in “Replaced” oder “Obsolete” geändert werden. Diese Änderung muss auch objektiv überprüfbar und/oder diskutiert werden.

Ein Prozess-BIP kann vom Status „Draft“ nach Aktiv” geändertwerden, wenn es einen groben Konsens auf der Mailingliste erreicht. Ein solcher Vorschlag sollte einen groben Konsens haben, wenn er seit mindestens einem Monat zur Diskussion in der Entwicklungs-Mailingliste steht und niemand unbeantwortete begründete Einwände dagegen aufrechterhält. Angesprochene oder hinderliche Einwände können durch allgemeines Einvernehmen ignoriert/aufgehoben werden, wenn sie ausreichend berücksichtigt wurden. In den Fälen muss eine klare Begründung gegeben werden.

Übergang zum Final-Status

Ein Soft-Fork-BIP erfordert unbedingt eine klare Mining-Mehrheit, die durch Blockchain-Abstimmung ausgedrückt wird (z. B. mit BIP-9). Wenn die Community bereit scheint, einen Hard-fork zu machen (wie z.B. eine Änderung des Proof-of-Work-Algorithmus), wird der Soft-Fork nicht “Final” so lange, wie ein solcher Hard-Fork eine Mehrheit von Unterstützern zu haben scheint, aber höchstens drei Monate. Soft-Fork-BIPs können auch zusätzliche Anforderungen für ihre Annahme festlegen. Aufgrund der Möglichkeit von Änderungen der Miningsdynamik, insbesondere im Hinblick auf delegierte Abstimmungen (Miningpools), wird dringend empfohlen, dass das BIP selbst eine Supermehrheit von rund 95 % verlangt, es sei denn, es wird eine Begründung für eine niedrigere Schwelle gegeben.

Ein Hard-Fork-BIP erfordert die Übernahme durch die gesamte Bitcoin-Ökonomie, insbesondere derjenigen, die Waren und Dienstleistungen im Austausch gegen Bitcoin-Zahlungen verkaufen, sowie Bitcoin-Inhaber, die ihre Bitcoins nun anders ausgeben oder ausgeben müssen (einschließlich des Verkaufs in andere Währungen), wenn eine solcher Hard-Fork umgesetzt wird. Die Annahme muss de facto durch die Verwendung der Hard-Fork Implementierung in der Praxis ausgedrückt werden (d. h. nicht nur öffentliche Unterstützung zum Ausdruck bringen – obwohl dies ein guter Schritt ist, um eine Einigung vor der Annahme des BIP zu erzielen). Diese Akzeptanz kann nicht garantiert von einer Supermehrheit begründet werden, es sei denn, sie zwingt die Minderheit buchstäblich, den Hard-Fork zu akzeptieren (ob dies praktikabel ist oder nicht, liegt außerhalb des Anwendungsbereichs dieses Dokuments).

Peer Services-BIPs sollten von mindestens 1 % der öffentlichen Knoten einen Monat lang angenommen werden.

API/RPC- und Anwendungsschicht-BIPs müssen von mindestens zwei unabhängigen und kompatiblen Softwareanwendungen implementiert werden.

Software-Autoren werden gebeten, eine Übersicht zu veröffentlichen, welche BIPs ihre Software unterstützt, um zur Überprüfbarkeit von Statusänderungen beizutragen. Ein gutes Beispiele dafür sind – Stand heute – Bitcoin Core doc/bips.md sowie Bitcoin Wallet for Android Wallet/README.specs.md.

Diese Kriterien gelten als objektive Methoden zur Beobachtung der faktischen Annahme des BIPs und dürfen nicht als Gründe für die Ablehnung oder Ablehnung eines BIP herangezogen werden. Sollte ein BIP tatsächlich und eindeutig angenommen werden, obwohl es die hier beschriebenen Kriterien nicht erfüllt, kann es dennoch auf den „Final“-Status aktualisiert werden.

Begründung

Im folgenden Antworten auf fragen der Community:

Warum ist dieses BIP überhaupt notwendig?

  • BIP 1 definiert ein mehrdeutiges Kriterium für das Statusfeld von BIPs, das häufig zu Verwirrung führte. Infolgedessen wurden viele BIPs mit erheblicher Nutzung in der Praxis länger als angemessen im „Draft“ oder „Proposed“ Status belassen. Durch die Angabe objektiver Kriterien zur Beurteilung des Fortschritts der BIPs soll dieser Vorschlag dazu beitragen, den Status korrekt und aktuell zu halten.

Wie wird die „Bitcoin-Ökonomie“ definiert, nur durch Personen die Waren/Dienstleistungen verkaufen und “Hodler”?

  • Damit Bitcoin als Währung funktioniert, muss es als Zahlung akzeptiert werden. Bitcoins haben keinen Wert, wenn man nichts im Austausch für sie erwerben können. Wenn jeder, der solche Zahlungen akzeptiert, ein bestimmtes Maß an Konsensregeln fordert, werden „Bitcoins“ de facto durch dieses Regelwerk definiert – das ist bereits heute der Fall. Wenn erwartet wird, dass sich diese Konsensregeln erweitern (wie bei einem Hard-Fork), müssen diese Händler Zahlungen akzeptieren, die im Rahmen des neuen Regelwerks getätigt werden, oder sie werden „Bitcoins“ als ungültig ablehnen. Die “Hodler” sind insofern relevant, als sie die Händler auswählen, bei denen sie ihre “nicht-unterstützenswerten” Fork-Coins ausgeben möchten. Sie könnten sich zu einem vollständigen Verkauf dieser Fork-Coins entscheiden, und dann unter der einen oder der anderen Konsensregeln verkaufen, wodurch der Markt dieser Coins überschwemmt und der Preis zum Absturz gebracht wird.

Warum sind <x></x> nicht in der Ökonomie enthalten?

  • <x></x> können bis zu einem gewissen Grad daran beteiligt sein, Waren und/oder Dienstleistungen im Austausch gegen Bitcoins anzubieten, also in dieser Eigenschaft in die Ökonomie einbezogen werden, aber nicht ihre Kapazität als <x></x>.

    Miner sind nicht Teil der Ökonomie, weil sie sich lediglich auf andere verlassen, um ihre sonst wertlosen Erträge verkaufen/auszugeben zu können. Daher müssen sie die Richtung aller anderen akzeptieren, wenn es darum geht, die Konsensregeln zu bestimmen.

    Börsen sind nicht Teil der Ökonomie, weil sie lediglich Dienstleistungen zur Verbindung der Händler und Nutzer, die Handel treiben wollen, anbieten. Selbst wenn alle Börsen von Bitcoin abwandern sollten, können diese Händler und Nutzer immer direkt handeln und/oder ihre eigenen Börsen gründen.

    Entwickler sind aucn nicht Teil der Ökonomie, da sie lediglich Code schreiben, und es ist an anderen, sich zu entscheiden, diesen Code zu verwenden oder nicht.

Miner/Börsen/Entwickler tun etwas Wichtiges und haben viel in Bitcoin investiert! Sollten sie nicht in eine so wichtige Entscheidung einbezogen werden?

  • Dieses BIP soll nicht darauf eingehen, was die Grundlage von Entscheidungen sein sollte. Eine solche Aussage, so perfekt sie auch sein mag, wäre sinnlos, ohne eine Möglichkeit, andere zu zwingen, sie zu benutzen. Der BIP-Prozess soll nicht eine Art kraftvolle „Governance“ von Bitcoin sein, sondern lediglich ein kollaboratives Repository für den Vorschlag und die Bereitstellung von Informationen über Standards, die Menschen freiwillig annehmen oder nicht. Sie kann nur hoffen, Genauigkeit in Bezug auf das Feld „Status“ zu erreichen, indem sie danach strebt, die Realität von *wie die Dinge tatsächlich sind* zu reflektieren, und nicht *wie sie sein sollten*.

Was ist, wenn ein einzelner Händler eine Hard-Fork blockieren möchte?

  • Dieses BIP befasst sich nur mit dem Verlauf des Feldes BIP-Status, und nicht wie der Hard-Fork (oder einer anderen Änderung) umgesetzt wird.
  • Unabhängig davon kann ein Verkäufer nicht in einem Vakuum arbeiten: Wenn er tatsächlich allein wäre, könnte er bald nicht mehr im Austausch gegen Bitcoin verkaufen, da niemand sonst bereit wäre, die alte Blockchain zu nutzen, und mit diesen Coin bezahlen. Wenn der Verkäufer nicht mehr verkaufen kann, erfüllt er nicht mehr die hierin getroffenen Kriterien, die das Veto ermöglichen.

Wie wäre es mit einer kleinen Anzahl von Händlern (vielleicht nur zwei), die Produkte miteinander verkaufen?

  • In diesem Szenario scheint es, dass der vorherige Bitcoin weiter am Leben bleibt, und dass der Hard-Fork gescheitert ist. Wie eine solche Aufteilung zu lösen ist, liegt außerhalb des Rahmens dieses BIP.

Wie kann ein Konsorzium von Marktteilnehmern ein Veto einlegen?

  • Die Gruppe der Miner wird durch die Konsensregeln für die Dynamic-Membership-Multi-Party-Signatur bestimmt (für Bitcoin, der Proof-of-Work-Algorithmus), die mit einer Hard-Fork geändert werden kann. Wenn also die gleichen Bedingungen, die für die Änderung dieser Gruppe erforderlich sind, im Gegensatz zu einer Soft-Fork erfüllt werden, ist die Miner-Mehrheit, die die SoftFork unterstützt, praktisch ungültig, weil die Ökonomie beschließen kann, sie durch eine andere Gruppe von Möchtegern-Mining zu ersetzen, die den Soft-Fork nicht unterstützen.

Was passiert, wenn sich die Ökonomie mehr als drei Monate später von einer umstrittenen Soft-Fork abwendet?

  • Die umstrittene Soft-Fork wechselt unter diesen Umständen vom Status „Final“ in „Obsolete“, um die Art des Hard-Fork widerzuspiegeln, die den vorherigen (“Final”) Soft-Fork ersetzt.

Wie hoch ist der ideale Prozentsatz der Knoten, die für die Annahme von Peer-Services-Vorschlägen erforderlich sind?

  • Dies ist unbekannt, und ziemlich willkürlich zu diesem Zeitpunkt gesetzt. Damit eine zufällige Auswahl von Peers mindestens einen anderen Peer hat, der die Erweiterung implementiert, wären 13% oder mehr notwendig, aber Knoten könnten weiterhin das Netzwerk für solche Peers scannen, mit einigermaßen vernünftigen Erfolg. Darüber hinaus gibt es Servicebits, um die Identifizierung im Voraus zu unterstützen.

Warum ist es notwendig, dass mindestens zwei Softwareprojekte eine Implementierung von API/RPC- und Anwendungs-BiPs veröffentlichen, bevor sie endgültig werden?

  • Wenn es nur eine Implementierung einer Spezifikation gibt, gibt es kein anderes Programm, für das eine Standardschnittstelle verwendet oder benötigt wird.
  • Auch wenn es nur zwei Projekte statt mehreren gibt, gibt es eine standardisierte Koordinierung zwischen ihnen.

Was ist, wenn ein BIP vorgeschlagen wird, das nur für ein einzelnes bestimmtes Projekt sinnvoll ist?

  • Der BIP-Prozess besteht für die Standardisierung zwischen unabhängigen Projekten. Wenn etwas nur ein Projekt betrifft, sollte es durch die internen Prozesse dieses Projekts durchgeführt werden und niemals als BIP vorgeschlagen werden.

BIP-Kommentare

Spezifikation

Jedes BIP Author sollte in seiner Präambel einen Link zu einer öffentlichen Wiki-Seite mit einer Einschätzung der Community erstellen. Rezensenten des BIP, die sich für qualifiziert halten, sollten ihre eigenen Kommentare auf dieser Wiki-Seite veröffentlichen. Die Kommentarseite sollte in der Regel nur verwendet werden, um letzte Kommentare für ein abgeschlossenes BIP zu posten. Wenn ein BIP noch nicht abgeschlossen ist, sollten Prüfer stattdessen im entsprechenden Entwicklungsmailinglistenthread posten, damit der/die BIP-Autor(en) alle bedenken oder Probleme beheben können, auf die in den Kommentaren hingewiesen wird.

Einige BIPs erhalten eine Exposition außerhalb der Entwicklungscommunity vor Abschluss, und andere BIPs sind möglicherweise überhaupt nicht abgeschlossen. Um zu vermeiden, dass kritische BIP-Bewertungen während dieses Zeitraums unbemerkt bleiben können, können Prüfer ihre Bewertung nach ihrer Wahl weiterhin auf der Kommentarseite veröffentlichen, vorausgesetzt, sie veröffentlichen sie zuerst auf der Mailingliste und planen, sie später zu entfernen oder zu überarbeiten, je nach fertiger Version. Solche Überarbeitungen sollten durch Bearbeiten der vorherigen Überprüfungen und Aktualisierung des Zeitstempels vorgenommen werden. Bewertungen, die vor der vollständigen Version gemacht wurden, können entfernt werden, wenn sie nicht mehr anwendbar sind und nicht rechtzeitig aktualisiert wurden (z. B. innerhalb eines Monats).

Seiten müssen nach der vollständigen BIP-Nummer (z. B. „BIP 0001“) benannt und im Namespace „Kommentare“ platziert werden. Die Verknüpfung für BIP-1 wird z. B. https://github.com/bitcoin/bips/wiki/Comments:BIP-0001 .

Kommentare, die in diesem Wiki veröffentlicht werden, sollten das folgende Format verwenden:

<Ihre Meinung> --<Ihr Name>, <Datum der Veröffentlichung, als YYYY-MM-DD>

BIPs können zusätzlich zum BIPs-Wiki auch ein zweites Forum für BIP-Kommentare auflisten. In diesem Fall sollte der URI des zweiten Forums unter dem URI des primären Wikis aufgeführt werden.

Nach einiger Zeit kann das BIP selbst mit der Community-Einschätzung aus den Kommentare aktualisiert werden. Diese Einschätzungen können aus den folgenden Optionen ausgewählt werden, aber dieses BIP beabsichtigt nicht, alle möglichen Nuancen abzudecken, und andere Zusammenfassungen können bei Bedarf verwendet werden:

  • Noch keine Kommentare.
  • Einstimmig für die Umsetzung
  • Einstimmig gegen die Umsetzung
  • Mehrheit für die Implementierung, mit etwas Kritik
  • Mehrheit gegen die Umsetzung, mit einigen Befürwortern

Beispielsweise kann die Präambel zu BIP 1 um folgende Zeile aktualisiert werden :

    Comments-Summary: No comments yet.
    Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001
                  https://some-other-wiki.org/BIP_1_Comments

Diese Felder müssen dem in BIP 1 definierten „Discussions-To“-Header folgen (wenn dieser Header nicht vorhanden ist, sollte er der Position folgen, an der er vorhanden wäre; in der Regel befindet sich dies direkt über dem Status-Header).

Um Zweifel zu vermeiden: Kommentare und Status sind nicht verwandte Metriken, um ein BIP zu beurteilen, und keines von beiden sollte das andere direkt beeinflussen.

Begründung

Was ist der Zweck von BIP-Kommentaren?

  • Verschiedene BIPs wurden umgesetzt (und haben dadurch die erforderlich Kriterien für den „Final“ Status erfüllt), obwohl sie allgemein als nicht ratsam erachtet werden. Einige betrachten BIPs derzeit als „implementierenswert“, nur weil ihnen eine BIP-Nummer zugewiesen wurde. Aufgrund der geringen Eintrittsbarriere für die Einreichung neuer BIPs erscheint es ratsam, dass Gutachter ihre Meinung dazu in einer Weise äußern können, die der Öffentlichkeit zugänglich ist, ohne die gesamte Entwicklungsdiskussion überprüfen zu müssen.

Werden BIP-Kommentare zensiert oder auf bestimmte Teilnehmer/“Experten“ beschränkt?

  • Teilnehmer sollten davon absehen, außerhalb ihres Wissens- oder Fachbereichs zu kommentieren. Kommentare sollten jedoch nicht zensiert werden, und die Teilnahme sollte der Öffentlichkeit zugänglich sein.

BIP-Lizenzierung

Spezifikation

Neue BIPs können mit den folgenden Lizenzen akzeptiert werden. Jedes neue BIP muss mindestens eine akzeptierbare Lizenz in seiner Präambel ausweisen. Der Lizenz-Header in der Präambel muss nach dem Created-Header platziert werden. Jede Lizenz muss durch die unten angegebene Abkürzung referenziert werden.

Eine Präambel kann z. B. den folgenden Lizenzheader enthalten:

    License: BSD-2-Clause
             GNU-All-Permissive

In diesem Fall ist der BIP-Text sowohl unter der OSI-zugelassenen BSD 2-Klausel-Lizenz, als auch unter der GNU All-Permissive License vollständig lizenziert, und jeder kann den Text ändern und weiterverteilen, sofern er den Bedingungen einer der Lizenzen entspricht. Mit anderen Worten, die Lizenzliste ist eine „ODER-Auswahl“, keine „AND auch“-Anforderung.

Es ist auch möglich, Quellcode anders als der BIP-Text zu lizenzieren. Ein optionaler License-Code-Header wird nach dem Lizenzheader platziert. Auch hier muss auf jede Lizenz mit ihrer nachstehenden Abkürzung verwiesen werden.

Eine Präambel, die den optionalen License-Code-Header angibt, könnte z. B. wie folgt aussehen:

    License: BSD-2-Clause
             GNU-All-Permissive
    License-Code: GPL-2.0+

In diesem Fall ist der Code im BIP nicht unter den BSD- oder All-Permissive-Lizenzen verfügbar, sondern nur unter den Bedingungen der GNU General Public License (GPL), Version 2 oder neuer. Wenn der Code *nur* als Version 2 verfügbar sein sollte, sollte das „+“-Symbol aus der Lizenzkürzel entfernt werden. Für eine neuere Version (z. B. GPL 3.0) würden Sie die Versionsnummer erhöhen (und das „+“ je nach Absicht beibehalten oder entfernen).

    License-Code: GPL-2.0   # Bedeutet nur GPL v2.0, keine spätere 
                              Version wird akkzeptiert.
    License-Code: GPL-2.0+  # Bedeute GPL v2.0 oder höher.
    License-Code: GPL-3.0   # Bedeutet nur GPL v3.0, keine spätere 
                              Version wird akkzeptiert. 
    License-Code: GPL-3.0+  # Bedeute GPL v3.0 oder höher.

Für den Fall, dass die Lizenzierung für den Text oder Code zu kompliziert ist, um sie mit einer einfachen Liste von Alternativen auszudrücken, sollte die Liste stattdessen durch den einzigen Begriff „Komplex“ ersetzt werden. In allen Fällen müssen Details zu den Lizenzbedingungen sowieso im Copyright-Bereich des BIP angegeben werden.

BIPs müssen nicht ausschließlich unter genehmigten Bedingungen lizenziert sein und können auch zusätzlich unter inakzeptablen Lizenzen, aber unter mindestens einer akzeptierbaren Lizenz lizenziert werden. In diesem Fall sollten nur die zulässigen Lizenzen in den Headern Lizenz und Lizenzcode aufgeführt werden.

Empfohlene Lizenzen

Darüber hinaus wird empfohlen, dass im BIP enthaltener Literalcode unter den gleichen Lizenzbedingungen wie das projektändernde Projekt doppelt lizenziert wird. Beispielsweise wäre literaler Code, der für Bitcoin Core vorgesehen ist, idealerweise unter den MIT-Lizenzbedingungen sowie einer der oben genannten mit dem Rest des BIP-Textes doppelt lizenziert.

Nicht empfohlene, aber akzeptable Lizenzen

Nicht akzeptierbare Lizenzen

Alle Lizenzen, die nicht explizit in den obigen Listen enthalten sind, sind keine akzeptablen Bedingungen für einen Bitcoin-Verbesserungsvorschlag, es sei denn, ein späteres BIP erweitert diese. BIPs, die vor dem Inkrafttreten dieses BIP entstanden sind, waren jedoch unter anderen Bedingungen zulässig und sollten folgende Abkürzung verwenden, wenn keine andere Lizenz erteilt wird:

Begründung

BIP 1 erlaubte die Open Publication License oder die Freigabe in die öffentliche Domäne; war das nicht ausreichend?

  • Die OPL gilt allgemein als veraltet und ist nicht als Lizenz für neue Veröffentlichungen geeignet.
  • Viele sind mit den OPL-Begriffen nicht vertraut und bevorzugen lieber die öffentliche Domäne als die Lizenz unter unsicheren Bedingungen.
  • Die OPL-Lizenzbedingungen erlaubten es dem Autor, Veröffentlichungen und abgeleitete Werke zu verhindern, was weithin als ungeeignet für Bitcoin-Standards angesehen wurde.
  • OPL wird nicht global als legitime Handlung anerkannt, daher ist er nicht ratsam diese zu nutzen.

Warum sind Softwarelizenzen enthalten?

  • Einige BIPs, insbesondere die Konsensschicht, können literalen Code in das BIP selbst aufnehmen, der möglicherweise nicht unter den genauen Lizenzbedingungen des BIP verfügbar ist.
  • Trotzdem wären nicht alle Softwarelizenzen für Inhalte in BIPs akzeptabel.

Warum ist Public Domain für neue BIPs nicht mehr akzeptabel?

  • In einigen Rechtsordnungen wird public domain nicht als legitime rechtliche Handlung anerkannt, so dass das BIP einfach urheberrechtlich geschützt ist, ohne dass eine Weitergabe oder Änderungen überhaupt nicht erlaubt wären.

Änderungen ab BIP 1

  • Akzeptierbare Lizenzen werden vollständig neu gewählt, was eine Vielzahl offener Lizenzen ermöglicht und gleichzeitig die problematischen älteren Optionen verbietet.
  • Der Status “Accepted” wurde in „Proposed“ umbenannt.
  • Eine Implementierung ist nun (falls zutreffend) erforderlich, bevor BIPs zum „Proposed“ Status übergehen können.
  • BIP-Kommentare werden neu eingeführt.
  • Die Header der Lizenzpräambel wurden hinzugefügt.
  • Der Layer-Header ist aus BIP 123 enthalten.
  • Nicht-Bild-Hilfsdateien sind im Unterverzeichnis bip-XXXX zulässig.
  • E-Mail-Adressen sind jetzt für Autoren erforderlich.
  • Der Post-History-Header kann als Link anstelle eines einfachen Datums bereitgestellt werden.
  • Das Markdown-Format ist für BIPs nicht mehr zulässig.
  • Der Resolution-Header wurde gelöscht, da er nicht auf ein dezentralisiertes System anwendbar ist, in dem keine Befugnis besteht, endgültige Entscheidungen zu treffen.

Siehe auch