Investigando sobre los algoritmos de enrutamiento disponibles para Bitcoin Lightning Network, he estado leyendo el documento técnico de Flare y me vino a la mente esta idea/pregunta:
Dado que todos los canales de pago se crean con una transacción de cadena de bloques, y Flare mismo verifica la cadena de bloques para ver si un canal está activo o si se ha cerrado, ¿no sería posible analizar la cadena de bloques para todos los canales de pago en vivo para crear un completo? -mapa actualizado de la Red para que no tenga que usar inundaciones o balizas en la propia Red?
¿Las transacciones en cadena que crean el canal de pago almacenan las identificaciones de los nodos? Si es así, entonces esto parece una táctica trivial y tal vez efectiva.
¿No sería posible analizar la cadena de bloques para todos los canales de pago en vivo para crear un mapa completo y actualizado de la red para que no tenga que usar inundaciones o balizas en la propia red?
No, porque no es posible saber qué transacciones están relacionadas con la apertura de un canal de pago y las transacciones de cierre del canal pueden ser ambiguas. La transacción de financiación envía dinero a un multisig 2 de 2, pero estos están en salidas como un script P2WSH o P2SH-P2WSH, lo que significa que no se conoce el script de redimir que especifica el 2 de 2. No puede asumir que cualquier P2WSH o P2SH (porque un P2SH-P2WSH se parece a un P2SH) es para financiar un canal de pago.
Para el cierre de transacciones, si hay un cierre cooperativo, entonces el gasto de los resultados de la transacción de financiación se verá como un multigrado normal de 2 de 2, lo que no es indicativo de un canal de pago. En un cierre unilateral, podría identificar el cierre unilateral solo después de que la persona que cierra el canal gaste su producción.
pebwindkraft