Bitcoin Optech : Divulgation de sécurité : Bitcoin Magazine : Actualités, articles, graphiques et guides Bitcoin

ainsi que des ressources qui les aident à en savoir plus nous republions le dernier numéro de cette newsletter ci-dessous

les annonces de nouvelles versions de logiciels et de candidats à la version, et des descriptions de changements notables apportés au logiciel d’infrastructure Bitcoin populaire.

Nouvelles

• Écart CVE-2021-31876 entre l’implémentation BIP125 et Bitcoin Core : la spécification BIP125 de l’opt-in Replace By Fee (RBF) indique qu’une transaction parent non confirmée qui signale la remplaçabilité rend toutes les transactions enfants qui dépensent les sorties du parent également remplaçables par héritage inféré. Cette semaine, Antoine Riard a publié sur la liste de diffusion Bitcoin-Dev la divulgation complète de sa découverte précédemment rapportée en privé que Bitcoin Core ne met pas en œuvre ce comportement. Il est toujours possible que les transactions enfants soient remplacées si elles signalent explicitement la remplaçabilité ou qu’elles soient expulsées du mempool si leur transaction parente est remplacée.

  Le déploiement continu des sorties d’ancrage par diverses implémentations de LN éliminera la capacité d’effectuer cet épinglage.

  

  Au moment d’écrire ces lignes, il n’y a pas eu de discussion substantielle sur la question sur la liste de diffusion

• Appel à candidatures pour une subvention Brink : Bitcoin Optech encourage tout ingénieur contribuant à des projets open source Bitcoin ou Lightning à postuler pour une subvention Brink avant la date limite de candidature le 17 mai. Les subventions initiales durent un an et permettent aux développeurs de travailler à plein temps sur des projets open source de n’importe où dans le monde

Club de révision Bitcoin Core PR

mettant en évidence 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.

# 96, # 129 et # 142), précédemment discuté dans les clubs de révision # 16698 et # 18038, dont le but est de rendre le comportement de rediffusion des nœuds pour les transactions de portefeuille indiscernable de celui des transactions d’autres pairs.

La discussion du club d’examen s’est concentrée sur le comportement actuel des transactions et les changements proposés:

Lorsque notre transaction ne s’est pas propagée (notre nœud était peut-être hors ligne) ou semble avoir été abandonné par les mempools d’autres nœuds du réseau

Pourquoi un nœud supprime-t-il une transaction de son mempool? En plus d’être incluse dans un bloc, une transaction peut expirer au bout de 14 jours, être évincée de la taille mempool limitée d’un nœud (taille par défaut 300 Mio) par des transactions à frais plus élevés, être remplacée via l’opt-in BIP125 Remplacer par frais ( RBF), être supprimée si une transaction conflictuelle est incluse dans un bloc, ou être incluse dans un bloc qui est ultérieurement réorganisé (auquel cas le nœud essaiera de le rajouter lors de la mise à jour du mempool pour qu’il soit à nouveau cohérent après la réorganisation )

Quel pourrait être un problème avec le comportement actuel de chaque portefeuille étant responsable de la rediffusion de ses propres transactions?

Cela peut être une fuite de confidentialité qui permet de lier l’adresse IP à l’adresse du portefeuille, car dans le comportement de rediffusion actuel, un nœud qui diffuse une transaction plus d’une fois annonce essentiellement que la transaction provient de son portefeuille

Quand un mineur peut-il exclure une transaction qui est dans notre mempool? Lorsque le mineur l’a dépriorisé pour avoir des frais bas, ne l’a pas encore vu, l’a retiré de son mempool par RBF, l’a censuré ou a miné un bloc vide

Quand un mineur peut-il inclure une transaction qui n’est pas dans notre mempool? Lorsque le mineur a priorisé manuellement la transaction (par exemple en tant que service commercial), l’a reçue avant notre nœud, ou la transaction est en conflit avec une autre dans notre mempool mais pas dans le leur

Comment la proposition examinée déciderait-elle des transactions à rediffuser?

