La newsletter de cette semaine résume la suite de discussions sur l’activation de full RBF, fournit des aperçus de plusieurs transcriptions de discussions lors d’une réunion CoreDev.tech, et décrit une proposition de sorties d’ancrage éphémères conçues pour les protocoles de contrat comme LN. Vous trouverez également nos sections habituelles avec des résumés des principales questions et réponses du Bitcoin Stack Exchange, une liste des nouvelles versions logicielles et des release candidate, ainsi que les principaux changements apportés aux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Poursuite de la discussion sur le full RBF : durant la newsletter de la semaine dernière, nous avons résumé une discussion sur la liste de diffusion Bitcoin-Dev concernant l’inclusion d’une nouvelle option mempoolfullrbf qui pourrait créer des problèmes pour plusieurs entreprises qui acceptent des transactions avec zéro confirmation (“zero conf”) comme paiement final. La discussion a continué cette semaine à la fois sur la liste de diffusion et dans la salle IRC #bitcoin-core-dev. Voici quelques points saillants de la discussion :

    • ● Problème d’option gratuite : Sergej Kotliar averti qu’il pense que le plus grand problème de tout type de remplacement de transaction est qu’il crée un option de style Option Américaine gratuite. Par exemple, le client Alice demande à acheter des gadgets au marchand Bob. Bob donne à Alice une facture pour 1 BTC au prix actuel de 20 000 USD/BTC. Alice envoie à Bob les 1 BTC dans une transaction avec un faible taux de frais. La transaction n’est pas confirmée lorsque le taux de change passe à 25 000 USD/BTC, ce qui signifie qu’Alice paie maintenant 5 000 dollars de plus. À ce stade, elle choisit très rationnellement de remplacer sa transaction par une transaction dans laquelle elle se rembourse les BTC, annulant ainsi la transaction. Cependant, si le taux de change avait évolué en faveur d’Alice (par exemple 15 000 USD/BTC), Bob ne pourrait pas annuler le paiement d’Alice et n’aurait donc aucun moyen, dans le flux normal des transactions Bitcoin onchain, de profiter de la même option, créant ainsi un risque de change asymétrique. En comparaison, lorsque le remplacement de la transaction n’est pas possible, Alice et Bob partagent le même risque de taux de change.

      Kotliar note que le problème existe aujourd’hui avec la disponibilité de RBF du BIP125, mais il estime que le full-RBF pourrait accentuer le problème.

      Greg Sanders et Jeremy Rubin notent séparement que le commerçant Bob pourrait inciter les mineurs à confirmer la transaction originale du client Alice en utilisant CPFP, particuliérement si package relay était activé.

      Antoine Riard note que le même risque existe avec LN, car Alice pourrait attendre de payer la facture du commerçant Bob jusqu’à peu avant son expiration, ce qui lui laisserait le temps d’attendre que le taux de change change. Cependant, dans ce cas, si Bob remarque que le taux de change a changé de manière significative, il peut demander à son nœud de ne pas accepter le paiement et rendre l’argent à Alice.

    • ● Bitcoin Core n’est pas en charge du réseau : Gloria Zhao a écrit dans la discusion IRC, “Je pense que, quelle que soit l’option choisie, il doit être clair pour les utilisateurs que le Core ne contrôle pas si le full RBF se produit ou non. Nous pourrions revenir en arrière 25353 et cela pourrait encore arriver. […]”

      Après la réunion, Zhao a aussi posté une vue détaillée de la situation.

    • ● L’absence de retrait signifie que le problème peut se produire : dans la discussion sur IRC, Anthony Towns a rappelé ses points de la semaine dernière, “si nous ne supprimons pas l’option mempoolfullrbf de la 24.0, nous allons vers un déploiement non coordonné.”

      Greg Sanders était circonspect, “la question est: Est-ce que 5 %+s constitueront une variable ? Je ne pense pas.” Ce à quoi Towns a répondu: “UASF uacomment a démontré qu’il était facile d’obtenir ~11% d’une variable en seulement quelques semaines”.

    • ● Devrait être une option : Martin Zumsande a dit dans la discussion IRC, “Je pense que si un nombre significatif d’opérateurs de nœuds et de mineurs veulent une politique spécifique, cela ne devrait pas être aux devs de leur dire ‘vous ne pouvez pas avoir cela maintenant’. Les devs peuvent et doivent donner une recommandation (en choisissant l’option par défaut), mais fournir des options aux utilisateurs informés ne devraient jamais être un problème.”

    Au moment où nous écrivons ces lignes, aucune résolution claire n’a été trouvée. L’option mempoolfullrbf est toujours incluse dans les release candidate de la prochaine version de Bitcoin Core 24.0 et Optech recommande que tout service dépendant des transactions zero conf évalue soigneusement les risques, en commençant peut-être par lire les courriels dont le lien figure à l’adresse suivante de la newsletter de la semaine dernière.

  • ● CoreDev.tech transcription : Avant la conférence Atlanta Bitcoin (TabConf), 40 développeurs environ ont participé à un événement CoreDev.tech. Les transcriptions d’environ la moitié des réunions de l’événement ont été fournies par Bryan Bishop. Les principales discussions portaient sur :

    • ● le chiffrement du transport: une conversation sur la récente mise à jour de la proposition de protocole de transport chiffré version 2 (voir la Newsletter #222). Ce protocole rendrait plus difficile pour les espions du réseau de savoir quelle adresse IP est à l’origine d’une transaction et améliorerait la capacité à détecter et à résister aux attaques de type “man-in-the-middle” entre des nœuds honnêtes.

      La discussion couvre plusieurs des considérations relatives à la conception du protocole et est une lecture recommandée pour tous ceux qui se demandent pourquoi les auteurs du protocole ont pris certaines décisions. Elle examine également la relation avec le protocole d’authentification antérieur countersign.

    • ● les frais: une large discussion sur les frais de transaction dans le passé, le présent et l’avenir. Parmi les sujets abordés, citons les questions sur la raison pour laquelle les blocs sont apparemment toujours presque pleins alors que le mempool ne l’est pas, le débat sur le temps dont nous disposons pour qu’un marché de frais significatif se développe avant que nous devions nous inquiéter de la stabilité à long terme de Bitcoin, et les solutions que nous pourrions déployer si nous pensions qu’un problème existait.

    • ● FROST: une présentation sur le schéma de signature à seuil FROST. La transcription documente plusieurs excellentes questions techniques sur les choix cryptographiques dans la conception et peut être une lecture utile pour toute personne intéressée à en savoir plus sur FROST en particulier ou sur la conception de protocoles cryptographiques en général. Voir aussi la transcription de TabConf sur ROAST, un autre schéma de signature à seuil pour Bitcoin.

    • ● GitHub: une discussion sur le transfert de l’hébergement git du projet Bitcoin Core de GitHub vers une autre solution de gestion des problèmes et des relations publiques, ainsi que sur les avantages de continuer à utiliser GitHub.

    • ● les spécifications prévisibles dans les BIP: dans le cadre d’une discussion sur l’utilisation du langage de spécification hacspec dans les BIPs pour fournir des spécifications qui sont prouvées correctes. Voir aussi la transcript pour un exposé connexe pendant la TabConf.

    • ● les relais de transactions en paquet v3: la transcription d’une présentation sur les propositions visant à activer le relais de transactions en paquet et à utiliser de nouvelles règles de relais de transaction pour éliminer les attaques de pinning dans certains cas.

    • ● Stratum v2: une discussion qui a commencée avec l’annonce d’un nouveau projet open-source mettant en œuvre le protocole de minage groupé Stratum version 2. Les améliorations apportées par Stratum v2 comprennent des connexions authentifiées et la possibilité pour les mineurs individuels (ceux qui disposent d’un équipement minier local) de choisir les transactions à exploiter (plutôt que le pool qui choisit les transactions). En plus de nombreux autres avantages, il a été mentionné dans la discussion que le fait de permettre aux mineurs individuels de choisir leur propre modèle de bloc pourrait devenir très souhaitable pour les pools qui s’inquiètent de voir les gouvernements imposer les transactions à extraire, comme dans la controverse de Tornado Cash. La plupart des discussions se sont concentrées sur les changements qui devraient être apportés à Bitcoin Core pour permettre le support natif de Stratum v2. Voir également la transcription de la TabConf sur Braidpool, un protocole de minage en pool décentralisé.

    • ● Merging est une discussion sur les stratégies permettant d’obtenir une révision du code dans le cadre du projet Bitcoin Core, bien que de nombreuses suggestions s’appliquent également à d’autres projets. Idées incluses :

      • Diviser les grands changements en plusieurs petites PR

      • Faire en sorte que les évaluateurs comprennent facilement l’objectif final. Pour chaque PR, cela signifie rédiger une description motivante de la PR. Pour les changements qui sont effectués de manière incrémentielle, utilisez les suivis de problèmes, les tableaux de projet et motivez les remaniements en ouvrant également les PR qui utiliseront le code remanié pour atteindre un objectif souhaitable.

      • Produire des explications de haut niveau pour des projets de longue haleine décrivant l’état antérieur du projet, l’état d’avancement actuel, ce qu’il faudra faire pour atteindre le résultat et les avantages qu’en tireront les utilisateurs.

      • Former des groupes de travail avec ceux qui sont intéressés par les mêmes projets ou sous-systèmes de codes

  • ● Ephemeral anchors: Greg Sanders a poursuivi la discussion précédente sur le relais des transactions v3 (voir Newsletter #220) avec un article sur le serveur Bitcoin-Dev contenant une proposition pour un nouveau type de anchor output. Une transaction v3 pourrait payer zéro frais mais contenir une sortie payant le script OP_TRUE, permettant à quiconque de la dépenser selon les règles du consensus dans une transaction enfant. La transaction parentale non confirmée à frais nuls ne serait relayée et exploitée par Bitcoin Core que si elle faisait partie d’un paquet de transactions contenant également la transaction enfant dépensant la sortie OP_TRUE. Cela n’affecterait que la politique de Bitcoin Core; aucune règle de consensus ne serait modifiée.

    Les avantages décrits dans cette proposition sont qu’elle élimine le besoin d’utiliser des timelocks relatifs d’un seul bloc (appelés 1 OP_CSV d’après le code utilisé pour les activer) pour empêcher l’épinglage de la transaction et permet à quiconque de faire payer la transaction parente (similaire à une proposition antérieure de parrainage de la transaction).

    Jeremy Rubin a soutenu a soutenu la proposition mais a noté qu’elle ne fonctionne pas pour les contrats qui ne peuvent pas utiliser les transactions v3. Plusieurs autres développeurs ont également discuté du concept, tous semblent le trouver attrayant au moment de la rédaction de cet article.

Selection de Q&R du Bitcoin Stack Exchange

Bitcoin Stack Exchange est une des principales places pour les contributeurs d’Optech pour trouver les réponses à leurs questions—ou lorsque nous avons quelques instants pour aider les utilisateurs curieux ou confus. Dans cette chronique mensuelle, nous mettons en avant certaines des questions et réponses les plus postées depuis notre dernière édition.

Mises à jour et release candidate

Nouvelles mises à jour et release candidates des principaux logiciels d’infrastructure Bitcoin. Prévoyez s’il vous plait de vous mettre à jour à la nouvelle version ou d’aider à tester les pré-versions.

  • ● LDK 0.0.112 est une version de cette bibliothèque permettant de construire des application basé sur LN

  • ● Bitcoin Core 24.0 RC2 est une release candidate pour la prochaine version de l’implémentation de nœuds complets la plus largement utilisée sur le réseau. Un guide de test est disponible.

    Attention : cette release candidate inclut l’option de configuration mempoolfullrbf qui, selon plusieurs développeurs de protocoles et d’applications, pourrait entraîner des problèmes pour les services marchands, comme décrit dans les bulletins de cette semaine et de la semaine dernière. Optech encourage tous les services qui pourraient être affectés à évaluer la RC et à participer à la discussion publique.

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 #23443 ajoute un nouveau message de protocole P2P, sendtxrcncl (envoyer la réconciliation des transactions), qui permet à un nœud de signaler à un pair qu’il supporte erlay. Ce PR n’ajoute que la première partie du protocole erlay—d’autres parties sont nécessaires pour pouvoir l’utiliser.

  • ● Eclair #2463 et #2461 Mise à jour de l’implémentation d’Éclair des protocoles de financement interactif et double pour exiger que chaque entrée de financement opte pour RBF et soit également confirmée (c’est-à-dire qu’elle dépense une sortie qui est déjà dans la chaîne de blocs). Ces changements garantissent que RBF peut être utilisé et qu’aucun des frais apportés par un utilisateur d’Eclair ne sera utilisé pour aider à confirmer les transactions précédentes de son pair.