Matt Corallo, conocido como TheBlueMatt, es un desarrollador de Bitcoin vinculado a Compact Block Relay, la red de retransmisión FIBRE y rust-lightning. Una pregunta práctica une estos trabajos: ¿cómo mejorar redes y aplicaciones sin confundir la rapidez con la certeza de que todo es correcto?
En GitHub, Matt Corallo utiliza el nombre TheBlueMatt. Su perfil avisa de que muchos repositorios se han trasladado a git.bitcoin.ninja. Un repositorio guarda el código fuente y su historial de cambios, por lo que una ubicación antigua vacía no implica necesariamente abandono. Para saber quién aportó qué, conviene seguir ese historial, las propuestas y sus autores. En el caso de Corallo, ese recorrido va desde una transmisión de bloques más eficiente hasta herramientas para Lightning. [1]
Los ordenadores que verifican Bitcoin intercambian continuamente transacciones sin confirmar. Cuando llega un bloque nuevo, pueden conocer ya buena parte de su contenido. Compact Block Relay aprovecha esa circunstancia. BIP 152, la especificación técnica pública, atribuye la autoría a Corallo y agradece a Gregory Maxwell la idea inicial, el diseño y las pruebas. Su objetivo principal es ahorrar datos. La transmisión también puede acelerarse, pero las reglas de validez de los bloques no cambian. [2]
Imagine una lista compartida de documentos: ya tiene la mayoría y solo necesita saber cuáles forman el nuevo paquete. BIP 152 emplea de forma parecida identificadores cortos de transacciones y el mempool, el almacén local de transacciones sin confirmar. El receptor pide los datos que faltan mediante getblocktxn. Los identificadores pueden colisionar: dos transacciones distintas pueden tener la misma etiqueta corta. Ahorrar tráfico no elimina la necesidad de obtener los datos reales y comprobar que el bloque reconstruido es el correcto. [2]
En condiciones concretas, BIP 152 permite anunciar un bloque de forma compacta antes de verificar por completo todas sus transacciones. Eso no autoriza a retransmitir cualquier cosa: hay que comprobar la cabecera, su enlace con la cadena validada, la prueba de trabajo y su compromiso con las transacciones incluidas. Una vez reconstruido, el bloque se procesa normalmente. El receptor sigue verificando que se gasten fondos existentes conforme a las reglas. «El bloque ha llegado» no equivale a «el bloque es válido». [2]
Internet transporta los datos en pequeñas piezas llamadas paquetes. Si una se pierde, esperar su reenvío añade retraso. El 7 de julio de 2016, Corallo describió FIBRE: combina bloques compactos con UDP, un transporte sin reenvío automático de paquetes perdidos, y FEC, una codificación que permite recuperar partes ausentes. Los datos adicionales ayudan a reconstruir el contenido sin otra petición. A cambio se transmite más información; no se garantiza una entrega impecable en cualquier circunstancia. [3]
FIBRE puede reenviar paquetes antes de comprobarlos. Ahorra tiempo, pero exige una confianza interna fuerte entre sus nodos. No significa aceptar cualquier conexión sin verificar. El código público permite crear otras redes, aunque el operador de una red concreta puede elegir con quién conectarse. Según las preguntas frecuentes, w0xlt y Justin, de Localhost Research, asumieron el mantenimiento en 2025 con el asesoramiento de Corallo y Maxwell. El proyecto continúa así mediante el trabajo de otras personas. [4]
Otra parte de la obra de Corallo está relacionada con Lightning, una red de pagos mediante canales sobre Bitcoin. El manifiesto, es decir, la descripción del paquete lightning de rust-lightning, cita a Matt Corallo como autor. La biblioteca está escrita en Rust y ofrece las funciones centrales de Lightning, dejando a la aplicación elegir la cartera, la interacción con la cadena, el almacenamiento y la red. Esa atribución no significa que una sola persona escribiera todos los cambios posteriores ni que la biblioteca sea ya una cartera completa. [5]
LDK se integra en la aplicación como un SDK, un conjunto de herramientas para desarrolladores. Estos deben conectar el almacenamiento y los demás componentes necesarios. El resultado de un pago no tiene por qué llegar al iniciarlo: LDK comunica después el éxito o el fallo mediante un evento que la aplicación debe procesar. Iniciar la operación no confirma su éxito. Para quien utiliza la cartera, la exigencia es sencilla: la pantalla debe distinguir un pago en curso de uno completado. [6]
Para obtener la imagen más completa, lee esta entrada junto con Gregory Maxwell, Luke Dashjr, Satoshi Nakamoto. También enlazan con esta entrada Stratum V2, Gregory Maxwell, Luke Dashjr.