Nodos de enrutado en la Lightning Network

Tiempo de lectura aprox: 22 minutos, 11 segundos

Bitcoin es soberanía y Lightning Network es una red de nodos Bitcoin conectados por canales, a través de los que se realizan y reciben pagos de forma instantánea, más privada y con menores comisiones, quedando todo registrando en la cadena de bloques de Bitcoin, el oro 2.0.

Un poco de historia

En marzo de 2018 @Stadicus3000 publicó en GitHub la guía «DIY» para Raspibolt (a la postre Raspibolt I), un nodo Bitcoin, que incorporaba Lightning Network, funcionando en una Raspberry Pi; la configuración completa se hacía paso a paso y desde cero mediante conexión SSH.

Más allá de poner al alcance de cualquiera con un mínimo de ganas, algo tan trascendente como correr su propio Bitcoin “full node”, abrió las puertas de un mundo mágico y soñado, en el que muchos han vuelto a ser niños, jugando, aprendiendo y aportando al ecosistema Bitcoin. «I am Stadicus, a Bitcoin minimalist and a full node maximalist», así comenzó su charla en la “Lightning Conference” de Berlín en octubre de 2019. Gratitud eterna, gracias por encender la llama.

Raspibolt I se acomodaba en cualquier rinconcito de la casa, ocupando poco espacio, sin hacer ruido y con un consumo mínimo; eso sí, no trataras de explicar que era y para que servía porque era batalla perdida. Recuerdo cuando se lo enseñe a un familiar, me miró con cara de no saber que decir y para contentarme me dijo: “Se parece mucho a un ventilador, ¿no?” …. “No, el nodo es lo que está detrás del ventilador”.

De todos modos, aquel nodo Raspibolt I no era un equipo sobre el que ningún «hodler» cabal fuera a depositar más allá de un puñado de satoshis para empezar a jugar en la Lightning Network, al menos en “mainnet”.

En diciembre de 2019 se publica el repositorio del nodo Raspibolt II y la propuesta en mucho más robusta. La Raspberry Pi 4 Model B con 4GB de RAM ya estaba en el mercado, la experiencia decía que el disco externo tenía que ser SSD (los HDD son menos estables y toleran con dificultad las desconexiones repentinas, siendo habitual la corrupción de datos y la consiguiente reconstrucción de directorios a partir de “backups”), daba la opción de funcionar en la red TOR, permitía incorporar un servidor Electrs (aunque esto no suponga nada adicional para Lightning)…y si a esto le sumamos algunas protecciones de cosecha propia que comentaremos más tarde, podemos decir que los astros se empezaban a alinear.

Pero Raspibolt II tenía aún un punto débil y era las actualizaciones y la resolución de incidencias, @Stadicus3000 se incorporó a mediados de 2019 a @ShitCryptoHQ (que a principios de 2020 abandonó, para sorpresa de muchos, su proyecto BitBoxBase de nodos Bitcoin para centrarse en la hardware wallet BitBox02) y el mantenimiento del repositorio lógicamente se resintió.

Lo anterior no quiere decir que Raspibolt sea un proyecto abandonado, sigue siendo una referencia y continua teniendo actualizaciones; si de verdad quieres entrar a fondo en la configuración de un nodo Lightning en una Raspberry Pi, y estas dispuesto a disfrutar el viaje, es una de las mejores opciones disponibles. Raspibolt ha tenido algunos compañeros de viaje (Bitcoin “full node” en una Raspberry Pi), que han ido un paso más allá y ofrecen alternativas donde la configuración inicial y el mantenimiento se simplifica, entre ellos Raspiblitz, myNode y BTCPay Server.

Raspiblitz nace a partir de Raspibolt, y la dedicación de @rootzoll, @openoms, @frennkie y otros, ha hecho que se mantenga en el top. Combina la sencillez de poner un nodo en funcionamiento a partir de una imagen cargada en la microSD, con la esencia de interactuar y solucionar muchos problemas desde la línea de comandos, tiene una interfaz gráfica algo austera (mejora en el “backlog” según @rootzoll) pero muy efectiva, y su comunidad tiene un perfil bastante técnico.

Las actualizaciones son constantes y se van integrando muchas de las aplicaciones nuevas que van apareciendo, lo que mantiene a este proyecto en la cresta de la ola y al servicio de lo que demanda la comunidad. La pantallita que incorpora donde se muestra información del estado del nodo, e incluso se puede interactuar con él, es la guinda del pastel.

myNode nace a mediados de 2019 de la mano de Taylor Helsper y la principal novedad es que aporta una interfaz gráfica muy amigable, tiene una completa paleta de aplicaciones y está orientado al usuario que no tiene conocimientos o tiempo para teclear desde la línea de comandos y se quiere centrar en las experiencias que aportan todas las aplicaciones que proporciona, es decir, correr nuestro propio nodo con una dedicación mínima al mantenimiento del mismo.

