Recomendaciones para usuarios de LN
Una simple advertencia sobre el uso de Lightning Network en el estado actual
Este artículo está dedicado a todos los nuevos usuarios que comienzan ahora o quieren comenzar ahora a correr un nodo BTC/LN.
INTRODUCCIÓN
Estas son mis observaciones y recomendaciones personales después de más de 25 años en sistemas de TI, más de 10 años en Bitcoinlandia y más de 2 años corriendo varios nodos LN, dedicando mucho tiempo a probar y usando varias soluciones para nodos LN, ayudando a otros operadores de nodos. Mi único objetivo es hacer que LN funcione mejor para todos los participantes y presentar algunos aspectos desde un punto de vista muy objetivo.
No me importa si muchos no estarán de acuerdo o incluso me odiarán por lo que diré aquí. Sí, para algunos no serán palabras agradables. Estoy caliente aquí para complacer a cualquiera, estoy presentando hechos. Si buscas palabras bonitas y "besar culos", no las oirás de mí. Siempre diré la verdad a mi manera, si no te gustan mis palabras, es tu problema no el mío.
En 2020, después de que Umbrel lanzara la suite BTC/LN Umbrel Node, muchas personas nuevas se sumaron e instalaron, pensando que era divertido, fácil e incluso un "ingreso pasivo". Pero ignoraron un aspecto importante: EDUCACIÓN sobre Lightning Network.
En casi 1 año, hemos visto aumentar la cantidad de nodos LN con al menos 9000 nodos. Esa es una cantidad increíble en tan poco tiempo. Y sobre todo en Tor.
Sí, es bueno ver el interés en ejecutar un nodo LN, pero por lo que vi en los grupos y foros de Telegram, el 90 % no tiene idea de lo que está haciendo.
Creo que este lanzamiento fue un error, o al menos se hizo de mala manera. Demasiados usuarios con un conocimiento total de 0 saltaron y crearon un caos. No sé quién lo promociona como "muy fácil de instalar un nodo en 3 clics", pero ejecutar un nodo no se trata de que pueda instalarlo con solo 3 clics. Se trata más de tener mucho conocimiento sobre Bitcoin y cómo funciona LN en segundo plano. De lo contrario, solo está creando una red caótica de personas sin idea de lo que están haciendo. Sí, los ayudé mucho con mis guías y estando casi 24/7 disponible con consejos. Pero no es suficiente. Tienen que hacer grandes esfuerzos para leer y aprender sobre los nodos. De lo contrario, todo es en vano.
Sí, algunos de ellos comienzan a educarse lentamente y se convierten en buenos operadores de nodos. Pero a la mayoría, les importaron una mierda las advertencias y aún continúan ejecutando sus nodos de muy mala manera, sin el mantenimiento adecuado, sin conocimientos básicos sobre cómo funciona LN, algunos de ellos el único enfoque que tienen es "ganar sats" .
Esta situación está empeorando cada día más, porque estos "nodos defectuosos" se están convirtiendo en una pesadilla para TODOS NOSOTROS en la red.
PROBLEMAS ACTUALES EN LN
Y mencionaré algunos aspectos de esta pesadilla:
Nodos que se desconectan muy a menudo. Eso hace que los canales sean muy inestables e inutilizables.
Nodos que no tienen una conexión a Internet estable y, en especial, buenos relés Tor.
Nodos que son SOLO Tor y aún no usan un modo híbrido (Tor + clearnet). Tor como red de comunicación para nodos es realmente mala, porque es inestable. Los nodos LN deben poder comunicarse todo el tiempo a través del protocolo gossip. De lo contrario, no se pueden "ver unos a otros", incluso si el nodo de Bitcoin aún se está sincronizando.
HTLCs atascados, que al final provocan forzar canales cerrados. Esta es una situación muy molesta y costosa. Muchos operadores de nodos no piensan o no saben que si un HTLC pasa por su nodo y este se desconecta o simplemente no puede comunicarse con el LN a través del protocolo de chismes, ese HTLC es un verdadero dolor de cabeza para TODOS. Es un contrato no cumplido y si en el período de vencimiento no se cumple el HTLC, se activará un cierre forzado de canales en cascada para todos los pares conectados a ese HTLC. Afecta a todos. Aquí hay una alerta del nodo ZFR.
Configuraciones incorrectas o caóticas para CLTV delta, tarifas, HTLC mínimo/máximo. Vi a los usuarios jugando con estas configuraciones sin tener ningún conocimiento básico de lo que están cambiando. Eso hace que sea muy difícil trabajar con ellos como pares. O peor aún, si son los pares de tus pares y no sabes lo que hacen, te afectará indirectamente.
Re-balanceo de canales obsesivo. Esta es otra historia, que muchos la abrazan y no entiendo esa obsesión por rebalancear todo el tiempo sus canales. En mi humilde opinión, esto es inútil. Puede mover la liquidez exactamente cuando se necesita para un HTLC pendiente. Es inútil y no ayuda de ninguna manera, pero lo empeora con el tráfico "falso" que no representa de ninguna manera el tráfico real de LN. En lugar de hacer este rebalanceo, ajuste mejor el HTLC mínimo/máximo, bájelo a una cantidad normal de tx y el usuario debería comenzar a usar MPP todo el tiempo. El balanceo de un canal es bueno solo cuando es uno de tus primeros canales y necesitas liquidez entrante.
Deshabilitar canales. Todavía existen "herramientas LN", scripts que deshabilitan canales, si el canal específico "no es rentable" para enrutar. Esto es idiota e improductivo. Es solo cerrar puertas para posibles rutas.
Los usuarios aún no utilizan MPP (multi-part payment) como opción principal cuando realizan pagos a través de LN. Esto hace que los canales se puedan drenar muy rápidamente y, además, al no usar rutas eficientes, los nodos siempre tendrán que adaptar el tráfico con diferentes métodos (rebalanceo, ajuste de tarifas, ajuste de HTLC máximo, apertura de más canales). MPP no es solo dividir el monto de un pago en muchas partes pequeñas, sino también buscar la mejor ruta para cada división. Los HTLC más pequeños tendrán una tasa mejor y más rápida de encontrar un buen camino que una gran cantidad.
Path-finding / Búsqueda de rutas. Sí, este es un tema muy importante en LN y se debe principalmente a todos los aspectos mencionados anteriormente.
RECOMENDACIONES PARA NUEVOS USUARIOS DE LN
Entonces, como nuevo usuario en este fascinante mundo de Lightning Network, lo que debe hacer:
Antes de comenzar a ejecutar un nodo, pregúntese: ¿por qué necesita ejecutar un nodo LN completo? Como mencioné en la guía sobre Primeros pasos con Umbrel, hay una lista de respuestas que las personas deberían considerar antes de comenzar a ejecutar un nodo.
Si solo quiere jugar con LN e incluso tener un nodo LN privado, ¡NO HAY NECESIDAD de ejecutar un nodo de enrutamiento! Puede ejecutar fácilmente su Blixt Node Wallet móvil con canales privados, sin necesidad de estar 100% en línea, administración completa de sus canales, más privado, fácil de administrar, sin necesidad de tener muchos fondos en LN. O si desea una billetera LN aún más simple, use SBW (Cartera simple de Bitcoin). Vea más carteras de LN para móviles aquí con todas las características detalladas.
Si desea usar una billetera LN de escritorio, puede usar fácilmente Electrum, funciona perfectamente. Próximamente también Blixt tendrá una versión de escritorio, más avanzada y potente.
Si no es tan técnico y no le gusta leer la documentación, es mejor que no ejecute esos nodos de escritorio/RPi. No estás ayudando en nada a la red al no saber nada de LN y solo mantener un nodo de mierda en la red. Estás haciendo más daño que bien.
Si realmente desea ejecutar un nodo de enrutamiento de escritorio completo, es mejor que esté bien preparado: lea mucho toda la documentación disponible, estudie todos los tutoriales en video, tenga preparada una buena máquina fuerte para su nodo como mencioné en esta guía dedicada al mantenimiento de nodos, observe proactivamente a sus pares y canales, mantenga un buen tráfico con tarifas bajas y buenas rutas. Compañeros que son difíciles de mantener en línea, no los mantenga, se lo están poniendo más difícil para sus rutas.
¡Use hardware fuerte! Es muy importante. Para nodos con más de 50-100 canales, una máquina RPi se está volviendo realmente problemática, en especial usando LND.
Comience a usar el método de ajustar el HTLC máximo por canal, a un cierto nivel en el que vea que el tráfico de sus pares está mejorando en ambos lados. Como expliqué en la otra guía aquí. Esto ayudará mucho a encontrar rutas y hará que los satélites fluyan más rápido a través de su nodo, pasando por los canales correctos, donde hay suficiente liquidez indicada.
Las tarifas altas no lo ayudarán de ninguna manera, pero empeorarán las cosas. Nunca te conectes a nodos con tarifas altas. ¡AISLALOS! Solo tome ejemplos de estos nodos idiotas con tarifas ultra altas: Sweet16Joe, Magnetron y muchos más como ese. Estamos aquí para joder a los banqueros, no para joder unos a otros.
SOLICITUDES PARA LOS DESARROLLADORES DE LIGHTNING
Considere encontrar una manera de mejorar el código LN con estos aspectos. Estas solicitudes no son solo para desarrolladores de implementación de LN, sino también para administrar herramientas y billeteras como Thunderhub, RTL, Zeus, etc. Tal vez sus objetivos sean diferentes, pero al menos escuche lo que los usuarios dicen y solicitan:
Agregue en el código una opción para no cerrar un canal hasta que una cierta altura del bloque, establecida por ambos pares, abriendo el canal. Hoy tenemos muchos mercados de canales, que venden canales de liquidez, pero no hay una manera simple de "bloquear" esos canales, para ser casi imposibles de cerrarlos hasta un cierto número de bloque. Esto también evitará hacer trampa en esos contratos de liquidez y también establecer ciertas reglas.
Cambie la forma en que HTLC está activando un cierre con fuerza. ¿Por qué castigar un nodo que ya estaba enrutando el HTLC, si el siguiente par en la ruta es el que no cumple con el HTLC? Estos canalescerrados con fuerza son literalmente idiotas, no tienen ningún sentido y son costosos. O al menos dar la oportunidad al par de mantener el canal abierto y funcional y disputar de otra manera los HTLC pendientes. Use un sistema de reservas, donde cada par depositará una reserva primero. Eso hará que los nodos piensen dos veces con quién y cómo abrirán canales.
Haga que el protocolo de chismes sea más eficiente y confiable. Esto es realmente doloroso ver que los compañeros están literalmente en línea, podrías hacer un ping, pero el chisme dice que el canal está fuera de línea. Esto hace que mucho HTLC esté en estado pendiente e incluso perdido debido a que no se comunica bien a través de los chismes.
Agregue una opción simple para establecer Max HTLC para un canal basado en la liquidez de ese canal para cada lado, anunciando literalmente el saldo cuando llega un pago al nodo. Sí, muchos dirán que esto "violará la privacidad", pero seamos honestos, ya tenemos muchas maneras de encontrar el equilibrio de un canal, sin necesidad de esconderse detrás del dedo. Estos son nodos de enrutamiento, que tienen que anunciar muy bien la liquidez, no son nodos privados. En este momento descubro que simplemente ajustando manualmente el máximo HTLC para un canal mejoró mucho el tráfico, sin hacer ningún rebalanceo estúpido o tarifas de ajuste en función de la liquidez disponible. Estoy totalmente de acuerdo con la propuesta del nodo ZFR aquí.
Agregue mejores opciones para administrar rutas en canales específicos, con un conjunto de reglas que el operador de nodo puede administrar fácilmente. Ejemplo: quiero que todos los canales privados se enruten a través de canales públicos específicos. O para aplicaciones lndhub como BlueWallet y Lnbits, me gustaría tener canales dedicados para ser utilizados. Sí, intenté muchas formas de establecer tarifas específicas, Min/Max HTLC pero no funciona bien.
Agregue un mejor soporte para los nodos solo o encuentre otro protocolo para comunicarse en privado. Tor es realmente poco confiable para los nodos LN. Crea tantos problemas.
¿Por qué tenemos 3 implementaciones LN con 3 delta CLTV diferentes? ¿Por qué no son todos los mismos? ¿Cómo deben establecerse los usuarios, en función de qué métricas? Vi algunos nodos jugando con estas configuraciones predeterminadas (CLN = 34, LND = 40, Eclair = 144) y el enrutamiento se vuelve loco e incluso termina con canales de fuerza cerrados. ¿Por qué no puede ser algo estable y confiable?
Deje que toda la mierda se ponga por un tiempo, deje de agregar "nuevas características y tokens inútiles" además de LN, y concéntrese en hacer que LN funcione mejor. Porque ahora mismo ... no funciona bien. Está lejos de ser una red de pago eficiente. Y si no abordamos estos problemas, pronto tendremos un proyecto fallido o simplemente intentamos parchear.
Para los desarrolladores de Umbrel en especial: ¡no agregue tantas aplicaciones de bloatware! Los usuarios solo los están instalando solo por curiosidad y cargan esos pequeños RPI con aplicaciones inútiles. Concéntrese más por parte de tener un nodo LN fuerte y agregue opciones importantes para administrar ese nodo LN. Todas las aplicaciones no relacionadas con la noda no son útiles y podrían empaquetarse fácilmente en otro conjunto de "servidor personal" si realmente quieren usarlas. ¡No mezcle estas cosas! Sé que sus intenciones es hacer un "servidor personal soberano", ¡pero no va a funcionar así! Me ejecuto un nodo para el paraguas, pero solo como un nodo LN, no cualquier otra cosa. Todo el resto de las aplicaciones las ejecuto por separado en otra máquina o incluso en mi NAS QNAP. No necesito hinchar mi nodo con ellos. Pero muchos novatos no saben este aspecto. Mejor separado.
Espero que este artículo abra muchos más ojos y haga que la gente se dé cuenta de que todavía tenemos trabajo que hacer para mejorar la LN. Todavía tenemos tiempo para solucionarlo y podemos comenzar con cosas simples: educación para nuevos usuarios y arreglar/mejorar el código LN.
Puedes reabrir un canal, pero los SAT perdidos del cierre de la fuerza, y la reapertura fueron arrojadas en vano ...
Y cuando comience a tener 4-5 FC / semana, no lo vería tan confiable para ejecutar un nodo de enrutamiento.
Yo mismo tengo 2 nodos LN y estoy considerando cerrar totalmente uno de ellos. Tal vez ambos (CLN y LND) y solo ejecutarán un escritorio y móvil Blixt, en privado y no le importe toda la enrutamiento y ayudando a la red.
Estoy dispuesto a enrutar gratis, pero pagar los cierres de la fuerza por otros errores ... no es aceptable.
Comenzamos a construir una red de pago, pero otros del otro lado están tratando de cerrarla. Ahora tenemos mercados de liquidez, compramos canales, pero si estos "contratos" no se respetan y no se establecen con ciertas reglas, a nadie le importará una mierda y simplemente cerrarán sus canales. La reputación no le devolverá ningún sats que haya perdido por ese cierre forzado y la red que comenzó a construir y ahora se pierde.
Ejemplo aquí, un vendedor que vendió un canal y luego está dispuesto a cerrarlo. Sí, el par podría estar fuera de línea o podría estar en línea. Pero tienes un contrato cuando vendiste ese canal. Y esto creará un precedente. La gente te venderá canales y luego los cerrará. Todo tu trabajo se ha ido.
Sí, este vendedor tiene razón, le preocupa por qué el par está fuera de línea. Pero el contrato es un contrato. Debe ser respetado.
También podría ser el maldito chisme, que a veces es realmente loco, mostrando a algunos compañeros fuera de línea, pero en realidad no lo están.
Yo mismo estuve en una situación en la que algunos días seguidos, 3-4-5 pares aparecieron fuera de línea (de 55 pares en total). Uno de esos fue incluso mi otro nodo CLN, que lo estaba viendo al mismo tiempo y estaba bien, en línea y bien. Así que LND decidió cerrar la conexión con estos pares, sin motivo alguno.
Intenté volver a conectarme con compañeros, algunos funcionaron, otros no. Contacte los pares, dijeron que están en línea y bien. Mi CLN incluido.
¿Por qué está pasando esto? Nadie lo sabe ni intenta arreglarlo. Y a partir de este problema comienzan los otros problemas con HTLC pendientes, luego cierres forzados.
Estoy lanzando una ADVERTENCIA aquí, ahora, y tal vez en unos años la gente recordará mis palabras.
Si este problema en LN, con los canales cerrados a la fuerza, no se soluciona de alguna manera, o se agregan nuevas reglas específicas en el código, veremos una gran centralización en un puñado de grandes nodos que manejarán la liquidez, con tarifas enormes.
O tal vez en unos años, veremos surgir una nueva LN, la LN plebeya, en paralelo, donde nacerá otro sistema de pago, pero que puede “pegarse” a la “LN centralizada” que se está formando hoy.
Al momento de escribir este artículo, LND también lanzó v.0.15 y CLN v0.11.1, solucionando algunos problemas, pero al mismo tiempo causando cierres forzados masivos para muchos nodos.
Como se puede ver aquí en este gráfico de https://bitcoinvisuals.com/ln-nodes:
Muchos de esos nodos “desaparecidos” del gráfico, son:
nodos que se están moviendo a nodos "privados" (no anunciados, no públicos), que ya no enrutan o que enrutan en privado.
novatos que se dan cuenta de que el modelo de "nodo RPi con Umbrel" no genera "ingresos pasivos" y simplemente se dan por vencidos.
demasiados cierres forzados de canales y operadores que simplemente cerraron los nodos.
QUE EL ₿ITCOIN TE ACOMPAÑE!
Si aprecia las guias de DarthCoin, puede enviar algunos satoshis a través de Lightning Address: darthcoin@getalby.com or darthcoin@stacker.news or darthcoin.blink.sv
o con Cashu Address a darthcoin@minibits.cash
Si no desea suscribirse en Substack, todas las guías de Bitcoin de Darthcoin también se anuncian en este canal de Telegram dedicado, para una fácil búsqueda.
Para suscribirse en Substack, haga clic aquí: