Mes expérimentations avec les nœuds LN ont commencé en 2019 avec un simple nœud C-Lightning. Cela a bien fonctionné. J’ai appris beaucoup de choses à propos du Lightning Network, en particulier sur le fonctionnement d’un nœud BTC/LN et sur les différents avantages et inconvénients qu’on peut rencontrer. Mais ce n’était que le début du LN.

En 2020, j’ai découvert Umbrel. J’ai donc transformé mon nœud C-Lightning en un nouveau nœud Umbrel sur un Gigabyte Brix NUC avec un système d’exploitation Debian. J’ai fait cela juste pour continuer à en apprendre davantage, mais également pour aider la pléthore de nouveaux utilisateurs qui a commencé à installer Umbrel sans avoir la moindre idée de ce qu’est le LN, et encore moins un nœud LN.

Le meilleur moyen était donc de le tester, d’apprendre à l’utiliser, de le découvrir, puis de documenter lentement mais minutieusement toutes mes étapes dans des guides à la portée de tout le monde, afin de pouvoir partager mes connaissances avec les nouveaux utilisateurs avides de ces informations et des tutos.

J’ai donc pris mon temps pour structurer ce nœud en étudiant de très près les pairs avec qui j’allais avoir des canaux, créant ainsi ma propre liste de pairs (qui contient également la célèbre liste de nœuds ZeroBaseFee de René Pickhardt).

Je ne dis pas que mes méthodes, politiques de frais, approches sont les meilleures, ni même bonnes. J’exprime seulement mes observations et mes propres remarques sur la façon de gérer un nœud LN. Je ne suis pas un expert ou un développeur LN, ni même un “gourou” à suivre, juste une personne de la plèbe méditant sur ses expériences avec son nœud LN avec bon sens.

OK, ceci étant dit j’ai donc rejoint quelques Rings of Fire, des anneaux LN+, des groupes privés etc… Et je me suis également connecté à quelques nœuds spécifiques, tout cela avec le nœud Umbrel, et cela sur une période de 2 ans. J’ai continué jusqu’à atteindre une limite de 40 canaux, de canaux bien stables avec d’honorables pairs. Pour la plupart d’entre eux, j’ai pu avoir un contact direct — il est bon de pouvoir s’entraider / collaborer entre pair (peut-être qu’un jour je ferais un guide à ce sujet).

Ensuite, en 2022, j’ai commencé un nœud secondaire, un nœud privé, sans alias, sous Tor seulement, et non lié de quelconque manière que ce soit à mon identité réelle ou à toute autre identité en ligne. Cela fait partie d’une autre expérience qui est décrite dans ce guide.

À l’époque, comme maintenant, je ne suis pas du tout été intéressé par “faire de l’argent” avec le LN. Mon objectif est d’aider à faire du LN un réseau de paiements très liquide, afin que les utilisateurs puissent l’utiliser au quotidien et cesser d’utiliser cette putain de monnaie fiat. Il nous est impossible d’avoir un réseau de paiement sain si nous commençons à nous voler les uns les autres et à bloquer le réseau pour seulement quelques misérables sats.

Lorsque le LN sera vraiment stable, avec un bon algorithme de recherche des routes et des nœuds sains et viables, avec de nombreux utilisateurs l’utilisant au quotidien pour leurs paiements (et pas seulement pour de stupides ré-équilibrages), alors seulement à ce moment il sera peut-être question d’augmenter les frais de routage afin de construire des incitations économiques pour les nœuds de routage.

Cependant nous n’en sommes pas encore là ! Qu’importe que d’autres clament qu’ils ont gagné un montant x sats/mois. VOUS N’Y ARRIVEREZ PAS !

Et rappelez-vous : le but est de FUCK LES BANQUES, pas de se fuck mutuellement !

Si dès à présent nous facturons des frais élevés aux nouveaux utilisateurs qui souhaitent juste tester le LN, nous réussirons uniquement à leur faire peur et surtout à les faire fuire. Ils se diront que le Lightning Network n’est qu’un système de paiement merdique et cher.

Ne les effrayez pas, aidez-les à tester et à utiliser cette fantastique technologie. Nous aurons tout le loisir d’augmenter les frais plus tard afin de maintenir une incitation économique pour les nœuds de routage.