Une fois par nouveau bloc, il propose de rediffuser les transactions supérieures à une durée estimée qui ont au moins 30 minutes, qui ont été rediffusées pas plus de 6 fois et pas plus récemment qu’il y a 4 heures, avec jusqu’à 3/4 des transactions qui correspondent. le bloc

Après un changement de règle de consensus, il peut y avoir des nœuds non mis à jour sur le réseau qui rediffusent des transactions qui ne respectent pas les nouvelles règles de consensus. Conserver les transactions dans le suivi des tentatives de rediffusion éviterait que ces nœuds les rediffusent trop de fois (un maximum de 6 fois sur 90 jours) et permettrait aux transactions d’expirer

Lorsque la transaction est confirmée, RBF ou entre en conflit avec une autre transaction incluse dans un bloc

Comment la durée minimale estimée pour la rediffusion serait-elle calculée? Pourquoi ne pas utiliser le taux de rendement le plus bas dans le dernier bloc miné?

Le plancher de réémission serait estimé une fois par minute en assemblant un bloc du mempool pour simuler l’inclusion dans le prochain bloc miné. Cette approche est meilleure que d’utiliser le taux le plus bas du dernier bloc miné car elle calcule les frais en fonction de l’avenir immédiat dans un environnement en évolution au lieu de se baser sur le passé

Libère et libère des candidats

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

• Rust-Lightning 0.0.14 est une nouvelle version qui rend Rust Lightning plus compatible avec l’obtention de données à partir de serveurs de style Electrum, ajoute des options de configuration supplémentaires et améliore la conformité avec la spécification LN, entre autres corrections de bogues et améliorations

Modifications notables du code et de la documentation

Changements notables cette semaine dans Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIPs) et Lightning BOLTs.

• Bitcoin Core # 20867 augmente le nombre de clés pouvant être incluses dans les descripteurs multisig et utilisées dans les RPC addmultisigaddress et createmultisig de 16 à 20. La limite augmentée ne peut être utilisée que dans les sorties P2WSH. Les sorties P2SH sont limitées à des scripts de 520 octets qui sont seulement assez grands pour contenir 15 clés publiques compressées
• Bitcoin Core GUI # 125 permet aux utilisateurs d’ajuster la taille de l’espace de bloc d’auto-réglage par défaut dans la boîte de dialogue d’introduction. Il ajoute également une description améliorée du fonctionnement du stockage élagué, précisant que toute la blockchain doit être téléchargée et traitée mais sera supprimée à l’avenir pour maintenir une faible utilisation du disque
• C-Lightning # 4489 ajoute un plugin de financement pour configurer le comportement de contribution à double financement en réponse aux demandes d’ouverture de canal entrantes. Les utilisateurs pourront spécifier une politique de contribution générale (pourcentage de correspondance, pourcentage de fonds disponibles ou contribution fixe), un montant de réserve de portefeuille en vertu duquel aucune contribution à double financement ne se produira, un montant de contribution maximal pour toute demande ouverte à un seul canal, etc..

  Ce PR représente la dernière étape pour permettre un support expérimental à double financement entre les nœuds C-Lightning. Les protocoles de construction de transaction interactive et d’établissement de canal v2 découlant de ce travail sont toujours en cours de normalisation dans les BOLT ouverts # 851 PR

C-Lightning avait déjà plusieurs sujets intégrés, mais ce PR fusionné permet aux auteurs de plugins de créer et de consommer des notifications pour toute nouvelle catégorie de sujet qu’ils aimeraient utiliser

• Rust Bitcoin # 589 démarre le processus de mise en œuvre de la prise en charge de la racine pivotante avec les signatures schnorr. La prise en charge ECDSA existante est déplacée vers un nouveau module mais continue d’être exportée sous les noms existants pour préserver la compatibilité des API. Un nouveau module util : : schnorr ajoute la prise en charge des encodages de clé schnorr BIP340. Le problème n ° 588 est utilisé pour suivre l’implémentation complète de la compatibilité de la racine pivotante

Trouvez le message original ici.