Standardité et politique

Curiosité

1. Pourquoi une transaction valide est-elle parfois rejetée par un portefeuille avant même d’atteindre un mineur ?
2. Que se passe-t-il si une contrepartie utilise un logiciel différent du vôtre, mais que les deux sont « corrects » ?
3. Comment le fait de tenir les opcodes inutilisés à l’écart du relais peut-il protéger les futures mises à niveau ?

Explorer

1. Les règles de consensus définissent la validité ; elles déterminent ce qui peut figurer dans un bloc et être accepté par tous les nœuds. La standardité est une politique locale distincte qui détermine quelles transactions un nœud donné relaie à ses pairs et conserve dans son mempool. Une transaction peut être parfaitement valide selon le consensus tout en étant non standard au regard des politiques de relais par défaut. Lorsqu’un utilisateur diffuse une telle transaction, son propre nœud peut la rejeter immédiatement, même si les mineurs pourraient techniquement l’inclure.
2. Les types de sortie standard sont strictement limités afin de protéger les nœuds contre les attaques par déni de service et l’épuisement des ressources. Ils comprennent P2PKH, P2SH, P2WPKH, P2WSH, P2TR, les petits scripts multisig nus (jusqu’à trois clés) et les sorties de données OP_RETURN d’une taille donnée. Les scripts utilisant des opcodes réservés ou inconnus, ou dépassant les limites de taille, ne sont pas relayés par défaut. Ce filtrage permet de garder le mempool gérable et empêche des acteurs malveillants d’inonder le réseau de données inutiles, complexes et coûteuses en calcul.
3. La politique n’est pas figée ; elle évolue selon chaque implémentation de nœud. En 2025, les développeurs de Bitcoin Core ont décidé d’assouplir la limite de taille par défaut des sorties de données OP_RETURN. Ce changement a suscité un débat parmi les opérateurs de nœuds, dont certains se sont opposés à cette extension et sont passés à un logiciel alternatif comme Bitcoin Knots afin de conserver les anciennes limites, plus strictes. Cette divergence montre que la standardité est un réglage local : deux nœuds exécutant des versions ou des forks différents peuvent relayer des sous-ensembles différents de transactions valides sans enfreindre le consensus.
4. Une transaction non standard mais valide peut tout de même être confirmée si elle contourne entièrement le réseau de relais par défaut. Des mineurs ont proposé des services de soumission directe, permettant aux utilisateurs d’envoyer des transactions directement dans leurs blocs, indépendamment de la politique des nœuds. Si un portefeuille compte sur le rejet pour non-standardité pour sa sécurité, en supposant qu’un script d’apparence invalide ne se propagera jamais, il s’expose à un risque : une contrepartie disposant d’un accès direct aux mineurs pourrait faire confirmer cette transaction. Cela crée une divergence de comportement, non de vérité, pouvant entraîner des mouvements de fonds inattendus ou des pertes.
5. La standardité sert de soupape de sécurité pour les futures mises à niveau par soft fork. En appliquant dès maintenant des règles plus strictes, comme traiter les opcodes NOP réservés aux mises à niveau comme non standards lors du relais, le protocole garantit une transition en douceur lorsqu’une mise à niveau resserre les règles de consensus. Comme les transactions utilisant ces opcodes réservés ne sont ni relayées ni minées par défaut, il en existe peu, voire aucune, lorsqu’un soft fork donne un sens à ces opcodes ; les nouvelles règles n’invalident donc rien de ce sur quoi les gens comptaient, et il est peu probable que des mineurs non mis à niveau minent un bloc que les nouvelles règles rejettent.
6. Lisez vous-même les vérifications de politique : dans le code source de Bitcoin Core, le fichier policy/policy.cpp contient IsStandard et IsStandardTx, qui énumèrent les types de sortie acceptés ainsi que les limites de taille ; la série « Waiting for confirmation » de Bitcoin Optech explique les raisons qui sous-tendent ces règles. Comparez-les avec les règles de consensus présentes dans le code de validation, et notez à quel point les règles de relais sont plus restrictives.

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.

• Bitcoin Core source code, policy/policy.cpp
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)
• Bitcoin Optech, 'Waiting for confirmation' series (2023)