Cette semaine, le bulletin contient la dernière entrée de notre série hebdomadaire limitée sur la politique de la mempool, ainsi que nos sections régulières décrivant les changements notables apportés aux clients, aux services et aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

Aucune actualité significative n’a été trouvée cette semaine dans les listes de diffusion Bitcoin-Dev ou Lightning-Dev.

En attente de confirmation #10 : Impliquez-vous

La dernière entrée de notre série hebdomadaire limitée sur le relais des transactions, l’inclusion dans la mempool et la sélection des transactions minières - y compris pourquoi Bitcoin Core a une politique plus restrictive que celle autorisée par consensus et comment les portefeuilles peuvent utiliser cette politique de la manière la plus efficace.

Nous espérons que cette série a donné aux lecteurs une meilleure idée de ce qui se passe pendant qu’ils attendent une confirmation. Nous avons commencé par une discussion sur la façon dont certaines valeurs idéologiques de Bitcoin se traduisent dans sa structure et ses objectifs de conception. La structure distribuée du réseau pair à pair offre une résistance accrue à la censure et à la confidentialité par rapport à un modèle centralisé typique. Un réseau de relais de transactions ouvert permet à tout le monde d’apprendre les transactions dans les blocs avant la confirmation, ce qui améliore l’efficacité de la transmission des blocs, facilite l’adhésion en tant que nouveau mineur et crée une enchère publique pour l’espace des blocs. Comme le réseau idéal est composé de nombreuses entités indépendantes et anonymes exécutant des nœuds, le logiciel des nœuds doit être conçu pour se protéger contre les attaques par déni de service et minimiser les coûts opérationnels.

Les frais jouent un rôle important dans le réseau Bitcoin en tant que moyen “équitable” de résoudre la concurrence pour l’espace des blocs. Les pools de mémoire avec des algorithmes de remplacement de transactions et de sélection et d’éviction sensibles aux paquets utilisent la compatibilité des incitations pour mesurer l’utilité de stocker une transaction et permettent aux utilisateurs de bénéficier de mécanismes d’augmentation des frais tels que RBF et CPFP. La combinaison de ces politiques de pool de mémoire, de portefeuilles qui construisent des transactions de manière économique et d’une bonne estimation des frais crée un marché efficace pour l’espace des blocs qui profite à tous.

Les nœuds individuels appliquent également une politique de relais de transactions pour se protéger contre l’épuisement des ressources et exprimer leurs préférences personnelles. À l’échelle du réseau, les règles de normalité et d’autres politiques protègent les ressources essentielles à l’évolutivité, à l’accessibilité de l’exécution d’un nœud et à la capacité de mettre à jour les règles de consensus. Comme la grande majorité du réseau applique ces politiques, elles sont une partie importante de l’interface sur laquelle les applications Bitcoin et les protocoles L2 se basent. Elles ne sont cependant pas parfaites. Nous avons décrit plusieurs propositions liées aux politiques qui abordent des limitations générales et des cas d’utilisation spécifiques tels que les attaques d’épinglage sur les transactions de règlement L2.

Nous avons également souligné que l’évolution continue des politiques du réseau nécessite une collaboration entre les développeurs travaillant sur les protocoles, les applications et les portefeuilles. À mesure que l’écosystème Bitcoin se développe en termes de logiciels, de cas d’utilisation et d’utilisateurs, un processus de prise de décision décentralisé devient de plus en plus nécessaire mais aussi plus difficile. Même si l’adoption de Bitcoin augmente, le système émerge des préoccupations et des efforts de ses parties prenantes—il n’y a pas d’entreprise chargée de recueillir les commentaires des clients et d’embaucher des ingénieurs pour développer de nouvelles fonctionnalités de protocole ou supprimer les fonctionnalités inutilisées. Les parties prenantes qui souhaitent faire partie du consensus approximatif du réseau ont différentes façons de participer : s’informer, soulever des questions et des problèmes, s’impliquer dans la conception du réseau, voire contribuer à la mise en œuvre d’améliorations. La prochaine fois que votre transaction prendra trop de temps à se confirmer, vous saurez quoi faire !

Modifications apportées aux services et aux logiciels clients

Dans cette rubrique mensuelle, nous mettons en évidence les mises à jour intéressantes des portefeuilles et services Bitcoin.

• ● Le portefeuille 10101 bêta teste la mise en commun des fonds entre les LN et les DLC : 10101 a annoncé un portefeuille construit avec LDK et BDK qui permet aux utilisateurs de négocier des dérivés sans garde en utilisant des DLCs dans un contrat hors chaîne qui peut également être utilisé pour envoyer, recevoir et transférer des paiements LN. Les DLC reposent sur des oracles qui utilisent des signatures d’adaptateur pour l’attestation des prix.

