Agradeço ao artigo escrito por Guillaume Girard e Fanis Michalakis, pois me incentivou a escrever também sobre a minha jornada pela Lightning Network.
[lwptoc]
Introdução
Desde o início de 2018, a quantidade de nodes Lightning vem aumentando exponencialmente. Com isso, uma pergunta começa a reverberar em toda a internet, principalmente na comunidade Bitcoin: Como gerenciar meus canais e como criar uma rede bem conectada?
Aqui, irei apresentar algumas ferramentas, técnicas e jeitos que você pode utilizar para gerenciar melhor o seu node da Lightning Network.
Importante dizer que aqui estarão condensados tudo o que aprendi até este momento. Boa parte das coisas foram postas em prática por mim, mas existem outras que não foram testadas, mas que estarão descritas aqui para aqueles que quiserem testar, pois acredito que possam se beneficiar desta informação, mas não se preocupe, quando houver algo que não foi testado, deixarei informado.
Acredito que não é necessário dizer, mas prefiro pecar pelo excesso: Ao fazer os testes usando a rede principal do Bitcoin (mainnet), existe a possibilidade de fundos serem perdidos, portanto, cuidado ao usar as informações contidas aqui. Saiba o que está fazendo e somente teste aquilo se tiver confiança no que está fazendo.
ATENÇÃO! Este artigo irá levar em consideração que você, leitor, tem um full node do Bitcoin com os aplicativos Ride The Lightning (RTL) e BalanceOfSatoshi (BOS) instalados, e que tenha ao menos um entendimento básico dos conceitos da Lightning Network. Se você não tem um node, saiba como obter um e porque você deveria ter um, lendo o artigo da Eduarda Lobato.
Rotear Pagamentos é Trabalhoso e Muitas Vezes Não é Lucrativo
Se estiver procurando métodos de ganhar satoshis passivamente através do roteamento, então pode dar meia volta. Não quero gastar seu ativo mais precioso (seu tempo) mostrando tudo o que aprendi durante esses meses, para no final te dizer que as chances de lucro são mínimas.
É possível que você consiga ao menos zerar seus gastos com as aberturas de canais depois de alguns meses, talvez seja possível pagar a energia utilizada pelo node, mas isso será tudo na maioria das vezes.
Além disso, é impossível escrever um guia que diz “conecte ao nodes X, Y e Z abrindo canais de S satoshis e colocando taxas em T que você irá rotear pagamentos e ganhar satoshinhos“.
É preciso entender a Lightning Network como um mercado altamente competitivo (semelhante a um mercado de peixe), onde vários usuários estão oferecendo fluxos de capitais o mais eficiente possível.
Por isso, se todos usarem a mesma estratégia, qualquer vantagem que ela venha a ter irá desaparecer, criando oportunidades para outros utilizarem técnicas diferentes. Se todos abrirem canais de tamanhos iguais, com os mesmos nodes, usando as mesmas taxas, seria uma corrida ao fundo do poço para seus usuários, e um prato cheio para aqueles que conseguirem utilizar essa estratégia para ir contra o mercado.
Além disso, você já deve ter observado que este artigo não é pequeno. Isso dá-se ao fato de que existem muitas, mas muitas variáveis a serem analisadas. Não estou brincando, estou falando de pelo menos umas 10 variáveis, tais como:
- Quanto capital irá alocar para abertura dos canais;
- Tamanho de cada canal;
- Quais nodes serão conectados;
- Taxas de roteamento (fixas e variáveis);
- Minimização de pagamento das taxas de rede;
- Capacidade de cada canal, tanto de entrada quanto de saída;
- Manutenção do roteamento (rebalanceamento e swaps entre onchain/lightning);
- Capacidade dos nodes conectados;
- Tempo de resposta, tempo online e saúde dos nodes conectados;
- Tempo de resposta, tempo online e saúde do seu node.
Depois de jogar este balde de água fria e te deixar tão desmotivado quanto possível em relação a ganhos com o roteamento, podemos enfim, adentrar ao assunto.
Estrutura do Artigo
O artigo será dividido da seguinte forma:
- Primeiro, irei mostrar como escolher os melhores canais e qual o tamanho que eles devem ter.
- Depois, vou mostrar dois jeitos de diminuir as taxas de abertura dos canais, através de aberturas em lote e também por financiamento de ambas as partes.
- Posteriormente, irei falar sobre as duas variáveis mais importantes para serem analisadas quando quisermos rotear pagamentos: O rebalanceamento dos canais e as políticas de taxas.
- Irei comentar sobre como conseguir comprar ou encontrar liquidez remota, um dos maiores problemas de quem tem um node da Lightning Network.
- Também será discutido como encontrar os nodes que não estão sendo utilizados para que os canais sejam fechados liberando saldo para que seja utilizado em outros canais.
- Depois, irei comentar sobre algumas soluções avançadas que podem ser utilizadas para resolver alguns problemas específicos de ganho de liquidez remota.
- Por fim, irei mostrar os meus últimos resultados e pensamentos depois de toda a minha pesquisa e tentativas.
Com Quem Abrir os Canais
O Alex Bosworth deixou neste arquivo, que está em inglês, uma descrição detalhada do que é a liquidez dentro da Lightning Network. Recomendo a leitura para entender melhor o contexto geral.
Abrir um canal com um node é algo muitíssimo simples de ser feito, inclusive usando a linha de comando. É mais fácil ainda encontrar pessoas que queiram que você abra canal com os nodes delas.
O problema é deixar seus satoshis “travados” no canal, sem poder enviar pra outras pessoas porque a outra parte é um node mal conectado, sem contar que, se o node da outra parte ficar muito tempo offline e você precisar fechar o canal unilateralmente, seus fundos podem ficar travados no limbo por vários dias.
Uma das coisas que percebi foi o erro absurdo de abrir canais com pessoas do seu grupinho, colegas, amigos e parentes. Isso porque você fica limitado apenas aquelas pessoas daquele determinado círculo para que seus pagamentos sejam roteados.
Atualmente não temos uma solução que consiga fazer uma análise detalhada dos status de liquidez de um node sem ter que abrir um canal com ele e fazer a verificação nós mesmos. Espero poder ver alguma ferramenta que faça essa análise, preferencialmente o mais rápido possível.
Agora vem a parte mais interessante e difícil da escolha dos nodes. Se quiser apenas utilizar a Lightning Network para enviar e receber satoshis, então basta se conectar com nodes de entrega de serviços, como ACINQ (node da carteira Phoenix) e Breez, que são soluções de carteiras não custodiais, a Bitfinex que é uma exchange e a LNMarkets que é um mercado de derivativos descentralizado.
Entretanto, se quiser rotear satoshis, isso seria totalmente o oposto que deveria fazer, porque o foco deve ser na criação de novas pontes unindo pares que antes não podiam ser roteados ou estavam muito longe uns dos outros.
O importante é não se conectar nas opções que a RTL irá te disponibilizar por padrão, e nem ir se conectando a qualquer node que te enviarem. É imprescindível saber o que está fazendo quando quiser abrir canais na Lightning, ainda mais com o objetivo de tentar auferir lucro no processo.
Além de não termos sistemas que nos ajudam a solucionar esse problema, existem alguns aplicativos no mercado que muitos acreditam ser uma boa solução porém não são, como o caso dos sistemas de pontuação do Balance of Satoshi (conhecido como BOS).
O próprio criador disse que o código não traduz nodes bem roteados em alta pontuações. Tá achando que é fácil entrar em um mercado novo que não está consolidado? Calma que ainda só estamos começando!
Atualmente, depois de muito pesquisar, me deparei com uma ferramenta razoavelmente interessante chamada Lightning Node Match.
Neste site, você informa a pubkey do seu node e ele faz uma varredura de toda a rede, informando quais são os melhores nodes para se conectar que aumentam a sua conectividade em relação a rede como um todo.
Mas abrir canais cegamente com os nodes da dita lista também não é uma boa opção, pois existem variáveis que o site não leva em consideração. Por isso, quando vou abrir um novo canal, primeiramente verifico os nodes que estão na lista.
Depois, verifico no Lightning Terminal (conhecido como LiT) se o node é estável (leia-se, a quanto tempo o node está online, sua capacidade total, se possui vários canais, etc).
E por fim, mas não menos importante, verifico quais são as políticas das taxas do node usando o site amboss. Essa última parte é importante para evitar abrir um canal com um node que tenha taxas abusivas para receber roteamento.
Existe um script chamado “improve centrality” criado pelo pessoal da Gridflare que faz parte de um pacote de ferramentas em Python que pode ser usado pelos nodes baseados no lnd, chamado de lndpytools.
Descobri essa ferramenta nas minhas últimas pesquisas, então não o testei ainda, porém, uso uma solução que vou descrever mais abaixo. Entretanto, essa ferramenta não é nada amigável e precisa da exportação do grafo completo da rede para um outro computador para que seja analisado e retorne o resultado em um formato json.
Uma coisa que necessita ser falada é que, nodes com mais de 500 canais, mas que não fazem parte dos grupos de nodes de serviços, tendem a ser instáveis, não sendo bons para rotearem pagamentos.
Acredito que isso ocorra por conta do hardware não aguentar a quantidade de processamento (normalmente, nodes de serviços são estáveis porque possuem computadores e/ou servidores dedicados, e não um raspberry pi4 executando todos os serviços). Mas, existem pessoas que dizem o exato oposto, portanto, é preciso testar e verificar qual é o seu caso.
No final, você pode verificar o quanto de conectividade pode ser conseguida, usando a ferramenta LN Node Insight. Na opção Channel Simulator, você coloca seu node e até três opções de nodes para se conectar.
Assim, pode verificar o quão melhor conectado estará com os canais abertos. Vale ressaltar que as informações sobre o ranking não são bem descritas, então ele é menos transparente que a solução da Gridflare, mas é bem mais simples de ser utilizada.
Qual o Tamanho dos Canais
Assim como muitas coisas na vida, a pergunta neste caso também é relevante. O tamanho realmente importa?
E assim como muitas coisas, a resposta é, depende. Se quiser apenas enviar e receber pagamentos, o tamanho do canal não irá importar muito, porque ele será dimensionado para a sua necessidade e, quem melhor para dizer qual é a sua necessidade do que você, não é mesmo? Apesar disso, sempre recomendo as pessoas a abrirem canais de PELO MENOS 250 mil satoshis.
Agora, se o seu objetivo é fazer roteamentos, o que recomendo é a abertura de canais grandes, de no máximo 10 milhões de satoshis. Porém, se não tiver saldo o suficiente para abrir canais tão grandes, recomendo que tenha canais de pelo menos 1 milhão de satoshis.
O motivo de limitar o tamanho a 10 milhões é devido ao fato de canais maiores não influenciarem em um melhor roteamento ou em uma diminuição da necessidade de rebalanceamento.
Vale lembrar que, como discutido anteriormente, o tamanho do canal é apenas uma das diversas variáveis que precisam ser analisadas, e é totalmente possível que seu node tenha um alto volume de roteamento usando canais menores.
Obviamente, a quantidade de rebalanceamento com canais de tamanho menor será maior, mas isso não o impedirá de ter um node para este fim. Só para se ter uma ideia, o canal que tenho com a lnmarkets é de um milhão de satoshis, e é um dos mais utilizados para enviar e receber pagamentos.
Os valores que entram e saem são entre 15 a 50 mil satoshis por vez, então um canal de um milhão de satoshis é o suficiente neste caso. A parte mais interessante é, quanto maior for a quantidade de canais abertos e quanto mais diverso for os nodes conectados, a dinâmica de pagamentos irá mudar completamente de acordo com a utilização da rede pelos usuários.
Além disso, pode-se evitar que as pessoas abram canal com baixa capacidade total alterando/adicionando alguns parâmetros no seu arquivo lnd.conf:
minchansize=1000000 /*Permite abertura de canais com tamanho igual ou maior a 1M sats*/
Alguns nodes, principalmente aqueles relacionados a serviços, limitam o tamanho mínimo do canal que pode ser aberto com eles. Isso acontece porque esses nodes não querem ter muitos canais para gerenciar ou por qualquer outro motivo arbitrário.
Um exemplo dessa limitação são os dois nodes da bitfinex, o bfx-lnd0 e o bfx-lnd1, que limitam o mínimo para 1 milhão de satoshis. Se tentar abrir um canal com um node que possui uma limitação mínima, receberá um erro informando que o tamanho do canal é pequeno demais e que é necessário abrir um com pelo menos X satoshis.
Só recapitulando. Antes de abrir um canal, é importantíssimo verificar qual é a política de roteamento do node que está querendo se conectar, porque existem aqueles que possuem uma taxa alta, quando não, possuem taxas abusivas.
Um exemplo são os próprios nodes da bitfinex que tendem a ter uma taxa de 100 ppm (0,01%), enquanto outros possuem taxas base absurdamente altas, como foi o caso da OKCoin durante a implementação da Lightning Network, onde configuraram a taxa base para 1 milhão de satoshis.
De acordo com eles, na época, o objetivo era que os canais fossem criados somente para serem utilizados como tráfego de satoshis entre os nodes conectados e a plataforma, pois neste caso, não existe taxas de envio e recebimento. Entretanto, hoje em dia, a política foi alterada, mas existem alguns nodes que ainda possuem taxas altas e abusivas, portanto, cuidado.
Métodos Para Diminuir os Custos de Abertura de Canais
Nesta seção, vou mostrar dois métodos que podem ser utilizados para economizar na abertura dos canais. Podemos diminuir os custos abrindo canais em lote ou abrindo canais com financiamento de ambas as partes.
PS: Os dois métodos informados não foram testados pelo autor deste artigo, pois o mesmo não tinha conhecimento da abertura em lote de canais no momento inicial da configuração do node e o financiamento por ambas as partes não se aplicava na época.
Abrindo Canais em Lote
Essa dica é para quem está inicializando um novo node ou está querendo abrir mais de um canal. Se já tem um node configurado com vários canais e não está pensando em abrir novos, então pode pular para a próxima etapa.
Para usar essa dica, irá precisar da linha de comando. Se estiver confiante em utilizá-la, pode continuar a ler esta seção, caso contrário, pode avançar. Essa necessidade advém de não termos soluções para este problema que são amigáveis para o usuário.
Importante! A abertura de canais em lote usando o BOS é um processo que envolve uma transação onchain. Sendo assim, existe a possibilidade de perda permanente dos fundos caso cometa algum erro. Portanto, cuidado.
Existe um artigo muito bom que mostra o passo-a-passo para isso, que está no site satbase.org.
O artigo está em inglês e é necessário pagar alguns satoshis para ter acesso, portanto, não o utilizei como base. Entretanto, existe um outro artigo menos detalhado mas que também é muito bom, escrito pelo The Count no site Null Count. O texto está em inglês, mas recomendo a sua leitura.
Para abrir canais em lote precisará usar o seguinte comando no seu node:
bos open <pubkey1> --amount <sats1> <pubkey2> --amount <sats2>
PS: Parte-se do princípio que o seu node está pelo menos com a versão v8.0.2 do BOS instalada e que o está acessando com o usuário bos.
A aplicação irá tentar fazer um contrato de abertura de canal com os nodes informados. Caso o seu node consiga acessar todos os nodes informados, o comando retornará algo semelhante a isso:
Addresses:
endereco_1, quantidade_em_btc_1
endereco_2, quantidade_em_btc_2
Essa é a informação de que necessitará para criar os canais. Abra um outro terminal e execute o seguinte comando com o usuário bos:
bos fund endereco_1 quantidade_em_sats_1 endereco_2 quantidade_em_sats_2
Importante! O comando anterior irá te informar a quantidade em BITCOIN, mas no segundo comando precisará informar os valores em SATOSHIS!
O comando acima te fornecerá o retorno da transação em HEX. Basta copiar essa informação no primeiro terminal que receberá o código da transação de abertura de canal.
Pode ser definido também a quantidade de sats por byte que queira pagar pela transação fazendo com que diminua ainda mais os custos de abertura dos canais, quando a mempool estiver vazia. Para isso, basta colocar a informação no final do comando:
bos fund endereco_1 quantidade_em_sats_1 endereco_2 quantidade_em_sats_2 --fee-rate <valor_por_byte>
Abrindo Canais Financiados Pelas Duas Partes
Essa dica é válida se tiver um amigo que deseja abrir um canal e queira ajudar a financiar parte da abertura porque irá diminuir os custos de rebalanceamento e/ou de loop out que seria necessário para manter o canal balanceado. Se não for este o seu caso, então pode pular para a próxima etapa.
Para usar essa dica, irá precisar da linha de comando. Se estiver confiante em utilizá-la, pode continuar a ler esta seção, caso contrário, pode avançar. Essa necessidade advém de não termos soluções para este problema que são amigáveis para o usuário. Iremos usar novamente o BOS nesta seção.
A versão simplificada está descrita abaixo, mas se quiser, pode assistir ao vídeo explicativo desta parte. O passo-a-passo foi retirado da wiki da plebnet, e pode ser encontrado em inglês, clicando aqui.
Godofredo e Mau querem abrir um canal já balanceado entre os dois. O processo seria o seguinte:
(Node 1: Godofredo)
(0) Executa o comando: bos open-balance-channel
(1) Insere a chave pública do node do Mau
(2) Insire a capacidade total do canal
(3) Insere quais as taxas do canal
Abre um novo terminal.
(4) Executa o comando: bos fund --fee-rate <taxa> <endereço> <qtde_em_sats>
Copia a transação_assinada. Volta para o primeiro terminal
(5) Cola a transação_assinada no terminal do bos na primeira janela
(Node 2: Mau)
(0) Executa o comando: bos open-balance-channel (aqui o Mau poderá ver a solicitação do node do Godofredo)
(1) Aceita ou não a taxa de financiamento (Y/N)
Abre uma novo terminal.
(2) Executa o comando: bos fund --fee-rate <taxa> <endereço> <qtde_em_sats>
Copia a transação_assinada. Volta para o primeiro terminal
(3) Cola a transação_assinada no terminal do bos na primeira janela
(4) Aperta Enter e observa a mágina da internet acontecer.
Pode ser verificado por ambos usando o comando: lncli pendingchannels
Fonte: Opening channels
Balanceando os Canais
Chegamos a um momento em que precisará dedicar mais carinho, amor e atenção. Depois de ter escolhido os nodes, analisado o tamanho correto e aberto os canais, está é a parte onde você irá gastar mais tempo, esforço e satoshis. É neste momento onde a porca torce o rabo e o filho chora e a mãe não vê.
Canal mal balanceado (que tem 90% dos fundos em uma das duas extremidades) é a pior coisa que pode acontecer com alguém que queira rotear pagamentos na Lightning Network. Mesmo se apenas enviar ou só receber, em algum momento poderá ter problemas com balanceamento dos canais.
No meu caso, houve vários canais que não conseguia rebalanceá-los devido a problemas de liquidez da rede. Se isso acontecer em algum momento, seja porque o canal nunca é rebalanceado ou porque nunca é utilizado para rotear pagamentos, a dica que dou é fechá-lo e alocar o capital que está bloqueado neste canal em outro lugar.
Outro ponto importantíssimo: se for uma pessoa perfeccionista, este será o momento em que provavelmente irá perder uma quantidade considerável de satoshis.
É imprescindível analisar do ponto de vista econômico se vale a pena ou não reequilibrar os canais. Não tente balancear perfeitamente os seus canais, pois isso não trará nenhum benefício direto e apenas irá fazer com que gaste satoshis desnecessariamente. Caso queira verificar os custos para balancear seu canal, pode utilizar novamente o BOS com a flag --dryrun quando for utilizar o comando balance. Assim terá uma estimativa do quanto irá gastar para fazer o balanceamento desejado.
Além disso, pode configurar o crontab para que seja executado a cada X minutos, mas cuidado. Ao fazer isso, é necessário definir uma taxa máxima para que o balanceamento seja feito. Um bom parâmetro é definir a taxa máxima como sendo 50% da taxa cobrada pelo seu node, assim é garantido que pelo menos 50% dos satoshis roteados por aquele canal serão lucro. Se quiser fazer isso, basta adicionar uma linha ao seu crontab que normalmente fica em /etc/crontab:
*/10 * * * * admin caminho/para/bos rebalance -max-fee-rate <taxa-max-div-2>
Importante! Não use o rebalance da RTL, pois além de dar estimativas fora da realidade, os custos para se fazer o balanceamento são altíssimos, além do fato deste sistema não tentar diversas vezes, como o BOS e o rebalance-lnd que iremos falar agora.
Se pesquisar sobre soluções para rebalanceamento dos seus canais, cedo ou tarde irá acabar caindo no repositório do Dr. Carsten Otto criador de uma excelente ferramenta chamada rebalance-lnd. Utilizo essa solução todos os dias para rebalancear os meus canais.
De maneira geral o rebalance-lnd é como se fosse o rebalance do BOS com esteroides, porque ele possui muito mais opções e comandos que o BOS. Apesar da ferramenta do Dr. Otto ter uma opção que analisa a viabilidade econômica na hora de fazer os balanceamentos, particularmente não o utilizo (sempre uso a opção --reckless), pois os rebalanceamentos nunca funcionam.
Gosto dessa ferramenta porque ela faz até cem tentativas de rotas diferentes para conseguir fazer o balanceamento. Além disso é possível escolher qual o canal que irá receber/enviar, o montante, a quantidade máxima de taxa a ser paga, fixa ou relativa ao que é enviado, quais nodes excluir no rebalanceamento, e muito mais. Se usar o node Umbrel precisará definir o -lnddir, mas se usar o raspiblitz ou mynode não tem necessidade.
A criação de um alias pode te ajudar a deixar tudo mais fácil para ser acessado. É possível fazer isso acessando o bashrc:
$ nano ~/.bashrc
Depois, adicionando no alias um dos comandos abaixo e o caminho até a ferramenta:
alias rebalance="/caminho/ate/rebalancelnd/./rebalance.py"
alias rebalance="python3 /caminho/ate/rebalancelnd/rebalance.py"
alias rebalance="python /caminho/ate/rebalancelnd/rebalance.py"
Além disso, depois que usar com bastante afinco o rebalance-lnd, poderá incluí-lo no crontab para executar a cada 10 minutos, usando um comando semelhante ao informado abaixo:
*/10 * * * * admin /caminho/ate/rebalancelnd/rebalance.py --to -1 --amount <qtde_sats> --fee-ppm-limit <taxa_em_ppm> --reckless
Comando que executa o balanceamento a cada 5 minutos, limitando a taxa de roteamento.
No caso utilizo o parâmetro --to -1 para usar qualquer um dos meus canais para tentar balancear. Meu node atual possui aproximadamente 15 canais, onde pelo menos metade deles precisa de rebalanceamento.
Com a ferramenta configurada no crontab, ao menos 6 tentativas são feitas por hora para deixar os canais balanceados, porém, limito a quantidade enviada para 25 mil sats, pois é uma quantidade que percebi que tem maior probabilidade de ser aceita utilizando as taxas limite que coloco.
Importante! Ao definir o rebalance-lnd no crontab, provavelmente terá uma explosão de invoices não pagos e expirados. Para não precisar carregar todas as vezes esses invoices inúteis, recomendo adicionar essas duas linhas no seu lnd.conf . Elas irão expurgar os invoices que não foram pagos e já expiraram ao iniciar o lnd e também irá expurgar aqueles que forem criados e expirarem sem serem pagos depois que o node estiver online.
gc-canceled-invoices-on-startup=true
gc-canceled-invoices-on-the-fly=true
Políticas de Taxas de Roteamento
As taxas de roteamento são outro ponto que dão uma grande dor de cabeça para quem quiser ganhar alguns satoshis com o roteamento, isso porque elas dependem do quão bem conectado está o seu node e os nodes que você abriu os canais.
Se for apenas enviar e receber satoshinhos, neste caso, colocar taxas altas de roteamento pode evitar problemas de rebalanceamento. Uma opção para isso é usar as seguintes definições padrão no lnd.conf:
base_fee_msat:1000000 # 1000 sats por transação
fee_ppm:10000 # 1,0% do valor total a ser enviado
Com essa configuração qualquer pessoa que tentar rotear usando o seu node, precisará pagar mil satoshis mais 1% do valor total. É um valor abusivo, mas que ainda pode ser utilizado em casos de alguém estar desesperadamente precisando de roteamento e queira pagar essas taxas.
No primeiro mês que comecei a fazer os roteamentos, coloquei uma política de taxas mais ou menos assim:
base_fee_msat:1000 # 1 sat por transação
fee_ppm:1000 # 0,1% do valor total a ser enviado
A ideia era verificar se mesmo com as taxas altas, haveria algum roteamento, porém, percebi que durante todo o mês, apenas poucos roteamentos aconteceram, e mesmo assim, eram valores pequenos. Isso, obviamente, era porque minhas taxas eram muito altas e também porque o meu node não estava conectado aos nodes corretos.
Hoje, consigo rotear bem usando a seguinte configuração:
base_fee_msat:0 # 0 sat por transação
fee_ppm:750 # 0,075% do valor total a ser enviado
Para canais que abro ativamente, e:
base_fee_msat:1000 # 1 sat por transação
fee_ppm:1 # 0,0001% do valor total a ser enviado
Para canais que terceiros abrem comigo.
Nos últimos dias encontrei uma ferramenta bem interessante chamada charge-lnd que basicamente altera automaticamente as taxas de roteamento dos canais de maneira dinâmica. Ainda não a utilizei porque ela entra em conflito com outra ferramenta, mas deixarei aqui caso queira testá-la com ou sem a aplicação anterior.
A ferramenta se baseia no saldo (local/outbound e remoto/inbound) que está no canal para configurar uma taxa mínima e máxima que for definida. Se o seu canal só tiver saldo local, ele configura a taxa com a mínima informada. Se o seu canal só tiver saldo remoto, ele configura a taxa como sendo a máxima definida.
Para extrair o máximo da configuração é necessário colocar o charge-lnd para executar uma vez a cada hora. Para deixar isso automático, basta incluir mais um cronjob no crontab:
0 * * * * admin /caminho/para/charge-lnd -c /caminho/para/charge.config
Importante! O script NÃO deve ser executado com maior frequência do que um vez por hora. Isso porque as atualizações são propagadas mais ou menos na velocidade de 1 salto por minuto. Se alterar as taxas com uma frequência maior, os nodes que quiserem rotear usando seus canais, terão erros do tipo FEE_INSUFFICIENT e o deixarão em uma blacklist por algumas horas. Além disso, ninguém deseja que o tráfico da atualização dessa informação seja constante.
Analisando a configuração de algumas pessoas, encontrei uma configuração de taxas que muitos disseram ser interessante:
[proporcional]
chan.min_ratio = 0 # definição de mínimo
chan.max_ratio = 1 # definição de máximo
strategy = proportional # Tipo de estratégia
base_fee_msat = 1000 # Taxa base
min_fee_ppm = 2 # taxa mínima
max_fee_ppm = 200 #taxa máxima
Apesar de ter falado anteriormente, voltarei a dizer para evitar que acidentes aconteçam.
Talvez tenha notado que ao alterar sua política de taxas, automaticamente entrará em conflito com a lógica usada na ferramenta rebalance-lnd, principalmente se quiser utilizar a viabilidade econômica da aplicação (ou seja, executar sem utilizar o --reckless).
Para evitar problemas relacionados a isso, minha recomendação é:
- Utilize uma
min_fee_ppmnocharge-lndnão muito baixa, e configure orebalance-lndcom um valor menor do que essa taxa; - Utilize OU o
charge-lndpara balancear os canais organicamente (demora mas não paga taxas), OU utilize orebalance-lndpara balancear os canais ativamente (mais rápido, mas pagando taxas).
Não existe almoço grátis. Ou tem as melhores práticas de uma ferramenta, ou tem as melhores práticas de outra, ou tem complexidade que evita usar as melhores práticas, ou utiliza as melhores práticas de maneira simplificada e perde dinheiro.
Comprando Liquidez Remota
Pode parecer absurdo e até mesmo contra intuitivo pensar que as pessoas que executam seus próprios nodes e abrem seus próprios canais com foco no roteamento possuem problemas de liquidez, mas ganhar e manter liquidez remota (inbound) é um dos maiores desafios para quem executa um node de roteamento.
No momento em que estou escrevendo este artigo os valores de compra de um milhão de satoshis de liquidez remota dos seguintes serviços são:
Você pode usar serviços que abrem canais recíprocos, mas para isso é necessário confiar no serviço, no sentindo de que ele irá te enviar os saldos posteriormente ou que eles vão abrir os canais como prometido. Se não tiver problema com isso pode usar esses dois serviços:
Outra possibilidade é usar uma exchange que tenha suporte a Lightning Network, assim poderá abrir um canal com ela, enviar os saldos e posteriormente sacar usando uma transação onchain, criando assim uma liquidez remota. Ou abrir canais com empresas que possuem serviços de carteiras lightning, como a Breez e a Phoenix, assim pode baixar o aplicativo da carteira, e fazer um envio para ela e posteriormente enviar de volta usando uma transação onchain.
Por fim, existem vários canais de comunidades ativas que garantem liquidez na rede. Aqui deixarei algumas delas e quais faço parte:
- PlebNet (Faço parte e já testei);
- LightningNetwork+ (Irei testar em um futuro próximo);
- Reddit Lightning Triangles (Não testei e não faço parte);
- Rings of Fire (Não testei e não faço parte).
Vale deixar claro que não existe nenhum tipo de garantia de que haverá entrada de liquidez, pois os terceiros podem analisar seu node como sendo mal conectado e consequentemente fechar os canais.
De todas as opções, a única que realmente garante o recebimento da liquidez informada é a Lightning Pool (que pode ser acessada através da LiT), pois existe um contrato pode detrás da relação entre as partes e nele está escrito o tempo de duração do canal e o mesmo realmente é garantido, a nível da blockchain.
Fechando Canais e Liberando Saldos
Chegará um momento em que os nodes que foram abertos canais começarão a ficar instáveis, criando assim a necessidade de fechar os canais para que o saldo seja alocado em outro canal. Se o canal for fechado cooperativamente, ou seja, quando for feito o fechamento o node terceiro está online, não há problema nenhum. Mas nem sempre será o caso. Quando há o fechamento unilateral, o seu saldo pode ficar preso no limbo por semanas.
Por isso é importante avaliar se os nodes nos quais possui canais estão saudáveis. É possível fazer isso manualmente, mas caso tenha muitos canais, o BOS possui uma opção que pode ajudar a avaliar quais canais fechar. Basta usar o seguinte comando:
bos remove-peer --dryrun --idle-days 30 --active
O comando acima irá analisar ao invés de realmente fechar --dryrun, os nodes que fazem 30 dias ou mais que não são roteados --iddle-days e que estão online no momento --active.
Você pode usar a flag --offline com a opção fee-rate para fechar os canais que estiverem offline a uma taxa de X sats por byte:
bos remove-peer --dryrun --idle-days 30 --fee-rate 1 --offline
Se quiser deixar tudo no automático é só colocar no crontab para executar os dois comandos sem a flag de análise uma vez por dia.
Soluções Avançadas
Nesta seção, vou mostrar algumas soluções mais avançadas que podem ser utilizados para fazer os loops (para dentro e fora da Lightning Network) mas que demandam um conhecimento mais técnico e entendimento mais avançado sobre a Lightning Network, bem como utilização mais intensivas da linha de comando e de configurações.
Usando a Lightning Loop
A Lightning Loop é uma excelente solução para conseguir liquidez remota de modo a demandar menos confiança de terceiros do que as soluções acima, mas para que consiga utilizá-la é necessário ter alguns conhecimentos mais aprofundados para configurar a ferramenta (não é algo difícil, mas demanda um pouco de trabalho).
Quando tudo estiver configurado, é só acessar a documentação para verificar os comandos da ferramenta. No caso estou fazendo uma cotação (quote) de quanto ficaria a retirada (out) de 500 mil satoshis da Lightning Network, para ganhar liquidez remota:
$ ./loop quote out -v 500000
Send off-chain: 500000 sat
Receive on-chain: 498532 sat
Estimated on-chain fee: 218 sat
Loop service fee: 1250 sat
Estimated total fee: 1468 sat
No show penalty (prepay): 30000 sat
Talvez tenha mais sucesso do que tive, mas é muito difícil ter o loop confirmado. Boa parte dos loops que fiz manualmente (existe a opção de fazer automático) não foram concluídos. Além disso, para fazer a retirada é importante fazer com uma quantidade considerável para que as taxas da rede valham à pena, entretanto, quanto maior a quantidade que queira retirar, mais difícil é para encontrar saldo.
Valores como o informado acima podem ser fáceis de serem roteados, porém, quando fui fazer um loop de 5 milhões de satoshis, não consegui de jeito nenhum. Existe uma outra opção que é abrir um canal com o node Loop diretamente. É sobre isso que vamos falar na próxima seção.
Abrindo Canal com a Loop
Como não consegui fazer o loop usando a ferramenta acima, decidi então abrir um canal diretamente com node do Loop (Atenção! O único node Loop é este, às vezes, as pessoas colocam o nome do node igual para que novatos desatentos abram canais com eles ao invés de abrir com o verdadeiro), assim não teria problema de roteamento na Lightning devido a tentar enviar uma quantidade grande.
Abri um canal com eles, mas sem a intenção de fazer o loop out, apenas para rotear pagamentos. Em menos de uma semana, não havia mais nenhuma capacidade para enviar satoshis para a Loop devido ao roteamento consumir todo o meu saldo local. Em alguns fóruns o pessoal diz que se o canal estiver com menos de 1/5 do saldo no lado local, a Loop o fecha automaticamente.
Basicamente, os canais que são abertos com eles com o propósito de roteamento são fechados rapidamente, tanto que se observar a média de idade dos canais, verá que não passam de 15 dias, e normalmente, são fechados um pouco menos de 10% dos canais, todos os dias. Portanto, é uma boa opção ter um canal de roteamento com a Loop, contanto, que a blockchain esteja vazia.
Talvez tenha passado pela sua cabeça a seguinte estratégia milionária:
“Ora, se o roteamento é garantido neste node, basta abrir um canal, deixar ele ser drenado, fechado e depois, é só abrir novamente, e repetir o processo e ganhar satoshinhos com o roteamento”.
Pois é meu amigo, mas não se esqueça que do mesmo jeito que este canal é drenado, os outros canais abertos no seu node serão cheios na mesma proporção da drenagem. Isso significa que chegará uma hora que todos os seus outros canais estarão com liquidez local, e neste momento você é quem precisará fazer o loop out, que muito provavelmente irá lhe custar todo o ganho de roteamento, senão, mais.
Uma estratégia que ainda não testei é abrir um canal com esse node, definir taxas altas de roteamento para ele, garantindo que não seja drenado rapidamente, e em seguida, ir comprando liquidez local a uma taxa menor do que aquela conseguida pelo roteamento, assim o canal não é fechado e existe o lucro no processo.
Resultados obtidos
Estes são os resultados obtidos nos últimos 30 dias depois que coloquei em prática todas as informações acima:
Estes foram os custos de roteamento que foram necessários durante os últimos 30 dias:
Usando somente essas informações podemos perceber que obtive um lucro de 3.535 satoshis. Entretanto, o que não é informado nesses gráficos é o custo de abertura e fechamento dos canais, que posso garantir que foi maior do que este valor.
Apesar de não ter um node focado em roteamento que seja lucrativo, acredito que no futuro próximo, consiga ter uma receita que sobreponha os meus gastos, pois estou vendo uma consistência maior nos meus ganhos de roteamento.
Existem algumas coisas que precisam ser atualizadas para que possa aumentar a receita, uma delas é a atualização da LND para a versão 0.13. Atualmente, utilizo a versão 0.12 que não me permite ter canais conectados a nodes que não estejam na rede TOR.
Outro ponto que não tem perspectiva de ser atualizado, mas que acredito ser necessário para a expansão da Lightning Network é a diminuição da latência da rede TOR como um todo, pois o modelo atual tende a deixar os pagamentos mais lentos e em situações piores, evitar que o roteamento funcione completamente.
Como operador do node, durante muito tempo fiquei focado no balanço dos saldos individualmente, porém percebi que a liquidez geral do node é muito mais importante. Isso significa que se você tiver no total, 10 milhões de sats de liquidez remota e apenas 1 milhão de sats local, toda essa quantidade de liquidez remota é inútil. Canais menores e balanceados são melhores do que canais grandes e totalmente desbalanceados.
Além disso, é importante entender que o seu raspberry não foi feito para esta função, portanto, cuidado em ter grandes expectativas. Se quiser realmente focar no ganho financeiro, é importante disponibilizar um hardware apropriado, ou adquirir uma VPS descente.
De maneira geral, existe muita coisa a ser melhorada na Lightning que irão ajudar os nodes de roteamento, mas também precisamos entender mais sobre o gerenciamento e o roteamento da liquidez. Precisamos conseguir mais informações sobre os canais que enviam pagamentos, e precisamos de mais comunicação entre os nodes (atualmente, podemos usar o BOS para enviar mensagens por 1 satoshi para os nodes que temos canal, usando o bos send, mas é muito difícil a pessoa ler). Seria uma solução excelente, porque poderíamos conversar com os demais operadores para verificar o que está acontecendo, se estão tendo problemas ou quais são suas intenções.
Ainda é muito difícil encontrar as rotas ideias, tanto que Rene Pickhardt e Stefan Richter escreveram um artigo sobre o assunto e mostraram que é essa tarefa é complicada principalmente quando a taxa base não é definida como 0. Eu mesmo defini as taxas base dos canais que abro como sendo 0, tanto para ajudar em um futuro quando a análise de grafos for implantada, como também, porque acredito ser mais fácil para rotear valores mais baixos.
Por fim, parabéns por ler este artigo. Acredito que ele poderá te ajudar a ingressar de maneira mais consciente no mundo da Lightning Network, além de mostrar muitas ferramentas que foram construídas a fim de ajudar a resolver uma das N dores de quem tem o seu próprio node. Se tiver alguma dúvida, ou pergunta, sinta-se a vontade me procurar no Twitter.
Ah, e uma última dica que na verdade é relacionada ao node como um todo. Se você é como eu, e quer saber realmente quando as coisas aconteceram sem precisar ficar fazendo conta porque o node está com o fuso horário errado, basta rodar na linha de comando do seu node o seguinte:
sudo timedatectl set-timezone America/Sao_Paulo
