Disclaimer : Cet article est dédié à tous les nouveaux utilisateurs qui commencent maintenant ou veulent commencer à gérer un nœud BTC/LN

Un simple avertissement sur l’utilisation du réseau Lightning actuel

Sommaire
Introduction
Problèmes réels sur le Lightning
Recommandations pour les utilisateurs du Lightning
Demandes aux développeurs

Il s’agit de mes observations et recommandations personnelles (DarthCoin) après plus de 25 ans dans les systèmes informatiques, plus de 10 ans dans Bitcoinlandia et plus de 2 ans de fonctionnement de divers nœuds LN, consacrant beaucoup de temps à tester et utiliser diverses solutions pour les nœuds LN, aidant d’autres opérateurs de nœuds.

Mon seul objectif est d’améliorer le fonctionnement de LN pour tous les participants et de présenter certains aspects d’un point de vue très objectif.

Je m’en fous que beaucoup ne soient pas d’accord ou même me détestent pour ce que je vais dire ici. Oui, pour certains, ce ne seront pas des mots agréables. Je ne suis pas ici pour plaire à qui que ce soit, je présente des faits. Si vous cherchez des mots agréables et du « lèche-cul », vous ne les entendrez pas de moi. Je dirai toujours la vérité à ma façon, si vous n’aimez pas mes mots, c’est votre problème, pas le mien.

En 2020, après qu’Umbrel ait lancé la suite BTC/LN Umbrel Node, beaucoup de nouvelles personnes se sont jetées dessus et l’ont installé, pensant que c’était amusant, facile et qu’on pouvait même avoir un « revenu passif ». Mais ils ont ignoré un aspect important : L’ÉDUCATION à propos du Lightning Network.

En presque 1 an, nous avons vu le nombre de nœuds LN augmenter d’au moins 9 000 nœuds. C’est un nombre insensé en si peu de temps. Et principalement sur Tor.

Oui, il est agréable de voir l’intérêt grandissant pour le fonctionnement d’un nœud LN, mais de ce que j’ai vu sur les groupes Telegram et les forums, 90% n’ont aucune idée de ce qu’ils font.

Je pense que ce lancement a été une erreur, ou du moins la façon dont il a été fait. Trop d’utilisateurs sans aucune connaissance se sont lancés et ont créé le chaos. Je ne sais pas qui le promeut comme « très facile d’installer un nœud en 3 clics », mais le fonctionnement d’un nœud ne s’effectue pas en 3 clics. Il s’agit plutôt d’avoir beaucoup de connaissances sur Bitcoin et sur la façon dont LN fonctionne en coulisse. Sinon, cela revient à créer un réseau chaotique de personnes n’ayant aucune idée de ce qu’elles font. Oui, je les ai beaucoup aidés avec mes guides et en étant disponible presque 24h/7j avec des conseils. Mais ce n’est pas suffisant. Ils doivent faire de gros efforts pour lire et apprendre sur les nœuds. Sinon, c’est en vain.

Oui, certains d’entre eux ont commencé à s’éduquer lentement et sont devenus de bons opérateurs de nœuds. Mais la majorité d’entre eux ne se sont pas souciés des avertissements et continuent à faire fonctionner leurs nœuds de manière très mauvaise, sans maintenance appropriée, sans connaissances de base sur le fonctionnement du LN, certains d’entre eux ne pensent qu’à « gagner des sats ». Cette situation s’aggrave de jour en jour, car ces « mauvais nœuds » font un cauchemar pour nous tous sur le réseau.

Je vais mentionner quelques aspects de ce cauchemar :