• ● LDK Node annoncé : L’équipe LDK a annoncé LDK Node v0.1.0. LDK Node est une bibliothèque Rust de nœud Lightning qui utilise les bibliothèques LDK et BDK pour permettre aux développeurs de configurer rapidement un nœud Lightning auto-hébergé tout en offrant un degré élevé de personnalisation pour différents cas d’utilisation.

• ● Payjoin SDK annoncé : Payjoin Dev Kit (PDK) a été annoncé en tant que bibliothèque Rust qui implémente BIP78 pour une utilisation dans les portefeuilles et les services souhaitant intégrer la fonctionnalité payjoin.

• ● Annonce de la version bêta de Validating Lightning Signer (VLS) : VLS permet de séparer un nœud Lightning des clés qui contrôlent ses fonds. Un nœud Lightning fonctionnant avec VLS routera les demandes de signature vers un dispositif de signature distant au lieu des clés locales. La version bêta prend en charge CLN et LDK, les règles de validation de la couche 1 et de la couche 2, les capacités de sauvegarde/récupération et fournit une implémentation de référence. L’annonce du blog appelle également à des tests, des demandes de fonctionnalités et des commentaires de la communauté.

• ● BitGo ajoute la prise en charge de MuSig2 : BitGo a annoncé la prise en charge de BIP327 (MuSig2) et a pointé les frais réduits et la confidentialité supplémentaire par rapport à leurs autres types d’adresses pris en charge.

• ● Peach ajoute la prise en charge de RBF : L’application mobile Peach Bitcoin pour l’échange pair à pair a annoncé la prise en charge de l’augmentation des frais Replace-By-Fee (RBF).

• ● Le portefeuille Phoenix ajoute la prise en charge du splicing : ACINQ a annoncé les tests bêta de la prochaine version de leur portefeuille mobile Lightning Phoenix. Le portefeuille prend en charge un seul canal dynamique qui est rééquilibré en utilisant le splicing et un mécanisme similaire à la technique swap-in-potentiam (voir Podcast #259).

• ● Appel à commentaires sur le Mining Development Kit (MDK) : L’équipe travaillant sur le Mining Development Kit (MDK) a publié une mise à jour sur leurs progrès pour développer du matériel, des logiciels et des micrologiciels pour les systèmes de minage de Bitcoin. L’article appelle à des commentaires de la communauté sur les cas d’utilisation, la portée et l’approche.

• ● Binance ajoute la prise en charge de Lightning : Binance a annoncé la prise en charge de l’envoi (retraits) et de la réception (dépôts) en utilisant le réseau Lightning.

• ● Nunchuk ajoute la prise en charge de CPFP : Nunchuk a annoncé la prise en charge de l’augmentation des frais Child-Pays-For-Parent (CPFP) pour les expéditeurs et les destinataires d’une transaction.

Changements notables dans le code et la documentation

Changements notables cette semaine 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 (BIP), Lightning BOLTs, et Bitcoin Inquisition.

• ● Bitcoin Core #27411 empêche un nœud de diffuser son adresse Tor ou I2P à des pairs sur d’autres réseaux (tels que IPv4 ou IPv6 simples) et ne diffusera pas son adresse depuis des réseaux d’anonymat à des pairs sur Tor et I2P. Cela aide à empêcher quelqu’un d’associer l’adresse réseau régulière d’un nœud à l’une de ses adresses sur un réseau d’anonymat. CJDNS est traité différemment de Tor et I2P pour le moment, bien que cela puisse changer à l’avenir.

• ● Core Lightning #6347 ajoute la possibilité pour un plugin de s’abonner à chaque notification d’événement en utilisant le caractère générique *.

• ● Core Lightning #6035 ajoute la possibilité de demander une adresse bech32m pour recevoir des dépôts sur des scripts de sortie P2TR. Les modifications de transaction seront également désormais envoyées à une sortie P2TR par défaut.

• ● LND #7768 implémente les BOLT #1032 et #1063 (voir Newsletter #225), permettant au destinataire final d’un paiement (HTLC) d’accepter un montant supérieur à celui demandé et avec un délai d’expiration plus long que celui demandé. Auparavant, les destinataires basés sur LND adhéraient à l’exigence de BOLT4 selon laquelle le montant et le delta d’expiration devaient être exactement égaux au montant demandé, mais cette exactitude permettait à un nœud de transfert de sonder le prochain saut pour voir s’il était le destinataire final en modifiant légèrement l’une ou l’autre valeur.

• ● Libsecp256k1 #1313 commence les tests automatiques à l’aide de versions de développement des compilateurs GCC et Clang, ce qui peut permettre de détecter des modifications qui pourraient entraîner l’exécution de certaines parties du code libsecp256k1 en temps variable. Un code non-constant qui fonctionne avec des clés privées et des nonces peut entraîner des attaques par canaux secondaires. Voir Newsletter #246 pour une occasion où cela aurait pu se produire et Newsletter #251 pour une autre occasion et une annonce selon laquelle ce type de test était prévu.