Le bulettin de cette semaine annonce un nouveau protocole de signature agrégée compatible avec secp256k1 et décrit un schéma de sauvegarde standardisé pour les descripteurs de portefeuille. Sont également incluses nos sections régulières résumant les récentes questions et réponses de Bitcoin Stack Exchange, annoncant de nouvelles versions et des candidats à la publication, ainsi que les résumés des modifications notables apportées aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

• ● Signatures agrégées interactives compatibles avec secp256k1 : Jonas Nick, Tim Ruffing, Yannick Seurin ont posté sur la liste de diffusion Bitcoin-Dev pour annoncer un article qu’ils ont écrit sur la création de signatures agrégées de 64 octets compatibles avec les primitives cryptographiques déjà utilisées par Bitcoin. Les signatures agrégées sont la condition cryptographique pour l’agrégation de signatures entre entrées (CISA), une fonctionnalité proposée pour Bitcoin qui pourrait réduire la taille des transactions avec plusieurs entrées, ce qui diminuerait le coût de nombreux types de dépenses, y compris les dépenses améliorant la confidentialité à travers les coinjoins et payjoins.

  En plus d’un schéma de signature agrégée comme le schéma DahLIAS proposé par les auteurs, l’ajout du support pour CISA à Bitcoin nécessiterait un changement de consensus et des interactions possibles entre l’agrégation de signatures et d’autres changements de consensus proposés qui peuvent nécessiter une étude plus approfondie.

• ● Sauvegarde standardisée pour les descripteurs de portefeuille : Salvatore Ingala a posté sur Delving Bitcoin un résumé des différents compromis liés à la sauvegarde des descripteurs de portefeuille et un schéma proposé qui devrait être utile pour de nombreux types de portefeuilles, y compris ceux utilisant des scripts complexes. Son schéma chiffre les descripteurs en utilisant un secret de 32 octets généré de manière déterministe. Pour chaque clé publique (ou clé publique étendue) dans le descripteur, une copie du secret est xorée avec une variante de la clé publique, créant n chiffrements secrets de 32 octets pour n clés publiques. Quiconque connaît l’une des clés publiques utilisées dans le descripteur peut la xor avec le chiffrement secret de 32 octets pour obtenir le secret de 32 octets qui peut déchiffrer le descripteur. Ce schéma simple et efficace permet à quiconque de stocker de nombreuses copies chiffrées d’un descripteur sur plusieurs supports et emplacements réseau, puis d’utiliser leur graine de portefeuille BIP32 pour générer leur xpub, qu’ils peuvent utiliser pour déchiffrer le descripteur s’ils perdent jamais leurs données de portefeuille.

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

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

• ● Praticité des signatures Schnorr semi-agrégées ? Fjahr discute pourquoi des signatures indépendantes, non agrégées, ne sont pas nécessaires pour valider une signature semi-agrégée dans l’agrégation de signature inter-entrées (CISA) et pourquoi les signatures non agrégées peuvent en fait poser problème.

• ● Quelle est la plus grande taille de payload OP_RETURN jamais créée ? Vojtěch Strnad lie à une transaction du meta-protocole Runes avec 79 870 octets comme le plus grand OP_RETURN.

• ● Explication hors-LN du pay-to-anchor ? Murch détaille la logique et la structure des scripts de sortie pay-to-anchor (P2A).

• ● Statistiques à jour sur les réorganisations de chaîne ? 0xb10c et Murch indiquent des sources de données sur les réorg, incluant le dépôt stale-blocks, le site web forkmonitor.info, et le site web fork.observer.

• ● Les canaux Lightning sont-ils toujours P2WSH ? Polespinasa note le développement en cours des canaux simple taproot P2TR et résume le support actuel à travers les implémentations Lightning.

• ● Child-pays-for-parent comme défense contre un double dépense ? Murch liste les complications à utiliser une transaction enfant CPFP à frais élevés pour inciter à une réorganisation de la blockchain et annuler une sortie déjà confirmée et doublement dépensée.

• ● Quelles valeurs CHECKTEMPLATEVERIFY hache-t-il ? Average-gray décrit les champs auxquels OP_CHECKTEMPLATEVERIFY s’engage : nVersion, nLockTime, nombre d’entrées, hash des séquences, nombre de sorties, hash des sorties, indice d’entrée, et dans certains cas le hash de scriptSig.

• ● Pourquoi les nœuds Lightning ne peuvent-ils pas choisir de révéler les soldes des canaux pour une meilleure efficacité de routage ? Rene Pickhardt explique les préoccupations concernant l’obsolescence et la fiabilité des données, les implications sur la vie privée, et renvoie à une proposition similaire de 2020.

• ● Le post-quantique nécessite-t-il un hard fork ou un soft fork ? Vojtěch Strnad décrit une approche de la manière dont un schéma de signature post-quantique (PQC) pourrait être activé par soft-fork ainsi que comment un hard ou soft fork pourrait verrouiller les pièces vulnérables aux attaques quantiques.

Mises à jour et versions candidates

Nouvelles mises-à-jours et versions candidates pour des projets d’infrastructure Bitcoin populaires. Veuillez envisager de mettre à niveau vers les nouvelles mises-à-jour ou d’aider à tester les versions candidates.

• ● LND 0.19.0-beta.rc3 est un candidat à la sortie pour ce nœud LN populaire. L’une des principales améliorations qui pourrait probablement nécessiter des tests est le nouveau bumping de frais basé sur RBF pour les fermetures coopératives.

Changements notables dans le code et la documentation

Changements récents notables dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware WalletInterface (HWI), Rust Bitcoin, BTCPay Server, BDK, Propositions d’Amélioration de Bitcoin (BIPs), Lightning BOLTs, Lightning BLIPs, Interrogatoire Bitcoin, et BINANAs.

• ● Bitcoin Core #31247 ajoute le support pour la sérialisation et l’analyse des champs MuSig2 PSBT comme spécifié dans BIP373 pour permettre aux portefeuilles de signer et dépenser des entrées MuSig2. Du côté de l’entrée, cela consiste en un champ listant les clés publiques des participants, plus un champ de nonce public séparé et un champ de signature partielle séparé pour chaque signataire. Du côté de la sortie, c’est un champ unique listant les clés publiques des participants pour le nouveau UTXO.

• ● LDK #3601 ajoute une nouvelle énumération LocalHTLCFailureReason pour représenter chaque code d’erreur standard BOLT4, ainsi que quelques variantes qui fournissent des informations supplémentaires à l’utilisateur qui étaient précédemment supprimées pour des raisons de confidentialité.