Le bulletin de cette semaine résume les résultats d’un test de préremplissage de bloc compact et fournit un lien vers une bibliothèque d’estimation des frais basée sur le mempool. Sont également incluses nos sections régulières résumant les récentes discussions sur la modification des règles de consensus de Bitcoin, annonçant des mises à jour et des versions candidates, et décrivant les changements notables dans les projets d’infrastructure Bitcoin populaires.

Nouvelles

• ● Test du préremplissage de bloc compact : David Gumberg a répondu à un fil de discussion Delving Bitcoin sur l’efficacité de la reconstruction de bloc compact (précédemment couverte dans les Bulletins 315 et 339) avec un résumé des résultats qu’il a obtenus en testant le relais de bloc compact préremplir—une node relayant de manière préventive certaines ou toutes les transactions d’un nouveau bloc à ses pairs lorsqu’elle pense que les pairs peuvent ne pas déjà avoir ces transactions. Le post de Gumberg est détaillé et fournit un lien vers un cahier Jupyter pour permettre à d’autres d’expérimenter par eux-mêmes. Les points clés incluent :

  • Considéré indépendamment du transport réseau, une règle simple pour déterminer quelles transactions préremplir a augmenté le taux de reconstructions de blocs réussies d’environ 62% à environ 98%.

  • Lors de la prise en compte du transport réseau, certains préremplissages peuvent avoir résulté en un aller-retour supplémentaire—annulant tout bénéfice dans ce cas et possiblement dégradant légèrement la performance. Cependant, de nombreux préremplissages auraient pu être construits pour éviter le problème, augmentant le taux de reconstruction probable à environ 93% et soutenant encore des améliorations.

• ● Bibliothèque d’estimation des frais basée sur le mempool : Lauren Shareshian a posté sur Delving Bitcoin pour annoncer une bibliothèque pour l’estimation des frais développée par Block. Contrairement à certains autres outils d’estimation des frais, elle utilise uniquement le flux de transactions entrant dans le mempool d’un nœud comme base de ses estimations. Le post compare la bibliothèque, Augur, à plusieurs services d’estimation des frais et trouve qu’Augur a un faible taux d’échec (c’est-à-dire, plus de 85% des transactions se confirment dans leur fenêtre prévue) et un faible taux de surestimation moyen (c’est-à-dire, les transactions paient des frais supérieurs d’environ 16% à ce qui est nécessaire).

  Abubakar Sadiq Ismail a répondu au fil Delving et a également commencé un problème informatif sur le dépôt Augur pour examiner certaines des hypothèses utilisées par la bibliothèque.

Modification du consensus

Une nouvelle section mensuelle résumant les propositions et discussions sur la modification des règles de consensus de Bitcoin.

