Supongamos que estoy usando un dispositivo computacionalmente muy limitado (por ejemplo, un sensor) y usa Lightning Network para enviar/recibir pagos. Sin embargo, al estar limitado desde el punto de vista computacional, no desea reenviar los pagos entrantes que en realidad están destinados a otros nodos. Las razones podrían ser que el reenvío de un pago requerirá que reenvíe el htlc, lo cumpla y calcule la cebolla para enrutarlo al siguiente nodo, lo que podría ser computacionalmente agotador. Sin embargo, enviar un error sería solo una operación después de analizar la cebolla.
Cada vez que el nodo del sensor analiza la cebolla y ve que el pago no es para él, enviará un mensaje de error temporary_node_failureo . temporary_channel_failureEn situaciones en las que el software Lightning utiliza algunas herramientas de análisis de datos como el piloto automático, otros nodos pueden evitar por completo que este nodo sensor reenvíe los pagos debido a su alta tasa de fallas.
¿Es esto algo que se puede implementar con un ligero ajuste a las implementaciones de rayos actuales (como LND o c-lightning)? Si la tasa de fallas es demasiado alta, ¿hay algo como un banscore que otros nodos mantienen que podría evitar que este nodo sensor reciba/envíe pagos en el futuro?
Sí, básicamente hay dos formas de evitar convertirse en un nodo de reenvío:
La primera es compatible con el propio protocolo y es una medida proactiva contra el reenvío de cualquier pago que no esté destinado a usted, mientras que la segunda es una medida reactiva y le permitiría decidir por HTLC si desea reenviarlo. o ahora.
El protocolo permite que los canales permanezcan privados y no se anuncien en la red más amplia:
Solo el bit menos significativo de channel_flags está definido actualmente: anunciar_canal. Esto indica si el iniciador del flujo de fondos desea anunciar este canal públicamente en la red, como se detalla en el BOLT #7.
Esto significa que el canal no se incluirá en los chismes y los nodos no aprenderán sobre la existencia del canal. Luego, para recibir pagos, lo que requiere que el remitente calcule una ruta hacia usted a través de ese canal no anunciado, usted le informa selectivamente al remitente sobre el canal en la factura utilizando sugerencias de ruta, es decir, el campo en rla factura.
El segundo método mencionado anteriormente implica instrumentar el nodo de manera que acepte HTLC, pero rechace inmediatamente cualquier HTLC para el que no sea el destino. Esto tiene varias desventajas, entre las cuales está el hecho de que está anunciando canales que fundamentalmente no están operativos para el reenvío, y todavía tiene que procesar todos los HTLC ya que no puede filtrarlos antes de tiempo. Esto corresponde al escenario que mencionó Rene Pickhardt . La sobrecarga computacional consiste en:
Ambos métodos se implementan en algunas implementaciones: la versión móvil de eclair no anuncia sus canales de forma predeterminada, lnd planea implementar un sesgo contra (aunque no una exclusión completa) canales y nodos que han demostrado ser poco confiables y c-lightning permite que implemente cualquier política de reenvío que desee como un complemento utilizando el htlc_acceptedgancho. Además, es trivial modificar lnd y c-lightning para que el anuncio de los canales sea configurable.
(Descargo de responsabilidad: soy uno de los autores de especificaciones y trabajo en c-lightning)
update_add_htlca su par local utilizando el local channel_idque solo conocen usted y su par. La recepción se realiza agregando el short_channel_id, cltv_expiry_deltay el de su par local node_iddentro del rcampo de la factura; esto permite que un remitente se comunique con usted sin saber nada sobre su nodo, siempre que pueda descubrir a su par a través de la red de chismes.La respuesta TL;DR es: Sí, es totalmente posible, pero hasta donde yo sé, no está implementado en ningún software de Lightning Node en este momento.
Sin embargo, deseo elaborar un poco. En tu pregunta escribiste:
Las razones podrían ser que el reenvío de un pago requerirá que reenvíe el htlc, lo cumpla y calcule la cebolla para el enrutamiento al siguiente nodo, lo que podría ser computacionalmente agotador.
¡Cuando acepto un pago, tengo que seguir todos estos pasos! Tengo que aceptar un update_add_htlcmensaje entrante que contiene un onion. Luego tengo que descifrar la cebolla y si tengo la preimagen suelte la payment_preimagepara asentar/cumplir la cebolla. Puedo asegurarme un poco de calcular la próxima cebolla, pero eso no es más complejo que descifrar la cebolla entrante, lo que tendría que hacer en cualquier caso. Así que los ahorros pueden ser pequeños aquí.
también preguntaste:
Si la tasa de fallas es demasiado alta, ¿hay algo como un banscore que otros nodos mantienen que podría evitar que este nodo sensor reciba/envíe pagos en el futuro?
Creo que Alex Bosworth de lnd anunció que a partir de la próxima versión principal (supongo que debería ser lnd 0.8) quieren comenzar a realizar un seguimiento de los nodos de enrutamiento buenos y malos y crear una puntuación interna que se utilizará en el cálculo de rutas. De esa manera, planean pasar de la tarifa de enrutamiento más barata a métricas como la confiabilidad y el tiempo de actividad.
Los BOLT en realidad no especifican cómo se supone que se debe calcular la búsqueda de rutas, por lo que cualquier implementación puede hacer lo que quiera en este extremo.
Un último pensamiento. Hay personas que trabajan en la billetera de hardware para Lightning, una política para esas billeteras es ser al revés de lo que pides. Tenga las claves privadas en el nodo para permitir el enrutamiento de los pagos, pero si se supone que se debe enviar un nuevo pago, tenga un dispositivo con espacio de aire que ayude a firmar los mensajes que se necesitan.
Dicho todo esto, es totalmente posible que un nodo decida implementar solo una parte del protocolo. Sin embargo, el envío y la recepción son exactamente los mensajes y las partes de los protocolos que se necesitan para el enrutamiento de todos modos (ya que un pago ingresa al aceptar un htlc) y un pago sale al ofrecer un htlc. En realidad, es la capacidad de enviar pagos lo que actualmente hace que el mantenimiento de un nodo de rayos sea un gasto, ya que necesitan participar en chismes (que es la operación más costosa) para participar en el enrutamiento basado en la fuente que se necesita para iniciar un pago.
Si solo desea ser un nodo de enrutamiento, puede optar por no participar en los chismes y simplemente mantener sus canales de pago y su estado, lo que tiene un costo extremadamente bajo.
marca h
announceestablecido en0en elopen_channelmensaje)? Si no está enrutando pagos, no es necesario que sus canales sean públicos.Ugam kamat