Rusty Russell

Los grandes proyectos suelen empezar discretamente. La retrospectiva de Blockstream del 9 de junio de 2026 recuerda el primer commit de Russell, del 26 de mayo de 2015: una pequeña herramienta para construir un mensaje de apertura de canal. Un commit registra un cambio en el historial del código. Aquel experimento creció hasta convertirse en Core Lightning, con aportaciones de Russell al programa, las pruebas y la formación de otros desarrolladores. El artículo también describe su salida tras once años. No anuncia el fin de todas sus futuras contribuciones ni convierte un liderazgo pasado en autoridad permanente sobre la red. [1]

Imagina una cafetería y un cliente que usan programas distintos. Pagar no debería exigir que ambos elijan al mismo proveedor. Necesitan reglas compartidas sobre los mensajes y su significado. Las especificaciones BOLT describen esa comunicación en Lightning. Russell coordinó su desarrollo colectivo y defendió la interoperabilidad: la capacidad de distintas implementaciones para trabajar juntas. El repositorio público acepta propuestas y comentarios. Ni siquiera un colaborador destacado puede imponer un cambio a todos los nodos por sí solo: las reglas deben trasladarse al software real y a su uso. [1] [2]

Dos programas pueden interpretar un mismo párrafo de manera diferente. lnprototest, creado por Russell, ofrece herramientas en Python para escribir escenarios y comprobar respuestas a mensajes del protocolo. El README, documento introductorio del proyecto, distingue un ejecutor simulado de las pruebas contra una implementación real. La simulación ayuda a preparar una prueba, pero su éxito no demuestra el comportamiento de un nodo real. Importa saber qué se ejecutó y qué situaciones se cubrieron. Una colección de pruebas superadas tampoco es una auditoría completa de todos los fallos posibles. [3]

Con BOLT 12, la cafetería puede publicar una oferta reutilizable, por ejemplo mediante un código QR. La cartera del cliente envía una invoice_request a partir de ella y recibe una factura concreta: una solicitud con los datos de ese pago. Después se paga. La oferta puede reutilizarse mientras cada cliente obtiene facturas individuales. Eso no convierte una factura ya utilizada en una solicitud nueva para cada compra. Separar oferta, petición y factura hace cómodo el pago sin confundir operaciones distintas. [4]

Core Lightning muestra esa separación. El comando fetchinvoice contacta con quien publica la oferta y obtiene una factura. El campo changes puede indicar diferencias frente a la oferta, como el importe o la descripción. Una respuesta correcta no envía dinero. Es como recibir la cuenta de la cafetería: primero compruebas qué vas a pagar y cuánto. La cartera debe procesar las condiciones recibidas e iniciar el pago por separado. Terminar de obtener una solicitud no equivale a completar su pago. [5]

La documentación de pay distingue complete, pending y failed: completado, pendiente y fallido. Pendiente no significa pagado. También separa amount_msat, el importe recibido por el destinatario, de amount_sent_msat, el total enviado con comisiones. msat significa millisatoshi, una milésima de satoshi. El cliente puede gastar una comisión más de lo que recibe la cafetería. La documentación ya marca pay como obsoleto y describe la transición a xpay. Aquí se explican estados e importes, no se recomienda instalar una versión concreta; hay que interpretar los resultados según el programa utilizado. [6]

Cuando la cafetería devuelve dinero, no rebobina el pago original. BOLT 12 también describe el flujo inverso: el comercio anuncia cuánto quiere enviar, el cliente proporciona una factura y el comercio comprueba invoice_node_id, el identificador del nodo al que va a pagar. Después realiza un nuevo pago al cliente. No cancela la transferencia original ni concede automáticamente un derecho a devolución. El protocolo ofrece una forma de realizarla; las partes deben acordar por separado el motivo y las condiciones. [4]

En una disputa conviene saber exactamente qué demuestra una prueba. BOLT 12 explica que el preimage, el valor secreto correspondiente al hash de una solicitud de pago, puede demostrar que una factura fue pagada. Sin embargo, una vez publicado, cualquiera puede mostrarlo; por sí solo no identifica a quien envió el dinero. Una clave incluida en la petición permite demostrar quién solicitó la factura, pero no verifica automáticamente su identidad civil. Una factura pagada, el control de una clave y la identidad del cliente son hechos distintos. [4]