¿Los identificadores de canal están inherentemente vinculados a los identificadores de nodo en el protocolo Lightning?

Me pregunto si es posible cerrar mi nodo, cambiar mi ID de nodo, pero conservar mis canales en el protocolo Lightning. ¿Existe una limitación inherente al protocolo que evita que esto suceda? Al mirar desde BOLT2, parece que no lo hay.

Tampoco en el nivel de transacción (Bolt3).

Respuestas (2)

BOLT#7 describe en las reglas para recibir channel_announcementmensajes, que cualquier canal previamente conocido con diferentes node_ids, debe resultar en la lista negra de todos los nodos asociados tanto para el mensaje actual como para el canal previamente conocido.

si ha recibido previamente un channel_announcement válido, para la misma transacción, en el mismo bloque, pero para un node_id_1 o node_id_2 diferente:

  • DEBERÍA incluir en la lista negra el node_id_1 y el node_id_2 del mensaje anterior, así como este node_id_1 y node_id_2 Y olvidar cualquier canal conectado a ellos.

EDITAR:

Supongo que una posible forma de evitar lo anterior sería esperar más de 2 semanas y no publicar actualizaciones. Dado que el software generalmente se olvida de los nodos o canales para los que no han recibido una actualización en dos semanas, cuando transmite un node_announcementcanal anterior bajo un nuevo node_id, otros participantes de la red simplemente lo verán como un nuevo canal.

Esto necesitaría negociar con el socio de canal para no cerrarlo y restablecerlo bajo un nuevo node_id, que actualmente no hay forma de hacerlo en la especificación existente.

Su sugerencia de esperar ~ 2 semanas y olvidar no parece seguir el protocolo. Supongo que si está desconectado durante tanto tiempo, la mayoría de los socios de canal forzarán el cierre del canal.
Sí, la idea es un truco para sortear la lista negra. No podrá hacerlo con las implementaciones existentes, pero es posible que pueda hacerlo con software modificado y la cooperación de la contraparte del canal. El problema sería si otras implementaciones se olvidan después de dos semanas, lo cual es solo una recomendación.
@RenePickhardt Parece que es un "detalle de implementación" que la mayoría de los socios de canal obligarán a cerrar el canal. Es decir, el protocolo le permite cambiar su ID de nodo, pero en la práctica es muy difícil hacerlo debido a las implementaciones actuales. Si tuviera que escribir un cliente relámpago, podría eludir esto, ¿correcto? Si estamos pensando en esto desde la perspectiva del adversario, ¿puedes hacer algo con este hecho?

Creo que lo que pides no es posible cuando queremos seguir el protocolo por el siguiente razonamiento: (lo siento, soy un poco débil en BOLT 07)

Si observa BOLT 07 y los mensajes de anuncio de canal, verá que tiene que cerrar la sesión de los canales con los bitcoin_keysque pertenecen al node_idsde funding pupkey.

Si cambias tu node_idno solo tendrías una diferente funding pubkeysino que también tendrías que (intercambiar) ambas firmas por tu channel_announcment-message. Ambas firmas porque cambió los datos en el mensaje de anuncio del canal, por lo que sus socios de canal también tendrían que firmar. Como no veo cómo el protocolo podría manejar tal actualización (el cambio de funding pubkeyfirmas así como el intercambio de nuevas), no veo cómo podría anunciar ese canal.

Por supuesto, debe anunciar el canal si desea que las personas sepan que este canal pertenece a su nuevo node_id. Una solución engañosa podría ser hacer que este canal sea privado, pero aún así su socio de canal probablemente no lo admita de inmediato.

En caso de que esta característica sea necesaria, puedo imaginar cómo podría funcionar un truco dejando el node_id pero haciendo que el canal sea privado y use el próximo enrutamiento Rendez-vous, pero eso también requeriría parchear su nodo Lightning.