Qué pasó
El 21 de agosto de 2026 el Lightning Development Kit integró
dos commits
que hacen que un nodo rechace un input de splice presentado como propio de un solo par
cuando pertenece a los dos. El primero describe el problema con sus propias palabras: "Un
iniciador malicioso de splice puede codificar el outpoint de financiación compartido
esperado usando prevtx y omitiendo shared_input_txid. El receptor contabiliza entonces
toda la salida de financiación anterior como propiedad del iniciador, lo que permite que
salidas adicionales del iniciador consuman el presupuesto de comisión previsto para la
transacción sin dejar de pasar la comprobación de tasa por parte"
(commit 972a25c1).
El commit atribuye el reporte al Bitcoin Red Team.
Qué cambia
Un splice redimensiona un canal Lightning sin cerrarlo. La transacción de splice gasta la salida de financiación actual del canal y paga a una nueva de otro tamaño. Esa salida de financiación es un 2-de-2, así que es el único input que ambos pares tienen que firmar: el input compartido.
Los dos pares construyen la transacción juntos, cada uno añadiendo inputs y salidas, y
BOLT 2 reparte la
cuenta. El iniciador paga por los campos comunes; "el resto de los bytes de la transacción
son responsabilidad del par que aportó ese input o esa salida". Al terminar el intercambio,
cada lado revisa al otro y debe abortar si "la tasa pagada por el par no alcanza o supera la
feerate acordada", o si los inputs del par valen menos que sus salidas.
El input compartido se anuncia de forma distinta a uno propio. El iniciador "DEBE añadir el
input del canal actual a la transacción de splice enviando tx_add_input con
shared_input_txid" y "NO DEBE incluir prevtx para ese input compartido", porque prevtx
existe para probar el valor y el script de un input que el receptor nunca ha visto, y ambos
lados ya conocen su propia salida de financiación.
LDK leía primero la otra rama de ese mensaje. Un input con
prevtx y sin shared_input_txid se tomaba como propiedad exclusiva de quien lo enviaba,
apuntara a donde apuntara, de modo que un iniciador que enviase la transacción de financiación
anterior completa quedaba acreditado con todo el saldo del canal, incluida la mitad del
receptor. Ese crédito de más es el que pagaba las salidas propias del iniciador mientras su
aritmética seguía cuadrando.
La firma seguía a la transacción y no a la negociación. Al construirla, LDK localizaba el
input compartido buscando el outpoint de financiación, "con independencia de cómo se hubiera
contabilizado ese input durante la negociación"
(commit 65ca961e),
así que el receptor ponía su clave sobre el input que acababa de anotar como ajeno. El
resultado "puede por tanto quedar completamente firmado y ser válido según consenso mientras
paga menos que la comisión negociada". La corrección rechaza un prevtx que nombre el
outpoint de financiación compartido, y toma el input compartido de cómo lo clasificó la
negociación.
Qué no cambia
No es una vía hacia el saldo del canal. Lo que gana el iniciador es el presupuesto de comisión: la transacción confirma a una tasa menor que la acordada por ambos lados, y hasta que confirme el canal queda a medio splice. Eso es un coste real y no es un robo de los fondos de la contraparte, y el mensaje del commit no afirma nada más.
Solo alcanza a nodos que aceptan splices de pares en los que no tienen motivo para confiar.
LDK lo condiciona a UserConfig::reject_inbound_splices, que existe desde que el splicing
llegó en la versión 0.2, el 2 de diciembre de 2025.
No arregla nada de lo que hay instalado. Los commits están en la rama principal de
desarrollo, que lleva la versión 0.3.0. Ni la rama 0.3 ni la rama 0.2, cuya publicación más
reciente es la 0.2.5 del 4 de agosto de 2026, los contienen, y la misma rama sin protección
de prevtx sigue en el código de 0.2. Y no dice nada sobre las demás implementaciones: cada
una ha escrito su propia construcción interactiva de transacciones, y un fallo en una no es
prueba sobre las otras.
Contexto
El splicing es joven y la complejidad está exactamente en esta maquinaria. La propia serie 0.2 de LDK ya traía una corrección del mismo vecindario: un canal con saldo exactamente cero y comisiones de compromiso a cero permitía que "la contraparte sacase todo su saldo mediante un splice, incumpliendo los requisitos de reserva que en otro caso estaría obligada a mantener".
El otro patrón que merece atención es quién lo encontró. Las mismas notas de versión que incluyen esa corrección agradecen a Project Loupe los problemas de seguridad reportados, y este commit acredita al Bitcoin Red Team. Las implementaciones de Bitcoin se están leyendo a un ritmo al que no se habían leído antes, y el resultado visible es una cola de parches pequeños, concretos y bien descritos, no un incidente. El límite de LND a la memoria del gossip llegó del mismo modo a principios de este mes: no eran fondos, sino algo que un nodo estaba haciendo y no debía.