Al igual que Raspiblitz, es modular y permite activar solo las aplicaciones que consideremos necesarias, minimizando así posibles fallos por errores o incompatibilidades y disminuyendo la superficie de ataque. Su repositorio de GitHub tiene actividad continua, dispone de actualizaciones frecuentes y la comunidad es muy activa…puede que no tan técnica como la de Raspiblitz, pero con unas ganas enormes de experimentar.

Después de probar myNode durante un par de meses llegué a la conclusión de que era justamente lo que necesitaba, dispone de una versión Premium que te permite funcionar en la red TOR, actualizar el nodo a golpe de “click” y añade soporte para resolución de incidencias. En esos meses también armé un BTCPay Server, pero ese Ferrari está destinado a otras carreteras.

Nodo Lightning

Instalando nuestro nodo Lightning

Por lo tanto, consciente de que antes de instalar un nodo de enrutado y bloquear en él varios miles de satoshis había que asegurar que se mantuviera “online” en continuo, que lo hiciera de manera estable, que fuera sencillo de mantener y con actualizaciones periódicas, myNode fué la elección; un myNode activado únicamente con las aplicaciones necesarias para gestionar un nodo Lightning.

Raspiblitz hubiera sido igualmente una decisión acertada, más aún viendo como ha evolucionado en los últimos meses, con más aplicaciones Lightning que myNode e igualmente modular. Las guías de @openoms son referencia no sólo para los usuarios de Raspiblitz sino también para el resto de usuarios de «Lightning Nodes»; véase “Lightning Node Management” https://github.com/openoms/lightning-node-management, un lujo. Como punto adicional, no dispone de ningún «premium» y el paquete completo se instala de forma gratuita.

Si la privacidad es otro punto importante necesitaremos entonces que funcione en la red TOR, esto no impedirá que se relacione con nodos que operan en la «clearnet». Además, si el nodo funciona en TOR, nos ahorramos el jaleo de abrir puertos y redireccionar tráfico en el router si queremos operar el nodo fuera de nuestra red local y además lo haremos de forma más privada… y también se facilita el poder llevarnos el nodo con nosotros y con tan solo conectarlo a otra red hacer que vuelva a estar “online”.

El nuevo modelo de Raspberry Pi 4B (4GB de RAM son suficientes, aunque también hay de 8GB si queremos ir más que sobrados) permiten que el nodo realice la configuración inicial en poco tiempo (unas 60 horas con una buena conexión a internet) y opere en continuo con estabilidad y fluidez; es importante comprobar que la fuente de alimentación seleccionada va a suministrar la potencia necesaria, una tarjeta microSD de al menos 16GB (mejor 32GB por el precio que tienen) y un disco duro externo SSD de 1TB. Debemos incorporar disipadores de calor con refrigeración forzada, aunque también los hay de mayor superficie (y llegan a hacer de carcasa) que permiten prescindir del ventilador. La carcasa es el toque final y podemos optar por modelos comerciales o por los personalizados que ofrece la gente de @cryptocloaks.

Para asegurar la máxima disponibilidad del nodo, podemos instalar un “router” que incorpore tarjeta SIM 4G de respaldo y conectar tanto la Raspberry Pi como el “router” a un Sistema de Alimentación Ininterrumpido (SAI, o UPS en inglés); para la potencia demandada por ambos equipos hay SAIs asequibles que pueden mantener varias horas todo el sistema en funcionamiento sin inmutarse.

Como respaldo de lo anterior, en el caso de que el nodo esté “offline” por un corte de Internet, de alimentación eléctrica, corrupción de datos o cualquier otro motivo, es recomendable configurar una “WatchTower” (Torre de Vigilancia) desde otro nodo, que protegerá nuestros canales de ataques maliciosos por parte de los nodos con los que están abiertos, en caso de que intenten publicar estados pasados del canal en los que tuvieran una posición de balance más favorable para ellos, con la intención de robarnos fondos. Si así ocurriera, nuestra Torre reclamaría la totalidad de los fondos del canal, penalizando así el comportamiento no adecuando del otro nodo («penalty transaction» o «justice transaction»).

Esta “WatchTower” nos permitirá por lo tanto apagar el nodo y estar tranquilos de que los fondos en los canales abiertos están a salvo. En caso de que la “WatchTower” no esté activa por cualquier motivo, el periodo de protección será como máximo de dos semanas; este tiempo es función del valor del parámetro “remote_csv_delay” que se haya fijado en los canales, e indica el número de bloques que requerimos retrasar el cierre forzado del canal en caso de realizarse por el otro nodo.

Existen varias implementaciones de Lightning Network; LND (Lightning Network Daemon) es la implementación de Lightning Labs, la más habitual entre usuarios no avanzados (y la utilizada en myNode y Raspiblitz) que permite configurar una Torre de Vigilancia desde otro nodo de forma sencilla, configurando convenientemente el archivo “lnd.conf” en ambos nodos.

No podemos hablar de WatchTowers sin hacer referencia a “The Eye of Satoshi” https://github.com/talaia-labs/python-teos, la Torre de Vigilancia desarrollada por Sergi Delgado desde Talaia Labs y que funciona para la implementación C-Lightning (de Blockstream), proyecto para el que Square Crypto ha destinado apoyo económico a principios de 2020. TOP.

