BIP-2

La refonte du processus BIP

BIP-2, écrit par Luke Dashjr et adopté en février 2016, remplace BIP-1 comme document de référence pour la procédure des Bitcoin Improvement Proposals. Cinq ans après le premier essai d'Amir Taaki, l'expérience accumulée justifiait une refonte plus rigoureuse, notamment pour distinguer les types de propositions et clarifier la notion de « consensus » dans une communauté sans autorité centrale.

Les ajouts majeurs

Par rapport à BIP-1, BIP-2 introduit :

1. Trois types clairs : Standards Track, Informational, Process.
2. Sous-types Standards : Consensus (modifie les règles), Peer Services, API/RPC, Application.
3. Le statut Active : pour les BIP « vivants » comme BIP-2 lui-même.
4. Critères objectifs pour passer de Draft à Proposed (implémentation de référence, discussion sur la mailing list).
5. Critères de Final : déploiement effectif, adoption mesurable.

Workflow révisé

Draft → Proposed → ┬→ Final (déployé, immuable)
                   ├→ Active (procédural, modifiable)
                   ├→ Replaced (remplacé par un autre)
                   ├→ Withdrawn (auteur abandonne)
                   ├→ Rejected (BIP editor refuse)
                   └→ Obsolete (plus pertinent)

Le rôle des BIP editors

BIP-2 formalise le rôle de BIP editor : il garde le repo bitcoin/bips, assigne les numéros, applique les exigences formelles (markdown, structure, copyright). Il ne peut pas refuser un BIP pour des raisons techniques, seulement pour des raisons de forme ou de motivation incohérente. Le consensus technique se fait ailleurs : mailing list, conférences, code review sur Bitcoin Core.

Limites et critiques

BIP-2 a été parfois critiqué pour ses critères flous : qui décide qu'un BIP est « Final » ? Comment quantifier l'adoption ? La pratique a évolué : un BIP devient Final lorsque l'écosystème l'a clairement intégré (wallets, nœuds, signaling miners). Le processus reste non-contraignant : un BIP n'est pas une loi, juste un standard de référence.

À retenir

BIP-2 régit aujourd'hui la majorité des propositions Bitcoin. Comprendre son workflow permet de lire correctement le statut d'une proposition (Taproot était Active avant activation, puis Final après) et de saisir comment Bitcoin évolue sans autorité centrale.