La Newsletter de Bitcoin Optech en français

• LDK 0.0.111 ajoute la création, la réception et la relayage d’ onion messages, parmi plusieurs autres nouvelles fonctionnalités et apporte des corrections de bogues.

Changements notables dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), et Lightning BOLTs.

• Bitcoin Core #25614 construit sur Bitcoin Core #24464, permettant la possibilité d’ajouter et de tracer des journaux avec des niveaux spécifiques de gravité dans addrdb, addrman, banman, i2p, mempool, netbase, net, net_processing, timedata, et torcontrol.
• Bitcoin Core #25768 corrige un bogue où le portefeuille ne rediffusait pas toujours de transactions enfants des transactions non confirmées. Le portefeuille intégré de Bitcoin Core tente périodiquement de diffuser ses transactions qui n’ont pas encore été confirmées. Certaines de ces transactions peuvent dépenser les sorties d’autres transactions non confirmées. Bitcoin Core rendait aléatoire l’ordre des transactions avant de les envoyer à une autre partie du code qui s’attendait à recevoir des transactions parentes non confirmées avant les transactions enfants (ou, plus généralement, tous les ancêtres non confirmés avant tout descendant). Lorsqu’une transaction enfant était reçue avant son parent, elle était rejetée en interne au lieu d’être rediffusée.
• Bitcoin Core #19602 ajoute un RPC migratewallet qui convertira un portefeuille en utilisant nativement descriptors. Cela fonctionne pour les portefeuilles pré-HD (ceux créés avant que BIP32 n’existe ou n’ait été adopté par Bitcoin Core), les portefeuilles HD et les portefeuilles de surveillance uniquement sans clés privées (watch-only). Avant d’appeler cette RPC, lisez la documentation et sachez qu’il existe certaines différences d’API entre les portefeuilles sans descripteurs et ceux qui prennent en charge nativement les descripteurs.

• Eclair #2406 ajoute une option pour configurer l’implémentation expérimentale interactive funding protocol pour exiger que les transactions d’ouverture de canal incluent uniquement les entrées confirmées — entrées qui dépensent les sorties faisant partie d’une transaction confirmée. S’il est activé, cela peut empêcher un initiateur de retarder l’ouverture d’un canal en le basant sur une grande transaction non confirmée avec un faible taux de commission (fee rate).
• Eclair #2190 supprime la prise en charge du format original des données “onion” de longueur fixe, dont la suppression de la spécification LN est également proposée dans BOLTs #962. Le format amélioré à longueur variable a été ajouté à la spécification il y a plus de trois ans et les résultats de l’analyse du réseau mentionnés dans le PR BOLTs #962 indiquent qu’il est pris en charge par tous les nœuds sauf 5 sur plus de 17 000 annoncés publiquement. Core Lightning a également supprimé le support plus tôt cette année (voir Newsletter #193).
• Rust Bitcoin #1196 modifie l’ajout précédent du type LockTime (voir Newsletter #211) pour devenir absolute::LockTime et ajoute un nouveau relative::LockTime qui représente les “locktimes” utilisés avec BIP68 and BIP112.

Sep 7, 2022

Cette semaine au sommaire de cette newsletter, plusieurs changements notables au logiciel de l’infrastructure Bitcoin.

Nouvelles

Pas de nouvelles signifiantes cette semaine.

Changements notables dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

• Bitcoin Core #25717 Ajout d’une étape de pré-synchronisation des entêtes (Headers Presync) durant le téléchargement initial des blocs (Initial Block Download – IBD) afin de prévenir d’une attaque par déni de service (DoS) ainsi qu’une étape vers la suppression des points de contrôle. Les noeuds utilisent la pré-synchronisation pour vérifier que la chaîne d’en-têtes d’un pair a suffisamment travaillé avant de la stocker de manière permanente.Au cours de l’IBD, un pair malicieux pourrait essayer de bloquer le process de synchronisation, injecter des blocs qui ne sont pas de la chaîne la plus longue, ou simplement épuiser les ressources du noeud. Ainsi, bien que la vitesse de synchronisation et l’usage de la bande passante soient des préoccupations importantes pendant l’IBD, un objectif principal de conception est d’éviter l’attaque par déni de service (DoS). Depuis la version v0.10.0, le noeud Bitcoin Core synchronise d’abord la première en-tête de block avant de télécharger les données du bloc et rejette les en-têtes qui ne respectent pas un ensemble de points de contrôle.Au lieu d’utiliser les valeurs codées en dur, cette nouvelle conception utilise les propriétés inhérentes de résistance à l’attaque de déni de service du schéma de la preuve de travail (Proof of Work – PoW) pour réduire la quantité de mémoire allouée avant de trouver la chaîne principale.Avec ces changements, les noeuds téléchargent deux fois les en-têtes durant la synchronisation de l’en-tête initiale: une première fois pour vérifier l’en-tête de la preuve de travail (sans la stocker) jusqu’à ce que le travail accumulé rencontre un seuil prédéterminé, puis une seconde passe pour les mémoriser. Afin de prévenir qu’un attaquant envoie la chaîne principale lors de la pré-synchronisation et ensuite une différente, une chaîne malicieuse lors du re-téléchargement, le noeud stocke les engagements envers la chaîne d’en-têtes pendant la pré-synchronisation.
• Bitcoin Core #25355 Ajout du support pour remplacer l’adresse I2P fixe par une adresse I2P temporaire par connexion seulement quand la sortie I2P connections est autorisée. Dans I2P, celui qui reçoit apprend l’adresse I2P de la connexion de l’initiateur. Les noeuds I2P qui n’acceptent pas de connexions entrantes utiliseront maintenant par défaut les adresses I2P temporaires lorsqu’ils établissent des connexions sortantes.
• BDK #689 ajout d’une méthode allow_dust autorisant un portefeuille à créer une transaction qui ne respecte pas la limite de poussière dust limit. Bitcoin Core et les autres noeuds utilisant le même réglage ne relaieront plus les transactions non confirmées sans que toutes les sorties (excepté OP_RETURN) ne reçoivent plus de satoshis que la limite de poussières. BDK empêche généralement les utilisateurs de créer de telles transactions non relayables en appliquant la limite de poussière sur les transactions qu’elle crée, mais cette nouvelle option permet d’ignorer cette politique. L’auteur du PR mentionne qu’ils l’utilisent pour tester leur portefeuille.
• BDK #682 ajoute des capacités de signature pour les dispositifs de signature matérielle utilisant HWI et la librairie rust-hwi. Le PR introduit également un émulateur de périphérique Ledger pour les tests.

Source : https://bitcoinops.org/fr/publications/