Le bulletin de cette semaine résume les discussions en cours sur la récompense des mineurs en pool avec des parts d’ecash échangeables et décrit une nouvelle proposition pour permettre la résolution offchain des DLC. Sont également incluses nos sections régulières annoncant des mises à jour et des versions candidates, et résumant les changements notables dans les principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Discussion continue sur la récompense des mineurs de pool avec des parts d’ecash échangeables : Depuis notre résumé précédent, la discussion a été suivie d’un fil de discussion sur Delving Bitcoin concernant le paiement des mineurs en pool avec de l’ecash pour chaque part qu’ils soumettent. Auparavant, Matt Corallo avait demandé pourquoi un pool mettrait en œuvre le code supplémentaire et la comptabilité nécessaires pour gérer des parts d’ecash échangeables lorsqu’ils pourraient simplement payer les mineurs en utilisant une monnaie ecash normale (ou via LN). David Caseria a répondu que dans certains schémas pay per last N shares (PPLNS), tels que TIDES, un mineur pourrait devoir attendre que le pool trouve plusieurs blocs, ce qui pourrait prendre des jours ou des semaines pour un petit pool. Au lieu d’attendre, un mineur avec des parts d’ecash pourrait immédiatement les vendre sur un marché ouvert (sans divulguer au pool ou à un tiers quoi que ce soit sur leur identité, pas même une identité éphémère utilisée lors du minage).

    Caseria a également noté que les pools de minage existants trouvent difficile de soutenir financièrement le schéma full paid per share (FPPS) où un mineur est payé proportionnellement à la récompense totale du bloc (subvention plus frais de transaction) lorsqu’ils créent une part. Il n’a pas donné de détails, mais nous comprenons que le problème est la variation des frais obligeant les pools à conserver de grandes réserves. Par exemple, si un mineur de pool contrôle 1% de la puissance de hachage et crée des parts sur un modèle avec environ 1 000 BTC en frais et 3 BTC en subvention, son pool lui devra environ 10 BTC. Cependant, si le pool ne mine pas ce bloc et si au prochain bloc qu’il mine, les frais sont de retour à une fraction de la récompense du bloc, le pool pourrait n’avoir que 3 BTC au total à répartir entre tous ses mineurs, l’obligeant à payer à partir de ses réserves. Si cela arrive trop souvent, les réserves du pool seront épuisées et il fera faillite. Les pools abordent ce problème de diverses manières, y compris en utilisant des proxies pour les frais réels.

    Le développeur vnprc a décrit la solution qu’il a développée qui se concentre sur les parts d’ecash reçues dans le schéma de paiement PPLNS. Il pense que cela pourrait être particulièrement utile pour lancer de nouveaux pools : actuellement, le premier mineur à rejoindre un pool subit la même haute variance que l’exploitation minière en solo, donc typiquement les seules personnes qui peuvent démarrer un pool sont les grands mineurs existants ou ceux prêts à louer une puissance de calcul (hashrate) significative. Cependant, avec les parts ecash PPLNS, vnprc pense qu’un pool pourrait se lancer en tant que client d’un pool plus grand, de sorte que même le premier mineur à rejoindre le nouveau pool recevrait une variance plus faible que celle du minage solo. Le pool intermédiaire pourrait alors vendre les parts ecash qu’il gagne pour financer le schéma de paiement qu’il choisit de payer à ses mineurs. Une fois que le pool intermédiaire a acquis une quantité significative de hashrate, il aurait également un levier pour négocier avec les pools plus grands sur la création de modèles de blocs alternatifs qui conviennent à ses mineurs.

  • ● DLC offchain : un développeur a exposé sur la liste de diffusion DLC-dev un protocole de contrat qui permet une dépense offchain de la transaction de financement signée par les deux parties pour créer plusieurs DLCs. Après que le DLC offchain a été réglé (par exemple, toutes les signatures d’oracle requises ont été obtenues), une nouvelle dépense offchain peut être signée par les deux parties pour réallouer les fonds selon la résolution du contrat. Une troisième dépense alternative peut ensuite allouer les fonds à de nouveaux DLCs.

    Les réponses de Kulpreet Singh et Philipp Hoenisch ont fait référence à des recherches et développements antérieurs de cette idée de base, y compris des approches qui permettent d’utiliser le même pool de fonds à la fois pour les DLCs offchain et pour LN (voir les Bulletins #174 et #260). Une réponse de Conduition décrit la principale différence entre sa proposition et les propositions précédentes.

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.

  • ● LDK v0.1 est une sortie importante de cette bibliothèque pour la construction de portefeuilles et d’applications compatibles LN. Les nouvelles fonctionnalités comportent “le support pour les deux côtés des protocoles de négociation d’ouverture de canal LSPS, […] le support pour la résolution de noms lisibles par l’homme BIP353, [et une réduction des] coûts de frais onchain lors de la résolution de plusieurs HTLCs pour une fermeture forcée de canal.”

Changements notables dans le code et la documentation

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

  • ● Eclair #2936 introduit un délai de 12 blocs avant de marquer un canal comme fermé après que sa sortie de financement a été dépensée pour permettre la propagation d’une mise à jour splice (voir le Bulletin #214 et la description de la motivation par un développeur d’Eclair tbast splice). Les canaux dépensés sont temporairement suivis dans une nouvelle carte spentChannels, où ils sont soit retirés après 12 blocs, soit mis à jour en tant que canaux épissés. Lorsqu’une épissure se produit, l’identifiant court du canal parent (SCID), la capacité et les limites de solde sont mis à jour au lieu de créer un nouveau canal.

  • ● Rust Bitcoin #3792 ajoute la capacité d’encoder et de décoder les messages de transport P2P v2 de BIP324 (voir le Bulletin #306). Cela est réalisé en ajoutant une structure V2NetworkMessage, qui encapsule l’énumération originale NetworkMessage et fournit l’encodage et le décodage v2.

  • ● BDK #1789 met à jour la version de transaction par défaut de 1 à 2 pour améliorer la confidentialité du portefeuille. Avant cela, les portefeuilles BDK étaient plus identifiables du fait que seulement 15% du réseau utilisait la version 1. De plus, la version 2 est requise pour une future mise en œuvre du mécanisme anti fee sniping basé sur nSequence de BIP326 pour les transactions taproot.

  • ● BIPs #1687 fusionne BIP375 pour spécifier l’envoi de paiements silencieux en utilisant les PSBTs. S’il y a plusieurs signataires indépendants, une preuve DLEQ est requise pour permettre à tous les signataires de prouver aux co-signataires que leur signature ne dépense pas les fonds de manière abusive, sans révéler leur clé privée (voir le Bulletin #335 et le Recap #327).

  • ● BIPs #1396 met à jour la spécification payjoin de BIP78 pour s’aligner sur la spécification PSBT de BIP174, résolvant un conflit précédent. Dans BIP78, un receveur supprimait auparavant les données UTXO après avoir complété ses entrées, même si l’expéditeur avait besoin des données. Avec cette mise à jour, les données UTXO sont désormais conservées.