LDK 0.3 RC3 étend le Lightning Splicing et BOLT 12

Rust-Lightning, également appelé Lightning Development Kit (LDK), a fait évoluer sa version 0.3 de RC2 à RC3 et ajouté des améliorations majeures pour les développeurs et opérateurs de nœuds du Bitcoin Lightning Network. LDK 0.3 étend le channel splicing avec la prise en charge du replace-by-fee (RBF), la possibilité d’ajouter et de retirer des fonds en une seule opération, ainsi que des API pour suivre les splices en attente et les transactions de financement abandonnées. La prise en charge des anchor channels a également été élargie, tandis que la négociation de HTLC sans frais est désormais activée par défaut. Les anciens canaux antérieurs à la prise en charge des anchors devraient être progressivement abandonnés. LDK 0.3 ajoute la prise en charge de LSPS1, améliore la gestion de LSPS2 et étend les fonctionnalités de BOLT 12, notamment les payer proofs, les métadonnées de paiement et les offers pour les phantom nodes. L’interception des HTLC, les chemins de paiement aveuglés, la confidentialité du routage et la comptabilisation des paiements transférés ont également été améliorées. La signature asynchrone est désormais disponible pour toutes les méthodes ECDSA de channel-signer prises en charge. Les améliorations du stockage et de la fiabilité comprennent PaginatedKVStore, FilesystemStoreV2, l’écriture différée de ChainMonitor et un chargement parallèle plus rapide des moniteurs. Cette version corrige plusieurs problèmes liés au channel gossip, aux réorganisations de la blockchain, au suivi du financement et au splicing. LDK 0.3 requiert Rust 1.75 ou une version ultérieure. Pour les traders Bitcoin, il s’agit principalement d’une actualité liée à l’infrastructure, et non d’un catalyseur direct des prix. LDK 0.3 pourrait favoriser des paiements Lightning plus fiables et améliorer l’utilité de Bitcoin pour les paiements à long terme, mais son impact à court terme sur le marché du BTC devrait rester limité. Les développeurs doivent examiner les risques de migration, car certaines factures BOLT 11 contenant des métadonnées de paiement, les remboursements BOLT 12 non réclamés et les paiements BOLT 12 en cours pourraient devenir incompatibles entre les versions. Les rétrogradations peuvent également être limitées en présence de splices en attente, de surveillance asynchrone et de canaux sans réserve.