LA CUPIDITÉ À OUTRANCE EST CE QUI TUE L’INNOVATION.

Ainsi, en février 2022, j’ai lancé, avec l’un de mes pairs aguerris, un mouvement de #ZeroFeeFebruary au sein de nombreux RoF (ring of fire) et groupes. Cela s’est plutôt bien passé avec plus de 35 nœuds qui ont uni leurs forces et fixé leurs frais de tous les canaux à 0/0 (0 frais de base, 0 ppm).

Mon humble nœud Umbrel a commencé à doubler, tripler et quadrupler le nombre de paiements acheminés. J’ai également fermé quelques petits canaux zombies avec des pairs qui ne se sont pas du tout développés au cours des 6 derniers mois.

C’est un aspect très important : les pairs qui ne grandissent pas assez sur une période de plusieurs mois, sont inutiles et peuvent faire plus de dégâts que de bien.

Donc ceci est un avertissement à tous les noobs avec un nœud : si vous prévoyez de faire tourner un nœud pour le LN avec seulement 2 ou 3 canaux et de ne jamais augmenter le nombre de canaux, alors attendez-vous à ce que vos pairs ferment leurs canaux avec vous. Stackez plus de sats et ensuite vous serez en mesure d’ouvrir plus de canaux LN. Les fonds dans le LN ne sont pas “perdu” ni même “bloqué” comme certains s’amusent à vous faire croire. Non, les fonds dans les canaux LN SONT JUSTE DE LA PUTAIN DE LIQUIDITÉ. Cela signifie qu’elle DOIT CIRCULER. Sinon, c’est totalement inutile.

Puis j’ai continué par fermer les canaux avec les pairs qui imposent des frais élevés. Pour moi, des frais élevés sont :

• Frais de base > 1 sats : tout ce qui est plus élevé que cela est stupide et fait plus de dégâts que de bien.

• ppm > 150-200 msats : parfois les frais ppm sont nécessaires pour pousser la liquidité d’un côté ou de l’autre, surtout quand vous en avez vraiment besoin. Ce qui est le cas des marchands qui ne veulent pas faire de ré-équilibrage en permanence mais préfèrent laisser le trafic faire son propre équilibrage.

Ainsi, si un pair connecté à mon nœud utilise de telles politiques de frais pour tous ses canaux comme par exemple 2 sats / 300 ppm, alors je fermerai le canal, sans aucun remord. Ou bien, je fixerai des frais de base tellement élevés que tout le trafic sera bloqué sur ce canal, et j’attendrai que ce soit lui qui ferme le canal.

Aussi pour tout ceux qui utilisent intensivement le script charge-lnd : s’il vous plaît si vous êtes un noob arrêtez de l’utiliser ! Ou au moins apprenez son fonctionnement avant de l’utiliser.

Mal-employé, il fait plus de mal que de bien. Le script est conçu pour désactiver automatiquement les canaux qui sont en dessous d’un certain niveau de “rentabilité”. L’utilisateur ne sait même pas que ses canaux sont désactivés et cela signifie que cela créé des VALVES FERMÉES. Et que par conséquent plus aucun routage ne peut s’effectuer à travers ces canaux. Donc quand je vois un nœud avec beaucoup de canaux désactivés, en permanence, c’est un message clair : il utilise ce putain de script infâme, ou il est connecté à de nombreux pairs utilisant ce script. Pour moi, ce pair est un “no go”.

La liquidité circule dans les deux sens, oui c’est plus lent, mais soyez patient. Laissez le réseau Lightning se développer naturellement et la liquidité circuler organiquement. Si vous mettez des barrières sur son chemin, et bien le réseau en trouvera simplement d’autres.

J’ai essayé d’être raisonnable avec les pairs qui sont réactifs, comprennent la situation et qui ajustent leurs frais en conséquence. Lentement, l’avidité sera isolée dans les limites extérieures de la galaxie LN.

Le mois de février ressemble à ceci, pour mon humble nœud, une liquidité totale de 70 Msats équilibrée sur 40 canaux

Au total, c’est plus de 995 paiements qui ont été acheminés, pour un total de 84 millions de sats.

Le pic le plus élevé a été de 95 paiements routés et 9M de sats au total en un jour. En moyenne, durant tout le mois de février, j’ai enregistré 20 txs/jour avec environ 3M de sats routés par jour — pas mal, pour un si petit nœud. Je n’ai pas de très grands canaux, ni même de wumbo canal.