• • Des nœuds qui se déconnectent très souvent. Cela rend les canaux très instables et inutilisables.
• • Les nœuds qui n’ont pas une connexion internet stable et en particulier de bons relais Tor.
• • Les nœuds qui sont SEULEMENT Tor et qui n’utilisent toujours pas un mode hybride (Tor + clearnet). Tor comme réseau de communication pour les nœuds est vraiment mauvais, parce qu’il est instable. Les nœuds LN doivent être en permanence en mesure de communiquer via le protocole gossip. Sinon, ils ne peuvent pas « se voir », même si le nœud Bitcoin est toujours synchronisé.
• • Des HTLC bloqués, qui finissent par provoquer des canaux fermés de force. C’est une situation très ennuyeuse et coûteuse. De nombreux opérateurs de nœuds ne pensent pas ou ne savent pas que si un HTLC passe par leur nœud et que celui-ci se déconnecte ou ne peut tout simplement pas communiquer avec le LN par le biais du protocole gossip, ce HTLC est une véritable plaie pour TOUT LE MONDE. C’est un contrat non rempli et si, au cours de la période d’expiration, le HTLC n’est pas rempli, il déclenchera une fermeture forcée des canaux en cascade pour tous les pairs connectés à ce HTLC. Cela affecte tout le monde. Voici une alerte du nœud ZFR.
• • Paramètres erronés ou chaotiques pour le delta de la CLTV, les frais, les HTLC min/max. J’ai vu des utilisateurs jouer avec ces paramètres sans avoir aucune connaissance de base de ce qu’ils modifient. Cela rend très difficile de travailler avec eux en tant que pairs. Ou pire encore, s’ils sont les pairs de vos pairs et que vous ne savez pas ce qu’ils font, cela vous affectera indirectement.
• • Rééquilibrage obsessionnel. C’est une autre histoire, que beaucoup embrassent et je ne comprends pas cette obsession de rééquilibrer tout le temps leurs canaux. À mon avis, c’est stupide et inutile. Cela peut déplacer de la liquidité au moment même où elle est nécessaire pour un HTLC en attente. C’est inutile et cela n’aide en rien, mais aggrave la situation avec un « faux » trafic qui ne représente en rien le vrai trafic de LN. Au lieu de faire ce rééquilibrage, il vaut mieux ajuster les HTLC min/max, l’abaisser à un montant normal d’une tx et l’utilisateur devrait commencer à utiliser le MPP tout le temps.
• • Désactivation des canaux. Il y a encore des « LN-tools« , des scripts qui désactivent des canaux, si un canal spécifique n’est pas « rentable » pour le routage. C’est stupide et improductif. C’est juste fermer des portes pour des routes possibles
  • Les utilisateurs n’utilisent toujours pas MPP comme option principale quand ils font des paiements sur LN. Cela fait que les canaux peuvent être drainés très rapidement et aussi ne pas utiliser de routes efficaces, les nœuds devront toujours adapter le trafic avec différentes méthodes (rééquilibrage, ajustement des frais, ajustement du HTLC maximal, ouverture de plus de canaux). MPP ne se contente pas de diviser le montant d’un paiement en plusieurs petites parties, mais cherche également la meilleure route pour chaque division. Un petit HTLC aura un taux plus rapide et meilleur pour trouver un bon chemin qu’un gros montant.
  • Le calcul de la route (Path Finding). Oui, il s’agit d’une question très importante dans LN et elle est principalement due à tous les aspects mentionnés ci-dessus.

Donc, en tant que nouvel utilisateur dans ce monde fascinant qu’est le réseau Lightning, voilà ce que vous devriez faire :

• • • Avant de commencer à faire fonctionner un nœud, demandez-vous pourquoi vous avez besoin de faire fonctionner un nœud LN complet. Comme je l’ai mentionné dans le guide sur la mise en route d’Umbrel, il y a une liste de réponses que les gens devraient considérer avant de commencer à faire fonctionner un nœud.
  •  
    • Si vous voulez juste jouer avec LN et même avoir un nœud LN privé, il n’y a PAS BESOIN d’exécuter un nœud de routage ! Vous pouvez facilement gérer votre propre nœud avec le wallet Blixt pour avoir des canaux privés, et même pas besoin d’être 100% en ligne + gestion complète de vos canaux. C’est bien plus privé, facile à gérer et pas besoin d’avoir beaucoup de fonds dans LN. Ou si vous voulez un portefeuille LN encore plus simple, utilisez SBW (Simple Bitcoin Wallet). Voir d’autres portefeuilles LN pour mobiles ici avec toutes les caractéristiques détaillées.
  •  
    • Si vous voulez utiliser un portefeuille LN sur votre ordi, vous pouvez facilement utiliser Electrum, qui fonctionne parfaitement. Blixt aura bientôt une version PC, plus avancée et plus puissante.
  •  
    • Si vous n’êtes pas très technophile et n’aimez pas lire la documentation, il vaut mieux ne pas utiliser ces nœuds PC/RPi. Vous n’aidez pas du tout le réseau en ne connaissant rien à la LN et en gardant juste un piètre nœud sur le réseau. Vous faites plus de mal que de bien.
  •  
    • Si vous voulez vraiment faire tourner un nœud de routage sur un PC, alors il vaut mieux être bien préparé : lisez beaucoup toute la documentation disponible, étudiez tous les tutoriels vidéo, préparez une bonne machine solide pour votre nœud comme je l’ai mentionné dans ce guide dédié à la maintenance des nœuds, surveillez pro-activement vos pairs et vos canaux, maintenez un bon trafic avec des frais bas et de bonnes routes. Ne gardez pas des pairs qui sont difficiles à maintenir en ligne, ils rendent les choses plus difficiles pour vos routes.

