Le bulletin de cette semaine annonce une divulgation prochaine de vulnérabilités affectant les anciennes versions de Bitcoin Core, décrit une proposition de BIP pour une nouvelle version de testnet, résume une proposition pour des covenants basés sur le chiffrement fonctionnel, examine une mise à jour de la proposition pour effectuer des opérations arithmétiques 64 bits dans Bitcoin Script, renvoie à un script pour valider la preuve de travail sur signet avec l’opcode OP_CAT, et examine une proposition de mise à jour de la spécification BIP21 des URI bitcoin:. Sont également incluses nos sections habituelles avec des annonces de mises à jour et versions candidates, ainsi que les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Divulgation à venir de vulnérabilités affectant les anciennes versions de Bitcoin Core : plusieurs membres du projet Bitcoin Core ont discuté sur IRC d’une politique de divulgation des vulnérabilités qui ont affecté les anciennes versions de Bitcoin Core. Pour les vulnérabilités de faible gravité, les détails seront divulgués environ deux semaines après la première version d’un Bitcoin Core qui élimine (ou atténue de manière satisfaisante) la vulnérabilité. Pour la plupart des autres vulnérabilités, les détails seront divulgués après que la dernière version de Bitcoin Core affectée par la vulnérabilité atteigne la fin de vie (ce qui est environ un an et demi après sa sortie). Pour les vulnérabilités critiques rares, les membres de l’équipe de sécurité de Bitcoin Core discuteront en privé du calendrier de divulgation le plus approprié.

    Une fois que ce calendrier sera défini en détail, les contributeurs commencerons à divulguer les vulnérabilités affectant Bitcoin Core 24.x et précédente. Il est fortement recommandé que tous les utilisateurs et administrateurs passent à Bitcoin Core 25.0 ou supérieur dans les deux prochaines semaines. L’idéal étant d’utiliser la version la plus récente possible, soit la dernière version (27.0 au moment de la rédaction) ou la dernière version dans une série de versions particulière (par exemple, 25.2 pour la série de versions 25.x ou 26.1 pour la série de versions 26.x).

    Comme cela a toujours été notre politique, Optech fournira des résumés de toutes les divulgations de sécurité significatives affectant l’un des projets d’infrastructure que nous surveillons (ce qui inclut Bitcoin Core).

  • ● BIP et mise en œuvre expérimentale de testnet4 : Fabian Jahr a posté sur la liste de diffusion Bitcoin-Dev pour annoncer une proposition de BIP pour testnet4, une nouvelle version de testnet conçue pour éliminer certains problèmes avec le testnet3 existant (voir le Bulletin #297). Jahr renvoie également à une pull request de Bitcoin Core avec une proposition de mise en œuvre. Testnet4 a deux différences notables par rapport à testnet3 :

    • ● Moins de retours à la difficulté-1 : il était facile (accidentellement ou délibérément) de réduire une période entière de 2 016 blocs à la difficulté minimale (difficulté-1) en minant le dernier bloc d’une période avec un horodatage de plus de 20 minutes après l’avant-dernier bloc. Désormais, la difficulté d’une période ne peut être ajustée qu’à la baisse, bien qu’il soit toujours possible d’exploiter tous les blocs individuels, à l’exception du premier bloc d’une nouvelle période, en difficulté-1 s’ils ont un horodatage plus de 20 minutes après le bloc précédent.

    • ● Correction du time warp : il était possible sur testnet3 (et également sur mainnet) de produire des blocs significativement plus rapidement qu’une fois toutes les 10 minutes sans augmenter la difficulté en exploitant l’attaque time warp. Testnet4 implémente maintenant la solution au time warp qui a été proposée dans le cadre du soft fork de nettoyage du consensus pour mainnet.

    Le BIP draft mentionne également quelques idées supplémentaires et alternatives pour testnet4 qui ont été discutées mais non utilisées.

  • ● Covenants de chiffrement fonctionnel : Jeremy Rubin a publié sur Delving Bitcoin son papier concernant l’utilisation théorique du chiffrement fonctionnel pour ajouter une gamme complète de comportements de covenant à Bitcoin sans besoin de changements de consensus. Fondamentalement, cela nécessiterait que les utilisateurs des covenants fassent confiance à un tiers, bien que cette confiance puisse être distribuée entre plusieurs parties où une seule d’entre elles aurait besoin d’avoir agi honnêtement à un moment donné.

    Le chiffrement fonctionnel permettrait essentiellement la création d’une clé publique qui correspondrait à un programme particulier. Une partie qui pourrait satisfaire le programme serait capable de créer une signature qui correspondrait à la clé publique (sans jamais découvrir une clé privée correspondante).

    Rubin note que cela a un avantage sur les propositions de covenant existantes en ce que toutes les opérations (à l’exception de la vérification de la signature résultante) se produisent off-chain et aucune donnée (à l’exception de la clé publique et de la signature) n’a besoin d’être publiée on-chain C’est toujours plus privé et économisera souvent de l’espace. Plusieurs programmes de covenant peuvent être utilisés dans le même script en effectuant plusieurs vérifications de signature.

    Outre le besoin d’une configuration de confiance, Rubin décrit l’autre inconvénient majeur du chiffrement fonctionnel comme étant une “cryptographie sous-développée qui rend son utilisation actuellement peu pratique”.

  • ● Mises à jour de la proposition de soft fork pour l’arithmétique 64 bits : Chris Stewart a publié sur Delving Bitcoin pour annoncer une mise à jour de sa proposition précédente d’ajouter la capacité de travailler avec des nombres 64 bits dans Bitcoin Script (voir les Bulletins #285 et #290). Les principaux changements sont :

    • ● Mise à jour des opcodes existants : au lieu d’ajouter de nouveaux opcodes comme OP_ADD64, les opcodes existants (par exemple, OP_ADD) sont mis à jour pour fonctionner avec des nombres 64 bits. Étant donné que l’encodage pour les grands nombres est différent de celui actuellement utilisé pour les petits nombres, les fragments de script qui sont mis à niveau pour utiliser de grands nombres peuvent nécessiter d’être révisés ; Stewart donne l’exemple de OP_CHECKLOCKTIMEVERIFY qui doit maintenant prendre un paramètre de 8 octets plutôt qu’un paramètre de 5 octets.

    • ● Le résultat inclut un booléen : une opération réussie place non seulement le résultat sur la pile, mais aussi un booléen sur la pile qui indique que l’opération a été réussie. Une raison courante pour laquelle une opération pourrait échouer est parce que le résultat est plus grand que 64 bits, dépassant la taille du champ. Le code peut utiliser OP_VERIFY pour s’assurer que l’opération a été réussie.

      Anthony Towns a répondu en plaidant pour une approche alternative où les opcodes par défaut échouent en cas de dépassement de capacité, plutôt que de nécessiter que les scripts vérifient en plus que les opérations ont été réussies. Pour les cas où il pourrait être utile de tester si une opération pourrait entraîner un dépassement de capacité, de nouveaux opcodes comme ADD_OF seraient disponibles.

  • ● Script OP_CAT pour valider la preuve de travail : Anthony Towns a posté sur Delving Bitcoin à propos d’un script pour signet qui utilise OP_CAT pour permettre à quiconque de dépenser des pièces envoyées au script en utilisant la preuve de travail (PoW). Cela peut être utilisé comme un faucet de signet-bitcoin décentralisé : quand un mineur ou un utilisateur obtient des bitcoins signet en excès, ils les envoient au script. Lorsqu’un utilisateur souhaite obtenir plus de bitcoins signet, il recherche dans l’ensemble UTXO les paiements au script, génère une PoW, et crée une transaction qui utilise leur PoW pour réclamer les pièces.

    Le post de Towns décrit le script et la motivation de plusieurs choix de conception.

  • ● Mise à jour proposée pour le BIP21 : Matt Corallo a posté sur la liste de diffusion Bitcoin-Dev à propos de la mise à jour de la spécification BIP21 pour l’URI bitcoin:. Comme discuté précédemment (voir le Bulletin #292), presque tous les portefeuilles Bitcoin utilisent le schéma URI différemment de ce qui était spécifié, et des changements supplémentaires dans les protocoles de facturation entraîneront probablement des changements supplémentaires dans l’utilisation du BIP21. Les principaux changements dans la proposition incluent :

    • ● Plus que base58check : BIP21 s’attend à ce que chaque adresse Bitcoin utilise l’encodage base58check, mais cela n’est utilisé que pour les adresses héritées pour les sorties P2PKH et P2SH. Les sorties modernes utilisent bech32 et bech32m. Les paiements futurs seront reçus aux adresses de paiement silencieux et le protocole offres de LN, qui seront très certainement utilisés comme charge utile de BIP21.

    • ● Corps vide : BIP21 exige actuellement qu’une adresse Bitcoin soit fournie dans la partie corps de la charge utile, avec des paramètres de requête fournissant des informations supplémentaires (telles qu’un montant à payer). Les nouveaux protocoles de paiement, comme le protocole de paiement BIP70, ont spécifié de nouveaux paramètres de requête à utiliser (voir BIP72), mais les clients qui ne comprenaient pas le paramètre se contentaient d’utiliser l’adresse dans le corps. Dans certains cas, les destinataires peuvent ne pas vouloir revenir à l’un des types d’adresses de base (base58check, bech32 ou bech32m), comme les utilisateurs soucieux de leur vie privée utilisant des paiements silencieux. La mise à jour proposée permet au champ du corps d’être vide.

    • ● Nouveaux paramètres de requête : la mise à jour décrit trois nouvelles clés : lightning pour les factures BOLT11 (actuellement utilisées), lno pour les offres LN (proposées), et sp pour les paiements silencieux (proposés). Elle décrit également comment les clés pour les futurs paramètres devraient être nommées.

    Corallo note dans son post que les changements sont sûrs pour tous les cas connus Les logiciels déployés comme portefeuilles ignoreront ou rejetteront tout URI bitcoin: qu’ils ne peuvent pas analyser avec succès.

Mises à jour et versions candidates

Nouvelles versions et versions candidates pour les principaux projets d’infrastructure Bitcoin. Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les versions candidates.

  • ● Core Lightning 24.05rc2 est un candidat à la version pour la prochaine version majeure de cette populaire implémentation de nœud LN.

  • ● Bitcoin Core 27.1rc1 est un candidat à la version pour une version de maintenance de l’implémentation de nœud complet prédominante.

Changements notables dans le code et la documentation

Changements récents notables dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Interface de Portefeuille Matériel (HWI), Rust Bitcoin, Serveur BTCPay, BDK, Propositions d’Amélioration de Bitcoin (BIPs), Lightning BOLTs, Lightning BLIPs, Inquisition Bitcoin, et BINANAs.

  • ● Core Lightning #7252 change le comportement de lightningd pour ignorer le paramètre ignore_fee_limits lors d’une fermeture de canal coopérative. Cela corrige un problème où un nœud qui ouvre des canaux Core Lightning (CLN) paie trop de frais lorsque la contrepartie est un nœud LDK. Dans ce scénario, lorsque le nœud non-ouvreur LDK (Alice) initie une fermeture de canal coopérative et commence la négociation des frais, le nœud ouvreur CLN (Bob) répond que les frais peuvent être n’importe quoi entre min_sats et max_channel_size en raison du paramètre ignore_fee_limits. LDK choisira “toujours le montant le plus élevé autorisé” (contrairement à la spécification des BOLTs), donc Bob choisit la limite supérieure, et Alice accepte, ce qui amènera Alice à diffuser une transaction avec des frais considérablement surévalués.

  • ● LDK #2931 améliore les journaux lors de la recherche de chemin pour inclure des données supplémentaires sur les canaux directs, par exemple, s’ils sont manquants, leur montant minimum HTLC, et leur montant maximum HTLC. L’ajout de journaux vise à mieux dépanner les problèmes de routage en fournissant une visibilité sur la liquidité disponible et les limitations de chaque canal.

  • ● Rust Bitcoin #2644 ajoute HKDF (HMAC (Hash-based Message Authentication Code) Extract-and-Expand Key Derivation Function) au composant bitcoin_hashes pour implémenter BIP324 dans Rust Bitcoin. HKDF est utilisé pour dériver des clés cryptographiques à partir d’une source de matériel de clé de manière sécurisée et standardisée. BIP324 (également connu sous le nom de transport P2P v2) est une méthode permettant aux nœuds Bitcoin de communiquer les uns avec les autres sur des connexions cryptées (activées par défaut dans Bitcoin Core).

  • ● BIPs #1541 ajoute BIP431 avec une spécification des transactions Topologically Restricted Until Confirmation (TRUC) (transactions v3) qui sont un sous-ensemble de transactions standard avec des règles supplémentaires conçues pour permettre le remplacement de transaction tout en minimisant le coût pour surmonter les attaques de transaction-pinning.

  • ● BIPs #1556 ajoute BIP337 avec une spécification des transactions compressées, un protocole de sérialisation pour compresser les transactions bitcoin afin de réduire leur taille jusqu’à 50%. Elles sont pratiques pour la transmission à faible bande passante comme par satellite, radio HAM, ou à travers la stéganographie. Deux commandes RPC sont proposées : compressrawtransaction et decompressrawtransaction. Voir le Bulletin #267 pour une explication plus détaillée du BIP337.

  • ● BLIPs #32 ajoute BLIP32 décrivant comment les instructions de paiement Bitcoin lisibles par l’homme basées sur une proposition DNS (voir le Bulletin #290) peuvent être utilisées avec les messages en onion pour permettre l’envoi de paiements à une adresse telle que bob@example.com. Par exemple, Alice donne instruction à son client LN de payer Bob. Son client peut ne pas être capable de résoudre de manière sécurisée les adresses DNS directement, mais il peut utiliser un message en onion pour contacter l’un de ses pairs qui annonce un service de résolution DNS. Le pair récupère l’enregistrement DNS TXT pour l’entrée bob à example.com et place les résultats ainsi qu’une signature DNSSEC dans une réponse de message en onion à Alice. Alice vérifie l’information et l’utilise pour demander une facture à Bob en utilisant le protocole offres.