Mon nœud de test avait : 5 canaux au-dessus de 4M sats, 14 canaux entre 4M et 1M sats, 12 canaux à 1M sats et 9 canaux de 500k sats. Au total 40 canaux (plus ou moins, dépendant de l’ouverture ou la fermeture de certains).

Comparaison du mois de février avec les 6 mois précédents :

• J’ai réduit la quantité maximale de HTLC à 500k sats sur tous les canaux.

• J’ai configuré mon nœud pour fonctionner en mode hybride – Tor & clearnet. Cela aide à trouver le chemin quand Tor est bouché.

• J’ai activé le compactage de mon fichier channel.db, cela aide pour la réactivité du nœud et réduit le nombre de HTLCs en attente.

• J’ai fixé un nombre maximum de HTLCs dans le fichier lnd.conf à 10.

• J’ai maintenu, autant que possible, tous mes pairs connectés. Parfois, les communications (gossip) à travers Tor sont vraiment erratiques et signalent les pairs hors ligne même s’ils ne le sont pas. Donc, ce que j’ai fait, c’est supprimer de la liste de mes pairs ceux qui apparaissent hors ligne et de les ajouter à nouveau, si possible en utilisant son URI Clearnet. Après quelques secondes, le peer est de nouveau en ligne et le canal est prêt. Vous pouvez utiliser Thunderhub pour toutes ces étapes

En général, ce test a été un succès pour moi. Mon objectif principal était de voir la possibilité et la capacité de routage pour ce petit nœud et d’apprendre de cette situation, dans des conditions avec un volume élevé de trafic. Je ne veux pas doxer mes pairs, donc je ne posterai pas de captures d’écran avec les statistiques sur des canaux spécifiques. Mais je peux dire que pour beaucoup d’entres eux la liquidité à sacrément bouger au cours de ce mois de février 2022.

Quelques points clés que j’ai observés :

1 – Politique de frais

Les frais 0/0 attirent beaucoup de trafic, mais il est également important d’avoir des pairs avec une politique similaire ou des frais faibles.

2 – Ré-équilibrage

Les pairs avec des frais élevés ont tout simplement été mis de côté. Bien que certains ont raconté que de nombreux nœuds profitaient des frais 0/0 pour ré-équilibrer gratuitement, ce n’est pas le cas. En tout cas je n’ai pas remarqué cela avec mon nœud. Il y a eu peu de mouvements vers des pairs avec des frais plus élevés utilisant les canaux avec des frais 0/0. Je pense que la plupart des routages ont juste suivi la voie naturelle qui consiste à trouver le chemin le moins cher et le plus rapide, en ignorant les nœuds avec des frais élevés.

Beaucoup ont dit que les canaux “épuisés” (quasi-totalité de la liquidité d’un côté du canal) ne peuvent pas router et doivent être ré-équilibrés ou fermés. Ce n’est pas vrai ! J’ai eu beaucoup de canaux épuisés, mais seulement sur une courte période de temps (de l’ordre du jour). Mais après un certain temps, le flux de liquidité s’inverse et les sats se déplacent dans l’autre sens. Tout dépend si votre nœud a suffisamment de canaux, car avec suffisamment de liquidité et une liquidité suffisamment équilibrée au niveau global (pas au niveau du canal) les paiements continuent de router.

Lorsque votre liquidité totale entrante et sortante est presque égale et que vous avez au moins 10 à 30 canaux de qualité (pas morts, pas en bordure extérieure de la galaxie LN), alors votre nœud routera naturellement des deux côtés. Lorsque le rapport entrée/sortie est déséquilibré de plus de 30%, alors oui, vous commencez à avoir des problèmes car votre nœud peut se boucher.

Depuis tout ce temps, je n’ai JAMAIS ré-équilibré d’aucune façon, aucun canal. Je n’ai pas utilisé de script automatisé pour cela, pas même manuellement. Je me suis contenté de m’asseoir et de regarder.

Je voulais aussi voir si le simple fait d’ajuster légèrement le HTLC peut aider à ré-équilibrer automatiquement le canal en redirigeant le flux là où il est nécessaire et où il y a assez de liquidité.

3 – Ressources, charge mémoire