Utilisez du matériel solide ! C’est très important. Pour les nœuds avec plus de 50-100 canaux, une machine RPi devient vraiment problématique, en particulier en utilisant LND.

• • • Commencez à utiliser la méthode qui consiste à ajuster le HTLC maximum par canal, jusqu’à un certain niveau où vous voyez que le trafic de vos pairs passe bien des deux côtés. Comme je l’ai expliqué dans l’autre guide ici. Cela aidera beaucoup la recherche de chemins pour les routes et fera circuler plus rapidement les sats à travers votre nœud, en passant par les canaux corrects, où il y a suffisamment de liquidité comme indiquée.
  •  
    • Des frais élevés ne vous aideront en aucun cas, mais aggraveront la situation. Ne vous connectez jamais à des nœuds dont les frais sont élevés. ISOLEZ-LES !
  •  
    Voici quelques exemples de ces nœuds idiots avec des frais très élevés : Sweet16Joe, Magnetron et beaucoup d’autres sont comme ça. Nous sommes ici pour plumer les banksters, pas pour nous plumer les uns les autres.

Veuillez envisager de chercher un moyen d’améliorer le code du LN avec les aspects suivants. Ces demandes ne concernent pas seulement les développeurs des implémentations du LN, mais aussi les outils de gestion et les portefeuilles comme Thunderhub, RTL, Zeus, etc. Peut-être que vos objectifs sont différents, mais s’il vous plaît, écoutez au moins ce que les utilisateurs disent et demandent :

• • Ajouter dans le code une option pour ne pas fermer un canal avant une certaine hauteur de bloc, établie par les deux pairs ouvrant le canal. Nous avons aujourd’hui de nombreux marchés pour les canaux, vendant des canaux de liquidité, mais il n’y a pas de moyen simple de « verrouiller » ces canaux, pour qu’il soit presque impossible de les fermer avant un certain nombre de blocs. Cela permettrait également d’éviter la tricherie dans ces contrats de liquidité et d’établir certaines règles.

• • Changer la façon dont les HTLC déclenchent une fermeture forcée. Pourquoi punir un nœud qui était déjà en train d’acheminer un HTLC, si le prochain pair dans la route est celui qui ne remplit pas le HTLC ? Cette statégie de fermeture forcée des canaux est tout simplement idiote, insensée et coûteuse. Ou au moins donner la chance au peer de garder le canal ouvert et fonctionnel et de contester d’une autre manière les HTLCs en attente. Utiliser un système de réserves, où chaque pair déposera d’abord une réserve. Cela obligera les nœuds à réfléchir à deux fois avec qui et comment ils ouvriront les canaux.

• • Rendre le protocole gossip plus efficace et plus fiable. C’est vraiment pénible de voir que les pairs sont littéralement en ligne, vous pouvez leur envoyer un ping mais le gossip dit que le canal est hors ligne. Cela fait que beaucoup de HTLC sont en attente et même perdus parce qu’ils ne sont pas bien communiqués par le protocole gossip.

