Le bulletin de cette semaine décrit une recherche sur les compromis entre l’usabilité et la sécurité dans les signatures à seuil, résume une approche pour convertir des signatures à seuil imbriquées en un seul groupe de signature, et examine dans quelle mesure les données pourraient être intégrées dans l’ensemble UTXO sous un ensemble restrictif de règles. Sont également incluses nos sections régulières résumant une réunion du Bitcoin Core PR Review Club, annonçant des mises à jour et des versions candidates, et décrivant les changements notables dans les projets d’infrastructure Bitcoin populaires.

Nouvelles

• ● Signatures à Seuil Optimal: Sindura Saraswathi a publié une recherche, co-écrite avec Korok Ray, sur Delving Bitcoin concernant la détermination du seuil optimal pour un schéma de multisignature. Dans cette recherche, les paramètres d’usabilité et de sécurité sont explorés, ainsi que leur relation et comment cela affecte le seuil que l’utilisateur devrait sélectionner. En définissant p(τ) et q(τ) puis en les combinant en une solution en forme fermée, ils tracent l’écart entre sécurité et usabilité.

  Saraswathi explore également l’utilisation de signatures à seuil dégradantes où les premières étapes utilisent des seuils plus élevés, qui diminuent progressivement dans les étapes ultérieures. Cela signifie qu’avec le temps, l’attaquant obtient plus d’accès pour prendre les fonds. Elle dit aussi qu’en utilisant taproot, il peut y avoir de nouvelles possibilités à débloquer avec celles-ci à travers les taptrees et des contrats plus complexes, incluant les timelocks et les signatures multiples.