J’ai remarqué que la RAM est plus utilisée lorsque plus de HTLCs étaient en attente. Limiter le nombre total de HTLCs en attente dans le fichier lnd.conf m’a un peu aidé. Je ne suis pas sûr de la raison pour laquelle il y avait constamment au moins 3-4 HTLCs en attente pendant 5 à 15 minutes. Est-ce à cause de mon nœud ? De mon disque dur de mauvaise qualité ? De ma connexion (j’étais en mode hybride tout le temps). De mes pairs ? Et/ou des problèmes habituels avec Tor ?

Je comprends la signification des HTLCs en attente, mais pas depuis si longtemps que ça. J’aimerais pouvoir faire quelque chose à leur sujet, mais je n’ai pas assez de connaissances ou des bonnes informations sur la façon m’en prévenir. Peut-être que LN a besoin d’une amélioration dans ce domaine. Je ne sais tout simplement pas.

4 – Centralité des nœuds et croissance

Votre position au sein du réseau, appelée la centralité de votre, et ses connexions sont des aspects très importants. J’ai déjà posté une liste avec tous les outils LN disponibles. Utilisez-les, ils sont utiles pour observer et analyser vos pairs, les routes, etc … Les pairs qui sont loins, à la périphérie du réseau, ne routeront pas beaucoup de sats, contrairement à ceux qui ont des connexions avec de nombreux nœuds au centre du réseau et des RoF (Ring of Fire).

Donc si vous avez un nouveau nœud (ou même un ancien nœud) mais que vous avez de mauvaises connexions… changez-les. Et essayez de ne pas vous connecter avec des pairs qui ont déjà les mêmes connexions que vous. Les RoF sont très bons pour s’étendre. Mais attention, soyez attentif car lorsque vous vous joignez à de nombreux anneaux différents avec les mêmes pairs, cela n’aide en rien. Cela peut même être pire que mieux, car vous pouvez vous retrouver enfermé dans une boucle, et éloigner votre nœud du centre du réseau.

Déployer des connexions vers des nœuds qui ne sont pas dans la plupart des RoF, soyez le pont entre eux et les autres RoF. Analyser le comportement de vos pairs LN chaque fois que vous avez le temps, et faites également cela avec les nouveaux nœuds du réseau.

Connectez-vous avec plus de nœuds qui utilisent 0 frais de base (“0 fee base”) et une politique de frais ppm faible. Vous retrouverez ici une longue liste maintenue par René Pickhardt répertoriant de nombreux nœuds “0 fee base”.

Si vous avez un nœud avec seulement 2 ou 3 canaux, et que vous ne prévoyez pas de vous déployer davantage, vous feriez mieux de les fermer et d’utiliser un simple portefeuille mobile LN. Vous n’aidez ni vous-même, ni le réseau. Nous savons tous qu’il est difficile de stacker des sats, mais personne ne vous oblige à gérer un nœud LN de qualité avec une grosse liquidité.

De par mon expérience, j’ai pu constater que même avec des canaux relativement petits (1-5M sats) on peut obtenir un bon routage. Oui, vous pourriez avoir 2 ou 3 grands canaux de 10-20M sats, mais je considère que la centralité comme plus essentielle que de la concentration de votre liquidité en un seul endroit. Par exemple, au lieu d’un seul canal de 20M sats, je préfère avoir 4 canaux de 5M sats et ainsi plus de connexions, fournissant alors une meilleure connectivité pour mon nœud.

5 – Utilisez la liquidité de votre nœud de liquidité !

Oui, si vous avez déjà un nœud LN, utilisez-le, bordel ! Utilisez le pour vos paiements. Partout où vous trouvez un marchand qui accepte les paiements via le LN, payez-le avec votre nœud (ou en passant par votre noeud). Non pas parce que cela aidera les marchands ou le réseau, mais tout simplement pour rendre votre nœud plus visible au sein du réseau. Vous faites circuler la liquidité. C’est pourquoi ça s’appelle “liquidité” parce qu’elle est FLUIDE, elle doit couler, bouger, circuler afin de créer quelque chose de grand et de merveilleux : un réseau de paiements à la vitesse de l’éclair par dessus Bitcoin !

