LDK 0.3 RC3 amplía el splicing de Lightning y BOLT 12

Rust-Lightning, también conocido como Lightning Development Kit (LDK), ha avanzado su versión 0.3 de RC2 a RC3, incorporando importantes mejoras para los desarrolladores y operadores de nodos de la red Lightning de Bitcoin. LDK 0.3 amplía el soporte para el «splicing» de canales con replace-by-fee (RBF), permite añadir y retirar fondos en una sola operación e incorpora APIs para realizar un seguimiento de los «splices» pendientes y de las transacciones de financiación descartadas. También se ha ampliado el soporte para canales con anclaje, mientras que la negociación de HTLC con comisión cero está activada por defecto. Se espera que los canales antiguos anteriores al anclaje se descontinúen gradualmente. La versión LDK 0.3 añade compatibilidad con LSPS1, mejora la gestión de LSPS2 y amplía la funcionalidad de BOLT 12, incluidas las pruebas del pagador, los metadatos de pago y las ofertas para nodos fantasma. También mejora la interceptación de HTLC, las rutas de pago cegadas, la privacidad del enrutamiento y la contabilidad de los pagos reenviados. La firma asíncrona ya está disponible en todos los métodos compatibles de los firmantes de canales ECDSA. Las mejoras de almacenamiento y fiabilidad incluyen PaginatedKVStore, FilesystemStoreV2, escrituras diferidas de ChainMonitor y una carga paralela más rápida de los monitores. La versión corrige varios problemas relacionados con la difusión de canales, las reorganizaciones de la cadena de bloques, el seguimiento de la financiación y el «splicing». LDK 0.3 requiere Rust 1.75 o posterior. Para los operadores de Bitcoin, se trata principalmente de una noticia de infraestructura, no de un catalizador directo para el precio. LDK 0.3 podría permitir pagos Lightning más fiables y mejorar la utilidad de Bitcoin como medio de pago a largo plazo, pero es probable que su impacto a corto plazo en el mercado de BTC sea limitado. Los desarrolladores deben revisar los riesgos de migración, ya que algunas facturas BOLT 11 que contienen metadatos de pago, los reembolsos BOLT 12 no reclamados y los pagos BOLT 12 en curso podrían dejar de ser compatibles entre versiones. Las migraciones a versiones anteriores también pueden estar restringidas en casos con «splices» pendientes, supervisión asíncrona y canales sin reserva.