• ● Migration à partir des sorties vulnérables aux quantiques : Jameson Lopp a posté sur la liste de diffusion Bitcoin-Dev une proposition en trois étapes pour éliminer progressivement les dépenses à partir des sorties vulnérables aux quantiques.

  • Trois ans après l’activation par consensus du schéma de signature résistant aux quantiques BIP360 (ou un schéma alternatif), un soft fork rejetterait les transactions avec des sorties payant des adresses vulnérables au quantique. Seules les dépenses vers des sorties résistantes au quantique seraient autorisées.

  • Deux ans plus tard, un second soft fork rejetterait les dépenses provenant de sorties vulnérables au quantique. Tout fond restant dans des sorties vulnérables au quantique deviendrait inutilisable.

  • Optionnellement, à un moment non défini ultérieurement, un changement de consensus pourrait permettre les dépenses depuis des sorties vulnérables aux quantique en utilisant un schéma de preuve résistant aux quantique (voir le Bulletin #361 pour un exemple).

  La plupart des discussions dans le fil de discussion ont largement répété les discussions précédentes sur la nécessité d’empêcher les gens de dépenser des bitcoins vulnérables aux quantique avant qu’il soit certain qu’un ordinateur quantique assez rapide pour les voler existait (voir le Bulletin 348). Des arguments raisonnables ont été avancés des deux côtés et nous devons nous attendre à ce que ce débat continue.

• ● Proposition de OP_TEMPLATEHASH natif à Taproot : Greg Sanders a posté sur la liste de diffusion Bitcoin-Dev une proposition pour ajouter trois opcodes à tapscript. Deux des opcodes sont les OP_CHECKSIGFROMSTACK et OP_INTERNALKEY précédemment proposés (voir le Bulletin 285). Le dernier opcode est OP_TEMPLATEHASH, une variation native à taproot de OP_CHECKTEMPLATEVERIFY (OP_CTV) avec les différences suivantes soulignées par les auteurs :

  • Pas de changements pour les scripts legacy (pré-segwit). Voir le Bulletin #361 pour une précédente discussion sur cette alternative.

  • Les données qui sont hashées (et l’ordre dans lequel elles sont hashées) sont très similaires aux données hashées pour les signatures afin de s’engager dans taproot, simplifiant l’implémentation pour tout logiciel qui supporte déjà taproot.

  • ● Cela s’engage sur l’annexe de taproot, ce que OP_CTV ne fait pas. Une manière d’utiliser cela est de s’assurer que certaines données sont publiées dans le cadre d’une transaction, comme des données utilisées dans un protocole de contrat pour permettre à une contrepartie de se récupérer de la publication d’un ancien état.

  • Cela redéfinit un opcode OP_SUCCESSx plutôt qu’un opcode OP_NOPx. Les soft forks redéfinissant les opcodes OP_NOPx doivent être des opcodes VERIFY qui marquent la transaction comme invalide s’ils échouent. Les redéfinitions d’opcodes OP_SUCCESSx peuvent simplement placer soit 1 (succès) soit 0 (échec) sur la pile après exécution ; cela leur permet d’être utilisés directement dans des cas où les redéfinitions de OP_NOPx devraient être enveloppées par des conditionnels tels que les instructions OP_IF.

  • “Cela empêche de surprendre les entrées avec … scriptSig” (voir le Bulletin #361 ).

  Brandon Black a répondu avec une comparaison de la proposition à sa précédente proposition de bundle LNHANCE (voir le Bulletin 285) et l’a trouvée comparable à bien des égards, bien qu’il ait noté qu’elle est moins efficace en espace onchain pour le contrôle de congestion (une forme de paiement différé de regroupement des paiements).

• ● Proposition pour permettre des timelocks relatifs plus longs : le développeur Pyth a posté sur Delving Bitcoin pour suggérer de permettre aux timelocks relatifs BIP68 d’être étendus de leur maximum actuel d’environ un an à un nouveau maximum d’environ dix ans. Cela nécessiterait un soft fork et l’utilisation d’un bit supplémentaire du champ sequence de l’entrée de transaction.

  Fabian Jahr a répondu avec une préoccupation que des timelocks trop éloignés dans le futur pourraient conduire à une perte de fonds, comme en raison du développement des ordinateurs quantiques (ou, nous ajoutons, le déploiement de protocoles de défense quantique tels que la proposition de Jameson Lopp décrite plus tôt dans ce bulletin). Steven Roose a noté que des timelocks très éloignés dans le futur sont déjà possibles en utilisant d’autres mécanismes de verrouillage temporel (tels que les transactions pré-signées et BIP65 CLTV), et Pyth a ajouté que leur cas d’utilisation souhaité est pour un chemin de récupération de portefeuille où le long timelock ne serait utilisé que si le chemin principal devenait indisponible et l’alternative serait de toute façon la perte permanente des fonds.

• ● Sécurité contre les ordinateurs quantiques avec taproot comme schéma d’engagement : Tim Ruffing a posté un lien vers un papier qu’il a écrit analysant la sécurité des engagements taproot contre la manipulation par des ordinateurs quantiques. Il examine si les engagements taproot aux tapleaves continueraient de posséder les propriétés de liaison et de masquage qu’ils ont contre les ordinateurs classiques. Il conclut que :

  Un attaquant quantique doit effectuer au moins 2^81 évaluations de SHA256 pour créer une sortie Taproot et être capable de l’ouvrir à une racine Merkle inattendue avec une probabilité de 1/2. Si l’attaquant dispose uniquement de machines quantiques dont la plus longue séquence de calculs SHA256 est limitée à 2^20, alors l’attaquant a besoin d’au moins 2^92 de ces machines pour obtenir une probabilité de succès de 1/2.

  Si les engagements taproot sont sécurisés contre la manipulation par des ordinateurs quantiques, alors la résistance quantique peut être ajoutée à Bitcoin en désactivant les dépenses de chemin de clé et en ajoutant des opcodes de vérification de signature résistants aux quantiques à tapscript. Une mise à jour récente à BIP360 pay-to-quantum-resistant-hash qu’Ethan Heilman a posté sur la mailing list Bitcoin-Dev fait exactement ce changement.

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 Core 29.1rc1 est un candidat à la sortie pour une version de maintenance du logiciel de nœud complet prédominant.

Changements notables dans le code et la documentation

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

• ● Bitcoin Core #29954 étend le RPC getmempoolinfo en ajoutant deux champs de politique de relais à son objet de réponse : permitbaremultisig (si le nœud relaie les sorties multisig nues) et maxdatacarriersize (le nombre maximal d’octets agrégés autorisés dans les sorties OP_RETURN pour une transaction dans le mempool). D’autres drapeaux de politique, tels que fullrbf et minrelaytxfee, étaient déjà exposés, donc ces ajouts permettent d’avoir un aperçu complet de la politique de relais.

• ● Bitcoin Core #33004 active par défaut l’option -natpmp, permettant le transfert automatique de port via le Port Control Protocol (PCP) avec un recours au NAT Port Mapping Protocol (NAT-PMP) (voir le Bulletin 323). Un nœud en écoute derrière un routeur qui supporte soit PCP soit NAT-PMP devient accessible sans configuration manuelle.

• ● LDK #3246 permet la création d’offres BOLT12 et de remboursements sans un chemin aveuglé en utilisant le signing_pubkey de l’offre comme destination. Les fonctions create_offer_builder et create_refund_builder délèguent désormais la création de chemin aveuglé à MessageRouter::create_blinded_paths, où un appelant peut générer un chemin compact en passant DefaultMessageRouter, un chemin de pubkey de longueur complète avec NodeIdMessageRouter, ou aucun chemin du tout avec NullMessageRouter.

• ● LDK #3892 expose publiquement la signature de l’arbre de Merkle des factures BOLT12, permettant aux développeurs de construire des outils CLI ou d’autres logiciels pour vérifier la signature ou recréer des factures. Cette PR ajoute également un champ OfferId aux factures BOLT12 pour suivre l’offre d’origine.

• ● LDK #3662 implémente BLIPs #55, également connu sous le nom de LSPS05, qui définit comment les clients peuvent s’inscrire à des webhooks via un point de terminaison pour recevoir des notifications push d’un LSP. L’API expose des points de terminaison supplémentaires qui permettent aux clients de lister toutes les inscriptions de webhook ou de supprimer une inscription spécifique. Cela peut être utile pour les clients afin d’être notifiés lors de la réception d’un paiement asynchrone.