English | Español | Deustch | Français | Italiano | Hrvatski | Hindi

Oorspronkelijk gepost op Substack op 23 mei 2022, hier bijgewerkt op 20 december 2024.

Een waarschuwing voor alle openbare node-operators over het daadwerkelijke gebruik van Lightning Network. Dit artikel is bedoeld voor alle nieuwe gebruikers die nu beginnen of nu een BTC LN-knooppunt willen runnen.

INLEIDING

Dit zijn mijn persoonlijke observaties en aanbevelingen na 25+ jaar in IT-systemen, 10+ jaar in Bitcoinlandia en 2+ jaar verschillende LN-knooppunten te hebben gerund, veel tijd te hebben besteed aan het testen en gebruiken van verschillende oplossingen voor LN-knooppunten, en andere knooppuntbeheerders te hebben geholpen.

Mijn enige doel is om LN beter te laten werken voor alle deelnemers en om sommige aspecten vanuit een zeer objectief oogpunt te presenteren.

Het kan me niet schelen of velen het er niet mee eens zijn of me zelfs haten om wat ik hier zeg. Ja, voor sommigen zullen dat geen prettige woorden zijn. Ik ben hier niet om iemand te plezieren, ik presenteer feiten. Als je op zoek bent naar mooie woorden en "kus kont", dan zul je het niet van mij horen. Ik zal altijd de waarheid spreken op mijn eigen manier, als je mijn woorden niet leuk vindt, is dat jouw probleem, niet het mijne.

In 2020, nadat Umbrel de BTC/LN-suite Umbrel Node lanceerde, sprongen veel nieuwe mensen erin en installeerden het, denkend dat het leuk, gemakkelijk en zelfs een "passief inkomen" was. Maar ze negeerden één belangrijk aspect: EDUCATIE over Lightning Network.

In bijna 1 jaar tijd hebben we het aantal LN-knooppunten zien toenemen met minstens 9000 knooppunten. Dat is een krankzinnig aantal in zo'n korte tijd. En vooral op Tor.

Ja, het is leuk om te zien dat er interesse is in het runnen van een LN-knooppunt, maar van wat ik zag op Telegram-groepen en forums, heeft 90% geen idee wat ze doen.

Ik denk dat deze lancering een vergissing was, of in ieder geval de manier waarop het is gedaan. Te veel gebruikers met totaal 0 kennis sprongen erin en creëerden chaos. Ik weet niet wie het promoot als "heel makkelijk om een ​​node te installeren in 3 klikken", maar het runnen van een node gaat niet over dat je het met slechts 3 klikken kunt installeren. Het gaat meer over het hebben van veel kennis over Bitcoin en hoe LN op de achtergrond werkt. Anders is het gewoon het creëren van een chaotisch netwerk van mensen die geen idee hebben wat ze doen. Ja, ik heb ze veel geholpen met mijn gidsen en ben bijna 24/7 beschikbaar met advies. Maar dat is niet genoeg. Ze moeten grote inspanningen leveren om te lezen en te leren over nodes. Anders is alles tevergeefs.

Ja, sommigen van hen beginnen zichzelf langzaam te onderwijzen en werden goede node-operators. Maar de meerderheid gaf geen reet om de waarschuwingen en bleef hun nodes op een heel slechte manier runnen, zonder goed onderhoud, zonder basiskennis over hoe LN werkt, sommigen van hen hebben alleen nog maar de focus op "sats verdienen".

Deze situatie wordt elke dag erger, omdat deze "slechte nodes" een nachtmerrie vormen voor ONS ALLEN in het netwerk.

ECHT PROBLEMEN OP LN

Hier zal ik enkele aspecten van deze nachtmerrie noemen (misschien zijn sommige problemen al opgelost):