Rester assis sur votre nœud LN en attendant que d’autres routent leurs paiements et les facturer des frais exorbitants est TOUT SIMPLEMENT STUPIDE. Et vous vous comportez tel un profiteur.

Pour info, je tiens à jour une liste d’endroits/services géniaux où vous pouvez utiliser vos sats avec votre nœud LN.

Prochaine étape : #March1ppm

Pour le mois de mars 2021, j’ai fait le même scénario mais en passant cette fois-ci à 0/1 (0 frais de base / 1 ppm).

J’ai également défini le HTLC maximum à 500k sats pour tous les canaux avec une capacité supérieure à 1M, et à 150k sinon.

1ER RETOUR

Après une semaine avec le max HTLC fixé à 500k sats, j’ai vu trop de txs échouées. J’ai donc commencé à changer ma stratégie. Chaque matin, pendant mon café habituel, j’ai observé tous mes canaux et les txs routées la veille, et j’ai ajusté le HTLC maximum à la quantité de sats de mon côté du canal (aka la liquidité sortante). Cela signifie que si une transaction arrive jusqu’à mon nœud, elle vérifiera automatiquement que le “tuyau” est assez grand pour pouvoir passer. Quand la quantité de sats de mon côté est plus grand que 1M, je règle simplement le HTLC max à 800-900k sats, ou même plus si nécessaire. Mais j’ai remarqué que habituellement les utilisateurs commencent à utiliser de plus en plus MPP (multiple path paiement), donc je ne pense pas qu’une tx de plus de 1Msats ne sera routé en un seul morceau, elle sera toujours divisée en plusieurs petites parties.

Par exemple, pour ce canal, sur un total de 1M de sats, je n’ai de mon côté que 112 765 sats disponibles. Je vais donc fixer un maximum de 110 000 sats HTLC (pas besoin d’être exact), car je ne peux pas transmettre plus que cela. Ainsi, si un nouveau paiement acheminé jusqu’à mon nœud est plus grand que cela, alors automatiquement il ne tentera pas de calculer une route à travers ce canal spécifique.

Détails du canal avec ThunderHub

Modification du HTLC max (en sats)

Ce processus m’a pris 5 à 10 minutes chaque matin, ce qui n’est pas chronophage car je n’ai que quelques canaux, pas des centaines, et donc je n’ai pas besoin d’un script automatisé pour définir les différents HTLC max.

Après une semaine, j’ai remarqué un routage plus “naturel”, c’est-à-dire avec moins d’échecs de HTLC.

Remarquez que le nombre de tx routées par jour est plus ou moins stable

Une autre tâche que j’ai fait toutes les 4-5h chaque jour (2x par jour), est de vérifier s’il y a des canaux “offline”, en particulier ceux qui routent le plus. Parfois, le gossip échoue et les canaux sont considérés comme “hors ligne”, alors qu’il ne le sont pas vraiment.

Alors ce que j’ai fait c’est aller dans Thunderhub – Peers, puis je supprime le peer “mort” et je le rajoute tout de suite. Après quelques secondes, le canal est à nouveau “en ligne”. Si le peer n’est vraiment pas en ligne, le processus d’ajout échouera donc rien à faire de toute façon, il suffit de réessayer plus tard.

Cette tâche peut être faite avec le script BoS pour l’automatiser toutes les 5h, mais pour le moment je peux le faire manuellement (je préfère comme ça), je n’ai pas trop de déconnexions chaque jour, et j’ai de bons pairs aussi.

J’ai commencé le mois de mars avec un fichier channel.db de 1.3GB. Voyons ce qu’il en sera dans un mois.

2ND RETOUR

Le 15 mars j’ai fait un compactage de la base de données. Elle était déjà de 2.2GB, il a fallu 5h pour la ramener à 1.2GB. Après quelques heures, le nœud a commencé à router comme un fou et à atteindre jusqu’à plus de 100 txs routées, je ne sais pas comment le compactage a pu affecter cela.

Ce n’était pas une grande quantité de sats, juste 7M sats routés avec ces +100 txs. Je pense que la stratégie consistant à ajuster le HTLC maximum pour les canaux avec moins de liquidité en est plus responsable.

À partir du 15 mars, j’ai commencé une autre stratégie : pour tous les canaux de plus de 1M de sats, j’ai fixé le HTLC minimum à 99 sats. Je ne laisse le HTLC min de 1 sat que pour quelques canaux pour lesquelles j’utilise toujours la politique de frais 0/0 et pour lesquels je veux acheminer des micro-paiements . Suite à cela, la liquidité circule bien mieux.