Es importante que el espacio físico donde situemos el nodo sea lo más tranquilo posible, sin variaciones bruscas de temperatura ni vibraciones; y si aún queremos más, podemos monitorizar la zona donde tengamos los equipos con una cámara de vigilancia… no será de gran ayuda, pero tendremos siempre un as en la manga para vacilar a nuestro cuñado cuando le hablemos de Bitcoin.

Abriendo canales y realizando los primeros enrutados

El primer paso, una vez el nodo está configurado, es depositar satoshis en la cartera Lightning, para desde ahí poder bloquear fondos en una “multisig address 2 of 2” (dirección multifirma dos de dos) con otros nodos, que es lo que permite la apertura de canales.

La cartera Lightning del nodo es por el momento una «hot wallet», a futuro se facilitará el proceso de apertura de canales directamente desde “hardware wallets” (“cold wallet”), mejora en pro de la seguridad; debemos tener esto en cuenta y solo depositar fondos que estemos dispuestos a perder.

La selección de nodos con los que abrir canales es importante y, además de con algún amigo que también se mueva en Lightning, siempre será preferible hacerlo con aquellos que tengan buena reputación, más adelante hablaremos sobre esto.

Para seleccionar con que nodos realizar la apertura de canales hay varias fuentes donde consultar:

• https://1ml.com/: donde hay mucha información de cada uno de los nodos Lightning y de sus canales, clasificados por diferentes criterios: capacidad, incremento de esta, número de canales, antigüedad del nodo y disponibilidad. Hay también análisis que muestran los nodos con mayor incremento de canales y de capacidad en los últimos días o semanas. Permite además asociar perfiles de Twitter o páginas web al nodo; de esta página sacaremos mucha información útil.
• https://moneni.com/nodematch: propone una serie de nodos a los que conectarnos, maximizando los nodos a los que llegar de forma directa a través de ellos, sin saltos intermedios.
• LNDManage  (https://github.com/bitromortac/lndmanage): se interactúa desde la línea de comandos y ofrece propuestas en base a diferentes algoritmos basados por ejemplo en los enrutados pasados o en los nuevos nodos que se han añadido a la red; dispone de otras funciones que son útiles para la gestión del nodo.

Para entender el funcionamiento de los canales Lightning se puede pensar en una tubería por la que fluyen los satoshis, y estos sólo pueden estar en nuestro lado del canal (será la “outbound capacity” y son satoshis de los que somos propietarios) o en el extremo opuesto (será la “inbound capacity” y son propiedad del otro nodo). No hay más.

Lo normal cuando abrimos un canal es hacerlo con toda la capacidad de nuestro lado, como «outbound capacity» (depositamos fondos de “onchain” a “offchain”, a Lightning), pero también se puede realizar la apertura empujando parte de los fondos al otro lado del canal (canal balanceado), incluso realizar una apertura con todos los fondos del otro extremo; claro, hay que tener en cuenta que en estos dos últimos casos los satoshis que estén en el otro extremo del canal pasan a ser propiedad del otro nodo.

Una vez registrada la transacción «multisig 2 of 2» en la blockchain de Bitcoin, con al menos tres confirmaciones, nuestro canal ya estará disponible para ser utilizado. Cuando abramos el primer canal, el nodo pasará a estar visible en los exploradores Lightning: https://1ml.com/ , https://lightblock.me/ o https://bitnodes.io/ , https://explorer.acinq.co/ .

Lo primero que nos llamará la atención cuando veamos lo fondos disponibles en el canal, es que son menores que los depositados; el motivo es que hay una pequeña cantidad («commitment fee») que se bloquea para poder asumir las «fees» onchain en caso de cierre. La cantidad va variando en función del estado de la «mempool» (la «memory pool» donde se almacenan las transacciones pendientes de registrar en la blockchain de Bitcoin), oscilando entre una y varias decenas de miles de satoshis.

Ahora ya podemos comenzar a enviar y recibir satoshis; para el envío hemos de disponer de “outbound capacity” (que marcará además el límite de envío), y para recibir satoshis de “inbound capacity” (que será por lo tanto lo máximo que se pueda recibir) … ya empezamos a ver que la “inbound capacity” es un bien preciado, quédate con ello porque más adelante ampliaremos este concepto.

También podemos empezar a ver que la capacidad del canal (los satoshis bloqueados en él) es un parámetro importante y limitará el volumen de los pagos o cobros que se pueden realizar. Hay una buena noticia aquí, “Atomic Multipath Payments” (implementado recientemente en LND) permite realizar un pago repartiendo la cantidad entre varios canales de salida en caso de ser necesario; es decir, la “outbound capacity” de todos los canales se suma y actúa como una sola. Lo mismo aplica para la “inbound capacity”.

Otra novedad de este verano, relacionada con la capacidad de los canales, es la posibilidad de abrir “Wumbo Channels” (de Lightning Labs para LND), con la que se eliminó la limitación existente de 0,16777215 BTC por canal. Actualmente los canales (públicos) de mayor capacidad son de 5 BTC y están abiertos desde Bitfinex (exchange) a Loop (servicio «Submarine Swaps» de Lightning Labs), Bitrefill (tarjetas de prepago) y OpenNode (pasarela de pagos).

Para enviar satoshis a otro nodo de la red, no es necesario tener abierto un canal directo entre ambos, el pago puede enrutarse a través de otros canales por los que estén conectados, apoyándose en los nodos intermedios que se encuentran en el camino; el proceso se realiza a través de HTLC (Hash Time Lock Contracts), y de forma conceptual y muy sencilla, en la ida del pago se bloquean fondos en cada nodo, que se desbloquean en sentido inverso una vez el pago llega al nodo destinatario y se desvela un secreto. Estos nodos intermedios se llaman enrutadores y se quedan con una pequeña “fee” (comisión) por el servicio.

Acabamos de presentar por lo tanto la función de enrutado que todo nodo puede desarrollar en cualquier momento, cuando un nodo enruta un pago:

• en el canal por el que llega el pago: una parte de los fondos pasan de ser “inbound” a ser “outbound” (se atraen fondos hacia nuestro nodo por el canal de llegada).
• en el canal por el que sale el pago: esa misma cantidad (menos una pequeña comisión, “fee”) de fondos pasan de ser “outbound” a ser “inbound” (nuestro nodo empuja fondos hacia otro nodo por el canal de salida).

Es decir, si nos olvidamos de las “fees”, el nodo ni gana ni pierde fondos, simplemente redistribuye parte de la “outbound capacity” y “inbound capacity” en dos canales, pero las cantidades totales no varían.

La “fee” se carga en el canal por el que sale el pago, es decir, si se enruta un pago de 1000 satoshis, en el canal de entrada pasarán 1000 satoshis de “inbound” a “outbound” y en el canal de salida pasarán 998 satoshis de “outbound” a “inbound”; suponiendo que la “fee” ha sido de 2 satoshis.

La “fee” (comisión) de enrutado tiene dos componentes:

• «Base Fee»: es una cantidad fija por enrutado y suele fijarse en 1 satoshi.  
• «Fee Rate»: es un porcentaje de la cantidad que se enruta, se expresa en satoshis por cada millón de satoshis enrutados y sus valores varían según la estrategia del nodo (valores habituales están entre 1 y 100); hay que tener en cuenta que un valor elevado penalizará enrutados respecto a canales de otros nodos por los que sea más barato enrutar pagos.

Cuando un nodo enruta un pago, es conocedor de los nodos de llegada y de salida, pero no si estos son el origen o destino del pago, esto es relevante y mantiene la privacidad de los usuarios en Lightning Network.

El movimiento de fondos en un canal se puede producir de forma indefinida, es decir, los fondos pueden ir y venir tantas veces como sea necesario, se pueden producir enrutados en ambos sentidos continuamente, generado las correspondientes “fees” en estos movimientos y sin que esto implique ningún tipo de mantenimiento necesario por nuestra parte.

Cuando una canal se cierra y llega al final de su vida, el estado de los balances se publica “onchain”, depositándose en la wallet de nuestro nodo la cantidad que tengamos como “outbound capacity” y en el otro nodo del canal lo que hubiera como “inbound”. El cierre de los canales puede realizarse por dos procedimientos:

• Colaborativo entre los nodos: en ese caso se pueden ajustar las “fees onchain” con las que se incluirá la transacción en la “mempool”, lo que permite ajustar el importe final del cierre y reducirlo si no tenemos urgencia.
• Cierre forzado: puede producirse por un posible error o inestabilidad del protocolo, porque una de las partes así lo demande o también al reconstruir un nodo a partir del “channel.backup”. La transacción va a ser priorizada para entrar en la cadena de bloques, así que en función del estado de la “mempool” esto puede ser un buen susto.

Es importante entender como funcionan las “fees” en el enrutado de pagos, pero no perdamos de vista que cuando se realiza un pago entre dos nodos conectados por un canal, directamente de uno a otro y dentro de los límites operativos del canal, la comisión es de 0 satoshis.

Enrutado en Lightning Network

Ofreciendo servicios de enrutado en la Lightning Network

La economía Lightning es un ecosistema aún pequeño al que poco a poco se van sumando servicios, dentro de este ecosistema el nodo de enrutado identifica dos actores relevantes:

Usuarios que consumen servicios en Lightning y necesitan enviar satoshis, para los que no es eficiente ni económico abrir un canal con cada comerciante o “peer” con el que quieran transaccionar, en este caso el nodo de enrutado se sitúa como nodo de salida contra el que abrir un canal de gran capacidad que ir utilizando para los diferentes servicios.

Es importante que el nodo de enrutado sea receptivo con estos usuarios y coloque canales de salida con “outbound capacity” apuntando hacia servicios que los usuarios vayan a necesitar, disminuyendo así las “fees” que estos van a pagar al ser los enrutados más directos.

Comerciantes que ofrecen servicios y necesitan recibir satoshis, que demandan por lo tanto canales abiertos con fondos apuntando hacia ellos (fondos en “inbound” visto desde su lado del canal), para recibirlos como pagos por los servicios que ofrezcan, empujando así los satoshis hacia su lado del canal, y pasando a ser propietarios de ellos.

La «inbound capacity» es un bien muy demandado , y ya no solo por comerciantes, sino también por usuarios que quieren recibir pagos en Lightning; veamos que hay un coste asociado que asume el proveedor de esta liquidez.

Hay que tener en cuenta que tanto las “fees on-chain” de apertura del canal, como las de cierre, corren a cargo del nodo que abre el canal, y no digamos nada si, como sucede con algunos nodos que solicitan «inbound capacity», una vez que todos los satoshis han pasado a su lado del canal deciden cerrarlo y pasarlos a “on-chain” … hagamos cuentas…o hemos aplicado una comisión altísima o vamos a perder bastantes satoshis en la jugada. No es muy habitual, pero este riesgo y los costes que indicábamos antes se han de tener en cuenta a la hora de abrir un canal aportando liquidez a otro nodo.

Consiguiendo «inbound capacity»

La “inbound capacity” es la madre del cordero.

En los dos casos anteriores hemos visto la necesidad de disponer de “inbound capacity”:

• Los usuarios, por regla general, comienza sin “inbound” y no pueden recibir pagos, hasta que, por ejemplo, algún amigo abre un canal hacia ellos. 
• Los comerciantes demandan “inbound” desde el comienzo de su actividad, para poder recibir pagos.

Lógicamente se han comenzado a crear mercados en los que se ofrece “inbound capacity”, y en los que más allá de la necesidad puramente comercial es interesante ver cuál es el precio del dinero, que tipo de interés se paga por disponer de liquidez. Recientemente, “Lightning Labs” ha lanzado “Pool” para LND, un mercado de subasta donde se realiza el “leasing” de canales con fondos apuntando hacia el nodo que lo solicite.

También los usuarios se han organizado en torno a grupos de Telegram, como “Lightning Liquidity & Pool” (con algo más de 200 usuarios) donde se abren canales balanceados, con fondos en ambos extremos, pudiendo disponer así de “inbound capacity” desde el inicio y repartiendo las “fees” de apertura del canal. El proceso es el siguiente, una parte envía fondos “onchain” y la otra abre un canal, colocando tanto sus fondos como los recibidos repartidos a partes iguales en los extremos del canal.  Una vez finalizado el proceso se puede valorar el desempeño del otro usuario, y aumentar su reputación. 

No es perfecto y es necesaria confianza entre las partes, por lo que el “don´t trust…” no aplicaría; por lo que vemos claramente que este servicio es un nicho donde surgirán aplicaciones, que como comentaremos más adelante ya están empezando a proponerse. Por otro lado, el grupo mantiene un ambiente bastante “developer” con varias leyendas de la escena Lightning y con usuarios desarrollando aplicaciones en Telegram para por ejemplo asociar nodos a perfiles y realizar mapas de la red Lightning (Lightning Name Server), o para crear mercados de subasta de liquidez, similar al Pool de Lightning Labs (Lightning Liquidity); Philip Sheppard e Infinite Jestopher (satbase.org) son los perfectos maestros de ceremonias y se encargan de que la fiesta no decaiga.

Hay otros grupos de Telegram donde también he visto a usuarios solicitando la apertura de canales balanceados, como “Lightning Network” y “Lightning Network en Español” (gestionado por el gran Carlos Roldan de @SatoshisGames y donde están muchos de los perfiles conocidos del ecosistema Lightning en español), precaución con estas prácticas.

En los comienzos de “Lightning” había nodos, y alguna iniciativa con fines comerciales, que ofrecían “inbound capacity” de forma gratuita, abriendo canales con fondos apuntando directamente hacia nuestro nodo, van quedando muy pocos o ninguno. Algunas carteras Lightning para móvil ofrecen este servicio y te permiten recibir pagos nada más ubicar fondos en ella.

Un lugar donde conseguir “inbound capacity” es por ejemplo Bitrefill, con su servicio “Thor Lightning Channel Capacity” para la apertura de canales con fondos apuntando hacia nuestro nodo, aportándonos “inbound capacity”.  El precio de un canal con 0,01 BTC es de 30600 satoshis (3% aprox), que va bajando hasta los 267.900 satoshis por un canal de 0,165 BTC (1,62%); se garantiza la apertura durante 30 días, más tiempo si hay movimiento en el canal. Recuerda que los fondos en “inbound” no son nuestros hasta que alguien los empuja a nuestro lado del canal, aquí estamos pagando sólo por disponer de liquidez en “inbound”. El pago se puede hacer en BTC, LTC, ETH, DASH y DOGE.

Si estamos pensando en adquirir “inbound capacity”, es importante que analicemos el nodo con el que lo hagamos, además de que esté bien comunicado, y por supuesto tenga elevada disponibilidad… hay que tener en cuenta que tanto nuestros pagos, como los cobros que hagamos a otros nodos, estarán sujetos a las “fees” de enrutado de sus canales.

Otra forma de incrementar la “inbound capacity” en canales ya abiertos de nuestro nodo es realizar “Submarine Swaps”, esto es, empujar parte de los fondos desde nuestro lado del canal al otro extremo (dejando de ser nuestros) y recibiéndolos en la dirección “onchain” que indiquemos; parte de nuestros fondos pasan de estar “offchain” en un canal a estar “onchain”.

“Lightning Labs” tiene la herramienta Loop que permite realizar el proceso anterior y se llama “loop out”. También tiene habilitado “loop in” con el que fondos “onchain” pasan a “offchain”, incrementando la “outbound capacity” de uno de nuestros canales.

“Boltz Exchange” también ofrece el servicio “Submarine Swaps”, y esta misma semana ha anunciado que, además de BTC y LTC, también permiten hacerlo de forma directa desde USDT (Tether, ERC20 token) y en ambos sentidos; es decir BTC-LN –> USDT y USDT –> BTC-LN. “Mind-blowing”.

Gestionando canales

A medida que el número de canales va creciendo, es útil disponer de un listado con todos los canales abiertos y cerrados, donde ir anotando cualquier información relevante de otros nodos: quien ha abierto el canal (será el que haya pagado las “fees” de la transacción “onchain”, y tendrá que hacer lo mismo cuando se cierre el canal), que cantidad de satoshis hay bloqueados en el canal, si es privado o no (funciona y enruta como un canal normal, pero no se hace público), que tipo de nodo es (usuario normal, nodo de enrutado, exchange, comercio y que servicio ofrece …), así como cualquier evento positivo o negativo que hayamos tenido.

Es importante tener la posibilidad de contactar con los nodos de nuestros canales, ya que en caso de cualquier incidente podremos consultar y tener respuesta de que está pasando. Del mismo modo, dar una identidad y posibilidad de contacto a nuestro nodo ayudará a que otros se sientan más seguros al abrir un canal con nosotros.

Sobre la gestión de los canales y como tienen que estar repartidos los fondos para maximizar el enrutado hay diferentes enfoques y no es fácil acertar siempre, hay que tener en cuenta que todos los nodos pueden ser tanto emisores como receptores de pagos en cualquier momento y además hay bastantes nodos tratando de realizar funciones de enrutado. Para complicar la cosa, debemos saber que es posible ver las capacidades de los canales (públicos) de la red Lightning, pero no la posición de sus fondos, no podemos saber como están repartidos entre ambos extremos en cada momento; esa información sólo la tienen los dos nodos de cada canal.

Algunos consejos en este tema si se quiere configurar un nodo de enrutado serían:

• Seleccionar una mezcla de buenos nodos, algunos del top 100 y otros del top 500, para tratar de crear caminos que no existan en la red; incluyendo “exchanges”, pasarelas de pago y “wallets” comerciales; es decir, nodos que tengan movimiento.
• Abrir canales de 1.000.000 de satoshis como mínimo, si son algo mayores, mejor.
• Abrir los canales (o cerrarlos) aprovechando momentos en los que la “mempool” este vacía, para reducir costes.
• Disponer de al menos el 30% de los fondos como “inbound”, y si es algo más, mejor…pero como explicamos antes, no es sencillo y seguramente tenga un coste.
• Aplicar una “base fee” de 1 satoshi y una “fee rate” no muy alta, entre 10 y 75 satoshis.
• Sobre todo, no obsesionarse, dejar que el nodo vaya enrutando y, después de varios días o semanas, analizar como lo hace para identificar patrones de flujo.

Con suerte, la familia y el trabajo nos dejarán algo de tiempo para ir controlando cómo evolucionan los canales y viendo también si hay nodos en 1ML en los que merezca la pena colocar fondos y aportarles “inbound capacity”.

Este control puede ser diario (los primeros días que enrutes seguro que será así, la sensación de recibir satoshis recompensa muchos sacrificios), pero con tanta evolución en la Lightning Network y en Bitcoin, leer y escuchar para estar al día de todo es tanto o más importante que gestionar nuestro nodo… que además funciona sólo y que, de momento, no nos va a pagar la jubilación.

Hay aplicaciones con interfaz gráfica como “Ride The Lightning” o “ThunderHub” (de nuestro amigo @tonyioi, L#86 de LNTCN) que son de gran apoyo para la gestión de los canales y del nodo en general, nos van a ahorrar mucho tiempo y hacer la vida más fácil.

De todos modos, es recomendable habituarse a utilizar la línea de comandos y conocer a fondo todo lo que ofrece “lncli” (el cliente de LND, de Lightning Labs) porque seguro que en algún momento lo vamos a necesitar, nos da información adicional, nos permite ser autónomos y nos hace sentir más seguros frente al nodo en situaciones en las que las cosas se pueden complicar.

Otra aplicación utilizada por los gestores de nodos más avanzados es “Balance of Satoshis”, de Alex Bosworth (@alexbosworth, sobran las presentaciones), que funciona completamente desde la línea de comandos, permite la gestión completa de nuestros canales, realizar “circular rebalance” en canales ya abiertos y tiene, por ejemplo, comunicación con Telegram para avisarnos cuando se realizan enrutados. Continuamente en la brecha de lo más innovador, esta misma semana anunciaba la posibilidad de abrir “canales balanceados” comprometiendo fondos directamente desde dos nodos, y revertiendo la operación si algo no sale como debe: “I´ve noticed people making trusted dual-funded channels. Expanding on my concept for KeySend APIs I implemented channel dual-funding using LN payments to negotiate all the details, then waiting for pending channels before committing coin. Better to minimize trust. This is the way”.

Cuando en el parrafo anterior decimos “circular rebalance”, nos referimos a una práctica habitual con la cual realojamos la “outbound” e “inbound capacity” de unos canales en otros, y se realiza de una forma tan sencilla como haciéndonos un pago a nosotros mismos, indicando el canal de salida y el de llegada. “Balance of Satoshis” y “ThunderHub” incluyen esta herramienta (también «Ride The Lightning», aunque puede que no tan fluida), que tiene el coste de las “fees” de los distintos canales de la red por los que vaya pasando el pago.

Cerrar canales es una decisión que sólo hay que tomar en el caso de tener algún «zombie channel» o cuando haya un “peer” con el que tenemos gran cantidad de fondos bloqueados en nuestro lado del canal y no haya habido movimiento en varios meses, y hay que hacerlo siempre de forma colaborativa en caso de ser posible.

Reputación de nuestro nodo

Como decíamos antes, nos debemos sentir más cómodos abriendo canales con nodos con los que nos podamos poner en contacto, que dispongan de un historial conocido y un buen desempeño; “Lightning Network” está aún en su infancia, todo el mundo está aprendiendo, el ambiente de colaboración es total y esto hay que aprovecharlo mientras dure.

Es muy probable que a futuro la reputación de los nodos vaya ganando importancia, o al menos se valore para algunos servicios. Por ejemplo, “Lightning Labs” está dando opción a los “takers” (los compradores de liquidez) de Pool (la aplicación de subasta de liquidez que comentamos anteriormente) de realizar el “leasing” sólo con nodos “Tier 1” según la clasificación “Bos Score”, premiando así a nodos con buen desempeño y evitando en cierta medida a actores maliciosos en un estado tan inicial de la aplicación.  https://lightningwiki.net/bos/

Para la versión alfa de “Pool”, al algoritmo de “Bos Socre” no es aún público y “Lightning Labs” está trabajando en su mejora con la intención de incluir a tantos nodos “Tier 1” como sea posible, apoyándose en los datos obtenidos del funcionamiento de Pool durante estas primeras semanas; publicar un listado de nodos fiables no es tarea baladí y hay que asegurarse de que los que estén incluidos realmente lo sean.

Los parámetros considerados por “Bos Score” son: antigüedad del canal, tiempo en servicio, capacidad de los canales, número de canales, puntuación de los canales vecinos, proximidad a los destinos de pago y “fees” establecidas; valorando a los nodos en una escala hasta 100.000.000 y dejando fuera a los que están por debajo de 10.000.000; actualmente el listado incluye 248 nodos.

«FUNDS ARE SAFU» (backups)

En caso de que nuestro nodo deje de funcionar y no seamos capaz de ponerlo en marcha otra vez, habrá que reconstruirlo. Para ello es necesario disponer de la “seed” (24 palabras) de la cartera Lightning, de la “passphrase” en caso de existir y del archivo “channel.backup”, donde se guardan todos los canales; es importante que cuando realicemos alguna apertura o cierre de canal actualicemos la copia (o mejor, copias) de seguridad de este archivo; no es importante, ES IMPORTANTISIMO.

Esto será lo que necesitemos para volver a revivir nuestro nodo “Lightning”, pero debemos saber que cuando vuelva a la vida lo primero que hará es solicitar de forma automática el cierre forzado de todos los canales (para evitar publicar estados de balance pasados que nos pudieran penalizar) y traspasar los fondos a nuestra “wallet onchain”.

Recuerda, la “WatchTower” (Torre de Vigilancia) nos protegerá durante este tiempo para evitar que ningún nodo malicioso intente robar los fondos del canal, esto pueden hacerlo cerrando el canal y publicando un balance de los fondos incorrectos (con una mejor posición para él), a lo que nuestro nodo no podría replicar por estar “offline”.

El negocio de enrutar pagos

¿Cuántos satoshis va a generar nuestro nodo?

Poner un nodo enrutador a disposición en la Lightning Network es apoyar la economía circular en Bitcoin, y como parte de ella recibir satoshis por el servicio.

Eso sí, hay unos pasos previos que es necesario considerar y valorar económicamente.

• Coste del hardware: una Raspberry Pi 4B ronda los 60€, los accesorios (carcasa, disipadores, ventilador y alimentador) 20€ más, una microSD 10€ y un disco externo SSD más cable de conexión USB 3.0 unos 120€, en total unos 200€.
• Equipos de apoyo: SAIs y router con SIM 4G hay muchos modelos, el mayor trastorno aquí puede ser migrar el router de nuestra operadora, vamos a presupuestar 150€ para ambos.
• Vigilancia externa: la “WatchTower” la puedes obtener de algún conocido o activarla en otro nodo estable 24h que dispongas; la cámara para vacilar a tu cuñado la puedes conseguir por unos 30€.
• Si optamos por contratar la suscripción Premium en myNode, esta tiene un precio de 99$.
• Consumo eléctrico y conexión a internet: el consumo eléctrico de una Raspeberry Pi es mínimo y los costes de consumo eléctrico del router y de la conexión a Internet se supone que ya los tenemos como fijos en la red en la que instalemos el nodo.
• Apertura y cierre de canales: la apertura de un canal implica una transacción “onchain”, cuyas “fees” son asumidas por el nodo que abre el canal y que puede rondar los 1500 satoshis. Del mismo modo el cierre del canal implica otra transacción “onchain”.

Una vez asumido esto, saber cuántos satoshis se recibe por enrutar no es sencillo; no es dato público que se pueda consultar y no es habitual que los gestores de nodos compartan esta información, que además depende en gran medida de los ajustes que hagamos en los canales y que funciona a base de prueba y error, a saber: con que nodos tenemos abiertos canales, si balanceamos el saldo de los canales y con qué frecuencia, que “fees” tenemos establecidas, si el nodo funciona en la red TOR puede que tenga más latencia, que porcentajes del saldo tenemos como “outbound” y cuanto como “inbound” y en que canales, que disponibilidad tiene el nodo…es decir, no hay una fórmula mágica.

Por experiencias compartidas con otros operadores de nodos de enrutado, se puede estimar que para un nodo con 1 BTC distribuido en canales de media capacidad (entre 1.000.000 y 8.000.000 de satoshis), con un reparto outbound/inbound del 60/40, con una “base fee” de 1 sat y una “fee rate” de 50 sats, con canales abiertos a nodos con movimiento y bien comunicados y con una disponibilidad 24/7 de manera sostenida durante semanas, el orden de magnitud de satoshis a recibir puede estar entre 500 y 1500 mensualmente.

Entonces, todo esto, ¿para qué?

Efectivamente, no compensa si lo miras a corto plazo y con criterios de puro retorno de inversión, pero hay más aspectos, además del servicio de enrutado, que debemos considerar si realmente somos bitcoiners “low time preference”:

• La privacidad, rapidez y poco coste que aporta Lightning respecto a las transacciones “onchain”. Podemos conectar una app como Zeus a nuestro nodo y, además de disponer de las funciones básicas para gestion de canales, nos permitirá utilizar Lightning en cualquier lugar.
• El conocimiento adquirido en una de las madrigueras de Bitcoin que, desde su puesta en funcionamiento en 2018, no ha dejado de avanzar y tiene el apoyo general de toda la comunidad, en mayor o menor medida.
• Disponer de una infraestructura (nodo, canales, satoshis….)  preparada y lista para realizar y recibir pagos en Lightning en caso de que las “fees” se incrementen considerablemente en la “mempool”. En este escenario, la apertura y cierre de canales será además mucho más cara…aunque bueno, es posible que las mejoras futuras en Bitcoin, además de ayudar a mejorar la seguridad de Lightning, permitan reducir los costes asociados (por ejemplo, apertura de varios canales en una única transacción).
• Disponer de una infraestructura preparada y lista para enrutar si la Lightning Network comienza a crecer exponencialmente. En ese escenario habría que volver a hacer números.
• Estar preparados para experimentar con las nuevas capas que vayan surgiendo encima de la Lightning Network, permitiéndonos consumir servicios a los que sólo se pueda acceder a través de ella.

Lightning Network es un protocolo aún en su infancia, al que le falta madurar en muchos aspectos, y algunas de las mejoras que llegarán a Bitcoin ayudarán a ello.

No hay que perder de vista que la única forma de avanzar en un protocolo que custodia valor es muy lentamente, no solo por la parte del consenso sino también para asegurar que los cambios no van a romper nada de lo que funciona.

El ecosistema de grupos de trabajo y empresas es cada vez más amplio y variado (https://medium.com/@fulgur.ventures/building-an-overview-of-the-lightning-network-ecosystem-a93be2343f61).

Tomate todo esto por la parte positiva y súbete al barco, no tardarás en ponerte al día y, bien sea esta tecnología la que se adopte o sea otra, te ayudará a conocer y a entender mejor a Bitcoin y sus limitaciones, y cuales y como trata de solucionar la Lightning Network.

———————————————————————————————————————————————-

Este artículo se basa en experiencias y explica de una forma sencilla como configurar un nodo de enrutado en la Lightning Network para usuarios no avanzados.
Debe verse como un experimento y un campo de pruebas, que nos permite al mismo tiempo dar apoyo real al desarrollo de Bitcoin y de la Lightning Network.
Si en algún momento valoramos ir un paso más allá y configurar un nodo de enrutado con varios Bitcoins y con fines comerciales, la recomendación es estudiar opciones más robustas a nivel de hardware y software, así como realizar un control más continuo y amplio de su actividad.

Sobre el autor de este artículo