• • Ajouter une option simple pour définir le HTLC maximum pour un canal basé sur la liquidité de ce canal pour chaque côté, en annonçant littéralement le solde quand un paiement arrive au nœud. Oui, beaucoup diront que cela va « violer la vie privée », mais soyons honnêtes, nous avons déjà de nombreuses façons de trouver le solde d’un canal, pas besoin de se voiler la face. Ces nœuds de routage, qui doivent annoncer très bien la liquidité, ne sont pas des nœuds privés. Pour l’instant, j’ai découvert que le simple fait d‘ajuster manuellement le HTLC maximum d’un canal améliore considérablement le trafic, sans faire de rééquilibrage stupide ou ajuster les frais en fonction de la liquidité disponible. Je suis totalement d’accord avec la proposition de nœud ZFR ici.

• • Ajouter de meilleures options pour gérer les routes sur des canaux spécifiques, avec un ensemble de règles qui peuvent être facilement gérées par l’opérateur du nœud.
    Exemple : Je veux que tous les canaux privés soient acheminés vers des canaux publics spécifiques. Ou pour les applications LNDhub comme Bluewallet et LNbits, je voudrais avoir des canaux dédiés à utiliser. Oui, j’ai essayé de nombreuses façons de définir des frais spécifiques, min/max HTLC mais cela ne fonctionne pas bien.

• • Ajouter un meilleur support pour les nœuds uniquement sous Tor ou trouver un autre protocole pour communiquer en privé. Tor est vraiment peu fiable pour les nœuds LN. Ça crée tellement de problèmes.

• • Pourquoi avons-nous 3 implémentations LN avec 3 delta CLTV différents ? Pourquoi ne sont-elles pas toutes identiques ? Comment les utilisateurs doivent-ils régler, en fonction de quelles métriques ? J’ai vu certains nœuds jouer avec ces paramètres par défaut (CLN=34, LND=40, Eclair=144) et le routage devient fou et se termine même avec la fermeture forcée de canaux. Pourquoi ne peut-on pas avoir quelque chose de stable et de fiable ?

• • S’il vous plaît, laissez toutes ces conneries de côté pour un moment, arrêtez d’ajouter de « nouvelles fonctionnalités et ‘tokens’ inutiles » sur LN, et concentrez-vous sur l’amélioration du fonctionnement du LN. Parce que pour l’instant… il ne fonctionne pas bien. Il est loin d’être un réseau de paiement efficace. Et si nous ne réglons pas ces problèmes, nous aurons bientôt un projet qui aura échoué ou nous essaierons simplement d’appliquer un patch sur un autre.

• • Pour les développeurs d’Umbrel en particulier : s’il vous plaît, n’ajoutez pas autant d’applications bloatware (NdT : Un bloatware est un logiciel qui encombre inutilement le CPU d’un hardware) ! Les utilisateurs les installent juste par curiosité et chargent leur petits RPi d’applications inutiles. Concentrez-vous davantage sur le fait d‘avoir un nœud LN fort et ajoutez des options importantes pour gérer ce nœud LN. Toutes les applications non liées au nœud ne sont pas du tout utiles et pourraient être facilement intégrées dans une autre suite de « serveur personnel » s’ils veulent vraiment les utiliser. Ne mélangez pas ces choses ! Je sais que vos intentions sont de faire un « serveur personnel souverain » mais cela ne fonctionnera pas comme ça ! Je fais tourner moi-même un nœud Umbrel, mais juste comme un nœud LN, rien d’autre. Toutes les autres applications, je les exécute séparément sur une autre machine ou même sur mon Qnap NAS. Je n’ai pas besoin d’alourdir mon nœud avec elles. Mais beaucoup de noobs ne connaissent pas cet aspect. Mieux vaut séparer.

J’espère que cet article ouvrira de nombreux yeux et fera prendre conscience aux gens que nous avons encore du travail à faire pour améliorer le LN. Nous avons encore le temps de le réparer et nous pouvons commencer par des choses simples : l’éducation des nouveaux utilisateurs et la correction/amélioration du code du LN.

Vous pouvez rouvrir un canal mais les sats perdus par la fermeture forcée et la réouverture ont été jetés en vain… Et quand vous commencez à avoir 4-5 fermetures forcées par semaine, vous vous rendez compte qu’il est si fiable que ça de faire tourner un nœud de routage.