Regardez ces quelques canaux. Je ne les ai jamais ré-équilibrés. J’ai commencé avec 2 dont la liquditié était de mon côté et 3 avec la liquidité de leur côté. Après une semaine, ils sont parfaitement équilibrés.

Je n’ai ABSOLUMENT RIEN fait ! Pas de scripts, pas de ré-équilibrage automatique, pas de frais dépensés, j’ai juste ajusté le HTLC max et fixer 0 frais de base et 1 ppm.

Certains autres nœuds commencent à ouvrir des canaux avec le mien. Je ne sais pas pourquoi, peut-être parce que certains scripts de pilotage automatique ont trouvé mon noeud comme “approprié” ou “rentable”. Mais le truc c’est qu’ils utilisent des frais élevés… donc je ferme tout simplement leurs canaux. Je ne veux pas de pairs avides. Cela affecte également mon routage. Quand j’ai des pairs avec des frais élevés, voici ce qui se passe… le nombre total des tx routées diminue. J’ai fermé ces canaux et, voyez ce qui se passe le jour suivant ? Le nombre de tx routées double.

CONCLUSION POUR MARS 2022

Le mois de mars 2022 a été plutôt bon et cela avec une politique de frais de 0/1. Il faut aussi mentionner que pour toutes les canaux de plus de 1M de sats, j’ai réglé le HTLC minimum à 9 sats et tous les autres à 1 sat.

Au total j’ai routé 1 779 txs et obtenu 113 sats en frais, avec un total de 123 218 850 sats transférés, dans les deux sens, avec 43 canaux toujours en ligne. J’avais 2-3 canaux qui étaient morts (les opérateurs m’ont informé de leurs problèmes donc je ne les ai pas fermés).

La méthode consistant à ajuster le HTLC maximum pour chaque canal en fonction de la liquidité de mon côté (aka liquidité sortante) semble assez bien fonctionner. Je remarque que cela réveillent quelques canaux “dormants” et ils se mettent à router plus de txs. Pour les canaux les plus actifs, ils ont, pour certains, eu de belle période sur laquelle une grande quantité de sats a été routée.

Tout dépend aussi des pairs et des pairs de vos pairs. Si vous avez des pairs dormants qui attendent simplement que d’autres déplacent leurs sats et qu’ils ne font aucun paiement via le LN, alors ces pairs peuvent être un fardeau et vous devriez chercher à les remplacer. Les sats sur le LN doivent circuler pour que le réseau puisse se développer.

Rapport mensuel (Mars 2020) du nombre total de transactions routées

Rapport mensuel (Mars 2020) du nombre total de sats routés

Avril-Sept 2020

Pour le 1er avril, j’ai augmenté ma politique de frais à 10 ppm. Voyons les conséquences que cela eu.

Remarque au 15 avril

Jusqu’à présent j’ai une moyenne stable de 50 txs routées/jour. Mais je souhaite mentionner que j’ai eu à redemarrer de nombreuses fois mon noeud, en raison de quelques autres expériences avec LNbits.

Aussi, j’ai fait quelques ajustements de mon fichier lnd.conf et j’ai fait quelques expériences pour étudier ce qui se passait avec la “peste” des fermetures forcées des canaux.

Voici la personnalisation de mon fichier lnd.conf.

Remarque au 19 avril

Vous pouvez ajuster votre HTLC max pour chaque canal manuellement si vous n’avez pas des centaines de canaux ou vous pouvez l’automatiser avec un script. Je préfère le faire manuellement chaque matin, en buvant mon café, cela me permet de vérifier l’état de mon nœud après une nuit bien chargée, et de n’ajuster uniquement les canaux pour lesquels je considère cela nécessaire.

Je ne vois vraiment pas la nécessité de faire en permanence un ré-équilibrage obsessionnel et inutile. Cela crée du trafic “factice” sur le LN et surtout ça vous fait dépenser des frais pour rien.

La recherche de chemin (path finding) et le routage peuvent être améliorés et plus efficaces si les paiements routés trouvent plus facilement le bon chemin, c’est-à-dire celui où les canaux ont plus de la liquidité et agissent en conséquence, comme de l’eau le long d’un réseau de canalisation. Si je “cache” cette liquidité, l’eau cessera de couler par ce tuyau et empruntera d’autres voies.

