Le processus BIP

Curiosité

1. Si un BIP n’est qu’un document, comment peut-il modifier le comportement de millions d’ordinateurs ?
2. Pourquoi les éditeurs attribuent-ils des numéros aux propositions sans jamais voter sur leur mérite ?
3. Qu’est-ce qui empêche un seul développeur d’imposer un changement de règle à l’ensemble du réseau ?

Explorer

1. Amir Taaki a introduit les Bitcoin Improvement Proposals (BIP) en août 2011, directement sur le modèle des PEP de Python. Le BIP1 a établi le cadre de documentation des modifications du protocole et des informations générales. Luke Dashjr l’a révisé en 2016 avec le BIP2, et en 2025, le BIP3, « Updated BIP Process », de Mark Erhardt, a remplacé le BIP2. D’abord hébergés sur un wiki, les BIP se trouvent désormais dans un dépôt sous contrôle de version sur GitHub, si bien que chaque modification est tracée et peut être examinée.
2. Selon le BIP3, il existe trois types. Les BIP de spécification décrivent des modifications du protocole ou de logiciels interopérables, comme de nouvelles règles de transaction, des normes de portefeuille ou des messages réseau. Les BIP informatifs fournissent des orientations ou du contexte sans rien exiger. Les BIP de processus décrivent le fonctionnement du développement lui-même, y compris le processus BIP. Les anciens BIP conservent l’étiquette « Standards Track » sous laquelle ils ont été rédigés, qui correspond à l’actuel type Spécification.
3. Chaque proposition est portée par ses auteurs, qui la rédigent, la défendent sur la liste de diffusion et lors des revues, et la révisent en réponse aux critiques. En être l’auteur ne confère aucun pouvoir d’en imposer l’adoption. Un BIP reste un document tant qu’un logiciel de nœud ou de portefeuille ne l’implémente pas et que des gens ne choisissent pas de faire tourner ce logiciel. Il n’y a pas de vote ; un changement de consensus ne se produit que si une part suffisante du réseau se met à jour.
4. Les discussions ont lieu sur la liste de diffusion bitcoin-dev, dans les pull requests soumises à la revue de code et lors de conférences. Il n’existe ni autorité formelle ni vote contraignant. Les éditeurs attribuent des numéros et vérifient la forme, mais ne décident pas de l’adoption. Selon le BIP3, le statut d’une proposition passe par « Draft », puis « Complete » lorsque ses auteurs la jugent terminée, puis « Deployed » une fois qu’elle est en usage ; les propositions abandonnées ou remplacées sont marquées « Closed ». Le champ de statut du dépôt reflète ce cycle de vie.
5. Des BIP bien connus illustrent l’impact de ce processus. Le BIP16 a introduit le Pay-to-Script-Hash (P2SH) en 2012. Le BIP32 a défini les portefeuilles hiérarchiques déterministes (HD), et le BIP39 a standardisé les phrases de récupération. Le BIP141 a mis en place Segregated Witness (SegWit), activé en août 2017 au bloc 481 824. Les BIP 340 à 342 ont introduit les signatures Schnorr et Taproot, activés en novembre 2021. Chacun a nécessité une coordination minutieuse entre développeurs, mineurs et utilisateurs pour garantir la rétrocompatibilité ou un fork propre.
6. Ouvrez le dépôt des BIP sur GitHub. Repérez trois BIP : un Standards Track (par exemple le BIP141), un Informational (par exemple le BIP50) et un Process (par exemple le BIP3). Lisez le champ de statut de chacun. Notez la date de création de chacun et l’évolution de son statut. Cet exercice montre que le mérite technique ne suffit pas : le consensus social et l’alignement économique sont les véritables gardiens de l’évolution de Bitcoin.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• 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