J’ai moi-même 2 nœuds LN en fonctionnement et j’envisage de fermer totalement l’un d’entre eux. Peut-être même les deux (CLN et LND) et je me contenterai de faire tourner un Blixt desktop et mobile, à titre privé, sans me soucier du routage et de l’aide au réseau. Je suis prêt à router gratuitement, mais payer des fermetures forcées pour des erreurs commises par d’autres… n’est pas acceptable.

Nous commençons à construire un réseau de paiement, mais d’autres, de l’autre côté, essaient de le sacager. Nous avons maintenant des places de marché de liquidité, nous achetons des canaux, mais si ces « contrats » ne sont pas respectés et établis avec certaines règles, personne n’en aura rien à foutre et fermera simplement vos canaux. La réputation ne vous rendra pas les sats que vous avez perdus à cause de cette fermeture forcée et le réseau que vous avez commencé à construire est maintenant perdu.

Voici un exemple, un vendeur qui a vendu un canal et qui veut ensuite le fermer. Oui, l’homologue peut être hors ligne ou en ligne. Mais vous avez un contrat quand vous avez vendu ce canal. Et cela va créer un précédent. Les gens vont vous vendre des canaux et puis les fermer. Tout votre travail est parti.

Oui, ce vendeur a raison, il se demande pourquoi le pair est hors ligne. Mais le contrat est un contrat. Il doit être respecté. Il peut aussi y avoir les putains de gossips, qui sont parfois vraiment fous, montrant certains pairs hors ligne, mais en fait ils ne le sont pas.

J’ai moi-même été dans une situation où, quelques jours de suite, 3-4-5 pairs sont apparus hors ligne (sur 55 pairs au total). L’un d’eux était même mon autre nœud CLN, que je regardais en même temps et qui était OK, en ligne et fonctionnel. LND a donc décidé de fermer la connexion avec ces pairs, sans raison.

J’ai essayé de me reconnecter aux pairs, certains ont fonctionné, d’autres non. J’ai contacté mes pairs, ils m’ont dit qu’ils étaient en ligne et en bonne santé. Mon CLN également.

Pourquoi cela se produit-il ? Personne ne le sait ou n’essaie de le résoudre. Et c’est à partir de ce problème que commencent les autres problèmes avec les HTLC en attente, puis les fermetures forcées.

Je soulève un AVERTISSEMENT ici, maintenant, et peut-être que dans quelques années les gens se souviendront de mes paroles.

Si ce problème dans le réseau Lightning, avec la fermeture forcée de canaux, n’est pas résolu d’une manière ou d’une autre, ou si l’on n’ajoute pas de nouvelles règles spécifiques dans le code, nous verrons une énorme centralisation dans une poignée de grands nœuds qui géreront la liquidité, avec des frais énormes.

Ou peut-être que dans quelques années, nous verrons apparaître un nouveau LN, le Plebs LN, en parallèle, où un autre système de paiement verra le jour, mais qui pourra être « rattaché » au « LN centralisé » qui se forme aujourd’hui.

Au moment de la rédaction de cet article, LND a également lancé la v.0.15 et le CLN v0.11.1, corrigeant certains problèmes, mais provoquant dans le même temps des fermetures forcées massives pour de nombreux nœuds. Comme vous pouvez le voir ici dans ce graphique provenant d’ici :

Beaucoup des nœuds qui ont « disparu » du graphe, sont :

• des noeuds qui déménagent vers des noeuds « privés » (non annoncés, non publics), qui ne routent plus, ou qui routent en privé.

• des noobs qui se rendent compte que le modèle de « nœud RPi avec Umbrel » n’apporte pas de « revenu passif » et ils abandonnent tout simplement

• des opérateurs qui ferment simplement les nœuds car trop de fermetures forcées de canaux

Que ₿ITCOIN SOIT AVEC TOI !

Tips asi0 !

LNURL1DP68GURN8GHJ7MRWW3UXYMM59E3K7MF09EMK2MRV944KUMMHDCHKCMN4WFK8QTMPWD5NQHMXD3SK6MT9W4ESX0GU7S

Nos derniers articles