Lorsque vous utilisez des frais plus élevés ou plus bas mais que vous cachez la liquidité, la transaction arrive toujours mais se retrouve bloquée à votre nœud. Vous avez donc plus d’échecs de routage, ce qui signifie que votre nœud sera peu à peu moins “perçu” comme une bonne route.

Oui, certains “défenseurs de la vie privée” diront que révéler le solde d’un canal avec le HTLC max doxx la totalité du solde de votre nœud. C’est comme se cacher derrière un arbre en esquivant les balles : c’est inutile. Le solde de chacun de vos canaux peut être obtenu très facilement avec moulte méthodes et parfois même directement avec des explorateurs publics.

Faites circuler la liquidité et de temps à autre vous pouvez ajuster vos frais comme vous le souhaitez. Le plus important c’est que la liquidité circule en permanence !

Remarque au 22 avril

J’ai augmenté la liquidité totale de quelques vieux et petits canaux à plus de 2.5M sats. Le résultat après quelques jours est le suivant : le nombre de txs routées par jour a déjà dépassé les 200. Nous verrons si c’est juste temporaire ou si c’est une nouvelle tendance. J’ai également remarqué que de plus en plus de personnes utilisent le LN pour des paiements réguliers (pas seulement pour des ré-équilibrages inutiles).

Lors de la dernière semaine d’avril, j’ai eu un gros pic dans le nombre de paiements routés avec un maximum à 227 txs. Puis c’est redescendu à un niveau normal de 50 à 60 txs par jour.

En avril, j’ai dû redémarrer de nombreuses fois mon noeud et j’ai appliqué de nombreuses modifications, cela a affecté de manière significative la quantité de txs acheminées. J’ai aussi beaucoup modifier mes canaux (fermetures et ouvertures). Retrouver un bon flux au niveau des txs a prend du temps.

Je ne suis pas sûr que le fait que j’ai augmenté les frais ppm à 10 ait affecté le routage.

La patience est la clé.

Je viens de voir ce tweet d’Alex Bossworth et j’ai décidé de baisser les frais pour le mois de mai prochain à 1 ppm (Zero Base Fee Forever). J’ai posté ici une réponse pour Alex.

Je pense qu’il est plus important maintenant de construire un réseau de paiement stable et peu coûteux, que de commencer une “course aux frais” et de chercher à se foutre des batons dans les roues. Et honnêtement, je ne pense pas qu’Alex vive de ses frais de routage …

Remarque au 5 mai

Ce mois-ci, je vais tenter une autre “expérience”. En dehors des frais ppm sélectifs, entre 0 et 10ppm, je vais encore plus jouer avec le HTLC maximum.

Mon plan est le suivant :

• fixer HTLC max à 299k sats, quand la plupart de la liquidité est de mon côté et que le canal est plus grand que 2M sats.

• fixer le HTLC maximum à 199k sats, lorsque la plupart de la liquidité est de mon côté et que le canal est inférieur à 2M sats.

• Ajustez le HTLC max si la liquidité se rapproche de ce HTLC max, en passant à 199k puis à 19k si elle descend.

• Ajustez le HTLC maximum en 3 étapes si la liquidité revient de mon côté.

De cette façon, il n’est pas nécessaire de mettre à jour tout le temps les canaux (ce qui n’est pas recommandé) et de “tunneliser” une quantité spécifique de txs à travers des canaux spécifiques.

J’espère que les utilisateurs utiliseront de plus en plus les MPP (multi-part payments) et auront une meilleure recherche de chemin et des routes plus courtes.

Remarque au 22 Septembre

René Pickhardt vient de publier ce super article, qui a plus ou moins la même conclusion que mon expérience : 
Le pouvoir des valves pour une meilleure régulation du débit, une fiabilité améliorée et des taux de défaillance de paiements attendus plus faibles sur le réseau Lightning.

Que ₿ITCOIN SOIT AVEC TOI !

Tips asi0 !

LNURL1DP68GURN8GHJ7EM9W3SKCCNE9E3K7MF0D3H82UNVWQHKZUMFXQY33CD5

Nos derniers articles