BIP 54 resserre quatre cas limites historiques du consensus sans ajouter de nouvel opcode utilisateur ; Complete signifie que la spécification est achevée, pas activée sur Bitcoin mainnet.
Antoine Poinsot et Matt Corallo ont réuni dans BIP 54 quatre corrections ciblées : timewarp, blocs dont la validation est extrêmement coûteuse, faiblesse de l’arbre de Merkle liée aux transactions de 64 octets et risque futur de transactions coinbase dupliquées. Le paquet n’ajoute aucun opcode utilisateur. [1]
À chaque frontière d’une période de 2016 blocs, le BIP impose au timestamp du premier bloc d’être au moins égal à celui du bloc précédent moins 7 200 secondes et à celui du dernier d’être au moins égal au premier de la période. Cela ferme le timewarp classique et une période Murch–Zawy négative. [1]
Pour chaque transaction hors coinbase, il fixe un plafond de 2 500 legacy signature operations comptées dans scriptSig, scriptPubKey et le P2SH redeemScript. Selon le BIP, le pire temps de validation est ainsi réduit d’environ quarante fois sans toucher les transactions standard ordinaires. [1]
Les transactions dont la sérialisation sans witness data mesure exactement 64 octets deviendraient invalides après activation. Ces mêmes 64 octets peuvent sinon être interprétés comme les deux hashes d’un nœud interne de l’arbre de Merkle, ce qui complique les preuves simplifiées sûres. [1]
La coinbase devrait avoir nLockTime égal à la hauteur du bloc moins 1 et nSequence différent de 0xffffffff. Chaque future coinbase se distingue alors des exceptions historiques et le contrôle BIP 30 peut être définitivement omis après activation avant la hauteur risquée la plus proche, 1 983 702. [1]
La spécification a atteint la version 1.0.0 et le statut Complete en mai 2026. Son changelog indique le 22 mai ; Bitcoin Core possède une implémentation de référence sans activation mainnet et produit déjà des modèles de blocs plus compatibles, mais rien de cela n’active les nouvelles règles à lui seul. [3]
Le projet BIP 95 pour Testnet 5 prévoit BIP 54 dès le bloc 1, mais reste lui-même Draft. Un réseau de test, signet ou du code inactif aide à vérifier une implémentation ; ce n’est pas la preuve d’un consensus mainnet. [4]
Pour vérifier une affirmation, il faut consulter la version actuelle du BIP, l’état de tout mécanisme d’activation et la version exacte du nœud. Complete qualifie un document achevé ; la validation complète des nouvelles règles ne commence qu’après une activation séparée du soft fork, si elle a lieu. [2]
Pour une vision complète, lisez aussi Règles de consensus, Soft Fork, Timewarp Attack, Proof of Work, Bitcoin Core, Transaction. Cette entrée est également citée par Timewarp Attack.
01BIP 54 est-il actif sur Bitcoin mainnet ?+
Non. La spécification est Complete et une implémentation sans activation mainnet existe, mais les restrictions de consensus exigent un processus d’activation distinct.
02Que change précisément Consensus Cleanup ?+
Il resserre les timestamps aux frontières des périodes de difficulté, plafonne les legacy sigops par transaction, interdit les transactions d’exactement 64 octets sans witness data et impose l’unicité des futures coinbase.