• ● Aplatir certaines signatures à seuil imbriquées : ZmnSCPxj a posté sur Delving Bitcoin pour décrire comment éviter d’utiliser des signatures schnorr imbriquées dans certains cas qui n’ont pas été prouvés sûrs. Par exemple, Alice peut vouloir entrer dans un contrat avec un groupe composé de Bob, Carol et Dan. Toutes transactions doivent être approuvées par Alice et au moins deux parmi Bob, Carol et Dan. En théorie, cela pourrait être fait avec une multisignature (par ex. MuSig) où Alice fournit une signature partielle et une signature à seuil (par ex. FROST) est utilisée pour générer la signature partielle de Bob, Carol et Dan. Cependant, ZmnSCPxj écrit que “actuellement, nous n’avons pas de preuve que FROST-dans-MuSig est sûr”. Au lieu de cela, ZmnSCPxj note que cet exemple peut être satisfait en utilisant uniquement des signatures à seuil : Alice reçoit plusieurs parts—assez pour qu’elle puisse empêcher un quorum, mais pas assez pour qu’elle puisse signer unilatéralement ; les autres signataires reçoivent chacun une part.

  Les utilisations décrites de cela incluent les statechains multi-opérateurs, les utilisateurs de LN qui souhaitent utiliser plusieurs dispositifs de signature, et la proposition de surpaiements redondants améliorée par LSP de ZmnSCPxj (voir le Bulletin #372).

• ● Limitations théoriques sur l’incorporation de données dans l’ensemble UTXO : Adam “Waxwing” Gibson a lancé une discussion sur la liste de diffusion concernant la mesure dans laquelle les données pourraient être incorporées dans l’ensemble UTXO sous un ensemble restrictif de règles pour les transactions Bitcoin. La principale nouvelle règle, que Gibson décrit comme “effroyable”, serait d’exiger que chaque sortie P2TR soit accompagnée d’une signature prouvant que la sortie pourrait être dépensée. Gibson tente de prouver qu’il n’y a que trois façons de contourner cette règle pour permettre à des données arbitraires de se faire passer pour une clé publique :

  1. La version de Bitcoin des signatures schnorr est défectueuse, par exemple basée sur une hypothèse erronée. Ce n’est clairement pas le cas actuellement.

  2. Une petite quantité de données arbitraires pourrait être incorporée en broyant la clé publique (c’est-à-dire, générer de nombreuses clés privées différentes, dériver la clé publique correspondante pour chacune, et écarter toutes les clés privées dont les clés publiques ne contiennent pas les données arbitraires souhaitées encodées d’une manière qui peut être extraite. Pour inclure n bits de données arbitraires dans l’ensemble UTXO de cette manière, il faut environ 2ⁿ opérations de force brute, ce qui est impraticable pour plus de quelques dizaines de bits (quelques octets) par sortie).

  3. Utiliser une clé privée qui peut facilement être calculée par des tiers, une forme de “divulgation de votre clé privée”.

  Dans le troisième cas, divulguer votre clé privée pourrait permettre à un tiers de dépenser la sortie, en la retirant de l’ensemble UTXO. Cependant, plusieurs réponses à la discussion ont noté des moyens qui pourraient permettre de contourner cela dans un système sophistiqué comme Bitcoin. Une réponse d’Anthony Towns a ajouté, “une fois que vous rendez le système programmable de manière intéressante, je pense que vous obtenez immédiatement la possibilité d’incorporer des données, et ensuite c’est juste une question de compromis entre le taux d’encodage optimal et la facilité d’identification de vos transactions. Forcer les données à être cachées au prix de les rendre moins efficaces laisse juste moins de ressources disponibles aux autres utilisateurs du système, ce qui ne me semble pas être un avantage de quelque manière que ce soit.”

Bitcoin Core PR Review Club

Dans cette section mensuelle, nous résumons une récente réunion du Bitcoin Core PR Review Club, en soulignant certaines des questions et réponses importantes. Cliquez sur une question ci-dessous pour voir un résumé de la réponse de la réunion.

Compact block harness est un PR de Crypt-iQ qui augmente la couverture du test de fuzz en ajoutant un harnais de test pour la logique de relais de blocs compacts. Le fuzzing est une technique de test qui fournit des entrées quasi aléatoires au code pour découvrir des bugs et des comportements inattendus.

Le PR introduit également une nouvelle option de démarrage réservée aux tests -fuzzcopydatadir pour augmenter la performance d’exécution du harnais de test. Pourquoi un pair choisirait-il d’avoir une bande passante élevée ou faible ? Plus généralement, pourquoi un pair choisirait-il d’être à haute ou basse bande passante ?

Mises à jour et versions candidates

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

• ● Bitcoin Inquisition 29.1 est une sortie de ce nœud complet signet conçu pour expérimenter avec des soft forks proposés et d’autres changements majeurs de protocole. Il inclut le nouveau frais de relais minimum par défaut (0.1 sat/vb) introduit dans Bitcoin Core 29.1, les limites datacarrier plus grandes attendues dans Bitcoin Core 30.0, le support pour OP_INTERNALKEY (voir les Bulletins #285 et #332), et nouvelle infrastructure interne pour le support de nouveaux soft forks.

Changements notables dans le code et la documentation

Changements notables récents dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, et BINANAs.

• ● Bitcoin Core #33453 annule la dépréciation des options de configuration datacarrier et datacarriersize car de nombreux utilisateurs souhaitent continuer à utiliser ces options, le plan de dépréciation était flou, et il y a peu d’inconvénients à retirer la dépréciation. Voir les Bulletins #352 et #358 pour un contexte supplémentaire sur ce sujet.

• ● Bitcoin Core #33504 saute l’application des vérifications TRUC pendant une réorganisation de bloc lorsque les transactions confirmées réintègrent le mempool, même si elles violent les contraintes topologiques TRUC. Auparavant, l’application de ces vérifications évinçait par erreur de nombreuses transactions.

• ● Core Lightning #8563 retarde la suppression des anciens HTLCs jusqu’à ce qu’un nœud soit redémarré, plutôt que de les supprimer lorsqu’un canal est fermé et oublié. Cela améliore la performance en évitant une pause inutile qui arrête tous les autres processus CLN. Cette PR met également à jour le RPC listhtlcs pour exclure les HTLCs des canaux fermés.

• ● Core Lightning #8523 supprime le champ blinding précédemment déprécié et désactivé du RPC decode et du hook onion_message_recv, car il a été remplacé par first_path_key. Les options experimental-quiesce et experimental-offers sont également supprimées, car ces fonctionnalités sont désormais par défaut.

• ● Core Lightning #8398 ajoute une commande RPC cancelrecurringinvoice aux offres récurrentes expérimentales BOLT12 offers, permettant à un payeur de signaler à un receveur d’arrêter d’attendre d’autres demandes de facture de cette série. Plusieurs autres mises à jour sont faites pour s’aligner sur les derniers changements de spécification dans BOLTs #1240.

• ● LDK #4120 efface l’état de financement interactif lorsqu’une négociation de splice échoue avant la phase de signature, si un pair se déconnecte ou envoie tx_abort, permettant de réessayer le splice proprement. Si un tx_abort est reçu après que les pairs ont commencé à échanger des tx_signatures, LDK le traite comme une erreur de protocole et ferme le canal.

• ● LND #10254 déprécie le support pour les services onion Tor v2, qui seront retirés dans la prochaine version 0.21.0. La configuration de l’option tor.v2 est désormais cachée ; les utilisateurs devraient utiliser Tor v3 à la place.