43 / 691BIP

BIP (Bitcoin Improvement Proposal)

Proposition d’amélioration de Bitcoin

Une proposition d'amélioration Bitcoin (BIP) est un document numéroté et versionné dans le référentiel public Bitcoin/bips qui décrit les normes techniques, les informations ou les processus liés au Bitcoin. Publier un BIPu signifie respecter les règles du référentiel, et non l'adoption du Bitcoin ou parvenir à un consensus.

Le processus actuel est géré par le BIP 3 déployé. N'importe qui peut rédiger une proposition, mais le numéro est attribué et le document est publié par les éditeurs du BIP. Les BIP sont divisés en spécifications, informations et processus, passent par les états brouillon, complet, déployé et fermé et restent une recommandation des auteurs ; l'adoption réelle ne se produit que par la mise en œuvre, l'utilisation et éventuellement l'activation en dehors du référentiel lui-même. (Specification) (Informational) (Draft) (Deployed) (Closed)

BIP est le document de proposition publique pour Bitcoin. Il peut définir une fonctionnalité technique, une règle d'interopérabilité, un processus, une recommandation ou un historique. Le référentiel donne à la conception un point de référence stable et conserve un historique des modifications. BIP n'est pas une loi, une commande de protocole ou une mise à jour automatique ; un nœud applique uniquement les règles contenues dans le logiciel qu'il exécute réellement.

Le BIP 3, nommé Processus BIP mis à jour, a le statut Déployé et a remplacé le BIP 2. Le processus a clarifié le flux de travail, limité l'espace de prise de décision des éditeurs, remplacé l'ancienne catégorie Standards Track par la catégorie Spécification et simplifié les statuts. Dans le même temps, il est dit explicitement que le référentiel est un support de publication et une archive, et non un système de vote ou un compteur d'acceptation.

Le travail commence avant GitHub. L'auteur doit passer en revue des propositions plus anciennes et discuter d'une idée spécifique sur la liste de diffusion de développement Bitcoin. Seule une proposition suffisamment élaborée est envoyée sous forme de pull request sans son propre numéro. L'éditeur BIP attribue un numéro si le texte est thématiquement pertinent, correctement formaté et clairement au-delà du stade de l'idée ; puis le publie en le fusionnant dans le référentiel.

La spécification BIP définit des règles techniques implémentables en matière de fonctionnalité ou d'interopérabilité ; il doit avoir une implémentation de référence et des vecteurs de test complets avant l'état Complete. Le BIP informationnel décrit un problème de conception, une recommandation ou une information. Process BIP modifie le processus autour de Bitcoin et, après le déploiement, peut fonctionner comme un document de processus mis à jour en permanence.

Brouillon signifie une proposition en cours. Complete indique que les auteurs considèrent que les travaux prévus sont terminés et recommandent leur adoption ou leur mise en œuvre ; il doit y avoir des documents de mise en œuvre et de test pour la spécification BIPu. Déployé signifie une utilisation active documentée ou, dans le cas du processus BIP, un consensus approximatif requis. Fermé indique un document qui n'est plus activement travaillé ou utilisé ; reste préservé pour l’histoire.

Les éditeurs du BIP examinent la portée, le format, les discussions préalables, la licence et l'état de préparation, attribuent des numéros et gèrent les métadonnées. Selon le BIP 3, il ne leur appartient pas de décider si la proposition sera acceptée. Par conséquent, la simple publication d’un BIP controversé ne confirme pas sa sécurité, son exactitude, sa popularité ou le consensus communautaire.

Le numéro sert principalement de référence stable. Le BIP 39 est une norme mnémonique largement utilisée, le BIP 141 décrit les règles de SegWit, le BIP 174 définit le PSBT et le BIP 50 est l'autopsie de la scission de mars 2013. Les autres BIP numérotés restent en projet ou fermés. Le chiffre lui-même ne dit rien sur l’importance, la mise en œuvre ou l’approbation.

Une spécification peut exister sans implémentation de production, un logiciel expérimental peut implémenter une ébauche et le déploiement ou l'activation sont des événements distincts. Pour les changements consensuels, la différence est cruciale : un BIP peut définir de nouvelles règles, une autre façon de les déployer, et un nœud ne commence à les appliquer que lorsque son logiciel et ses conditions d'activation le déterminent.

BIP 141 est la spécification BIP, dont les règles sont devenues partie intégrante du consensus Bitcoin après l'activation de SegWit. BIP 174 est un format d'interopérabilité des portefeuilles et des signataires sans modifier la validité des blocs. Le BIP 50 documente l'incident. Le BIP 3 lui-même est un BIP de processus. La phrase « BIP a été reçu » peut donc signifier des choses fondamentalement différentes selon les types.

Un BIP moderne contient des métadonnées telles que le statut, le type, la date d'attribution du numéro, la licence, les liens de discussion, la version et éventuellement les besoins, les remplacements et les remplacements proposés. Une fois terminé, les modifications plus importantes sont écrites dans le journal des modifications avec des versions similaires au versionnage sémantique. Une modification rétrocompatible apportée à une spécification mature devrait généralement donner lieu à un nouveau BIP, et non changer discrètement la signification de l'ancien numéro.

Commencez toujours par la version actuelle dans le référentiel officiel, et non par une capture d'écran ou un ancien article. Vérifiez le type, le statut, la version, les auteurs, les discussions, les dépendances et le journal des modifications. Vérifiez ensuite de manière indépendante la prise en charge dans le logiciel concerné et, pour la conception, le déploiement et l'activation consensuels. La question clé n'est pas « le BIP existe-t-il ? », mais « que précise-t-il exactement, qui le met en œuvre et quelles preuves montrent qu'il est réellement actif ? ».

Pour une vision complète, lisez aussi Soft Fork, Règles de consensus, Bitcoin Core, Bitcoin, Hard Fork, BIP 39. Cette entrée est également citée par Soft Fork, Guerre de la taille des blocs, Bitcoin Core.

DOC · 001BIP 3 — Updated BIP ProcessSpécification ↗DOC · 002bitcoin/bips — official BIP repositorySource primaire ↗DOC · 003BIP 123 — BIP ClassificationSpécification ↗DOC · 004BIP 1 — BIP Purpose and GuidelinesDocumentation ↗DOC · 005BIP 2 — BIP process, revisedDocumentation ↗DOC · 006BIP 39 — Mnemonic codeSpécification ↗DOC · 007BIP 141 — Segregated WitnessSpécification ↗DOC · 008BIP 174 — PSBTSpécification ↗DOC · 009BIP 50 — March 2013 chain fork post-mortemDocumentation ↗DOC · 010Bitcoin Core — supported BIPsDocumentation ↗
Révisé le 1er août 2026Sources d’abord · Pas un conseil financier