• Nodes die heel vaak offline gaan. Dat maakt de kanalen erg instabiel en onbruikbaar.
• Nodes die geen stabiele internetverbinding hebben en in speciale goede Tor-relays.
• Nodes die ALLEEN Tor zijn en nog steeds geen hybride modus gebruiken (Tor + clearnet). Tor als communicatienetwerk voor nodes is echt slecht, omdat het instabiel is. LN-nodes moeten altijd kunnen communiceren via het gossip-protocol. Anders kunnen ze elkaar niet "zien", zelfs niet als de Bitcoin-node nog steeds synchroniseert.
• Vastgelopen HTLC's, die uiteindelijk gedwongen gesloten kanalen veroorzaken. Dit is een erg vervelende en kostbare situatie. Veel node operators denken of weten niet dat als een HTLC via hun node gaat en hun node offline gaat of gewoon niet kan communiceren met de LN via het gossip protocol, die HTLC een echte pijn in de kont is voor IEDEREEN. Het is een onvervuld contract en als in de vervalperiode de HTLC niet wordt vervuld, dan zal het een gedwongen sluiting van kanalen in cascade activeren naar alle peers die verbonden zijn met die HTLC. Het heeft invloed op iedereen. Hier is een waarschuwing van ZFR node.
• Verkeerde of chaotische instellingen voor CLTV delta, kosten, min/max HTLC. Ik zag gebruikers spelen met deze instellingen zonder enige basiskennis van wat ze veranderen. Dat maakt het erg moeilijk om ermee te werken als peers. Of nog erger, als ze de peers van je peers zijn en je weet niet wat ze doen, zal het je indirect beïnvloeden.
• Obsessieve herverdeling. Dit is een ander verhaal, dat velen het omarmen en ik begrijp deze obsessie met het voortdurend herverdelen van hun kanalen niet. IMHO is dit idioot en nutteloos. Het kan liquiditeit verplaatsen precies wanneer dat nodig is voor een in behandeling zijnde HTLC. Het is nutteloos en helpt op geen enkele manier, maar maakt het erger met "nep"-verkeer dat op geen enkele manier het echte LN-verkeer vertegenwoordigt. In plaats van deze herverdeling, kun je beter de min/max HTLC aanpassen, deze verlagen naar een normale hoeveelheid van een tx en de gebruiker zou MPP de hele tijd moeten gebruiken.
• Kanalen uitschakelen. Er zijn nog steeds "LN-tools", scripts die kanalen uitschakelen als het specifieke kanaal "niet winstgevend" is om te routeren. Dit is idioot en onproductief. Het sluit gewoon de deuren voor mogelijke routes.
• Gebruikers gebruiken MPP nog steeds niet als hoofdoptie wanneer ze betalingen doen via LN. Dit zorgt ervoor dat kanalen heel snel leeg kunnen raken en ook niet door efficiënte routes te gebruiken, zullen nodes altijd het verkeer moeten aanpassen met verschillende methoden (herbalanceren, kosten aanpassen, max HTLC aanpassen, meer kanalen openen). MPP is niet alleen het bedrag van een betaling in veel kleine delen splitsen, maar ook zoeken naar de beste route voor elke splitsing. Kleinere HTLC zal een snellere en betere kans hebben om een ​​goed pad te vinden dan een groot bedrag.
• Pad vinden. Ja, dit is een heel belangrijk probleem in LN en is vooral te wijten aan alle hierboven genoemde aspecten.

AANBEVELINGEN VOOR NIEUWE PUBLIEKE LN NODE RUNNERS

Dus wat u als nieuwe gebruiker in deze fascinerende wereld van Lightning Network moet doen:

• Voordat je een node gaat runnen, vraag jezelf af: waarom moet je een volledige LN-node runnen? Zoals ik al zei in de gids over Aan de slag met Umbrel, staat daar een lijst met antwoorden die mensen moeten overwegen voordat ze een node gaan runnen.
• Als je gewoon met LN wilt spelen en zelfs een privé-LN-node wilt hebben, is het NIET NODIG om een ​​routing-node te runnen! U kunt eenvoudig uw mobiele Blixt Node Wallet of Zeus Node wallet met privékanalen runnen, u hoeft niet 100% online te zijn, volledig beheer van uw kanalen, meer privé, eenvoudig te beheren, u hoeft niet veel geld in LN te hebben. Bekijk hier meer LN wallets voor mobiele telefoons met alle functies gedetailleerd en een speciale gids voor PRIVATE LN nodes.
• Als u een desktop LN wallet wilt gebruiken, kunt u eenvoudig Electrum gebruiken, werkt perfect. Binnenkort zal Blixt ook een desktopversie hebben, geavanceerder en krachtiger.
• Als je niet zo technisch bent en niet graag documentatie leest, kun je beter die desktop-/RPi-nodes niet uitvoeren. Je helpt het netwerk helemaal niet door niets te weten over LN en gewoon een waardeloze node in het netwerk te houden. Je doet meer kwaad dan goed.
• Als je echt een volledige desktop-routeringsnode wilt uitvoeren, kun je beter goed voorbereid zijn: lees alle beschikbare documentatie, bestudeer alle videotutorials, bereid een goede, sterke machine voor je node voor zoals ik al zei in deze speciale handleiding voor node-onderhoud, houd proactief je peers en kanalen in de gaten, onderhoud een goed verkeer met lage kosten en goede routes. Peers die moeilijk online te houden zijn, houd ze niet vast, ze maken het moeilijker voor je routes.
• Gebruik sterke hardware! Dat is erg belangrijk. Voor nodes met meer dan 50-100 kanalen wordt een RPi-machine echt problematisch, met name bij gebruik van LND.
• Begin met het gebruiken van de methode om de maximale HTLC per kanaal aan te passen, tot een bepaald niveau waarop je ziet dat het verkeer van je peers aan beide kanten goed verloopt. Zoals ik in de andere gids hier heb uitgelegd. Dit zal het vinden van het pad voor routes enorm helpen en zal ervoor zorgen dat de sats sneller door je node stromen, via de juiste kanalen, waar voldoende liquiditeit wordt aangegeven.
• Hoge kosten helpen je op geen enkele manier, maar maken het alleen maar erger. Maak nooit verbinding met nodes met hoge kosten. ISOLEER ZE! Neem bijvoorbeeld deze idiote nodes met extreem hoge kosten: Sweet16Joe, Magnetron (Muun wallet) en nog veel meer. We zijn hier om de bankiers te neuken, niet om elkaar te neuken.

Voorbeeld van een Umbrel-gebruiker die een "node operator" wil zijn zonder enig idee wat hij doet

VERZOEKEN VOOR LIGHTNING DEVELOPERS

Overweeg een manier te vinden om de LN-code met deze aspecten te verbeteren. Deze verzoeken zijn niet alleen voor LN-implementatieontwikkelaars, maar ook voor het beheren van tools en wallets zoals Thunderhub, RTL, Zeus etc. Misschien zijn uw doelen anders, maar luister in ieder geval naar wat gebruikers zeggen en verzoeken:

