Le bulletin de cette semaine résume une analyse comparant les propositions pour des ancrages éphémères à SIGHASH_GROUP et relaie une demande pour que les chercheurs étudient comment créer une preuve qu’un paiement asynchrone LN a été accepté. Vous trouverez également nos sections habituelles avec des résumés des principales questions et réponses sur le Bitcoin Stack Exchange et des descriptions des changements notables apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • Ancrages éphémères par rapport à SIGHASH_GROUP : Anthony Towns a posté sur la liste de diffusion Bitcoin-Dev une analyse comparant la récente proposition d’ancrages éphémères à une plus ancienne proposition SIGHASH_GROUP. SIGHASH_GROUP permet à une entrée de spécifier les sorties qu’elle autorise, avec différentes entrées dans une transaction pouvant spécifier différentes sorties tant qu’elles ne se chevauchent pas. Cela peut être particulièrement utile pour ajouter des frais aux transactions dans les protocoles de contrat où deux entrées ou plus sont utilisées avec des transactions présignées. La nature présignée de ces transactions implique que les frais peuvent être ajoutés plus tard lorsqu’un taux approprié est connu, et les drapeaux existants SIGHASH_ANYONECANPAY et SIGHASH_SINGLE ne sont pas assez flexibles pour les transactions à entrées multiples car ils ne s’engagent que sur une seule entrée ou sortie.

    Les ancrages éphémères, similaires aux parrainages de frais, permettent à n’importe qui de faire payer une transaction CPFP. La transaction faisant l’objet de la demande de remboursement est autorisée à ne pas contenir de frais. Puisque n’importe qui peut faire payer une transaction en utilisant des ancrages éphémères, ce mécanisme peut également être utilisé pour payer des frais pour les transactions présignées à entrées multiples qui sont une cible pour SIGHASH_GROUP.

    SIGHASH_GROUP présenterait encore deux avantages : premièrement, il pourrait permettre le traitement par lots de multiples transactions présignées non liées, ce qui pourrait réduire la surcharge de la taille des transactions, réduisant ainsi les coûts pour l’utilisateur et augmentant la capacité du réseau. Deuxièmement, elle ne nécessite pas de transaction enfant, ce qui réduirait encore les coûts et augmenterait la capacité.

    Towns conclut en notant que l’ancrage éphémère, avec sa dépendance à l’égard du relais de transaction v3, reprend la plupart des avantages de SIGHASH_GROUP et offre l’avantage significatif d’être beaucoup plus facile à mettre en production que le changement de consensus par embranchement convergent de SIGHASH_GROUP.

  • Demande de preuve qu’un paiement asynchrone a été accepté : Valentine Wallace a posté sur la liste de diffusion Lightning-Dev une demande pour que les chercheurs étudient comment une personne effectuant un paiement asynchrone pourrait recevoir la preuve qu’elle a payé. Pour les paiements LN traditionnels, le destinataire génère un secret qui est digéré par une fonction de hachage ; ce condensé est remis à l’expéditeur dans une facture signée ; l’expéditeur utilise un HTLC pour payer toute personne qui divulgue le secret original. Ce secret divulgué prouve que l’expéditeur a payé le condensé contenu dans la facture signée.

    En revanche, les paiements asynchrones sont acceptés lorsque le récepteur est hors ligne, ils ne peuvent donc pas révéler un secret, ce qui empêche la création d’une preuve de paiement dans le modèle actuel de LN. Wallace demande aux chercheurs d’étudier comment obtenir une preuve de paiement pour les paiements asynchrones, soit dans le système HTLC actuel de LN, soit dans une future mise à niveau vers PTLC.

Questions et réponses sélectionnées dans Bitcoin Stack Exchange

Bitcoin Stack Exchange est l’un des premiers endroits où les collaborateurs d’Optech cherchent des réponses à leurs questions—ou lorsque nous avons quelques moments libres pour aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en évidence certaines des questions et réponses les plus votées postées depuis notre dernière mise à jour.

Principaux changements apportés au code et à la documentation

Principaux changements 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 #26325 améliore les résultats de la commande de recherche scanblocks en supprimant les faux positifs lors d’un second passage. scanblocks peut être utilisé pour trouver des blocs contenant des transactions pertinentes à un ensemble fourni de descripteurs. Puisque le balayage contre les filtres peut faussement indiquer certains blocs qui ne contiennent pas réellement de transactions pertinentes, ce PR valide chaque hit dans une autre passe pour voir si les blocs correspondent réellement aux descripteurs passés avant de fournir les résultats à l’appelant. Pour des raisons de performance, la deuxième passe doit être activée en appelant le RPC avec l’option filter_false_positives.

  • Libsecp256k1 #1192 met à jour les tests exhaustifs de la bibliothèque. En changeant le paramètre B de la courbe secp256k1 de 7 à un autre nombre, il est possible de trouver différents groupes de courbes compatibles avec libsecp256k1 mais qui sont beaucoup plus petits que l’ordre de secp256k1 d’environ 2256. Sur ces minuscules groupes inutiles pour la cryptographie sécurisée, il est possible de tester la logique libsecp256k1 de manière exhaustive sur toutes les signatures possibles. Ce PR a ajouté un groupe de taille 7 en plus des tailles existantes 13 et 199, bien que les cryptographes aient d’abord dû comprendre les propriétés algébriques particulières qui faisaient que l’algorithme de recherche naïf pour de tels groupes ne réussissait pas toujours auparavant. La taille 13 reste la valeur par défaut.

  • BIPs #1383 attribue BIP329 à la proposition d’un format d’exportation d’étiquette de portefeuille standard. Depuis la proposition originale (voir le Bulletin #215), la principale différence est un interrupteur au format de données de CSV à JSON.