405 / 736DECKER

Christian Decker

Investigador de canales de pago y desarrollador de Lightning

Christian Decker estudia cómo funciona Bitcoin entre ordenadores reales y cómo construir pagos seguros sobre esa red. Su trabajo abarca la propagación de bloques, eltoo y Greenlight. Los une una pregunta práctica: ¿cómo mantener el control del dinero cuando los mensajes llegan tarde, la otra parte deja de colaborar o alguien más opera parte de la infraestructura?

Christian Decker es investigador y desarrollador de Bitcoin y Lightning, una red de pagos mediante canales. Ha trabajado en la propagación de datos, eltoo, BIP 118 y Greenlight. Sus aportaciones se entienden mejor por los problemas que abordan: información distinta entre participantes, acuerdos de saldo desactualizados y las tareas que exige operar un nodo.

Al buscar el trabajo de Decker aparecen la cuenta cdecker y el nombre Snyke. Su perfil público también indicaba Blockstream al revisarlo en octubre de 2026. Eso permite vincular al autor con código y propuestas, pero una breve biografía no basta para establecer su cargo actual. En una red abierta, una propuesta vale por el problema que resuelve y por cómo supera la revisión. El nombre o el empleador no otorgan autoridad para cambiar las reglas de los demás. [1]

Un bloque nuevo se propaga por etapas: un ordenador lo transmite a otros y ese viaje lleva tiempo. Christian Decker y Roger Wattenhofer lo midieron en un estudio de 2013. Analizaron la difusión de transacciones y bloques y su relación con bifurcaciones temporales, cuando distintas partes de la red trabajan con bloques recientes diferentes. Esas mediciones históricas ayudan a entender el funcionamiento práctico, pero no describen la velocidad actual de Bitcoin: el software y la transmisión han cambiado. [2]

En un canal de pago, los participantes acuerdan repetidamente qué parte de los fondos comprometidos corresponde a cada uno. ¿Y si alguien lo cierra con un acuerdo antiguo que le favorece? La propuesta eltoo de Decker, Rusty Russell y Olaoluwa Osuntokun permite imponer un estado más reciente antes de la liquidación final. Es como sustituir un cálculo desactualizado por el último acuerdo. Se trata de un mecanismo propuesto, no de una función presente automáticamente en todos los canales Lightning actuales. [3]

Poder corregir no basta. En eltoo, la transacción correctora debe confirmarse antes de que el estado antiguo pueda liquidarse. OP_CSV establece el margen de reacción: permite un gasto concreto solo después de un plazo contado desde la confirmación de la salida correspondiente. Por ello, el usuario o un servicio designado debe vigilar la cadena. La propuesta cambia cómo se resuelven los estados antiguos, pero no hace seguro permanecer desconectado indefinidamente. [3]

Aplicar un acuerdo nuevo a distintos estados anteriores exige reglas de firma adecuadas. BIP 118, de Decker y Anthony Towns, propone SIGHASH_ANYPREVOUT. Al revisarlo en octubre de 2026, figuraba como Draft, es decir, borrador, y describía un cambio de consenso mediante soft fork: una modificación de las reglas de validación de los nodos Bitcoin. Publicarlo o lograr apoyo de desarrolladores no demuestra su activación. Propuesta, implementación y adopción son pasos diferentes. [4]

Normalmente, una firma también queda vinculada a la salida concreta de una transacción anterior que se gasta: un importe con condiciones de gasto. BIP 118 flexibiliza ese vínculo en un modo elegido. La transacción firmada puede asociarse a otra salida compatible, lo que ayuda a sustituir estados antiguos del canal. No permite gastar arbitrariamente dinero ajeno. La mayor posibilidad de reutilizar una firma exige un diseño cuidadoso. Según el modo, también importan los vínculos con el importe y las condiciones de gasto. [4]

Operar un nodo Lightning exige mantenimiento. Blockstream anunció el lanzamiento público de Greenlight el 12 de octubre de 2023, con Decker como responsable del proyecto. El servicio reparte las tareas: el usuario conserva las claves privadas y un proveedor opera la infraestructura del nodo. Una clave privada autoriza gastos; conservarla no equivale a gestionar un servidor. Este modelo no garantiza una disponibilidad ininterrumpida ni condiciones comerciales invariables. Esos aspectos deben evaluarse por separado. [5]

Core Lightning es un programa para operar un nodo Lightning. Sus plugins o complementos amplían funciones según las necesidades del operador; reckless ayuda a instalarlos y activarlos. Es un cambio de naturaleza distinta al de las reglas de firma de Bitcoin. Instalar un complemento no incorpora BIP 118 a las reglas de toda la red. El trabajo de Decker conecta investigación, propuestas de protocolo y herramientas prácticas, aunque cada ámbito tiene su propio camino hasta el uso real. [6]

Para obtener la imagen más completa, lee esta entrada junto con Elizabeth Stark, Andreas Antonopoulos, Lightning Network. También enlazan con esta entrada Elizabeth Stark, Andreas Antonopoulos.

DOC · 001Christian Decker — public developer profileDocumentación DOC · 002Decker and Wattenhofer — Information Propagation (2013)Documentación DOC · 003Decker, Russell and Osuntokun — eltooDocumentación DOC · 004BIP 118 — SIGHASH_ANYPREVOUTDocumentación DOC · 005Blockstream — Greenlight launch (2023)Documentación DOC · 006Core Lightning — pluginsDocumentación
Revisado: Fuentes primero · No es asesoramiento financiero