• Voeg in de code een optie toe om een ​​kanaal niet te sluiten tot een bepaalde blokhoogte, vastgesteld door beide peers die het kanaal openen. We hebben tegenwoordig veel kanaalmarkten die liquiditeitskanalen verkopen, maar er is geen eenvoudige manier om die kanalen te "vergrendelen", waardoor het bijna onmogelijk is om ze te sluiten tot een bepaald bloknummer. Dit voorkomt ook vals spelen in die liquiditeitscontracten en stelt ook bepaalde regels vast.
• Verander de manier waarop HTLC een gedwongen sluiting triggert. Waarom een ​​knooppunt straffen dat de HTLC al routeerde, als de volgende peer in de route degene is die de HTLC niet vervult? Deze gedwongen gesloten kanalen zijn letterlijk IDIOOT, slaan nergens op en zijn kostbaar. Of geef de peer tenminste de kans om het kanaal open en functioneel te houden en op een andere manier de in behandeling zijnde HTLC's te betwisten. Gebruik een reservesysteem, waarbij elke peer als eerste een reserve stort. Dat zorgt ervoor dat nodes twee keer nadenken over wie en hoe ze kanalen openen.
• Maak het gossipprotocol efficiënter en betrouwbaarder. Het is echt pijnlijk om te zien dat peers letterlijk online zijn, je zou ze kunnen pingen, maar de gossip zegt dat het kanaal offline is. Dit zorgt ervoor dat veel HTLC in de in behandeling zijnde staat zijn en zelfs verloren gaan omdat er niet goed wordt gecommuniceerd via gossip.
• Voeg een eenvoudige optie toe om max HTLC voor een kanaal in te stellen op basis van de liquiditeit van dat kanaal voor elke kant, waarbij letterlijk het saldo wordt aangekondigd wanneer een betaling bij de node binnenkomt. Ja, velen zullen zeggen dat dit "de privacy schendt", maar laten we eerlijk zijn, we hebben al veel manieren om het saldo van een kanaal te vinden, het is niet nodig om ons achter de vinger te verschuilen. Dit zijn routing nodes, die de liquiditeit heel goed moeten aankondigen, zijn geen private nodes. Op dit moment kom ik erachter dat alleen al door handmatig de max HTLC voor een kanaal aan te passen, het verkeer enorm is verbeterd, zonder domme herverdeling of aanpassing van kosten op basis van beschikbare liquiditeit. Ik ben het helemaal eens met het ZFR node voorstel hier.
• Voeg betere opties toe om routes op specifieke kanalen te beheren, met een set regels die eenvoudig kunnen worden beheerd door de node operator. Voorbeeld: ik wil dat alle private kanalen worden gerouteerd via specifieke publieke kanalen. Of voor LNDhub apps zoals Bluewallet en LNbits, zou ik graag speciale kanalen willen hebben om te gebruiken. Ja, ik heb veel manieren geprobeerd om specifieke kosten in te stellen, min/max HTLC maar het werkt niet goed.
• Voeg betere ondersteuning toe voor Tor only nodes of vind een ander protocol om privé te communiceren. Tor is echt onbetrouwbaar voor LN-knooppunten. Het zorgt voor zoveel problemen.
• Waarom hebben we 3 LN-implementaties met 3 verschillende CLTV-delta's? Waarom zijn ze niet allemaal hetzelfde? Hoe moeten gebruikers instellen, op basis van welke statistieken? Ik zag een aantal knooppunten spelen met deze standaardinstellingen (CLN=34, LND=40, Eclair=144) en de routing wordt gek en eindigt zelfs met gedwongen gesloten kanalen. Waarom kan het niet stabiel en betrouwbaar zijn?
• Laat al die onzin even rusten, stop met het toevoegen van "nieuwe nutteloze functies en tokens" bovenop LN en concentreer je op het beter laten werken van LN. Want op dit moment... werkt het niet goed. Het is verre van een efficiënt betalingsnetwerk. En als we deze problemen niet aanpakken, hebben we binnenkort een mislukt project of proberen we gewoon patch over patch.
• Voor ontwikkelaars van Umbrel in het bijzonder: voeg alsjeblieft niet zoveel bloatware-apps toe! Gebruikers installeren ze gewoon uit nieuwsgierigheid en laden die kleine RPis vol met nutteloze apps. Concentreer je meer op het hebben van een sterke LN-node en voeg belangrijke opties toe voor het beheren van die LN-node. Alle niet-node-gerelateerde apps zijn helemaal niet nuttig en kunnen gemakkelijk worden verpakt in een andere "personal server"-suite als ze ze echt willen gebruiken. Meng deze dingen niet! Ik weet dat je van plan bent om een ​​"soevereine personal server" te maken, maar zo gaat het niet werken! Ik run zelf een Umbrel-node, maar alleen als een LN-node, niets anders. Alle andere apps run ik apart op een andere machine of zelfs op mijn Qnap NAS. Ik hoef mijn node er niet mee op te blazen. Maar veel noobs kennen dit aspect niet. Beter apart.

CONCLUSIE

Ik hoop dat dit artikel nog veel meer ogen opent en mensen laat beseffen dat we nog werk te doen hebben om LN te verbeteren. We hebben nog tijd om het te repareren en we kunnen beginnen met simpele dingen: educatie voor nieuwe gebruikers en het repareren/verbeteren van de LN-code.

