Bulletin Bitcoin Optech #430

Perçage de trous TCP pour les nœuds domestiques

Bitcoin Optech souligne la discussion continue autour du perçage de trous TCP comme moyen de permettre aux nœuds derrière des routeurs résidentiels d’accepter des connexions entrantes. Les nœuds domestiques ne font généralement que des connexions sortantes, et l’activation par défaut récente du NAT‑PMP dans Bitcoin Core 30.0 n’a pas nettement amélioré la visibilité. Le perçage de trous fonctionne en faisant ouvrir simultanément deux nœuds, ce qui permet aux routeurs de laisser passer le trafic. Les partisans soutiennent que davantage de nœuds honnêtes visibles rendraient plus difficile pour les nœuds contrôlés par des attaquants, plus faciles à atteindre, de remplir les créneaux sortants.

Problèmes de sécurité et modélisation des attaquants

Les critiques, notamment Anthony Towns, avertissent que le mécanisme pourrait être détourné. Il estime qu’un attaquant diffusant environ 10 000 adresses correspondrait rapidement à la plupart des nœuds honnêtes, augmentant potentiellement l’exposition. Towns suggère également des connexions entrantes aléatoires de courte durée comme alternative à moindre risque. Les données citées par Jonathan Harvey‑Buschel montrent que les nœuds honnêtes sont actuellement moins visibles que les nœuds attaquants, renforçant la nécessité d’une conception prudente. Le débat aborde aussi les récentes vulnérabilités TCP et de protocole, se demandant si le réglage par défaut devrait rester uniquement sortant pour les utilisateurs domestiques.

Projet de BIP pour les politiques de dépense des co‑signataires

Un fil séparé introduit un projet de BIP visant à standardiser les politiques des co‑signataires lors de l’émulation de clauses. La proposition définit une structure de politique en cinq parties — descripteur de sortie, groupe de co‑signataires, modèles de transaction, conditions et profils de vérification — garantissant au moins un chemin de dépense sans co‑signataire. Elle impose des attestations d’oracle compatibles DLC et laisse le format de sérialisation (JSON vs TLV) ainsi que les détails de vérification masquée ouverts. Les retours ont souligné l’absence de drapeaux de finalité dans les profils de preuve et le besoin de hachages de politique pour s’engager sur la sémantique du vérificateur, que l’auteur prévoit d’ajouter.

Avancées du nettoyage du consensus BIP54

Le bulletin fait également le point sur le BIP54, qui vise à interdire les transactions dont la taille sans témoin est exactement de 64 octets et à limiter les scripts pré‑SegWit à 2 500 opérations de signature. Une pull request de Bitcoin Core active les nouvelles règles sur regtest, et un travail d’interopérabilité est en cours dans btcd. Antoine Riard prévoit une fenêtre d’activation réaliste dans la seconde moitié de 2027, sous réserve du consensus communautaire. Il note que la correction de l’horodatage conserve une fenêtre de 7 200 s, ne permettant que des ajustements modestes de la difficulté (~0,60 % par retarget) et limitant la portée des propositions de blocs futurs.

Implications pour la communauté

Pour les opérateurs de nœuds, le débat sur le perçage de trous met en évidence un compromis entre connectivité et surface d’attaque ; adopter la technique pourrait nécessiter des garde‑fous supplémentaires ou une coordination via Tor. Les développeurs de portefeuilles devraient suivre le projet de BIP sur les co‑signataires, car son adoption pourrait simplifier les constructions multi‑signatures et similaires aux clauses entre différentes implémentations. Enfin, les mineurs et parties prenantes du protocole devraient surveiller le calendrier du BIP54, car son activation éventuelle affectera les règles de validation des transactions et pourrait influencer la dynamique des frais.