Bitcoin Optech #151 : Sélection des transactions

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

Le bulletin d’information de cette semaine décrit une proposition visant à modifier l’algorithme de sélection des transactions de Bitcoin Core pour les modèles de blocs de mineurs afin d’augmenter légèrement la rentabilité des mineurs et de donner aux utilisateurs qui augmentent les frais un plus grand effet de levier collectif. Sont également inclus nos sections régulières décrivant les versions logicielles et les versions candidates, ainsi que les modifications notables apportées aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

Construction du modèle de bloc basé sur l’ensemble candidat (CSB) : Mark Erhardt a publié sur la liste de diffusion Bitcoin-Dev une analyse que lui et Clara Shikhelman ont effectuée sur un algorithme de sélection de transaction alternatif pour les mineurs. Les règles de consensus de Bitcoin imposent qu’aucune transaction ne peut être incluse dans un bloc à moins que tous ses ancêtres non confirmés ne soient également inclus plus tôt dans ce même bloc. Bitcoin Core résout cette contrainte en traitant chaque transaction avec des ancêtres non confirmés comme si elle contenait à la fois les frais et la taille de ces ancêtres. Par exemple, si la transaction B dépend de la transaction A non confirmée, alors Bitcoin Core additionne les frais payés par les deux transactions et les divise par la taille combinée des deux transactions. Cela permet à Bitcoin Core de comparer équitablement toutes les transactions dans le mempool en fonction de leur taux effectif, que ces transactions aient ou non des ancêtres. Cependant, Erhardt et Shikhelman notent qu’un algorithme plus sophistiqué qui peut nécessiter un peu plus de CPU peut trouver des ensembles de transactions associées. qui sont encore plus rentables à exploiter que l’algorithme simple existant de Bitcoin Core. Les auteurs ont testé leur algorithme sur les données historiques de mempool et ont constaté qu’il aurait collecté un peu plus de frais que l’algorithme existant de Bitcoin Core dans presque tous les blocs récents. S’il est implémenté et utilisé par les mineurs, l’algorithme amélioré pourrait permettre à plusieurs utilisateurs qui ont chacun reçu une sortie à partir d’une grande jointure ou d’un paiement groupé pour payer chacun une petite partie des frais totaux nécessaires aux frais CPFP qui dépassent cette jointure ou ce paiement. Ce serait une amélioration par rapport au cas actuel où la majoration des frais CPFP de chaque utilisateur est considérée indépendamment et plusieurs majorations de frais connexes peuvent ne pas avoir d’effet global sur l’extraction d’une transaction ancêtre

Release et Release Candidates

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

HWI 2.0.2 est une version mineure qui ajoute la prise en charge de la signature de messages avec BitBox02, utilise toujours h au lieu de ‘ pour indiquer les chemins BIP32 avec dérivation renforcée et inclut plusieurs corrections de bogues
LND 0.13.0-beta.rc3 est une version candidate qui ajoute la prise en charge de l’utilisation d’un nœud complet Bitcoin élagué, permet de recevoir et d’envoyer des paiements à l’aide de Atomic MultiPath (AMP) et augmente ses capacités PSBT, entre autres améliorations et corrections de bogues

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 (BIP) et Lightning BOLT.

Bitcoin Core # 20833 est le premier PR dans un effort pour mettre en œuvre l’acceptation des packages mempool dans Bitcoin Core. Cette modification permet au testmempoolaccept RPC d’accepter plusieurs transactions où les transactions ultérieures peuvent être issues de transactions antérieures. Les futurs PR pourraient permettre de tester les chaînes de transaction L2, de soumettre des packages de transaction directement au pool de mémoire via des RPC et de communiquer des packages sur le réseau P2P
Bitcoin Core #22017 met à jour le certificat de signature de code utilisé pour les versions de Windows après la révocation du certificat précédent par son émetteur sans qu’il fournisse une raison explicite. Plusieurs versions récentes de Bitcoin Core pourraient être rééditées avec des numéros de version légèrement différents afin que leurs binaires Windows puissent utiliser ce certificat

Plus le nombre de sorties dépensées ensemble est élevé, plus les frais peuvent être élevés par rapport à un portefeuille avec des indicateurs par défaut, mais aussi, moins il est probable que des tiers soient en mesure d’identifier les transactions ultérieures de l’utilisateur

C-Lightning #4501 ajoute des schémas JSON pour la sortie d’environ la moitié des commandes actuelles de C-Lightning (avec des schémas pour l’autre moitié qui devraient être ajoutés à l’avenir). La sortie produite lors d’une exécution de la suite de tests de C-Lightning est validée par rapport aux schémas pour assurer la cohérence. Les schémas sont également utilisés pour générer automatiquement la documentation de C-Lightning sur la sortie produite par chaque commande

/li>

LND # 5155 ajoute une option de configuration pour sélectionner au hasard les UTXO de portefeuille à dépenser dans une transaction ; cela réduit la fragmentation UTXO dans le portefeuille au fil du temps. En revanche, l’algorithme de sélection de pièces par défaut dans LND dépense les UTXO de valeur plus élevée avant les UTXO de valeur inférieure ; cela minimise les frais à court terme mais peut entraîner la nécessité de payer des frais plus élevés à l’avenir lorsque tous les intrants proches de la taille d’une transaction, ou plus, ont déjà été dépensés

si elle est définie, permet aux transactions de clôture LN de pouvoir payer n’importe quelle version de script segwit, y compris les types de script qui n’ont pas encore de signification consensuelle sur le réseau, comme les adresses pour la racine pivotante

/li>

Retrouvez l’article d’origine ici.