Je kunt een kanaal heropenen, maar de verloren sats door het geforceerd sluiten en heropenen waren tevergeefs...

En als je 4-5 FC / week begint te hebben, zul je het niet zo betrouwbaar vinden om een ​​routing node te draaien.

Ik heb zelf 2 draaiende LN nodes en ik overweeg om er een volledig te sluiten. Misschien beide (CLN en LND) en gewoon een Blixt of Zeus op desktop of mobiel, privé en geef geen moer om alle routing en het helpen van het netwerk.

Ik ben bereid om gratis te routeren, maar betalen voor gedwongen sluitingen voor fouten van anderen... is niet acceptabel./<

We beginnen met het bouwen van een betalingsnetwerk, maar anderen aan de andere kant proberen het te sluiten. We hebben nu liquiditeitsmarktplaatsen, we kopen kanalen, maar als deze "contracten" niet worden gerespecteerd en vastgelegd met bepaalde regels, zal niemand er een moer om geven en zullen ze gewoon je kanalen sluiten. Reputatie geeft je geen sats terug die je bent verloren door die gedwongen sluiting en het netwerk dat je bent gaan bouwen en nu verloren is.

Voorbeeld hier, een verkoper die een kanaal verkocht en vervolgens bereid was het te sluiten. Ja, de peer kan offline of online zijn. Maar je hebt een contract toen je dat kanaal verkocht. En dit zal een precedent scheppen. Mensen zullen je kanalen verkopen en ze vervolgens sluiten. Al je werk is weg.

Ja, deze verkoper heeft gelijk, hij maakt zich zorgen waarom de peer offline is. Maar het contract is een contract. Moet gerespecteerd worden.

Het zou ook de fucking roddel kunnen zijn, die soms echt gek is, die laat zien dat sommige peers offline zijn, maar in feite zijn ze dat niet.

Ik zat zelf in een situatie dat een paar dagen achter elkaar, 3-4-5 peers offline leken (van 55 peers in totaal). Een daarvan was zelfs mijn andere node CLN, die ik op hetzelfde moment bekeek en die OK, online en goed was. Dus LND besloot de verbinding met deze peers te verbreken, zonder reden.

Probeerde opnieuw verbinding te maken met peers, sommige werkten, sommige niet. Contact opgenomen met peers, ze zeiden dat ze online en goed waren. Mijn CLN inbegrepen.

Waarom gebeurt dit? Niemand weet het of probeert het op te lossen. En vanaf dit probleem beginnen de andere problemen met in behandeling zijnde HTLC's, en dan gedwongen sluitingen.

Ik waarschuw hier nu, en misschien herinneren mensen zich mijn woorden over een paar jaar.

Als dit probleem in LN, met gedwongen gesloten kanalen, niet op de een of andere manier wordt opgelost, of als er nieuwe specifieke regels in de code worden toegevoegd, zullen we een enorme centralisatie zien in een handvol grote knooppunten die de liquiditeit zullen verwerken, met enorme kosten.

Of misschien zullen we over een paar jaar een nieuw LN zien, het plebs LN, parallel, waar een ander betalingssysteem zal worden geboren, maar dat kan worden "gekoppeld" aan het "gecentraliseerde LN" dat vandaag wordt gevormd.

Tijdens het schrijven van dit artikel lanceerde LND ook v.0.15 en CLN v0.11.1, die enkele problemen oplosten, maar tegelijkertijd enorme gedwongen sluitingen veroorzaakten voor veel knooppunten.

Zoals u hier in deze grafiek kunt zien van https://bitcoinvisuals.com/ln-nodes:

Veel van die nodes zijn "verdwenen" uit de grafiek, zijn:

• nodes die naar "private" nodes verhuizen (niet aangekondigd, niet openbaar), niet meer routeren, of routeren in private.
• noobs die zich realiseren dat het model van "RPi node met Umbrel" geen "passief inkomen" oplevert en ze geven het gewoon op
• te veel gedwongen gesloten kanalen en operators die nodes gewoon sluiten

Opmerking: een vervolg op dit artikel is hier met een gids over hoe je LN op 3 niveaus kunt gebruiken