Dominando A Rede Relâmpago

Glossário
Este glossário rápido contém muitos dos termos usados em relação ao Bitcoin e à Lightning
Network. Esses termos são usados ao longo do livro, portanto, marque-os como uma referência
rápida.
endereço
Endereços de Bitcoin codificam de forma compacta as informações necessárias para pagar um
receptor. Um endereço moderno consiste em uma sequência de letras e números que começa
com bc1 e se parece com bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4. Um endereço é uma
forma abreviada para o script de bloqueio (locking script) do receptor, que pode ser usado por
um remetente para transferir fundos para o receptor. A maioria dos endereços representa a
chave pública do receptor ou algum tipo de script que define condições de gastos mais
complexas. O exemplo anterior é um endereço bech32 que codifica um programa de testemunha
bloqueando fundos no hash de uma chave pública (Veja Pay-to-Witness-Public-Key-Hash).
Também existem formatos de endereços mais antigos que começam com 1 ou 3 e usam a
codificação de endereço Base58Check para representar hashes de chaves públicas ou hashes de
scripts.
sistema criptográfico assimétrico

Criptografia assimétrica, ou criptografia de chave pública, é um sistema criptográfico que utiliza
pares de chaves: chaves públicas que podem ser amplamente divulgadas e chaves privadas que
são conhecidas apenas pelo proprietário. A geração de tais chaves depende de algoritmos
criptográficos baseados em problemas matemáticos para produzir funções que são fáceis de
resolver em uma direção, mas muito difíceis de resolver na direção oposta. A segurança efetiva
requer apenas manter a chave privada em sigilo; a chave pública pode ser distribuída
abertamente sem comprometer a segurança.
piloto automático
Um piloto automático é um mecanismo de recomendação para nós (nodes) Lightning que utiliza
estatísticas da topologia da Lightning Network para sugerir com quais nós eles devem abrir
canais. Dependendo da implementação do piloto automático, a capacidade do canal também
pode ser recomendada. Um piloto automático não faz parte do protocolo LN.
saldo
O saldo de um canal de pagamento é a quantidade de bitcoin que pertence a cada parceiro do
canal. Por exemplo, Alice pode abrir um canal com Bob no valor de 1 BTC. O saldo do canal seria
então de 1 BTC para Alice e 0 BTC para Bob. À medida que os usuários realizam transações, o
saldo do canal é atualizado. Por exemplo, se Alice envia 0,2 BTC para Bob, o saldo agora é 0,8 BTC
para Alice e 0,2 para Bob. Quando o canal é fechado, os bitcoins no canal são divididos entre os
dois parceiros do canal de acordo com o saldo mais recente codificado na transação de
compromisso (commitment transaction). Na Rede Lightning, a capacidade de enviar e receber
pagamentos é limitada pelos saldos dos canais. Consulte capacidade.
bech32
Bech32 se refere a um formato genérico codificado em base32 com verificação de checksum,
oferecendo garantias fortes de detecção de erros. Embora o Bech32 tenha sido originalmente
1
desenvolvido para ser usado como formato de endereço para saídas nativas do SegWit (BIP-173),
ele também é utilizado para codificar faturas (invoices) do Lightning Network (BOLT #11).
Enquanto as saídas nativas do SegWit versão 0 (P2WPKH e P2WSH) utilizam o Bech32, versões
superiores de saídas nativas do SegWit (como Pay-to-Taproot ou P2TR) utilizam a variante
aprimorada chamada bech32m (BIP-350). Os endereços bech32m são às vezes chamados de
"endereços bc1", refletindo o prefixo desses endereços. As saídas nativas do SegWit são mais
eficientes em termos de espaço de bloco em comparação aos endereços mais antigos, podendo,
assim, reduzir as taxas de transação para o proprietário de um endereço desse tipo.
Bitcoin Improvement Proposal (BIP)

Um BIP (Bitcoin Improvement Proposal) é uma proposta apresentada por membros da
comunidade Bitcoin para melhorar o Bitcoin. Por exemplo, o BIP-21 é uma proposta para
melhorar o esquema de identificador uniforme de recursos (URI) do Bitcoin. Os BIPs podem ser
encontrados em GitHub.
bitcoin, Bitcoin
Dependendo do contexto, "bitcoin" pode se referir ao nome da unidade de moeda (a
criptomoeda em si), à rede ou ao protocolo subjacente. Escrito como "bitcoin" com "b" minúsculo
geralmente se refere à unidade de moeda. Já "Bitcoin" com "B" maiúsculo geralmente se refere
ao protocolo ou sistema.
mineração de Bitcoin
A mineração de Bitcoin é o processo de construir um bloco a partir de transações recentes de
Bitcoin e, em seguida, resolver um problema computacional necessário como prova de trabalho.
É o processo pelo qual o registro compartilhado de bitcoins (ou seja, a blockchain do Bitcoin) é
atualizada e novas transações são incluídas no registro. É também o processo pelo qual novos
bitcoins são emitidos. Sempre que um novo bloco é criado, o nó de mineração recebe novos
bitcoins criados dentro da transação coinbase desse bloco.
bloco
Um bloco é uma estrutura de dados na blockchain do Bitcoin que consiste em um cabeçalho e
um corpo de transações de Bitcoin. O bloco é marcado com um carimbo de data e hora e se
refere a um bloco predecessor (pai) específico. Quando é aplicada a função de hash ao cabeçalho
do bloco, ele fornece a prova de trabalho que torna a blockchain probabilisticamente imutável.
Os blocos devem obedecer às regras impostas pelo consenso da rede para estender a blockchain.
Quando um bloco é anexado à blockchain, as transações incluídas são consideradas como tendo
sua primeira confirmação.
blockchain
A blockchain é um registro distribuído, ou banco de dados, de todas as transações Bitcoin. As
transações são agrupadas em atualizações discretas chamadas de blocos, limitados a 4 milhões
de unidades de peso. Os blocos são produzidos aproximadamente a cada 10 minutos por meio de
um processo estocástico chamado mineração. Cada bloco inclui uma "prova de trabalho"
computacionalmente intensiva. O requisito de prova de trabalho é usado para regular os
intervalos de bloco e proteger a blockchain contra ataques que visam reescrever o histórico: um
atacante precisaria superar a prova de trabalho existente para substituir os blocos já publicados,
tornando cada bloco probabilisticamente imutável à medida que é "enterrado" sob blocos
subsequentes.
2
BOLT
A BOLT—Basis Of Lightning Technology ou Base da Tecnologia Lightning—é a especificação
formal da Lightning Network. Ao contrário do Bitcoin, que possui uma implementação de
referência que também serve como especificação do protocolo, as várias implementações da LN
seguem o BOLT para que possam funcionar entre si e formar a mesma rede. Ele está disponível
em GitHub.
capacidade
A capacidade de um canal de pagamento é equivalente à quantidade de bitcoin fornecida pela
transação de financiamento (funding transaction). Devido à visibilidade pública da transação de
financiamento na blockchain e ao anúncio do canal por meio do protocolo de divulgação (gossip
protocol), a capacidade do canal é uma informação pública. Isso não revela nenhuma
informação sobre quanto bitcoin cada um dos parceiros do canal possui no canal, ou seja, o
saldo. Uma alta capacidade não garante que o canal possa ser usado para roteamento em ambos
os sentidos .
c-lightning
Implementação do protocolo LN pela empresa baseada em Victoria Blockstream. Está escrito em
C. O código-fonte está em GitHub.
closing transaction
Se ambos os parceiros do canal concordarem em fechar um canal, eles criarão uma transação de
liquidação que reflete a transação de compromisso mais recente. Após a troca de assinaturas
para uma transação de fechamento, nenhuma atualização adicional do canal deve ser feita. O
fechamento mútuo de um canal com a ajuda de uma transação de fechamento tem a vantagem
de que menos transações de blockchain são necessárias para reivindicar todos os fundos, em
comparação com forçar unilateralmente o fechamento de um canal publicando uma transação
de compromisso. Além disso, os fundos para ambas as partes podem ser gastos imediatamente
após o fechamento da transação.
CLTV
CLTV é uma sigla para o operador de Script do Bitcoin OP_CHECKLOCKTIMEVERIFY. Isso define
um bloco de altura absoluta antes que uma saída possa ser gasta. A atomicidade do processo de
roteamento depende muito dos valores CLTV em HTLCs. Os nós de roteamento anunciam, por
meio do protocolo de divulgação (gossip protocol), seus deltas de expiração CLTV esperados para
quaisquer HTLCs de entrada e saída.
coinbase
A coinbase é um campo especial permitido apenas na única entrada de transações coinbase. A
coinbase permite até 100 bytes de dados arbitrários, mas desde o BIP-34, deve primeiro
apresentar a altura do bloco atual para garantir que as transações coinbase sejam únicas. Não
deve ser confundido com transação coinbase.
transação coinbase
A primeira transação em um bloco que é sempre criada por um minerador e inclui uma única
coinbase. A transação coinbase pode reivindicar a recompensa do bloco e atribuí-la a uma ou
mais saídas. A recompensa do bloco consiste no subsídio do bloco (bitcoin recém-criado) e na
soma de todas as taxas de transação das transações incluídas no bloco. As saídas coinbase só
3
podem ser gastas após amadurecerem por 100 blocos. Se o bloco incluir alguma transação
SegWit, a transação coinbase deve incluir um compromisso com os identificadores de transação
testemunha (witness transaction identifiers) em uma saída adicional.
cold storage
Refere-se a manter uma quantidade de bitcoin offline. O armazenamento a frio (cold storage) é
alcançado quando as chaves privadas do Bitcoin são criadas e armazenadas em um ambiente
seguro e offline. O armazenamento a frio é importante para proteger os bitcoins. Computadores
online estão vulneráveis a hackers e não devem ser usados para armazenar uma quantidade
significativa de bitcoins.
commitment transaction
Uma transação de compromisso é uma transação Bitcoin, assinada por ambos os parceiros de
canal, que codifica o saldo mais recente de um canal. Sempre que um novo pagamento for feito
ou encaminhado pelo canal, o saldo do canal será atualizado e uma nova transação de
compromisso será assinada por ambas as partes. É importante ressaltar que em um canal entre
Alice e Bob, tanto Alice quanto Bob mantêm sua própria versão da transação de compromisso
(commitment transaction), que também é assinada pela outra parte. A qualquer momento, o
canal pode ser fechado por Alice ou Bob se eles enviarem sua transação de compromisso para a
blockchain do Bitcoin. O envio de uma transação de compromisso mais antiga (desatualizada) é
considerado uma "trapaça" (ou seja, uma violação do protocolo) na Rede Lightning e pode ser
penalizado pela outra parte, que pode reivindicar todos os fundos do canal para si por meio de
uma transação de penalidade (penalty transaction).
confirmações
Assim que uma transação é incluída em um bloco, ela possui uma confirmação. Assim que o
próximo bloco é minerado na blockchain, a transação possui duas confirmações, e assim por
diante. Seis ou mais confirmações são consideradas provas suficientes de que uma transação
não pode ser revertida.
contrato
Um contrato é um conjunto de transações Bitcoin que juntas resultam em um determinado
comportamento desejado. Exemplos são RSMCs (Revocable Sequence Maturity Contracts) para
criar um canal de pagamento bidirecional sem confiança, ou HTLCs (Hashed Time-Locked
Contracts) para criar um mecanismo que permite o encaminhamento de pagamentos sem
confiança por meio de terceiros.
Diffie–Hellman Key Exchange (DHKE)

Na Rede Lightning, o método Elliptic Curve Diffie-Hellman (ECDH) é usado. É um protocolo de
acordo de chave anônimo que permite que duas partes, cada uma tendo um par de chaves
pública-privada de curva elíptica, estabeleçam um segredo compartilhado por meio de um canal
de comunicação inseguro. Esse segredo compartilhado pode ser usado diretamente como uma
chave ou para derivar outra chave. A chave, ou a chave derivada, pode então ser usada para
criptografar comunicações subsequentes usando uma cifra de chave simétrica. Um exemplo de
chave derivada seria o segredo compartilhado entre a chave de sessão efêmera de um remetente
de uma cebola com a chave pública do nó de um salto da cebola, conforme descrito e usado pelo
SPHINX Mix Format.
4
assinatura digital
Uma assinatura digital é um esquema matemático para verificar a autenticidade e integridade
de mensagens ou documentos digitais. Pode ser visto como um compromisso criptográfico em
que a mensagem não está oculta.
gasto duplo
O gasto duplo é o resultado de gastar algum dinheiro com sucesso mais de uma vez. Bitcoin
protege contra gastos duplos, verificando se cada transação adicionada à blockchain adere às
regras de consenso; isso significa verificar se os insumos para a transação não foram gastos
anteriormente.
Elliptic Curve Digital Signature Algorithm (ECDSA)

O Algoritmo de Assinatura Digital de Curva Elíptica ou ECDSA (Elliptic Curve Digital Signature
Algorithm) é um algoritmo criptográfico usado pelo Bitcoin para garantir que os fundos só
possam ser gastos pelo detentor da chave privada correta.
Eclair
Implementação do Protocolo LN pela empresa com sede em Paris ACINQ. Está escrito em Scala.
O código-fonte está em GitHub.
encoding
Codificação é o processo de converter uma mensagem em uma forma diferente. Por exemplo,
converter um número de decimal para hexadecimal.
servidor Electrum
Um servidor Electrum é um nó Bitcoin com uma interface adicional (API). Ele é frequentemente
necessário por carteiras de Bitcoin que não executam um nó completo (full node). Por exemplo,
essas carteiras verificam o status de transações específicas ou transmitem transações para o
mempool usando as APIs do servidor Electrum. Algumas carteiras (wallets) da Rede Lightning
também utilizam servidores Electrum.
chave efêmera
Chaves efêmeras são chaves que são usadas apenas por um curto período de tempo e não são
mantidas após o uso. Elas são frequentemente derivadas para uso em uma sessão a partir de
outra chave que é retida a longo prazo. As chaves efêmeras são principalmente usadas dentro do
formato SPHINX Mix e no roteamento de cebolas (onion routing) na Lightning Network. Isso
aumenta a segurança das mensagens ou pagamentos transportados. Mesmo que uma chave
efêmera vaze, apenas as informações sobre uma única sessão se tornam públicas.
feature bits
Uma string binária que os nós da Lightning usam para comunicar entre si quais recursos são
compatíveis. Bits de recurso (feature bits) são incluídos em muitas mensagens da Lightning
Network, bem como no BOLT #11. Eles podem ser decodificados usando o BOLT #9 e informarão
aos nós quais recursos o nó habilitou e se eles são compatíveis com versões anteriores. Também
conhecidos como "flags" de recursos.
taxas
No contexto da Rede Lightning, os nós cobrarão taxas de roteamento para encaminhar os
5
pagamentos de outros usuários. Os nós individuais podem definir suas próprias políticas de
taxas, que serão calculadas como a soma de uma taxa fixa (base_fee) e uma taxa de juros
(fee_rate) que depende do valor do pagamento. No contexto do Bitcoin, o remetente de uma
transação paga uma taxa de transação aos mineradores para incluir a transação em um bloco.
As taxas de transação do Bitcoin não incluem uma taxa base e dependem linearmente do peso
da transação, mas não do valor da transação.
funding transaction
A transação de financiamento é usada para abrir um canal de pagamento. O valor (em bitcoin)
da transação de financiamento é exatamente a capacidade do canal de pagamento. A saída da
transação de financiamento é um script de múltiplas assinaturas (multisig) 2-de-2, onde cada
parceiro do canal controla uma chave. Devido à sua natureza de multisig, ela só pode ser gasta
por acordo mútuo entre os parceiros do canal. Eventualmente, será gasta por uma das
transações de compromisso ou pela transação de fechamento.
características globais (globalfeatures field)

As características globais de um nó da Lightning Network são as características de interesse para
todos os outros nós. Mais comumente, eles estão relacionados a formatos de roteamento
suportados. Elas são anunciadas na mensagem init do protocolo de pares (peer protocol), bem
como nas mensagens channel_announcement e node_announcement do protocolo de divulgação
(gossip protocol).
protocolo gossip
Os nós da Lightning Network enviam e recebem informações sobre a topologia da rede
Lightning por meio de mensagens de divulgação (gossip messages) que são trocadas com seus
pares. O protocolo de divulgação (gossip protocol) é principalmente definido no BOLT #7 e define
o formato das mensagens node_announcement, channel_announcement e channel_update. Para evitar
spam, as mensagens de anúncio de nó só serão encaminhadas se o nó já tiver um canal, e as
mensagens de anúncio de canal só serão encaminhadas se a transação de financiamento do
canal tiver sido confirmada pela rede Bitcoin. Normalmente, os nós da Lightning Network se
conectam aos seus parceiros de canal, mas também é possível se conectar a qualquer outro nó
da Lightning para processar as mensagens de divulgação (gossip messages).
hardware wallet
Uma carteira de hardware é um tipo especial de carteira Bitcoin que armazena as chaves
privadas do usuário em um dispositivo de hardware seguro. No momento em que escrevemos o
livro, as carteiras de hardware não estão disponíveis para os nós da LN porque as chaves usadas
pela Lightning precisam estar online para participar do protocolo.
hash
Uma impressão digital de tamanho fixo de alguma entrada binária de comprimento arbitrário.
Também conhecido como digest.
hash-based message authentication code (HMAC)

O HMAC (Hash-based Message Authentication Code) é um algoritmo para verificar a integridade
e autenticidade de uma mensagem com base em uma função de hash e uma chave criptográfica.
Ele é usado no roteamento de cebola (onio routing) para garantir a integridade de um pacote em
cada salto, bem como na variante do protocolo de ruído (Noise Protocol) usado para criptografia
6
de mensagens.
função hash
Uma função hash criptográfica é um algoritmo matemático que mapeia dados de tamanho
arbitrário para uma sequência de bits de tamanho fixo (um hash) e é projetada para ser uma
função unidirecional, ou seja, uma função que é inviável de ser invertida. A única maneira de
recriar os dados de entrada a partir da saída de uma função hash criptográfica ideal é tentar
uma busca de força bruta (brute-force search) de possíveis entradas para ver se elas produzem
uma correspondência (match).
hashlock
Um hashlock é uma condição de gasto (spending condition) em Bitcoin Script que restringe o
gasto de uma saída até que um determinado dado seja revelado. Os hashlocks possuem a
propriedade útil de que, uma vez que qualquer hashlock seja revelado por meio de um gasto,
quaisquer outros hashlocks protegidos usando a mesma chave também podem ser gastos. Isso
torna possível criar várias saídas que estão todas condicionadas pelo mesmo hashlock e que se
tornam todas gastáveis ao mesmo tempo.
hash time-locked contract (HTLC)

Um contrato de tempo fechado por hash (HTLC - Hash Time-Locked Contract) é um Bitcoin Script
que consiste em hashlocks (travas de hash) e timelocks (travas de tempo) para exigir que o
destinatário de um pagamento gaste o pagamento antes de um prazo, apresentando a pré-
imagem do hash, ou o remetente pode reivindicar um reembolso após a expiração do timelock.
Na Lightning Network, os HTLCs são saídas na transação de compromisso (commitment
transaction) de um canal de pagamento e são usados para possibilitar o roteamento de
pagamentos sem confiança.
invoice
O processo de pagamento na Lightning Network é iniciado pelo destinatário (recebedor), que
emite uma fatura, também conhecida como solicitação de pagamento (invoice), ou payment
request. As faturas incluem o hash do pagamento, o valor, uma descrição e o tempo de
expiração. As faturas da Lightning Network são definidas no BOLT #11. As faturas também
podem incluir um endereço Bitcoin de fallback para o qual o pagamento pode ser feito caso não
seja possível encontrar uma rota, bem como dicas para o roteamento de um pagamento por
meio de um canal privado.
just-in-time (JIT) routing

O roteamento Just-in-time (JIT) é uma alternativa ao roteamento baseado na origem que foi
proposto pela primeira vez pelo coautor René Pickhardt. Com o roteamento just-in-time (JIT), os
nós intermediários ao longo de um caminho podem pausar um pagamento em andamento (in-
flight payment) para reequilibrar seus canais antes de prosseguir com o pagamento. Isso pode
permitir que eles encaminhem com sucesso pagamentos que, de outra forma, poderiam ter
falhado devido à falta de capacidade de saída.
Lightning message
Uma mensagem da Lightning Network é uma sequência de dados criptografados que pode ser
enviada entre dois pares na Lightning Network. Semelhante a outros protocolos de
comunicação, as mensagens da Lightning consistem em um cabeçalho e um corpo. O cabeçalho e
7
o corpo possuem seus próprios HMAC (Hash-based Message Authentication Code). As mensagens
da Lightning são o principal componente da camada de mensagens.
Lightning Network, Lightning Network Protocol, Lightning Protocol

A Lightning Network, ou Rede Relâmpago, é um protocolo em cima do Bitcoin (ou outras
criptomoedas). Ele cria uma rede de canais de pagamento que permite o encaminhamento
confiável de pagamentos através da rede com a ajuda de HTLCs (Hashed Time-Locked Contract)
e roteamento de cebola. Outros componentes da Lightning Network são o protocolo de
divulgação (gossipprotocol), a camada de transporte e as solicitações de pagamento.
Lightning Network protocol suite

O conjunto de protocolos Lightning Network consiste em cinco camadas responsáveis por várias
partes do protocolo. Da camada inferior (primeira camada) até a camada superior (quinta
camada), essas camadas são chamadas de camada de comunicação de rede (network
communication layer), camada de mensagens (messaging layer), camada peer-to-peer (peer-to-
peer layer), camada de roteamento (routing layer) e camada de pagamento (payment layer).
Vários BOLTs definem partes de uma ou várias camadas.
Lightning Network node, Lightning node

Um computador que participa da Lightning Network, por meio do protocolo ponto a ponto
Lightning. Os nós do Lightning têm a capacidade de abrir canais com outros nós, enviar e
receber pagamentos e encaminhar pagamentos de outros usuários. Normalmente, um usuário
de nó Lightning também executará um nó Bitcoin.
lnd
Implementação do protocolo LN pela empresa com sede em São Francisco Lightning Labs. Está
escrito em Go. O código-fonte está em GitHub.
local features (field: localfeatures)

As características locais de um nó da Lightning Network são as características configuráveis de
interesse direto para seus pares. Eles são anunciados na mensagem init do protocolo peer, bem
como nas mensagens channel_announcement e node_announcement do protocolo gossip (protocolo de
divulgação).
locktime
Locktime, ou mais tecnicamente nLockTime, é a parte de uma transação de Bitcoin que indica o
horário mais cedo ou o bloco mais cedo em que essa transação pode ser adicionada à blockchain.
messaging layer
A camada de mensagens é construída em cima da camada de conexão de rede do conjunto de
protocolos da Lightning Network. A camada de mensagens é responsável por garantir uma
comunicação criptografada e segura, bem como a troca de informações por meio do protocolo
da camada de conexão de rede escolhido. A camada de mensagens define o formato e a
estrutura das Mensagens da Lightning Network, conforme definido no BOLT #1. Os bits de
recurso (feature bits) definidos no BOLT #9 também fazem parte desta camada.
millisatoshi
A menor unidade de conta na Lightning Network. Um millisatoshi é um centésimo de
8
bilionésimo de um único bitcoin. Um millisatoshi é um milésimo de um satoshi. Os millisatoshis
não existem nem podem ser liquidados na rede Bitcoin.
multipart payments (MPP)

Os pagamentos multipartes (MPP), frequentemente também chamados de pagamentos
multipath, são um método para dividir o valor do pagamento em várias partes menores e
entregá-las ao longo de um ou mais caminhos. Como o MPP pode enviar muitas ou todas as
partes por um único caminho, o termo pagamento multipartes é mais preciso do que pagamento
multipath. Na ciência da computação, os pagamentos multipartes são modelados como fluxos de
rede.
multisignature
Multisignature (multisig) refere-se a um script que requer mais de uma assinatura para
autorizar gastos. Os canais de pagamento são sempre codificados como endereços multisig que
exigem uma assinatura de cada parceiro do canal de pagamento. No caso padrão de um canal de
pagamento de duas partes, um endereço multisig 2 de 2 (2-of-2) é usado.
node
See Lightning Network node.
network capacity
A capacidade do LN é a quantidade total de bitcoin bloqueado e circulado dentro da Lightning
Network. É a soma das capacidades de cada canal público. Isso reflete o uso da Lightning
Network até certo ponto, porque esperamos que as pessoas coloquem bitcoin nos canais
Lightning para gastá-lo ou encaminhar pagamentos de outros usuários. Portanto, quanto maior
a quantidade de bitcoin nos canais Lightning, maior o uso esperado da Lightning Network.
Observe que, como apenas a capacidade pública do canal pode ser observada, a capacidade real
da rede é desconhecida. Além disso, como a capacidade de um canal pode permitir um número
ilimitado de pagamentos de ida e volta, a capacidade da rede não implica um limite no valor
transferido na Lightning Network.
network connection layer

A camada mais baixa do conjunto de protocolos Lightning Network. Sua responsabilidade é
suportar protocolos de internet como IPv4, IPv6, TOR2 e TOR3, e utilizá-los para estabelecer um
canal de comunicação criptográfico seguro, conforme definido no BOLT #8, ou para utilizar o
protocolo DNS para a inicialização da rede, conforme definido no BOLT #10.
Noise_XK
O modelo do Framework de Protocolo de Ruído (Noise Protocol Framework) é usado para
estabelecer um canal de comunicação autenticado e criptografado entre dois pares da Lightning
Network. X significa que nenhuma chave pública precisa ser conhecida do iniciador da conexão.
K significa que a chave pública do receptor precisa ser conhecida.
onion routing
O roteamento Onion (roteamento de cebola) é uma técnica para comunicação anônima em uma
rede de computadores. Em uma rede cebola, as mensagens são encapsuladas em camadas de
criptografia, análogas às camadas de uma cebola. Os dados criptografados são transmitidos por
uma série de nós de rede chamados roteadores de cebola, cada um dos quais remove uma única
9
camada, revelando o próximo destino dos dados. Quando a camada final é descriptografada, a
mensagem chega ao seu destino. O remetente permanece anônimo porque cada intermediário
conhece apenas a localização dos nós imediatamente anteriores e posteriores.
output
A saída de uma transação Bitcoin, também chamada de saída de transação não gasta
(UTXO—Unspent Transaction Output). Uma saída é uma quantidade indivisível de bitcoin que
pode ser gasta, bem como um script que define quais condições precisam ser atendidas para que
esse bitcoin seja gasto. Toda transação bitcoin consome algumas saídas de transações registradas
anteriormente e cria novas saídas que podem ser gastas posteriormente por transações
subsequentes. Uma saída típica de bitcoin exigirá que uma assinatura seja gasta, mas as saídas
podem exigir o cumprimento de scripts mais complexos. Por exemplo, um script de múltiplas
assinaturas (multisignature) requer que dois ou mais detentores de chaves assinem antes que a
saída possa ser gasta. Esse é um componente fundamental da Lightning Network.
Pay-to-Public-Key-Hash (P2PKH)
P2PKH (Pay-to-Public-Key-Hash) é um tipo de saída que vincula bitcoin ao hash de uma chave
pública. Uma saída bloqueada por um script P2PKH pode ser desbloqueada (gasta) apresentando
a chave pública correspondente ao hash e uma assinatura digital criada pela chave privada
correspondente.
Pay-to-Script-Hash (P2SH)
P2SH (Pay-to-Script-Hash) é um tipo versátil de saída que permite o uso de Scripts Bitcoin
complexos. Com P2SH, o script complexo que detalha as condições para gastar a saída (redeem
script) não é apresentado no locking script. Em vez disso, o valor é bloqueado para o hash de um
script, que deve ser apresentado e cumprido para gastar a saída.
P2SH address
Os endereços P2SH são codificações Base58Check do hash de 20 bytes de um script. Os endereços
P2SH começam com um "3". Os endereços P2SH ocultam toda a complexidade, de modo que o
remetente de um pagamento não vê o script.
Pay-to-Witness-Public-Key-Hash (P2WPKH)
P2WPKH é o equivalente SegWit de P2PKH, usando uma testemunha segregada (segregated
witness). A assinatura para gastar uma saída P2WPKH é colocada na árvore testemunha em vez
do campo ScriptSig. Veja SegWit.
P2WPKH address
O formato de endereço "nativo SegWit v0", os endereços P2WPKH são codificados em bech32 e
começam com "bc1q".
Pay-to-Witness-Script-Hash (P2WSH)
P2WSH é o equivalente SegWit de P2SH, usando uma testemunha segregada. A assinatura e o
script para gastar uma saída P2WSH são colocados na árvore testemunha em vez do campo
ScriptSig. Veja SegWit.
P2WSH address
O formato de endereço de script "nativo Segwi v0", os endereços P2WSH são codificados em
10
bech32 e começam com "bc1q".
Pay-to-Taproot (P2TR)
Com ativação em novembro de 2021, o Taproot é um novo tipo de saída que bloqueia o bitcoin
em uma árvore de condições de gastos ou em uma única condição de raiz.
P2TR address
O formato de endereço Taproot, representando SegWit v1, é um endereço codificado em
bech32m e começa com "bc1p".
payment
Um pagamento Lightning ocorre quando o bitcoin é transferido dentro da Lightning Network. Os
pagamentos geralmente não são vistos na blockchain do Bitcoin.
payment channel
Um canal de pagamento é uma relação financeira entre dois nós na Lightning Network, criada
usando uma transação bitcoin pagando um endereço de assinatura múltipla. Os parceiros de
canal podem usar o canal para enviar bitcoins de um para o outro sem precisar registrar todas
as transações na blockchain do Bitcoin. Em um canal de pagamento típico, apenas duas
transações são adicionadas à blockchain: a transação de financiamento (funding transaction) e a
transação de compromisso (commitment transaction). Os pagamentos enviados pelo canal não
são registrados no blockchain e ocorrem "fora da cadeia" (off-chain).
payment layer
A camada superior e a quinta do conjunto de protocolos Lightning Network operam sobre a
camada de roteamento. Sua responsabilidade é viabilizar o processo de pagamento via BOLT
#11. Embora faça amplo uso do gráfico de canais obtido pelo protocolo de divulgação (gossip
protocol), conforme definido no BOLT #7, as estratégias reais para encaminhar um pagamento
não fazem parte da especificação do protocolo e são deixadas a cargo das implementações. Como
este tema é muito importante para garantir a confiabilidade do processo de entrega de
pagamentos, nós o incluímos neste livro.
peer
Os participantes em uma rede peer-to-peer. Na Lightning Network, os pares se conectam uns aos
outros por meio de comunicação criptografada e autenticada por meio de um soquete TCP, seja
por IP ou através do Tor.
peer-to-peer layer
A camada ponto a ponto (peer-to-peer) é a terceira camada do conjunto de protocolos Lightning
Network e funciona sobre a camada de mensagens. Ele é responsável por definir a sintaxe e a
semântica das informações trocadas entre os pares por meio de mensagens da rede Lightning.
Isso consiste em mensagens de controle conforme definidas no BOLT #9; mensagens de
estabelecimento de canal, operação e encerramento do canal conforme definidas no BOLT #2;
bem como mensagens de divulgação e roteamento conforme definidas no BOLT #7.
private channel
Um canal não anunciado para o resto da rede. Tecnicamente, "privado" é um termo inadequado
porque esses canais ainda podem ser identificados por meio de pistas de roteamento e
11
transações de compromisso. Eles são melhor descritos como canais "não-anunciados". Com um
canal não anunciado, os parceiros de canal podem enviar e receber pagamentos entre si
normalmente. No entanto, o restante da rede não estará ciente do canal e, portanto, não poderá
usá-lo para rotear pagamentos. Como o número e a capacidade de canais não anunciados são
desconhecidos, a contagem e a capacidade total de canais públicos representam apenas uma
parte do total da Lightning Network.
preimage
No contexto da criptografia e especificamente na Lightning Network, o termo "preimage" se
refere à entrada de uma função hash que produz uma hash específica. Não é viável calcular o
preimage a partir da hash (as funções hash são unidirecionais). Ao selecionar um valor aleatório
secreto como preimage e calcular sua hash, podemos nos comprometer com esse preimage e
revelá-lo posteriormente. Qualquer pessoa pode confirmar se o preimage revelado produz
corretamente a hash correspondente.
Proof of Work (PoW)

Dados que exigem computação significativa para serem encontrados e podem ser facilmente
verificados por qualquer pessoa para provar a quantidade de trabalho necessária para produzi-
los. No Bitcoin, os mineradores devem encontrar uma solução numérica para o algoritmo SHA-
256 que atenda a uma meta de toda a rede, chamada de meta de dificuldade. Consulte Mineração
de Bitcoin para obter mais informações.
Point Time-Locked Contract (PTLC)

Um Point Time-Locked Contract (PTLC) é um script Bitcoin que permite um gasto condicional na
apresentação de um segredo ou após a passagem de um determinado blockheight (altura de
bloco), semelhante a um HTLC. Ao contrário dos HTLCs, os PTLCs não dependem de uma pré-
imagem de uma função hash, mas sim da chave privada de um ponto de curva elíptica. A
suposição de segurança é, portanto, baseada no logaritmo discreto. Os PTLCs ainda não estão
implementados na Lightning Network.
relative timelock
Um bloqueio temporal relativo é um tipo de bloqueio temporal que permite que uma entrada
especifique o tempo mais anterior em que a entrada pode ser adicionada a um bloco. O tempo é
relativo e baseia-se no momento em que a saída referenciada por essa entrada foi registrada em
um bloco. Os bloqueios temporais relativos são definidos pelo campo de transação nSequence e
pelo opcode CHECKSEQUENCEVERIFY (CSV) do Bitcoin Script, que foi introduzido pelo BIP-
68/112/113.
Revocable Sequence Maturity Contract (RSMC)

Este contrato é usado para construir um canal de pagamento entre dois usuários de Bitcoin ou
LN que não precisam confiar um no outro. O nome vem de uma sequência de estados que são
codificados como transações de compromisso e podem ser revogados se publicados e minerados
indevidamente pela rede Bitcoin.
revocation key
Cada RSMC (Recoverable Sequence Maturity Contract) contém duas chaves de revogação. Cada
parceiro do canal conhece uma chave de revogação. Ao conhecer ambas as chaves de revogação,
a saída do RSMC pode ser gasta dentro do prazo definido. Durante a negociação de um novo
12
estado do canal, as chaves de revogação antigas são compartilhadas, revogando assim o estado
antigo. As chaves de revogação são usadas para desencorajar os parceiros do canal de transmitir
um estado antigo do canal.
RIPEMD-160
RIPEMD-160 é uma função hash criptográfica que produz um hash de 160 bits (20 bytes).
routing layer
A quarta camada do conjunto de protocolos Lightning Network opera sobre a camada ponto a
ponto (peer-to-peer). Sua responsabilidade é definir as primitivas criptográficas e o protocolo de
comunicação necessário para permitir o transporte seguro e atômico de bitcoins de um nó
remetente para um nó destinatário Enquanto o BOLT #4 define o formato da cebola (onion) que
é usado para comunicar informações de transporte para participantes remotos com os quais não
existem conexões diretas, o transporte real das cebolas e as primitivas criptográficas são
definidos no BOLT #2.
topology
A topologia da Lightning Network descreve a forma da Lightning Network como um grafo
matemático. Os nós do grafo são os nós da Lightning (participantes/receptores da rede). As
bordas do grafo são os canais de pagamento. A topologia da Lightning Network é transmitida
publicamente com a ajuda do protocolo gossip, com exceção dos canais não anunciados. Isso
significa que a Lightning Network pode ser significativamente maior do que o número
anunciado de canais e nós. Conhecer a topologia é de particular interesse no processo de
roteamento baseado em origem de pagamentos, no qual o remetente descobre uma rota.
satoshi
Um satoshi é a menor unidade (denominação) de bitcoin que pode ser registrada na blockchain.
Um satoshi equivale a 1/100 milionésimo (0,00000001) de um bitcoin e recebe o nome do criador
do Bitcoin, Satoshi Nakamoto.
Satoshi Nakamoto
Satoshi Nakamoto é o nome utilizado pela pessoa ou grupo de pessoas que projetaram o Bitcoin
e criaram sua implementação de referência original. Como parte da implementação, eles
também conceberam o primeiro banco de dados blockchain. No processo, eles foram os
primeiros a resolver o problema de gasto duplo para moedas digitais. Sua verdadeira identidade
permanece desconhecida.
Schnorr signature
Um novo esquema de assinatura digital que será ativado no Bitcoin em novembro de 2021. Ele
permite inovações na Lightning Network, como PTLCs (Payment Tokenized Lightning Network
Contract) eficientes—uma melhoria nos HTLCs (Hashed Time Lock Contracts).
script, Bitcoin Script

Bitcoin usa um sistema de script para transações chamado Bitcoin Script. Assemelhando-se à
linguagem de programação Forth, é simples, baseado em pilha (stack-based) e processado da
esquerda para a direita. É intencionalmente Turing-incompleto, sem loops ou recursão.
13
ScriptPubKey (aka pubkey script)
ScriptPubKey ou script pubkey, é um script incluído nas saídas que define as condições que
devem ser cumpridas para que essas saídas sejam gastas. Os dados para cumprir as condições
podem ser fornecidos em um script de assinatura. Consulte também ScriptSig.
ScriptSig (aka signature script)

ScriptSig ou script de assinatura são os dados gerados por um gastador, que quase sempre são
usados como variáveis para satisfazer um pubkey script.
secret key (chave privada)

O número secreto que desbloqueia bitcoin enviado para o endereço correspondente. Uma chave
privada se parece com isso:
5J76sF8L5jTtzE96r66Sf8cka9y44wdpJjMwCxR3tzLh3ibVPxh.
Segregated Witness (SegWit)

Segregated Witness (SegWit) é uma atualização do protocolo do Bitcoin introduzida em 2017 que
adiciona uma nova testemunha para assinaturas e outras provas de autorização de transações.
Este novo campo de testemunha é isento do cálculo do ID da transação, o que resolve a maioria
das classes de maleabilidade de transações por terceiros (transaction malleability). O Segregated
Witness foi implementado como um soft fork e é uma mudança que torna tecnicamente as
regras do protocolo do Bitcoin mais restritivas.
Secure Hash Algorithm (SHA)

O Secure Hash Algorithm (SHA) é uma família de funções criptográficas de hash publicadas pelo
National Institute of Standards and Technology (NIST). O protocolo do Bitcoin atualmente utiliza
o SHA-256, que produz um hash de 256 bits.
short channel ID (scid)

Uma vez que um canal é estabelecido, o índice da transação de financiamento na blockchain é
utilizado como o ID de canal curto para identificar de forma única o canal. O ID de canal curto
consiste em oito bytes referentes a três números. Em sua forma serializada, esses três números
são representados como valores decimais separados pela letra "x" (por exemplo, 600123x01x00).
O primeiro número (4 bytes) é a altura do bloco. O segundo número (2 bytes) é o índice da
transação de financiamento com os blocos. O último número (2 bytes) é a saída da transação.
verificação simplificada de pagamento (SPV)

SPV (Simplified Payment Verification) é um método para verificar se determinadas transações
foram incluídas em um bloco sem fazer o download o bloco inteiro. Esse método é utilizado por
algumas carteiras leves de Bitcoin e Lightning.
source-based routing
Na Lightning Network, o emissor de um pagamento decide a rota do pagamento. Embora isso
diminua a taxa de sucesso do processo de roteamento, aumenta a privacidade dos pagamentos.
Devido ao SPHINX Mix Format usado pelo roteamento de cebola, todos os nós de roteamento não
conhecem o originador de um pagamento ou o destinatário final. O roteamento baseado na
fonte (source-based routing) é fundamentalmente diferente de como o roteamento funciona no
Protocolo de Internet.
14
soft fork
Soft fork, ou alteração de soft fork, é uma atualização de protocolo que é compatível com versões
anteriores e posteriores, permitindo que nós antigos e novos continuem usando a mesma cadeia
de blocos.
SPHINX Mix Format

Uma técnica específica para roteamento de cebola usada na Lightning Network e inventada por
George Danezis e Ian Goldberg em 2009. Com o SPHINX Mix Format, cada mensagem do pacote
onion é preenchida com alguns dados aleatórios para que nenhum único salto (hop) possa
estimar a distância percorrida ao longo da rota. Embora a privacidade do emissor e do
destinatário do pagamento seja protegida, cada nó ainda pode retornar uma mensagem de erro
ao longo do caminho para o originador da mensagem.
submarine swap
Um submarine swap é uma troca atômica sem confiança entre endereços Bitcoin na cadeia (on-
chain) e pagamentos na rede Lightning Network fora da cadeia (off-chain). Assim como os
pagamentos na Lightning Network usam HTLCs (Hashed Time Lock Contracts) que condicionam
a reivindicação final dos fundos à revelação de um segredo (preimagem de hash), os submarine
swaps utilizam o mesmo mecanismo para transferir fundos através da barreira entre on-chain e
off-chain com confiança mínima. Os reverse submarine swaps permitem trocas na direção
oposta, de um pagamento off-chain na Lightning Network para um endereço Bitcoin na cadeia
(on-chain).
timelock
Um timelock é um tipo de restrição que impede o gasto de alguns bitcoins até um momento
futuro ou altura de bloco especificados. Timelocks são amplamente utilizados em muitos
contratos do Bitcoin, incluindo canais de pagamento e HTLCs (Hashed Time Lock Contracts).
transação
Transações são estruturas de dados usadas pelo Bitcoin para transferir bitcoin de um endereço
para outro. Vários milhares de transações são agregadas em um bloco, que é então registrado
(minerado) na blockchain. A primeira transação em cada bloco, chamada de transação coinbase,
gera um novos bitcoin.
transaction malleability
A maleabilidade da transação é uma propriedade na qual o hash de uma transação pode mudar
sem alterar a semântica da transação. Por exemplo, alterar a assinatura pode alterar o hash de
uma transação. Uma transação de compromisso (commitment transaction) precisa do hash de
uma transação de financiamento (funding transaction), e se o hash da transação de
financiamento for alterado, as transações que dependem dela se tornarão inválidas. Isso fará
com que os usuários não consigam reivindicar reembolsos, caso existam. O soft fork do
Segregated Witness (SegWit) aborda essa questão e, portanto, foi uma atualização importante
para suportar a Lightning Network.
camada de transporte
Em redes de computadores, a camada de transporte é uma divisão conceitual dos métodos
usados pelos computadores (e, em última instância, pelas aplicações) para se comunicarem
entre si. A camada de transporte fornece serviços de comunicação entre computadores, como
15
controle de fluxo, verificação e multiplexação (para permitir que várias aplicações funcionem
em um computador ao mesmo tempo).
unspent transaction output (UTXO)

Consulte output.
carteira
Uma carteira (wallet) é um software que guarda as chaves privadas do Bitcoin. Ela é usada para
criar e assinar transações do Bitcoin. No contexto da Lightning Network, ela também guarda
segredos de revogação do estado antigo do canal e as últimas transações de compromisso pré-
assinadas.
watchtower
Watchtowers são um serviço de segurança na Lightning Network que monitoram os canais de
pagamento em busca de possíveis violações do protocolo. Se um dos parceiros de canal ficar
offline ou perder o backup, essa torre de vigilância mantém os backups e pode restaurar as
informações do canal.
Os watchtowers também monitoram a blockchain do Bitcoin e podem enviar uma transação de

penalidade se um dos parceiros tentar "trapacear" ao transmitir um estado desatualizado. Os
watchtowers podem ser operados pelos próprios parceiros do canal ou como um serviço pago
oferecido por terceiros. Os watchtowers não têm controle sobre os fundos nos canais em si.
Algumas definições de contribuição foram obtidas sob uma licença CC-BY de Bitcoin Wiki,
Wikipedia, Mastering Bitcoin, ou de outras publicações de código aberto.
16
Prefácio
A Lightning Network (LN) é uma rede ponto a ponto de segunda camada que nos permite realizar
pagamentos com Bitcoin "off-chain", ou seja, sem registrá-los como transações na blockchain do
Bitcoin.
A Lightning Network (Rede Relâmpago) nos oferece pagamentos em Bitcoin seguros, baratos,
rápidos e muito mais privados, mesmo para pagamentos muito pequenos.
Baseando-se na ideia de canais de pagamento, inicialmente proposta pelo inventor do Bitcoin,

Satoshi Nakamoto, a Lightning Network é uma rede roteada de canais de pagamento, na qual os
pagamentos "saltam" por um caminho de canais de pagamento do remetente ao destinatário.
A ideia inicial da Lightning Network foi proposta em 2015 no artigo inovador intitulado "The
Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" (A Rede Lightning do Bitcoin:
Pagamentos instantâneos escaláveis fora da cadeia.), escrito por Joseph Poon e Thaddeus Dryja. Até
2017, uma versão de teste da Lightning Network já estava em funcionamento na internet, pois
diferentes grupos desenvolveram implementações compatíveis e coordenaram a definição de
alguns padrões de interoperabilidade. Em 2018, a Lightning Network foi oficialmente lançada e os
pagamentos começaram a ser realizados.
Em 2019, Andreas M. Antonopoulos, Olaoluwa Osuntokun e René Pickhardt concordaram em

colaborar para escrever este livro. Parece que fomos bem sucedidos!
Público-alvo
Este livro destina-se principalmente a leitores técnicos com uma compreensão dos fundamentos do
Bitcoin e outras blockchains abertas.
Convenções Usadas Neste livro

As seguintes convenções tipográficas são usadas neste livro:
Italic
Indica novos termos, URLs, endereços de e-mail, nomes de arquivo e extensões de arquivo.
Constant width
Usada para listagens de programas, assim como dentro de parágrafos para se referir a elementos
de programas, como nomes de variáveis ou funções, bancos de dados, tipos de dados, variáveis
de ambiente, declarações e palavras-chave.
Constant width bold

Exibe comandos ou outro texto que deve ser digitado literalmente pelo usuário.
Constant width italic

Mostra texto que deve ser substituído por valores fornecidos pelo usuário ou por valores
determinados pelo contexto.
1
Este elemento significa uma dica ou sugestão.
Este elemento significa uma nota geral.
Este elemento indica um aviso ou precaução.
Exemplos de Código
Os exemplos são ilustrados em Go, C++, Python e usando a linha de comando de um sistema
operacional semelhante ao Unix. Todos os trechos de código estão disponíveis no repositório do
GitHub, na subpasta "code". Faça um fork do código do livro, experimente os exemplos de código ou
envie correções através do seguinte link: GitHub.
Todos os trechos de código podem ser replicados na maioria dos sistemas operacionais com uma
instalação mínima de compiladores, interpretadores e bibliotecas para as respectivas linguagens.
Quando necessário, fornecemos instruções básicas de instalação e exemplos passo a passo da saída
dessas instruções.
Alguns trechos de código e saídas de código foram reformatados para impressão. Em todos esses
casos, as linhas foram divididas por um caractere de barra invertida (\), seguido por um caractere
de nova linha. Ao transcrever os exemplos, remova esses dois caracteres e junte as linhas
novamente, e você obterá resultados idênticos aos mostrados no exemplo.
Todos os trechos de código usam valores e cálculos reais sempre que possível, para que você possa
construir de exemplo em exemplo e obter os mesmos resultados em qualquer código que você
escreva para calcular os mesmos valores. Por exemplo, as chaves privadas, chaves públicas
correspondentes e endereços são todos reais.
Usando Exemplos de Código

Se você tiver uma pergunta técnica ou um problema usando os exemplos de código, envie um e-
mail para bookquestions@oreilly.com .
Este livro está aqui para ajudá-lo a concluir seu trabalho. Em geral, se houver código de exemplo
oferecido com este livro, você pode usá-lo em seus programas e documentação. Não é necessário
entrar em contato conosco para obter permissão, a menos que você esteja reproduzindo uma parte
significativa do código. Por exemplo, escrever um programa que usa vários trechos de código deste
livro não requer permissão. Vender ou distribuir exemplos de livros da O’Reilly requer permissão.
Responder a uma pergunta citando este livro e citando código de exemplo não requer permissão.
Incorporar uma quantidade significativa de código de exemplo deste livro na documentação do seu
produto requer permissão.
Agradecemos, mas não exigimos, atribuição. Uma atribuição geralmente inclui o título, autor,
editora, ISBN e direitos autorais. Por exemplo: “Mastering the Lightning Network by Andreas M.
2
Antonopoulos, Olaoluwa Osuntokun, and René Pickhardt (O’Reilly). Copyright 2022 aantonop Books
LLC, René Pickhardt, and uuddlrlrbas LLC, ISBN 978-1-492-05486-3."
Mastering the Lightning Network é oferecido sob a Licença Atribuição-NãoComercial-

SemDerivações 4.0 Internacional (CC BY-NC-ND 4.0).
Se você acha que seu uso de exemplos de código está fora do uso justo ou da permissão dada
anteriormente, sinta-se à vontade para nos contatar em permissions@oreilly.com .
Referências a Empresas e Produtos

Todas as referências a empresas e produtos destinam-se a fins educacionais, de demonstração e de
referência. Os autores não endossam nenhuma das empresas pass: [ ou produtos ] mencionados. Não testamos a operação ou a segurança de nenhum
dos produtos, projetos ou segmentos de código mostrados neste livro. Use-os por sua conta e risco!
Endereços e Transações Neste Livro

Os endereços de Bitcoin, transações, chaves, códigos QR e dados de blockchain utilizados neste livro
são, em sua maioria, reais. Isso significa que você pode navegar pela blockchain, examinar as
transações oferecidas como exemplos, recuperá-las com seus próprios scripts ou programas, etc.
No entanto, observe que as chaves privadas usadas para construir os endereços impressos neste
livro foram "queimadas". Isso significa que, se você enviar dinheiro para qualquer um desses
endereços, o dinheiro será perdido para sempre ou (mais provavelmente) apropriado, pois
qualquer pessoa que ler o livro poderá pegá-lo usando as chaves privadas impressas aqui.
NÃO ENVIE DINHEIRO PARA NENHUM DOS ENDEREÇOS DESTE LIVRO. Seu dinheiro será
retirado por outro leitor ou perdido para sempre.
O’Reilly Online Learning
Por mais de 40 anos, O'Reilly Media tem fornecido treinamento em tecnologia e negócios,
conhecimento, e insights para ajudar as empresas a serem bem-sucedidas.
Nossa rede exclusiva de especialistas e inovadores compartilha seu conhecimento e expertise por
meio de livros, artigos e nossa plataforma de aprendizado online. A plataforma de aprendizado
online da O’Reilly oferece acesso sob demanda a cursos de treinamento ao vivo, trajetórias de
aprendizado aprofundadas, ambientes de codificação interativos e uma vasta coleção de texto e
vídeo da O’Reilly e mais de 200 outras editoras. Para mais informações, visite http://oreilly.com .
Como Nos Contatar

Informações sobre Mastering the Lightning Network, bem como a Open Edition e as traduções estão
disponíveis no https://lnbook.info.
3
Por favor, dirija comentários e perguntas relacionadas a este livro para o editor:
<ul class="simplelist">
<li>O’Reilly Media, Inc.</li>
<li>1005 Gravenstein Highway North</li>
<li>Sebastopol, CA 95472</li>
<li>800-998-9938 (in the United States or Canada)</li>
<li>707-829-0515 (internacional ou local)</li>
<li>707-829-0104 (fax)</li>
</ul>
Escreva para bookquestions@oreilly.com para comentários ou perguntas técnicas sobre este livro.
Para notícias e informações sobre nossos livros e cursos, visite o http://oreilly.com.
Encontre-nos no Facebook: http://facebook.com/oreilly
Siga-nos no Twitter: http://twitter.com/oreillymedia
Assista-nos no YouTube: http://www.youtube.com/oreillymedia
Entrando em Contato com Andreas
Você pode entrar em contato com Andreas M. Antonopoulos em seu site pessoal:
https://aantonop.com
Inscreva-se no canal do Andreas no YouTube: https://www.youtube.com/aantonop
Curta a página do Andreas no Facebook: https://www.facebook.com/AndreasMAntonopoulos
Siga Andreas no Twitter: https://twitter.com/aantonop
Conecte-se com Andreas no LinkedIn: https://linkedin.com/company/aantonop
Andreas também gostaria de agradecer aos patrocinadores que apoiam seu trabalho por meio de
doações mensais. Você pode apoiar Andreas no Patreon pelo https://patreon.com/aantonop.
Entrando em Contato com René
Você pode entrar em contato com René Pickhardt por meio de seu site pessoal: https://ln.rene-
pickhardt.de
Inscreva-se no canal do René no YouTube: https://www.youtube.com/user/RenePickhardt
Siga René no Twitter: https://twitter.com/renepickhardt
Conecte-se com René no LinkedIn: https://www.linkedin.com/in/rene-pickhardt-80313744
René também gostaria de agradecer a todos os patrocinadores que apoiam seu trabalho por meio
de doações mensais. Você pode apoiar René no Patreon no https://patreon.com/renepickhardt.
Ou você pode apoiar o trabalho dele diretamente com Bitcoin (também através da Lightning
4
Network) no https://donate.ln.rene-pickhardt.de pelo qual René é igualmente grato.
Entrando em Contato com Olaoluwa Osuntokun
Você pode entrar em contato com Olaoluwa Osuntokun por meio de seu endereço de e-mail
profissional: laolu@lightning.engineering
Siga Olaoluwa no Twitter: https://twitter.com/roasbeef
Agradecimentos de Andreas
Devo meu amor pelas palavras e pelos livros à minha mãe, Theresa, que me criou em uma casa com
livros revestindo todas as paredes. Minha mãe também comprou meu primeiro computador em
1982, apesar de se autodescrever como tecnófoba. Meu pai, Menelaos, um engenheiro civil que
publicou seu primeiro livro aos 80 anos, foi quem me ensinou o pensamento lógico e analítico e o
amor pela ciência e pela engenharia.
Obrigado a todos por me apoiarem ao longo desta jornada.
Agradecimentos de René
Quero agradecer ao sistema educacional alemão por meio do qual adquiri o conhecimento sobre o
qual meu trabalho se baseia. É um dos maiores presentes que recebi. Da mesma forma, quero
agradecer ao sistema de saúde pública alemão e a cada pessoa que dedica seu tempo trabalhando
nessa indústria. Seu esforço e resistência os tornam meus heróis pessoais, e nunca esquecerei a
ajuda, paciência e apoio que recebi quando estava precisando. Agradeço a todos os estudantes que
me permitiram ensinar e que participaram de discussões e perguntas interessantes. Foi com vocês
que aprendi mais. Também sou grato à comunidade Bitcoin e Lightning Network que me acolheu
calorosamente e aos entusiastas e pessoas físicas que apoiaram financeiramente e continuam a
apoiar meu trabalho. Em particular, sou grato a todos os desenvolvedores de código aberto (não
apenas do Bitcoin e da Lightning Network) e às pessoas que os financiam para tornar essa
tecnologia possível. Um agradecimento especial vai para meus coautores por me acompanharem
durante a tempestade. Por último, mas não menos importante, sou grato aos meus entes queridos.
Agradecimentos de Olaoluwa Osuntokun

Gostaria de agradecer à incrível equipe do Lightning Labs, pois sem vocês, não não haveria LND.
Também gostaria de agradecer ao conjunto original de autores da especificação BOLT: Rusty
Russell, Fabrice Drouin, Conner Fromnkchet, Pierre-Marie Padiou, Lisa Neigut e Christian Decker.
Por último, mas não menos importante, gostaria de agradecer a Joseph Poon e Tadge Dryja, os
autores do artigo original sobre a Lightning Network, pois sem eles não existiria uma Rede
Lightning para escrevermos um livro sobre.
Contribuições
Muitos colaboradores ofereceram comentários, correções e adições ao livro enquanto ele era
escrito de forma colaborativa no GitHub.
5
A seguir está uma lista em ordem alfabética de todos os contribuidores do GitHub, incluindo seus
IDs do GitHub entre parênteses:
• 8go (@8go)
• Aaqil Aziz (@batmanscode)
• Alexander Gnip (@quantumcthulhu)
• Alpha Q. Smith (@alpha_github_id)
• Ben Skee (@benskee)
• Brian L. McMichael (@brianmcmichael)
• CandleHater (@CandleHater)
• Daniel Gockel (@dancodery)
• Dapeng Li (@luislee818)
• Darius E. Parvin (@DariusParvin)
• Doru Muntean (@chriton)
• Eduardo Lima III (@elima-iii)
• Emilio Norrmann (@enorrmann)
• Francisco Calderón (@grunch)
• Francisco Requena (@FrankyFFV)
• François Degros (@fdegros)
• Giovanni Zotta (@GiovanniZotta)
• Gustavo Silva (@GustavoRSSilva)
• Guy Thayakorn (@saguywalker)
• Haoyu Lin (@HAOYUatHZ)
• Hatim Boufnichel (@boufni95)
• Imran Lorgat (@ImranLorgat)
• Jeffrey McLarty (@jnmclarty)
• John Davies (@tigeryant)
• Julien Wendling (@trigger67)
• Jussi Tiira (@juhi24)
• Kory Newton (@korynewton)
• Lawrence Webber (@lwebbz)
• Luigi (@gin)
• Maximilian Karasz (@mknoszlig)
• Omega X. Last (@omega_github_id)
• Owen Gunden (@ogunden)
• Patrick Lemke (@PatrickLemke)
6
• Paul Wackerow (@wackerow)
• Randy McMillan (@RandyMcMillan)
• René Köhnke (@rene78)
• Ricardo Marques (@RicardoM17)
• Sebastian Falbesoner (@theStack)
• Sergei Tikhomirov (@s-tikhomirov)
• Severin Alexander Bühler (@SeverinAlexB)
• Simone Bovi (@SimoneBovi)
• Srijan Bhushan (@srijanb)
• Taylor Masterson (@tjmasterson)
• Umar Bolatov (@bolatovumar)
• Warren Wan (@wlwanpan)
• Yibin Zhang (@z4y1b2)
• Zachary Haddenham (@senf42)
Sem a ajuda oferecida por todos os listados aqui, este livro não teria sido possível. Suas
contribuições demonstram o poder do código aberto e da cultura aberta, e somos eternamente
gratos por sua ajuda.
Obrigado.
Fontes
Parte do material deste livro foi obtido de uma variedade de fontes de domínio público, fontes de
licença aberta ou com permissão. Veja [sources_licenses] para fontes, licenças, e detalhes de
atribuição.
7
Appendix A: Revisão dos Fundamentos do
Bitcoin
A Lightning Network é capaz de operar em várias blockchains, mas está principalmente ancorada
no Bitcoin. Para entender a Lightning Network, é necessário ter um entendimento fundamental do
Bitcoin e de seus blocos de construção.
Existem muitos bons recursos que você pode usar para aprender mais sobre Bitcoin, incluindo o
livro Mastering Bitcoin, 2nd Edition, by Andreas M. Antonopoulos, que você pode encontrar no
GitHub em an licença open source. No entanto, você não precisa ler um outro livro inteiro para
estar pronto para este!
Neste capítulo, reunimos os conceitos mais importantes que você precisa saber sobre o Bitcoin e os
explicamos no contexto da Lightning Network. Dessa forma, você pode aprender exatamente o que
precisa saber para compreender a Lightning Network sem distrações.
Este capítulo cobre vários conceitos importantes do Bitcoin, incluindo:
• Chaves e assinaturas digitais
• Funções Hash
• Transações de Bitcoin e sua estrutura
• Encadeamento de transações Bitcoin
• Outpoints de transação do Bitcoin
• Bitcoin Script: locking e unlocking scripts
• Scripts de bloqueio (locking) básicos
• Scripts de bloqueio complexos e condicionais
• Timelocks
Chaves e Assinaturas Digitais

Você pode ter ouvido falar que o bitcoin é baseado em criptografia, que é um ramo da matemática
usado amplamente em segurança computacional. A criptografia também pode ser usada para
provar o conhecimento de um segredo sem revelar esse segredo (assinatura digital) ou provar a
autenticidade de dados (impressão digital digital). Esses tipos de provas criptográficas são as
ferramentas matemáticas fundamentais para o Bitcoin e são amplamente utilizadas em aplicações
de Bitcoin.
A propriedade do bitcoin é estabelecida por meio de chaves digitais, endereços de bitcoin e

assinaturas digitais. As chaves digitais não são realmente armazenadas na rede, mas são criadas e
armazenadas pelos usuários em um arquivo ou banco de dados simples, chamado carteira (wallet).
As chaves digitais na carteira de um usuário são completamente independentes do protocolo
Bitcoin e podem ser geradas e gerenciadas pelo software de carteira do usuário sem referência à
blockchain ou acesso à internet.
1
A maioria das transações de Bitcoin requer uma assinatura digital válida para ser incluída no
blockchain, que só pode ser gerada com uma chave secreta; portanto, qualquer pessoa que possua
uma cópia dessa chave tem controle sobre o bitcoin. A assinatura digital usada para gastar fundos
também é chamada de testemunha (witness), um termo usado em criptografia. Os dados da
testemunha em uma transação de bitcoin atestam a verdadeira propriedade dos fundos sendo
gastos. As chaves são compostas por pares, consistindo de uma chave privada (secreta) e uma chave
pública. Pode-se pensar na chave pública como semelhante a um número de conta bancária e na
chave privada como semelhante a um PIN secreto.
Chaves Privadas e Públicas
Uma chave privada é simplesmente um número escolhido aleatoriamente. Na prática, e para

facilitar o gerenciamento de muitas chaves, a maioria das carteiras de Bitcoin gera uma sequência
de chaves privadas a partir de uma única semente (seed) aleatória usando um algoritmo de
derivação determinística. Em termos simples, um único número aleatório é usado para produzir
uma sequência repetível de números aparentemente aleatórios que são usados como chaves
privadas. Isso permite que os usuários façam backup apenas da semente e sejam capazes de derivar
todas as chaves necessárias a partir dessa semente.
Bitcoin, assim como muitas outras criptomoedas e blockchains, usa curvas elípticas para
segurança.No Bitcoin, a multiplicação de curvas elípticas na curva elíptica secp256k1 é usada como
umafunção unidirecional. Simplificando, a natureza da matemática de curvas elípticas torna trivial
calcular a multiplicação escalar de um ponto, mas impossível calcular a inversa (divisão ou
logaritmo discreto).
Cada chave privada tem uma chave pública correspondente, que é calculada a partir da chave
privada usando a multiplicação escalar na curva elíptica. Em termos simples, com uma chave
privada k, podemos multiplicá-la por uma constante G para produzir uma chave pública K:
<li>K = k*G</li>
</ul>
É impossível reverter esse cálculo. Dada uma chave pública K, não é possível calcular a chave
privada k. A divisão por G não é possível na matemática de curvas elípticas. Em vez disso, seria
necessário tentar todos os valores possíveis de k em um processo exaustivo chamado de ataque de
força bruta. Como k é um número de 256 bits, esgotar todos os valores possíveis com qualquer
computador clássico exigiria mais tempo e energia do que está disponível neste universo.
Hashes
Outra ferramenta importante usada extensivamente no Bitcoin e na Lightning Network são as

funções de hash criptográficas, especificamente a função de hash SHA-256.
Uma função de hash, também conhecida como função de resumo, é uma função que recebe dados
de comprimento arbitrário e os transforma em um resultado de comprimento fixo, chamado de
hash, resumo ou impressão digital(consulte O algoritmo de hash criptográfico SHA-256). É
importante ressaltar que as funções de hash são funções unidirecionais, o que significa que você
não pode revertê-las e calcular os dados de entrada a partir da impressão digital.
2
Figure 1. O algoritmo de hash criptográfico SHA-256
Por exemplo, se usarmos um terminal de linha de comando para inserir o texto "Dominando a
Lightning Network" na função SHA-256, ela produzirá uma impressão digital da seguinte forma:
$ echo -n "Mastering the Lightning Network" | shasum -a 256
ce86e4cd423d80d054b387aca23c02f5fc53b14be4f8d3ef14c089422b2235de -
O input usado para calcular o hash também é chamado de pré-imagem.
O comprimento da entrada pode ser muito maior, é claro. Vamos tentar a mesma coisa com o PDF
do Bitcoin whitepaper de Satoshi Nakamoto:
$ wget http://bitcoin.org/bitcoin.pdf
$ cat bitcoin.pdf | shasum -a 256
b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553 -
3
Embora leve mais tempo do que uma única frase, a função SHA-256 processa o PDF de 9 páginas,
"digerindo-o" em uma impressão digital de 256 bits.
Neste ponto, você pode estar se perguntando como é possível que uma função que digere dados de
tamanho ilimitado possa produzir uma impressão digital única que é um número de tamanho fixo.
Em teoria, como há um número infinito de pré-imagens possíveis (inputs) e apenas um número

finito de impressões digitais, deve haver muitas pré-imagens que produzem a mesma impressão
digital de 256 bits.Quando duas pré-imagens produzem o mesmo hash, isso é conhecido como uma
colisão.
Na prática, um número de 256 bits é tão grande que você nunca encontrará uma colisão
intencionalmente. As funções de hash criptográficas funcionam com base no fato de que uma busca
por uma colisão é um esforço de força bruta que requer tanta energia e tempo que não é
praticamente possível.
As funções hash criptográficas são amplamente usadas em uma variedade de aplicativos porque
possuem alguns recursos úteis. Elas são:
Determinísticas
O mesmo input sempre produz o mesmo hash.
Irreversíveis
Não é possível calcular a pré-imagem de um hash.
À prova de colisão
É computacionalmente inviável encontrar duas mensagens que tenham o mesmo hash.
Descorrelacionadas: Uma pequena alteração na entrada produz uma mudança tão grande na saída
que a saída parece não estar correlacionada com a entrada.
Uniformes/aleatórias
Uma função hash criptográfica produz hashes que são distribuídos uniformemente por todo o
espaço de 256 bits de saídas possíveis. A saída de um hash parece ser aleatória, embora não seja
verdadeiramente aleatória.
Usando essas características de hashes criptográficos, podemos construir algumas aplicações:

interessantes.
Impressões digitais: Um hash pode ser usado para atribuir uma impressão digital única a um
arquivo ou mensagem, de forma que possa ser identificado de maneira única. Hashes podem ser
usados como identificadores universais para qualquer conjunto de dados.
Prova de integridade: Uma impressão digital de um arquivo ou mensagem demonstra sua

integridade, pois o arquivo ou mensagem não pode ser adulterado ou modificado de nenhuma
maneira sem alterar a impressão digital. Isso é frequentemente usado para garantir que o software
não tenha sido adulterado antes de instalá-lo em seu computador.
Comprometimento/não repúdio: Você pode se comprometer com uma pré-imagem específica (por
exemplo, um número ou mensagem) sem revelá-la, publicando seu hash. Posteriormente, você
4
pode revelar o segredo, e todos podem verificar que é a mesma coisa com a qual você se
comprometeu anteriormente, pois produz o hash publicado.
Proof-of-work/hash grinding: Prova de trabalho. Você pode usar um hash para provar que realizou
trabalho computacional mostrando um padrão não aleatório no hash, que só pode ser produzido
por suposições repetidas de uma pré-imagem. Por exemplo, o hash do cabeçalho de um bloco de
Bitcoin começa com muitos bits zero. A única maneira de produzi-lo é alterar uma parte do
cabeçalho e calcular o hash trilhões de vezes até que ele produza esse padrão por acaso.
Atomicidade: Você pode fazer com que uma pré-imagem secreta seja um pré-requisito para gastar
fundos em várias transações vinculadas. Se qualquer uma das partes revelar a pré-imagem para
gastar uma das transações, todas as outras partes também poderão gastar suas transações. Todas ou
nenhuma se tornam gastáveis, alcançando atomicidade em várias transações.
Assinaturas Digitais
A chave privada é usada para criar assinaturas que são necessárias para gastar bitcoins, provando
a propriedade dos fundos usados em uma transação.
Uma assinatura digital é um número calculado a partir da aplicação da chave privada a uma
mensagem específica.
Dada uma mensagem m e uma chave privada k, uma função de assinatura Fsign pode produzir uma
assinatura S:
$ S = F_{sign}(m, k) $
Esta assinatura S pode ser verificada independentemente por qualquer pessoa que tenha a chave
pública K (correspondente à chave privada k) e a mensagem:
$ F_{verify}(m, K, S) $
Se Fverify retornar um resultado verdadeiro, então o verificador pode confirmar que a mensagem m
foi assinada por alguém que teve acesso à chave privada k. É importante ressaltar que a assinatura
digital comprova a posse da chave privada k no momento da assinatura, sem revelar k.
As assinaturas digitais utilizam um algoritmo de hash criptográfico. A assinatura é aplicada a um

hash da mensagem, de modo que a mensagem m seja "resumida" para um hash de comprimento
fixo H(m) que funciona como uma impressão digital.
Ao aplicar a assinatura digital no hash de uma transação, a assinatura não apenas comprova a
autorização, mas também trava (locks) os dados da transação, garantindo sua integridade. Uma
transação assinada não pode ser modificada, pois qualquer alteração resultaria em um hash
diferente e invalidaria a assinatura.
5
Tipos de Assinatura
As assinaturas nem sempre são aplicadas em toda a transação. Para fornecer flexibilidade na
assinatura, uma assinatura digital do Bitcoin contém um prefixo chamado de tipo de hash da
assinatura, que especifica qual parte dos dados da transação é incluída no hash. Isso permite que a
assinatura comprometa ou "trave" (lock) todos, ou apenas alguns, dos dados na transação. O tipo de
hash de assinatura mais comum é SIGHASH_ALL, que bloqueia tudo na transação ao incluir todos
os dados da transação no hash que é assinado. Em comparação, SIGHASH_SINGLE bloqueia todas as
entradas da transação, mas apenas uma saída (mais sobre entradas—inputs e saídas—outputs na
próxima seção). Diferentes tipos de hash de assinatura podem ser combinados para produzir seis
"padrões" diferentes de dados da transação que são bloqueados pela assinatura.
Mais informações sobre os tipos de hash de assinatura podem ser encontradas em the section
"Signature Hash Types" in Chapter 6 of Mastering Bitcoin, Second Edition.
Transações Bitcoin
Transações são estruturas de dados que codificam a transferência de valor entre os participantes do
sistema Bitcoin.
Inputs e Outputs
O elemento fundamental de uma transação de Bitcoin é uma saída de transação—transaction

output).As saídas de transação ou outputs de transação são porções indivisíveis da moeda bitcoin,
registradas na blockchain e reconhecidas como válidas por toda a rede. Uma transação gasta
entradas (inputs) e cria saídas (outputs).Os inputs de transação são simplesmente referências aos
outputs de transações previamente registradas. Dessa forma, cada transação gasta os outputs de
transações anteriores e cria novos outputs. (see A transaction transfers value from inputs to
outputs).
Figure 2. A transaction transfers value from inputs to outputs
Os nós completos do Bitcoin rastreiam todas as saídas disponíveis e gastáveis, conhecidas como
Unspent Transaction Outputs (UTXOs). A coleção de todos os UTXOs é conhecida como o conjunto
UTXO, que atualmente possui milhões de UTXOs. O conjunto UTXO cresce à medida que novos
UTXOs são criados e diminui quando os UTXOs são consumidos. Cada transação representa uma
alteração (transição de estado) no conjunto UTXO, consumindo um ou mais UTXOs como inputs de
transação e criando um ou mais UTXOs como seus outputs de transação.
Por exemplo, vamos supor que a usuária Alice possui um UTXO de 100.000 satoshis que ela pode
gastar. Alice pode pagar a Bob 100.000 satoshis construindo uma transação com um input
6
(consumindo sua entrada existente de 100.000 satoshis) e uma output que "paga" Bob com 100.000
satoshis. Agora Bob possui um UTXO de 100.000 satoshis que ele pode gastar, criando uma nova
transação que consome esse novo UTXO e o gasta para outro UTXO como pagamento a outro
usuário, e assim por diante (veja Alice pays 100,000 satoshis to Bob).
Figure 3. Alice pays 100,000 satoshis to Bob
Um output de transação pode ter um valor arbitrário (inteiro) denominado em satoshis. Assim
como os dólares podem ser divididos em duas casas decimais, conhecidas como centavos, o bitcoin
pode ser dividido em oito casas decimais, denominadas satoshis. Embora um output possa ter
qualquer valor arbitrário, uma vez criado, ele é indivisível. Essa é uma característica importante
dos outputs que precisa ser enfatizada: as saídas são unidades discretas e indivisíveis de valor,
denominadas em satoshis inteiros. Um output não gasto só pode ser consumido integralmente por
uma transação.
Nesse caso, se Alice deseja pagar a Bob 50.000 satoshis, mas possui apenas um UTXO indivisível de
100.000 satoshis, Alice precisará criar uma transação que consuma (como entrada) o UTXO de
100.000 satoshis e tenha duas saídas: uma que pague 50.000 satoshis para Bob e outra que pague
50.000 satoshis de volta para Alice como "troco" (veja Alice paga 50.000 sat para Bob e 50.000 sat
para si mesma como troco).
Figure 4. Alice paga 50.000 sat para Bob e 50.000 sat para si mesma como troco
Não há nada de especial em uma saída de troco (change output) ou qualquer maneira de
distingui-la de qualquer outro output. Ela não precisa ser a última saída. Pode haver mais de
uma saída de troco, ou nenhuma saída de troco. Apenas o criador da transação sabe quais
outputs são destinados a outras pessoas e quais outputs são destinados a endereços de sua
propriedade e, portanto, são "troco".
Da mesma forma, se Alice quiser pagar a Bob 85.000 satoshis, mas tiver duas UTXOs (Unspent
7
Transaction Outputs) de 50.000 satoshis disponíveis, ela precisará criar uma transação com duas
entradas (consumindo ambas as suas UTXOs de 50.000 satoshis) e duas saídas, pagando 85.000
satoshis a Bob e enviando 15.000 satoshis de volta para si mesma como troco. (veja Alice usa duas
entradas de 50.000 para pagar 85.000 sat para Bob e 15.000 sat para si mesma como troco).
Figure 5. Alice usa duas entradas de 50.000 para pagar 85.000 sat para Bob e 15.000 sat para si mesma
como troco
As ilustrações e exemplos anteriores mostram como uma transação de Bitcoin combina (gasta) uma
ou mais entradas e cria uma ou mais saídas. Uma transação pode ter centenas ou até milhares de
entradas e saídas.
Enquanto as transações criadas pela Lightning Network têm várias saídas, elas não possuem
um "troco" propriamente dito, porque o saldo total disponível em um canal é dividido entre os
dois parceiros do canal.
Cadeias de Transação
Cada saída pode ser gasta como entrada em uma transação subsequente. Portanto, por exemplo, se
Bob decidir gastar 10.000 satoshis em uma transação para pagar a Chan, e a Chan gastar 4.000
satoshis para pagar a Dina, isso seria demonstrado como mostrado em Alice paga Bob que paga
Chan que paga Dina.
Um output é considerado spent (gasto) se for referenciado como um input em outra transação
registrada na blockchain. Um output é considerado unspent (e disponível para gastos) se nenhuma
transação registrada fizer referência a ele.
O único tipo de transação que não possui inputs é uma transação especial criada por mineradores
de Bitcoin chamada coinbase transaction. A transação coinbase tem apenas outputs (saídas) e
nenhuma entrada porque cria novos bitcoins a partir da mineração. Todas as outras transações
gastam uma ou mais saídas previamente registradas como suas entradas.
Uma vez que as transações são encadeadas, se você escolher uma transação aleatoriamente, você
pode seguir qualquer um dos seus inputs de volta até a transação anterior que a criou. Se você
continuar fazendo isso, eventualmente chegará a uma transação de coinbase onde o bitcoin foi
minerado pela primeira vez.
8
Figure 6. Alice paga Bob que paga Chan que paga Dina
TxID: Transaction Identifiers (IDs de Transação)
Cada transação no sistema Bitcoin é identificada por um identificador único (assumindo a

existência do BIP-0030), chamado de transaction ID ou TxID abreviado. Para produzir um
identificador único, utilizamos a função hash criptográfica SHA-256 para gerar um hash dos dados
da transação. Essa "impressão digital" serve como um identificador universal. Uma transação pode
ser referenciada pelo seu TxID e, uma vez que uma transação é registrada na blockchain do Bitcoin,
todos os nós na rede Bitcoin sabem que essa transação é válida.
Por exemplo, um ID de transação pode se parecer com isto:
Um ID de transação produzido a partir do hash dos dados da transação
e31e4e214c3f436937c74b8663b3ca58f7ad5b3fce7783eb84fd9a5ee5b9a54c
Esta é uma transação real (criada como exemplo para o livro Dominando Bitcoin) que pode ser
encontrada na blockchain do Bitcoin. Tente encontrá-lo inserindo este TxID em um block explorer
(explorador de blocos):
<li><a
href="https://blockstream.info/tx/e31e4e214c3f436937c74b8663b3ca58f7ad5b3fce7783eb84fd9a5e
e5b9a54c">https://blockstream.info/tx/e31e4e214c3f436937c74b8663b3ca58f7ad5b3fce7783eb
84fd9a5ee5b9a54c</a></li></ul>
9
ou use o link curto (case sensitive):
<li><a href="http://bit.ly/AliceTx">http://bit.ly/AliceTx</a></li>
</ul>
Outpoints: Output Identifiers (Identificadores de Saídas)
Como cada transação tem um ID único, também podemos identificar unicamente uma saída de
transação dentro daquela transação por referência ao TxID e ao número do índice de saída (output
index number). A primeira saída em uma transação é o índice de saída 0, a segunda saída é o índice
de saída 1, e assim por diante. Um identificador de saída é comumente conhecido como outpoint.
Por convenção, escrevemos um outpoint como o TxID, seguido de dois pontos (":") e o número do
índice de saída—output index number.
Um outpoint: identificando uma saída por TxID e número de índice
7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18:0
Identificadores de saída (outpoints) são os mecanismos que conectam as transações em uma cadeia.
Cada transaction input é uma referência a uma saída específica de uma transação anterior. Essa
referência é um outpoint: um TxID e um número de índice de saída. Portanto, uma transação
"gasta" uma saída específica (por número de índice) de uma transação específica (por TxID) para
criar novas saídas que podem ser gastas por referência ao outpoint.
Entradas de transação referem-se a pontos de saída formando uma corrente mostra a cadeia de
transações de Alice para Bob, para Chan, para Dina, desta vez com outpoints em cada uma das
entradas.
10
Figure 7. Entradas de transação referem-se a pontos de saída formando uma corrente
O input na transação de Bob faz referência à transação de Alice (pelo TxID) e do input com index 0.
O input na transação de Chan faz referência ao TxID da transação de Bob e o primeiro output
indexado , porque o pagamento para o output de Chan é #1. No pagamento de Bob para Chan, o
[1]
"troco" de Bob é o output #0.
Agora, se observarmos o pagamento de Alice para Bob, podemos ver que Alice está gastando um
outpoint que era o terceiro (output index #2) na transação cujo ID é 6a5f1b3[…]. Não vemos essa
transação referenciada no diagrama, mas podemos deduzir esses detalhes a partir do outpoint.
Bitcoin Script
O elemento final do Bitcoin necessário para completar nosso entendimento é a linguagem de script
que controla o acesso aos outpoints. Até agora, simplificamos a descrição dizendo "Alice assina a
transação para pagar Bob". No entanto, nos bastidores, há uma complexidade oculta que torna
possível implementar condições de gastos mais complexas. A condição de gasto mais simples e
comum é "apresentar uma assinatura que corresponda à seguinte chave pública". Uma condição de
gasto como essa é registrada em cada saída como um locking script escrito em uma linguagem de
script chamada Bitcoin Script.
Bitcoin Script é uma linguagem de script extremamente simples baseada em pilha (stack-based
scripting language). Ela não contém loops ou recursão e, portanto, é Turing incompleta (o que
significa que não pode expressar complexidade arbitrária e possui execução previsível). Aqueles
familiarizados com a (agora antiga) linguagem de programação FORTH reconhecerão a sintaxe e o
11
estilo.
Executando um Bitcoin Script
Em termos simples, o sistema Bitcoin avalia o Bitcoin Script executando o script em uma pilha
(stack); se o resultado final for TRUE (verdadeiro), o script considera a condição de gasto satisfeita e
a transação válida.
Vamos analisar um exemplo muito simples de Bitcoin Script, que adiciona os números 2 e 3 e, em
seguida, compara o resultado com o número 5:
2 3 ADD 5 EQUAL
Em Exemplo de execução do Bitcoin Script, nós vemos como este script é executado (da esquerda
para a direita).
12
Figure 8. Exemplo de execução do Bitcoin Script
Scripts de Bloqueio (Locking) e Desbloqueio (Unlocking)
Bitcoin Script é composto por duas partes:
13
Scripts de bloqueio
Os locking scripts são integrados nos outputs de transação, definindo as condições que devem
ser cumpridas para o gasto do output. Por exemplo, a carteira de Alice adiciona um script de
bloqueio ao output que paga Bob, estabelecendo a condição de que a assinatura de Bob é
necessária para gastá-lo.
Scripts de desbloqueio
Os unlocking scripts são integrados aos inputs de transação, cumprindo as condições
estabelecidas pelo locking script do output referenciado. Por exemplo, Bob pode desbloquear o
output anterior fornecendo um script de desbloqueio contendo uma assinatura digital.
Usando um modelo simplificado, para validação, o script de desbloqueio e o script de bloqueio são
concatenados e executados (P2SH e SegWit são exceções). Por exemplo, se alguém bloqueou um
output de transação com o script de bloqueio "3 ADD 5 EQUAL", poderíamos gastá-la com o script de
desbloqueio "2" em uma entrada de transação. Qualquer pessoa que valide essa transação irá
concatenar nosso script de desbloqueio (2) e o script de bloqueio (3 ADD 5 EQUAL) e executar o
resultado através do mecanismo de execução do Bitcoin Script. Eles obteriam TRUE e nós seríamos
capazes de gastar a saída.
Obviamente, esse exemplo simplificado seria uma péssima escolha para bloquear um output real
de Bitcoin, pois não há segredo, apenas aritmética básica. Qualquer pessoa poderia gastar o output
fornecendo a resposta "2". Portanto, a maioria dos scripts de bloqueio requer demonstração do
conhecimento de um segredo.
Bloqueio por Chave Pública (Assinatura)
A forma mais simples de um script de bloqueio é aquele que requer uma assinatura. Vamos
considerar a transação de Alice que paga 50.000 satoshis a Bob. O output que Alice cria para pagar
Bob terá um script de bloqueio que exige a assinatura de Bob e teria a seguinte aparência:
Um script de bloqueio que requer uma assinatura digital da chave privada de Bob
<Bob Public Key> CHECKSIG
O operador CHECKSIG retira dois elementos da stack: uma assinatura e uma chave pública. Como
você pode ver, a chave pública de Bob está no script de bloqueio, então o que está faltando é a
assinatura correspondente a essa chave pública. Esse script de bloqueio só pode ser gasto por Bob,
porque somente Bob possui a chave privada correspondente necessária para produzir uma
assinatura digital que corresponda à chave pública.
Para desbloquear esse script de bloqueio, Bob forneceria um script de desbloqueio contendo
apenas sua assinatura digital:
Um script de desbloqueio contendo (apenas) uma assinatura digital da chave privada de Bob
<Bob Signature>
Em [locking_unlocking_chain]você pode ver o script de bloqueio na transação de Alice (no output
14
que paga Bob) e o script de desbloqueio (no input que gasta aquele output) na transação de Bob.
1. Uma cadeia de transações mostrando o script de bloqueio (saída) e o script de desbloqueio

(entrada) image::images/mtln_aa09.png["Uma corrente de transações mostrando o locking
script (output) and unlocking script (input)]
Para validar a transação de Bob, um node (nó) Bitcoin faria o seguinte:
1. Extrair o unlocking script do input (<Bob Signature>).
2. Procurar o outpoint que ele está tentando gastar (a643e37...3213:0). Esta é a transação de Alice e
seria encontrada na blockchain.
3. Extrair o locking script daquele outpoint (<Bob PubKey> CHECKSIG).
4. Concatenar em um script, colocando o unlocking script na frente do locking script (<Bob

Signature><Bob PubKey> CHECKSIG).
5. Executar este script no mecanismo de execução de Bitcoin Script para ver qual resultado é
produzido.
6. Se o resultado for TRUE, deduzIR que a transação de Bob é válida pois ela conseguiu cumprir a
condição de gasto (spending condition) para gastar aquele outpoint.
Bloqueio por Hash (Segredo)
Outro tipo de script de bloqueio, usado na Lightning Network, é o hashlock (bloqueio por hash).
Para desbloqueá-lo, você precisa conhecer o preimage (pré-imagem) secreto correspondente ao
hash.
Para demonstrar isso, vamos fazer com que Bob gere um número aleatório R e o mantenha em
segredo:
R = 1833462189
Agora, Bob calcula o hash SHA-256 deste número:
H = SHA256(R) =>
H = SHA256(1833462189) =>
H = 0ffd8bea4abdb0deafd6f2a8ad7941c13256a19248a7b0612407379e1460036a
Agora, Bob dá o hash H que calculamos anteriormente para Alice, mas mantém o número R em
segredo. Lembre-se de que, devido às propriedades dos hashes criptográficos, Alice não pode
"reverter" o cálculo do hash e adivinhar o número R.
Alice cria uma saída pagando 50.000 satoshi com o script de bloqueio:
HASH256 H EQUAL
onde H é o valor real do hash (0ffd8...036a) que Bob deu a Alice.
15
Vamos explicar este script:
O operador HASH256 extrai um valor do stack e calcula o hash SHA-256 de tal valor. Em seguida,
ele coloca o resultado no stack.
O valor H é colocado no stack e, em seguida, o operador EQUAL verifica se os dois valores são iguais
e coloca TRUE ou FALSE no stack de acordo com o resultado.
Portanto, este script de bloqueio só funcionará se for combinado com um script de desbloqueio que
contenha R, de forma que quando concatenados, tenhamos:
R HASH256 H EQUAL
Apenas Bob conhece R, então apenas Bob pode produzir uma transação com um script de
desbloqueio revelando o valor secreto R.
Curiosamente, Bob pode dar o valor R para qualquer outra pessoa, que pode gastar esse Bitcoin.
Isso torna o valor secreto R quase como um "voucher" de bitcoin, já que qualquer um que o possua
pode gastar o output que Alice criou. Veremos como esta é uma propriedade útil para a Lightning
Network!
Multisignature Scripts
A linguagem Bitcoin Script oferece uma multisignature building block (primitive)—um bloco de
construção de múltiplas assinaturas—que pode ser usado para construir serviços de custódia
(escrow) e configurações de propriedade complexas entre vários participantes.Um arranjo que
requer múltiplas assinaturas para gastar bitcoin é chamado de esquema de multisignature,
especificado como um esquema K-de-N, onde:
• N é o número total de signatários identificados no esquema de multisignature, e
• K é o quorum ou threshold (limiar): o número mínimo de assinaturas para autorizar o gasto.
O script para uma assinatura múltipla K-of-N é:
K <PubKey1> <PubKey2> ... <PubKeyN> N CHECKMULTISIG
onde N é o número total de chaves públicas listadas (Chave Pública 1 até Chave Pública N) e K é o
limite inferior de assinaturas necessárias para gastar o output.
A Lightning Network usa um esquema de assinatura múltipla 2-de-2 para criar um canal de
pagamento. Por exemplo, um canal de pagamento entre Alice e Bob seria construído em uma 2-of-2
multisignature como esta:
2 <PubKey Alice> <PubKey Bob> 2 CHECKMULTISIG
O script de bloqueio anterior pode ser satisfeito com um script de desbloqueio contendo um par de
16
[2]
assinaturas.:
0 <Sig Alice> <Sig Bob>
Os dois scripts juntos formariam o script de validação combinado:
0 <Sig Alice> <Sig Bob> 2 <PubKey Alice> <PubKey Bob> 2 CHECKMULTISIG
Um multisignature locking script pode ser representado por um endereço Bitcoin, codificando o
hash do script de bloqueio. Por exemplo, a transação inicial de financiamento de um canal de
pagamento Lightning é uma transação que paga para um endereço que codifica um script de
bloqueio 2-of-2 multisig dos dois parceiros do canal.
Timelock Scripts (Scripts de bloqueio de tempo)
Outro bloco de construção importante que existe no Bitcoin e é amplamente utilizado na Lightning
Network é o timelock (bloqueio temporal). Um timelock é uma restrição de gasto que requer que
um determinado tempo ou altura do bloco tenha decorrido antes que o gasto seja permitido. É um
pouco como um cheque pré-datado retirado de uma conta bancária que não pode ser descontado
antes da data indicada no cheque.
Bitcoin tem dois níveis de timelocks: timelocks de nível de transação (transaction-level timelocks) e
timelocks de nível de saída (output-level timelocks).
Um timelock de nível de transação é registrado no campo nLockTime da transação e impede que a

transação inteira seja aceita antes que o timelock seja atingido. Os timelocks de nível de transação
são o mecanismo de timelock mais comumente usado no Bitcoin hoje em dia.
Um timelock de nível de saída é criado por um operador de script. Existem dois tipos de timelocks de
saída: timelocks absolutos e timelocks relativos.
Os timelocks absolutos de nível de saída são implementados pelo operador

CHECKLOCKTIMEVERIFY, que geralmente é abreviado na conversa como CLTV. Os timelocks
absolutos implementam uma restrição de tempo com um carimbo de data/hora ou altura de bloco
absolutos, expressando o equivalente a "não gastável antes do bloco 800.000".
Os timelocks relativos de nível de saída são implementados pelo operador CHECKSEQUENCEVERIFY,

geralmente abreviado na conversa como CSV. Os timelocks relativos implementam uma restrição
de gasto que é relativa à confirmação da transação, expressando o equivalente a "não pode ser
gasto até 1.024 blocos após a confirmação".
Scripts com Múltiplas Condições
Umdos recursos mais poderosos do Bitcoin Script é o controle de fluxo, também conhecido como
cláusulas condicionais. Você provavelmente está familiarizado com o controle de fluxo em várias
linguagens de programação que usam a construção IF...THEN...ELSE. As cláusulas condicionais do
Bitcoin têm uma aparência um pouco diferente, mas essencialmente seguem a mesma construção.
17
Em um nível básico, os opcodes condicionais do Bitcoin nos permitem construir um script de
bloqueio que possui duas formas de ser desbloqueado, dependendo do resultado TRUE/FALSE da
avaliação de uma condição lógica. Por exemplo, se x for TRUE, o script de bloqueio é A ELSE o script
de bloqueio é B.
Além disso, as expressões condicionais do Bitcoin podem ser nested (aninhadas) indefinidamente, o
que significa que uma cláusula condicional pode conter outra dentro dela, que contém outra e
assim por diante. O controle de fluxo do Bitcoin Script pode ser usado para construir scripts muito
complexos com centenas ou até milhares de caminhos de execução possíveis. Não há limite para o
nesting (aninhamento), mas as regras de consenso impõem um limite no tamanho máximo, em
bytes, de um script.
O Bitcoin implementa o controle de fluxo usando os opcodes IF, ELSE, ENDIF e NOTIF. Além disso,
as expressões condicionais podem conter operadores booleanos, como BOOLAND, BOOLOR, e NOT.
Num primeiro olhar, você pode achar os scripts de controle de fluxo do Bitcoin confusos. Isso
ocorre porque o Bitcoin Script é uma linguagem baseada em pilha (stack). Da mesma forma que a
operação aritmética 1 + 1 parece "de trás pra frente" quando expressa em Bitcoin Script como 1 1
ADD, as cláusulas de controle de fluxo no Bitcoin também parecem estar "invertidas".
Na maioria das linguagens de programação tradicionais (procedurais), o controle de fluxo se parece

com isto:
Pseudocode of flow control in most programming languages
if (condition):
code to run when condition is true
else:
code to run when condition is false
code to run in either case
Em uma linguagem baseada em pilha como o Bitcoin Script, a condição lógica vem antes do IF, o
que faz com que pareça "invertida", como neste exemplo:
Bitcoin Script flow control
condition
IF
code to run when condition is true
ELSE
code to run when condition is false
ENDIF
code to run in either case
Ao ler o Bitcoin Script, lembre-se de que a condição sendo avaliada vem antes do opcode IF.
Usando Controle de Fluxo em Scripts
Um uso muito comum do controle de fluxo no Bitcoin Script é construir um script de bloqueio que
18
oferece várias trajetórias de execução, cada uma representando uma forma diferente de resgatar o
UTXO.
Vamos dar uma olhada em um exemplo simples, onde temos dois assinantes, Alice e Bob, e
qualquer um deles pode resgatar. Com uma multisig, isso seria expresso como um 1-of-2 multisig
script. Para fins de demonstração, faremos a mesma coisa com uma cláusula IF:
IF
<Alice's Pubkey> CHECKSIG
ELSE
<Bob's Pubkey> CHECKSIG
ENDIF
Ao olhar para esse script de bloqueio, você pode estar se perguntando: "Onde está a condição? Não
há nada antes da cláusula IF!"
A condição não faz parte do script de bloqueio. Em vez disso, a condição será oferecida no script de
desbloqueio, permitindo que Alice e Bob "escolham" qual trajetória de execução desejam seguir.
Alice resgata isso com o script de desbloqueio:
<Alice's Sig> 1
O 1 no final serve como a condição (TRUE) que fará a cláusula IF executar o primeiro caminho de
resgate para o qual Alice possui uma assinatura.
Para que Bob resgate isso, ele teria que escolher a segunda trajetória de execução fornecendo um
valor FALSE para a cláusula IF:
<Bob's Sig> 0
O script de desbloqueio de Bob coloca um 0 na pilha, fazendo com que a cláusula IF execute o
segundo script (ELSE), que requer a assinatura de Bob.
Porque cada uma das duas condições também requer uma assinatura, Alice não pode usar a
segunda cláusula e Bob não pode usar a primeira cláusula; eles não possuem as assinaturas
necessárias para isso!
Como os fluxos condicionais podem ser aninhados (nested), os valores TRUE / FALSE no script de
desbloqueio também podem ser aninhados para navegar em um caminho complexo de condições.
No Um script complexo usado na Lightning Network você pode ver um exemplo do tipo de script
[3]
complexo usado na Lightning Network, com várias condições. Os scripts usados na Lightning
Network são altamente otimizados e compactos, para minimizar a pegada na blockchain, portanto,
não são fáceis de ler e entender. Apesar disso, veja se você consegue identificar alguns dos
conceitos do Bitcoin Script que aprendemos neste capítulo.
19
Example 1. Um script complexo usado na Lightning Network
# To remote node with revocation key

DUP HASH160 <RIPEMD160(SHA256(revocationpubkey))> EQUAL
IF
CHECKSIG
ELSE
<remote_htlcpubkey> SWAP SIZE 32 EQUAL
NOTIF
# To local node via HTLC-timeout transaction (timelocked).
DROP 2 SWAP <local_htlcpubkey> 2 CHECKMULTISIG
ELSE
# To remote node with preimage.
HASH160 <RIPEMD160(payment_hash)> EQUALVERIFY
CHECKSIG
ENDIF
ENDIF
[1] Lembre-se de que o troco não precisa ser o último output em uma transação e, na verdade, é indistinguível de outros inputs.
[2] O primeiro argumento (0) não tem nenhum significado, mas é necessário devido a um bug na implementação de multisignature
do Bitcoin. Esse problema é descrito em Mastering Bitcoin. Chapter 7.
[3] From BOLT #3.
20
Appendix A: Instalação e Uso Básico de
Docker
Este livro contém vários exemplos que são executados dentro de contêineres Docker para
padronização em diferentes sistemas operacionais.
Esta seção o ajudará a instalar o Docker e a se familiarizar com alguns dos comandos Docker mais
usados, para que você possa executar os contêineres de exemplo do livro.
Instalando o Docker
Antes de começarmos, você deve instalar o sistema de contêiner Docker em seu computador. O
Docker é um sistema aberto distribuído gratuitamente como Community Edition para diversos
sistemas operacionais, incluindo Windows, macOS e Linux. As versões para Windows e macOS são
chamadas de Docker Desktop e consistem em um aplicativo de desktop com interface gráfica e
ferramentas de linha de comando. A versão para Linux é chamada de Docker Engine e é composta
por um daemon de servidor e ferramentas de linha de comando. Vamos utilizar as ferramentas de
linha de comando, que são idênticas em todas as plataformas.
Vá em frente e instale Docker para seu sistema operacional seguindo as instruções para "Get
Docker" em Docker website.
Selecione seu sistema operacional na lista e siga as instruções de instalação.
Se você estiver instalando o Docker no Linux, siga as instruções pós-instalação para garantir
que você possa executar o Docker como um usuário regular em vez do usuário root. Caso
contrário, você precisará adicionar o prefixo sudo antes de todos os comandos docker,
executando-os como root, por exemplo: sudo docker.
Depois de instalar o Docker, você pode testar sua instalação executando o contêiner de
demonstração hello-world assim:
$ docker run hello-world
Hello from Docker!

This message shows that your installation appears to be working correctly.
[...]
Comandos Básicos de Docker

Neste apêndice, utilizaremos o Docker de forma bastante extensiva. Vamos utilizar os seguintes
comandos e argumentos do Docker.
1
Construindo um Contêiner
<pre data-type="programlisting">docker build [-t tag] [directory]</pre>
__tag__ é como identificamos o contêiner que estamos construindo, e __directory__ é o local onde o
contexto do contêiner (pastas e arquivos) e o arquivo de definição (Dockerfile) são encontrados.
Executando um Contêiner
<pre data-type="programlisting">docker run -it [--network netname] [--name

cname] tag</pre>
__netname__ é o nome de uma rede Docker, __cname__ é o nome que escolhemos para esta
instância do contêiner, e __tag__ é a name tag que atribuímos ao contêiner quando o construímos.
Executando um Comando em um Contêiner
<pre data-type="programlisting">docker exec cname command</pre>
__cname__ é o nome que atribuímos ao contêiner no comando run, e __command__ é um executável

ou script que queremos executar dentro do contêiner.
Parando e Iniciando um Contêiner
Na maioria dos casos, se estivermos executando um contêiner no modo interativo e terminal, ou

seja, com as flags i e t (combinadas como -it), o contêiner pode ser interrompido simplesmente
pressionando Ctrl-C ou saindo do shell com exit ou Ctrl-D. Se um contêiner não terminar, você pode
pará-lo a partir de outro terminal da seguinte forma:
<pre data-type="programlisting">docker stop cname</pre>
Para retomar um contêiner já existente, use o comando start da seguinte forma:
<pre data-type="programlisting">docker start cname</pre>
Deletando um Container por Nome
Se você der um nome a um contêiner em vez de permitir que o Docker o nomeie aleatoriamente,
você não poderá reutilizar esse nome até que o contêiner seja excluído. O Docker retornará um
erro como este:
docker: Error response from daemon: Conflict. The container name "/bitcoind" is
already in use...
Para corrigir isso, exclua a instância existente do contêiner:
<pre data-type="programlisting">docker rm cname</pre>
__cname__ é o nome atribuído ao contêiner (bitcoind na mensagem de erro de exemplo).
2
Listando Contêineres em Execução
docker ps
Este comando mostra os contêineres em execução no momento e seus nomes.
Listando Imagens do Docker
docker image ls
Este comando mostra as imagens Docker que foram construídas ou baixadas em seu computador.
Conclusão
Esses comandos básicos do Docker serão suficientes para você começar e permitirão que você
execute todos os exemplos deste livro.
3
Appendix A: Fontes e Avisos de Licença
Este apêndice contém avisos de atribuição e licença para material incluído por permissão
concedida por meio de licenças abertas.
Fontes
O material foi obtido de várias fontes públicas e de licença aberta (open-licensed sources):
• ION Lightning Network Wiki
• "Lightning 101: What Is a Lightning Invoice?" by Suredbits
• Lightning Network In-Progress Specifications GitHub; Creative Commons Attribution (CC-BY 4.0)
• Wikipedia page, "Elliptic-curve Diffie–Hellman"
• Wikipedia page, "Digital signature"
• Wikipedia page, "Cryptographic hash function"
• Wikipedia page, "Onion routing"
• Wikimedia Commons, "Lightning Network Protocol Suite"
• Wikimedia Commons, "Introduction to the Lightning Network Protocol and the Basics of
Lightning Technology"
BTCPay Server
BTCPay Server logo, screenshots, and other images used with permission under the MIT License:
MIT License
Copyright (c) 2018 BTCPay Server
A permissão é concedida, gratuitamente, a qualquer pessoa que obtenha

uma cópia deste software e dos arquivos de documentação associados (o
"Software"), para lidar com o Software sem restrições, incluindo, sem
limitação, os direitos de usar, copiar, modificar, fundir, publicar, distribuir,
sublicenciar e/ou vender cópias do Software e permitir que as pessoas para
as quais o Software é fornecido que o façam, sob as seguintes condições:
O aviso de direitos autorais acima e este aviso de permissão devem ser

incluídos em todas as cópias ou partes substanciais do Software.
O SOFTWARE É FORNECIDO "COMO ESTÁ", SEM QUALQUER GARANTIA,

EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO A, AS
GARANTIAS DE COMERCIALIZAÇÃO, ADEQUAÇÃO A UMA FINALIDADE
1
ESPECÍFICA E NÃO VIOLAÇÃO. EM NENHUM CASO, OS AUTORES OU
TITULARES DE DIREITOS AUTORAIS SERÃO RESPONSÁVEIS POR QUALQUER
REIVINDICAÇÃO, DANOS OU OUTRAS RESPONSABILIDADE, SEJA EM UMA
AÇÃO CONTRATUAL, ATO ILÍCITO OU OUTRA FORMA, DECORRENTE DE,
FORA DE OU EM CONEXÃO COM O SOFTWARE OU O USO OU OUTROS
NEGÓCIOS NO SOFTWARE.
Lamassu Industries AG
Imagens de Gaia Bitcoin ATM seen in [bitcoin-atm] são usadas com permissão de Lamassu
Industries AG. O uso dessas imagens não é um endosso do produto ou da empresa, mas são
fornecidas como um exemplo visual de um caixa eletrônico de Bitcoin (Bitcoin ATM).
2
Appendix A: Mensagens de Protocolo Wire
Este apêndice lista todos os tipos de mensagens atualmente definidos utilizados no protocolo
Lightning P2P. Além disso, mostramos a estrutura de cada mensagem, agrupando as mensagens em
grupos lógicos com base nos fluxos do protocolo.
As mensagens do Protocolo Lightning são extensíveis e sua estrutura pode mudar durante
atualizações em toda a rede. Para obter informações autoritativas, consulte a versão mais
recente dos BOLTs encontrados em GitHub Lightning-RFC repository.
Message Types
Os tipos de mensagens atualmente definidos estão listados na Tipos de mensagem.
Table 1. Tipos de mensagem
Tipo inteiro Nome da mensagem Categoria
16 init Estabelecimento de Conexão
17 error Erro de Comunicação
18 ping Vitalidade da Conexão
19 pong Vitalidade da Conexão
32 open_channel Financiamento de Canal
33 accept_channel Financiamento de Canal
34 funding_created Financiamento de Canal
35 funding_signed Financiamento de Canal
36 funding_locked Financiamento de Canal +

Operação de Canal
38 shutdown Fechamento de Canal
39 closing_signed Fechamento de Canal
128 update_add_htlc Operação de Canal
130 update_fulfill_hltc Operação de Canal
131 update_fail_htlc Operação de Canal
132 commit_sig Operação de Canal
133 revoke_and_ack Operação de Canal
134 update_fee Operação de Canal
135 update_fail_malformed_htlc Operação de Canal
136 channel_reestablish Operação de Canal
256 channel_announcement Anúncio de Canal
1
Tipo inteiro Nome da mensagem Categoria
257 node_announcement Anúncio de Canal
258 channel_update Anúncio de Canal
259 announce_signatures Anúncio de Canal
261 query_short_chan_ids Sincronização de Grafo de

Canais
262 reply_short_chan_ids_end Sincronização de Grafo de

Canais
263 query_channel_range Sincronização de Grafo de

Canais
264 reply_channel_range Sincronização de Grafo de

Canais
265 gossip_timestamp_range Sincronização de Grafo de

Canais
Na [message_types], o campo Category permite a rápida categorização de uma mensagem com base
em sua funcionalidade dentro do próprio protocolo. Em alto nível, colocamos uma mensagem em
um dos oito buckets (não exaustivos), incluindo:
Connection Establishment
Enviada quando uma conexão peer-to-peer é estabelecida estabelecida. Também usado para
negociar o conjunto de recursos suportados por uma nova conexão.
Error Communication
Usada por peers para comunicar um ao outro a ocorrência de erros em nível de protocolo.
Connection Liveness
Usada por peers para verificar que certa conexão de transporte ainda está ativa.
Channel Funding
Usada por peers para criar um novo canal de pagamento. Este também é conhecido como
processo de financiamento de canal.
Channel Operation
O ato de atualizar um determinado canal off-chain. Isto inclui o envio e recebimento de
pagamentos, bem como o encaminhamento de pagamentos dentro da rede.
Channel Announcement
O processo de anunciar um novo canal público para a rede mais ampla para que possa ser usada
para propósitos de roteamento.
Channel Graph Syncing

O processo de fazer download e verificação do channel graph.
Observe como as mensagens que pertencem à mesma categoria geralmente também compartilham
2
um message type (tipo de mensagem) adjacente. Isso é feito com o propósito de agrupar mensagens
semanticamente similares dentro da especificação em si.
Message Structure
Agora detalhamos cada categoria de mensagem para definir com precisão a estrutura e a semântica
todas as mensagens definidas no protocolo LN (Lightning Network).
Mensagens de Estabelecimento de Conexão
Mensagens nesta categoria são as primeiríssimas mensagens enviadas entre pares assim que eles
estabelecem uma conexão de transporte. No momento em que escrevemos este capítulo existe
somente uma única mensagem dentro desta categoria, a mensagem init. A mensagem init é
enviada por ambos os lados da conexão assim que ela é estabelecida pela primeira vez. Nenhuma
outra mensagem deve ser enviada antes que a mensagem init tenha sido enviada por ambas as
partes.
======= A mensagem init
A estrutura da mensagem init é definida como segue:
• Tipo: 16
• Campos:
◦ uint16: global_features_len
◦ global_features_len*byte: global_features
◦ uint16: features_len
◦ features_len*byte: features
◦ tlv_stream_tlvs
Estruturalmente, a mensagem init é composta por duas fatias de bytes de tamanho variável e cada
uma armazena um conjunto de feature bits.As we see in [feature_bits], feature bits são uma
primitiva usada dentro do protocolo para anunciar o conjunto de recursos do protocolo que um
node entende (recursos opcionais) ou exige (recursos obrigatórios).
Observe que as implementações modernas de nodes usarão apenas o campo features, com itens
que residem no vetor global_features para principalmente propósitos históricos (compatibilidade
retroativa ou backward compatibility).
O que segue após a mensagem principal é uma série de registros de Tipo-Comprimento-Valor, ou

Type-Length-Value (TLV) que podem ser usados para estender a mensagem de forma compatível
com versões futuras e passadas, no futuro. Vamos explicar o que são os registros TLV e como eles
são utilizados mais tarde neste apêndice.
A mensagem init é então examinada por um peer para determinar se a conexão é bem definida
com base no conjunto de recursos opcionais e necessários suportados e anunciados por ambos os
lados.
3
Um recurso opcional significa que um peer conhece um recurso, mas não o considera fundamental
para o funcionamento de uma nova conexão. Um exemplo disso seria a capacidade de entender a
semântica de um campo recém-adicionado a uma mensagem existente.
Por outro lado, recursos obrigatórios indicam que se o outro peer não conhecer o recurso, então a
conexão não está bem definida. Um exemplo desse recurso seria um novo tipo de canal teórico
dentro do protocolo: se o seu peer não conhece esse recurso, você não deseja manter a conexão
porque eles não podem abrir o seu novo tipo preferido de canal.
Mensagens de Erro de Comunicação
Mensagens nesta categoria são usadas para enviar erros de nível de conexão entre dois peers.
Existe outro tipo de erro no protocolo: um erro de encaminhamento de HTLC. Erros de nível de
conexão podem sinalizar coisas como incompatibilidade de bits de recurso ou a intenção de forçar
o fechamento (unilateralmente transmitir o último compromisso assinado).
A mensagem de erro
A única mensagem nesta categoria é a mensagem error.
• Tipo: 17
• Campos:
◦ channel_id : chan_id
◦ uint16 : data_len
◦ data_len*byte : data
Uma mensagem de error pode ser enviada dentro do escopo de um canal específico definindo o
campo channel_id para o channel_id do canal que está passando por esse novo estado de erro.
Alternativamente, se o erro se aplica à conexão em geral, o campo channel_id deve ser definido
como todos zeros. channel_id também é conhecido como um identificador de erro a nível de
conexão.
Dependendo da natureza do erro, enviar uma mensagem error para um peer com quem você tem
um canal pode indicar que o canal não pode continuar sem intervenção manual, então a única
opção nesse ponto é forçar o fechamento do canal transmitindo o estado de compromisso
(commitment state) mais recente do canal.
Vitalidade da Conexão
As mensagens desta seção são usadas para sondar e verificar se uma conexão está ativa ou não.
Como o protocolo LN abstrai em certa medida o transporte subjacente usado para transmitir as
mensagens, um conjunto de mensagens de nível de protocolo ping e pong são definidas.
======= A mensagem ping
A mensagem ping é usada para verificar se a outra parte em uma conexão está "ativa". Ela contém
os seguintes campos:
4
• Tipo: 18
• Campos:
◦ uint16 : num_pong_bytes
◦ uint16 : ping_body_len
◦ ping_body_len*bytes : ping_body
Em seguida, seu companheiro, a mensagem pong.
A mensagem pong
A mensagem pong é enviada em resposta à mensagem ping e contém os seguintes campos:
• Tipo: 19
• Campos:
◦ uint16 : pong_body_len
◦ ping_body_len*bytes : pong_body
Uma mensagem ping pode ser enviada por qualquer uma das partes a qualquer momento.
A mensagem ping inclui um campo num_pong_bytes que é usado para instruir o node receptor em
relação ao tamanho do payload que ele envia em sua mensagem de pong. A mensagem ping também
inclui um conjunto de bytes opacos chamado ping_body que pode ser ignorado com segurança. Ele
serve apenas para permitir que o remetente preencha as mensagens ping que envia, o que pode ser
útil na tentativa de impedir certas técnicas de desanonimização com base no tamanho dos pacotes
na rede.
Uma mensagem pong deve ser enviada em resposta a uma mensagem ping recebida. O receptor
deve ler um conjunto de bytes aleatórios num_pong_bytes para enviar de volta como o campo
pong_body. O uso inteligente desses campos/mensagens pode permitir que um node de roteamento
preocupado com a privacidade tente impedir certas classes de tentativas de desanonimização de
rede, pois eles podem criar uma transcrição "falsa" que se assemelha a outras mensagens com base
nos tamanhos de pacotes enviados. Lembre-se de que, por padrão, a Lightning Network usa um
transporte criptografado, portanto, um monitor passivo de rede não pode ler os bytes em texto
simples e, portanto, só tem informações de temporização e tamanhos de pacotes para se basear.
Financiamento do Canal
Conforme avançamos, entramos no território das mensagens principais que governam a

funcionalidade e a semântica do Protocolo Lightning. Nesta seção, exploramos as mensagens
enviadas durante o processo de criação de um novo canal. Apenas descreveremos os campos
utilizados, pois deixamos uma análise detalhada do processo de financiamento no
[payment_channels].
As mensagens que são enviadas durante o fluxo de financiamento do canal pertencem ao seguinte
conjunto de cinco mensagens: open_channel, accept_channel, funding_created, funding_signed e
funding_locked.
5
O fluxo detalhado do protocolo usando essas mensagens é descrito em [payment_channels].
A mensagem open_channel
A mensagem open_channel inicia o processo de financiamento do canal e contém os seguintes

campos:
• Tipo: 32
• Campos:
◦ chain_hash : chain_hash
◦ 32*byte : temp_chan_id
◦ uint64 : funding_satoshis
◦ uint64 : push_msat
◦ uint64 : dust_limit_satoshis
◦ uint64 : max_htlc_value_in_flight_msat
◦ uint64 : channel_reserve_satoshis
◦ uint64 : htlc_minimum_msat
◦ uint32 : feerate_per_kw
◦ uint16 : to_self_delay
◦ uint16 : max_accepted_htlcs
◦ pubkey : funding_pubkey
◦ pubkey : revocation_basepoint
◦ pubkey : payment_basepoint
◦ pubkey : delayed_payment_basepoint
◦ pubkey : htlc_basepoint
◦ pubkey : first_per_commitment_point
◦ byte : channel_flags
◦ tlv_stream : tlvs
Esta é a primeira mensagem enviada quando um nó deseja executar um novo fluxo de

financiamento com outro node. Essa mensagem contém todas as informações necessárias para que
ambos os peers construam tanto ambas as transações de financiamento (funding transaction)
quanto ambas as transação de compromisso (commitment transaction).
No momento da escrita deste capítulo, um único registro TLV é definido dentro do conjunto de
registros TLV opcionais que podem ser anexados ao final de uma mensagem definida:
• Tipo: 0
• Dados: upfront_shutdown_script
O upfront_shutdown_script é uma sequência de bytes de tamanho variável que deve ser um script de
6
chave pública válido, conforme aceito pelo algoritmo de consenso da rede Bitcoin. Ao fornecer esse
endereço, a parte que envia é capaz de criar efetivamente um "loop fechado" para seu canal, pois
nenhum dos lados assinará uma transação de encerramento cooperativo que pague para qualquer
outro endereço. Na prática, esse endereço costuma ser derivado de uma carteira de
armazenamento a frio (cold storage).
O campo channel_flags é um bitfield (campo de bits) do qual, no momento da escrita, apenas o

primeiro bit tem algum tipo de significado. Se esse bit estiver definido, esse canal será anunciado
para a rede pública como um canal roteável. Caso contrário, o canal é considerado não anunciado,
também conhecido como um canal privado.
A mensagem accept_channel
A mensagem accept_channel é a resposta à mensagem open_channel .
• Tipo: 33
• Campos:
◦ uint64 : dust_limit_satoshis
◦ uint64 : max_htlc_value_in_flight_msat
◦ uint64 : channel_reserve_satoshis
◦ uint32 : minimum_depth
◦ uint16 : to_self_delay
◦ uint16 : max_accepted_htlcs
◦ pubkey : funding_pubkey
◦ pubkey : revocation_basepoint
◦ pubkey : payment_basepoint
◦ pubkey : delayed_payment_basepoint
◦ pubkey : htlc_basepoint
◦ pubkey : first_per_commitment_point
◦ tlv_stream : tlvs
A mensagem accept_channel é a segunda mensagem enviada durante o processo de fluxo de

financiamento. Ela serve para reconhecer a intenção de abrir um canal com um novo node remoto
(peer). A mensagem geralmente reflete o conjunto de parâmetros que o destinatário deseja aplicar
à sua versão da transação de compromisso. No [payment_channels], quando entramos no processo
de financiamento em detalhes, exploramos as implicações dos vários parâmetros que podem ser
definidos ao abrir um novo canal.
A mensagem funding_created
Em resposta, o iniciador enviará a mensagem funding_created.
7
• Tipo: 34
• Campos:
◦ 32*byte : funding_txid
◦ uint16 : funding_output_index
◦ sig : commit_sig
Uma vez que o iniciador de um canal recebe a mensagem accept_channel do destinatário, ele tem
todos os materiais necessários para construir a transação de compromisso, bem como a transação
de financiamento. Como os canais por padrão, possuem apenas um financiador (apenas um lado
compromete fundos), somente o iniciador precisa para construir a transação de financiamento.
Como resultado, para permitir que o destinatário assine uma versão da transação de compromisso
para o iniciador, o iniciador só precisa enviar o "funding outpoint" do canal.
A mensagem funding_signed
Para concluir, o destinatário envia a mensagem funding_signed .
• Tipo: 34
• Campos:
◦ channel_id : channel_id
◦ sig : signature
Após receber a mensagem funding_created, o destinatário possui agora uma assinatura válida da
transação de compromisso pelo iniciador. Com essa assinatura, ele pode encerrar o canal a
qualquer momento, assinando sua metade da saída de financiamento multisig e transmitindo a
transação. Isso é chamado de encerramento forçado. Por outro lado, para dar ao iniciador a
capacidade de encerrar o canal, o destinatário também assina a transação de compromisso do
iniciador.
Assim que essa mensagem for recebida pelo iniciador, ele pode com segurança transmitir a
transação de financiamento, pois agora pode encerrar o acordo do canal unilateralmente.
======= A mensagem funding_locked
Uma vez que a transação de financiamento tenha recebido um número suficiente de confirmações,
a mensagem funding_locked é enviada.
• Tipo: 36
• Campos:
◦ pubkey : next_per_commitment_point
Somente após a transação de financiamento ter obtido um número de confirmações igual ou

superior ao minimum_depth , então a mensagem funding_locked deve ser enviada por ambos os lados.
Somente após o recebimento e envio dessa mensagem é que o canal pode começar a ser utilizado.
8
Fechamento do Canal
O fechamento do canal é um processo de várias etapas. Um node inicia enviando a mensagem

shutdown. Os dois parceiros do canal então trocam uma série de mensagens closing_signed para
negociar taxas mutuamente aceitáveis para a transação de fechamento.O financiador do canal
envia a primeira mensagem closing_signed , e a outra parte pode aceitar enviando uma mensagem
closing_signed com os mesmos valores de taxa.
A mensagem de desligamento
A mensagem shutdown inicia o processo de fechamento de um canal e contém os seguintes campos:
• Type: 38
• Campos:
◦ u16 : len
◦ len*byte : scriptpubkey
A mensagem closing_signed
A mensagem closing_signed é enviada por cada parceiro de canal até que eles concordem com as
taxas. Ela contém os seguintes campos:
• Tipo: 39
• Campos:
◦ u64 : fee_satoshis
◦ signature : signature
Operação do Canal
Nesta seção, descrevemos brevemente o conjunto de mensagens usadas para permitir que os nós
operem um canal. Por operação, queremos dizer a capacidade de enviar, receber e encaminhar
pagamentos em um determinado canal.
Para enviar, receber ou encaminhar um pagamento em um canal, um HTLC (Hashed Time-Locked

Contract) deve ser adicionado primeiro às transações de compromisso (commitment transactions)
que compõem uma ligação do canal (channel link).
A mensagem update_add_htlc
A mensagem update_add_htlc permite que qualquer um dos lados adicione um novo HTLC à
transação de compromisso oposta.
• Tipo: 128
• Campos:
9
◦ uint64 : id
◦ uint64 : amount_msat
◦ sha256 : payment_hash
◦ uint32 : cltv_expiry
◦ 1366*byte : onion_routing_packet
O envio dessa mensagem permite que uma das partes inicie ou o envio de um novo pagamento ou
encaminhe um pagamento existente que tenha chegado por meio de um canal de entrada. A
mensagem especifica o valor (amount_msat) juntamente com o payment hash que desbloqueia o
próprio pagamento. O conjunto de instruções de encaminhamento do próximo salto é criptografado
em camadas (onion encryption) dentro do campo onion_routing_packet.. No [onion_routing], em um
encaminhamento de HTLC em vários saltos, abordamos em detalhes o protocolo de roteamento em
camadas (onion routing) usado na Lightning Network.
Observe que cada HTLC enviado usa um ID de incremento automático que é usado por qualquer
mensagem que modifica um HTLC (settle ou cancel) para referenciar o HTLC de maneira única no
escopo do canal.
A mensagem update_fulfill_hltc
A mensagem update_fulfill_hltc permite o resgate (recebimento) de um HTLC ativo.
• Tipo: 130
• Campos:
◦ uint64 : id
◦ 32*byte : payment_preimage
Essa mensagem é enviada pelo receptor do HTLC ao proponente para resgatar um HTLC ativo. A
mensagem faz referência ao id do HTLC em questão e também fornece o preimage (que
desbloqueia o HTLC).
A mensagem update_fail_htlc
A mensagem update_fail_htlc é enviada para remover um HTLC de uma transação de

compromisso.
• Tipo: 131
• Campos:
◦ uint64 : id
◦ uint16 : len
◦ len*byte : reason
10
A mensagem update_fail_htlc é o oposto da mensagem update_fulfill_hltc, pois permite que o
destinatário de um HTLC remova o próprio HTLC. Essa mensagem é normalmente enviada quando
um HTLC não pode ser roteado corretamente montante acima e precisa ser devolvido ao remetente
para desfazer a cadeia HTLC. Conforme exploramos em [failure_messages], a mensagem contém
um motivo de falha criptografado (reason), que pode permitir que o remetente ajuste sua rota de
pagamento ou a encerre caso a falha em si seja terminal.
A mensagem commitment_signed
A mensagem commitment_signed é usada para carimbar a criação de uma nova transação de

compromisso.
• Tipo: 132
• Campos:
◦ sig : signature
◦ uint16 : num_htlcs
◦ num_htlcs*sig : htlc_signature
Além de enviar uma assinatura para a próxima transação de compromisso, o remetente desta
mensagem também precisa enviar uma assinatura para cada HTLC presente na transação de
compromisso.
A mensagem revoke_and_ack
A mensagem revoke_and_ack é enviada para revogar um compromisso datado.
• Tipo: 133
• Campos:
◦ 32*byte : per_commitment_secret
◦ pubkey : next_per_commitment_point
Porque a Lightning Network utiliza uma transação de compromisso "replace-by-revoke" (substituir

por revogação), após receber uma nova transação de compromisso por meio da mensagem
commit_sig , uma parte deve revogar seu compromisso anterior antes de poder receber outro. Ao
revogar uma transação de compromisso, o revogador também fornece o próximo ponto de
compromisso que é necessário para permitir que a outra parte lhes envie um novo estado de
compromisso.
A mensagem update_fee
A mensagem update_fee é enviada para atualizar a taxa nas transações de compromisso atuais.
• Tipo: 134
• Campos:
11
◦ uint32 : feerate_per_kw
Esta mensagem só pode ser enviada pelo iniciador do canal; são eles que pagarão pela taxa de
compromisso do canal enquanto estiver aberto.
A mensagem update_fail_malformed_htlc
A mensagem update_fail_malformed_htlc é enviada para remover um HTLC corrompido.
• Tipo: 135
• Campos:
◦ uint64 : id
◦ sha256 : sha256_of_onion
◦ uint16 : failure_code
Essa mensagem é semelhante à mensagem update_fail_htlc, mas raramente é usada na prática.

Como mencionado anteriormente, cada HTLC contém um pacote de roteamento criptografado por
cebola (onion encrypted routing) que também cobre a integridade de partes do próprio HTLC. Se
uma parte receber um pacote de cebola que tenha sido corrompido de alguma forma no caminho,
ela não conseguirá descriptografar o pacote. Como resultado, ela também não pode encaminhar
corretamente o HTLC; portanto, enviará esta mensagem para indicar que o HTLC foi corrompido
em algum lugar ao longo do caminho de volta para o remetente.
Anúncio do Canal
As mensagens nesta categoria são usadas para anunciar componentes da estrutura de dados
autenticada do grafo de canais (channel graph) para a rede mais ampla. O grafo de canais possui
uma série de propriedades exclusivas devido à condição de que todos os dados adicionados ao
grafo de canais também devem estar ancorados na blockchain do Bitcoin. Como resultado, para
adicionar uma nova entrada ao gráfico de canal, um agente deve ser uma taxa de transação on-
chain. Isso serve como um impedimento de spam natural para a Rede Relâmpago.
======= A mensagem channel_announcement
A mensagem channel_announcement é usada para anunciar um novo canal para rede mais ampla.
• Tipo: 256
• Campos:
◦ sig : node_signature_1
◦ sig : node_signature_2
◦ sig : bitcoin_signature_1
◦ sig : bitcoin_signature_2
◦ uint16 : len
12
◦ len*byte : features
◦ short_channel_id : short_channel_id
◦ pubkey : node_id_1
◦ pubkey : node_id_2
◦ pubkey : bitcoin_key_1
◦ pubkey : bitcoin_key_2
A sequência de assinaturas e chaves públicas na mensagem serve para criar uma prova de que o
canal realmente existe dentro da base da blockchain do Bitcoin. Conforme detalhamos em [scid],
cada canal é identificado de forma única por um localizador que codifica sua localização dentro da
blockchain. Esse localizador é chamado de short_channel_id e pode ser representado por um
número inteiro de 64 bits.
A mensagem node_announcement
A mensagem node_announcement permite que um nó anuncie/atualize seu vértice dentro do grafo de

canais maior.
• Tipo: 257
• Campos:
◦ sig : signature
◦ uint64 : flen
◦ flen*byte : features
◦ uint32 : timestamp
◦ pubkey : node_id
◦ 3*byte : rgb_color
◦ 32*byte : alias
◦ uint16 : addrlen
◦ addrlen*byte : addresses
Note que se um nó não tiver nenhum canal anunciado dentro do grafo de canais, então essa
mensagem é ignorada para garantir que adicionar um item ao grafo de canais tenha um custo na
cadeia de blocos (on-chain). Nesse caso, o custo na cadeia de blocos será o custo de criar o canal ao
qual esse nó está conectado.
Além de anunciar suas capacidades, essa mensagem também permite que um nó anuncie/atualize o
conjunto de endereços de rede—addresses— onde ele pode ser alcançado.
======= A mensagem channel_update
A mensagem channel_update é enviada para atualizar as propriedades e políticas de uma borda de

canal ativa dentro do grafo de canais.
13
• Tipo: 258
• Campos:
◦ signature : signature
◦ uint32 : timestamp
◦ byte : message_flags
◦ byte : channel_flags
◦ uint16 : cltv_expiry_delta
◦ uint32 : fee_base_msat
◦ uint32 : fee_proportional_millionths
◦ uint16 : htlc_maximum_msat
Além de poder habilitar/desabilitar um canal, essa mensagem permite que um nó atualize suas
taxas de roteamento, bem como outros campos que determinam o tipo de pagamento que é
permitido fluir através desse canal.
A mensagem announce_signatures
A mensagem announce_signatures é trocada pelos pares de canal para montar o conjunto de

assinaturas necessárias para produzir uma mensagem channel_announcement.
• Tipo: 259
• Campos:
◦ sig : node_signature
◦ sig : bitcoin_signature
Após o envio da mensagem funding_locked, se ambos os lados desejarem divulgar seu canal para a
rede, cada um enviará a mensagem announce_signatures , que permite que ambos os lados
coloquem as quatro assinaturas necessárias para gerar uma mensagem announce_signatures .
Sincronização de gráfico de canal
Os nós criam uma perspectiva local do gráfico do canal usando cinco mensagens:
query_short_chan_ids, reply_short_chan_ids_end, query_channel_range, reply_channel_range e
gossip_timestamp_range.
======= A mensagem query_short_chan_ids
Amensagem query_short_chan_ids permite que um nó obtenha informações sobre um canal
14
relacionadas a uma série de IDs curtos de canal.
• Tipo: 261
• Campos:
◦ u16 : len
◦ len*byte : encoded_short_ids
◦ query_short_channel_ids_tlvs : tlvs
Como aprendemos no [gossip], esses IDs de canal podem ser uma série de canais. que eram novos
para o emissor ou estavam desatualizados, o que permite que o emissor obtenha o conjunto mais
recente de informações para um conjunto de canais.
======= A mensagem reply_short_chan_ids_end
A mensagem reply_short_chan_ids_end é enviada após um nó terminar de responder a uma

mensagem query_short_chan_ids anterior.
• Tipo: 262
• Campos:
◦ byte : full_information
Essa mensagem indica à parte receptora que, se eles desejam enviar outra mensagem de consulta,
agora podem fazê-lo.
A mensagem query_channel_range
A mensagem query_channel_range permite que um nó faça uma consulta para obter conjunto de
canais abertos dentro de um intervalo de blocos.
• Tipo: 263
• Campos:
◦ u32 : first_blocknum
◦ u32 : number_of_blocks
◦ query_channel_range_tlvs : tlvs
Como os canais são representados usando um ID de canal curto que codifica a localização de um
canal na cadeia (on-chain), um nó na rede pode usar a altura de um bloco como uma espécie de
cursor (indicador) para percorrer a cadeia a fim de descobrir um conjunto de canais recém-abertos.
A mensagem reply_channel_range
A mensagem reply_channel_range é a resposta à mensagem query_channel_range e inclui o conjunto
15
de IDs curtos de canal para os canais conhecidos dentro desse intervalo.
• Tipo: 264
• Campos:
◦ u32 : first_blocknum
◦ u32 : number_of_blocks
◦ byte : sync_complete
◦ u16 : len
◦ len*byte : encoded_short_ids
◦ reply_channel_range_tlvs : tlvs
Como resposta à query_channel_range, essa mensagem envia de volta o conjunto de canais que
foram abertos dentro desse intervalo. Esse processo pode ser repetido com o solicitante avançando
seu cursor mais adiante na cadeia para continuar sincronizando o grafo de canais.
======= A mensagem gossip_timestamp_range
A mensagem gossip_timestamp_range permite que um nó comece a receber novas mensagens de

gossip (fofoca) na rede.
• Tipo: 265
• Campos:
◦ u32 : first_timestamp
◦ u32 : timestamp_range
Uma vez que um nó tenha sincronizado o grafo de canais, ele pode enviar essa mensagem se
desejar receber atualizações em tempo real sobre as alterações no grafo de canais. Ele também
pode definir os campos first_timestamp e timestamp_range se desejar receber um backlog de
atualizações que possam ter sido perdidas enquanto estava desligado.
16
Introdução
Bem-vindo ao Dominando a Rede Relâmpago!
A Rede Relâmpago (Lightning Network, frequentemente abreviada como LN) está mudando a
forma como as pessoas trocam valor online e é um dos avanços mais empolgantes na história do
Bitcoin. Hoje, em 2021, a Rede Relâmpago ainda está em seus estágios iniciais. A Lightning Network
é um protocolo para utilizar o Bitcoin de uma maneira inteligente e não óbvia. É uma tecnologia de
segunda camada que funciona em cima do Bitcoin.
O conceito da Lightning Network foi proposto em 2015, e a primeira implementação foi lançada em
2018. Até 2021, estamos apenas começando a ver as oportunidades que a Lightning Network
oferece ao Bitcoin, incluindo melhorias na privacidade, velocidade e escalabilidade. Com um
conhecimento sólido da Lightning Network, você pode ajudar a moldar o futuro da rede e ao
mesmo tempo criar oportunidades para si mesmo.
Nós presumimos que você já tenha algum conhecimento básico sobre Bitcoin, mas se não tiver, não
se preocupe—vamos explicar os conceitos mais importantes do Bitcoin, aqueles que você precisa
conhecer para entender a Lightning Network, em [bitcoin_fundamentals_review]. Se você quiser
aprender mais sobre o Bitcoin, você pode ler Mastering Bitcoin, 2ª edição, por Andreas M.
Antonopoulos (O’Reilly), disponível em for free online.
Embora a maior parte deste livro seja escrita para programadores, os primeiros capítulos são
escritos de forma acessível para qualquer pessoa, independentemente de sua experiência técnica.
Neste capítulo, começaremos com algumas terminologias, em seguida, abordaremos a questão da
confiança e sua aplicação nesses sistemas, e finalmente discutiremos a história e o futuro da
Lightning Network. Vamos começar.
Conceitos Básicos da Lightning Network

Conforme exploramos como a Lightning Network realmente funciona, nos deparamos com alguns
termos técnicos que podem ser um pouco confusos no início. Embora todos esses conceitos e termos
sejam explicados em detalhes à medida que avançamos pelo livro e estão definidos no glossário,
algumas definições básicas agora tornarão mais fácil compreender os conceitos nos próximos dois
capítulos. Se você ainda não entende todas as palavras nessas definições, tudo bem. Você vai
entender mais à medida que avançar no texto.
Blockchain
Um livro-razão de transações distribuído, produzido por uma rede de computadores. O Bitcoin,
por exemplo, é um sistema que produz uma blockchain. A Lightning Network não é em si uma
blockchain, nem produz uma blockchain. É uma rede que depende de uma blockchain externa
existente para sua segurança.
Assinatura digital
Uma assinatura digital é um esquema matemático para verificar a autenticidade de mensagens
ou documentos digitais. Uma assinatura digital válida dá ao destinatário motivo para acreditar
que a mensagem foi criada por um emissor conhecido, que o emissor não pode negar ter
enviado a mensagem e que a mensagem não foi alterada durante a transmissão.
1
Função Hash
Uma função hash criptográfica é um algoritmo matemático que mapeia dados de tamanho
arbitrário para uma sequência de bits de tamanho fixo (um hash) e é projetada para ser uma
função unidirecional, ou seja, uma função que é inviável de ser invertida.
Nó
Um computador que participa de uma rede. Um nó Lightning é um computador que participa da
Lightning Network. Um nó Bitcoin é um computador que participa da rede Bitcoin.
Normalmente, um usuário da LN executará um nó Lightning e um nó Bitcoin.
On-chain versus off-chain

Um pagamento é considerado on-chain quando é registrado como uma transação na blockchain
do Bitcoin (ou em outra blockchain subjacente).Pagamentos enviados por meio de canais de
pagamento entre nós da Lightning e que não são visíveis na blockchain subjacente são
chamados de pagamentos off-chain (fora da cadeia). Geralmente, na Lightning Network, as
únicas transações on-chain (na blockchain) são aquelas usadas para abrir e fechar um canal de
pagamento da Lightning. Existe um terceiro tipo de transação de modificação de canal, chamado
de "splicing", que pode ser usado para adicionar/remover a quantidade de fundos
comprometidos em um canal.
Pagamento
Quando ocorre a troca de valor na Lightning Network, chamamos isso de "pagamento" em
comparação com uma "transação" na blockchain do Bitcoin.
Canal de pagamento
Uma relação financeira entre dois nós na Lightning Network é tipicamente implementada por
meio de transações de Bitcoin com múltiplas assinaturas (multisig) que compartilham o controle
sobre os bitcoin entre os dois nós da Lightning.
Roteamento versus envio

Ao contrário do Bitcoin, onde as transações são enviadas ao serem transmitidas para todos, a
Lightning é uma rede roteada em que os pagamentos são "roteados" por meio de um ou mais
canais de pagamento, seguindo um caminho do remetente ao destinatário.
Transação
Uma estrutura de dados que registra a transferência de controle sobre alguns fundos (por
exemplo, alguns bitcoin). A Lightning Network depende de transações do Bitcoin (ou de outra
blockchain) para rastrear o controle dos fundos.
Definições mais detalhadas desses e de muitos outros termos podem ser encontradas no[glossary].
Ao longo deste livro, explicaremos o significado desses conceitos e como essas tecnologias
realmente funcionam.
Ao longo deste livro, você verá "Bitcoin" com a primeira letra em maiúscula, o que se refere ao
sistema Bitcoin e é um substantivo próprio. Você também verá "bitcoin", com um b minúsculo,
que se refere à unidade de moeda. Cada bitcoin é subdividido em 100 milhões de unidades,
chamadas de "satoshi" (singular) ou "satoshis" (plural).
2
Agora que você está familiarizado com esses termos básicos, vamos avançar para um conceito com
o qual você já está confortável: confiança.
Confiança em Redes Descentralizadas

Você frequentemente ouvirá pessoas chamando o Bitcoin e a Lightning Network de "sem confiança"
(trustless). À primeira vista, isso pode ser confuso. Afinal, a confiança não é algo bom? Os próprios
bancos usam a confiança em seus nomes! Um sistema "sem confiança" não seria algo ruim?
O uso da palavra "sem confiança" tem o objetivo de transmitir a capacidade de operar sem a
necessidade de confiar nos outros participantes do sistema. Em um sistema descentralizado como o
Bitcoin, você sempre pode optar por fazer transações com alguém em quem confia. No entanto, o
sistema garante que você não possa ser enganado, mesmo se não puder confiar na outra parte
envolvida na transação. A confiança é uma propriedade desejável, mas não obrigatória do sistema.
Compare isso com sistemas tradicionais como o bancário, nos quais você precisa depositar sua
confiança em uma terceira parte, uma vez que ela controla seu dinheiro. Se o banco violar sua
confiança, talvez você possa buscar alguma reparação por meio de um órgão regulador ou tribunal,
mas isso demandará um custo enorme em termos de tempo, dinheiro e esforço.
"Sem confiança" não significa completamente sem confiança. Significa que a confiança não é um
requisito necessário para todas as transações e que você pode realizar transações mesmo com
pessoas em quem não confia, pois o sistema impede fraudes.
Antes de entrarmos em como a Lightning Network funciona, é importante entender um conceito

básico que subjacente ao Bitcoin, à Lightning Network e a muitos outros sistemas semelhantes: algo
que chamamos de um "protocolo de justiça" (fairness protocol). Um protocolo de justiça é uma
forma de alcançar resultados justos entre os participantes, que não precisam confiar uns nos
outros, sem a necessidade de uma autoridade central, sendo a base dos sistemas descentralizados
como o Bitcoin.
Justiça Sem Autoridade Central

Quando as pessoas têm interesses concorrentes, como podem estabelecer confiança suficiente para
se engajarem em comportamentos cooperativos ou transacionais? A resposta a essa pergunta reside
no cerne de várias disciplinas científicas e humanísticas, como economia, sociologia, psicologia
comportamental e matemática. Algumas dessas disciplinas nos fornecem respostas "soft" que
dependem de conceitos como reputação, justiça, moralidade e até religião. Outras disciplinas nos
fornecem respostas concretas que dependem apenas da suposição de que os participantes dessas
interações agirão de forma racional, com o interesse próprio como principal objetivo.
Em termos gerais, existem algumas maneiras de garantir resultados justos em interações entre
indivíduos que podem ter interesses conflitantes:
Exigir confiança
Você interage apenas com pessoas em quem já confia, devido a interações anteriores, reputação
ou relacionamentos familiares. Isso funciona bem em uma escala pequena, especialmente
dentro de famílias e grupos pequenos, sendo a base mais comum para comportamento
3
cooperativo. Infelizmente, isso não funciona em grande escala e sofre com viés tribalista
(favorável ao grupo).
Estado de direito
Estabelecer regras para interações que são aplicadas por uma instituição. Isso escala melhor,
mas não pode ser aplicado globalmente devido às diferenças de costumes e tradições, bem como
à incapacidade de expandir as instituições de aplicação. Um efeito colateral desagradável dessa
solução é que as instituições se tornam cada vez mais poderosas à medida que crescem, o que
pode levar à corrupção.
Terceiras partes confiáveis

Colocar um intermediário em cada interação para garantir imparcialidade. Combinado com o
"estado de direito" para fornecer supervisão dos intermediários, isso escala melhor, mas sofre
com o mesmo desequilíbrio de poder: os intermediários se tornam muito poderosos e podem
atrair corrupção. A concentração de poder leva a riscos sistêmicos e falhas sistêmicas ("grande
demais para falir").
Protocolos de justiça baseados em teoria dos jogos

Esta última categoria surge da combinação da internet e da criptografia e é o tema desta seção.
Vamos ver como eles funcionam e quais são suas vantagens e desvantagens.
Protocolos de Confiança Sem Intermediários
Sistemas criptográficos como o Bitcoin e a Lightning Network são sistemas que permitem realizar
transações com pessoas (e computadores) nas quais você não confia. Isso é frequentemente
chamado de operação "sem confiança", embora não seja completamente sem confiança. Você
precisa confiar no software que está executando e confiar que o protocolo implementado por esse
software resultará em resultados justos.
A grande diferença entre um sistema criptográfico como esse e um sistema financeiro tradicional é
que no sistema financeiro tradicional há um terceiro de confiança, como um banco, responsável por
garantir a equidade dos resultados. Um problema significativo com esses sistemas é que eles
concedem poder demais ao terceiro confiável e também são vulneráveis a um ponto único de falha.
Se o terceiro de confiança violar a confiança ou tentar fraudar, a base da confiança é rompida.
Ao estudar os sistemas criptográficos, você notará um padrão específico: em vez de depender de

um terceiro de confiança, esses sistemas tentam evitar resultados injustos usando um sistema de
incentivos e desincentivos. Em sistemas criptográficos, você deposita confiança noprotocolo, que é
efetivamente um sistema com um conjunto de regras que, se projetado corretamente, aplicará
corretamente os incentivos e desincentivos desejados. A vantagem desse método é dupla: você evita
confiar em um terceiro e reduz a necessidade de impor resultados justos. Desde que os
participantes sigam o protocolo acordado e permaneçam dentro do sistema, o mecanismo de
incentivo presente nesse protocolo alcança resultados justos sem necessidade de aplicação
coercitiva.
O uso de incentivos e desincentivos para alcançar resultados justos é um aspecto de um ramo da

matemática chamado teoria dos jogos, que estuda "modelos de interação estratégica entre
[1]
tomadores de decisão racionais." Sistemas criptográficos que controlam as interações financeiras
entre os participantes, como o Bitcoin e a Lightning Network, dependem muito da teoria dos jogos
4
para evitar que os participantes trapaceiem e permitir que participantes que não confiam uns nos
outros alcancem resultados justos.
Embora a teoria dos jogos e seu uso em sistemas criptográficos possam parecer confusos e
desconhecidos a princípio, é provável que você já esteja familiarizado com esses sistemas em sua
vida cotidiana; você simplesmente ainda não os reconhece. Na próxima seção, usaremos um
exemplo simples da infância para nos ajudar a identificar o padrão básico. Assim que você
entender o padrão básico, verá esse padrão em todos os lugares no espaço blockchain e o
reconhecerá rapidamente e intuitivamente.
Neste livro, chamamos esse padrão deprotocolo de justiça, definido como um processo que utiliza
um sistema de incentivos e/ou desincentivos para garantir resultados justos para participantes que
não confiam uns nos outros. A aplicação de um protocolo de justiça só é necessária para garantir
que os participantes não possam escapar dos incentivos ou desincentivos.
Um Protocolo de Justiça em Ação
Vamos analisar um exemplo de um protocolo de justiça com o qual você já pode estar
familiarizado.
Imagine um almoço em família, com um pai e dois filhos. As crianças são exigentes para comer e a
única coisa com a qual concordam em comer são batatas fritas. O pai preparou uma tigela de
batatas fritas. Os dois irmãos devem compartilhar o prato de batatas fritas. O pai precisa garantir
uma distribuição justa das batatas fritas para cada criança; caso contrário, terá que ouvir
reclamações constantes (talvez o dia todo), e sempre há a possibilidade de uma situação injusta
evoluir para violência. O que um pai deve fazer?
Existem algumas maneiras diferentes de alcançar a justiça nessa interação estratégica entre os dois
irmãos que não confiam um no outro e têm interesses concorrentes. O método ingênuo, mas
comumente usado, é o pai usar sua autoridade como um terceiro confiável: eles dividem a tigela de
batatas fritas em duas porções. Isso é semelhante às finanças tradicionais, onde um banco,
contador ou advogado atua como um terceiro confiável para evitar qualquer trapaça entre duas
partes que desejam fazer uma transação.
O problema com esse cenário é que ele atribui muito poder e responsabilidade nas mãos do
terceiro confiável. Nesse exemplo, o pai é totalmente responsável pela alocação igualitária das
batatas fritas, e as partes apenas esperam, observam e reclamam. As crianças acusam o pai de
mostrar favoritismo e não distribuir as batatas de forma justa. Os irmãos brigam pelas batatas,
gritando "essa batata é maior!" e envolvendo o pai na briga. Isso parece terrível, não é mesmo? O
pai deveria gritar mais alto? Tirar todas as batatas? Ameaçar nunca mais fazer batatas e deixar as
crianças ingratas passarem fome?
Existe uma solução muito melhor: os irmãos são ensinados a jogar um jogo chamado "dividir e
escolher". Em cada almoço, um dos irmãos divide a tigela de batatas fritas em duas porções e o
outro irmão escolhe qual porção deseja. Quase imediatamente, os irmãos entendem a dinâmica
desse jogo. Se aquele que está dividindo cometer um erro ou tentar trapacear, o outro irmão pode
"punir" escolhendo a porção maior. É do interesse de ambos os irmãos, mas especialmente daquele
que está dividindo, jogar de forma justa. Somente o trapaceiro sai perdendo nesse cenário. O pai
nem precisa usar sua autoridade ou impor justiça. Tudo o que o pai precisa fazer é fazer cumprir o
5
protocolo; desde que os irmãos não possam escapar de seus papéis atribuídos de "divisor" e
"escolhedor", o próprio protocolo garante um resultado justo sem a necessidade de qualquer
intervenção. O pai não pode mostrar favoritismo ou distorcer o resultado.
Embora as batalhas de batatas fritas infames dos anos 1980 ilustrem claramente o ponto,
qualquer semelhança entre o cenário anterior e quaisquer experiências reais de infância dos
autores com seus primos é totalmente coincidência… ou será que não é?
Primitivos de Segurança como Blocos de Construção
Para que um protocolo de justiça como esse funcione, é necessário ter certas garantias, ou
primitivas de segurança (security primitives), que podem ser combinadas para garantir a execução
do mesmo. A primeira primitiva de segurança é a ordem/sequenciamento estrito do tempo: a ação de
"dividir" deve ocorrer antes da ação de "escolher". Não é imediatamente óbvio, mas a menos que
seja possível garantir que a ação A ocorra antes da ação B, o protocolo se desfaz. A segunda
primitiva de segurança é o comprometimento com não repúdio. Cada irmão deve se comprometer
com seu papel escolhido: seja como divisor ou como escolhedor. Além disso, uma vez que a divisão
tenha sido concluída, o divisor fica comprometido com a divisão que criou—não pode repudiar
(negar) essa escolha e tentar novamente.
Sistemas criptográficos oferecem uma série de primitivas de segurança que podem ser combinadas
de diferentes maneiras para construir um protocolo de justiça. Além do sequenciamento e do
comprometimento, também podemos usar várias outras ferramentas:
• Funções hash para criar uma impressão digital dos dados, como forma de compromisso ou
como base para uma assinatura digital.
• Assinaturas digitais para autenticação, não repúdio e comprovação de posse de um segredo.
• Criptografia/descriptografia para restringir o acesso às informações apenas a participantes

autorizados.
Esta é apenas uma pequena lista de uma ampla "coleção" de primitivas de segurança e
criptográficas que estão em uso. Primitivas mais básicas e combinações são inventadas o tempo
todo.
No nosso exemplo da vida real, vimos uma forma de protocolo de justiça chamado "dividir e
escolher". Isso é apenas um dos inúmeros protocolos de equidade diferentes que podem ser
construídos combinando os blocos de construção das primitivas de segurança de diferentes
maneiras. Mas o padrão básico é sempre o mesmo: dois ou mais participantes interagem sem
confiar um no outro, envolvendo-se em uma série de etapas que fazem parte de um protocolo
acordado. As etapas do protocolo estabelecem incentivos e desincentivos para garantir que, se os
participantes forem racionais, trapacear seja contraproducente e a equidade seja o resultado
automático. A execução não é necessária para obter resultados justos - é apenas necessário evitar
que os participantes abandonem o protocolo acordado.
Agora que você entende esse padrão básico, começará a vê-lo em todos os lugares no Bitcoin, na
Lightning Network e em muitos outros sistemas. Vamos analisar alguns exemplos específicos em
seguida.
6
Exemplo do Protocolo de Justiça
O exemplo mais proeminente de um protocolo de equidade é o algoritmo de consenso Prova de

Trabalho (Proof 0f Work—PoW) do Bitcoin. No Bitcoin, os mineradores competem para verificar
transações e agregá-las em blocos. Para garantir que os mineradores não trapaceiem, sem confiar a
eles autoridade, o Bitcoin utiliza um sistema de incentivos e desincentivos. Os mineradores
precisam usar eletricidade e dedicar hardware para realizar um "trabalho" que é incorporado
como uma "prova" dentro de cada bloco. Isso é possível graças a uma propriedade das funções hash
em que o valor de saída é distribuído aleatoriamente em todo o intervalo de possíveis saídas. Se os
mineradores conseguirem produzir um bloco válido rápido o suficiente, eles são recompensados
recebendo a recompensa em bloco por aquele bloco. O fato de os mineradores terem que gastar
muita eletricidade antes que a rede considere seu bloco significa que eles têm um incentivo para
validar corretamente as transações no bloco. Se trapacearem ou cometerem algum erro, seu bloco é
rejeitado e a eletricidade usada para "prová-lo" é desperdiçada. Ninguém precisa forçar os
mineradores a produzir blocos válidos; a recompensa e o castigo os incentivam a fazê-lo. Tudo o
que o protocolo precisa fazer é garantir que apenas blocos válidos com Proof of Work sejam aceitos.
O padrão do protocolo de justiça também pode ser encontrado em muitos aspectos diferentes da
Lightning Network:
• Aqueles que financiam canais garantem que tenham uma transação de reembolso assinada
antes de publicarem a transação de financiamento.
• Sempre que um canal é movido para um novo estado, o estado anterior é "revogado" garantindo
que se alguém tentar transmiti-lo, perca todo o saldo e seja punido.
• Aqueles que encaminham pagamentos sabem que, se comprometerem fundos para

encaminhamento, podem receber um reembolso ou serem pagos pelo nó que os precede.
Mais uma vez, vemos esse padrão. Resultados justos não são impostos por nenhuma autoridade.
Eles surgem como consequência natural de um protocolo que recompensa a justiça e pune a
trapaça, um protocolo de justiça que direciona o autointeresse para alcançar resultados justos.
Bitcoin e a Lightning Network são ambas implementações de protocolos de justiça. Então, por que
precisamos da Lightning Network? O Bitcoin não é suficiente?
Motivação para a Lightning Network

O Bitcoin é um sistema que registra transações em um livro-razão público globalmente replicado.
Cada transação é vista, validada e armazenada por cada computador participante. Como você pode
imaginar, isso gera uma grande quantidade de dados e é difícil de escalar.
Conforme o Bitcoin e a demanda por transações aumentaram, o número de transações em cada

bloco aumentou até atingir o limite de tamanho do bloco. Uma vez que os blocos estejam "cheios",
as transações excedentes ficam em espera em uma fila. Muitos usuários aumentam as taxas que
estão dispostos a pagar para adquirir espaço para suas transações no próximo bloco.
Se a demanda continuar superando a capacidade da rede, um número crescente de transações dos

usuários ficará aguardando confirmação. A competição por taxas também aumenta o custo de cada
transação, tornando muitas transações de valor menor (por exemplo, microtransações)
7
completamente inviáveis durante períodos de demanda especialmente alta.
Para resolver esse problema, poderíamos aumentar o limite de tamanho do bloco para criar espaço
para mais transações. Um aumento na "oferta" de espaço de bloco levaria a um equilíbrio de preços
mais baixo para as taxas de transação.
No entanto, aumentar o tamanho do bloco transfere o custo para os operadores de nós e exige que
eles gastem mais recursos para validar e armazenar a blockchain. Como as blockchains são
protocolos de comunicação, cada nó é obrigado a conhecer e validar cada transação que ocorre na
rede. Além disso, uma vez validada, cada transação e bloco deve ser propagado para os "vizinhos"
do nó, multiplicando os requisitos de largura de banda. Assim, quanto maior o tamanho do bloco,
maiores são os requisitos de largura de banda, processamento e armazenamento para cada nó
individual. Aumentar a capacidade de transação dessa maneira tem o efeito indesejável de
centralizar o sistema, reduzindo o número de nós e operadores de nós. Como os operadores de nós
não são compensados por executar os nós, se os nós forem muito caros de serem mantidos, apenas
alguns operadores de nós bem financiados continuarão a executá-los.
Escalando Blockchains
Os efeitos colaterais de aumentar o tamanho do bloco ou diminuir o tempo do bloco em relação à

centralização da rede são graves, como mostram alguns cálculos com os números.
Vamos supor que o uso do Bitcoin cresça a ponto da rede ter que processar 40.000 transações por
segundo, que é aproximadamente o nível de processamento de transações da rede Visa durante o
uso de pico.
Considerando uma média de 250 bytes por transação, isso resultaria em um fluxo de dados de 10
megabytes por segundo (MBps) ou 80 megabits por segundo (Mbps) apenas para receber todas as
transações. Isso não inclui o tráfego adicional de encaminhamento das informações das transações
para outros pares (peers). Embora 10 MBps não pareça extremo no contexto de velocidades de fibra
ótica de alta velocidade e redes móveis 5G, isso efetivamente excluiria qualquer pessoa que não
possa atender a esse requisito de executar um nó, especialmente em países onde a internet de alta
velocidade não é acessível ou amplamente disponível a um custo acessível.
Os usuários também têm muitas outras demandas em sua largura de banda e não pode ser
esperado que gastem tanto apenas para receber transações.
Além disso, armazenar essas informações localmente resultaria em 864 gigabytes por dia. Isso
equivale aproximadamente a um terabyte de dados, ou seja, o tamanho de um disco rígido.
Verificar 40.000 assinaturas do algoritmo de criptografia de curva elíptica (Elliptic Curve Digital
Signature Algorithm—ECDSA) por segundo também é quase inviável (see this article on
StackExchange), tornando o processo de download de bloco inicial (Initial Block Download—IBD)
da blockchain do Bitcoin (sincronização e verificação de tudo a partir do bloco de gênese) quase
impossível sem hardware muito caro.
Embora 40.000 transações por segundo pareçam ser um número alto, isso só alcança a paridade
com redes de pagamento financeiro tradicionais em momentos de pico. Inovações em pagamentos
de máquina para máquina, microtransações e outras aplicações provavelmente aumentarão a
demanda para níveis muito superiores a isso.
8
Em termos simples: não é possível dimensionar uma blockchain para validar todas as transações do
mundo de forma descentralizada.
E se cada nó não precisasse saber e validar todas as transações? E se houvesse uma maneira de ter
transações fora da cadeia (off-chain) escaláveis, sem perder a segurança da rede Bitcoin?
Em fevereiro de 2015, Joseph Poon e Thaddeus Dryja propuseram uma possível solução para o
problema de escalabilidade do Bitcoin, com a publicação de "The Bitcoin Lightning Network:
[2]
Scalable Off-Chain Instant Payments."
No artigo (agora desatualizado), Poon e Dryja estimam que, para que o Bitcoin alcance as 47.000
transações por segundo processadas em seu pico pelo Visa, seriam necessários blocos de 8 GB. Isso
tornaria a execução de um nó completamente inviável para qualquer pessoa além de empresas em
larga escala e operações de nível industrial. O resultado seria uma rede na qual apenas alguns
usuários seriam capazes de validar o estado do livro-razão. O Bitcoin depende dos usuários
validarem o livro-razão por si mesmos, sem confiar explicitamente em terceiros, para se manter
descentralizado. Ao impedir que os usuários executem nós, devido aos altos custos, o usuário médio
seria forçado a confiar em terceiros para descobrir o estado do livro-razão, o que, em última
instância, quebraria o modelo de confiança do Bitcoin.
A Lightning Network propõe uma nova rede, uma segunda camada, na qual os usuários podem
fazer pagamentos entre si de forma ponto a ponto (peer-to-peer), sem a necessidade de publicar
uma transação na blockchain do Bitcoin para cada pagamento. Os usuários podem pagar uns aos
outros na Lightning Network quantas vezes quiserem, sem criar transações adicionais no Bitcoin
ou incorrer em taxas on-chain. Eles apenas utilizam a blockchain do Bitcoin para carregar bitcoin
inicialmente na Lightning Network e para realizar a liquidação final, ou seja, para remover bitcoin
da Lightning Network. O resultado é que muitos mais pagamentos em Bitcoin podem ocorrer fora
da cadeia, sendo necessário validar e armazenar apenas as transações iniciais de carregamento e as
transações finais de liquidação pelos nós do Bitcoin. Além de reduzir o ônus sobre os nós, os
pagamentos na Lightning Network são mais baratos para os usuários, pois eles não precisam pagar
taxas de blockchain, e mais privados, pois não são publicados para todos os participantes da rede e
também não são armazenados permanentemente.
Embora a Lightning Network tenha sido inicialmente concebida para o Bitcoin, ela pode ser
implementada em qualquer blockchain que atenda a alguns requisitos técnicos básicos. Outras
blockchains, como o Litecoin, já suportam a Lightning Network. Além disso, várias outras
blockchains estão desenvolvendo soluções semelhantes de segunda camada, ou "camada 2", para
ajudá-las a escalar.
Os Recursos Definidores da Lightning Network

A Lightning Network é uma rede que opera como um protocolo de segunda camada em cima do
Bitcoin e outras blockchains. A Lightning Network permite pagamentos rápidos, seguros, privados,
sem necessidade de confiança e sem necessidade de permissão. Aqui estão algumas das
características da Lightning Network:
• Os usuários da Lightning Network podem rotear pagamentos entre si a baixo custo e em tempo
real.
9
• Usuários que realizam trocas de valor na Lightning Network não precisam esperar por
confirmações de blocos para os pagamentos.
• Uma vez que um pagamento na Lightning Network é concluído, geralmente em questão de

segundos, ele é final e não pode ser revertido. Assim como uma transação de Bitcoin, um
pagamento na Lightning Network só pode ser reembolsado pelo destinatário.
• Enquanto as transações de Bitcoin na cadeia (on-chain) são transmitidas e verificadas por todos
os nós da rede, os pagamentos roteados na Lightning Network são transmitidos entre pares de
nós e não são visíveis para todos, resultando em uma privacidade muito maior.
• Ao contrário das transações na rede Bitcoin, os pagamentos roteados na Lightning Network não
precisam ser armazenados permanentemente. A Lightning, portanto, utiliza menos recursos e,
consequentemente, é mais barata. Essa propriedade também traz benefícios para a privacidade.
• A Lightning Network utiliza o roteamento em camadas (onion routing), semelhante ao

protocolo utilizado pela rede de privacidade The Onion Router (Tor), de modo que mesmo os
nós envolvidos no roteamento de um pagamento estão cientes apenas de seu predecessor e
sucessor na rota do pagamento.
• Quando usada em cima do Bitcoin, a Lightning Network utiliza bitcoin reais, que estão sempre
na posse (custódia) e controle total do usuário. A Lightning não é um token ou moeda separada,
ela é Bitcoin.
Casos de Uso da Lightning Network, Usuários e Suas

Histórias
Para compreender melhor como a Lightning Network funciona na prática e por que as pessoas a
utilizam, vamos acompanhar diversos usuários e suas histórias.
Nos exemplos apresentados, algumas pessoas já utilizam o Bitcoin e outras são novatas na rede do
Bitcoin. Cada pessoa e sua história, conforme listadas aqui, ilustram um ou mais casos de uso
específicos. Voltaremos a essas histórias ao longo deste livro:
Consumidor
Alice é uma usuária de Bitcoin que deseja fazer pagamentos rápidos, seguros, baratos e privados
para compras de varejo de pequeno valor. Ela compra café usando Bitcoin, utilizando a
Lightning Network.
Comerciante
Bob é dono de uma cafeteria chamada "Bob’s Cafe". Pagamentos em Bitcoin na cadeia principal
(on-chain) não são escaláveis para pequenas quantias, como uma xícara de café. Por isso, ele
utiliza a Lightning Network para aceitar pagamentos em Bitcoin quase instantaneamente e com
baixas taxas.
Negócio de serviços de software

Chan é um empreendedor chinês que vende serviços de informação relacionados à Lightning
Network, Bitcoin e outras criptomoedas. Chan vende esses serviços de informação pela internet,
implementando micropagamentos na Lightning Network. Além disso, Chan implementou um
serviço de provedor de liquidez que aluga capacidade de canal de entrada na Lightning
10
Network, cobrando uma pequena taxa em bitcoin por cada período de aluguel.
Gamer
Dina é uma adolescente gamer da Rússia. Ela joga vários jogos de computador, mas seus
favoritos são aqueles que possuem uma "economia do jogo" baseada em dinheiro real. Enquanto
joga, ela também ganha dinheiro adquirindo e vendendo itens virtuais dentro dos jogos. A
Lightning Network permite que ela realize transações em pequenas quantias para comprar itens
do jogo, além de ganhar pequenas quantias ao completar missões.
Conclusão
Neste capítulo, discutimos o conceito fundamental que sustenta tanto o Bitcoin quanto a Lightning
Network: o protocolo de justiça.
Analisamos a história da Lightning Network e as motivações por trás das soluções de escalabilidade
de segunda camada para o Bitcoin e outras redes baseadas em blockchain.
Aprendemos terminologia básica, incluindo nó, canal de pagamento, transações na cadeia principal
(on-chain) e pagamentos fora da cadeia (off-chain).
Por fim, conhecemos Alice, Bob, Chan e Dina, que acompanharemos ao longo do restante do livro.
No próximo capítulo, conheceremos Alice e acompanharemos seu processo de pensamento
enquanto ela seleciona uma carteira Lightning e se prepara para fazer seu primeiro pagamento na
Lightning Network para comprar uma xícara de café na Bob’s Cafe.
[1] The Wikipedia entry on game theory provides more information.

[2] Joseph Poon and Thaddeus Dryja. "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments." DRAFT Version 0.5.9.2.
January 14, 2016. https://lightning.network/lightning-network-paper.pdf.
11
Começando
Neste capítulo, começaremos onde a maioria das pessoas começa ao se deparar com a Lightning
Network pela primeira vez—escolhendo o software para participar da economia da LN. Vamos
examinar as escolhas de dois usuários que representam um caso de uso comum para a Lightning
Network e aprender por exemplo. Alice, uma cliente de uma cafeteria, usará uma carteira
Lightning em seu dispositivo móvel para comprar café na Bob’s Cafe. Bob, um comerciante, usará
um nó e uma carteira Lightning para executar um sistema de ponto de venda em sua cafeteria,
permitindo que ele aceite pagamentos pela Lightning Network.
A Primeira Carteira Relâmpago de Alice

Alice é uma usuária de Bitcoin há muito tempo. Nós a conhecemos no Capítulo 1 de Mastering
[1]
Bitcoin, quando ela comprou uma xícara de café Bob’s Cafe usando uma transação em Bitcoin. Se
você ainda não está familiarizado com o funcionamento das transações em Bitcoin ou precisa
relembrar, por favor, leia o livro Mastering Bitcoin ou o resumo em [bitcoin_fundamentals_review].
Alice descobriu recentemente que a cafeteria de Bob agora está aceitando pagamentos pela
LN—Lightning Network! Alice está ansiosa para aprender e experimentar a Lightning Network; ela
quer ser uma das primeiras clientes do Bob a usar a LN. Para fazer isso, primeiro, Alice precisa
escolher uma carteira Lightning que atenda às suas necessidades.
Alice não deseja confiar a custódia de seus bitcoin a terceiros. Ela aprendeu o suficiente sobre
criptomoedas para saber como usar uma carteira. Além disso, ela quer uma carteira móvel (mobile
wallet) para poder fazer pequenos pagamentos enquanto está em movimento, então ela escolhe a
carteira Eclair, uma popular carteira móvel Lightning não custodial. Vamos aprender mais sobre
como e por que ela fez essas escolhas.
Nós da Lightning
A Lightning Network é acessada por meio de aplicativos de software que podem se comunicar por
meio do protocolo LN. Um nó da Lightning Network (nó LN ou simplesmente nó) é um aplicativo de
software que possui três características importantes. Primeiro, os nós da Lightning são carteiras, o
que significa que eles enviam e recebem pagamentos na Lightning Network, assim como na rede
Bitcoin. Segundo, os nós devem se comunicar em uma base peer-to-peer (ponto a ponto) com outros
nós da Lightning, criando a rede. Por fim, os nós da Lightning também precisam ter acesso à
blockchain do Bitcoin (ou de outras blockchains para outras criptomoedas) para garantir os fundos
utilizados nos pagamentos.
Os usuários têm o mais alto grau de controle ao executar seu próprio nó Bitcoin e nó Lightning. No
entanto,os nós da Lightning também podem usar um cliente Bitcoin leve, comumente referido
como verificação simplificada de pagamento (Simplified Payment Verification—SPV), para interagir
com a blockchain do Bitcoin.
Lightning Explorers
Os exploradores da LN são ferramentas úteis para mostrar as estatísticas de nós, canais e
1
capacidade da rede.
Segue uma lista inesgotável:
• 1ML Lightning explorer
• ACINQ’s Lightning explorer, com visualizações elaboradas
• Amboss Space Lightning explorer, com métricas da comunidade e visualizações intuitivas
• Fiatjaf’s Lightning explorer com muitos diagramas
• hashXP Lightning explorer
Observe que, ao usar exploradores da Lightning, assim como com outros exploradores de
blocos, a privacidade pode ser uma preocupação. Se os usuários não forem cuidadosos, o site
pode rastrear seus endereços IP e coletar registros de comportamento (por exemplo, os nós
nos quais os usuários estão interessados).
Além disso, é importante observar que, como não há um consenso global sobre o gráfico atual
da Lightning ou o estado atual de qualquer política de canal existente, os usuários nunca
devem confiar nos exploradores da Lightning para obter as informações mais atualizadas.
Além disso, à medida que os usuários abrem, fecham e atualizam canais, o gráfico será
alterado e os exploradores individuais da Lightning podem não estar atualizados. Utilize os
exploradores da Lightning para visualizar a rede ou obter informações, mas não como uma
fonte autoritativa do que está acontecendo na Lightning Network. Para ter uma visão
autoritativa da Lightning Network, execute seu próprio nó Lightning que irá construir um
gráfico de canais e coletar várias estatísticas, as quais você pode visualizar por meio de uma
interface baseada na web.
Carteiras Relâmpago
O termo carteira Lightning é um tanto ambíguo, pois pode descrever uma variedade ampla de
componentes combinados com uma interface de usuário. Os componentes mais comuns do
software de carteira Lightning incluem:
• Um repositório de chaves que armazena segredos, como chaves privadas
• Um nó LN (Lightning node) que se comunica na rede peer-to-peer, como descrito

anteriormente.
• Um nó Bitcoin que armazena os dados da blockchain e se comunica com outros nós Bitcoin
• Um banco de dados "mapa" de nós e canais que são anunciados na Lightning Network
• Um gerenciador de canais que pode abrir e fechar canais da LN
• Um sistema de roteamento que pode encontrar um caminho de canais conectados desde a

origem do pagamento até o destino do pagamento
Uma carteira Lightning pode conter todas essas funções, atuando como uma carteira "completa",
sem depender de serviços de terceiros. Ou um ou mais desses componentes podem depender
(parcial ou totalmente) de serviços de terceiros que intermediam essas funções.
2
Uma distinção chave (trocadilho intencional) é se a função de armazenamento de chaves é interna
ou terceirizada. Nas blockchains, o controle das chaves determina a custódia dos fundos, conforme
registrado pela frase "se as chaves são suas, as moedas são suas; se as chaves não são suas, as
moedas não são suas".Qualquer carteira que terceiriza a gestão das chaves é chamada de carteira
custodial, pois uma terceira parte agindo como custodiante tem controle sobre os fundos do
usuário, e não o próprio usuário.Uma carteira não custodial ouautocustodial, por comparação, é
aquela em que o armazenamento de chaves faz parte da própria carteira, e as chaves são
controladas diretamente pelo usuário. O termo carteira não custodial apenas implica que o
armazenamento de chaves é local e está sob o controle do usuário. No entanto, um ou mais dos
outros componentes da carteira podem ou não ser terceirizados e depender de terceiros confiáveis.
As blockchains, especialmente as blockchains abertas como o Bitcoin, buscam minimizar ou

eliminar a confiança em terceiros e empoderar os usuários.Isso é frequentemente chamado de
modelo "sem confiança", embora "confiança minimizada" seja um termo mais adequado. Em tais
sistemas, o usuário confia nas regras do software, não em terceiros. Portanto, a questão do controle
das chaves é um aspecto fundamental a ser considerado ao escolher uma carteira Lightning.
Todos os outros componentes de uma carteira Lightning trazem considerações semelhantes de

confiança. Se todos os componentes estiverem sob o controle do usuário, então a quantidade de
confiança em terceiros é minimizada, proporcionando máximo poder ao usuário. No entanto, isso
envolve uma compensação (troca) direta, pois com esse poder vem a correspondente
responsabilidade de gerenciar um software complexo.
Cada usuário deve considerar suas próprias habilidades técnicas antes de decidir que tipo de
carteira Lightning usar. Aqueles com habilidades técnicas avançadas devem utilizar uma carteira
Lightning que coloque todos os componentes sob o controle direto do usuário. Já aqueles com
habilidades técnicas mais limitadas, mas com o desejo de controlar seus fundos, devem escolher
uma carteira Lightning não custodial. Frequentemente, a confiança nesses casos está relacionada à
privacidade. Se os usuários decidem terceirizar alguma funcionalidade para uma terceira parte,
geralmente eles abrem mão de um pouco de privacidade, pois essa terceira parte poderá obter
algumas informações sobre eles.
Por fim, aqueles que buscam simplicidade e conveniência, mesmo às custas de controle e
segurança, podem escolher uma carteira Lightning custodial. Essa é a opção menos desafiadora
tecnicamente, mas ela enfraquece o modelo de confiança das criptomoedas e, portanto, deve ser
considerada apenas como um passo inicial em direção a um maior controle e autossuficiência.
Existem muitas maneiras pelas quais as carteiras podem ser caracterizadas ou categorizadas. As
perguntas mais importantes a serem feitas sobre uma carteira específica são:
1. Esta carteira Lightning tem um nó Lightning completo ou usa um nó Lightning de terceiros?
2. Esta carteira Lightning tem um nó Bitcoin completo ou usa um nó Bitcoin de terceiros?
3. Esta carteira Lightning armazena suas próprias chaves sob controle do usuário (autocustódia)
ou as chaves são mantidas por um terceiro?
Se uma carteira Lightning utiliza um nó Lightning de terceiros, é esse nó Lightning de terceiros

que decide como se comunicar com o Bitcoin. Portanto, o uso de um nó Lightning de terceiros
implica que você também está usando um nó Bitcoin de terceiros. Somente quando a carteira
3
Lightning utiliza seu próprio nó Lightning é que existe a escolha entre um nó Bitcoin completo
ou um nó Bitcoin de terceiros.
No nível mais alto de abstração, as questões 1 e 3 são as mais elementares. A partir dessas duas
perguntas, podemos derivar quatro categorias possíveis. Podemos colocar essas quatro categorias
em um quadrante, como visto na Lightning wallets quadrant. Mas lembre-se de que esta é apenas
uma maneira de categorizar as carteiras Lightning.
Table 1. Lightning wallets quadrant
Nó Lightning Completo Nó Lightning de Terceiros
Autocustódia Q1: Alta habilidade técnica, Q2: Habilidades técnicas abaixo

menor confiança em terceiros, da média, confiança abaixo da
mais sem permissão média em terceiros, requer
algumas permissões
Custodial Q3: Habilidades técnicas acima Q4: Habilidades técnicas baixas,

da média, confiança acima da alta confiança em terceiros,
média em terceiros, requer menos sem permissão
algumas permissões
O quadrante 3 (Q3), onde um nó Lightning completo é usado, mas as chaves são mantidas por um
custodiante (terceiro), atualmente não é comum. As futuras carteiras desse quadrante podem
permitir que um usuário se preocupe com os aspectos operacionais de seu nó, mas depois delegue o
acesso às chaves a uma terceira parte que utiliza principalmente armazenamento a frio (cold
storage).
As carteiras Lightning podem ser instaladas em uma variedade de dispositivos, incluindo laptops,
servidores e dispositivos móveis. Para executar um nó completo da Lightning, você precisará usar
um servidor ou computador desktop, pois dispositivos móveis e laptops geralmente não possuem
capacidade, processamento, vida útil da bateria e conectividade suficientes.
A categoria nós Lightning de terceiros pode novamente ser subdividida:
Leve
Isso significa que a carteira não opera um nó da Lightning e, portanto, precisa obter informações
sobre a Lightning Network pela internet a partir do nó do Lightning de outra pessoa.
None
Isso significa que não apenas o nó do Lightning é operado por uma terceira parte, mas a maior
parte da carteira é operada por uma terceira parte na nuvem. Esta é uma carteira custodial em
que outra pessoa controla a custódia dos fundos.
Essas subcategorias são usadas na Exemplos de carteiras Lightning populares.
Outros termos que precisam de explicação na Exemplos de carteiras Lightning populares na coluna
"Nó Bitcoin" são:
4
Neutrino
Esta carteira não opera um nó Bitcoin. Em vez disso, ela acessa um nó Bitcoin operado por outra
pessoa (uma terceira parte) por meio do Protocolo Neutrino.
Electrum
Esta carteira não opera um nó Bitcoin. Em vez disso, ela acessa um nó Bitcoin operado por outra
pessoa (uma terceira parte) por meio do Protocolo Electrum.
Bitcoin Core
Esta é uma implementação de um nó Bitcoin.
btcd
Esta é outra implementação de um nó Bitcoin.
Na Exemplos de carteiras Lightning populares, vemos alguns exemplos de aplicativos de carteira e

nó do Lightning atualmente populares para diferentes tipos de dispositivos. A lista é classificada
primeiro por tipo de dispositivo e depois em ordem alfabética.
Table 2. Exemplos de carteiras Lightning populares
Aplicativo Dispositivo Nó Lightning Nó Bitcoin Armazenamento

de chaves
Blue Wallet Mobile Nenhum Nenhum Custodial
Breez Wallet Mobile Nó Completo Neutrino Autocustódia
Eclair Mobile Mobile Leve Electrum Autocustódia
lntxbot Mobile Nenhum Nenhum Custodial
Muun Mobile Leve Neutrino Autocustódia
Phoenix Wallet Mobile Leve Electrum Autocustódia
Zeus Mobile Nó Completo Bitcoin Core/btcd Autocustódia
Electrum Desktop Nó Completo Bitcoin Autocustódia

Core/Electrum
Zap Desktop Desktop Nó Completo Neutrino Autocustódia
c-lightning Servidor Nó Completo Bitcoin Core Autocustódia
Eclair Server Servidor Nó Completo Bitcoin Autocustódia

Core/Electrum
lnd Servidor Nó Completo Bitcoin Core/btcd Autocustódia
Testnet Bitcoin
O sistema Bitcoin oferece uma cadeia alternativa para fins de teste chamada testnet, em contraste
com a cadeia Bitcoin "normal" conhecida como mainnet. Na testnet, a moeda utilizada é o testnet
bitcoin (tBTC), que é uma cópia sem valor do bitcoin usada exclusivamente para testes. Todas as
funções do Bitcoin são replicadas exatamente, mas o dinheiro não tem valor, então você
literalmente não tem nada a perder!
5
Algumas carteiras Lightning também podem operar na testnet, permitindo que você faça
pagamentos Lightning com testnet bitcoin, sem correr o risco de fundos reais. Essa é uma ótima
maneira de experimentar o Lightning com segurança. O Eclair Mobile, que Alice usa neste capítulo,
é um exemplo de uma carteira Lightning que suporta operação na testnet.
Você pode obter algum tBTC para brincar em um testnet bitcoin faucet, que distribui tBTC
gratuitamente sob demanda. Aqui estão alguns faucets da testnet:
<li><a href="https://coinfaucet.eu/en/btc-testnet/">https://coinfaucet.eu/en/btc-
testnet</a></li>
<li><a href="https://testnet-faucet.mempool.co/">https://testnet-
faucet.mempool.co</a></li>
<li><a
href="https://bitcoinfaucet.uo1.net/">https://bitcoinfaucet.uo1.net</a></li>
<li><a
href="https://testnet.help/en/btcfaucet/testnet">https://testnet.help/en/btcfaucet/tes
tnet</a></li>
</ul>
Todos os exemplos deste livro podem ser replicados exatamente na testnet com tBTC, para que você
possa acompanhar sem correr o risco de perder dinheiro real.
Equilibrando Complexidade e Controle

As carteiras Lightning precisam encontrar um equilíbrio cuidadoso entre complexidade e controle
do usuário. Aquelas que oferecem ao usuário o maior controle sobre seus fundos, o mais alto grau
de privacidade e a maior independência de serviços de terceiros são necessariamente mais
complexas e difíceis de operar. Conforme a tecnologia avança, algumas dessas compensações se
tornarão menos acentuadas e os usuários poderão ter mais controle sem aumentar a complexidade.
No entanto, por enquanto, diferentes empresas e projetos estão explorando diferentes posições
nesse espectro de controle e complexidade, na esperança de encontrar o "ponto ideal" para os
usuários que estão segmentando.
Ao selecionar uma carteira, tenha em mente que, mesmo que você não perceba essas
compensações, elas ainda existem. Por exemplo, muitas carteiras tentarão remover o ônus da
gestão de canais de seus usuários. Para fazer isso, elas introduzem nós centrais (hub nodes) aos
quais todas as suas carteiras se conectam automaticamente. Embora essa compensação simplifique
a interface do usuário e a experiência do usuário, ela introduz um único ponto de falha (Single
Point of Failure—SPoF) à medida que esses nós centrais se tornam indispensáveis para o
funcionamento da carteira. Além disso, depender de um "hub" desse tipo pode reduzir a
privacidade do usuário, pois o hub sabe o remetente e, potencialmente (se estiver construindo a
rota de pagamento em nome do usuário), também o destinatário de cada pagamento feito pela
carteira do usuário.
Na próxima seção, vamos voltar para nossa primeira usuária e acompanhar a configuração de sua
primeira carteira Lightning. Ela escolheu uma carteira mais sofisticada do que as carteiras
custodiais mais fáceis. Isso nos permite mostrar parte da complexidade subjacente e introduzir o
funcionamento interno de uma carteira avançada. Você pode descobrir que sua primeira carteira
6
ideal prioriza facilidade de uso, aceitando algumas das compensações de controle e privacidade. Ou
talvez você seja um usuário avançado e queira executar seus próprios nós Lightning e Bitcoin como
parte de sua solução de carteira.
Baixando e Instalando uma Carteira Lightning

Ao procurar por uma nova carteira de criptomoedas, é fundamental ter muito cuidado ao
selecionar uma fonte segura para o software.
Infelizmente, muitos aplicativos de carteira falsos podem roubar seu dinheiro, e alguns deles até
mesmo encontram seu caminho em lojas de aplicativos confiáveis e supostamente verificadas,
como a App Store da Apple e a Google Play Store. Sempre exerça extrema cautela, quer você esteja
instalando sua primeira ou décima carteira. Um aplicativo malicioso não só pode roubar qualquer
dinheiro que você confiar a ele, mas também pode ser capaz de roubar chaves e senhas de outros
aplicativos ao comprometer o sistema operacional do seu dispositivo móvel.
Alice usa um dispositivo Android e usará a Google Play Store para baixar e instalar a carteira Eclair.
Ao pesquisar na Google Play, ela encontra uma entrada para "Eclair Mobile", conforme mostrado na
Eclair Mobile na Google Play Store.
Figure 1. Eclair Mobile na Google Play Store
É possível experimentar e testar todo o software relacionado ao Bitcoin sem nenhum risco
(exceto pelo seu próprio tempo) usando testnet bitcoins. Você também pode baixar a carteira
Eclair para testnet e experimentar o Lightning (na testnet) acessando a Google Play Store.
Alice nota alguns elementos diferentes nesta página que a ajudam a verificar que esta é, muito
provavelmente, a carteira "Eclair Mobile" correta que ela está procurando. Primeiramente, a
[2]
organização ACINQ está listada como desenvolvedora desta carteira móvel, o que Alice sabe em
sua pesquisa que é o desenvolvedor correto. Em segundo lugar, a carteira foi instalada "10.000+"
vezes e possui mais de 320 avaliações positivas. É improvável que este seja um aplicativo malicioso
que tenha se infiltrado na Google Play Store. Em terceiro lugar, ela acessa o ACINQ website. Ela
verifica que a página da web é segura ao verificar se o endereço começa com "https" ou se há um
cadeado na barra de endereço em alguns navegadores. No site, ela vai para a seção de Downloads
ou procura pelo link para a Google Play Store. Ela encontra o link e clica nele. Ela compara e
verifica que esse link a leva para o exato aplicativo na Google Play Store. Satisfeita com essas
descobertas, Alice instala o aplicativo Eclair em seu dispositivo móvel.
Sempre tenha muito cuidado ao instalar software em qualquer dispositivo. Existem muitas
carteiras de criptomoedas falsas que não apenas roubarão seu dinheiro, mas também podem
7
comprometer todos os outros aplicativos em seu dispositivo.
Criando uma Nova Carteira

Quando Alice abre o aplicativo Eclair Mobile pela primeira vez, ela se depara com a opção de "Criar
uma Nova Carteira" ou "Importar uma Carteira Existente". Alice criará uma nova carteira, mas
vamos primeiro discutir por que essas opções são apresentadas aqui e o que significa importar uma
carteira existente.
Responsabilidade com a Custódia das Chaves
Conforme mencionado no início desta seção, o Eclair é uma carteira não custodial, o que significa
que Alice tem a custódia exclusiva das chaves usadas para controlar seus bitcoin. Isso também
significa que Alice é responsável por proteger e fazer backup dessas chaves. Se Alice perder as
chaves, ninguém poderá ajudá-la a recuperar os bitcoin, e eles serão perdidos para sempre.
Com a carteira Eclair Mobile, Alice tem a custódia e o controle das chaves e, portanto, a
responsabilidade total de manter as chaves seguras e fazer backup delas. Se ela perder as
chaves, perderá os bitcoin, e ninguém poderá ajudá-la a recuperar essa perda!
Palavras Mnemônicas
Similarmente à maioria das carteiras de Bitcoin, o Eclair Mobile fornece uma frase mnemônica
(também às vezes chamada de "seed" ou "seed phrase") para que Alice faça o backup. A frase
mnemônica consiste em 24 palavras em inglês, selecionadas aleatoriamente pelo software e usadas
como base para as chaves que são geradas pela carteira. Alice pode usar a frase mnemônica para
restaurar todas as transações e fundos na carteira Eclair Mobile no caso de perda do dispositivo
móvel, um bug de software ou corrupção de memória.
O termo correto para essas palavras de backup é "frase mnemônica". Evitamos o uso do termo
"seed" (semente) para se referir à frase mnemônica, porque, embora seu uso seja comum, ele é
incorreto.
Quando Alice escolhe criar uma nova carteira, ela verá uma tela com sua frase mnemônica, que se
parece com a captura de tela na Frase mnemônica de nova carteira.
8
Figure 2. Frase mnemônica de nova carteira
Na Frase mnemônica de nova carteira, nós intencionalmente ocultamos parte da frase mnemônica
para evitar que os leitores deste livro a reutilizem.
Armazenando a Mnemônica com Segurança
Alice precisa ter cuidado ao armazenar a frase mnemônica de uma maneira que evite roubo, mas
também evite perdas acidentais. A maneira recomendada de equilibrar adequadamente esses
riscos é escrever duas cópias da frase mnemônica em papel, com cada uma das palavras
numeradas—a ordem importa.
Após Alice ter registrado a frase mnemônica e tocar em "OK, ENTENDI" na tela, ela será
apresentada a um questionário para garantir que ela tenha registrado corretamente a frase
mnemônica. O questionário solicitará três ou quatro palavras aleatórias. Alice não estava
esperando um questionário, mas, como ela registrou corretamente a frase mnemônica, ela passa
pelo questionário sem dificuldades.
9
Após Alice ter registrado a frase mnemônica e passado pelo questionário, ela deve armazenar cada
cópia em um local seguro separado, como uma gaveta trancada da escrivaninha ou um cofre à
prova de fogo.
Nunca tente criar um esquema de segurança "faça você mesmo" que se desvie de qualquer
forma das recomendações das melhores práticas em segurança Armazenando a Mnemônica
com Segurança. Não divida sua frase mnemônica ao meio, faça capturas de tela, armazene-a
em unidades USB ou em serviços de armazenamento em nuvem, criptografe-a ou tente
qualquer outro método não convencional. Ao fazer isso, você desequilibra a balança de tal
forma que corre o risco de perda permanente. Muitas pessoas perderam fundos não por
roubo, mas porque tentaram soluções não convencionais sem ter a expertise necessária para
equilibrar os riscos envolvidos. A recomendação das melhores práticas é cuidadosamente
considerada por especialistas e adequada para a grande maioria dos usuários.
Após inicializar sua carteira Eclair Mobile, Alice verá um breve tutorial que destaca os vários
elementos da interface do usuário. Não iremos reproduzir o tutorial aqui, mas exploraremos todos
esses elementos à medida que acompanharmos a tentativa de Alice de comprar uma xícara de café!
Carregando Bitcoin na Carteira

Alice agora possui uma carteira Lightning. No entanto, ela está vazia! Agora ela enfrenta um dos
aspectos mais desafiadores deste experimento: ela precisa encontrar uma maneira de adquirir
alguns bitcoins e carregá-los em sua carteira Eclair.
Se Alice já possui bitcoin em outra carteira, ela pode optar por enviar esses bitcoin para sua
carteira Eclair em vez de adquirir novos bitcoin para carregar em sua nova carteira.
Adquirindo Bitcoin
Existem várias maneiras pelas quais Alice pode adquirir bitcoin:
• Ela pode trocar parte de sua moeda nacional (por exemplo, USD) em uma corretora de
criptomoedas.
• Ela pode comprar alguns de um amigo, ou um conhecido de um encontro Bitcoin, em troca de

dinheiro.
• Ela pode encontrar um Caixa Eletrônico de Bitcoin em sua área, que funciona como uma
máquina de venda automática, vendendo bitcoin por dinheiro.
• Ela pode oferecer suas habilidades ou um produto que ela vende e aceitar pagamento em
bitcoin.
• Ela pode pedir a seu empregador ou clientes que a paguem em bitcoin.
Todas essas métodos têm diferentes níveis de dificuldade e muitos envolvem o pagamento de taxas.
Alguns também podem exigir que Alice forneça documentos de identificação para cumprir as
regulamentações bancárias locais. No entanto, com todos esses métodos, Alice será capaz de
10
receber bitcoin.
Recebendo Bitcoin
Vamos supor que Alice tenha encontrado um caixa eletrônico de Bitcoin local e decidiu comprar
alguns bitcoins em troca de dinheiro em espécie. Um exemplo de um caixa eletrônico de Bitcoin,
construído pela empresa Lamassu, é mostrado na Um caixa eletrônico Bitcoin Lamassu. Esses
caixas eletrônicos de Bitcoin aceitam moeda nacional (dinheiro em espécie) por meio de uma
abertura para inserção do dinheiro e enviam bitcoin para um endereço Bitcoin escaneado a partir
da carteira do usuário usando uma câmera embutida.
Figure 3. Um caixa eletrônico Bitcoin Lamassu
Para receber os bitcoin em sua carteira Eclair Lightning, Alice precisará fornecer um endereço
Bitcoin da carteira Eclair Lightning ao caixa eletrônico. O caixa eletrônico poderá então enviar os
bitcoin recém-adquiridos por Alice para esse endereço Bitcoin.
Para visualizar um endereço Bitcoin na carteira Eclair, Alice precisa deslizar para a coluna
esquerda intitulada SEU ENDEREÇO BITCOIN (see Endereço bitcoin de Alice, mostrado em Eclair),
onde ela verá um código de barras quadrado (chamado de QR code) e uma sequência de letras e
números logo abaixo.
O código QR contém a mesma sequência de letras e números exibida abaixo dele, em um formato
fácil de escanear. Dessa forma, Alice não precisa digitar o endereço Bitcoin. Na captura de tela
(Endereço bitcoin de Alice, mostrado em Eclair), Nós intencionalmente ocultamos ambos para
evitar que os leitores enviem bitcoin para este endereço inadvertidamente.
11
Figure 4. Endereço bitcoin de Alice, mostrado em Eclair
Ambos endereços Bitcoin e códigos QR contêm informações de detecção de erros que impedem
que erros de digitação ou escaneamento produzam um endereço Bitcoin "errado". Se houver
um erro no endereço, qualquer carteira de Bitcoin detectará o erro e se recusará a aceitar o
12
endereço Bitcoin como válido.
Alice pode levar seu dispositivo móvel ao caixa eletrônico e mostrá-lo para a câmera embutida,
conforme mostrado na Caixa eletrônico Bitcoin escaneia o QR code. Após inserir dinheiro na
abertura designada, Alice receberá bitcoin em sua carteira Eclair!
Figure 5. Caixa eletrônico Bitcoin escaneia o QR code
Alice verá a transação do caixa eletrônico na guia HISTÓRICO DE TRANSAÇÕES da carteira Eclair.
Embora a Eclair detecte a transação de bitcoin em apenas alguns segundos, levará
aproximadamente uma hora para que a transação de bitcoin seja "confirmada" na blockchain do
Bitcoin. Como você pode ver na Alice recebe bitcoin, A carteira Eclair de Alice mostra "6+ conf"
abaixo da transação, indicando que a transação recebeu o mínimo necessário de seis confirmações,
e seus fundos estão prontos para uso.
O número de confirmações em uma transação é o número de blocos minerados desde (e

incluindo) o bloco que continha essa transação. Seis confirmações é uma prática recomendada,
mas diferentes carteiras Lightning podem considerar um canal aberto após qualquer número
de confirmações. Algumas carteiras até aumentam o número de confirmações esperadas com
base no valor monetário do canal.
Embora neste exemplo Alice tenha utilizado um caixa eletrônico para adquirir seu primeiro
bitcoin, os mesmos conceitos básicos se aplicariam mesmo se ela utilizasse um dos outros métodos
mencionados em Adquirindo Bitcoin. Por exemplo, se Alice quisesse vender um produto ou
fornecer um serviço profissional em troca de bitcoin, seus clientes poderiam escanear o endereço
Bitcoin com suas carteiras e pagar a ela em bitcoin.
13
Figure 6. Alice recebe bitcoin
Da mesma forma, se Alice emitisse uma fatura para um cliente por um serviço oferecido pela
internet, ela poderia enviar um e-mail ou mensagem instantânea com o endereço Bitcoin ou o
código QR para seu cliente, e ele poderiam colar ou escanear as informações em uma carteira de
Bitcoin para fazer o pagamento a ela.
Alice poderia até mesmo imprimir o código QR e fixá-lo em uma placa para exibição pública, a fim
14
de receber gorjetas. Por exemplo, ela poderia fixar um código QR em seu violão e receber gorjetas
[3]
enquanto se apresenta na rua!
Por fim, se Alice comprou bitcoins em uma exchange de criptomoedas, ela pode (e deve) "retirar" os
bitcoins colando seu endereço Bitcoin no site da exchange. A exchange enviará os bitcoins
diretamente para o endereço de Alice.
Do Bitcoin à Lightning Network

Os bitcoin de Alice agora estão sob controle de sua carteira Eclair e foram registrados na blockchain
do Bitcoin. Neste ponto, os bitcoin de Alice estão on-chain, o que significa que a transação foi
transmitida para toda a rede Bitcoin, verificada por todos os nós Bitcoin e minerada (registrada) na
blockchain do Bitcoin.
Até agora, a carteira Eclair Mobile tem funcionado apenas como uma carteira de Bitcoin, e Alice
não utilizou os recursos da Lightning Network do Eclair. Como acontece com muitas carteiras
Lightning, o Eclair faz a ponte entre o Bitcoin e a Lightning Network ao atuar como uma carteira de
Bitcoin e uma carteira Lightning ao mesmo tempo.
Agora, Alice está pronta para começar a usar a Lightning Network, levando seus bitcoin para fora
da cadeia principal (off-chain), a fim de aproveitar os pagamentos rápidos, baratos e privados que a
Lightning Network oferece.
Canais da Lightning Network
Ao deslizar para a direita, Alice acessa a seção CANAIS LIGHTNING dA Eclair. Aqui ela pode
gerenciar os canais que conectarão sua carteira à Lightning Network.
Vamos revisar a definição de um canal da Lightning Network (LN) neste ponto, para tornar as
coisas um pouco mais claras. Primeiramente, a palavra "canal" é uma metáfora para um
relacionamento financeiro entre a carteira Lightning de Alice e outra carteira Lightning. Chamamos
de canal porque é um meio para a carteira de Alice e essa outra carteira trocarem muitos
pagamentos entre si na Lightning Network (off-chain, fora da cadeia principal), sem a necessidade
de registrar transações na blockchain do Bitcoin (on-chain, na cadeia principal).
A carteira ou nó para a qual Alice abre um canal é chamada de seu channel peer (par de canal). Uma
vez "aberto", um canal pode ser usado para enviar muitos pagamentos de ida e volta entre a
carteira de Alice e seu par de canal.
Além disso, o par de canal de Alice pode encaminhar pagamentos por meio de outros canais mais
adiante na Lightning Network. Dessa forma, Alice pode rotear um pagamento para qualquer
carteira (por exemplo, para a carteira Lightning de Bob), desde que a carteira de Alice possa
encontrar um caminho viável pulando de canal em canal, até chegar à carteira de Bob.
Nem todos os pares de canal são bons para encaminhar pagamentos. Pares de canal bem
conectados terão a capacidade de rotear pagamentos por caminhos mais curtos até o destino,
aumentando as chances de sucesso. Pares de canal com bastante fundos poderão rotear
pagamentos de valor mais alto.
15
Em outras palavras, Alice precisa de um ou mais canais que a conectem a um ou mais outros nós na
Lightning Network. Ela não precisa de um canal para conectar sua carteira diretamente à cafeteria
do Bob para enviar um pagamento a ele, embora possa optar por abrir um canal direto, se desejar.
Qualquer nó na Lightning Network pode ser usado como o primeiro canal de Alice. Quanto mais
bem conectado um nó estiver, mais pessoas Alice poderá alcançar. Neste exemplo, uma vez que
também queremos demonstrar o roteamento de pagamentos, Alice não abrirá um canal
diretamente para a carteira de Bob. Em vez disso, ela abrirá um canal para um nó bem conectado e,
posteriormente, usará esse nó para encaminhar seu pagamento, roteando-o por outros nós
conforme necessário para chegar a Bob.
Inicialmente, não há canais abertos, como podemos ver na Guia CANAIS LIGHTNING, a guia
LIGHTNING CHANNELS mostra uma lista vazia. Se você observar, no canto inferior direito, há um
símbolo de adição (+), que é um botão para abrir um novo canal.
16
Figure 7. Guia CANAIS LIGHTNING
17
Alice pressiona o símbolo de adição e são apresentadas quatro possíveis formas de abrir um canal:
• Colar um URI de nó
• Escanear um URI de nó
• Nó aleatório
• Nó ACINQ
Uma "URI de nó" é um Identificador Universal de Recurso (URI) que identifica um nó específico na
Lightning Network. Alice pode colar essa URI a partir da área de transferência ou escanear um
código QR que contenha essa mesma informação. Um exemplo de uma URI de nó é exibido como
um código QR na URI de nó como QR code e, em seguida, como uma sequência de texto.
Figure 8. URI de nó como QR code
node URI
0237fefbe8626bf888de0cad8c73630e32746a22a2c4faa91c1d9877a3826e1174@1.ln.aantonop.com:9
735
Embora Alice possa selecionar um nó específico da Lightning Network ou usar a opção "Nó
aleatório" para que a carteira Eclair selecione um nó aleatório, ela selecionará a opção Nó ACINQ
para se conectar a um dos nós Lightning bem conectados da ACINQ.
Ao escolher o nó ACINQ, a privacidade de Alice será ligeiramente reduzida, pois dará à ACINQ a
capacidade de ver todas as transações de Alice. Isso também criará um único ponto de falha, já que
Alice terá apenas um canal e, se o nó ACINQ não estiver disponível, Alice não poderá fazer
pagamentos. Para manter as coisas simples no início, aceitaremos esses compromissos. Nos
capítulos subsequentes, aprenderemos gradualmente como obter mais independência e fazer
menos compromissos (trade-offs)!
Alice seleciona o nó ACINQ e está pronta para abrir seu primeiro canal na Lightning Network.
Abrindo um Canal Lightning
Quando Alice seleciona um nó para abrir um novo canal, ela é solicitada a escolher quanto bitcoin
ela deseja alocar para esse canal. Nos capítulos subsequentes, discutiremos as implicações dessas
escolhas, mas, por enquanto, Alice alocará quase todos os seus fundos para o canal. Como ela terá
que pagar taxas de transação para abrir o canal, ela selecionará um valor ligeiramente menor do
[4]
que o saldo total.
Alice aloca 0,018 BTC dos seus 0,020 BTC totais para o seu canal e aceita a taxa de transação padrão,
como mostrado na Abrindo um canal Lightning.
18
Figure 9. Abrindo um canal Lightning
Depois de clicar em ABRIR, sua carteira constrói a transação especial do Bitcoin queabre um canal
da Lightning, conhecida como transação de financiamento (funding transaction). A transação de
financiamento na cadeia principal (on-chain) é enviada para a rede Bitcoin para confirmação.
Alice agora precisa esperar novamente (see Aguardando a transação de financiamento para abrir o
19
canal) para que a transação seja registrada na blockchain do Bitcoin. Assim como na transação
inicial de Bitcoin que ela usou para adquirir seus bitcoin, ela terá que esperar por seis ou mais
confirmações (aproximadamente uma hora).
Figure 10. Aguardando a transação de financiamento para abrir o canal
Após a confirmação da transação de financiamento, o canal de Alice para o nó ACINQ estará aberto,
financiado e pronto, como mostrado na O canal está aberto.
20
Figure 11. O canal está aberto
Você percebeu que o valor do canal parece ter mudado? Na verdade, ele não mudou: o canal
contém 0,018 BTC, mas, no intervalo entre as capturas de tela, a taxa de câmbio do BTC mudou,
por isso o valor em USD está diferente. Você pode escolher exibir os saldos em BTC ou USD,
mas lembre-se de que os valores em USD são calculados em tempo real e podem mudar!
Comprando uma Xícara de Café Usando a Lightning

Network
Agora, Alice tem tudo pronto para começar a usar a Lightning Network. Como você pode ver, foi
necessário um pouco de trabalho e um pouco de tempo de espera pelas confirmações. No entanto,
agora as ações subsequentes são rápidas e fáceis. A Lightning Network permite pagamentos sem a
necessidade de esperar por confirmações, pois os fundos são liquidados em questão de segundos.
Alice pega seu dispositivo móvel e corre para a Café do Bob em seu bairro. Ela está animada para
experimentar sua nova carteira Lightning e usá-la para comprar algo!
Café do Bob
Bob possui um aplicativo simples de ponto de venda (Point-of-Sale—PoS) para uso de qualquer
cliente que queira pagar com bitcoin por meio da Lightning Network. Conforme veremos no
próximo capítulo, Bob utiliza a popular plataforma de código aberto chamada BTCPay Server, que
contém todos os componentes necessários para uma solução de comércio eletrônico ou varejo, tais
como:
21
• Um nó Bitcoin usando o software Bitcoin Core
• Um nó Lightning usando o software c-lightning
• Um aplicativo PoS simples para um tablet
O BTCPay Server torna simples a instalação de todo o software necessário, o upload de imagens e
preços de produtos, e o lançamento rápido de uma loja.
No balcão do Café do Bob, há um dispositivo tablet mostrando o que você vê na Aplicativo de ponto
de venda do Bob.
Figure 12. Aplicativo de ponto de venda do Bob
Uma Fatura Lightning
Alice seleciona a opção Café Latte na tela e é apresentada com uma fatura Lightning (também
conhecida como "solicitação de pagamento"), como mostrado na Fatura Lightning para o latte de
Alice.
22
Figure 13. Fatura Lightning para o latte de Alice
Para pagar a fatura, Alice abre sua carteira Eclair e seleciona o botão Enviar (que se parece com
uma seta voltada para cima) na guia HISTÓRICO DE TRANSAÇÕES, como mostrado em Alice
selecionando Enviar.
23
Figure 14. Alice selecionando Enviar
O termo "solicitação de pagamento" pode se referir a uma solicitação de pagamento Bitcoin ou

a uma fatura Lightning, e os termos "fatura" e "solicitação de pagamento" são frequentemente
usados indistintamente. O termo técnico correto é "fatura Lightning" (Lightning invoice),
independentemente de como seja chamado na carteira.
Alice seleciona a opção "escanear uma solicitação de pagamento", escaneia o código QR exibido na
tela do tablet (see Fatura Lightning para o latte de Alice), e é solicitada a confirmar seu pagamento,
como mostrado na A confirmação de envio de Alice.
Alice pressiona PAGAR e, um segundo depois, o tablet de Bob mostra um pagamento bem-sucedido.
Alice concluiu seu primeiro pagamento pela Lightning Network! Foi rápido, barato e fácil. Agora ela
pode desfrutar de seu café com leite, que foi comprado usando bitcoin por meio de um sistema de
pagamento rápido, barato e descentralizado. A partir de agora, Alice pode simplesmente selecionar
um item na tela do tablet de Bob, escanear o código QR com seu celular, clicar em PAGAR e receber
um café, tudo em questão de segundos e sem a necessidade de uma transação on-chain, na cadeia
principal.
24
Figure 15. A confirmação de envio de Alice
Pagamentos pela Lightning Network também são melhores para Bob. Ele tem confiança de que será
pago pelo café com leite de Alice sem precisar esperar por uma confirmação na cadeia principal. No
futuro, sempre que Alice quiser tomar um café no Café do Bob, ela poderá escolher pagar com
bitcoin na rede Bitcoin ou na Lightning Network. Qual você acha que ela escolherá?
Conclusão
Neste capítulo, acompanhamos Alice enquanto ela baixou e instalou sua primeira carteira
Lightning, adquiriu e transferiu alguns bitcoin, abriu seu primeiro canal Lightning e comprou uma
xícara de café ao fazer seu primeiro pagamento na Lightning Network. In the following chapters,
we will look "under the covers" at how each component in the Lightning Network works and how
Alice’s payment reached Bob’s Cafe.
[1] Andreas M. Antonopoulos, Mastering Bitcoin, 2nd Edition, Chapter 1 (O’Reilly)

[2] ACINQ: Developers of the Eclair Mobile Lightning wallet.
[3] Geralmente, não é recomendado reutilizar o mesmo endereço de Bitcoin para múltiplos pagamentos, pois todas as transações
de Bitcoin são públicas. Uma pessoa curiosa que passa por perto pode escanear o código QR de Alice e ver quantas gorjetas ela já
recebeu para esse endereço na blockchain do Bitcoin. Felizmente, a Lightning Network oferece soluções mais privadas para isso,
discutidas posteriormente neste livro!
[4] A carteira Eclair não oferece uma opção para calcular automaticamente as taxas necessárias e alocar a quantidade máxima de
fundos para um canal. Portanto, Alice precisará fazer esse cálculo ela mesma.
25
Como Funciona a Rede Lightning
Agora que acompanhamos Alice ao configurar uma carteira Lightning e comprar um café de Bob,
vamos examinar em detalhes os diferentes componentes da Lightning Network envolvidos nesse
processo. Este capítulo fornecerá uma visão geral de alto nível e não aprofundará todos os detalhes
técnicos. O objetivo é ajudá-lo a compreender os conceitos mais importantes e os componentes
fundamentais da Lightning Network.
Se você tiver experiência em ciência da computação, criptografia, Bitcoin e desenvolvimento de

protocolos, este capítulo deve ser suficiente para que você possa preencher os detalhes de conexão
por conta própria. Se você tiver menos experiência, este capítulo fornecerá uma visão geral
adequada para que você possa compreender melhor as especificações formais do protocolo,
conhecidas como BOLTs (Basis of Lightning Technology). Se você é um iniciante, este capítulo
ajudará você a compreender melhor os capítulos técnicos do livro.
Se você precisa relembrar os fundamentos do Bitcoin, você pode encontrar uma revisão resumida
dos seguintes tópicos no [bitcoin_fundamentals_review]:
• Chaves e endereços
• Funções hash
• Assinaturas digitais
• Estrutura da transação
• Entradas e saídas de transações
• Encadeamento de transações
• Bitcoin Script
• Scripts e endereços multiassinatura (multisig)
• Timelocks
• Scripts complexos
Vamos começar com uma definição em uma frase do que é a Lightning Network e analisá-la
detalhadamente no restante deste capítulo.
A Lightning Network é uma rede peer-to-peer (ponto a ponto) de canais de pagamento

implementados como contratos inteligentes na blockchain do Bitcoin, juntamente com um protocolo
de comunicação que define como os participantes configuram e executam esses contratos
inteligentes.
O Que É um Canal de Pagamento?

Existem várias maneiras de descrever um canal de pagamento, dependendo do contexto. Vamos
começar em um nível mais alto e depois adicionar mais detalhes.
Um canal de pagamento é um relacionamento financeiro entre dois nós na Lightning Network,

chamados de parceiros do canal. O relacionamento financeiro aloca um saldo de fundos
(denominado em milisatoshis), entre os dois parceiros do canal.
1
O canal de pagamento é gerenciado por um protocolo criptográfico, o que significa que um processo
pré-definido baseado em criptografia é usado pelos parceiros do canal para redistribuir o saldo do
canal em favor de um ou outro dos parceiros. O protocolo criptográfico garante que um parceiro do
canal não possa enganar o outro, de modo que os parceiros não precisem confiar um no outro.
O protocolo criptográfico é estabelecido pelo financiamento de um endereço de multisig (assinatura

múltipla) 2-de-2, que exige que os dois parceiros do canal cooperem e impede que qualquer um dos
parceiros do canal gaste os fundos unilateralmente.
Para resumir: um canal de pagamento é um relacionamento financeiro entre nós, que aloca fundos
de um endereço de assinatura múltipla por meio de um protocolo criptográfico estritamente
definido.
Noções Básicas do Canal de Pagamento

No cerne do canal de pagamento está apenas um endereço de assinatura múltipla 2-de-2 na
blockchain do Bitcoin, para o qual você possui uma chave e seu parceiro do canal possui a outra
chave.
Você e seu parceiro do canal negociam uma sequência de transações que gastam desse endereço de
assinatura múltipla. Em vez de transmitir e registrar essas transações na blockchain do Bitcoin,
ambos as mantêm, não gastas.
A transação mais recente nessa sequência codifica o saldo do canal e define como esse saldo é
dividido entre você e seu parceiro do canal.
Dessa forma, adicionar uma nova transação a essa sequência equivale a mover parte do saldo do
canal de um parceiro do canal para o outro, sem que a rede Bitcoin esteja ciente disso. Conforme
você negocia cada nova transação, alterando a alocação de fundos no canal, você também revoga a
transação anterior, para que nenhuma das partes possa retroceder para um estado anterior.
Cada transação na sequência faz uso da linguagem de script do Bitcoin, e, portanto, a negociação de
fundos entre você e seu parceiro do canal é gerenciada por um contrato inteligente do Bitcoin. O
contrato inteligente é configurado para penalizar um membro do canal se ele tentar enviar um
estado previamente revogado do canal.
Se você tiver uma transação não publicada de um endereço de assinatura múltipla 2-de-2 que
lhe paga parte do saldo, então uma assinatura da outra parte garante que você possa publicar
independentemente essa transação a qualquer momento, adicionando sua própria assinatura.
A capacidade de manter uma transação parcialmente assinada, offline e não publicada, com a
opção de publicar e possuir esse saldo a qualquer momento é a base da Lightning Network.
Roteamento de Pagamentos Entre Canais

Uma vez que vários participantes possuem canais de pagamento de uma parte para outra, os
pagamentos também podem ser "encaminhados" de um canal de pagamento para outro,
2
configurando um caminho pela rede que conecta vários canais de pagamento juntos.
Por exemplo, Alice pode enviar dinheiro para Charlie se Alice tiver um canal com Bob e Bob tiver
um canal com Charlie.
Pelo design da Lightning Network, é possível estender os contratos inteligentes que operam o canal
de forma que Bob não tenha como roubar os fundos que estão sendo encaminhados por meio de
seu canal.
Da mesma forma que o contrato inteligente protege os parceiros do canal para que eles não
precisem confiar um no outro, toda a rede protege os participantes para que eles possam
encaminhar pagamentos sem confiar em nenhum dos outros participantes.
Porque os canais são construídos a partir de endereços de múltiplas assinaturas e as transações de

atualização de saldo são transações pré-assinadas do Bitcoin, toda a confiança necessária para
operar a Lightning Network advém da confiança na rede descentralizada do Bitcoin!
As inovações mencionadas são certamente os avanços fundamentais que permitiram a criação da

Lightning Network. No entanto, a Lightning Network é muito mais do que os protocolos
criptográficos por cima da linguagem Bitcoin Script. É um protocolo de comunicação abrangente
que permite que os pares troquem mensagens Lightning para realizar a transferência de bitcoin. O
protocolo de comunicação define como as mensagens Lightning são criptografadas e trocadas.
A Lightning Network também utiliza um protocolo de gossip (fofoca, ou transmissão) para

distribuir informações públicas sobre os canais (topologia da rede) para todos os participantes.
Alice, por exemplo, precisa das informações da topologia da rede para estar ciente do canal entre
Bob e Charlie, para que ela possa construir uma rota até Charlie.
Por último, mas não menos importante, é essencial entender que a Lightning Network não passa de
uma aplicação em cima do Bitcoin, utilizando transações de Bitcoin e o Bitcoin Script. Não existe
uma "moeda Lightning" ou "blockchain Lightning". Além de todas as primitivas técnicas, o
protocolo LN é uma maneira criativa de obter mais benefícios do Bitcoin, permitindo um número
arbitrário de pagamentos instantâneos com liquidações instantâneas, sem a necessidade de confiar
em qualquer pessoa além da rede do Bitcoin.
Canais de Pagamento
Como vimos no capítulo anterior, Alice usou seu software de carteira para criar um canal de
pagamento entre ela mesma e outro participante da LN.
Um canal é limitado apenas por três coisas:
• Primeiro, o tempo necessário para a internet transferir as poucas centenas de bytes de dados
que o protocolo requer para mover os fundos de uma ponta do canal para a outra.
• Segundo, a capacidade do canal, ou seja, a quantidade de bitcoin que é comprometida com o

canal quando ele é aberto.
• Terceiro, o limite máximo de tamanho de uma transação do Bitcoin também limita o número de
pagamentos roteados incompletos (em andamento) que podem ser realizados simultaneamente
3
por um canal.
Os canais de pagamento possuem algumas propriedades muito interessantes e úteis:
• Devido ao fato de que o tempo para atualizar um canal está principalmente ligado à velocidade
de comunicação da internet, fazer um pagamento em um canal de pagamento pode ser
praticamente instantâneo.
• Se o canal estiver aberto, fazer um pagamento não requer a confirmação de blocos do Bitcoin.
Na verdade—desde que você e seu parceiro do canal sigam o protocolo—não é necessário
nenhuma interação com a rede Bitcoin ou qualquer outra pessoa além do seu parceiro do canal.
• O protocolo criptográfico é construído de tal forma que há pouca ou nenhuma confiança

necessária entre você e seu parceiro do canal. Se o seu parceiro se tornar inativo ou tentar
enganá-lo, você pode solicitar ao sistema Bitcoin que atue como um "tribunal", resolvendo o
contrato inteligente que você e seu parceiro concordaram anteriormente.
• Os pagamentos feitos em um canal de pagamento são conhecidos apenas por você e seu
parceiro. Nesse sentido, você ganha privacidade em comparação com o Bitcoin, onde todas as
transações são públicas. Apenas o saldo final, que é a agregação de todos os pagamentos nesse
canal, se tornará visível na blockchain do Bitcoin.
O Bitcoin tinha cerca de cinco anos de idade quando talentosos desenvolvedores descobriram pela
primeira vez como construir canais de pagamento bidirecionais, com duração indefinida e
roteáveis. Desde então, agora existem pelo menos três métodos conhecidos.
Este capítulo se concentrará no método de construção do canal descrito inicialmente no Lightning

Network whitepaper por Joseph Poon e Thaddeus Dryja in 2015.Esses são conhecidos como canais
Poon-Dryja e são o método de construção do canal atualmente utilizado na Lightning Network. Os
outros dois métodos propostos são os canais Duplex Micropayment, introduzidos por Christian
Decker na mesma época dos canais Poon-Dryja, e os canais eltoo, introduzidos em "eltoo: A Simple
Layer2 Protocol for Bitcoin" por Christian Decker, Rusty Russel, e (coautor deste livro) Olaoluwa
Osuntokun em 2018.
Os canais eltoo possuem algumas propriedades interessantes e simplificam a implementação de

canais de pagamento. No entanto, os canais eltoo exigem uma alteração na linguagem de script do
Bitcoin e, portanto, não podem ser implementados na rede principal do Bitcoin em 2020.
Endereço de Assinatura Múltipla
Os canais de pagamento são construídos em cima de endereços de assinatura múltipla 2-de-2.
Resumidamente, um endereço de assinatura múltipla é onde o bitcoin é bloqueado de forma que

requer múltiplas assinaturas para desbloqueá-lo e gastá-lo. Em um endereço de assinatura múltipla
2-de-2, como usado na Lightning Network, existem dois participantes assinantes e ambos precisam
assinar para gastar os fundos.
Os scripts e endereços de assinatura múltipla são explicados em mais detalhes em [multisig].
4
Transação de Financiamento
O elemento fundamental de um canal de pagamento é um endereço de assinatura múltipla 2-de-2.

Um dos dois parceiros do canal financiará o canal de pagamento enviando bitcoin para o endereço
de assinatura múltipla. Essa transação é chamada de transação de financiamento e é registrada na
[1]
Embora a transação de financiamento seja pública, não é óbvio que se trata de um canal de
pagamento da Lightning até que ele seja fechado, a menos que o canal seja anunciado
publicamente. Os canais geralmente são anunciados publicamente por nós de roteamento que
desejam encaminhar pagamentos. No entanto, também existem canais não anunciados, que são
geralmente criados por nós móveis que não participam ativamente do roteamento. Além disso, os
pagamentos do canal ainda não são visíveis para ninguém além dos parceiros do canal, assim como
a distribuição do saldo do canal entre eles.
A quantia depositada no endereço de assinatura múltipla é chamada de capacidade do canal e

define o valor máximo que pode ser enviado pelo canal de pagamento. No entanto, como os fundos
podem ser enviados de um lado para o outro, a capacidade do canal não é o limite máximo para a
quantidade de valor que pode fluir pelo canal. Isso ocorre porque, se a capacidade do canal for
esgotada com pagamentos em uma direção, ela pode ser usada novamente para enviar pagamentos
na direção oposta.
Os fundos enviados para o endereço de assinatura múltipla na transação de financiamento são

às vezes chamados de "bloqueados em um canal Lightning". No entanto, na prática, os fundos
em um canal Lightning não estão "bloqueados", mas sim "liberados". Os fundos do canal
Lightning são mais líquidos do que os fundos na blockchain do Bitcoin, pois podem ser gastos
de forma mais rápida, barata e privada. Existem algumas desvantagens em mover fundos para
a Lightning Network (como a necessidade de mantê-los em uma carteira "quente"—hot wallet,
online), mas a ideia de "bloquear fundos" na Lightning é enganosa.
Exemplo de um procedimento ruim de abertura de canal
Se você pensar cuidadosamente sobre endereços de assinatura múltipla 2-de-2, você perceberá que
colocar seus fundos em um endereço desse tipo parece carregar algum risco. E se o seu parceiro do
canal se recusar a assinar uma transação para liberar os fundos? Eles ficam presos para sempre?
Vamos analisar esse cenário e como o protocolo da LN o evita.
Alice e Bob desejam criar um canal de pagamento. Cada um deles cria um par de chaves
privada/pública e, em seguida, trocam as chaves públicas. Agora, eles podem construir uma
assinatura múltipla 2-de-2 com as duas chaves públicas, formando a base para o seu canal de
pagamento.
Em seguida, Alice constrói uma transação do Bitcoin enviando alguns mBTC para o endereço de
assinatura múltipla criado a partir das chaves públicas de Alice e Bob. Se Alice não tomar nenhuma
medida adicional e simplesmente transmitir essa transação, ela terá que confiar que Bob fornecerá
sua assinatura para gastar os fundos do endereço de assinatura múltipla. Por outro lado, Bob teria a
oportunidade de chantagear Alice retendo a assinatura dele assinatura e negando a Alice acesso aos
seus fundos.
5
Para evitar isso, Alice precisará criar uma transação adicional que gasta a partir do endereço de
assinatura múltipla, reembolsando seus mBTC. Alice então pede a Bob para assinar a transação de
reembolso antes de transmitir sua transação de financiamento para a rede Bitcoin. Dessa forma,
Alice pode obter um reembolso mesmo se Bob desaparecer ou se recusar a cooperar.
A transação de "reembolso" que protege Alice é a primeira de uma classe de transações chamadas
de transações de compromisso (commitment transactions), que examinaremos com mais detalhes a
seguir.
Transação de Compromisso
Uma transação de compromisso é uma transação que paga a cada parceiro do canal o saldo do canal
e garante que os parceiros do canal não precisem confiar um no outro. Ao assinar uma transação
de compromisso, cada parceiro do canal "compromete-se" com o saldo atual e dá ao outro parceiro
do canal a capacidade de obter seus fundos de volta quando desejar.
Ao possuir uma transação de compromisso assinada, cada parceiro do canal pode obter seus fundos
mesmo sem a cooperação do outro parceiro do canal. Isso os protege contra o desaparecimento do
outro parceiro do canal, recusa em cooperar ou tentativa de trapaça violando o protocolo do canal
de pagamento.
A transação de compromisso que Alice preparou no exemplo anterior era um reembolso de seu
pagamento inicial para o endereço de assinatura múltipla. De forma mais geral, no entanto, uma
transação de compromisso divide os fundos do canal de pagamento, pagando aos dois parceiros do
canal de acordo com a distribuição (saldo) que cada um deles possui. No início, Alice detém todo o
saldo, então é um simples reembolso. Mas à medida que os fundos fluem de Alice para Bob, eles
trocarão assinaturas para novas transações de compromisso que representam a nova distribuição
do saldo, com parte dos fundos pagos a Alice e parte pagos a Bob.
Vamos supor que Alice abre um canal com uma capacidade de 100.000 satoshis com Bob.
Inicialmente, Alice possui 100.000 satoshis, a totalidade dos fundos no canal. Vejamos como
funciona o protocolo do canal de pagamento:
1. Alice cria um novo par de chaves privada/pública e informa a Bob que deseja abrir um canal
por meio da mensagem open_channel (uma mensagem no protocolo da LN).
2. Bob também cria um novo par de chaves privada/pública e concorda em aceitar um canal de
Alice, enviando sua chave pública para Alice por meio da mensagem accept_channel.
3. Agora, Alice cria uma transação de financiamento em sua carteira que envia 100.000 satoshis
para o endereço de assinatura múltipla com um script de bloqueio: 2 <PubKey Alice> <PubKey
Bob> 2 CHECKMULTISIG.
4. Alice ainda não transmite essa transação de financiamento, mas envia para Bob o ID da
transação na mensagem funding_created, juntamente com sua assinatura para a transação de
compromisso de Bob.
5. Tanto Alice quanto Bob criam sua versão de uma transação de compromisso. Essa transação
gastará da transação de financiamento e enviará todos os bitcoin de volta para um endereço
controlado por Alice.
6. Alice e Bob não precisam trocar essas transações de compromisso, pois cada um sabe como elas
6
são construídas e podem construir ambas de forma independente (porque concordaram com
uma ordenação canônica das entradas e saídas). Eles apenas precisam trocar assinaturas.
7. Bob fornece uma assinatura para a transação de compromisso de Alice e envia de volta para
Alice por meio da mensagem funding_signed.
8. Agora que as assinaturas foram trocadas, Alice irá transmitir a transação de financiamento para
a rede Bitcoin.
Ao seguir esse protocolo, Alice não perde a propriedade de seus 100.000 satoshis, mesmo que os
fundos sejam enviados para um endereço de assinatura múltipla 2-de-2 no qual Alice controle
apenas uma chave. Se Bob parar de responder a Alice, ela poderá transmitir sua transação de
compromisso e receber seus fundos de volta. Seus únicos custos são as taxas das transações na
cadeia (on-chain). Desde que ela siga o protocolo, esse é o único risco que ela enfrenta ao abrir um
canal.
Após essa troca inicial, transações de compromisso são criadas cada vez que o saldo do canal é
alterado. Em outras palavras, cada vez que um pagamento é enviado entre Alice e Bob, novas
transações de compromisso são criadas e assinaturas são trocadas. Cada nova transação de
compromisso codifica o saldo mais recente entre Alice e Bob.
Se Alice deseja enviar 30.000 satoshis para Bob, ambos criarão uma nova versão de suas transações
de compromisso, que agora pagarão 70.000 satoshis para Alice e 30.000 satoshis para Bob. Ao
codificar um novo saldo para Alice e Bob, as novas transações de compromisso são o meio pelo qual
um pagamento é "enviado" pelo canal.
Agora que entendemos as transações de compromisso, vamos analisar alguns detalhes mais sutis.
Você pode perceber que esse protocolo deixa uma maneira para que Alice ou Bob trapaceiem.
Traição com Estado Anterior
Quantas transações de compromisso Alice possui depois de pagar 30.000 satoshis para Bob? Ela
possui duas: a original, que paga a ela 100.000 satoshis, e a mais recente, que paga a ela 70.000
satoshis e a Bob 30.000 satoshis.
No protocolo do canal que vimos até agora, nada impede que Alice publique uma transação de
compromisso anterior. Uma Alice desonesta poderia publicar a transação de compromisso que lhe
concede 100.000 satoshis. Uma vez que aquela transação de compromisso foi assinada por Bob, ele
não pode impedir que Alice a transmita.
De fato, é necessário algum mecanismo para evitar que Alice publique uma transação de
compromisso antiga. Agora, vamos descobrir como isso pode ser alcançado e como isso permite que
a Lightning Network opere sem exigir qualquer confiança entre Alice e Bob.
Como o Bitcoin é resistente à censura, ninguém pode impedir alguém de publicar uma transação de
compromisso antiga. Para evitar essa forma de trapaça, as transações de compromisso são
construídas de forma que, se uma transação antiga for transmitida, o trapaceiro possa ser punido.
Ao tornar a penalidade suficientemente alta, criamos um forte incentivo contra a trapaça, o que
torna o sistema seguro.
A forma como a penalidade funciona é dando à parte prejudicada a oportunidade de reivindicar o
7
saldo do trapaceiro. Portanto, se alguém tentar trapacear transmitindo uma transação de
compromisso antiga, na qual eles são pagos com um saldo mais alto do que o devido, a outra parte
pode puni-los tomando ambos seu próprio saldo quanto o saldo do trapaceiro. O trapaceiro perde
tudo.
Você pode perceber que, se Alice esgotar completamente o saldo do seu canal, ela poderia
tentar trapacear com pouco risco. A penalidade para Bob não seria tão dolorosa se o saldo do
canal de Alice estiver baixo. Para evitar isso, o protocolo Lightning requer que cada parceiro
de canal mantenha um saldo mínimo no canal (chamado de reserva) para que eles sempre
tenham um interesse no jogo.
Vamos revisar o cenário de construção do canal novamente, adicionando um mecanismo de

penalidade para proteger contra trapaças:
1. Alice cria um canal com Bob e coloca 100.000 satoshis nele.
2. Alice envia 30.000 satoshis para Bob.
3. Alice tenta enganar Bob de seus merecidos 30.000 satoshis, publicando uma antiga transação de
compromisso, reivindicando os 100.000 satoshis completos para si mesma.
4. Bob detecta a fraude e pune Alice, tomando os 100.000 satoshis completos para si mesmo.
5. Bob acaba com 100.000 satoshis, ganhando 70.000 satoshis por pegar Alice trapaceando.
6. Alice acaba com 0 satoshi.
7. Ao tentar enganar Bob em 30.000 satoshis, ela acaba perdendo os 70.000 satoshis que possuía.
Com um mecanismo de penalidade rigoroso, Alice não é tentada a trapacear publicando uma antiga
transação de compromisso, pois corre o risco de perder todo o seu saldo.
No Capítulo 12 de Mastering Bitcoin, Andreas Antonopoulos (o coautor deste livro) o descreve

da seguinte forma: "Uma característica fundamental do Bitcoin é que, uma vez que uma
transação é válida, ela permanece válida e não expira. A única maneira de cancelar uma
transação é realizando um gasto duplo de suas entradas com outra transação antes que ela
seja minerada."
Agora que entendemos o porquê de um mecanismo de penalidade ser necessário e como ele impede
trapaças, vamos ver como ele funciona em detalhes.
Normalmente, a transação de compromisso tem pelo menos duas saídas, pagando cada parceiro do
canal.Nós alteramos isso para adicionar um timelock delay (atraso de bloqueio temporal) e um
revocation secret (segredo de revogação) a um dos pagamentos. O atraso de bloqueio temporal
impede que o proprietário do output o gaste imediatamente assim que a transação de compromisso
for incluída em um bloco. O segredo de revogação permite que qualquer uma das partes gaste esse
pagamento imediatamente, contornando o atraso de bloqueio temporal.
Então, em nosso exemplo, Bob detém uma transação de compromisso que paga Alice
imediatamente, mas seu próprio pagamento está atrasado e sujeito a revogação. Alice também
8
possui uma transação de compromisso, mas a dela é o oposto: ela paga Bob imediatamente, mas seu
próprio pagamento está atrasado e sujeito a revogação.
Os dois parceiros do canal possuem metade do segredo de revogação, de forma que nenhum deles
conhece o segredo completo. Se eles compartilharem sua metade, então o outro parceiro do canal
terá o segredo completo e poderá usá-lo para exercer a condição de revogação. Ao assinar uma
nova transação de compromisso, cada parceiro do canal revoga o compromisso anterior,
fornecendo à outra parte sua metade do segredo de revogação.
Vamos examinar o mecanismo de revogação em mais detalhes em [revocation], onde

aprenderemos os detalhes de como os segredos de revogação são construídos e utilizados.
Em termos simples, Alice assina a nova transação de compromisso de Bob apenas se ele oferecer
sua metade do segredo de revogação do compromisso anterior. Bob só assina a nova transação de
compromisso de Alice se ela lhe fornecer sua metade do segredo de revogação do compromisso
anterior.
Com cada novo compromisso, eles trocam o segredo de "punição" necessário que lhes permite
efetivamente revogar a transação de compromisso anterior, tornando-a não lucrativa para ser
transmitida. Essencialmente, eles destroem a capacidade de usar compromissos antigos à medida
que assinam os novos. O que queremos dizer é que, embora ainda seja tecnicamente possível usar
compromissos antigos, o mecanismo de penalidade torna economicamente irracional fazê-lo.
O bloqueio temporal é definido para um número de blocos de até 2.016 (aproximadamente duas
semanas). Se qualquer um dos parceiros do canal publicar uma transação de compromisso sem
cooperar com o outro parceiro, eles terão que esperar esse número de blocos (por exemplo, duas
semanas) para reivindicar seu saldo. O outro parceiro do canal pode reivindicar seu próprio saldo a
qualquer momento. Além disso, se o compromisso que eles publicaram foi previamente revogado, o
parceiro do canal também pode reivindicar imediatamente o saldo do trapaceiro, contornando o
bloqueio temporal e punindo o trapaceiro.
O bloqueio temporal é ajustável e pode ser negociado entre os parceiros do canal. Normalmente, ele
é mais longo para canais com maior capacidade e mais curto para canais menores, para alinhar os
incentivos com o valor dos fundos envolvidos.
Para cada nova atualização do saldo do canal, novas transações de compromisso e novos segredos
de revogação precisam ser criados e salvos. Enquanto um canal permanecer aberto, todos os
segredos de revogação já criados para o canal precisam ser mantidos, pois podem ser necessários
no futuro. Felizmente, os segredos são relativamente pequenos e apenas os parceiros do canal
precisam mantê-los, não toda a rede. Além disso, devido a um mecanismo inteligente de derivação
usado para derivar segredos de revogação, só precisamos armazenar o segredo mais recente, pois
segredos anteriores podem ser derivados a partir dele (see [revocation_secret_derivation]).
No entanto, gerenciar e armazenar os segredos de revogação é uma das partes mais elaboradas dos
nós Lightning, que requer que os operadores dos nós mantenham backups.
Tecnologias como serviços de torre de observação (watchtower services) ou a alteração do

protocolo de construção de canal para o protocolo Eltoo podem ser estratégias futuras para
mitigar esses problemas e reduzir a necessidade de segredos de revogação, transações de
9
penalidade e backups de canal.
Alice pode fechar o canal a qualquer momento se Bob não responder, reivindicando sua parte justa
do saldo. Após publicar a última transação de compromisso na cadeia de blocos, Alice precisa
esperar o vencimento do bloqueio temporal antes de poder gastar seus fundos provenientes da
transação de compromisso. Como veremos mais adiante, existe uma maneira mais fácil de fechar
um canal sem esperar, desde que Alice e Bob estejam online e cooperem para fechar o canal com a
alocação correta dos saldos. No entanto, as transações de compromisso armazenadas por cada
parceiro do canal atuam como uma medida de segurança, garantindo que eles não percam fundos
caso haja um problema com o parceiro do canal.
Anunciando o Canal
Os parceiros do canal podem concordar em anunciar seu canal para toda a Rede Lightning,
tornando-o um canal público. Para anunciar o canal, eles utilizam o protocolo de divulgação (gossip
protocol) da Rede Lightning para informar a outros nós sobre a existência, capacidade e taxas do
canal.
Anunciar canais publicamente permite que outros nós os usem para roteamento de pagamento,
gerando assim também taxas de roteamento para os parceiros de canal.
Por outro lado, os parceiros do canal podem decidir não anunciar o canal, tornando-o um canal não
anunciado.
Você pode ouvir o termo "canal privado" sendo usado para descrever um canal não anunciado.
Evitamos usar esse termo porque ele é enganoso e cria uma falsa sensação de privacidade.
Embora um canal não anunciado não seja conhecido por outros enquanto estiver em uso, sua
existência e capacidade serão reveladas quando o canal for encerrado, pois esses detalhes
serão visíveis on-chain na transação final de liquidação. Sua existência também pode vazar de
várias outras maneiras, portanto, evitamos chamá-lo de "privado".
Os canais não anunciados ainda são usados para rotear pagamentos, mas apenas pelos nós que
estão cientes de sua existência ou que recebem "dicas de roteamento" sobre um caminho que inclui
um canal não anunciado.
Quando um canal e sua capacidade são anunciados publicamente usando o protocolo de divulgação
(gossip protocol), o anúncio também pode incluir informações sobre o canal (metadados), como
suas taxas de roteamento e duração do bloqueio temporal.
Quando novos nós se juntam à Rede Lightning, eles coletam os anúncios de canais propagados por
meio do protocolo de divulgação (gossip protocol) de seus pares, construindo um mapa interno da
Rede Lightning. Esse mapa pode ser usado para encontrar caminhos para pagamentos, conectando
canais de ponta a ponta.
Fechando o Canal
A melhor maneira de fechar um canal é… não fechá-lo! Abrir e fechar canais requer uma transação
10
on-chain, o que implica em taxas de transação. Portanto, é melhor manter os canais abertos o
maior tempo possível. Você pode continuar usando seu canal para fazer e encaminhar pagamentos,
desde que tenha capacidade suficiente em sua extremidade do canal. Mas mesmo que você envie
todo o saldo para a outra extremidade do canal, você ainda pode usar o canal para receber
pagamentos do seu parceiro de canal. Esse conceito de usar um canal em uma direção e depois usá-
lo na direção oposta é chamado de "rebalanceamento" e examinaremos em mais detalhes em outro
capítulo. Ao fazer o rebalanceamento de um canal, ele pode ser mantido aberto por um período
praticamente indefinido e usado para um número essencialmente ilimitado de pagamentos.
No entanto, às vezes, fechar um canal é desejável ou necessário. Por exemplo:
• Você deseja reduzir o saldo mantido em seus canais Lightning por motivos de segurança e quer
enviar fundos para "armazenamento a frio" (cold storage).
• Seu parceiro de canal fica inativo por um longo período de tempo e você não consegue mais
usar o canal.
• O canal não está sendo usado com frequência porque seu parceiro de canal não é um nó bem
conectado, então você deseja usar os fundos para outro canal com um nó melhor conectado.
• Seu parceiro de canal violou o protocolo, seja devido a um erro de software ou

intencionalmente, forçando você a fechar o canal para proteger seus fundos.
Existem três maneiras de fechar um canal de pagamento:
• Fechamento mútuo (o jeito bom)
• Fechamento forçado (o jeito ruim)
• Quebra de protocolo (o jeito feio)
Cada um desses métodos é útil para circunstâncias diferentes, as quais exploraremos nas próximas
seções deste capítulo. Por exemplo, se seu parceiro de canal estiver offline, você não poderá seguir
"o caminho ideal" porque um fechamento mútuo não pode ser feito sem um parceiro cooperativo.
Geralmente, o seu software LN selecionará automaticamente o melhor mecanismo de fechamento
disponível de acordo com as circunstâncias.
Fechamento mútuo (o jeito bom)
O fechamento mútuo ocorre quando ambos os parceiros do canal concordam em fechar o canal e é
o método preferido de fechamento de canal.
Quando você decide que deseja fechar um canal, seu nó LN informará seu parceiro de canal sobre
sua intenção. Agora, tanto o seu nó quanto o nó do parceiro de canal trabalham juntos para fechar
o canal. Nenhuma nova tentativa de roteamento será aceita por qualquer um dos parceiros do
canal, e quaisquer tentativas de roteamento em andamento serão resolvidas ou removidas após o
tempo limite expirar. Finalizar as tentativas de roteamento leva tempo, portanto, um fechamento
mútuo também pode levar algum tempo para ser concluído.
Uma vez que não haja mais tentativas de roteamento pendentes, os nós cooperam para preparar
uma transação de fechamento (closing transaction). Essa transação é semelhante à transação de
compromisso: ela codifica o último saldo do canal, mas as saídas NÃO estão sujeitas a um bloqueio
temporal (timelock).
11
As taxas da transação on-chain para a transação de fechamento são pagas pelo parceiro do canal
que abriu o canal, e não pela pessoa que iniciou o procedimento de fechamento. Usando o
estimador de taxa on-chain, os parceiros do canal concordam com a taxa apropriada e ambos
assinam a transação de fechamento.
Uma vez que a transação de fechamento é transmitida e confirmada pela rede Bitcoin, o canal é
efetivamente fechado e cada parceiro do canal já recebeu sua parte do saldo do canal. Apesar do
tempo de espera, um fechamento mútuo geralmente é mais rápido do que um fechamento forçado.
Fechamento forçado (o jeito ruim)
Um fechamento forçado ocorre quando um dos parceiros do canal tenta fechar um canal sem o
consentimento do outro parceiro do canal.
Isso geralmente acontece quando um dos parceiros do canal está inacessível, portanto, um
fechamento mútuo não é possível. Nesse caso, você iniciaria um fechamento forçado para fechar
unilateralmente o canal e "liberar" os fundos.
Para iniciar um fechamento forçado, você pode simplesmente publicar a última transação de
compromisso que seu nó possui. Afinal, para isso servem as transações de compromisso.—elas
oferecem uma garantia de que você não precisa confiar em seu parceiro de canal para recuperar o
saldo do seu canal.
Uma vez que você transmita a última transação de compromisso para a rede Bitcoin e ela seja
confirmada, ela criará duas saídas gastáveis, uma para você e outra para seu parceiro. Conforme
discutimos anteriormente, a rede Bitcoin não tem como saber se essa foi a transação de
compromisso mais recente ou uma antiga que foi publicada para roubar do seu parceiro. Portanto,
essa transação de compromisso dará uma pequena vantagem ao seu parceiro. O parceiro que
iniciou o fechamento forçado terá sua saída sujeita a um bloqueio temporal, enquanto a saída do
outro parceiro será gasta imediatamente. No caso de você transmitir uma transação de
compromisso anterior, o atraso de bloqueio temporal dá ao seu parceiro a oportunidade de
contestar a transação usando o segredo de revogação e puni-lo por tentativa de trapaça.
Ao publicar uma transação de compromisso durante um fechamento forçado, as taxas on-chain

serão mais altas do que em um fechamento mútuo por várias razões:
1. Quando a transação de compromisso foi negociada, os parceiros do canal não sabiam quanto
seriam as taxas on-chain no momento futuro em que a transação seria transmitida. Como as
taxas não podem ser alteradas sem alterar as saídas da transação de compromisso (o que
requer ambas as assinaturas), e como o fechamento forçado ocorre quando um dos parceiros do
canal não está disponível para assinar, os desenvolvedores do protocolo decidiram ser muito
generosos com a taxa de taxa incluída nas transações de compromisso. Ela pode ser até cinco
vezes maior do que as estimativas de taxa sugerem no momento em que a transação de
compromisso é negociada.
2. A transação de compromisso inclui saídas adicionais para quaisquer tentativas de roteamento

pendentes usando contratos de bloqueio temporal por hash (HTLC), o que torna a transação de
compromisso maior (em termos de bytes) do que uma transação de fechamento mútuo.
Transações maiores incorrem em taxas mais altas.
3. Todas as tentativas de roteamento pendentes terão que ser resolvidas on-chain, o que causa
12
transações adicionais na cadeia de blocos.
Contratos de bloqueio temporal por hash, ou hash-time-locked contracts (HTLCs) serão

abordados em detalhes em [htlcs]. Por enquanto, vamos considerar que esses são pagamentos
que são roteados pela Rede Lightning, em vez de pagamentos feitos diretamente entre os dois
parceiros do canal. Esses HTLCs são incluídos como saídas adicionais nas transações de
compromisso, aumentando assim o tamanho da transação e as taxas on-chain.
Em geral, não é recomendado fazer um fechamento forçado, a menos que seja absolutamente
necessário. Seus fundos ficarão bloqueados por mais tempo e a pessoa que abriu o canal terá que
pagar taxas mais altas. Além disso, você pode ter que pagar taxas on-chain para abortar ou resolver
tentativas de roteamento, mesmo se você não tiver aberto o canal.
Se você conhece o parceiro do canal, você pode considerar entrar em contato com essa pessoa ou
empresa para perguntar por que o nó Lightning deles está inativo e solicitar que o reiniciem para
que vocês possam realizar um fechamento mútuo do canal.
Você deve considerar um fechamento forçado apenas como último recurso.
Quebra de protocolo (o jeito feio)
Uma violação de protocolo ocorre quando seu parceiro de canal tenta enganá-lo, seja
intencionalmente ou não, publicando uma transação de compromisso desatualizada na cadeia de
blocos do Bitcoin, essencialmente iniciando um fechamento forçado (desonesto) do lado dele.
Seu nó deve estar online e monitorando novos blocos e transações na blockchain do Bitcoin para
detectar isso.
Porque o pagamento do seu parceiro de canal estará sujeito a um bloqueio temporal, seu nó tem
algum tempo para agir e detectar uma violação de protocolo e publicar umatransação de punição
(punishment transaction) antes que o bloqueio temporal expire.
Se você detectar com sucesso a violação de protocolo e aplicar a penalidade, você receberá todos os
fundos no canal, incluindo os fundos do seu parceiro de canal.
Nesse cenário, o fechamento do canal será bastante rápido. Você terá que pagar taxas on-chain para
publicar a transação de penalidade, mas seu nó pode definir essas taxas de acordo com a estimativa
de taxas e evitar pagar em excesso. Geralmente, você desejará pagar taxas mais altas para garantir
a confirmação o mais rápido possível. No entanto, como você eventualmente receberá todos os
fundos do trapaceiro, é essencialmente o trapaceiro quem pagará por essa transação.
Se você não conseguir detectar a violação de protocolo e o bloqueio temporal expirar, você
receberá apenas os fundos alocados a você pela transação de compromisso que seu parceiro
publicou. Quaisquer fundos que você receber depois disso terão sido roubados pelo seu parceiro. Se
houver algum saldo alocado para você, você terá que pagar taxas na cadeia de blocos (on-chain)
para coletar esse saldo.
Assim como em um fechamento forçado, todas as tentativas de roteamento pendentes também

terão que ser resolvidas na transação de compromisso.
13
Uma violação de protocolo pode ser executada mais rapidamente do que um fechamento mútuo
porque você não precisa esperar para negociar um fechamento com seu parceiro, e mais
rapidamente do que um fechamento forçado porque você não precisa esperar o bloqueio temporal
expirar.
A teoria dos jogos prevê que trapacear não é uma estratégia atraente porque é fácil detectar um
trapaceiro, e o trapaceiro corre o risco de perder todos os seus fundos, enquanto tem a chance de
ganhar apenas o que tinha em um estado anterior. Além disso, à medida que a Rede Lightning
amadurece e as torres de observação (watchtowers) se tornam amplamente disponíveis, os
trapaceiros serão detectáveis por uma terceira parte, mesmo se o parceiro do canal que que foi
enganado estiver offline.
Portanto, não recomendamos trapacear. No entanto, recomendamos que qualquer pessoa que
pegue um trapaceiro o puna tomando seus fundos.
Então, como detectar um trapaceiro ou uma violação de protocolo em suas atividades diárias? Você
faz isso executando um software que monitora a blockchain pública do Bitcoin em busca de
transações on-chain que correspondam a quaisquer transações de compromisso para qualquer um
dos seus canais. Este software é um dos três tipos:
• Um nó Lightning devidamente mantido, funcionando 24 horas por dia, 7 dias por semana
• Um nó de torre de vigia de propósito único que você executa para monitorar seus canais Um nó
watchtower de terceiros ao qual você paga para monitorar seus canais
Lembre-se de que a transação de compromisso tem um período de tempo limite especificado em

um determinado número de blocos, com um máximo de 2.016 blocos. Desde que você execute seu
nó Lightning pelo menos uma vez antes do período de tempo limite ser alcançado, ele detectará
todas as tentativas de trapaça. Não é aconselhável correr esse tipo de risco; é importante manter
um nó bem-mantido em execução de forma contínua (see [continuous_operation]).
Faturas (Invoices)
A maioria dos pagamentos na Lightning Network começa com uma fatura, gerada pelo destinatário
do pagamento. No nosso exemplo anterior, Bob cria uma fatura para solicitar um pagamento de
Alice.
Existe uma maneira de enviar um pagamento não solicitado sem uma fatura, usando uma
solução alternativa no protocolo chamada keysend. Vamos examinar isso. [keysend].
Uma fatura é uma simples instrução de pagamento que contém informações como um identificador
único de pagamento (chamado de "payment hash"), um destinatário, um valor e uma descrição de
texto opcional.
A parte mais importante da fatura é o payment hash (hash de pagamento), que permite que o
pagamento percorra vários canais de forma atômica. Em ciência da computação, atômico significa
que uma ação ou mudança de estado é concluída com êxito ou não é concluída de forma
alguma—não há possibilidade de um estado intermediário ou ação parcial. Na Lightning Network,
14
isso significa que o pagamento percorre todo o caminho ou falha completamente. Não é possível
que seja concluído parcialmente, de forma que um nó intermediário no caminho possa receber o
pagamento e mantê-lo. Não existe algo como um "pagamento parcial" ou "pagamento parcialmente
bem-sucedido".
As faturas não são comunicadas através da Lightning Network. Em vez disso, elas são comunicadas
"out of band" (fora da banda) usando qualquer outro mecanismo de comunicação. Isso é
semelhante à forma como endereços de Bitcoin são comunicados a remetentes fora da rede Bitcoin:
como um código QR, por e-mail ou mensagem de texto. Por exemplo, Bob pode apresentar uma
fatura Lightning para Alice como um código QR, por e-mail ou por qualquer outro canal de
mensagem.
As faturas geralmente são codificadas como uma longa sequência codificada em bech32 ou como
um código QR, para serem escaneadas por uma carteira Lightning em um smartphone. A fatura
contém a quantidade de bitcoin solicitada e uma assinatura do destinatário. O remetente usa a
assinatura para extrair a chave pública (também conhecida como ID do nó) do destinatário, para
que o remetente saiba para onde enviar o pagamento.
Você notou como isso contrasta com Bitcoin e como termos diferentes são usados? No Bitcoin, o
destinatário fornece um endereço ao remetente. Na Lightning, o destinatário cria uma fatura e
envia-a ao remetente. No Bitcoin, o remetente envia fundos para um endereço. Na Lightning, o
remetente paga uma fatura e o pagamento é roteado para o destinatário. O Bitcoin é baseado no
conceito de um "endereço", enquanto a Lightning é uma rede de pagamento baseada no conceito de
uma "fatura". No Bitcoin, criamos uma "transação", enquanto na Lightning enviamos um
"pagamento".
Hash de Pagamento e Pré-Imagem
A parte mais importante da fatura é o payment hash. Ao construir a fatura, Bob criará esse hash de
pagamento da seguinte forma:
1. Bob escolhe um número aleatório r. Esse número aleatório é chamado de preimage (pré-
imagem) ou payment secret (segredo de pagamento).
2. Bob usa SHA-256 para calcular o hash H de r, chamado de payment hash:

H = SHA-256(r).
O termo pré-imagem vem da matemática. Em qualquer função y = f(x), o conjunto de entradas

que produzem um determinado valor y são chamados de preimagem de y. Nesse caso, a função
é o algoritmo de hash SHA-256, e qualquer valor r que produza o hash H é chamado de pré-
imagem.
Não há uma maneira conhecida de encontrar a inversa do SHA-256 (ou seja, calcular uma pré-
imagem a partir de um hash). Apenas Bob conhece o valor r, então é o segredo de Bob. Mas uma vez
que Bob revela r, qualquer pessoa que tenha o hash H pode verificar se r é o segredo correto,
calculando SHA-256(r) e verificando se corresponde a H.
O processo de pagamento da Lightning Network só é seguro se r for escolhido completamente
15
aleatoriamente e não for previsível. Essa segurança se baseia no fato de que funções de hash não
podem ser invertidas ou quebradas por força bruta de forma viável, e, portanto, ninguém pode
encontrar r a partir de H.
Metadados Adicionais
As faturas podem opcionalmente incluir outros metadados úteis, como uma breve descrição em
texto. Se um usuário tiver várias faturas para pagar, o usuário pode ler a descrição e ser lembrado
do que se trata a fatura.
A fatura também pode incluir algumas "dicas de roteamento" (routing hints), que permitem ao
remetente usar canais não anunciados para construir uma rota até o destinatário. As dicas de
roteamento também podem ser usadas para sugerir canais públicos, por exemplo, canais
conhecidos pelo destinatário por terem capacidade de entrada suficiente para rotear o pagamento.
Caso o nó Lightning do remetente não consiga enviar o pagamento pela Lightning Network, as
faturas podem opcionalmente incluir um endereço Bitcoin on-chain como alternativa.
Embora sempre seja possível "reverter" (fall back) para uma transação Bitcoin on-chain, na
verdade é melhor abrir um novo canal com o destinatário em vez disso. Se você precisar pagar
taxas on-chain para fazer um pagamento, é melhor utilizar essas taxas para abrir um canal e
fazer o pagamento pela Lightning. Após o pagamento ser feito, você terá um canal aberto com
liquidez no lado do destinatário, que poderá ser utilizado para rotear pagamentos de volta ao
seu nó Lightning no futuro. Uma transação on-chain oferece um pagamento e um canal para
uso futuro.
As faturas da Lightning contêm uma data de expiração. Como o destinatário precisa manter a pré-
imagem r para cada fatura emitida, é útil ter faturas com prazo de validade para que esses pré-
imagens não precisem ser mantidas para sempre. Uma vez que uma fatura expire ou seja paga, o
destinatário pode descartar a pré-image.
Entregando o Pagamento
Vimos como o destinatário cria uma fatura que contém um payment hash. Esse payment hash será
usado para mover o pagamento através de uma série de canais de pagamento, do remetente ao
destinatário, mesmo que eles não tenham um canal de pagamento direto entre eles.
Nas próximas seções, vamos mergulhar nas ideias e métodos que estão sendo utilizados para
efetuar um pagamento na Lightning Network e utilizar todos os conceitos que apresentamos até
agora.
Primeiro, vamos analisar o protocolo de comunicação da Lightning Network.
O Protocolo de Divulgação Ponto-a-Ponto
Como mencionado anteriormente, quando um canal de pagamento é construído, os parceiros do

canal têm a opção de torná-lo público, anunciando sua existência e detalhes para toda a Lightning
16
Network.
Os anúncios de canais são comunicados por meio de um protocolo de divulgação (gossip protocol)
ponto a ponto. Um protocolo ponto a ponto é um protocolo de comunicação no qual cada nó se
conecta a uma seleção aleatória de outros nós na rede, geralmente via TCP/IP. Cada um dos nós que
está diretamente conectado (via TCP/IP) ao seu nó é chamado de seus "pares" (peers). Seu nó, por
sua vez, é um dos "pares" deles. É importante observar que quando dizemos que seu nó está
conectado a outros "pares", não significa que você possui canais de pagamento, mas apenas que
você está conectado por meio do protocolo de divulgação.
Após abrir um canal, um nó pode optar por enviar um anúncio do canal por meio da mensagem
channel_announcement para seus pares. Cada par valida as informações da mensagem
channel_announcement e verifica se a transação de financiamento está confirmada na blockchain do
Bitcoin. Após a verificação, o nó encaminhará a mensagem de divulgação para seus próprios pares,
e eles a encaminharão para seus pares e assim por diante, espalhando o anúncio por toda a rede.
Para evitar comunicação excessiva, o anúncio do canal é encaminhado por cada nó somente se ele
ainda não tiver encaminhado esse anúncio anteriormente.
O protocolo de divulgação também é usado para anunciar informações sobre nós conhecidos com a
mensagem node_announcement. Para que essa mensagem seja encaminhada, um nó deve ter pelo
menos um canal público anunciado no protocolo de divulgação, mais uma vez para evitar tráfego
excessivo de comunicação.
Os canais de pagamento possuem vários metadados que são úteis para outros participantes da rede.
Esses metadados são usados principalmente para tomar decisões de roteamento.Como os nós
podem ocasionalmente alterar os metadados de seus canais, essas informações são compartilhadas
em uma mensagem channel_update. Essas mensagens serão encaminhadas aproximadamente
quatro vezes por dia (por canal) para evitar uma comunicação excessiva. O protocolo de divulgação
também possui uma variedade de consultas e mensagens para sincronizar inicialmente um nó com
a visão da rede ou para atualizar a visão do nó após ficar offline por um tempo.
Um grande desafio para os participantes da Lightning Network é que as informações de topologia

compartilhadas pelo protocolo de divulgação são apenas parciais. Por exemplo, a capacidade dos
canais de pagamento é compartilhada no protocolo de divulgação por meio da mensagem
channel_announcement. No entanto, essa informação não é tão útil quanto a distribuição real da
capacidade em termos do saldo local entre os dois parceiros do canal. Um nó só pode encaminhar a
quantidade de bitcoin que ele realmente possui (saldo local) dentro desse canal.
Embora a Lightning Network pudesse ter sido projetada para compartilhar informações de saldo
dos canais e uma topologia precisa, isso não foi feito por várias razões:
• Para proteger a privacidade dos usuários, a rede não divulga todas as transações financeiras e
pagamentos. Atualizações de saldo do canal revelariam que um pagamento foi transferido pelo
canal. Essas informações poderiam ser correlacionadas para revelar todas as origens e destinos
de pagamentos.
• Para escalar a quantidade de pagamentos que podem ser realizados na Lightning Network.
Lembre-se de que a Lightning Network foi criada, em primeiro lugar, porque notificar cada
participante sobre cada pagamento não escala bem. Portanto, a Lightning Network não pode ser
projetada de forma a compartilhar atualizações de saldo do canal entre os participantes.
17
• A Lightning Network é um sistema dinâmico. Ela muda constantemente e com frequência.
Novos nós são adicionados, outros nós são desligados, saldos mudam, etc. Mesmo que tudo seja
sempre comunicado, as informações serão válidas apenas por um curto período de tempo. Na
verdade, as informações frequentemente estão desatualizadas no momento em que são
recebidas.
Vamos examinar os detalhes do protocolo de divulgação em um capítulo posterior.
Por enquanto, é importante apenas saber que o protocolo de divulgação existe e que ele é usado
para compartilhar informações de topologia da Lightning Network. Essas informações de topologia
são cruciais para a entrega de pagamentos por meio da rede de canais de pagamento.
Descobrindo o Caminho e Roteamento
Pagamentos na Lightning Network são encaminhados ao longo de um caminho formado por canais
que conectam um participante a outro, desde a origem do pagamento até o destino do pagamento.
O processo de encontrar um caminho da origem ao destino é chamado de descoberta de caminho
(pathfinding). O processo de usar esse caminho para efetuar o pagamento é chamado de
roteamento (routing).
Uma crítica frequente à Lightning Network é que o roteamento não está resolvido, ou até
mesmo que é um problema "insolúvel". Na verdade, o roteamento é trivial. A descoberta de
caminho, por outro lado, é um problema difícil. Os dois termos frequentemente são
confundidos e precisam ser claramente definidos para identificar qual problema estamos
tentando resolver.
Como veremos a seguir, a Lightning Network atualmente utiliza um protocolo baseado em origem
para a descoberta de caminho e um protocolo onion-routed para o roteamento de pagamentos.
Baseado em origem significa que o remetente do pagamento precisa encontrar um caminho através
da rede até o destino desejado. Onion-routed significa que os elementos do caminho são em
camadas (como uma cebola), com cada camada criptografada de forma que só possa ser visualizada
por um nó de cada vez. Discutiremos o roteamento em camadas na próxima seção.
Descoberta de Caminho Baseada na Origem

Se soubéssemos os saldos exatos de todos os canais, poderíamos facilmente calcular um caminho de
pagamento usando qualquer um dos algoritmos de descoberta de caminho padrão ensinados em
qualquer aula de ciência da computação. Isso até poderia ser resolvido de uma forma que otimiza
as taxas pagas aos nós pelo encaminhamento do pagamento.
No entanto, as informações de equilíbrio de todos os canais não são e não podem ser conhecidas
por todos os participantes da rede. Precisamos de estratégias de descoberta de caminhos mais
inovadoras.
Com apenas informações parciais sobre a topologia da rede, encontrar caminhos adequados é um
desafio real, e pesquisas ativas ainda estão sendo conduzidas nessa área da Lightning Network. O
fato de que o problema de busca de caminhos não está "totalmente resolvido" na Lightning
18
Network é um ponto crítico importante em relação à tecnologia.
Uma crítica comum ao processo de busca de caminhos na Lightning Network é que ele é
insolúvel porque é equivalente ao problema NP-completo (completo em tempo polinomial não
determinístico) docaixeiro-viajante (TSP, traveling salesperson problem), que é um problema
fundamental na teoria da complexidade computacional. Na verdade, a descoberta de
caminhos na Lightning não é equivalente ao TSP e se enquadra em uma classe diferente de
problemas. Nós solucionamos com sucesso esse tipo de problema (descoberta de caminhos em
grafos com informações incompletas) toda vez que pedimos ao Google para nos fornecer
direções de carro com evasão de tráfego. Também solucionamos esse problema com sucesso
toda vez que roteamos um pagamento na Lightning Network.
O processo de descoberta de caminhos e roteamento pode ser implementado de várias maneiras

diferentes, e múltiplos algoritmos de descoberta de caminhos e roteamento podem coexistir na
Lightning Network, assim como existem diversos algoritmos de busca de caminhos e roteamento na
internet. A busca de caminhos com base na fonte (source-based pathfinding) é uma das muitas
soluções possíveis e tem sido bem-sucedida na escala atual da Lightning Network.
A estratégia de descoberta de caminhos atualmente implementada pelos nós da Lightning é tentar

iterativamente diferentes caminhos até encontrar um que tenha liquidez suficiente para
encaminhar o pagamento. Esse é um processo iterativo de tentativa e erro, até que o sucesso seja
alcançado ou nenhum caminho seja encontrado. O algoritmo atualmente não necessariamente
resulta no caminho com as menores taxas. Embora isso não seja ótimo e certamente possa ser
aprimorado, até mesmo essa estratégia simplista funciona bastante bem.
Essa "sondagem" é realizada pelo próprio nó ou carteira da Lightning e não é diretamente visível
para o usuário. O usuário pode perceber que a sondagem está ocorrendo apenas se o pagamento
não for concluído instantaneamente.
Na internet, utilizamos o Protocolo de Internet e um algoritmo de encaminhamento de IP para

encaminhar pacotes de internet do remetente para o destinatário. Embora esses protocolos
tenham a propriedade de permitir que os hosts da internet encontrem colaborativamente um
caminho para o fluxo de informações pela internet, não podemos reutilizar e adotar esse
protocolo para encaminhar pagamentos na Lightning Network. Ao contrário da internet, os
pagamentos na Lightning precisam ser atômicos, e os saldos dos canais devem permanecer
privados. Além disso, a capacidade do canal na Lightning muda com frequência, ao contrário
da internet, onde a capacidade da conexão é relativamente estática. Essas restrições exigem
estratégias inovadoras.
Claro, descobrir um caminho é trivial se quisermos pagar diretamente nosso parceiro de canal e
tivermos saldo suficiente do nosso lado do canal para fazê-lo. Em todos os outros casos, nosso nó
utiliza informações do protocolo de divulgação (gossip protocol) para realizar a busca de caminho.
Isso inclui os canais de pagamento públicos conhecidos atualmente, os nós conhecidos, a topologia
conhecida (como os nós conhecidos estão conectados), as capacidades conhecidas dos canais e as
políticas de taxas conhecidas definidas pelos proprietários dos nós.
19
Roteamento de Cebola
A Lightning Network utiliza um protocolo de roteamento de cebola (onion routing protocol)

semelhante à famosa rede Tor (The Onion Router).O protocolo de roteamento em camadas usado
[2]
na Lightning é chamado de SPHINX Mix Format, que será explicado em detalhes em um capítulo
posterior.
O formato de roteamento em camadas SPHINX Mix Format usado na Lightning é apenas

similar ao roteamento da rede Tor em termos de conceito, mas tanto o protocolo quanto a
implementação são completamente diferentes dos usados na rede Tor.
[3]
Um pacote de pagamento usado para o roteamento é chamado de "cebola" (onion).
Vamos usar a analogia da cebola para seguir um pagamento roteado. Em sua rota do remetente do
pagamento (pagador) ao destinatário do pagamento (beneficiário), a cebola é passada de nó para nó
ao longo do caminho. O remetente constrói toda a cebola, do centro para fora. Primeiro, o
remetente cria as informações de pagamento para o destinatário (final) do pagamento e as
criptografa com uma camada de criptografia que apenas o destinatário pode decifrar. Em seguida,
o remetente envolve essa camada com instruções para o nó no caminho imediatamente anterior ao
destinatário final e criptografa com uma camada que apenas aquele nó pode decifrar.
As camadas são construídas com instruções, trabalhando de trás para frente até que todo o
caminho seja codificado em camadas. O remetente então entrega a cebola completa ao primeiro nó
do caminho, que só pode ler a camada mais externa. Cada nó descasca uma camada, encontra
instruções dentro dela revelando o próximo nó no caminho e repassa a cebola. À medida que cada
nó descasca uma camada, ele não pode ler o resto da cebola. Tudo o que ele sabe é de onde a cebola
acabou de vir e para onde está indo a seguir, sem qualquer indicação sobre quem é o remetente
original ou o destinatário final.
Isso continua até que a cebola alcance o destino do pagamento (beneficiário). Em seguida, o nó de
destino abre a cebola e descobre que não há mais camadas para decifrar, podendo ler as
informações de pagamento contidas no interior.
Ao contrário de uma cebola real, ao descascar cada camada, os nós adicionam algum
preenchimento criptografado para manter o tamanho da cebola igual para o próximo nó.
Como veremos, isso torna impossível para qualquer um dos nós intermediários saber
qualquer informação sobre o tamanho (comprimento) do caminho, quantos nós estão
envolvidos no roteamento, quantos nós os precederam ou quantos os seguem. Isso aumenta a
privacidade ao evitar ataques de análise de tráfego triviais.
O protocolo de roteamento em camadas usado na Lightning tem as seguintes propriedades:
• Um nó intermediário só pode ver em qual canal ele recebeu uma cebola e em qual canal
encaminhá-la. Isso significa que nenhum nó de roteamento pode saber quem iniciou o
pagamento e para quem o pagamento é destinado. Essa é a propriedade mais importante, que
resulta em um alto grau de privacidade.
20
• As cebolas são pequenas o suficiente para caber em um único pacote TCP/IP e até mesmo em um
quadro de camada de enlace (por exemplo, Ethernet). Isso torna a análise de tráfego dos
pagamentos significativamente mais difícil, aumentando ainda mais a privacidade.
• As cebolas são construídas de forma que sempre tenham o mesmo comprimento,

independentemente da posição do nó de processamento ao longo do caminho. À medida que
cada camada é "descascada", a cebola é preenchida com dados criptografados "inúteis" para
manter o tamanho da cebola igual. Isso impede que os nós intermediários saibam sua posição
no caminho.
• As cebolas possuem um HMAC (código de autenticação de mensagem baseado em hash) para

que manipulações das cebolas seja prevenido e praticamente impossível.
• As cebolas podem ter até aproximadamente 26 saltos, ou camadas de cebola, se preferir. Isso
permite caminhos suficientemente longos. O comprimento exato do caminho disponível
depende da quantidade de bytes alocados para a carga útil de roteamento em cada salto.
• A criptografia da cebola para cada salto usa chaves de criptografia efêmeras diferentes. Se uma
chave (em particular, a chave privada de um nó) vazar em algum momento, um atacante não
pode descriptografá-las. Em termos mais simples, as chaves nunca são reutilizadas para
garantir mais segurança.
• Erros podem ser enviados de volta do nó com erro para o remetente original, usando o mesmo
protocolo de roteamento em camadas. As cebolas de erro são indistinguíveis das cebolas de
roteamento para observadores externos e nós intermediários. O roteamento de erro permite o
método de tentativa e erro "sondagem" (probing) usado para encontrar um caminho que tenha
capacidade suficiente para rotear com sucesso um pagamento.
O roteamento em camadas será examinado em detalhes em [onion_routing].
Algoritmo de Encaminhamento de Pagamento
Depois que o remetente de um pagamento encontra um caminho possível através da rede e

constrói uma cebola, o pagamento é encaminhado por cada nó no caminho. Cada nó processa uma
camada da cebola e a encaminha para o próximo nó no caminho.
Cada nó intermediário recebe uma mensagem Lightning chamada update_add_htlc com um hash de
pagamento e uma cebola. O nó intermediário executa uma série de etapas, chamada de algoritmo
de encaminhamento de pagamento (payment forwarding algorithm):
1. O nó descriptografa a camada externa da cebola e verifica a integridade da mensagem.
2. O nó confirma se pode cumprir as dicas de roteamento com base nas taxas do canal e na
capacidade disponível no canal de saída.
3. O nó trabalha com seu parceiro de canal no canal de entrada (incoming channel) para atualizar
o estado do canal.
4. O nó adiciona algum preenchimento ao final da cebola para mantê-la em um comprimento

constante, uma vez que removeu alguns dados do início.
5. O nó segue as dicas de roteamento para encaminhar o pacote de cebola modificado em seu

canal de pagamento de saída, enviando também uma mensagem update_add_htlc que inclui o
mesmo hash de pagamento e a cebola.
21
6. O nó trabalha com seu parceiro de canal no canal de saída para atualizar o estado do canal.
Claro, essas etapas são interrompidas e abortadas se um erro for detectado, e uma mensagem de
erro é enviada de volta ao remetente (emissor) da mensagem update_add_htlc. A mensagem de erro
também é formatada como uma cebola e enviada de volta pelo canal de entrada (incoming
channel).
Conforme o erro se propaga retroativamente em cada canal ao longo do caminho, os parceiros de

canal removem o pagamento pendente, revertendo o pagamento de maneira oposta à qual ele
começou.
Embora a probabilidade de falha de um pagamento seja alta se ele não for concluído rapidamente,
um nó nunca deve iniciar outra tentativa de pagamento ao longo de um caminho diferente antes
que a cebola retorne com um erro. O remetente pagaria duas vezes se ambas as tentativas de
pagamento fossem bem-sucedidas eventualmente.
Criptografia de Comunicação Ponto a Ponto

O protocolo LN é principalmente um protocolo ponto-a-ponto entre seus participantes. Como vimos
em seções anteriores, existem duas funções sobrepostas na rede, formando duas redes lógicas que
juntas são a Lightning Network:
1. Uma ampla rede ponto-a-ponto que usa um protocolo de disseminação de informações de

topologia (gossip protocol) para propagar informações, em que os pares se conectam
aleatoriamente entre si. Os pares nem sempre têm canais de pagamento entre si, então eles nem
sempre são parceiros de canal.
2. Uma rede de canais de pagamento entre parceiros de canal. Os parceiros de canal também
compartilham informações sobre a topologia, ou seja, são nós pares no protocolo de
transmissão.
Toda comunicação entre os pares é enviada por meio de mensagens chamadas mensagens
Lightning. Essas mensagens são todas criptografadas, utilizando um framework de comunicação
criptográficachamado Noise Protocol Framework. O Noise Protocol Framework permite a
construção de protocolos de comunicação criptográfica que oferecem autenticação, criptografia,
segredo de encaminhamento e privacidade de identidade. O Noise Protocol Framework também é
utilizado em diversos sistemas populares de comunicação criptografada de ponta a ponta, como
WhatsApp, WireGuard e I2P. Mais informações podem ser encontradas em at the Noise Protocol
Framework website.
O uso do Noise Protocol Framework na Lightning Network garante que cada mensagem na rede
seja autenticada e criptografada, aumentando a privacidade da rede e sua resistência à análise de
tráfego, inspeção profunda de pacotes e espionagem. No entanto, como efeito colateral, isso torna o
desenvolvimento e teste do protocolo um pouco complicados, pois não é possível simplesmente
observar a rede com uma captura de pacotes ou uma ferramenta de análise de rede, como o
Wireshark. Em vez disso, os desenvolvedores têm que usar plug-ins especializados que
descriptografam o protocolo a partir da perspectiva de um nó, como o lightning dissector, um plug-
in Wireshark.
22
Pensamentos Sobre Confiança
Desde que uma pessoa siga o protocolo e mantenha seu nó seguro, não há um grande risco de perda
de fundos ao participar da Lightning Network. No entanto, existe o custo de pagar taxas on-chain
ao abrir um canal. Qualquer custo deve estar acompanhado de um benefício correspondente. No
nosso caso, a recompensa para Alice por arcar com o custo de abrir um canal é que Alice pode
enviar e, após mover algumas das moedas para a outra extremidade do canal, receber pagamentos
em bitcoin na Lightning Network a qualquer momento, além de poder ganhar taxas em bitcoin ao
encaminhar pagamentos para outras pessoas. Alice está ciente de que, em teoria, Bob pode fechar o
canal imediatamente após a abertura, o que resultaria em taxas de fechamento on-chain para Alice.
Alice precisará ter um pequeno nível de confiança em Bob. Se Alice já esteve no Café do Bob e está
claro que Bob tem interesse em vender café para ela, então Alice pode confiar em Bob nesse
sentido. Existem benefícios mútuos tanto para Alice quanto para Bob. Alice decide que a
recompensa é suficiente para que ela assuma o custo da taxa on-chain para criar um canal com
Bob. Por outro lado, Alice não abrirá um canal para alguém desconhecido que, sem convite, enviou
um e-mail pedindo para abrir um novo canal.
Comparação com Bitcoin

Embora a Lightning Network seja construída em cima do Bitcoin e herde muitas de suas
características e propriedades, existem diferenças importantes que os usuários de ambas as redes
precisam estar cientes.
Algumas dessas diferenças são diferenças de terminologia. Também existem diferenças

arquiteturais e diferenças na experiência do usuário. Nas próximas seções, vamos examinar as
diferenças e semelhanças, explicar a terminologia e ajustar nossas expectativas.
Endereços Versus Faturas, Transações Versus Pagamentos
Em um pagamento típico usando Bitcoin, um usuário recebe um endereço Bitcoin (por exemplo,
escaneando um código QR em uma página da web ou recebendo-o em uma mensagem instantânea
ou e-mail de um amigo). Em seguida, eles usam sua carteira Bitcoin para criar uma transação e
enviar fundos para esse endereço.
Na Lightning Network, o destinatário de um pagamento cria uma fatura (invoice). Uma fatura na
Lightning pode ser vista como análoga a um endereço Bitcoin. O destinatário fornece a fatura da
Lightning ao remetente, seja como um código QR ou uma sequência de caracteres, assim como um
endereço Bitcoin.
O emissor usa sua carteira Lightning para pagar a fatura, copiando o texto da fatura ou escaneando
o código QR da fatura. Um pagamento na Lightning é análogo a uma "transação" do Bitcoin.
Existem algumas diferenças na experiência do usuário, no entanto. Um endereço Bitcoin é

"reutilizável". Endereços Bitcoin nunca expiram e, se o proprietário do endereço ainda possuir as
chaves, os fundos nele contidos estão sempre acessíveis. Um remetente pode enviar qualquer
quantidade de bitcoin para um endereço usado anteriormente, e um destinatário pode divulgar um
único endereço estático para receber muitos pagamentos. Embora isso vá contra as melhores
práticas por motivos de privacidade, é tecnicamente possível e, na verdade, bastante comum.
23
Na Lightning, no entanto, cada fatura só pode ser usada uma vez para um valor específico de
pagamento. Você não pode pagar mais ou menos, não pode usar uma fatura novamente e a fatura
tem um tempo de expiração embutido. Na Lightning, o destinatário precisa gerar uma nova fatura
para cada pagamento, especificando o valor do pagamento antecipadamente. Há uma exceção a
isso, um mecanismo chamado keysend, que vamos examinar em [keysend].
Selecionando Saídas Versus Encontrando um Caminho
Para fazer um pagamento na rede Bitcoin, o remetente precisa consumir uma ou mais saídas de
transação não gastas (UTXOs). Se um usuário tiver várias UTXOs, eles (ou melhor, sua carteira)
precisarão selecionar quais UTXOs enviar. Por exemplo, um usuário que faz um pagamento de 1
BTC pode usar uma única saída com valor de 1 BTC, duas saídas com valores de 0,25 BTC e 0,75 BTC,
ou quatro saídas com valor de 0,25 BTC cada.
Na Lightning, os pagamentos não exigem que as entradas sejam consumidas. Em vez disso, cada
pagamento resulta em uma atualização do saldo do canal, redistribuindo-o entre os dois parceiros
do canal. O remetente vivencia isso como "movendo" o saldo do canal de sua extremidade para a
outra extremidade, para o seu parceiro de canal. Os pagamentos na Lightning usam uma série de
canais para rotear do remetente ao destinatário. Cada um desses canais deve ter capacidade
suficiente para rotear o pagamento.
Como muitos canais e caminhos possíveis podem ser usados para fazer um pagamento, a escolha
dos canais e caminhos pelo usuário da Lightning é em certa medida análoga à escolha de UTXOs
(Unspent Transaction Output) pelo usuário do Bitcoin.
Com tecnologias como pagamentos atômicos multipath (AMP, Atomic Multipath Payments) e
pagamentos multipartes (MPP, Multipart Payments), que serão abordadas em capítulos
subsequentes, vários caminhos da Lightning podem ser agregados em um único pagamento
atômico, assim como várias UTXOs do Bitcoin podem ser agregadas em uma única transação
atômica do Bitcoin.
Saídas de Troco no Bitcoin versus Ausência de Troco na Lightning
Para realizar um pagamento na rede Bitcoin, o remetente precisa consumir uma ou mais saídas de
transações não gastas (UTXOs). UTXOs só podem ser gastas integralmente; elas não podem ser
divididas e parcialmente gastas. Portanto, se um usuário deseja gastar 0,8 BTC, mas possui apenas
uma UTXO de 1 BTC, eles precisam gastar toda a UTXO de 1 BTC, enviando 0,8 BTC para o
destinatário e 0,2 BTC de volta para si mesmos como troco. O pagamento de troco de 0,2 BTC cria
uma nova UTXO chamada change output, ou "saída de troco."
Na Lightning Network, a transação de financiamento consome algumas UTXOs do Bitcoin, criando

uma UTXO multiassinatura para abrir o canal. Uma vez que os bitcoins estão bloqueados dentro
desse canal, partes deles podem ser enviadas de ida e volta dentro do canal, sem a necessidade de
criar qualquer troco. Isso ocorre porque os parceiros do canal simplesmente atualizam o saldo do
canal e só criam uma nova UTXO quando o canal é eventualmente fechado usando a transação de
fechamento do canal.
24
Taxas de Mineração Versus Taxas de Roteamento
Na rede Bitcoin, os usuários pagam taxas aos mineradores para que suas transações sejam
incluídas em um bloco. Essas taxas são pagas ao minerador que minera aquele bloco específico. A
quantia da taxa é baseada no tamanho da transação em bytes que a transação está usando em um
bloco, bem como na rapidez com que o usuário deseja que essa transação seja minerada. Porque os
mineradores normalmente mineram as transações mais lucrativas primeiro, um usuário que deseja
que sua transação seja minerada imediatamente pagará uma taxa mais alta por byte, enquanto um
usuário que não está com pressa pagará uma taxa mais baixa por byte.
Na Lightning Network, os usuários pagam taxas a outros usuários (nós intermediários) para rotear
pagamentos através de seus canais. Para rotear um pagamento, um nó intermediário precisará
movimentar fundos em dois ou mais canais de sua propriedade, além de transmitir os dados para o
pagamento do remetente. Normalmente, o usuário responsável pelo roteamento cobrará do
remetente com base no valor do pagamento, tendo estabelecido uma taxa básica mínimataxa base
(uma taxa fixa para cada pagamento) e umafee rate (uma taxa proporcional ao valor do
pagamento). Pagamentos de valor mais alto custarão mais para serem roteados, e um mercado de
liquidez é formado, onde diferentes usuários cobram diferentes taxas para rotear através de seus
canais.
Taxas Variáveis Dependendo do Tráfego Versus Taxas Anunciadas
Na rede do Bitcoin, os mineradores buscam obter lucro e geralmente incluem o maior número
possível de transações em um bloco, respeitando a capacidade máxima do bloco chamada depeso
do bloco (block weight).
Se houver mais transações na fila (chamada de "mempool") do que podem ser incluídas em um
bloco, os mineradores começarão minerando as transações que pagam as maiores taxas por
unidade (bytes) de peso da transação (transaction weight). Portanto, quando há muitas transações
na fila, os usuários precisam pagar uma taxa mais alta para serem incluídos no próximo bloco, ou
então terão que esperar até que haja menos transações na fila. Isso naturalmente leva ao
surgimento de um mercado de taxas, onde os usuários pagam com base na urgência de terem suas
transações incluídas no próximo bloco.
Na rede do Bitcoin, o recurso escasso é o espaço nos blocos. Os usuários do Bitcoin competem pelo
espaço nos blocos, e o mercado de taxas do Bitcoin é baseado no espaço disponível nos blocos. Os
recursos escassos na Lightning Network são aliquidez dos canais (a capacidade de fundos
disponíveis para roteamento nos canais) e a conectividade dos canais (quantos nós bem conectados
os canais podem alcançar). Os usuários da Lightning competem pela capacidade e conectividade;
portanto, o mercado de taxas da Lightning é impulsionado pela capacidade e conectividade.
Na Lightning Network, os usuários pagam taxas aos usuários que encaminham seus pagamentos.
Encaminhar um pagamento, em termos econômicos, nada mais é do que fornecer e atribuir
capacidade ao remetente. Naturalmente, os roteadores que cobram taxas mais baixas pela mesma
capacidade serão mais atrativos para serem utilizados como rota. Assim, existe um mercado de
taxas no qual os roteadores competem entre si pelas taxas que cobram para encaminhar
pagamentos por meio de seus canais.
25
Transações Públicas de Bitcoin Versus Pagamentos Relâmpago Privados
Na rede do Bitcoin, todas as transações são publicamente visíveis no blockchain do Bitcoin. Embora
os endereços envolvidos sejam pseudônimos e geralmente não estejam vinculados a uma
identidade, eles ainda são vistos e validados por todos os outros usuários da rede. Além disso,
empresas de vigilância blockchain coletam e analisam esses dados em massa e os vendem para
partes interessadas, como empresas privadas, governos e agências de inteligência.
Por outro lado, os pagamentos LN são praticamente privados. Geralmente, apenas o remetente e o
destinatário têm conhecimento completo da origem, destino e valor transacionado em um
determinado pagamento. Além disso, o destinatário pode nem mesmo saber a origem do
pagamento. Como os pagamentos são roteados em camadas (onion routed), os usuários que roteiam
o pagamento têm conhecimento apenas do valor do pagamento, sem poder determinar a origem
nem o destino.
Em resumo, as transações do Bitcoin são transmitidas publicamente e armazenadas

permanentemente. Os pagamentos na Lightning são executados entre um número limitado de
pares selecionados, e as informações sobre eles são armazenadas de forma privada apenas até o
fechamento do canal. Criar ferramentas de vigilância em massa e análise equivalentes às usadas no
Bitcoin será muito mais difícil na Lightning.
Aguardando Confirmações Versus Liquidação Instantânea
Na rede do Bitcoin, as transações são apenas confirmadas quando são incluídas em um bloco, sendo
assim, elas são consideradas "confirmadas" nesse bloco. À medida que mais blocos são minerados, a
transação adquire mais "confirmações" e é considerada mais segura.
Na Lightning Network, as confirmações são relevantes apenas para a abertura e fechamento dos
canais na blockchain. Uma vez que uma transação de financiamento atinge um número adequado
de confirmações (por exemplo, 3), os parceiros do canal consideram o canal aberto. Como os bitcoin
no canal são garantidos por um contrato inteligente que gerencia esse canal, os pagamentos são
liquidados instantaneamente assim que são recebidos pelo destinatário final. Em termos práticos, a
liquidação instantânea significa que os pagamentos na Lightning Network levam apenas alguns
segundos para serem executados e liquidados. Assim como no Bitcoin, os pagamentos na Lightning
não são reversíveis.
Por fim, quando o canal é fechado, uma transação é realizada na rede do Bitcoin; assim que essa
transação for confirmada, o canal é considerado fechado.
Enviando Valores Arbitrários Versus Restrições de Capacidade
Na rede do Bitcoin, um usuário pode enviar qualquer quantidade de bitcoin que possua para outro
usuário, sem restrições de capacidade. Uma única transação teoricamente pode enviar até 21
milhões de bitcoin como pagamento.
Na Lightning Network, um usuário só pode enviar a quantidade de bitcoin que atualmente existe
do seu lado em um canal específico para o parceiro do canal. Por exemplo, se um usuário possui
um canal com 0,4 BTC do seu lado e outro canal com 0,2 BTC do seu lado, o máximo que ele pode
enviar em um único pagamento é de 0,4 BTC. Isso é válido independentemente da quantidade de
26
bitcoin que o usuário tenha atualmente em sua carteira de Bitcoin.
Pagamentos em várias partes (Multipart Payments, MPP) é um recurso que, no exemplo anterior,
permite ao usuário combinar seus canais de 0,4 BTC e 0,2 BTC para enviar no máximo 0,6 BTC com
um pagamento. Os MPPs estão sendo testados na Lightning Network e espera-se que estejam
amplamente disponíveis e usados quando este livro for concluído. Para mais detalhes sobre o MPP,
veja [mpp].
Se o pagamento for roteado, cada nó de roteamento ao longo do caminho de roteamento deve ter
canais com capacidade pelo menos igual ao valor do pagamento sendo roteado. Isso deve ser
verdadeiro para cada canal individual pelo qual o pagamento é roteado. A capacidade do canal de
menor capacidade em um caminho define o limite superior para a capacidade de todo o caminho.
Portanto, a capacidade e a conectividade são recursos críticos e escassos na Lightning Network.
Incentivos para Pagamentos de Grande Valor Versus Pagamentos de

Pequeno Valor
A estrutura de taxas no Bitcoin é independente do valor da transação. Uma transação de $1 milhão

tem a mesma taxa que uma transação de $1 no Bitcoin, desde que possuam um tamanho de
transação semelhante, em bytes (mais especificamente, "bytes virtuais" após o SegWit [Segregated
Witness protocol]). Na Lightning Network, a taxa é composta por uma taxa base fixa, além de uma
porcentagem do valor da transação. Portanto, na Lightning Network, a taxa de pagamento aumenta
com o valor do pagamento. Essas estruturas de taxas opostas criam incentivos diferentes e levam a
diferentes padrões de uso em relação ao valor das transações. Uma transação de maior valor será
mais barata no Bitcoin; portanto, os usuários preferirão o Bitcoin para transações de grande valor.
Da mesma forma, no outro extremo da escala, os usuários preferirão a Lightning para transações
de pequeno valor.
Utilizando a Blockchain como um Livro-Razão Versus um Sistema Judiciário
Na rede do Bitcoin, toda transação é eventualmente registrada em um bloco na blockchain. A

blockchain, dessa forma, forma um histórico completo de todas as transações desde a criação do
Bitcoin, e uma maneira de auditar completamente todos os bitcoin em existência. Uma vez que uma
transação é incluída na blockchain, ela é final. Assim, nenhuma disputa pode surgir e é inequívoca
a quantidade de bitcoin controlada por um determinado endereço em um ponto específico da
blockchain.
Na Lightning Network, o saldo em um canal em um determinado momento é conhecido apenas

pelos dois parceiros do canal e só se torna visível para o restante da rede quando o canal é fechado.
Quando o canal é fechado, o saldo final do canal é enviado para a blockchain do Bitcoin, e cada
parceiro recebe sua parte dos bitcoin naquele canal. Por exemplo, se o saldo inicial foi de 1 BTC
pago por Alice, e Alice fez um pagamento de 0,3 BTC para Bob, então o saldo final do canal será de
0,7 BTC para Alice e 0,3 BTC para Bob. Se Alice tentar trapacear ao enviar o estado inicial do canal
para a blockchain do Bitcoin, com 1 BTC para Alice e 0 BTC para Bob, então Bob pode retaliar
enviando o verdadeiro estado final do canal, além de criar uma transação de penalidade que lhe dá
todos os bitcoin no canal. Para a Lightning Network, a blockchain do Bitcoin atua como um sistema
judicial. Como um juiz robótico, o Bitcoin registra os saldos inicial e final de cada canal e aprova
penalidades se uma das partes tentar trapacear.
27
Offline Versus Online, Assíncrono Versus Síncrono
Quando um usuário de Bitcoin envia fundos para um endereço de destino, eles não precisam saber
nada sobre o destinatário. O destinatário pode estar offline ou online, e nenhuma interação entre
remetente e destinatário é necessária. A interação ocorre entre o remetente e a blockchain do
Bitcoin. Receber bitcoin na blockchain do Bitcoin é uma atividade passiva e assíncrona que não
requer nenhuma interação por parte do destinatário, nem que o destinatário esteja online a
qualquer momento. Os endereços de Bitcoin podem até ser gerados offline e nunca são
"registrados" na rede do Bitcoin. Somente gastar bitcoin requer interação.
Na Lightning Network, o destinatário deve estar online para concluir o pagamento antes que ele
expire. O destinatário deve executar um nó ou ter alguém que execute um nó em seu nome (um
terceiro custodiante). Para sermos exatos, tanto o nó do remetente quanto o nó do destinatário
devem estar online no momento do pagamento e devem se coordenar. Receber um pagamento na
Lightning Network é uma atividade ativa e síncrona entre remetente e destinatário, sem a
participação da maioria da Lightning Network ou da rede Bitcoin (exceto pelos nós intermediários
de roteamento, se houver).
A natureza síncrona e sempre online da Lightning Network é provavelmente a maior diferença na

experiência do usuário, e isso muitas vezes confunde os usuários que estão acostumados com o
Bitcoin.
Satoshis Versus Milisatoshis
Na rede do Bitcoin, a menor unidade é um satoshi, que não pode ser dividido ainda mais. A
Lightning Network é um pouco mais flexível, e os nós da Lightning trabalham com millisatoshis
(milésimos de um satoshi). Isso permite o envio de pagamentos minúsculos via Lightning. Um
pagamento de um único millisatoshi pode ser enviado através de um canal de pagamento, uma
quantia tão pequena que pode ser caracterizada corretamente como um nanopagamento.
A unidade de millisatoshi não pode, é claro, ser liquidada na blockchain do Bitcoin com essa
granularidade. Ao fechar o canal, os saldos são arredondados para o satoshi mais próximo. No
entanto, ao longo da vida útil de um canal, milhões de nanopagamentos são possíveis em níveis de
millisatoshi. A Lightning Network ultrapassa a barreira dos micropagamentos.
Semelhança entre o Bitcoin e a Lightning

Embora a Lightning Network se diferencie do Bitcoin em diversos aspectos, incluindo arquitetura e
experiência do usuário, ela é construída a partir do Bitcoin e mantém muitas das características
fundamentais do Bitcoin.
Unidade Monetária
Tanto a rede do Bitcoin quanto a Lightning Network utilizam as mesmas unidades monetárias:
bitcoin. Os pagamentos na Lightning usam exatamente o mesmo bitcoin das transações do Bitcoin.
Como consequência, devido à unidade monetária ser a mesma, o limite monetário também é o
mesmo: menos de 21 milhões de bitcoin. Dos 21 milhões de bitcoin totais da rede Bitcoin, alguns já
estão alocados em endereços de multisig 2-de-2 como parte dos canais de pagamento na Lightning
28
Network.
Irreversibilidade e Finalidade dos Pagamentos
Tanto as transações do Bitcoin quanto os pagamentos na Lightning são irreversíveis e imutáveis.

Não há operação de "desfazer" ou "estorno" em nenhum dos sistemas. Como remetente em ambos
os casos, é necessário agir de forma responsável. No entanto, como destinatário, você tem a
garantia de finalidade em suas transações.
Confiança e Risco de Contraparte
Assim como o Bitcoin, a Lightning Network requer que o usuário confie apenas na matemática, na
criptografia e que o software não tenha bugs críticos. Nem o Bitcoin nem a Lightning exigem que o
usuário confie em uma pessoa, empresa, instituição ou governo. Como a Lightning está construída
sobre o Bitcoin e depende do Bitcoin como sua camada de base subjacente, é claro que o modelo de
segurança da Lightning se baseia na segurança do Bitcoin. Isso significa que a Lightning oferece
amplamente a mesma segurança do Bitcoin na maioria das circunstâncias, havendo apenas uma
leve redução na segurança em algumas circunstâncias específicas.
Operação Sem Permissões
Tanto o Bitcoin quanto a Lightning podem ser utilizados por qualquer pessoa com acesso à internet
e ao software apropriado, como um nó (node) e uma carteira (wallet). Nenhuma das redes exige
que os usuários obtenham permissão, aprovação ou autorização de terceiros, empresas, instituições
ou governos. Governos podem proibir o uso do Bitcoin ou da Lightning dentro de sua jurisdição,
mas não podem impedir seu uso globalmente.
Código Aberto e Sistema Aberto
Tanto o Bitcoin quanto a Lightning são sistemas de software de código aberto construídos por uma
comunidade global descentralizada de voluntários, disponíveis sob licenças abertas. Ambos são
baseados em protocolos abertos e interoperáveis, operando como sistemas e redes abertos. Globais,
abertos e livres.
Conclusão
Neste capítulo, examinamos como a Lightning Network realmente funciona e todos os
componentes que a constituem. Analisamos cada etapa na construção, operação e fechamento de
um canal. Observamos como os pagamentos são roteados e, finalmente, comparamos a Lightning
com o Bitcoin e analisamos suas diferenças e semelhanças.
Nos próximos capítulos, abordaremos todos esses tópicos novamente, mas com muito mais
detalhes.
[1] Embora o whitepaper original do Lightning descrevesse canais financiados por ambos os parceiros do canal, a especificação
atual, a partir de 2020, pressupõe que apenas um dos parceiros comprometa fundos para o canal. A partir de maio de 2021, os
canais Lightning com financiamento duplo são experimentais na implementação LN do c-lightning.
[2] George Danezis and Ian Goldberg, "Sphinx: A Compact and Provably Secure Mix Format," in IEEE Symposium on Security and
Privacy (New York: IEEE, 2009), 269–282.
29
[3] O termo "cebola" (onion) foi originalmente utilizado pelo projeto Tor. Além disso, a rede Tor também é chamada de rede Onion
e o projeto utiliza uma cebola como seu logotipo. O nome do domínio de nível superior (top-level domain name) utilizado pelos
serviços Tor na internet é onion.
30
Software de Nó Lightning
Como vimos nos capítulos anteriores, um nó Lightning é um sistema computacional que participa
da Lightning Network. A Lightning Network não é um produto ou empresa; é um conjunto de
padrões abertos que define uma base para interoperabilidade. Como tal, o software de nó Lightning
foi desenvolvido por uma variedade de empresas e grupos da comunidade. A grande maioria do
software Lightning é de código aberto, o que significa que o código-fonte é aberto e licenciado de
forma a permitir a colaboração, compartilhamento e participação da comunidade no processo de
desenvolvimento. Da mesma forma, as implementações de nó Lightning que apresentaremos neste
capítulo são todas de código aberto e são desenvolvidas colaborativamente.
Ao contrário do Bitcoin, onde o padrão é definido por uma implementação de referência em

software (Bitcoin Core), naLightning o padrão é definido por uma série de documentos de padrões
chamados Base da Tecnologia Lightning (Basis of Lightning Technology, BOLT), encontrados no
lightning-rfc repository.
Não há uma implementação de referência da Lightning Network, mas existem várias

implementações concorrentes, compatíveis com o BOLT e interoperáveis, desenvolvidas por
diferentes equipes e organizações. As equipes que desenvolvem o software para a Lightning
Network também contribuem no desenvolvimento e evolução dos padrões BOLT.
Outra diferença significativa entre o software de nó Lightning e o software de nó Bitcoin é que os

nós Lightning não precisam operar em sincronia com as regras de consenso e podem ter
funcionalidades estendidas além do básico dos BOLTs. Portanto, equipes diferentes podem buscar
recursos experimentais variados que, se forem bem-sucedidos e amplamente adotados, podem se
tornar parte dos BOLTs posteriormente.
Neste capítulo, você aprenderá como configurar cada um dos pacotes de software para as
implementações de nós Lightning mais populares. Apresentamos essas implementações em ordem
alfabética para enfatizar que geralmente não preferimos ou endossamos uma em relação à outra.
Cada uma possui seus pontos fortes e fracos, e a escolha dependerá de uma variedade de fatores.
Como elas são desenvolvidas em diferentes linguagens de programação (por exemplo, Go, C, etc.),
sua escolha também pode depender do seu nível de familiaridade e expertise com uma linguagem
específica e conjunto de ferramentas de desenvolvimento.
Ambiente de Desenvolvimento para Lightning

Se você é um desenvolvedor, você vai querer configurar um ambiente de desenvolvimento com
todas as ferramentas, bibliotecas e softwares de suporte necessários para escrever e executar
software relacionado ao Lightning. Neste capítulo altamente técnico, iremos guiar você através
desse processo passo a passo. Se o conteúdo se tornar muito denso ou se você não estiver realmente
configurando um ambiente de desenvolvimento, sinta-se à vontade para pular para o próximo
capítulo, que é menos técnico.
Usando a Linha de Comando
Os exemplos neste capítulo, e de forma mais ampla na maior parte deste livro, utilizam um
terminal de linha de comando. Isso significa que você digita comandos em um terminal e recebe
1
respostas em texto. Além disso, os exemplos são demonstrados em um sistema operacional baseado
no kernel Linux e no sistema de software GNU, especificamente na versão estável de longo prazo
mais recente do Ubuntu (Ubuntu 20.04 LTS). A maioria dos exemplos pode ser replicada em outros
sistemas operacionais, como Windows ou macOS, com pequenas modificações nos comandos. A
maior diferença entre os sistemas operacionais é o gerenciador de pacotes que instala as diversas
bibliotecas de software e suas dependências. Nos exemplos fornecidos, usaremos o apt, que é o
gerenciador de pacotes do Ubuntu. No macOS, um gerenciador de pacotes comum usado para
desenvolvimento de código aberto é o Homebrew, que é acessado pelo comando brew.
Na maioria dos exemplos aqui, estaremos construindo o software diretamente a partir do código-
fonte. Embora isso possa ser um desafio, nos dá mais poder e controle. Se você tiver dificuldades,
pode optar por usar contêineres Docker, pacotes pré-compilados ou outros mecanismos de
instalação alternativos.
Em muitos dos exemplos deste capítulo, estaremos usando a interface de linha de comando do
sistema operacional (também conhecida como shell), acessada por meio de um aplicativo de
terminal. O shell primeiro exibirá um prompt como indicador de que está pronto para receber
seu comando. Em seguida, você digita um comando e pressiona a tecla Enter, ao qual o shell
responde com algum texto e um novo prompt para o próximo comando. O prompt pode
parecer diferente no seu sistema, mas nos exemplos a seguir, ele é indicado pelo símbolo $.
Nos exemplos, quando você vir texto após o símbolo $, não digite o símbolo $, mas digite o
comando imediatamente após ele. Em seguida, pressione a tecla Enter para executar o
comando. Nos exemplos, as linhas que seguem cada comando são as respostas do sistema
operacional a esse comando. Quando você vir o próximo prefixo $, saberá que é um novo
comando e deve repetir o processo.
Para manter as coisas consistentes, usamos o shell bash em todos os exemplos de linha de comando.
Embora outros shells se comportem de maneira semelhante, e você possa executar todos os
exemplos sem problemas, alguns dos scripts do shell são escritos especificamente para o shell bash
e podem exigir algumas alterações ou personalizações para serem executados em outro shell. Para
manter a consistência, você pode instalar o shell bash no Windows e no macOS, e ele já vem
instalado por padrão na maioria dos sistemas Linux.
Baixando o Repositório do Livros
Todos os exemplos de código estão disponíveis no repositório online do livro. Como o repositório
será mantido o mais atualizado possível, você deve sempre procurar a versão mais recente no
repositório online em vez de copiá-la do livro impresso ou do ebook.
Você pode baixar o repositório como um pacote ZIP visitando GitHub e selecionando o botão verde
"Code" no canto direito.
Alternativamente, você pode usar o comando git para criar um clone controlado por versão do
repositório em seu computador local. O Git é um sistema distribuído de controle de versão
amplamente utilizado por desenvolvedores para colaborar no desenvolvimento de software e
rastrear alterações em repositórios de software. Baixe e instale o git seguindo as instruções from
the Git Project.
2
Para fazer uma cópia local do repositório em seu computador, execute o comando git da seguinte
forma:
$ git clone https://github.com/lnbook/lnbook.git
Agora você tem uma cópia completa do repositório do livro em uma pasta chamada lnbook. Você
vai querer navegar até o diretório recém-baixado executando o comando:
$ cd lnbook
Todos os exemplos subsequentes assumirão que você está executando comandos de dentro desta
pasta.
Contêineres Docker
Muitos desenvolvedores usam um contêiner, que é um tipo de máquina virtual, para instalar um
sistema operacional pré-configurado e aplicativos com todas as dependências necessárias. Muito do
software do Lightning também pode ser instalado usando um sistema de contêiner, como o Docker
encontrado em the Docker home page. As instalações de contêiner são muito mais fáceis,
especialmente para aqueles que não estão acostumados com um ambiente de linha de comando.
O repositório do livro contém uma coleção de contêineres Docker que podem ser usados para
configurar um ambiente de desenvolvimento consistente para praticar e replicar os exemplos em
qualquer sistema. Como o contêiner é um sistema operacional completo que é executado com uma
configuração consistente, você pode ter certeza de que os exemplos funcionarão em seu
computador sem a necessidade de se preocupar com dependências, versões de bibliotecas ou
diferenças de configuração.
Os contêineres Docker geralmente são otimizados para ocupar o menor espaço em disco possível.
No entanto, neste livro, estamos usando contêineres para padronizar o ambiente e torná-lo
consistente para todos os leitores. Além disso, esses contêineres não são destinados a serem usados
para executar serviços em segundo plano. Em vez disso, eles são destinados a serem usados para
testar os exemplos e aprender interagindo com o software. Por essas razões, os contêineres são
bastante grandes e vêm com muitas ferramentas de desenvolvimento e utilitários. Comumente, a
distribuição Alpine é usada para contêineres Linux devido ao seu tamanho reduzido. No entanto,
fornecemos contêineres baseados no Ubuntu porque mais desenvolvedores estão familiarizados
com o Ubuntu, e essa familiaridade é mais importante para nós do que o tamanho.
A instalação e uso do Docker e seus comandos são detalhados no [appendix_docker]. Se você não
está familiarizado com o Docker, agora é um bom momento para revisar rapidamente essa seção.
Você pode encontrar as definições mais recentes de contêineres e configurações de compilação no

repositório do livro, na pasta code/docker . Cada contêiner está em uma pasta separada, como pode
ser visto no seguinte exemplo:
3
$ tree -F --charset=asciii code/docker
code/docker
|-- bitcoind/
| |-- bashrc
| |-- bitcoind/
| | |-- bitcoin.conf
| | `-- keys/
| | |-- demo_address.txt
| | |-- demo_mnemonic.txt
| | `-- demo_privkey.txt
| |-- bitcoind-entrypoint.sh
| |-- cli
| |-- Dockerfile
| `-- mine.sh*
|-- c-lightning/
| |-- bashrc
| |-- cli
| |-- c-lightning-entrypoint.sh
| |-- devkeys.pem
| |-- Dockerfile
| |-- fund-c-lightning.sh
| |-- lightningd/
| | `-- config
| |-- logtail.sh
| `-- wait-for-bitcoind.sh
|-- eclair/
| |-- bashrc
| |-- cli
| |-- Dockerfile
| |-- eclair/
| | `-- eclair.conf
| |-- eclair-entrypoint.sh
| |-- logtail.sh
|-- lnd/
| |-- bashrc
| |-- cli
| |-- Dockerfile
| |-- fund-lnd.sh
| |-- lnd/
| | `-- lnd.conf
| |-- lnd-entrypoint.sh
| |-- logtail.sh
|-- check-versions.sh
|-- docker-compose.yml
|-- Makefile
4
`-- run-payment-demo.sh*
Conforme veremos nas próximas seções, você pode construir esses contêineres localmente ou pode
obtê-los do repositório do livro no Docker Hub. As seções seguintes assumirão que você tenha
instalado o Docker e esteja familiarizado com o uso básico do comando docker.
Bitcoin Core e Regtest

A maioria das implementações de nós Lightning precisa de acesso a um nó Bitcoin completo para
funcionar.
A instalação de um nó Bitcoin completo e a sincronização da blockchain do Bitcoin estão fora do

escopo deste livro e são empreendimentos relativamente complexos por si só. Se você deseja tentar,
consulte Mastering Bitcoin, "Chapter 3: Bitcoin Core: The Reference Implementation," que discute a
instalação e operação de um nó Bitcoin.
Um nó Bitcoin pode ser operado no modo regtest, onde o nó cria uma blockchain do Bitcoin
simulada local para fins de teste. Nos exemplos a seguir, estaremos usando o modo regtest para nos
permitir demonstrar o Lightning sem a necessidade de sincronizar um nó Bitcoin ou correr riscos
com fundos reais.
O contêiner para o Bitcoin Core é chamado de bitcoind. Ele é configurado para executar o Bitcoin
Core no modo regtest e minerar 6 novos blocos a cada 10 segundos. Sua porta de chamada de
procedimento remoto (RPC) é exposta na porta 18443 e pode ser acessada por chamadas RPC com o
nome de usuário regtest e a senha regtest. Você também pode acessá-lo com um shell interativo e
executar comandos bitcoin-cli localmente.
Construindo o Contêiner do Bitcoin Core
Vamos preparar o contêiner bitcoind. A maneira mais fácil é baixar o contêiner mais recente do
Docker Hub:
$ docker pull lnbook/bitcoind

Using default tag: latest
latest: Pulling from lnbook/bitcoind
35807b77a593: Pull complete
e1b85b9c5571: Pull complete
[...]
288f1cc78a00: Pull complete
Digest: sha256:861e7e32c9ad650aa367af40fc5acff894e89e47aff4bd400691ae18f1b550e2
Status: Downloaded newer image for lnbook/bitcoind:latest
docker.io/lnbook/bitcoind:latest
Alternativamente, você pode construir o contêiner você mesmo a partir da definição de contêiner
local que está em code/docker/bitcoind/Dockerfile.
Você não precisa construir o contêiner se você usou o comando pull anteriormente para baixá-
5
lo do Docker Hub.
Construir o contêiner localmente usará um pouco menos da sua largura de banda de rede, mas
exigirá mais do seu tempo de CPU para construir. Usamos o comando docker build para construí-lo:
$ cd code/docker
$ docker run -it --name bitcoind lnbook/bitcoind
Starting bitcoind...
Bitcoin Core starting
Waiting for bitcoind to start
bitcoind started
================================================
Imported demo private key
Bitcoin address: 2NBKgwSWY5qEmfN2Br4WtMDGuamjpuUc5q1
Private key: cSaejkcWwU25jMweWEewRSsrVQq2FGTij1xjXv4x1XvxVRF1ZCr3
================================================
================================================
Balance: 0.00000000
================================================
Mining 101 blocks to unlock some bitcoin
[
"34c744207fd4dd32b70bac467902bd8d030fba765c9f240a2e98f15f05338964",
"64d82721c641c378d79b4ff2e17572c109750bea1d4eddbae0b54f51e4cdf23e",
[...]
"7a8c53dc9a3408c9ecf9605b253e5f8086d67bbc03ea05819b2c9584196c9294",
"39e61e50e34a9bd1d6eab51940c39dc1ab56c30b21fc28e1a10c14a39b67a1c3",
"4ca7fe9a55b0b767d2b7f5cf4d51a2346f035fe8c486719c60a46dcbe33de51a"
]
Mining 6 blocks every 10 seconds
Balance: 50.00000000
[
"5ce76cc475e40515b67e3c0237d1eef597047a914ba3f59bbd62fc3691849055",
"1ecb27a05ecfa9dfa82a7b26631e0819b2768fe5e6e56c7a2e1078b078e21e9f",
"717ceb8b6c329d57947c950dc5668fae65bddb7fa03203984da9d2069e20525b",
"185fc7cf3557a6ebfc4a8cdd1f94a8fa08ed0c057040cdd68bfb7aee2d5be624",
"59001ae237a3834ebe4f6e6047dcec8fd67df0352ddc70b6b02190f982a60384",
"754c860fe1b9e0e7292e1de96a65eaa78047feb4c72dbbde2a1d224faa1499dd"
]
Como você pode ver, o bitcoind é iniciado e minera 101 blocos simulados para iniciar a cadeia. Isso
ocorre porque, de acordo com as regras de consenso do Bitcoin, os bitcoin recém-minerados não
são gastáveis até que tenham se passado 100 blocos. Ao minerar 101 blocos, tornamos a moeda do
primeiro bloco (coinbase) gastável. Após essa atividade inicial de mineração, 6 novos blocos são
minerados a cada 10 segundos para manter a cadeia em movimento.
Por enquanto, não há transações. Mas temos alguns bitcoin de teste que foram minerados na
carteira e estão disponíveis para gastar. Quando conectarmos alguns nós Lightning a esta cadeia,
6
enviaremos alguns bitcoin para suas carteiras para que possamos abrir alguns canais Lightning
entre os nós Relâmpago.
Interagindo com o contêiner bitcoin core
Enquanto isso, também podemos interagir com o contêiner bitcoind enviando comandos de shell. O
contêiner está enviando um arquivo de log (logfile) para o terminal, exibindo o processo de
mineração do processo bitcoind. Para interagir com o shell, podemos enviar comandos em outro
terminal, usando o comando docker exec. Como nomeamos o contêiner em execução
anteriormente com o argumento name, podemos nos referir a ele por esse nome quando
executarmos o comando docker exec. Primeiro, vamos executar um shell bash interativo:
$ docker exec -it bitcoind /bin/bash

root@e027fd56e31a:/bitcoind# ps x
PID TTY STAT TIME COMMAND
1 pts/0 Ss+ 0:00 /bin/bash /usr/local/bin/mine.sh
7 ? Ssl 0:03 bitcoind -datadir=/bitcoind -daemon
97 pts/1 Ss 0:00 /bin/bash
124 pts/0 S+ 0:00 sleep 10
125 pts/1 R+ 0:00 ps x
root@e027fd56e31a:/bitcoind#
Ao executar o shell interativo, entramos "dentro" do contêiner. Ele faz login como usuário root,
como podemos ver pelo prefixo root@ no novo prompt de shell root@e027fd56e31a:/bitcoind#. Se
digitarmos o comando ps x para ver quais processos estão em execução, veremos tanto o bitcoind
quanto o script mine.sh rodando em segundo plano. Para sair deste shell, pressione Ctrl-D ou digite
exit, e você será retornado ao prompt do seu sistema operacional.
Em vez de executar um shell interativo, também podemos emitir um único comando que é
executado dentro do contêiner. Para facilitar, o comando bitcoin-cli tem um alias "cli" que passa a
configuração correta. Então, vamos executá-lo para consultar o Bitcoin Code sobre o blockchain.
Executamos cli getblockchaininfo:
$ docker exec bitcoind cli getblockchaininfo

{
"chain": "regtest",
"blocks": 131,
"headers": 131,
"bestblockhash": "2cf57aac35365f52fa5c2e626491df634113b2f1e5197c478d57378e5a146110",
[...]
"warnings": ""
}
O comando cli no contêiner bitcoind nos permite emitir comandos RPC (Remote Procedure Call)
para o nó do Bitcoin Core e obter resultados codificados em JavaScript Object Notation (JSON).
7
Além disso, todos os nossos contêineres Docker possuem um codificador/decodificador JSON de
linha de comando chamado jq pré-instalado. O jq nos ajuda a processar dados formatados em JSON
por meio da linha de comando ou de dentro de scripts. Você pode enviar a saída JSON de qualquer
comando para o jq usando o caractere |. Esse caractere, assim como essa operação, é chamado de
"pipe". Vamos aplicar um pipe e o jq ao comando anterior da seguinte maneira:
$ docker exec bitcoind bash -c "cli getblockchaininfo | jq .blocks"

197
jq .blocks instrui o decodificador JSON jq a extrair o campo blocks do resultado getblockchaininfo.

No nosso caso, ele extrai e imprime o valor de 197, que poderíamos usar em um comando
subsequente.
Como veremos nas seções a seguir, podemos executar vários contêineres ao mesmo tempo e
interagir com eles individualmente. Podemos emitir comandos para extrair informações, como a
chave pública do nó Lightning, ou realizar ações, como abrir um canal Lightning para outro nó. Os
comandos docker run e docker exec, juntamente com o jq para decodificação JSON, são tudo o que
precisamos para construir uma Rede Lightning funcional que combina várias implementações de
nós diferentes. Isso nos permite realizar diversos experimentos em nosso próprio computador.
O Projeto de Nó Lightning c-lightning

c-lightning é uma implementação leve, altamente personalizável, e compatível com os padrões do
protocolo LN (Lightning Network). Foi desenvolvido pela Blockstream como parte do Elements
Project. O projeto é de código aberto e desenvolvido colaborativamente em GitHub.
Nas próximas seções, iremos construir um contêiner Docker que executa um nó c-lightning
conectado ao contêiner bitcoind que construímos anteriormente. Também mostraremos como
configurar e construir o software c-lightning diretamente a partir do código-fonte.
Construindo o c-lightning como um Contêiner Docker
A distribuição de software do c-lightning possui um contêiner Docker, mas ele foi projetado para
executar o c-lightning em sistemas de produção e ao lado de um nó bitcoind. Nós estaremos
usando um contêiner um pouco mais simples configurado para executar o c-lightning para fins de
demonstração.
Vamos obter o contêiner c-lightning do repositório Docker Hub do livro:
$ docker pull lnbook/c-lightning

latest: Pulling from lnbook/c-lightning
[...]
Digest: sha256:bdefcefe8a9712e7b3a236dcc5ab12d999c46fd280e209712e7cb649b8bf0688
Status: Downloaded image for lnbook/c-lightning:latest
8
docker.io/lnbook/c-lightning:latest
Alternativamente, podemos construir o contêiner Docker do c-lightning a partir dos arquivos do

livro que você baixou anteriormente em um diretório chamado lnbook. Assim como antes,
usaremos o comando docker build no subdiretório code/docker. Vamos marcar a imagem do
contêiner com a tag lnbook/c-lightning, da seguinte forma:
$ cd code/docker
$ docker build -t lnbook/c-lightning c-lightning
Sending build context to Docker daemon 91.14kB
Step 1/34 : ARG OS=ubuntu
Step 2/34 : ARG OS_VER=focal
Step 3/34 : FROM ${OS}:${OS_VER} as os-base
---> fb52e22af1b0
[...]
Step 34/34 : CMD ["/usr/local/bin/logtail.sh"]

---> Running in 8d3d6c8799c5
Removing intermediate container 8d3d6c8799c5
---> 30b6fd5d7503
Successfully built 30b6fd5d7503
Successfully tagged lnbook/c-lightning:latest
Nosso contêiner agora está construído e pronto para ser executado. No entanto, antes de executar o
contêiner c-lightning, precisamos iniciar o contêiner bitcoind em outro terminal, pois o c-
lightning depende do bitcoind. Também precisaremos configurar uma rede Docker que permita
que os contêineres se conectem entre si como se estivessem na mesma rede local.
Contêineres Docker podem "conversar" entre si por meio de uma rede local virtual gerenciada
pelo sistema Docker. Cada contêiner pode ter um nome personalizado e outros contêineres
podem usar esse nome para resolver seu endereço IP e se conectar facilmente a ele.
Configurando uma Rede Docker
Uma vez que uma rede Docker é configurada, o Docker ativará a rede em nosso computador local
sempre que o Docker for iniciado, por exemplo, após uma reinicialização. Portanto, só precisamos
configurar uma rede uma vez usando o comando docker network create. O nome da rede em si não
é importante, mas precisa ser único em nosso computador. Por padrão, o Docker possui três redes
chamadas host, bridge e none. Vamos nomear nossa nova rede como lnbook e criá-la da seguinte
forma:
$ docker network create lnbook

ad75c0e4f87e5917823187febedfc0d7978235ae3e88eca63abe7e0b5ee81bfb
$ docker network ls
NETWORK ID NAME DRIVER SCOPE
9
7f1fb63877ea bridge bridge local
4e575cba0036 host host local
ad75c0e4f87e lnbook bridge local
ee8824567c95 none null local
Como você pode ver, executar docker network ls nos fornece uma lista das redes Docker. A nossa
rede lnbook foi criada. Podemos ignorar o ID da rede, pois ele é gerenciado automaticamente.
Executando os Contêineres bitcoind e c-lightning
O próximo passo é iniciar os contêineres bitcoind e c-lightning e conectá-los à rede lnbook. Para
executar um contêiner em uma rede específica, devemos passar o argumento network para o
comando docker run. Para facilitar a localização dos contêineres entre si, também daremos a cada
um deles um nome usando o argumento name. Iniciamos o bitcoind da seguinte forma:
$ docker run -it --network lnbook --name bitcoind lnbook/bitcoind
Você deverá ver o bitcoind iniciar e começar a minerar blocos a cada 10 segundos. Deixe-o em
execução e abra uma nova janela do terminal para iniciar o c-lightning. Usamos um comando
docker run semelhante com os argumentos network e name para iniciar o c-lightning da seguinte
maneira:
$ docker run -it --network lnbook --name c-lightning lnbook/c-lightning

Waiting for bitcoind to start...
Waiting for bitcoind to mine blocks...
Starting c-lightning...
2021-09-12T13:14:50.434Z UNUSUAL lightningd: Creating configuration directory
/lightningd/regtest
Startup complete
Funding c-lightning wallet
8a37a183274c52d5a962852ba9f970229ea6246a096ff1e4602b57f7d4202b31
lightningd: Opened log file /lightningd/lightningd.log
lightningd: Creating configuration directory /lightningd/regtest
lightningd: Opened log file /lightningd/lightningd.log
O contêiner c-lightning é inicializado e conecta-se ao contêiner bitcoind por meio da rede Docker.
Primeiro, nosso nó c-lightning aguardará o início do bitcoind e, em seguida, aguardará até que o
bitcoind tenha minerado alguns bitcoin em sua carteira. Finalmente, como parte da inicialização do
contêiner, um script enviará um comando RPC para o nó bitcoind, o qual criará uma transação que
financia a carteira do c-lightning com 10 BTC de teste. Agora, nosso nó c-lightning não só está em
execução, mas também possui alguns bitcoin de teste para usar!
Como demonstramos com o contêiner bitcoind, podemos emitir comandos para nosso contêiner c-
lightning em outro terminal para extrair informações, abrir canais, etc. O comando que nos
permite emitir instruções de linha de comando para o nó c-lightning é chamado de lightning-cli.
Esse comando lightning-cli também é aliado como cli dentro desse contêiner. Para obter as
informações do nó c-lightning, use o seguinte comando docker exec em outra janela do terminal:
10
$ docker exec c-lightning cli getinfo
{
"id": "026ec53cc8940df5fed5fa18f8897719428a15d860ff4cd171fca9530879c7499e",
"alias": "IRATEARTIST",
"color": "026ec5",
"num_peers": 0,
"num_pending_channels": 0,
[...]
"version": "0.10.1",
"blockheight": 221,
"network": "regtest",
"msatoshi_fees_collected": 0,
"fees_collected_msat": "0msat",
"lightning-dir": "/lightningd/regtest"
}
Agora temos nosso primeiro nó Lightning em execução em uma rede virtual e se comunicando com
uma blockchain de teste do Bitcoin. Mais tarde neste capítulo, iniciaremos mais nós e os
conectaremos entre si para realizar alguns pagamentos na Lightning.
Na próxima seção, também veremos como baixar, configurar e compilar o c-lightning diretamente
a partir do código-fonte. Esta é uma etapa opcional e avançada que ensinará você a usar as
ferramentas de compilação e permitirá fazer modificações no c-lightning código-fonte. Com esse
conhecimento, você poderá escrever código, corrigir erros ou criar um plug-in para o c-lightning.
Se você não planeja mergulhar no código-fonte ou na programação de um nó Lightning, pode

pular completamente a próxima seção. O contêiner Docker que acabamos de construir é
suficiente para a maioria dos exemplos no livro.
Instalando o c-lightning a partir do Código-Fonte
Os desenvolvedores do c-lightning forneceram instruções detalhadas para a construção do c-

lightning a partir do código-fonte. Seguiremos as instruções from GitHub.
Instalando Bibliotecas e Pacotes Pré-requisitos
Essas instruções de instalação pressupõem que você está construindo o c-lightning em um sistema
Linux ou similar, com ferramentas de compilação GNU. Se esse não for o caso, procure as
instruções para o seu sistema operacional no repositório do Elements Project.
O primeiro passo comum é a instalação das bibliotecas pré-requisitas. Utilizamos o gerenciador de

pacotes apt para instalá-las:
$ sudo apt-get update
11
Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:2 http://eu-north-1b.clouds.archive.ubuntu.com/ubuntu bionic InRelease
Get:3 http://eu-north-1b.clouds.archive.ubuntu.com/ubuntu bionic-updates InRelease
[88.7 kB]
[...]
Fetched 18.3 MB in 8s (2,180 kB/s)

Reading package lists... Done
$ sudo apt-get install -y \

autoconf automake build-essential git libtool libgmp-dev \
libsqlite3-dev python python3 python3-mako net-tools zlib1g-dev \
libsodium-dev gettext
Reading package lists... Done

Building dependency tree
Reading state information... Done
The following additional packages will be installed:
autotools-dev binutils binutils-common binutils-x86-64-linux-gnu cpp cpp-7 dpkg-dev
fakeroot g++ g++-7 gcc gcc-7 gcc-7-base libalgorithm-diff-perl
[...]
Setting up libsigsegv2:amd64 (2.12-2) ...

Setting up libltdl-dev:amd64 (2.4.6-14) ...
Setting up python2 (2.7.17-2ubuntu4) ...
Setting up libsodium-dev:amd64 (1.0.18-1) ...
[...]
$
Após alguns minutos e muita atividade na tela, você terá instalado todos os pacotes e bibliotecas
necessárias. Muitas dessas bibliotecas também são utilizadas por outros pacotes do Lightning e são
necessárias para o desenvolvimento de software em geral.
Copiando o Código-Fonte do c-lightning
Em seguida, copiaremos a versão mais recente do c-lightning do repositório de código-fonte. Para

fazer isso, usaremos o comando git clone, que clona uma cópia controlada por versão em sua
máquina local, permitindo que você a mantenha sincronizada com alterações subsequentes sem
precisar baixar todo o repositório novamente:
$ git clone --recurse https://github.com/ElementsProject/lightning.git

Cloning into 'lightning'...
remote: Enumerating objects: 24, done.
remote: Counting objects: 100% (24/24), done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 53192 (delta 5), reused 5 (delta 2), pack-reused 53168
12
Receiving objects: 100% (53192/53192), 29.59 MiB | 19.30 MiB/s, done.
Resolving deltas: 100% (39834/39834), done.
$ cd lightning
Agora temos uma cópia do c-lightning clonado na subpasta lightning, e usamos o comando cd
(mudar diretório) para entrar nessa subpasta.
Compilando o Código-Fonte c-lightning
Em seguida, usamos um conjunto de scripts de construção que são comumente encontrados em

muitos projetos de código aberto. Esses scripts de construção utilizam os comandos configure e
make, que nos permitem:
• Selecionar as opções de construção e verificar as dependências necessárias (configure)
• Construir e instalar os executáveis e bibliotecas (make)
Executar configure com a opção help nos mostrará todas as opções disponíveis:
$ ./configure --help
Usage: ./configure [--reconfigure] [setting=value] [options]
Options include:
--prefix= (default /usr/local)
Prefix for make install
--enable/disable-developer (default disable)
Developer mode, good for testing
--enable/disable-experimental-features (default disable)
Enable experimental features
--enable/disable-compat (default enable)
Compatibility mode, good to disable to see if your software breaks
--enable/disable-valgrind (default (autodetect))
Run tests with Valgrind
--enable/disable-static (default disable)
Static link sqlite3, gmp and zlib libraries
--enable/disable-address-sanitizer (default disable)
Compile with address-sanitizer
Não precisamos alterar nenhum dos valores padrão neste exemplo. Portanto, executamos configure
novamente sem nenhuma opção para usar os padrões:
$ ./configure
Compiling ccan/tools/configurator/configurator...done
checking for python3-mako... found
Making autoconf users comfortable... yes
checking for off_t is 32 bits... no
checking for __alignof__ support... yes
13
[...]
Setting COMPAT... 1
PYTEST not found
Setting STATIC... 0
Setting ASAN... 0
Setting TEST_NETWORK... regtest
$
Em seguida, usamos o comando make para construir as bibliotecas, componentes e executáveis do

projeto c-lightning. Esta etapa levará vários minutos para ser concluída e utilizará intensivamente
a CPU e o disco do seu computador. Espere um pouco de ruído dos ventiladores! Execute o comando
make:
$ make
cc -DBINTOPKGLIBEXECDIR="\"../libexec/c-lightning\"" -Wall -Wundef -Wmis...
[...]
cc -Og ccan-asort.o ccan-autodata.o ccan-bitmap.o ccan-bitops.o ccan-...
Se tudo correr bem, você não verá nenhuma mensagem de ERROR que interrompa a execução do
comando anterior. O pacote de software c-lightning foi compilado a partir do código-fonte e agora
estamos prontos para instalar os componentes executáveis que criamos na etapa anterior:
$ sudo make install
mkdir -p /usr/local/bin
mkdir -p /usr/local/libexec/c-lightning
mkdir -p /usr/local/libexec/c-lightning/plugins
mkdir -p /usr/local/share/man/man1
mkdir -p /usr/local/share/doc/c-lightning
install cli/lightning-cli lightningd/lightningd /usr/local/bin
[...]
To verify that the lightningd and lightning-cli commands have been installed correctly, we will ask
each executable for its version information:
$ lightningd --version
v0.10.1-34-gfe86c11
$ lightning-cli --version
14
v0.10.1-34-gfe86c11
A versão consiste na versão de lançamento mais recente (v0.10.1), seguida pelo número de
alterações desde o lançamento (34) e, por fim, um hash que identifica exatamente qual a revisão
(fe86c11). Você pode ver uma versão diferente da mostrada anteriormente, pois o software
continua a evoluir muito após a publicação deste livro. No entanto, independentemente da versão
que você veja, o fato de os comandos serem executados e responderem com informações de versão
significa que você teve sucesso na construção do software c-lightning.
O Projeto do Nó Daemon da Lightning Network

O Lightning Network Daemon (LND) é uma implementação completa de um nó LN desenvolvida
pela Lightning Labs. O projeto LND fornece várias aplicações executáveis, incluindo lnd (o próprio
daemon) e lncli (a utilidade de linha de comando). O LND possui vários serviços de cadeia de
backend conectáveis, incluindo btcd (um nó completo), bitcoind (Bitcoin Core) e Neutrino (um novo
cliente leve experimental). O LND é escrito na linguagem de programação Go. O projeto é de código
aberto e desenvolvido colaborativamente em GitHub.
Nas próximas seções, iremos construir um contêiner Docker para executar o LND, construir o LND
a partir do código-fonte e aprender como configurar e executar o LND.
O Contêiner Docker do LND
Podemos obter o contêiner Docker do LND de exemplo do repositório Docker Hub do livro:
$ docker pull lnbook/lnd

latest: Pulling from lnbook/lnd
35807b77a593: Already exists
e1b85b9c5571: Already exists
52f9c252546e: Pull complete
[...]
Digest: sha256:e490a0de5d41b781c0a7f9f548c99e67f9d728f72e50cd4632722b3ed3d85952
Status: Downloaded newer image for lnbook/lnd:latest
docker.io/lnbook/lnd:latest
Alternativamente, podemos construir o contêiner do LND localmente. O contêiner está localizado

em code/docker/lnd. Alteramos o diretório de trabalho para code/docker e executamos o comando
docker build:
$ cd code/docker
$ docker build -t lnbook/lnd lnd
Step 1/29 : FROM golang:1.13 as lnd-base
---> e9bdcb0f0af9
15
Step 2/29 : ENV GOPATH /go
[...]

---> Using cache
---> 397ce833ce14
Successfully built 397ce833ce14
Successfully tagged lnbook/lnd:latest
Nosso contêiner agora está pronto para ser executado. Assim como o contêiner c-lightning que
construímos anteriormente, o contêiner do LND também depende de uma instância em execução
do Bitcoin Core. Como antes, precisamos iniciar o contêiner bitcoind em outro terminal e conectar o
LND a ele por meio de uma rede Docker. Já configuramos uma rede Docker chamada lnbook e a
usaremos novamente aqui.
Normalmente, cada operador de nó executa seu próprio nó Lightning e seu próprio nó Bitcoin
em seu próprio servidor. Para nós, um único contêiner bitcoind pode atender a vários nós
Lightning. Em nossa rede simulada, podemos executar vários nós Lightning, todos conectados
a um único nó Bitcoin no modo regtest.
Executando os Contêineres bitcoind e LND
Como antes, iniciamos o contêiner bitcoind em um terminal e o LND em outro. Se você já tem o
contêiner bitcoind em execução, não é necessário reiniciá-lo. Basta deixá-lo em execução e pular
para a próxima etapa. Para iniciar o bitcoind na rede lnbook, utilizamos o comando docker run da
seguinte maneira:
Em seguida, iniciamos o contêiner do LND que acabamos de construir. Como feito anteriormente,
precisamos conectá-lo à rede lnbook e atribuir um nome a ele:
$ docker run -it --network lnbook --name lnd lnbook/lnd

Starting lnd...
Startup complete
Funding lnd wallet
{"result":"dbd1c8e2b224e0a511c11efb985dabd84d72d935957ac30935ec4211d28beacb","error":n
ull,"id":"lnd-run-container"}
[INF] LTND: Version: 0.13.1-beta commit=v0.13.1-beta, build=production,
logging=default, debuglevel=info
[INF] LTND: Active chain: Bitcoin (network=regtest)
[INF] RPCS: Generating TLS certificates...
16
O contêiner LND é inicializado e se conecta ao contêiner bitcoind por meio da rede Docker.
Primeiro, nosso nó LND aguardará o início do bitcoind e, em seguida, aguardará até que o bitcoind
tenha minerado alguns bitcoin em sua carteira. Como parte da inicialização do contêiner, um script
enviará um comando RPC para o nó bitcoind, criando assim uma transação que financia a carteira
do LND com 10 BTC de teste.
Como demonstrado anteriormente, podemos emitir comandos para nosso contêiner em outro
terminal para extrair informações, abrir canais, etc. O comando que nos permite emitir instruções
de linha de comando para o daemon lnd é chamado de lncli. Mais uma vez, neste contêiner,
fornecemos o alias cli que executa o lncli com todos os parâmetros apropriados. Vamos obter as
informações do nó usando o comando docker exec em outra janela do terminal:
$ docker exec lnd cli getinfo

{
"version": "0.13.1-beta commit=v0.13.1-beta",
"commit_hash": "596fd90ef310cd7abbf2251edaae9ba4d5f8a689",
"identity_pubkey":
"02d4545dccbeda29a10f44e891858940f4f3374b75c0f85dcb7775bb922fdeaa14",
[...]
Agora temos mais um nó Lightning em execução na rede lnbook e se comunicando com o bitcoind.
Se você ainda estiver executando o contêiner do c-lightning, agora há dois nós em execução. Eles
ainda não estão conectados entre si, mas em breve os conectaremos.
Se desejar, você pode executar qualquer combinação de nós LND e c-lightning na mesma Lightning
Network. Por exemplo, para executar um segundo nó LND, você deve emitir o comando docker run
com um nome de contêiner diferente, como este:
$ docker run -it --network lnbook --name lnd2 lnbook/lnd
No comando anterior, iniciamos outro contêiner LND, nomeando-o como lnd2. Os nomes são
totalmente escolha sua, desde que sejam únicos. Se você não fornecer um nome, o Docker irá
construir um nome único combinando aleatoriamente duas palavras em inglês, como
"naughty_einstein". Esse foi o nome que o Docker escolheu para nós quando escrevemos este
parágrafo. Que engraçado!
Na próxima seção, veremos como baixar e compilar o LND diretamente a partir do código-fonte.
Esta é uma etapa opcional e avançada que ensinará você a usar as ferramentas de compilação da
linguagem Go e permitirá que você faça modificações no código-fonte do LND. Com esse
conhecimento, você poderá escrever código ou corrigir alguns bugs.
Se você não planeja mergulhar no código-fonte ou na programação de um nó Lightning, pode

pular completamente a próxima seção. O contêiner Docker que acabamos de construir é
17
Instalando o LND a partir do Código-Fonte
Nesta seção, iremos construir o LND do zero. O LND é escrito na linguagem de programação Go. Se
você quiser saber mais sobre o Go, pesquise por golang em vez de go para evitar resultados
irrelevantes. Por ser escrito em Go e não em C ou C++, ele utiliza uma estrutura de "compilação"
diferente da estrutura GNU autotools/make que vimos sendo usada no c-lightning anteriormente.
No entanto, não se preocupe, é bastante fácil instalar e usar as ferramentas do Go, e mostraremos
cada etapa aqui. O Go é uma linguagem fantástica para o desenvolvimento colaborativo de
software, pois produz um código muito consistente, preciso e de fácil leitura, independentemente
do número de autores. O Go é focado e "minimalista" de uma maneira que incentiva a consistência
entre as versões da linguagem. Como uma linguagem compilada, também é bastante eficiente.
Vamos mergulhar nisso.
Vamos seguir as instruções de instalação encontradas em LND project documentation.
Primeiro, vamos instalar o pacote golang e as bibliotecas associadas. Exigimos estritamente a

versão 1.13 ou posterior do Go. Os pacotes oficiais da linguagem Go são distribuídos como binários
de the Go Project. Para maior conveniência, eles também são empacotados como pacotes Debian
disponíveis através do comando apt. Você pode seguir as instruções disponíveis em from the Go
Project ou usar os seguintes comandos apt em um sistema Debian/Ubuntu Linux, conforme descrito
em GitHub’s wiki page on the Go language:
$ sudo apt install golang-go
Verifique se você possui a versão correta instalada e pronta para uso executando:
$ go version
go version go1.13.4 linux/amd64
Temos a versão 1.13.4, então estamos prontos para… ir! Em seguida, precisamos informar a
qualquer programa onde encontrar o código Go. Isso é feito configurando a variável de ambiente
GOPATH. Geralmente, o código Go está localizado em um diretório chamado gocode diretamente no
diretório principal do usuário. Com os dois comandos a seguir, configuramos consistentemente o
GOPATH e garantimos que seu shell o adicione ao seu PATH executável. Observe que o diretório
principal do usuário é referenciado como ~ no shell.
$ export GOPATH=~/gocode
$ export PATH=$PATH:$GOPATH/bin
Para evitar ter que definir essas variáveis de ambiente toda vez que você abrir um shell, você pode
adicionar essas duas linhas ao final do arquivo de configuração do shell bash chamado .bashrc no
seu diretório principal, usando o editor de sua escolha.
18
Copiando o Código-Fonte do LND
Assim como muitos projetos de código aberto atualmente, o código-fonte do LND está no GitHub
(www.github.com). O comando go get pode buscá-lo diretamente usando o protocolo Git:
$ go get -d github.com/lightningnetwork/lnd
Assim que o go get terminar, você terá um subdiretório em GOPATH que contém o código-fonte do
LND.
Compilando o Código-Fonte do LND
O LND usa o sistema de compilação make. Para compilar o projeto, alteramos o diretório para o
código-fonte do LND e, em seguida, utilizamos o make da seguinte forma:
$ cd $GOPATH/src/github.com/lightningnetwork/lnd
$ make && make install
Após alguns minutos, você terá dois novos comandos, lnd e lncli, instalados. Experimente-os e
verifique a versão para garantir que estejam instalados corretamente:
$ lnd --version
lnd version 0.10.99-beta commit=clock/v1.0.0-106-
gc1ef5bb908606343d2636c8cd345169e064bdc91
$ lncli --version
lncli version 0.10.99-beta commit=clock/v1.0.0-106-
gc1ef5bb908606343d2636c8cd345169e064bdc91
É provável que você veja uma versão diferente da mostrada anteriormente, pois o software
continua evoluindo mesmo depois da publicação deste livro. No entanto, não importa qual versão
você veja, o fato de os comandos serem executados e exibirem informações de versão significa que
você obteve sucesso na compilação do software LND.
O Projeto Eclair Lightning Node

Eclair (em francês significa relâmpago) é uma implementação em Scala da Lightning Network feita
pela ACINQ. Eclair também é uma das carteiras móveis mais populares e pioneiras do Lightning,
que usamos para demonstrar um pagamento do Lightning no [getting-started]. Nesta seção,
examinaremos o projeto do servidor Eclair, que executa um nó do Lightning. Eclair é um projeto de
código aberto e pode ser encontrado em GitHub.
Nas próximas seções, construiremos um contêiner Docker para executar o Eclair, assim como
fizemos anteriormente com o c-lightning e o LND. Também iremos construir o Eclair diretamente
a partir do código-fonte.
19
O Contêiner Docker Eclair
Vamos baixar o contêiner Eclair do repositório Docker Hub do livro:
$ docker pull lnbook/eclair

latest: Pulling from lnbook/eclair
35807b77a593: Already exists
e1b85b9c5571: Already exists
[...]
c7d5d5c616c2: Pull complete

Digest: sha256:17a3d52bce11a62381727e919771a2d5a51da9f91ce2689c7ecfb03a6f028315
Status: Downloaded newer image for lnbook/eclair:latest
docker.io/lnbook/eclair:latest
Alternativamente, podemos construir o contêiner localmente. Neste ponto, você já é quase um

especialista nas operações básicas do Docker! Nesta seção, repetiremos muitos dos comandos
previamente vistos para construir o contêiner do Eclair. O contêiner está localizado em
code/docker/eclair. Iniciamos em um terminal mudando o diretório de trabalho para code/docker e
executando o comando docker build:
$ cd code/docker
$ docker build -t lnbook/eclair eclair
Step 1/27 : ARG OS=ubuntu
Step 2/27 : ARG OS_VER=focal
Step 3/27 : FROM ${OS}:${OS_VER} as os-base
---> fb52e22af1b0
[...]

---> Running in fe639120b726
Removing intermediate container fe639120b726
---> e6c8fe92a87c
Successfully built e6c8fe92a87c
Successfully tagged lnbook/eclair:latest
Nossa imagem está pronta para ser executada. O contêiner do Eclair também depende de uma
instância em execução do Bitcoin Core. Como antes, precisamos iniciar o contêiner bitcoind em
outro terminal e conectar o Eclair a ele por meio de uma rede Docker. Já configuramos uma rede
Docker chamada lnbook e a reutilizaremos aqui.
Uma diferença notável entre o Eclair e o LND ou c-lightning é que o Eclair não possui uma carteira
separada de bitcoin, mas depende diretamente da carteira de bitcoin do Bitcoin Core. Lembre-se de
que, ao usar o LND, financiamos sua carteira de bitcoin executando uma transação para transferir
20
bitcoin da carteira do Bitcoin Core para a carteira de bitcoin do LND. Esse passo não é necessário ao
usar o Eclair. Ao executar o Eclair, a carteira de bitcoin do Bitcoin Core é usada diretamente como a
fonte de fundos para abrir canais. Como resultado, ao contrário dos contêineres LND ou c-
lightning, o contêiner Eclair não possui um script para transferir bitcoin para sua carteira durante
a inicialização.
Executando os Contêineres bitcoind e Eclair
Como antes, iniciamos o contêiner bitcoind em um terminal e o contêiner Eclair em outro. Se você
já tiver o contêiner bitcoind em execução, não é necessário reiniciá-lo. Deixe-o em execução e pule
para a próxima etapa. Para iniciar o bitcoind na rede lnbook, usamos o comando docker run da
seguinte forma:
Em seguida, iniciamos o contêiner Eclair que acabamos de construir. Precisamos conectá-lo à rede
lnbook e atribuir um nome a ele, assim como fizemos com os outros contêineres:
$ docker run -it --network lnbook --name eclair lnbook/eclair

Starting eclair...
Eclair node started
INFO o.b.Secp256k1Context - secp256k1 library successfully loaded
INFO fr.acinq.eclair.Plugin - loading 0 plugins
INFO a.e.slf4j.Slf4jLogger - Slf4jLogger started
INFO fr.acinq.eclair.Setup - hello!
INFO fr.acinq.eclair.Setup - version=0.4.2 commit=52444b0
[...]
O contêiner Eclair é iniciado e conectado ao contêiner bitcoind por meio da rede Docker. Primeiro,
nosso nó Eclair aguardará o início do bitcoind e, em seguida, aguardará até que o bitcoind tenha
minerado alguns bitcoin em sua carteira.
Como demonstramos anteriormente, podemos emitir comandos para nosso contêiner em outro
terminal para extrair informações, abrir canais, etc. O comando que nos permite emitir instruções
de linha de comando para o daemon eclair é chamado de eclair-cli. Como antes, neste contêiner,
fornecemos um alias útil para eclair-cli, chamado simplesmente de cli, que oferece os argumentos e
parâmetros necessários. Usando o comando docker exec em outra janela do terminal, obtemos as
informações do nó do Eclair:
$ docker exec eclair cli getinfo

{
"version": "0.4.2-52444b0",
"nodeId": "02fa6d5042eb8098e4d9c9d99feb7ebc9e257401ca7de829b4ce757311e0301de7",
"alias": "eclair",
21
"color": "#49daaa",
"features": {
[...]
},
"chainHash": "06226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f",
"network": "regtest",
"blockHeight": 779,
"publicAddresses": [],
"instanceId": "01eb7a68-5db0-461b-bdd0-29010df40d73"
}
Agora temos mais um nó do Lightning em execução na rede lnbook e se comunicando com o

bitcoind. Você pode executar qualquer número e qualquer combinação de nós do Lightning na
mesma rede do Lightning. Qualquer número de nós Eclair, LND e c-lightning podem coexistir. Por
exemplo, para executar um segundo nó Eclair, você deve emitir o comando docker run com um
nome de contêiner diferente, da seguinte forma:
$ docker run -it --network lnbook --name eclair2 lnbook/eclair
No comando anterior, iniciamos outro contêiner Eclair com o nome eclair2.
Na próxima seção, também veremos como baixar e compilar o Eclair diretamente a partir do
código-fonte. Esta etapa é opcional e avançada, e irá ensinar como usar as ferramentas de
compilação das linguagens Scala e Java, permitindo que você faça modificações no código-fonte do
Eclair. Com esse conhecimento, você poderá escrever código ou corrigir alguns bugs.
Se você não planeja se aprofundar no código-fonte ou programação de um nó do Lightning,

pode pular completamente a próxima seção. O contêiner Docker que acabamos de construir é
Instalando o Eclair a partir do Código-Fonte
Nesta seção, construiremos o Eclair a partir do zero. O Eclair é escrito na linguagem de

programação Scala, que é compilada usando o compilador Java. Para executar o Eclair, primeiro
precisamos instalar o Java e suas ferramentas de compilação. Seguiremos as instruções
encontradas no the BUILD.md document do projeto Eclair.
O compilador Java necessário faz parte do OpenJDK 11. Também precisaremos de um framework
de compilação chamado Maven, versão 3.6.0 ou superior.
Em um sistema Debian/Ubuntu Linux, podemos usar o comando apt para instalar tanto o OpenJDK
11 quanto o Maven, conforme mostrado a seguir:
$ sudo apt install openjdk-11-jdk maven
22
Verify that you have the correct version installed by running:
$ javac -version
javac 11.0.7
$ mvn -v
Apache Maven 3.6.1
Maven home: /usr/share/maven
Java version: 11.0.7, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64
We have OpenJDK 11.0.7 and Maven 3.6.1, so we’re ready.
Copiando o Código-Fonte do Eclair
O código-fonte do Eclair está no GitHub. O comando git clone pode criar uma cópia local para nós.
Vamos mudar para o diretório home e executá-lo lá:
$ cd ~
$ git clone https://github.com/ACINQ/eclair.git
Após a conclusão do git clone, você terá um subdiretório eclair contendo o código-fonte do servidor
Eclair.
Compilando o Código-Fonte do Eclair
O Eclair usa o sistema de compilação Maven. Para compilar o projeto, alteramos o diretório de
trabalho para o código-fonte do Eclair e, em seguida, usamos o comando mvn package da seguinte
forma:
$ cd eclair
$ mvn package
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] --------------------< fr.acinq.eclair:eclair_2.13 >---------------------
[INFO] Building eclair_2.13 0.4.3-SNAPSHOT [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[...]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:06 min
[INFO] Finished at: 2020-12-12T09:43:21-04:00
[INFO] ------------------------------------------------------------------------
23
Após alguns minutos, a compilação do pacote Eclair deve ser concluída. No entanto, a ação
"package" também executará testes, e alguns desses testes se conectam à internet e podem falhar.
Se você quiser pular os testes, adicione -DskipTests ao comando.
Agora, descompacte e execute o pacote de compilação seguindo as instruções

em:https://github.com/ACINQ/eclair#installing-eclair[instructions for installing Eclair] do GitHub.
Parabéns! Você construiu o Eclair a partir do código-fonte e está pronto para programar, testar,
corrigir bugs e contribuir para este projeto!
Construindo uma Rede Completa de Diversos Nós

Lightning
Nosso exemplo final, apresentado nesta seção, reunirá todos os vários contêineres que construímos
para formar uma Lightning Network composta por diversas implementações de nós (LND, c-
lightning, Eclair). Vamos compor a rede conectando os nós entre si e abrindo canais de um nó para
outro. Como último passo, vamos rotear um pagamento por esses canais!
Neste exemplo, vamos construir uma demonstração da Lightning Network composta por quatro
nós Lightning chamados Alice, Bob, Chan e Dina. Vamos conectar Alice a Bob, Bob a Chan e Chan a
Dina. Isso é mostrado na Uma pequena demonstração de rede de quatro nós.
Figure 1. Uma pequena demonstração de rede de quatro nós
Por fim, faremos com que Dina crie uma fatura e Alice pague essa fatura. Como Alice e Dina não
estão diretamente conectadas, o pagamento será roteado como um HTLC por todos os canais de
pagamento.
Usando o docker-compose para Orquestrar Contêineres Docker
Para fazer esse exemplo funcionar, usaremos uma ferramenta de orquestração de contêineres
chamada docker-compose. Esse comando nos permite especificar uma aplicação composta por
vários contêineres e executar a aplicação lançando todos os contêineres cooperantes juntos.
Primeiro, vamos instalar o docker-compose. As instructions dependem do seu sistema operacional.
24
Após concluir a instalação, você pode verificar sua instalação executando o comando docker-
compose da seguinte forma:
$ docker-compose version
docker-compose version 1.21.0, build unknown
[...]
Os comandos mais comuns do docker-compose que usaremos são up e down, por exemplo, docker-
compose up.
Configuração do docker-compose
O arquivo de configuração do docker-compose é encontrado no diretório code/docker e é chamado

docker-compose.yml. Ele contém uma especificação para uma rede e cada um dos quatro
contêineres. A parte superior se parece com isso:
version: "3.3"
networks:
lnnet:
services:
bitcoind:
container_name: bitcoind
build:
context: bitcoind
image: lnbook/bitcoind:latest
networks:
- lnnet
expose:
- "18443"
- "12005"
- "12006"
Alice:
container_name: Alice
O trecho anterior define uma rede chamada lnnet e um contêiner chamado bitcoind que se
conectará à rede lnnet. O contêiner é o mesmo que construímos no início deste capítulo. Expondo
três portas do contêiner, permitimos enviar comandos para ele e monitorar blocos e transações. Em
seguida, a configuração especifica um contêiner LND chamado "Alice". Mais adiante, você também
verá especificações para os contêineres chamados "Bob" (c-lightning), "Chan" (Eclair) e "Dina" (LND
novamente).
Como todas essas implementações diversas seguem a especificação BOLT e foram amplamente
testadas para interoperabilidade, elas não têm dificuldade em trabalhar juntas para construir uma
rede Lightning.
25
Iniciando a Rede Lightning de Exemplo
Antes de começarmos, devemos garantir que não estejamos executando nenhum dos containers. Se
um novo container tiver o mesmo nome de um que já está em execução, ele não poderá ser
iniciado. Use os comandos docker ps, docker stop e docker rm conforme necessário para parar e
remover quaisquer containers que estejam em execução!
Como usamos os mesmos nomes para esses containers Docker orquestrados, pode ser
necessário "limpar" para evitar conflitos de nomes.
Para iniciar o exemplo, navegamos até o diretório que contém o arquivo de configuração docker-
compose.yml e emitimos o comando docker-compose up:
$ cd code/docker
$ docker-compose up
Creating Chan ... done
Creating Dina ... done
Creating bitcoind ... done
Creating Bob ... done
Creating Alice ... done
Attaching to Chan, Dina, Alice, bitcoind, Bob
Alice | Waiting for bitcoind to start...
Bob | Waiting for bitcoind to start...
Dina | Waiting for bitcoind to start...
Chan | Waiting for bitcoind to start...
bitcoind | Starting bitcoind...
bitcoind | Waiting for bitcoind to start
bitcoind | bitcoind started
bitcoind | ================================================
[...]
Chan | Starting eclair...

Dina | Starting lnd...
Chan | Eclair node started
Alice | ...Waiting for bitcoind to mine blocks...
Bob | ...Waiting for bitcoind to mine blocks...
Alice | Starting lnd...
Bob | Starting c-lightning...
[...]
Após o início, você verá uma sequência de arquivos de log à medida que cada nó é iniciado e relata
seu progresso. Pode parecer confuso na tela, mas cada linha de saída é prefixada pelo nome do
contêiner, conforme visto anteriormente. Se você quiser acompanhar os logs de apenas um
contêiner, pode fazer isso em outra janela do terminal usando o comando docker-compose logs com
a flag f (follow) e o nome específico do contêiner:
26
$ docker-compose logs -f Alice
Abrindo Canais e Roteando um Pagamento
Nossa rede Lightning deve estar em funcionamento agora. Como vimos nas seções anteriores deste
capítulo, podemos enviar comandos para um contêiner Docker em execução usando o comando
docker exec. Independentemente de termos iniciado o contêiner com docker run ou iniciado vários
contêineres com docker-compose up, ainda é possível acessar os contêineres individualmente
usando os comandos do Docker.
A demonstração de pagamento está contida em um script de shell Bash chamado run-payment-

demo.sh. Para executar essa demonstração, você deve ter o shell Bash instalado em seu
computador. A maioria dos sistemas Linux e semelhantes ao Unix (por exemplo, macOS) tem o bash
pré-instalado. Os usuários do Windows podem instalar o Subsistema Windows para Linux e usar
uma distribuição Linux como o Ubuntu para obter um comando bash nativo em seu computador.
Você pode executar o script para ver seu efeito e, em seguida, podemos analisar como ele funciona
internamente. Use o comando bash para executá-lo:
$ cd code/docker
$ bash run-payment-demo.sh
Starting Payment Demo
======================================================
Waiting for nodes to startup

- Waiting for bitcoind startup...
- Waiting for bitcoind mining...
- Waiting for Alice startup...
- Waiting for Bob startup...
- Waiting for Chan startup...
- Waiting for Dina startup...
All nodes have started
======================================================
Getting node IDs

- Alice: 0335e200756e156f1e13c3b901e5ed5a28b01a3131cd0656a27ac5cc20d4e71129
- Bob: 033e9cb673b641d2541aaaa821c3f9214e8a11ada57451ed5a0eab2a4afbce7daa
- Chan: 02f2f12182f56c9f86b9aa7d08df89b79782210f0928cb361de5138364695c7426
- Dina: 02d9354cec0458e0d6dee5cfa56b83040baddb4ff88ab64960e0244cc618b99bc3
======================================================
[...]
Setting up connections and channels

- Alice to Bob
- Open connection from Alice node to Bob's node
- Create payment channel Alice->Bob
27
[...]
Get 10k sats invoice from Dina

- Dina invoice:
lnbcrt100u1psnuzzrpp5rz5dg4wy27973yr7ehwns5ldeusceqdaq0hguu8c29n4nsqkznjsdqqcqzpgxqyz5
vqsp5vdpehw33fljnmmexa6ljk55544f3syd8nfttqlm3ljewu4r0q20q9qyyssqxh5nhkpjgfm47yxn4p9ecv
ndz7zddlsgpufnpyjl0kmnq227tdujlm0acdv39hcuqp2vhs40aav70c9yp0tee6tgzk8ut79mr877q0cpkjcf
vr
======================================================
Attempting payment from Alice to Dina

Successful payment!
Como você pode ver a partir da saída, o script primeiro obtém os IDs dos nós (chaves públicas) para
cada um dos quatro nós. Em seguida, ele conecta os nós e configura um canal de 1.000.000 satoshis
de cada nó para o próximo na rede. Por fim, ele emite uma fatura de 10.000 satoshis a partir do nó
de Dina e paga a fatura pelo nó de Alice.
Se o script falhar, você pode tentar executá-lo novamente desde o início. Ou você pode emitir
manualmente os comandos encontrados no script um por um e verificar os resultados.
Há muito a ser revisado nesse script, mas à medida que você compreende a tecnologia subjacente,
mais e mais dessas informações se tornarão claras. Você está convidado a revisitar este exemplo
mais tarde.
Claro, você pode fazer muito mais com essa rede de teste do que um pagamento de três canais e
quatro nós. Aqui estão algumas ideias para seus experimentos:
• Crie uma rede mais complexa lançando muitos mais nós de tipos diferentes. Edite o arquivo
docker-compose.yml e copie as seções, renomeando os contêineress conforme necessário.
• Conecte os nós em topologias mais complexas: rotas circulares, hub-and-spoke ou malha

completa (full mesh).
• Execute muitos pagamentos para esgotar a capacidade dos canais. Em seguida, execute
pagamentos na direção oposta para reequilibrar os canais. Observe como o algoritmo de
roteamento se adapta.
• Altere as taxas dos canais para ver como o algoritmo de roteamento negocia várias rotas e quais
otimizações são aplicadas. Uma rota barata e longa é melhor do que uma rota cara e curta?
• Realize um pagamento circular de um nó de volta para si mesmo para reequilibrar seus

próprios canais. Veja como isso afeta todos os outros canais e nós.
• Gere centenas ou milhares de faturas pequenas em um loop e, em seguida, pague-as o mais

rápido possível em outro loop. Meça quantas transações por segundo você pode obter desta
rede de teste.
28
Lightning Polar permite visualizar a rede com a qual você tem experimentado usando o
Docker.
Conclusão
Neste capítulo, examinamos vários projetos que implementam as especificações BOLT. Construímos
contêineres para executar uma rede de Lightning Network de exemplo e aprendemos como
construir cada projeto a partir do código-fonte. Agora você está pronto para explorar mais e
aprofundar seus conhecimentos.
29
Operando um Nó de Rede Lightning
Após ter lido até aqui, você provavelmente configurou uma carteira de Lightning. Neste capítulo,
vamos dar um passo adiante e configurar um nó completo de Lightning. Além de configurá-lo,
vamos aprender como operá-lo e mantê-lo ao longo do tempo.
Existem muitas razões pelas quais você pode querer configurar seu próprio nó de Lightning. Alguns
motivos incluem:
• Ser um participante ativo e completo na Lightning Network, não apenas um usuário final
• Para executar uma loja de comércio eletrônico ou receber renda por meio de pagamentos na
Lightning
• Para obter renda através de taxas de roteamento na Lightning ou alugando liquidez de canais
• Para desenvolver novos serviços, aplicativos ou plug-ins para a Lightning Network
• Para aumentar sua privacidade financeira ao usar a Lightning
• Para usar alguns aplicativos desenvolvidos sobre a rede Lightning, como aplicativos de
mensagens instantâneas que usam a tecnologia Lightning
• Para liberdade financeira, independência e soberania
Existem custos associados à execução de um nó LN. Você precisa de um computador, uma conexão
à internet permanente, muito espaço em disco e muito tempo! Os custos operacionais incluirão
despesas com eletricidade.
Mas as habilidades que você aprenderá com essa experiência são valiosas e também podem ser
aplicadas a uma variedade de outras tarefas.
Vamos começar!
É importante que você defina suas próprias expectativas com base em fatos precisos. Se você
planeja operar um nó Lightning exclusivamente para obter renda através das taxas de
roteamento, por favor, faça sua pesquisa diligentemente primeiro. Operar um negócio
lucrativo através da operação de um nó Lightning definitivamente não é fácil. Calcule todos os
seus custos iniciais e contínuos em uma planilha. Estude cuidadosamente as estatísticas da LN.
Qual é o volume atual de pagamentos? Qual é o volume por nó? Quais são as taxas médias de
roteamento atuais? Consulte fóruns e peça conselhos ou feedback de outros membros da
comunidade que já adquiriram experiência do mundo real. Forme sua própria opinião
educada apenas depois de ter feito este exercício de devida diligência. A maioria das pessoas
encontrará sua motivação para executar um nó não em ganho financeiro, mas em outro
motivo.
Escolhendo Sua Plataforma

Existem várias maneiras de executar um nó do Lightning, desde um pequeno mini PC hospedado
em sua casa ou um servidor dedicado, até um servidor hospedado na nuvem. O método que você
1
escolherá dependerá dos recursos que você possui e de quanto dinheiro está disposto a investir.
Por Que a Confiabilidade é Importante para Executar um Nó Lightning?
No Bitcoin, o hardware não é especialmente importante, a menos que você esteja executando
especificamente um nó de mineração. O software de nó Bitcoin Core pode ser executado em
qualquer máquina que atenda aos requisitos mínimos e não precisa estar online para receber
pagamentos—apenas para enviá-los. Se um nó Bitcoin ficar fora do ar por um período prolongado,
o usuário pode simplesmente reiniciar o nó e, assim que ele se conectar ao restante da rede, ele irá
sincronizar novamente a blockchain.
No Lightning, no entanto, o usuário precisa estar online tanto para enviar quanto para receber
pagamentos. Se o nó Lightning estiver offline, ele não pode receber nenhum pagamento de
ninguém e, portanto, suas faturas em aberto não podem ser pagas. Além disso, os canais abertos de
um nó offline não podem ser usados para rotear pagamentos. Seus parceiros de canal perceberão
que você está offline e não poderão contatá-lo para rotear um pagamento. Se você estiver offline
com frequência, eles podem considerar que os bitcoin bloqueados em seus canais estão sendo
subutilizados e podem fechar esses canais. Já discutimos o caso de um ataque de protocolo em que
seu parceiro de canal tenta enganá-lo ao enviar uma transação de compromisso anterior. Se você
estiver offline e seus canais não estiverem sendo monitorados, a tentativa de roubo pode ter
sucesso e você não terá recursos uma vez que o timelock expire. Portanto, a confiabilidade do nó é
extremamente importante para um nó Lightning.
Existem também as questões de falha de hardware e perda de dados. No Bitcoin, uma falha de
hardware pode ser um problema trivial se o usuário tiver um backup de sua frase mnemônica ou
chaves privadas. A carteira do Bitcoin e os bitcoin dentro da carteira podem ser facilmente
restaurados a partir das chaves privadas em um novo computador. A maioria das informações
pode ser baixada novamente a partir da blockchain..
Em contraste, no Lightning, as informações sobre os canais do usuário, incluindo as transações de

compromisso e os segredos de revogação, não são de conhecimento público e são armazenadas
apenas no hardware do usuário individual. Portanto, falhas de software e hardware na Lightning
Network podem facilmente resultar em perda de fundos.
Tipos de Hardware de Nós Lightning
Existem três tipos principais de nós de hardware para a Lightning Network:
Computadores de propósito geral: Um nó LN pode ser executado em um computador doméstico ou

laptop rodando Windows, macOS ou Linux. Geralmente é executado junto com um nó Bitcoin.
Hardware dedicado:: Um nó Lightning também pode ser executado em hardware dedicado, como
um Raspberry Pi, Rock64 ou mini PC. Essa configuração normalmente inclui uma pilha de software,
incluindo um nó Bitcoin e outras aplicações. Essa configuração é popular porque o hardware é
dedicado exclusivamente para executar e manter o nó Lightning, e geralmente é configurado com
um "assistente" de instalação. Hardware pré-configurado:: Um nó LN também pode ser executado
em hardware projetado especificamente para esse fim, selecionado e configurado para isso. Isso
inclui soluções de nó Lightning "prontas para uso" que podem ser adquiridas como um kit ou um
sistema turnkey.
2
Executando na "Nuvem"
Servidores virtuais privados (VPS) e serviços de computação em nuvem, como Microsoft Azure,
Google Cloud, Amazon Web Services (AWS) ou DigitalOcean, são bastante acessíveis e podem ser
configurados rapidamente. Um nó Lightning pode ser hospedado por cerca de US$ 20 a US$ 40 por
mês em um serviço desse tipo.
No entanto, como diz o ditado, "‘Nuvem’ é apenas o computador de outra pessoa."

Usar esses serviços significa executar seu nó em computadores de outras pessoas. Isso traz
vantagens e desvantagens correspondentes. As principais vantagens são conveniência, eficiência,
tempo de atividade e possivelmente até mesmo custo. O operador de nuvem gerencia e executa o
nó em alto grau, fornecendo automaticamente conveniência e eficiência. Eles oferecem excelente
tempo de atividade e disponibilidade, muitas vezes muito melhor do que o que um indivíduo pode
alcançar em casa. Se considerarmos que apenas o custo de eletricidade de executar um servidor em
muitos países ocidentais é de cerca de $ 10 por mês, somando a isso o custo de largura de banda de
rede e o próprio hardware, a oferta de VPS se torna financeiramente competitiva. Por último, com
um VPS, você não precisa de espaço para um PC em casa e não tem problemas com ruído ou calor
do PC. Por outro lado, existem várias desvantagens importantes. Um nó Lightning em execução na
"nuvem" sempre será menos seguro e menos privado do que um em execução em seu próprio
computador. Além disso, esses serviços de computação em nuvem são muito centralizados. A
grande maioria dos nós Bitcoin e Lightning em execução nesses serviços está localizada em um
punhado de data centers em Virginia, Sunnyvale, Seattle, Londres e Frankfurt. Quando as redes ou
data centers desses provedores têm problemas de serviço, isso afeta milhares de nós em redes
supostamente "descentralizadas".
Se você tiver a possibilidade e a capacidade de executar um nó em seu próprio computador em casa

ou no escritório, essa pode ser uma opção preferível em relação à execução na nuvem. No entanto,
se executar seu próprio servidor não for uma opção, considere executar um em um VPS.
Executando um Nó em Casa
Se você tiver uma conexão de internet com capacidade razoável em casa ou no escritório,
certamente pode executar um nó Lightning lá. Qualquer conexão "banda larga" é suficiente para o
propósito de executar um nó leve, e uma conexão rápida permitirá que você execute um nó
completo do Bitcoin também.
Embora você possa executar um nó Lightning (e até mesmo um nó Bitcoin) no seu laptop, isso se
tornará irritante rapidamente. Esses programas consomem os recursos do seu computador e
precisam ser executados 24 horas por dia, 7 dias por semana. Suas aplicações de usuário, como seu
navegador ou sua planilha, competirão com os serviços em segundo plano do Lightning pelos
recursos do seu computador. Em outras palavras, seu navegador e outras cargas de trabalho na
área de trabalho serão desacelerados. E quando seu aplicativo de processamento de texto trava o
seu laptop, o seu nó Lightning também ficará indisponível, impossibilitando o recebimento de
transações e potencialmente deixando-o vulnerável a ataques. Além disso, você nunca deve desligar
o seu laptop. Tudo isso combinado resulta em uma configuração que não é ideal. O mesmo se aplica
ao seu desktop pessoal de uso diário.
Em vez disso, a maioria dos usuários optará por executar um nó em um computador dedicado.
Felizmente, você não precisa de um computador do tipo "servidor" para fazer isso. Você pode
3
executar um nó Lightning em um computador de placa única, como um Raspberry Pi, ou em um
mini PC (geralmente comercializado como PCs de home theater). Esses são computadores simples
que são comumente usados como hub de automação residencial ou servidor de mídia. Eles são
relativamente baratos quando comparados a um PC ou laptop. A vantagem de um dispositivo
dedicado como plataforma para nós Lightning e Bitcoin é que ele pode funcionar continuamente,
silenciosamente e sem interrupções em sua rede doméstica, escondido atrás do seu roteador ou da
TV. Ninguém nem vai saber que essa pequena caixa faz parte de um sistema bancário global!
Operar um nó em um sistema operacional de 32 bits e/ou CPU de 32 bits não é recomendado,

pois o software do nó pode enfrentar problemas de recursos, causando um travamento e
possivelmente a perda de fundos.
Qual Hardware é Necessário para Executar um Nó do Lightning?
ara executar um nó Lightning, você precisará, no mínimo, dos seguintes requisitos:
CPU
É necessária capacidade de processamento suficiente para executar um nó Bitcoin, que irá
baixar e validar continuamente novos blocos. O usuário também precisa considerar a
inicialização do download de blocos (Initial Block Download, IBD) ao configurar um novo nó
Bitcoin, o que pode levar de algumas horas a vários dias. Recomenda-se uma CPU de 2 núcleos
ou 4 núcleos.
RAM)
Um sistema com 2 GB de RAM irá apenas executar os nós Bitcoin e Lightning de forma básica.
Ele terá um desempenho muito melhor com pelo menos 4 GB de RAM. O IBD será especialmente
desafiador com menos de 4 GB de RAM. Mais de 8 GB de RAM é desnecessário, pois a CPU é o
maior gargalo para esses tipos de serviços, devido a operações criptográficas, como validação de
assinaturas.
Unidade de armazenamento
Isso pode ser um disco rígido (HDD) ou um disco de estado sólido (SSD). Um SSD será
significativamente mais rápido (mas mais caro) para executar um nó. A maior parte do
armazenamento é usada para a blockchain do Bitcoin, que tem centenas de gigabytes de
tamanho. Um compromisso justo (custo por complexidade) é comprar um pequeno SSD para
inicializar o sistema operacional e um HDD maior para armazenar objetos de dados grandes
(principalmente bancos de dados).
Raspberry Pis são uma escolha comum para executar software de nó, devido ao custo e
disponibilidade das peças. O sistema operacional que é executado no dispositivo geralmente é
inicializado a partir de um cartão de memória Secure Digital (SD). Para a maioria dos casos de
uso, isso não é um problema, mas o Bitcoin Core é conhecido por exigir muita entrada/saída
(I/O). Você deve garantir que coloque a blockchain do Bitcoin e o diretório de dados do
Lightning em uma unidade diferente, pois a intensa atividade de entrada/saída (I/O) a longo
prazo pode causar falha no cartão SD.
4
Conexão com a internet
Uma conexão de internet confiável é necessária para baixar novos blocos do Bitcoin, bem como
para se comunicar com outros participantes da Lightning. Durante a operação, o uso estimado
de dados varia de 10 a 100 GB por mês, dependendo da configuração. No início, um nó completo
de Bitcoin faz o download da blockchain completa.
Fonte de alimentação: É necessário ter uma fonte de alimentação confiável, pois os nós do
Lightning precisam estar online o tempo todo. Uma falha de energia causará a interrupção de
pagamentos em andamento. Para nós de roteamento de alto desempenho, é útil ter um backup ou
um sistema de alimentação ininterrupta (UPS) em caso de quedas de energia. Idealmente, você
deve conectar o roteador de internet a esse UPS também.
Backup
Backup é crucial porque uma falha pode resultar na perda de dados e, portanto, na perda de
fundos. Você vai querer considerar algum tipo de solução de backup de dados. Isso pode ser um
backup automatizado baseado em nuvem para um servidor ou serviço web que você controla.
Alternativamente, pode ser um backup local automatizado em hardware, como um segundo
disco rígido. Para obter melhores resultados, o backup local e remoto podem ser combinados.
Alterando a Configuração do Servidor na Nuvem
Ao alugar um servidor na nuvem, muitas vezes é mais econômico alterar a configuração entre duas
fases de operação. Uma CPU mais rápida e armazenamento mais rápido serão necessários durante
a IBD (por exemplo, o primeiro dia). Após a sincronização da blockchain, os requisitos de
desempenho da CPU e armazenamento são muito menores, portanto, o desempenho pode ser
reduzido para um nível mais econômico.
Por exemplo, na nuvem da Amazon, usaríamos um servidor com 8–16 GB RAM, CPU de 8
núcleos (por exemplo, t3-large ou m3.large) e um SSD mais rápido de 400 GB (com 1000+ operações
de entrada/saída [IOPS] provisionadas) para o IBD, reduzindo seu tempo para apenas 6-8 horas.
Uma vez concluída essa etapa, poderíamos trocar a instância do servidor por uma com 2 GB de
RAM, CPU de 2 núcleos (por exemplo, t3.small) e armazenamento em um HDD geral de 1 TB. Isso
custará aproximadamente o mesmo que se você o executasse no servidor mais lento o tempo todo,
mas permitirá que você comece a operar em menos de um dia, em vez de ter que esperar quase
uma semana pelo IBD.
Armazenamento Permanente de Dados (drive)
Se você usa um mini PC ou aluga um servidor, o armazenamento pode ser a parte mais cara,
custando tanto quanto o próprio computador e a conectividade (dados) juntos.
Vamos dar uma olhada nas diferentes opções disponíveis. Primeiro, existem dois tipos principais de
unidades de armazenamento, os HDDs e os SSDs. Os HDDs são mais baratos e os SSDs são mais
rápidos, mas ambos são eficientes para o trabalho.
Os SSDs mais rápidos disponíveis hoje em dia utilizam a interface Non-Volatile Memory Express
(NVMe). Os SSDs NVMe são mais rápidos em máquinas de alto desempenho, mas também são mais
caros. Os SSDs baseados em SATA tradicionais são mais baratos, mas não tão rápidos. Os SSDs SATA
têm um desempenho suficientemente bom para a configuração do seu nó. Computadores menores
5
podem não conseguir aproveitar os SSDs NVMe. Por exemplo, o Raspberry Pi 4 não pode se
beneficiar deles devido à largura de banda limitada de sua porta USB.
Para escolher o tamanho, vamos olhar para a blockchain do Bitcoin. Em agosto de 2021, seu
tamanho é de 360 GB, incluindo o índice de transações, e cresce aproximadamente 60 GB por ano.
Se você deseja ter uma margem disponível para o crescimento futuro ou para instalar outros dados
em seu nó, adquira pelo menos um disco de 512 GB, ou ainda melhor, um disco de 1 TB.
Usando um Instalador ou Assistente

Instalar um nó Lightning ou um nó Bitcoin pode ser assustador se você não estiver familiarizado
com um ambiente de linha de comando. Felizmente, existem vários projetos que fornecem
"assistentes", ou seja, software que instala e configura os vários componentes para você. Ainda será
necessário aprender alguns comandos de linha de comando para interagir com o seu nó, mas a
maior parte do trabalho inicial é feita para você.
RaspiBlitz
Um dos "assistentes" mais populares e completos é o RaspiBlitz. (Um nó RaspiBlitz), um projeto

desenvolvido por Christian Rotzoll. É destinado a ser instalado em um Raspberry Pi 4. O RaspiBlitz
vem com um kit de hardware recomendado que você pode montar em questão de horas ou no
máximo um fim de semana. Se você participar de um "hackathon" da Lightning em sua cidade, é
provável que veja muitas pessoas trabalhando em sua configuração do RaspiBlitz, trocando dicas e
se ajudando mutuamente. Você pode encontrar o projeto RaspiBlitz em GitHub.
Além de um nó Bitcoin e Lightning, o RaspiBlitz pode instalar uma série de serviços adicionais,
como:
• Tor (executado como serviço oculto)
• ElectRS (servidor Electrum em Rust)
• BTCPay Server (processador de pagamentos em criptomoedas)
• BTC RPC Explorer (explorador de blockchain Bitcoin)
• Ride The Lightning (interface gráfica para gerenciamento de nó Lightning)
• LNbits (sistema de carteira e contas Lightning)
• Specter Desktop (multisig Trezor, Ledger, carteira Coldcard, and Specter-DIY)
• lndmanage (interface de linha de comando para gerenciamento avançado de canais)
• Loop (serviço de trocas submarinas)
• JoinMarket (serviço CoinJoin)
6
Figure 1. Um nó RaspiBlitz
Mynode
myNode é outro projeto de "assistente" de código aberto popular que inclui muitos softwares
relacionados ao Bitcoin. É fácil de instalar: você "grava" o instalador em um cartão SD e inicializa
seu mini PC a partir do cartão SD. Você não precisa de um monitor para usar o myNode, pois as
ferramentas administrativas são acessíveis remotamente a partir de um navegador. Se o seu mini
PC não tiver monitor, mouse ou teclado, você pode gerenciá-lo a partir de outro computador ou até
mesmo do seu smartphone. Uma vez instalado, acesse http://mynode.local e crie uma carteira e um
nó Lightning em apenas dois cliques.
Além de um nó Bitcoin e Lightning, o myNode pode opcionalmente instalar uma variedade de

serviços adicionais, como:
• OpenVPN (suporte a rede privada virtual [VPN] para gerenciamento remoto ou carteira)
• lndmanage (interface de linha de comando para gerenciamento avançado de canais)
• BTC RPC Explorer (um explorador de blockchain do Bitcoin)
7
Umbrel
Famoso por sua UX/UI (mostrado em A interface web do Umbrel), Umbrel oferece uma maneira fácil
e acessível de configurar seu nó de Bitcoin e Lightning em pouco tempo, especialmente para
iniciantes. Uma característica muito distintiva é que o Umbrel utiliza o Neutrino/SPV durante o IBD
para que você possa começar a usar seu nó instantaneamente. Uma vez que o Bitcoin Core esteja
totalmente sincronizado em segundo plano, ele muda automaticamente e desativa o modo SPV. O
Umbrel OS suporta o Raspberry Pi 4 e também pode ser instalado em qualquer sistema operacional
baseado em Linux ou em uma máquina virtual no macOS ou Windows. Você também pode
conectar qualquer carteira que suporte Bitcoin Core P2P, Bitcoin Core RPC, o protocolo Electrum ou
lndconnect.
Não há necessidade de esperar por um dia chuvoso—você pode ir direto para <a
href="https://getumbrel.com">Umbrel</a> para aprender mais.
Figure 2. A interface web do Umbrel
Além de um nó Bitcoin e Lightning, o Umbrel introduziu a Umbrel App Store, onde você pode
instalar facilmente serviços adicionais, como:
• Terminal Lightning (interface para gerenciar a liquidez dos canais, Loop In, e Loop Out)
• Specter Desktop (coordenador observação-apenas para multisig e carteiras Bitcoin de chave

única)
• BTCPay Server (processador de pagamentos em criptomoedas)
• BTC RPC Explorer (explorador de blockchain Bitcoin)
• ThunderHub (monitorar e gerenciar seu nó)
• Sphinx Relay (gerenciamento de conectividade e armazenamento para bate-papo com Sphinx)
8
• mempool.space (visualizador da mempool e explorador de blocos)
• LNbits (sistema de carteira e contas Lightning)
Umbrel ainda está em fase beta e não é considerado seguro no momento.
BTCPay Server
Embora não tenha sido inicialmente projetado como um "assistente" de instalação, a plataforma de
comércio eletrônico e pagamento BTCPay Server possui um sistema de instalação incrivelmente
fácil que utiliza contêineres Docker e docker-compose para instalar um nó Bitcoin, nó Lightning e
gateway de pagamento, entre muitos outros serviços. Ele pode ser instalado em várias plataformas
de hardware, desde um simples Raspberry Pi 4 (recomendado 4 GB) até um mini PC, laptop antigo,
desktop ou servidor.
BTCPay Server é uma plataforma de comércio eletrônico totalmente equipada, auto-hospedada e

com auto custódia que pode ser integrada a muitas plataformas de comércio eletrônico, como o
WordPress WooCommerce e outros. A instalação do nó completo é apenas uma etapa da instalação
da plataforma de comércio eletrônico. Embora originalmente desenvolvido como uma substituição
de recurso por recurso do serviço de pagamento comercial BitPay e sua API, ele evoluiu para se
tornar uma plataforma completa para serviços BTC e Lightning relacionados ao comércio
eletrônico. Para muitos vendedores ou lojas, é uma solução abrangente e pronta para uso no
comércio eletrônico.
Além de um nó Bitcoin e Lightning, o BTCPay Server também pode instalar uma variedade de
serviços, incluindo:
• c-lightning ou nó LND Lightning
• Suporte Litecoin
• Suporte Monero
• Spark server (carteira web c-lightning)
• Charge server (API de comércio eletrônico c-lightning)
• Ride The Lightning (interface gráfica web de gerenciamento de nó Lightning)
• Muitos forks BTC
• BTCTransmuter (serviço de automação evento-ação com suporte a troca de moedas)
O número de serviços e recursos adicionais está crescendo rapidamente, então a lista anterior é
apenas uma pequena amostra do que está disponível na plataforma BTCPay Server.
Nó Bitcoin ou Lightning Leve
Uma escolha crucial para a sua configuração será a escolha do nó Bitcoin e sua configuração. O
Bitcoin Core, a implementação de referência, é a escolha mais comum, mas não a única disponível.
Uma alternativa é o btcd, que é uma implementação em linguagem Go de um nó Bitcoin. O btcd
suporta recursos que são úteis para executar um nó Lightning LND e não estão disponíveis no
Bitcoin Core.
9
Uma segunda consideração é se você executará um nó Bitcoin arquivado, com uma cópia completa
da blockchain (cerca de 350 GB em meados de -2021) ou uma blockchain podada, que mantém
apenas os blocos mais recentes. Uma blockchain podada pode economizar espaço em disco, mas
você ainda precisará baixar a blockchain completa pelo menos uma vez (durante o IBD). Portanto,
não economizará tráfego de rede. O uso de um nó podado para executar um nó Lightning ainda é
uma capacidade experimental e pode não suportar todas as funcionalidades. No entanto, muitas
pessoas estão executando um nó dessa maneira com sucesso.
Finalmente, você também tem a opção de não executar um nó Bitcoin. Em vez disso, você pode
operar o nó LND Lightning no modo "leve", usando o Protocolo Neutrino para obter informações da
blockchain de nós públicos Bitcoin operados por outros. Ao executar dessa maneira, você está
utilizando recursos da rede Bitcoin sem oferecer nada em troca. Em vez disso, você está oferecendo
seus recursos e contribuindo para a comunidade da LN. Para nós Lightning menores, isso
geralmente reduz o tráfego de rede em comparação com a execução de um nó Bitcoin completo.
Tenha em mente que operar um nó Bitcoin permite que você suporte outros serviços, além e em
conjunto com um nó Lightning. Esses outros serviços podem exigir um nó Bitcoin arquivado (não
podado) e muitas vezes não podem ser executados sem um nó Bitcoin. Considere antecipadamente
quais outros serviços você pode querer executar agora ou no futuro para tomar uma decisão
informada sobre o tipo de nó Bitcoin que você seleciona.
A decisão final para essa escolha é a seguinte: se você pode arcar com um disco com capacidade
superior a 500 GB, execute um nó Bitcoin arquivado completo. Você estará contribuindo com
recursos para o sistema Bitcoin e ajudando outras pessoas que não têm condições de fazer o
mesmo. Se você não pode arcar com um disco tão grande, execute um nó podado. Se você não pode
arcar com o disco ou com a largura de banda nem mesmo para um nó podado, execute um nó leve
do LND com o Neutrino.
Escolha do Sistema Operacional
O próximo passo é selecionar um sistema operacional para o seu nó. A grande maioria dos
servidores de internet roda em alguma variante do Linux. O Linux é a plataforma de escolha para a
internet porque é um poderoso sistema operacional de código aberto. No entanto, o Linux possui
uma curva de aprendizado íngreme e requer familiaridade com um ambiente de linha de comando.
Muitas vezes, pode ser intimidante para novos usuários.
Em última análise, a maioria dos serviços pode ser executada em qualquer sistema operacional
moderno baseado em POSIX, o que inclui macOS, Windows e, é claro, Linux. Sua escolha deve ser
baseada principalmente em sua familiaridade e conforto com um sistema operacional e em seus
objetivos de aprendizado. Se você deseja expandir seus conhecimentos e aprender a operar um
sistema Linux, esta é uma ótima oportunidade para fazê-lo com um projeto específico e um objetivo
claro. Se você apenas deseja configurar um nó e colocá-lo em funcionamento, opte pelo que você já
conhece.
Atualmente, muitos serviços também são entregues na forma de contêineres, geralmente baseados
no sistema Docker. Esses contêineres podem ser implantados em uma variedade de sistemas
operacionais, abstraindo o sistema operacional subjacente. No entanto, você pode precisar
aprender alguns comandos de linha de comando do Linux, pois a maioria dos contêineres roda
alguma variante do Linux internamente.
10
Escolha sua Implementação do Nó Lightning
Assim como a escolha do sistema operacional, a escolha da implementação do nó Lightning deve
depender principalmente da sua familiaridade com a linguagem de programação e as ferramentas
de desenvolvimento utilizadas pelos projetos. Embora haja algumas pequenas diferenças de
recursos entre as várias implementações de nó, essas diferenças são relativamente pequenas, e a
maioria das implementações converge para os padrões comuns definidos pelos BOLTs.
A familiaridade com a linguagem de programação e o sistema de compilação, por outro lado, é uma
boa base para escolher um nó. Isso ocorre porque a instalação, configuração, manutenção contínua
e solução de problemas envolverão a interação com as várias ferramentas usadas pelo sistema de
compilação. Isso inclui:
• Make, Autotools, e utilidades GNU para c-lightning
• Utilidades Go para LND
• Java/Maven para Eclair
A linguagem de programação influencia não apenas a escolha do sistema de compilação, mas

também muitos outros aspectos do programa. Cada linguagem de programação possui uma filosofia
de design e afeta muitos outros aspectos, como:
• Formato e sintaxe dos arquivos de configuração
• Localizações de arquivos (no sistema de arquivos)
• Argumentos de linha de comando e sua sintaxe
• Formatação da mensagem de erro
• Bibliotecas de pré-requisito
• Interfaces de chamada de procedimento remoto
Ao escolher o seu nó Lightning, você também está escolhendo todas as características mencionadas
anteriormente. Portanto, sua familiaridade com essas ferramentas e filosofias de design tornará
mais fácil executar um nó. Ou mais difícil, se você estiver em um domínio desconhecido.
Por outro lado, se esta for a sua primeira incursão no ambiente de linha de comando e em
servidores/serviços, você se encontrará sem familiaridade com qualquer implementação e terá a
oportunidade de aprender algo completamente novo. Nesse caso, você pode tomar sua decisão com
base em uma série de outros fatores, como:
• Qualidade dos fóruns de suporte e salas de bate-papo
• Qualidade da documentação
• Grau de integração com outras ferramentas que você deseja executar
Como última consideração, você pode querer examinar o desempenho e a confiabilidade das
diferentes implementações de nós. Isso é especialmente importante se você pretende utilizar esse
nó em um ambiente de produção e espera um alto volume de tráfego e requisitos de alta
confiabilidade. Isso pode ser o caso se você planeja executar o sistema de pagamentos de uma loja
nele.
11
Instalando nó Bitcoin ou Lightning
Você decidiu não usar um "assistente" de instalação e, em vez disso, prefere se aventurar na linha
de comando de um sistema operacional Linux? Essa é uma decisão corajosa e faremos o possível
para ajudá-lo a fazer funcionar. Se você preferir não tentar fazer isso manualmente, considere usar
um aplicativo que o auxilie na instalação do software do nó ou uma solução baseada em contêiner,
conforme descrito em Usando um Instalador ou Assistente.
Esta seção abordará o tópico avançado da administração do sistema a partir da linha de

comando. A administração do Linux é uma habilidade própria que está fora do escopo deste
livro. É um tópico complicado e há muitos desafios. Prossiga com cautela!
Nas próximas seções, descreveremos brevemente como instalar e configurar um nó Bitcoin e

Lightning em um sistema operacional Linux. Você precisará revisar as instruções de instalação
para os aplicativos de nó Bitcoin e Lightning específicos que você decidiu usar. Geralmente, você
pode encontrá-las em um arquivo chamado INSTALL ou no subdiretório docs de cada projeto.
Apenas descreveremos alguns dos passos comuns que se aplicam a todos esses serviços, e as
instruções que ofereceremos serão necessariamente incompletas.
Serviços em Segundo Plano
Para aqueles acostumados a executar aplicativos em seu desktop ou smartphone, um aplicativo

sempre possui uma interface gráfica, mesmo que às vezes seja executado em segundo plano. No
entanto, os aplicativos de nó Bitcoin e Lightning são muito diferentes. Esses aplicativos não
possuem uma interface gráfica incorporada. Em vez disso, eles são executados como serviços de
plano de fundo headless, o que significa que estão sempre operando em segundo plano (in the
background) e não interagem diretamente com o usuário.
Isso pode criar alguma confusão para usuários que não estão acostumados a executar serviços em
segundo plano. Como saber se um serviço está sendo executado? Como iniciar e parar o serviço?
Como interagir com ele? As respostas a essas perguntas dependem do sistema operacional que você
está usando. Por enquanto, vamos assumir que você está usando alguma variante do Linux e
responderemos a essas perguntas nesse contexto.
Isolamento do Processo
Os serviços em segundo plano geralmente são executados sob uma conta de usuário específica para
isolá-los do sistema operacional e entre si. Por exemplo, o Bitcoin Core é configurado para ser
executado como usuário bitcoin. Você precisará usar a linha de comando para criar um usuário
para cada um dos serviços que você executar.
Além disso, se você conectou uma unidade externa, precisará informar ao sistema operacional para
realocar o diretório principal do usuário para essa unidade. Isso ocorre porque um serviço como o
Bitcoin Core criará arquivos sob o diretório principal (home) do usuário. Se você estiver
configurando-o para baixar toda a blockchain do Bitcoin, esses arquivos ocuparão várias centenas
de gigabytes. Aqui, assumimos que você conectou a unidade externa e ela está localizada no
caminho /external_drive/ do sistema operacional.
12
Na maioria dos sistemas Linux, você pode criar um novo usuário com o comando useradd, da
seguinte maneira:
$ sudo useradd -m -d /external_drive/bitcoin -s /dev/null bitcoin
As flags m e d criam o diretório home do usuário conforme especificado por /external_drive/bitcoin

neste caso. A flag s atribui o shell interativo do usuário. Neste caso, definimos como /dev/null para
desabilitar o uso do shell interativo. O último argumento é o nome de usuário do novo usuário,
bitcoin.
Inicialização do Nó
Tanto para os serviços do nó Bitcoin quanto do Lightning, a "instalação" também envolve a criação
de um chamado script de inicialização para garantir que o nó seja iniciado quando o computador é
ligado. A inicialização e desligamento de serviços em segundo plano são tratados por um processo
do sistema operacional, que no Linux é chamado de init ou systemd. Geralmente, é possível
encontrar um script de inicialização do sistema no subdiretório contrib de cada projeto. Por
exemplo, se você estiver em um sistema operacional Linux moderno que utiliza systemd,
encontrará um script chamado bitcoind.service que pode iniciar e parar o serviço do nó Bitcoin
Core.
Aqui está um exemplo de como se parece um script de inicialização de um nó Bitcoin, retirado do

repositório de código do Bitcoin Core:
From bitcoin/contrib/init/bitcoind.service
[Unit]
Description=Bitcoin daemon
After=network.target
[Service]
ExecStart=/usr/bin/bitcoind -daemon \
-pid=/run/bitcoind/bitcoind.pid \
-conf=/etc/bitcoin/bitcoin.conf \
-datadir=/var/lib/bitcoind
# Make sure the config directory is readable by the service user

PermissionsStartOnly=true
ExecStartPre=/bin/chgrp bitcoin /etc/bitcoin
# Process management
####################
Type=forking
PIDFile=/run/bitcoind/bitcoind.pid
Restart=on-failure
TimeoutStopSec=600
# Directory creation and permissions
13
####################################
# Run as bitcoin:bitcoin
User=bitcoin
Group=bitcoin
# /run/bitcoind
RuntimeDirectory=bitcoind
RuntimeDirectoryMode=0710
# /etc/bitcoin
ConfigurationDirectory=bitcoin
ConfigurationDirectoryMode=0710
# /var/lib/bitcoind
StateDirectory=bitcoind
StateDirectoryMode=0710
[...]
[Install]
WantedBy=multi-user.target
Como usuário root, instale o script copiando-o para a pasta de serviço do systemd em
/lib/systemd/system/, e em seguida recarregue o systemd:
$ sudo systemctl daemon-reload
Em seguida, habilite o serviço:
$ sudo systemctl enable bitcoind
Agora você pode iniciar e parar o serviço. Não inicie ainda, pois não configuramos o nó Bitcoin.
$ sudo systemctl start bitcoind

$ sudo systemctl stop bitcoind
Configuração do Nó
Para configurar seu nó, você precisa criar e fazer referência a um arquivo de configuração. Por
convenção, esse arquivo geralmente é criado em /etc, sob um diretório com o nome do programa.
Por exemplo, as configurações do Bitcoin Core e do LND normalmente são armazenadas em
/etc/bitcoin/bitcoin.conf e /etc/lnd/lnd.conf, respectivamente.
Esses arquivos de configuração são arquivos de texto nos quais cada linha expressa uma opção de
configuração e seu valor. Valores padrão são assumidos para qualquer coisa que não esteja definida
14
no arquivo de configuração. Você pode ver quais opções podem ser definidas na configuração de
duas maneiras. Primeiro, executar o aplicativo do nó com o argumento help mostrará as opções
que podem ser definidas na linha de comando. Essas mesmas opções podem ser definidas no
arquivo de configuração. Segundo, você geralmente pode encontrar um exemplo de arquivo de
configuração, com todas as opções padrão, no repositório de código do software.
Você pode encontrar um exemplo de arquivo de configuração em cada uma das imagens Docker
que usamos no [set_up_a_lightning_node]. Por exemplo, o arquivo
code/docker/bitcoind/bitcoind/bitcoin.conf:
Configuration file for docker bitcoind (code/docker/bitcoind/bitcoind/bitcoin.conf)
Unresolved directive in for_use_mastering-the-lightning-

network_ch_05_node_operations_pt_BR.txt -
include::code/docker/bitcoind/bitcoind/bitcoin.conf[]
A configuração desse arquivo em particular configura o Bitcoin Core para operar como um nó
regtest e fornece um nome de usuário e senha fracos para acesso remoto, portanto, você não deve
usá-lo para a configuração do seu nó. No entanto, ele serve para ilustrar a sintaxe de um arquivo de
configuração e você pode fazer ajustes nele no contêiner Docker para experimentar diferentes
opções. Veja se você consegue usar o comando bitcoind -help para entender o que cada uma das
opções faz no contexto da rede Docker que construímos no [set_up_a_lightning_node].
Frequentemente, os valores padrão são suficientes e, com algumas modificações, o software do seu
nó pode ser configurado rapidamente. Para iniciar um nó do Bitcoin Core com personalização
mínima, você só precisa de quatro linhas de configuração:
server=1
daemon=1
txindex=1
rpcuser=USERNAME
rpcpassword=PASSWORD
Mesmo a opção txindex não é estritamente necessária, embora ela garanta que o nó do Bitcoin crie
um índice de todas as transações, o que é necessário para algumas aplicações. A opção txindex não
é necessária para executar um nó Lightning.
Um nó Lightning c-lightning executado no mesmo servidor também requer apenas algumas linhas
na configuração:
network=mainnet
bitcoin-rpcuser=USERNAME
bitcoin-rpcpassword=PASSWORD
Em geral, é uma boa ideia minimizar a quantidade de personalização desses sistemas. A

configuração padrão é cuidadosamente projetada para suportar as implantações mais comuns. Se
você modificar um valor padrão, isso pode causar problemas posteriormente ou reduzir o
15
desempenho do seu nó. Em resumo, faça modificações apenas quando necessário!
Configuração de Rede
A configuração de rede geralmente não é um problema ao configurar um novo aplicativo. No

entanto, redes ponto a ponto como o Bitcoin e a Lightning Network apresentam alguns desafios
únicos para a configuração de rede.
Em um serviço centralizado, o seu computador se conecta aos "grandes servidores" de uma

empresa, e não o contrário. A sua conexão de internet residencial é configurada com a suposição de
que você é apenas um consumidor de serviços fornecidos por outros. Mas em um sistema ponto a
ponto, cada nó tanto consome como fornece serviços para outros nós. Se você está executando um
nó de Bitcoin ou Lightning em sua casa, você está fornecendo um serviço para outros computadores
na internet. O seu serviço de internet, por padrão, não está configurado para permitir que você
execute servidores e pode precisar de alguma configuração adicional para permitir que outros
acessem o seu nó.
Se você deseja executar um nó de Bitcoin ou Lightning, é necessário permitir que outros nós na
internet se conectem a você. Isso significa habilitar conexões TCP de entrada para a porta do Bitcoin
(porta 8333 por padrão) ou a porta do Lightning (porta 9735 por padrão). Embora seja possível
executar um nó de Bitcoin sem conectividade de entrada, isso não é possível com um nó de
Lightning. Um nó de Lightning deve ser acessível para outros de fora da sua rede.
Por padrão, o roteador de internet residencial não espera conexões de entrada do exterior e, na
verdade, bloqueia essas conexões. O endereço IP do seu roteador de internet é o único endereço IP
acessível externamente, e todos os computadores que você executa dentro da rede doméstica
compartilham esse único endereço IP. Isso é alcançado por meio de um mecanismo chamado
Tradução de Endereços de Rede (Network Address Translation, NAT), que permite que o roteador de
internet atue como intermediário para todas as conexões de saída.Se você deseja permitir uma
conexão de entrada, você precisa configurar o encaminhamento de porta (port forwarding), que
informa ao seu roteador de internet que as conexões de entrada em portas específicas devem ser
encaminhadas para computadores específicos dentro da rede. Isso pode ser feito manualmente,
alterando a configuração do seu roteador de internet, ou, se o seu roteador suportar, por meio de
um mecanismo automático de encaminhamento de porta chamado Universal Plug and Play (UPnP).
Um mecanismo alternativo ao encaminhamento de porta é habilitar o The Onion Router (Tor), que
fornece uma espécie de rede virtual privada sobreposta que permite conexões de entrada a um
endereço onion. Se você executar o Tor, não será necessário fazer o encaminhamento de porta ou
permitir conexões de entrada nas portas do Bitcoin ou do Lightning. Se você executar seus nós
usando o Tor, todo o tráfego passará pelo Tor e nenhuma outra porta será usada.
Vamos analisar diferentes maneiras pelas quais você pode permitir que outras pessoas se conectem
ao seu nó. Vamos abordar essas alternativas em ordem, do mais fácil ao mais difícil.
Simplesmente funciona!
Existe a possibilidade de que seu provedor de serviços de Internet ou roteador esteja configurado
para suportar UPnP por padrão e tudo funcione automaticamente. Vamos tentar essa abordagem
primeiro, caso tenhamos sorte.
16
Supondo que você já tenha um nó Bitcoin ou Lightning em execução, vamos verificar se eles são
acessíveis externamente.
Para que esse teste funcione, você precisa ter um nó Bitcoin ou Lightning (ou ambos) em
execução em sua rede doméstica. Se o seu roteador suporta UPnP, o tráfego de entrada será
automaticamente encaminhado para as portas correspondentes no computador que está
executando o nó.
Você pode usar alguns sites muito populares e úteis para descobrir qual é o seu endereço IP externo
e se ele permite e encaminha conexões de entrada para uma porta conhecida. Aqui estão dois sites
confiáveis:
• https://canyouseeme.org
• https://www.whatismyip.com/port-scanner
Por padrão, esses serviços permitem que você verifique apenas as conexões de entrada para o
endereço IP a partir do qual você está conectado. Isso é feito para evitar que você use o serviço para
escanear redes e computadores de outras pessoas. Você verá o endereço IP externo do seu roteador
e um campo para inserir um número de porta. Se você não alterou as portas padrão na
configuração do seu nó, tente a porta 8333 (Bitcoin) e/ou 9735 (Lightning).
Na Verificando a porta de entrada 9735 você pode ver o resultado da verificação da porta 9735 em
um servidor executando a Lightning usando a ferramenta de verificação de porta do
whatismyip.com. Ela mostra que o servidor está aceitando conexões de entrada na porta da
Lightning. Se você ver um resultado assim, está tudo pronto!
Figure 3. Verificando a porta de entrada 9735
Encaminhamento de porta automático usando UPnP
Às vezes, mesmo que o seu roteador de internet suporte UPnP, ele pode estar desativado por
padrão. Nesse caso, você precisa alterar a configuração do seu roteador de internet por meio da
interface de administração web:
17
1. Conecte-se ao site de configuração do roteador de internet. Normalmente, isso pode ser feito
conectando-se ao endereço de gateway da sua rede doméstica usando um navegador da web.
Você pode encontrar o endereço de gateway verificando a configuração IP de qualquer
computador na sua rede doméstica. Geralmente, é o primeiro endereço em uma das redes não
roteáveis, como 192.168.0.1 ou 10.0.0.1. Verifique também todos os adesivos no seu roteador
para encontrar o gateway address. Uma vez encontrado, abra um navegador e insira o endereço
IP na barra de URL/Pesquisa do navegador, por exemplo, "192.168.0.1" ou "http://192.168.0.1."
2. Encontre o nome de usuário e senha do administrador para o painel de configuração web do

roteador. Isso geralmente está escrito em um adesivo no próprio roteador e pode ser tão
simples como "admin" e "senha". Uma rápida pesquisa na web pelo seu provedor de serviços de
internet (ISP) e modelo do roteador também pode ajudar a encontrar essas informações.
3. Encontre uma opção para UPnP e ative-a.
Reinicie seu nó Bitcoin e/ou Lightning e repita o teste de porta aberta com um dos sites que usamos
na seção anterior.
======= Usando o Tor para conexões de entrada
O The Onion Router (Tor) é uma VPN com a propriedade especial de criptografar as comunicações
entre os nós intermediários, de modo que qualquer nó intermediário não possa determinar a
origem ou o destino de um pacote. Tanto os nós Bitcoin quanto os nós Lightning suportam a
operação sobre o Tor, o que permite que você opere um nó sem revelar seu endereço IP ou
localização. Portanto, ele fornece um alto nível de privacidade para o tráfego da sua rede. Uma
vantagem adicional de executar o Tor é que, porque ele opera como uma VPN, resolve o problema
de encaminhamento de porta do seu roteador de internet. As conexões de entrada são recebidas
através do túnel do Tor, e seu nó pode ser encontrado por meio de um endereço onion gerado para
essa função, em vez de um endereço IP.
Para habilitar o Tor, são necessários dois passos. Primeiro, você precisa instalar o roteador e o
proxy Tor em seu computador. Segundo, você precisa habilitar o uso do proxy Tor em sua
configuração do Bitcoin ou Lightning.
Para instalar o Tor em um sistema Ubuntu Linux que utiliza o gerenciador de pacotes apt, execute o
seguinte comando:
sudo apt install tor
Em seguida, configuramos nosso nó Lightning para usar o Tor para conectividade externa. Aqui
está um exemplo de configuração para o LND:
[Tor]
tor.active=true
tor.v3=true
tor.streamisolation=true
listen=localhost
Isso ativará o Tor (tor.active), estabelecerá um serviço onion v3 (tor.v3=true), usará um fluxo onion
18
diferente para cada conexão (tor.streamisolation) e restringirá a escuta de conexões apenas para o
host local, para evitar vazamento do seu endereço IP (l⁠i⁠s⁠t⁠e⁠n=⁠l⁠o⁠c⁠a⁠l⁠h⁠o⁠s⁠t).
Você pode verificar se o Tor está corretamente instalado e funcionando executando um simples
comando de uma linha. Este comando deve funcionar na maioria das distribuições Linux:
curl --socks5 localhost:9050 --socks5-hostname localhost:9050 -s

https://check.torproject.org/ | cat | grep -m 1 Congratulations | xargs
Se tudo está funcionando corretamente, a resposta para esse comando deve ser "Congratulations.
This browser is configured to use Tor."
Devido à natureza do Tor, não é fácil usar um serviço externo para verificar se o seu nó é acessível
através de um endereço onion. No entanto, você deve ver o seu endereço onion do Tor nos registros
(logs) do seu nó Lightning. É uma sequência longa de letras e números seguida do sufixo .onion.
Agora o seu nó deve ser acessível a partir da internet, com a vantagem adicional de privacidade!
Encaminhamento manual de porta
Esse é o processo mais complexo e requer habilidades técnicas avançadas. Os detalhes dependem
do tipo de roteador de internet que você possui, das configurações e políticas do seu provedor de
serviços e de muitos outros contextos. Tente primeiro o UPnP ou o Tor, antes de tentar esse
mecanismo muito mais difícil.
Os passos básicos são os seguintes:
1. Encontre o endereço IP do computador onde o seu nó está localizado. Isso geralmente é alocado
dinamicamente pelo Protocolo de Configuração Dinâmica de Hosts (DHCP) e costuma estar em
algum lugar do intervalo 192.168.x.x ou 10.x.x.x.
2. Encontre o endereço de controle de acesso à mídia (MAC) da interface de rede do seu nó. Isso
pode ser encontrado nas configurações de internet desse computador.
3. Atribua um endereço IP estático para o seu nó, para que ele seja sempre o mesmo. Você pode
usar o endereço IP que ele possui atualmente. No seu roteador de internet, procure por "Static
Leases" nas configurações de DHCP. Associe o endereço MAC ao endereço IP selecionado. Agora,
o seu nó sempre terá esse endereço IP alocado. Alternativamente, você pode verificar a
configuração de DHCP do seu roteador e descobrir qual é o intervalo de endereços DHCP.
Selecione um endereço não utilizado fora do intervalo de endereços DHCP. Em seguida, no
servidor, configure a rede para parar de usar o DHCP e defina o endereço IP selecionado, que
não é obtido por DHCP, na configuração de rede do sistema operacional.
4. Por fim, configure o "Redirecionamento de Portas" (Port Forwarding) no seu roteador de

internet para encaminhar o tráfego de entrada em portas específicas para o endereço IP
selecionado do seu servidor.
Assim que terminar de reconfigurar, repita a verificação de portas usando um dos sites das seções
anteriores.
19
Segurança do Seu Nó
Um nó Lightning é, por definição, uma hot wallet (carteira quente). Isso significa que os fundos
(tanto na cadeia principal quanto fora da cadeia, on-chain e off-chain) controlados por um nó
Lightning são diretamente controlados pelas chaves que estão carregadas na memória do nó ou
armazenadas no disco rígido do nó. Se um nó Lightning for comprometido, é trivial criar transações
na cadeia principal ou fora da cadeia para esvaziar seus fundos. Portanto, é extremamente
importante protegê-lo contra acesso não autorizado.
A segurança é um esforço holístico, o que significa que você precisa garantir a segurança em todas
as camadas de um sistema. Como diz o ditado: a corrente é tão forte quanto o seu elo mais fraco.
Esse é um conceito importante na segurança da informação e aplicaremos isso ao nosso nó.
Apesar de todas as medidas de segurança que você adotará, lembre-se de que a Lightning Network
é uma tecnologia experimental em estágio inicial e é provável que haja bugs no código de qualquer
projeto que você use. Não coloque mais dinheiro do que está disposto a arriscar perder na Lightning
Network.
Segurança do Sistema Operacional
Assegurar um sistema operacional é um tópico amplo que está além do escopo deste livro. No
entanto, podemos estabelecer alguns princípios básicos.
Para garantir a segurança do seu sistema operacional, aqui estão alguns dos principais itens a
serem considerados:
Procedência
Comece garantindo que você esteja baixando a imagem correta do sistema operacional e
verifique as assinaturas ou checksums antes de instalá-lo. Estenda isso para qualquer software
que você instalar. Verifique duas vezes a origem ou URL de onde você faz o download. Verifique
a integridade e a correção do software baixado por meio da verificação de assinaturas e
checksums.
Manutenção
Certifique-se de manter seu sistema operacional atualizado. Habilite a instalação automatizada
de atualizações de segurança diariamente ou semanalmente.
Privilégio mínimo
configure usuários para processos específicos e conceda a eles o menor acesso necessário para
executar um serviço. Não execute processos com privilégios de administrador (por exemplo,
root).
Isolamento de processos
Use as funcionalidades do sistema operacional para isolar os processos uns dos outros.
Permissões do sistema de arquivos

Configure cuidadosamente o sistema de arquivos, seguindo o princípio do menor privilégio. Não
permita que arquivos sejam lidos ou alteráveis por todos.
20
Autenticação forte
Use senhas fortes geradas aleatoriamente ou, sempre que possível, autenticação por chave
pública. Por exemplo, é mais seguro usar o Secure Shell (SSH) com um par de chaves
criptográficas em vez de uma senha.
Autenticação de dois fatores (2FA)

Use a autenticação de dois fatores sempre que possível, incluindo o Universal 2nd Factor (U2F)
com chaves de segurança físicas. Isso se aplica a todos os serviços externos que você possa estar
usando, como o seu provedor de serviços em nuvem. Você também pode aplicar isso à sua
própria configuração, como a sua própria configuração do SSH. Use a 2FA também para serviços
indiretos. Por exemplo, digamos que você esteja usando um serviço em nuvem. Você forneceu ao
seu provedor de serviços em nuvem um endereço de e-mail, portanto, você também deve
proteger seu endereço de e-mail com 2FA. Backup: Faça backups do seu sistema e certifique-se
de proteger os backups com criptografia também. Realize esses backups periodicamente. Pelo
menos uma vez, teste se você consegue restaurar seu backup e se o backup está completo e
acessível. Se possível, mantenha uma cópia dos backups em um disco diferente para evitar que
uma falha em um único disco rígido destrua tanto seu nó ativo quanto suas cópias de backup.
Gerenciamento de vulnerabilidades e exposição: Use varreduras remotas para garantir que você
tenha minimizado a superfície de ataque do seu sistema. Feche quaisquer serviços ou portas
desnecessárias. Instale apenas software e pacotes que você realmente precisa e usa. Desinstale
pacotes que você não utiliza mais. É recomendado que você não utilize seu computador de nó
para atividades não relacionadas ao nó que você pode realizar em outro computador.
Especialmente, se possível, não use seu computador de nó para navegar, acessar a internet ou
ler seus e-mails.
Esta é uma lista das medidas de segurança mais básicas. Ela não é de forma alguma exaustiva.
Acesso ao Nó
O seu nó Lightning expõe uma API de chamada de procedimento remoto (RPC). Isso significa que o
seu nó pode ser controlado remotamente por comandos enviados para uma porta TCP específica. O
controle de acesso a essa API RPC é feito por meio de autenticação do usuário. Dependendo do tipo
de nó Lightning que você configurou, isso pode ser feito por username/password autenticação ou
por um mecanismo chamado de macaroon de autenticação. Como o nome sugere, um macaroon é
um tipo mais sofisticado de cookie. Ao contrário de um cookie, ele é assinado criptograficamente e
pode expressar um conjunto de permissões de acesso.
Por exemplo, o LND usa macaroons para conceder acesso à API RPC. Por padrão, o software LND
cria três macaroons com diferentes níveis de acesso, chamados admin, invoice e readonly.
Dependendo de qual macaroon você copiar e usar no seu cliente RPC, você terá acesso apenas para
leitura (read-only), acesso para criação de faturas (que inclui as capacidades de leitura) ou acesso de
administrador, que oferece controle total. Há também uma função de macaroon bakery no LND que
pode construir macaroons com qualquer combinação de capacidades com controle muito preciso.
Se você estiver usando um modelo de autenticação de nome de usuário/senha, certifique-se de

escolher uma senha longa e aleatória. Você não precisará digitar essa senha com frequência, pois
ela será armazenada nos arquivos de configuração. Portanto, escolha uma senha que não possa ser
adivinhada. Muitos dos exemplos que você encontrará incluem senhas mal escolhidas, e muitas
21
vezes as pessoas as copiam em seus próprios sistemas, fornecendo fácil acesso para qualquer
pessoa. Não faça isso! Use um gerenciador de senhas para gerar uma senha alfanumérica longa e
aleatória. Como certos caracteres especiais, como $?/!*\&%`"', podem interferir na linha de
comando, é melhor evitá-los para senhas que serão usadas em um ambiente de shell. Para evitar
problemas, opte por senhas alfanuméricas longas e aleatórias.
Uma sequência alfanumérica simples que tenha mais de 12 caracteres e seja gerada aleatoriamente
geralmente é suficiente. Se você planeja armazenar grandes quantias de dinheiro em seu nó
Lightning e está preocupado com ataques de força bruta remotos, selecione uma senha com mais
de 20 caracteres para tornar esses ataques praticamente inviáveis.
Backups de Nós e Canais

Uma consideração muito importante ao executar um nó Lightning é a questão dos backups. Ao
contrário de uma carteira Bitcoin, onde uma frase mnemônica BIP-39 pode recuperar todo o estado
da carteira, na Lightning isso não é o caso.
As carteiras da Lightning utilizam uma frase mnemônica BIP-39 para o backup, mas somente da
carteira on-chain. No entanto, devido à forma como os canais são construídos, a frase mnemônica
não é suficiente para restaurar um nó Lightning.É necessária uma camada adicional de backups,
chamada de static channel backup (SCB). Sem um SCB, um operador de nó Lightning pode perder
todos os fundos que estão nos canais caso perca o armazenamento de dados do nó Lightning.
Não financie canais até ter um sistema para fazer backups contínuos do estado dos seus
canais. Seus backups devem ser movidos para um local "externo", em um sistema e localização
diferentes do seu nó, de modo que possam sobreviver a uma variedade de falhas do sistema
(perda de energia, corrupção de dados etc.) ou desastres naturais (inundações, incêndios etc.).
SCBs não são uma solução perfeita. Primeiro, o estado de cada canal precisa ser copiado (backed
up) a cada nova transação de compromisso. Segundo, restaurar a partir de um backup de canal é
perigoso. Se você não tiver a transação de compromisso mais recente e acidentalmente transmitir
uma transação de compromisso antiga (revogada), seu par de canal assumirá que você está
tentando trapacear e reivindicará todo o saldo do canal com uma transação de penalidade. Para
garantir que você esteja fechando o canal, você precisa realizar um fechamento cooperativo. Mas
um par malicioso poderia enganar o seu nó para transmitir um compromisso antigo e revogado
durante esse fechamento cooperativo, enganando você fazendo com que seu nó tente trapacear
inadvertidamente.
Além disso, os backups dos seus canais precisam ser criptografados para manter sua privacidade e
segurança dos canais. Caso contrário, qualquer pessoa que encontre os backups poderá não apenas
ver todos os seus canais, mas também poderia usar os backups para fechar todos os seus canais de
uma maneira que transfere o saldo para seus pares de canal. Em outras palavras, uma pessoa
maliciosa que tenha acesso aos seus backups pode fazer com que você perca todos os fundos dos
seus canais.
Você pode ver que os SCBs não são uma proteção infalível. Eles são um compromisso fraco, pois
trocam um tipo de risco (corrupção ou perda de dados) por outro tipo de risco (pares maliciosos).
22
Para restaurar a partir de um SCB, você precisa interagir com seus pares de canal e torcer para que
eles não tentem enganá-lo, fornecendo um compromisso antigo ou enganando seu nó para
transmitir um compromisso revogado, para que possam penalizá-lo. Apesar das fraquezas dos
SCBs, eles fazem sentido e você deve realizá-los. Se você não fizer os SCBs e perder os dados do seu
nó, perderá os fundos dos seus canais para sempre. Garantido! No entanto, se você fizer os SCBs e
perder os dados do seu nó, então você tem uma chance razoável de que alguns dos seus pares sejam
honestos e que você possa recuperar alguns dos seus fundos de canal. Se tiver sorte, talvez você
consiga recuperar todos os seus fundos. Em conclusão, é melhor realizar SCBs contínuos em um
disco diferente do disco rígido principal do nó.
Mecanismos de backup de canais ainda estão em desenvolvimento e são uma fraqueza na maioria
das implementações do Lightning.
No momento em que este livro foi escrito, apenas o LND oferece um mecanismo embutido para
SCBs. O Eclair tem um mecanismo semelhante implementado para implantações do lado do
servidor, embora o Eclair Mobile ofereça backup opcional para o Google Drive. O c-lightning
recentemente incorporou as interfaces necessárias para um plug-in implementar backups de
canais. Infelizmente, não há um mecanismo de backup consistente e acordado entre diferentes
implementações de nós.
Os backups baseados em arquivos dos bancos de dados dos nós Lightning são, no máximo, uma
solução parcial, pois você corre o risco de fazer o backup de um estado inconsistente do banco de
dados. Além disso, você pode não capturar de forma confiável os compromissos de estado mais
recentes. É muito melhor ter um mecanismo de backup que seja acionado sempre que houver uma
alteração de estado em um canal, garantindo assim a consistência dos dados.
Para configurar SCBs no LND, defina o parâmetro backupfilepath na linha de comando ou no

arquivo de configuração. O LND salvará então um arquivo SCB nesse diretório. No entanto, isso é
apenas o primeiro passo da solução. Agora você precisa configurar um mecanismo que monitore
esse arquivo em busca de alterações. Cada vez que o arquivo é alterado, o mecanismo de backup
deve copiar esse arquivo para outro disco, de preferência fora do local. Tais mecanismos de backup
estão para além do escopo deste livro. No entanto, qualquer solução de backup sofisticada deve ser
capaz de lidar com esse cenário. Lembre-se de que os arquivos de backup também devem ser
criptografados.
Risco de Carteira Quente
Comodiscutimos anteriormente, a Lightning Network consiste em uma rede de hot wallets. Os

fundos armazenados em uma carteira Lightning estão online o tempo todo, o que os torna
vulneráveis. Portanto, você não deve armazenar grandes quantidades em uma carteira Lightning.
Grandes quantidades devem ser mantidas em uma cold wallet (carteira fria) que não está online e
que só pode fazer transações on-chain.
Mesmo que você comece com pouco, com o tempo você pode acabar tendo uma quantia
significativa de dinheiro em uma carteira Lightning. Isso é comum em cenários de lojas. Se você usa
um nó Lightning para uma operação de comércio eletrônico, é provável que sua carteira receba
fundos com frequência, mas envie fundos raramente. Como resultado, você se deparará com dois
problemas simultaneamente. Primeiro, seus canais estarão desequilibrados, com saldos locais
grandes superando os saldos remotos pequenos. Segundo, você terá muito dinheiro na carteira.
23
Felizmente, é possível resolver ambos os problemas simultaneamente.
Vamos analisar algumas soluções que você pode usar para reduzir os fundos expostos em uma
carteira quente.
Varrendo Fundos
Se o saldo da sua carteira Lightning se tornar muito grande para a sua tolerância de risco, você
precisará "varrer" os fundos para fora da carteira. Você pode fazer isso de três maneiras: on-chain
(na blockchain), off-chain (fora da blockchain) e usando o serviço Loop Out. Vamos analisar cada
uma dessas opções nas próximas seções.
======= Varredura on-chain
Varrer os fundos para a blockchain é realizado movendo os fundos da carteira Lightning para uma
carteira Bitcoin. Você faz isso fechando os canais. Ao fechar um canal, todos os fundos do seu saldo
local são "varridos" para um endereço Bitcoin. O endereço Bitcoin para os fundos na blockchain
geralmente é gerado pela sua carteira Lightning, então ainda é uma carteira online. Você pode
precisar fazer uma transação adicional na blockchain para mover os fundos para um endereço
mais seguro, como um gerado pela sua carteira de hardware.
Fechar canais incorrerá em uma taxa na blockchain e reduzirá a capacidade e conectividade do seu
nó Lightning. No entanto, se você executar um nó de comércio eletrônico popular, não faltará
capacidade de entrada e poderá fechar canais estrategicamente com saldos locais grandes,
essencialmente "empacotando" seus fundos para movimentação na blockchain. Talvez seja
necessário usar técnicas de rebalanceamento de canais (see Reequilibrando Canais) antes de fechar
canais para maximizar os benefícios dessa estratégia.
Varredura off-chain
Outra técnica que você pode usar envolve executar um segundo nó Lightning que não é divulgado
na rede. Você pode estabelecer canais de grande capacidade a partir do seu nó público (por
exemplo, aquele que executa a sua loja) para o seu nó não divulgado (oculto). Regularmente,
"varra" os fundos fazendo um pagamento Lightning para o seu nó oculto.
A vantagem dessa técnica reside no fato de que o nó Lightning que recebe pagamentos para a sua
loja será publicamente conhecido. Isso o torna um alvo para hackers, já que qualquer nó Lightning
associado a uma loja seria considerado como tendo um saldo alto. Um segundo nó que não esteja
associado à sua loja não será facilmente identificado como um alvo valioso.
Como uma medida adicional de segurança, você pode tornar o seu segundo nó um serviço oculto do
Tor, de modo que seu endereço IP não seja conhecido. Isso reduz ainda mais as oportunidades de
ataques e aumenta a sua privacidade.
Você precisará configurar um script que seja executado em intervalos regulares. O objetivo desse
script é criar uma fatura no seu nó oculto e pagar essa fatura a partir do nó da sua loja,
transferindo assim os fundos para o seu nó oculto.
Lembre-se de que essa técnica não move os fundos para armazenamento a frio. Ambos os nós do
Lightning são carteiras online. O objetivo dessa transferência é mover os fundos de uma carteira
24
online muito conhecida para uma carteira online obscura.
Varredura de troca submarina
Outra maneira de reduzir o saldo da sua carteira quente Lightning é usar uma técnica chamada
submarine swap (troca submarina). Trocas submarinas, conceituadas pelos coautores Olaoluwa
Osuntokun e Alex Bosworth, permitem a troca de bitcoin na blockchain por pagamentos Lightning
e vice-versa. Essencialmente, as trocas submarinas são trocas atômicas entre fundos off-chain da
Lightning e fundos on-chain do Bitcoin.
Um operador de nó pode iniciar uma troca submarina e enviar todos os saldos disponíveis dos
canais para a outra parte, que irá enviar bitcoin on-chain em troca.
No futuro, isso poderia ser um serviço pago oferecido pelos nós na Lightning Network que
anunciam taxas de câmbio ou cobram uma taxa fixa pela conversão.
A vantagem de uma submarine swap para transferir fundos é que nenhum canal precisa ser
fechado. Isso significa que preservamos nossos canais, apenas reequilibrando-os por meio dessa
operação. Ao enviar um pagamento pela Lightning, transferimos parte do saldo de local para
remoto em um ou mais de nossos canais. Isso não apenas reduz o saldo exposto na carteira quente
do nosso nó, mas também aumenta o saldo disponível para futuros pagamentos recebidos.
Você poderia fazer isso confiando em um intermediário para atuar como uma porta de entrada,
mas isso arrisca que suas moedas sejam roubadas. No entanto, no caso de uma troca submarina, a
operação não requer confiança. Trocas submarinas são operações atômicas não custodiais. Isso
significa que a contraparte na sua transação submarina não pode roubar seus fundos, porque o
pagamento on-chain depende da conclusão do pagamento off-chain e vice-versa.
Troca Submarina com Loop
Um exemplo de serviço de troca submarina é o Loop, desenvolvido pela Lightning Labs, a mesma
empresa por trás do LND. O Loop possui duas variações: Loop In e Loop Out. O Loop In aceita um
pagamento em Bitcoin on-chain e o converte em um pagamento em Lightning off-chain. O Loop Out
converte um pagamento Lightning em um pagamento Bitcoin.
Para usar o serviço Loop, você precisa estar executando um nó Lightning LND.
Para reduzir o saldo da sua carteira quente Lightning, você usaria o serviço Loop Out. Para usar o
serviço Loop, você precisa instalar alguns softwares adicionais no seu nó. O software Loop é
executado ao lado do seu nó LND e fornece algumas ferramentas de linha de comando para
executar as operações de trocas submarinas. Você pode encontrar o software Loop e as instruções
de instalação em GitHub.
Uma vez que você tenha o software instalado e em execução, uma operação Loop Out é tão simples
quanto executar um único comando:
loop out --amt 501000 --conf_target 400

Max swap fees for 501000 sat Loop Out: 25716 sat
25
Regular swap speed requested, it might take up to 30m0s for the swap to be executed.
CONTINUE SWAP? (y/n), expand fee detail (x): x
Estimated on-chain sweep fee: 149 sat

Max on-chain sweep fee: 14900 sat
Max off-chain swap routing fee: 10030 sat
Max no show penalty (prepay): 1337 sat
Max off-chain prepay routing fee: 36 sat
Max swap fee: 750 sat
CONTINUE SWAP? (y/n): y
Swap initiated
Run `loop monitor` to monitor progress.
Observe que a taxa máxima, que representa um cenário de pior caso, dependerá do alvo de
confirmação que você selecionar.
Tempo de Atividade e Disponibilidade do Nó Lightning

Ao contrário do Bitcoin, os nós Lightning precisam estar online quase continuamente. O seu nó
precisa estar online para receber pagamentos, abrir canais, fechar canais (de forma cooperativa) e
monitorar violações de protocolo. A disponibilidade do nó é um requisito tão importante na
Lightning Network que é uma métrica usada por várias ferramentas automáticas de gerenciamento
de canais (por exemplo, autopilot) para decidir com quais nós abrir canais. Você também pode ver a
"disponibilidade" como uma métrica de nó em exploradores de nós populares (see [ln_explorer])
como 1ML.
A disponibilidade do nó é especialmente importante para mitigar e resolver possíveis violações de

protocolo (por exemplo, compromissos revogados). Embora você possa tolerar interrupções breves
de uma hora a um ou dois dias, não pode ter o seu nó offline por períodos mais longos sem correr o
risco de perda de fundos.
Manter um nó online continuamente não é fácil, pois vários bugs e limitações de recursos podem e
eventualmente causarão períodos de inatividade. Especialmente se você estiver executando um nó
movimentado e popular, você encontrará limitações de memória, espaço de swap, número de
arquivos abertos, espaço em disco e assim por diante. Uma série de problemas diferentes pode
fazer com que o seu nó ou servidor falhe.
Tolerar Falhas e Automatizar
Se você tiver tempo e habilidades, é recomendado testar alguns cenários de falhas básicas na rede
de testes da Lightning. Na rede de testes (testnet), você poderá aprender lições valiosas sem correr o
risco de perder fundos. Qualquer medida que você tomar para automatizar o seu sistema
melhorará a sua disponibilidade:
Reinício automático do servidor de computador

O que acontece quando o servidor ou o sistema operacional falham? O que acontece durante
uma queda de energia? Simule essa falha pressionando o botão "reset" no seu PC ou
26
desconectando o cabo de energia. Após uma falha, reinício ou queda de energia, o computador
deve reiniciar automaticamente. Alguns computadores possuem uma configuração na BIOS para
especificar como o computador deve reagir a falhas de energia. Teste para garantir que o
computador realmente reinicie automaticamente sem intervenção humana em caso de queda de
energia.
Reinício automático do nó
O que acontece quando o nó ou um dos seus nós falha? Simule essa falha encerrando os
processos correspondentes do nó. Se um nó falhar, ele deve reiniciar automaticamente. Teste
para garantir que o nó ou nós realmente reiniciem automaticamente em caso de falha, sem
intervenção humana. Se isso não acontecer, provavelmente seu nó não está configurado
corretamente como um serviço do sistema operacional.
Reconexão automática de rede

O que acontece se a sua rede ficar indisponível? O que acontece quando o seu provedor de
serviços de internet fica temporariamente fora do ar? O que acontece quando o seu provedor de
serviços de internet atribui um novo endereço IP ao seu roteador ou ao seu computador?
Quando a rede é restabelecida, os nós que você está executando reconectam automaticamente à
rede? Simule essa falha desconectando e posteriormente reconectando o cabo Ethernet do
dispositivo que hospeda os seus nós. Os nós devem se reconectar automaticamente e continuar
em operação sem intervenção humana.
Configure os seus arquivos de log: Todas as falhas mencionadas anteriormente devem deixar
registros textuais nos respectivos arquivos de log (logfiles). Aumente a verbosidade do registro se
necessário. Localize essas entradas de erro nos arquivos de log e utilize-os para monitoramento.
Monitorando a Disponibilidade do Nó
Monitorar o seu nó é uma parte importante para mantê-lo funcionando. Você precisa monitorar
não apenas a disponibilidade do próprio computador, mas também a disponibilidade e o
funcionamento correto do software do nó Lightning.
Existem várias maneiras de fazer isso, mas a maioria requer alguma personalização. Você pode
usar monitoramento genérico de infraestrutura ou ferramentas de monitoramento de aplicativos,
mas precisará personalizá-las especificamente para consultar a API do nó Lightning para garantir
que o nó esteja em execução, sincronizado com a blockchain, e conectado aos pares de canais.
Lightning.watch fornece um serviço especializado que oferece monitoramento do nó Lightning. Ele

utiliza um bot do Telegram para notificá-lo sobre quaisquer interrupções no serviço. Este é um
serviço gratuito, embora você possa pagar (através da Lightning, é claro) para obter alertas mais
rápidos.
Ao longo do tempo, esperamos que mais serviços de terceiros forneçam monitoramento

especializado de nós Lightning, pagáveis por meio de micropagamentos. Talvez esses serviços e
suas APIs se tornem padronizados e um dia sejam suportadas diretamente pelo software do nó
Lightning.
27
Torres de Vigia (Watchtowers)
Watchtowers são um mecanismo para terceirizar o monitoramento e resolução de penalidades de

violações do protocolo Lightning.
Como mencionado nos capítulos anteriores, o protocolo Lightning mantém a segurança por meio de
um mecanismo de penalidade. Se um dos seus parceiros de canal transmitir uma transação de
compromisso antiga, o seu nó precisará executar a cláusula de revogação e transmitir uma
transação de penalidade para evitar perda de fundos. No entanto, se o seu nó estiver inativo
durante a violação do protocolo, você poderá perder dinheiro.
Para resolver esse problema, podemos usar um ou mais watchtowers para terceirizar a tarefa de
monitorar as violações do protocolo e emitir transações de penalidade. Existem duas partes em
uma configuração de watchtower: um servidor de watchtower (ou simplesmente watchtower) que
monitora a blockchain e um cliente de watchtower que solicita ao servidor de watchtower esse
serviço de monitoramento.
A tecnologia dos watchtowers ainda está em estágios iniciais de desenvolvimento e não é

amplamente suportada. No entanto, na passagem a seguir, listamos algumas implementações
experimentais que você pode experimentar.
O software LND inclui tanto um servidor watchtower quanto um cliente watchtower. Você pode
ativar o servidor watchtower adicionando as seguintes opções de configuração:
[watchtower]
watchtower.active=1
watchtower.towerdir=/path_to_watchtower_data_directory
Você pode usar o cliente watchtower do LND ativando-o na configuração e, em seguida, usando a
linha de comando para conectá-lo a um servidor watchtower. A configuração é a seguinte:
[wtclient]
wtclient.active=1
O cliente de linha de comando do LND, lncli, mostra as seguintes opções para gerenciar o cliente do
watchtower:
$ lncli wtclient
NAME:
lncli wtclient - Interact with the watchtower client.
USAGE:
lncli wtclient command [command options] [arguments...]
COMMANDS:
add Register a watchtower to use for future sessions/backups.
remove Remove a watchtower to prevent its use for future sessions/backups.
28
towers Display information about all registered watchtowers.
tower Display information about a specific registered watchtower.
stats Display the session stats of the watchtower client.
policy Display the active watchtower client policy configuration.
OPTIONS:
--help, -h show help
O c-lightning possui os ganchos de API necessários para um plug-in de cliente de watchtower,

embora nenhum plug-in desse tipo tenha sido implementado até o momento.
Por fim, um servidor de watchtower independente popular é o The Eye of Satoshi (TEOS). Ele pode
ser encontrado em GitHub.
Gestão de Canais
Como operador de um nó Lightning, uma das tarefas recorrentes que você precisará realizar é a
gestão dos seus canais. Isso significa abrir canais de saída do seu nó para outros nós, bem como
conseguir que outros nós abram canais de entrada para o seu nó. No futuro, a construção
cooperativa de canais pode ser possível, permitindo que você abra canais simétricos nos quais os
fundos são comprometidos em ambas as extremidades desde o início. Por enquanto, no entanto,
novos canais têm fundos apenas em uma extremidade, no lado do originador. Portanto, para
equilibrar o seu nó com capacidade de entrada e saída, é necessário abrir canais com outros nós e
incentivar outros nós a abrir canais para o seu nó.
Abrindo Canais de Saída
Assim que você colocar o seu nó Lightning em funcionamento, você pode financiar sua carteira
Bitcoin e, em seguida, começar a abrir canais com esses fundos.
Você deve escolher cuidadosamente os parceiros de canal, pois a capacidade do seu nó de enviar
pagamentos depende de quem são seus parceiros de canal e de quão bem conectados eles estão
com o restante da Lightning Network. Você também deseja ter mais de um canal para evitar ser
suscetível a um único ponto de falha. Como o Lightning agora suporta pagamentos multipartes,
você pode dividir seus fundos iniciais em vários canais e rotear pagamentos maiores combinando
sua capacidade. Ao mesmo tempo, evite tornar seus canais muito pequenos. Como você precisa
pagar taxas de transação em Bitcoin para abrir e fechar um canal, o saldo do canal não deve ser tão
pequeno a ponto de as taxas on-chain consumirem uma parte significativa. É tudo uma questão de
equilíbrio!
Para resumir:
• Conecte-se a alguns nós bem conectados
• Abra mais de um canal
• Não abra canais em excesso
• Não faça os canais muito pequenos
29
Uma maneira de encontrar nós bem conectados é abrir um canal para um comerciante popular que
venda produtos na Lightning Network. Esses nós tendem a ser bem financiados e bem conectados.
Então, quando você estiver pronto para comprar algo online via Lightning, você pode abrir um
canal diretamente para o nó do comerciante. O ID do nó do comerciante estará na fatura que você
receberá ao tentar comprar algo. Isso facilita o processo.
Outra maneira de encontrar nós bem conectados é usar um Explorador da Lightning (see
[ln_explorer]) como 1ML e navegue pela lista de nós classificados por capacidade do canal e
número de canais. Não escolha os nós maiores, pois isso incentiva a centralização. Opte por um nó
que esteja no meio da lista para ajudá-lo a crescer. Outro fator a considerar pode ser o tempo de
operação do nó. Nós estabelecidos há mais de um ano provavelmente são mais respeitáveis e
menos arriscados do que nós que começaram a operar há uma semana.
Piloto Automático
A tarefa de abrir canais pode ser parcialmente automatizada com o uso de um autopilot, que é um
software que abre canais automaticamente com base em algumas regras heurísticas. O software de
autopilot ainda é relativamente novo e nem sempre seleciona os melhores parceiros de canal para
você. Especialmente no início, pode ser melhor abrir canais manualmente. Atualmente, os
autopilots existem em três formas:
• lnd incorpora um autopilot que está totalmente integrado com o lnd e é executado
constantemente em segundo plano quando ativado.
• lib_autopilot.py pode oferecer cálculos de autopilot para qualquer implementação de nó com

base nos dados de gossip e de canais.
• Um plugin c-lightning baseado em lib_autopilot.py existe que fornece uma interface fácil de
usar para usuários do c-lightning.
Esteja ciente de que o autopilot do lnd começará a ser executado em segundo plano assim que for
ativado através do arquivo de configuração. Como resultado, ele começará a abrir canais
imediatamente se você tiver saídas on-chain em sua carteira do lnd. Se você deseja ter controle
total sobre as transações de bitcoin que você realiza e os canais que você abre, certifique-se de
desativar o autopilot antes de carregar sua carteira do lnd com fundos de bitcoin. Se o autopilot
estava anteriormente ativado, você pode precisar reiniciar o lnd antes de adicionar fundos à sua
carteira com uma transação on-chain ou antes de fechar canais, o que efetivamente lhe dará fundos
on-chain novamente. É crucial que você defina valores de configuração-chave se deseja executar o
autopilot. Dê uma olhada neste exemplo de configuração:
[lnd-autopilot]
autopilot.active=1
autopilot.maxchannels=40
autopilot.allocation=0.70
autopilot.minchansize=500000
autopilot.maxchansize=5000000
autopilot.heuristic=top_centrality:1.0
Este arquivo de configuração ativaria o piloto automático. Ele abriria canais desde que as duas
30
condições a seguir fossem atendidas:
1. Seu nó atualmente tem menos de 40 canais abertos.
2. Menos de 70% de seus fundos totais estão off-chain em canais de pagamento.
Os números 40 e 0.7 são escolhidos completamente arbitrariamente aqui porque não podemos
fazer recomendações que sejam válidas para todos sobre quantos canais você deve ter abertos e
qual porcentagem dos seus fundos deve estar off-chain. O autopilot do lnd não levará em
consideração as taxas on-chain. Em outras palavras, ele não atrasará a abertura de canais para um
período em que as taxas estejam baixas. Para reduzir as taxas, você pode abrir canais
manualmente durante um período em que as taxas estejam baixas, por exemplo, durante o fim de
semana. O autopilot fará recomendações de canais sempre que as condições forem atendidas e
tentará imediatamente abrir um canal usando as taxas atuais apropriadas. De acordo com o
arquivo de configuração anterior, os canais terão um tamanho entre 5 mBTC (minchansize = 500.000
satoshis) e 50 mBTC (maxchansize = 5.000.000 satoshis). Como é comum, os valores no arquivo de
configuração estão enumerados em satoshis. Atualmente, canais com menos de 1 mBTC não são
muito úteis, e não recomendamos que você abra canais muito pequenos e abaixo desse valor. Com
a adoção mais ampla de pagamentos multipartes, canais menores têm menos impacto. No entanto,
por enquanto, essa é nossa recomendação.
O plug-in c-lightning, originalmente escrito por René Pickhardt (um dos coautores deste livro),
funciona de maneira muito diferente em comparação com o autopilot do lnd. Primeiramente, ele
difere nos algoritmos usados para fazer as recomendações. Não iremos abordar isso aqui. Em
segundo lugar, ele difere na sua interface de usuário. Você precisará baixar o plug-in do autopilot do
repositório de plug-ins do c-lightning repository e ativá-lo.
Para ativar um plug-in no c-lightning, coloque-o no diretório ~/.lightning/plugins, certifique-se

de que ele está executável (por exemplo, `chmod x ~/.lightning/plugins/autopilot.py`), e em
seguida, reinicie o +lightningd.
Alternativamente, se você não quiser que um plug-in seja ativado automaticamente quando
iniciar o lightningd, você pode colocá-lo em um diretório diferente e ativá-lo manualmente
com o argumento plugin para o lightningd:
lightningd --plugin=~/lightning-plugins/autopilot.py
O autopiloto no c-lightning é controlado por meio de três valores de configuração que podem ser
definidos no arquivo de configuração ou como argumentos de linha de comando ao iniciar o
lightningd:
[c-lightning-autopilot]
autopilot-percent=75
autopilot-num-channels=10
autopilot-min-channel-size-msat=100000000msat
31
Esses valores são as configurações padrão reais e você não precisa definí-los.
O piloto automático não será executado automaticamente em segundo plano, como no lnd. Em vez
disso, você precisa iniciar uma execução específica com lightning-cli autopilot-run-once se
desejar que o autopiloto abra os canais recomendados. Mas se você quiser apenas receber
recomendações, a partir das quais você pode selecionar manualmente os nós, você pode adicionar
o argumento opcional dryrun.
Uma diferença fundamental entre o autopilot do lnd e do c-lightning é que o autopilot do c-

lightning também fará uma recomendação para o tamanho do canal. Por exemplo, se o autopilot
recomenda abrir um canal com um nó pequeno que só tem canais pequenos, ele não recomendará
abrir um canal grande. No entanto, se ele abrir um canal com um nó bem conectado que também
tenha muitos canais grandes, provavelmente recomendará um tamanho de canal maior.
Como você pode ver, o autopilot do c-lightning não é tão automático quanto o do lnd, mas oferece
um pouco mais de controle. Essas diferenças refletem preferências pessoais e podem ser o fator
decisivo para você escolher uma implementação em detrimento da outra.
Lembre-se de que os autopilots atuais usarão principalmente informações públicas do protocolo de

gossip (divulgação) sobre a topologia atual da Lightning Network. É óbvio que seus requisitos
pessoais para canais só podem ser refletidos até certo grau. Autopilots mais avançados usariam
informações históricas e de uso que seu nó coletou ao ser executado no passado, incluindo
informações sobre o sucesso de roteamento, quem você pagou no passado e quem lhe pagou. No
futuro, esses pilotos automáticos aprimorados também podem usar esses dados coletados para
fazer recomendações sobre o fechamento de canais e a realocação de fundos.
No geral, no momento da escrita deste livro, tenha cuidado para não depender ou confiar demais
nos pilotos automáticos.
Obtendo Liquidez de Entrada
No design atual da Lightning Network, é mais comum para os usuários obterem liquidez de saída
(outbound liquidity) antes de obterem liquidez de entrada (inbound liquidity). Eles farão isso
abrindo um canal com outro nó, e muitas vezes eles poderão gastar bitcoin antes de poderem
recebê-lo. Existem três maneiras típicas de obter liquidez de entrada:
• Abrir um canal com liquidez de saída e, em seguida, gastar parte desses fundos. Agora o saldo
está no outro lado do canal, o que significa que você pode receber pagamentos.
• Peça a alguém para abrir um canal para o seu nó. Ofereça-se para retribuir, para que ambos os
nós fiquem mais conectados e equilibrados.
• Use uma transação submarina (por exemplo, Loop In) para trocar BTC na blockchain por um
canal de entrada para o seu nó.
• Pague um serviço de terceiros para abrir um canal com você. Existem vários desses serviços
disponíveis. Alguns cobram uma taxa para fornecer liquidez, enquanto outros são gratuitos.
Aqui está uma lista de provedores de liquidez atualmente disponíveis que abrirão um canal para o
seu nó mediante o pagamento de uma taxa:
32
• Bitrefill’s Thor service
• Lightning To Me
• LNBig
• Lightning Conductor
Criar liquidez de entrada é desafiador tanto do ponto de vista prático quanto da experiência do
usuário. A liquidez de entrada não ocorre automaticamente, portanto, você precisa encontrar
maneiras de construí-la para o seu nó. Essa assimetria dos canais de pagamento também não é
intuitiva. Na maioria dos outros sistemas de pagamento, você é pago primeiro (entrada) antes de
pagar aos outros (saída).
O desafio de criar liquidez entrante é mais perceptível se você é um comerciante ou vende seus
serviços aceitando pagamentos em Lightning. Nesse caso, é preciso estar atento para garantir que
você tenha liquidez suficiente para receber pagamentos continuamente. E se houver um aumento
repentino de compradores em sua loja, mas eles não puderem efetuar o pagamento devido à falta
de capacidade de entrada?
No futuro, esses desafios podem ser parcialmente mitigados pela implementação de canais com
financiamento duplo, que são financiados de ambos os lados e oferecem capacidade equilibrada
tanto para receber quanto para enviar pagamentos. O ônus também pode ser reduzido com o uso
de software de autopilot mais sofisticado, que poderia solicitar e pagar por capacidade entrante
conforme necessário.
Em última análise, os usuários da Lightning precisam ser estratégicos e proativos em relação à

gestão de canais para garantir que haja capacidade entrante suficiente para atender às suas
necessidades.
Fechando Canais
Como discutido anteriormente no livro, um fechamento mútuo é a forma preferida de encerrar um

canal.No entanto, existem casos em que um fechamento forçado é necessário.
Alguns exemplos:
• Seu parceiro de canal está offline e não pode ser contatado para iniciar um fechamento mútuo.
• Seu parceiro de canal está online, mas não está respondendo às solicitações para iniciar um
fechamento mútuo.
• Seu parceiro de canal está online e seus nós estão negociando um fechamento mútuo, mas eles
ficam presos e não conseguem chegar a uma resolução.
Reequilibrando Canais
Ao realizar transações e rotear pagamentos na Lightning, a combinação de capacidades de entrada

e saída pode se tornar desequilibrada.
Por exemplo, se um dos seus parceiros de canal estiver roteando frequentemente pagamentos
através do seu nó, você esgotará a capacidade de entrada nesse canal, ao mesmo tempo em que
esgota a capacidade de saída nos canais de saída. Uma vez que isso acontece, você não poderá mais
33
rotear pagamentos por meio desse caminho.
Existem várias maneiras de reequilibrar os canais, cada uma com vantagens e desvantagens
diferentes. Uma forma é utilizar um submarine swap (por exemplo, Loop Out), como descrito
anteriormente neste capítulo. Outra forma de reequilibrar é simplesmente esperar por pagamentos
roteados que fluem na direção oposta. Se o seu nó estiver bem conectado, quando um caminho
específico se esgota em uma direção, o mesmo caminho se torna disponível na direção oposta.
Outros nós podem "descobrir" esse caminho na direção oposta e começar a usá-lo como parte do
caminho de pagamento, reequilibrando assim os fundos novamente.
Uma terceira forma de reequilibrar os canais é criar intencionalmente uma rota circular que envia
um pagamento do seu nó de volta para o seu próprio nó, através da Lightning Network. Ao enviar
um pagamento por um canal com grande capacidade local e organizar o caminho de forma que ele
retorne ao seu nó por um canal com grande capacidade remota, ambos os canais ficarão mais
equilibrados. Um exemplo de estratégia de reequilíbrio por rota circular pode ser visto na
Reequilíbrio por rota circular.
Figure 4. Reequilíbrio por rota circular
O reequilíbrio circular é suportado pela maioria das implementações de nós da Lightning e pode
ser feito através da linha de comando ou por meio de uma das interfaces de gerenciamento web,
como o Ride The Lightning (see Ride The Lightning).
O reequilíbrio de canais é uma questão complexa que é objeto de pesquisa ativa e é abordado com
mais detalhes em Reequilibrando Canais.
Taxas de Roteamento
Executar um nó Lightning permite que você ganhe taxas ao encaminhar pagamentos através dos
34
seus canais. No entanto, as taxas de roteamento geralmente não representam uma fonte
significativa de renda e são insignificantes em comparação com os custos de operação de um nó.
Por exemplo, em um nó relativamente movimentado que encaminha uma dúzia de pagamentos por
dia, as taxas podem chegar a no máximo 2.000 satoshis.
Os nós competem pelas taxas de roteamento ao definir a taxa desejada em cada canal. As taxas de
roteamento são definidas por dois parâmetros em cada canal: uma taxa base fixa que é cobrada
para qualquer pagamento e uma taxa de tarifa adicional variável proporcional ao valor do
pagamento.
Ao enviar um pagamento na Lightning, um nó selecionará um caminho de forma a minimizar as

taxas, minimizar os saltos ou ambos. Como resultado, surge um mercado de taxas de roteamento a
partir dessas interações. Atualmente, existem muitos nós que cobram taxas muito baixas ou
nenhuma taxa pelo roteamento, criando uma pressão negativa no mercado de taxas de roteamento.
Se você não fizer escolhas, o seu nó Lightning definirá uma taxa base e uma taxa de tarifa adicional
padrão para cada novo canal. Os valores padrão dependem da implementação do nó que você está
usando. A taxa base é definida na unidade de millisatoshi (milésimos de um satoshi). A taxa de
tarifa proporcional é definida na unidade de milionésimos e é aplicada ao valor do pagamento. A
unidade de milionésimos é frequentemente abreviada com ppm (partes por milhão). Por exemplo,
uma taxa base de 1.000 (millisatoshi) e uma taxa proporcional de 1.000 ppm (milionésimos)
resultariam nas seguintes cobranças para um pagamento de 100.000 satoshis:
\begin{equation}
\begin{aligned}
P &= 100,000 \text{ satoshi} \\
F_{base} &= 1,000 \text{ millisatoshi} = 1 \text{ satoshi} \\
F_{rate} &= 1,000 \text{ ppm} = 1,000/1,000,000 = 1/1,000 = \text{0.001} = 0.1\%
\\
F_{total} &= F_{base} + ( P * F_{rate} ) \\
\Rightarrow F_{total} &= 1 \text{ satoshi} + ( 100,000/1,000 ) \text{ satoshi}
\\
\Rightarrow F_{total} &= 1 \text{ satoshi} + 100 \text{ satoshi} = 101 \text{
satoshi} \\
\end{aligned}
\end{equation}
De uma forma geral, você pode adotar uma de duas abordagens em relação às taxas de roteamento.
Você pode rotear muitos pagamentos com taxas baixas, compensando as baixas taxas com um alto
volume. Alternativamente, você pode optar por cobrar taxas mais altas. Se você escolher definir
taxas mais altas, seu nó será selecionado apenas quando outras rotas mais baratas não estiverem
disponíveis. Portanto, você roteará com menos frequência, mas ganhará mais por cada roteamento
bem-sucedido.
Para a maioria dos nós, geralmente é melhor usar os valores padrão das taxas de roteamento. Dessa
forma, seu nó estará competindo em um campo de jogo mais equilibrado com outros nós que
também usam os valores padrão.
Você também pode usar as configurações das taxas de roteamento para rebalancear canais. Se a
35
maioria dos seus canais tiver as taxas padrão, mas você deseja rebalancear um canal específico,
basta diminuir as taxas nesse canal específico para zero ou para valores muito baixos. Em seguida,
aguarde alguém rotear um pagamento por sua rota "barata" e rebalancear seus canais como um
efeito colateral.
Gestão de Nó
Gerenciar seu nó Lightning na linha de comando obviamente não é fácil. Isso oferece a você a
flexibilidade total da API do nó e a capacidade de escrever seus próprios scripts personalizados
para atender aos seus requisitos pessoais. Mas se você não deseja lidar com a complexidade da
linha de comando e só precisa de algumas capacidades básicas de gerenciamento de nó, considere
instalar uma interface de usuário baseada na web que facilite o gerenciamento do nó.
Existem vários projetos concorrentes que oferecem gerenciamento de nó Lightning baseado na

web. Alguns dos mais populares são descritos na seção a seguir.
Ride The Lightning
Ride The Lightning (RTL) é uma interface gráfica baseada na web que ajuda os usuários a gerenciar
as operações de nós Lightning para as três principais implementações de nós Lightning (LND, c-
lightning e Eclair). O RTL é um projeto de código aberto desenvolvido por Shahana Farooqui e
muitos outros colaboradores. Você pode encontrar o software RTL em GitHub.
Exemplo de interface da Web RTL apresenta uma captura de tela de exemplo da interface web do
RTL, conforme fornecida no repositório do projeto.
Figure 5. Exemplo de interface da Web RTL
lndmon
Lightning Labs, os criadores do LND, fornecem uma interface gráfica baseada na web chamada
lndmon para monitorar as várias métricas de um nó Lightning LND. O lndmon só funciona com nós
LND. É uma interface somente leitura para monitoramento e, portanto, não permite gerenciar
ativamente o nó. Não é possível abrir canais ou realizar pagamentos. Encontre o lndmon em
36
GitHub.
ThunderHub
ThunderHub é uma interface gráfica baseada na web muito atraente, semelhante ao RTL, mas
exclusiva para o LND. Ela pode ser usada para fazer pagamentos, rebalancear canais e gerenciar o
nó por meio de uma variedade de recursos.
Conclusão
À medida que você mantém seu nó e adquire experiência, você aprenderá muito sobre a Lightning
Network. Ser um operador de nó é uma tarefa desafiadora, mas gratificante. Dominar essas
habilidades permitirá que você contribua para o crescimento e desenvolvimento dessa tecnologia e
da própria Lightning Network. Além disso, você terá a capacidade de enviar e receber pagamentos
na Lightning com o maior grau de controle e facilidade. Você desempenhará um papel central na
infraestrutura da rede e não apenas será um participante nas bordas.
37
Arquitetura de Rede Relâmpago
Na primeira parte deste livro, introduzimos os principais conceitos da Lightning Network e
trabalhamos em um exemplo abrangente de roteamento de um pagamento e configuração das
ferramentas que podemos usar para explorar mais a fundo. Na segunda parte do livro,
exploraremos a Lightning Network com muito mais detalhes técnicos, dissecando cada um dos
elementos fundamentais.
Nesta seção, iremos detalhar os componentes da Lightning Network de forma mais precisa e
fornecer uma visão geral para orientá-lo(a) ao longo dos capítulos seguintes.
O Conjunto de Protocolos de Rede Relâmpago

A Lightning Network é composta por uma coleção complexa de protocolos que funcionam sobre a
internet. Podemos classificar amplamente esses protocolos em cinco camadas distintas que
compõem uma pilha de protocolos, onde cada camada é construída sobre e utiliza os protocolos da
camada inferior. Além disso, cada camada de protocolo abstrai as camadas subjacentes e "oculta"
parte da complexidade.
A diagrama de arquitetura mostrado na O conjunto de protocolos da Rede Relâmpago fornece uma

visão geral dessas camadas e seus protocolos componentes.
Figure 1. O conjunto de protocolos da Rede Relâmpago
As cinco camadas da Lightning Network, de baixo para cima, são:
Camada de conexão de rede

Esta camada contém os protocolos que interagem diretamente com os protocolos principais da
internet (TCP/IP), protocolos de sobreposição (Tor v2/v3) e serviços da internet (DNS). Esta
camada também contém os protocolos de transporte criptográfico que protegem as mensagens
Lightning.
1
Camada de mensagens: Esta camada contém os protocolos que os nós usam para negociar recursos,
formatar mensagens e codificar campos de mensagens.
Camada peer-to-peer (P2P)

Esta camada é a principal camada de protocolo para comunicação entre os nós do Lightning e
contém todas as diferentes mensagens trocadas entre os nós.
Camada de roteamento
Esta camada contém os protocolos usados para rotear pagamentos entre nós, de ponta a ponta e
atomicamente. Esta camada contém a funcionalidade principal da Lightning Network:
pagamentos roteados.
Camada de pagamento
A camada mais alta da rede, que apresenta uma interface de pagamento confiável para
aplicativos.
Lightning em Detalhes
Pelos próximos 10 capítulos, vamos analisar o conjunto de protocolos e examinar cada componente
da Lightning Network em detalhes.
Passamos bastante tempo tentando decidir a melhor ordem de apresentar esses detalhes. Não é
uma escolha fácil porque há muita interdependência entre os diferentes componentes: quando
você começa a explicar um, percebe que ele envolve vários outros componentes. Em vez de uma
abordagem de cima para baixo ou de baixo para cima, acabamos escolhendo um caminho mais
sinuoso que começa com os blocos fundamentais mais importantes, que são exclusivos da
Lightning Network—Canais de Pagamento—e se expande a partir daí. Mas como esse caminho não
é óbvio, usaremos o Conjunto de Protocolos da Lightning mostrado na O conjunto de protocolos da
Rede Relâmpago como um mapa. Em cada capítulo, vamos nos concentrar em um ou mais
componentes relacionados, e você os verá destacados no conjunto de protocolos. É como um
marcador de mapa dizendo "Você está aqui!"
Aqui está o que vamos cobrir:
<a data-type="xref" href="payment_channels" data-xrefstyle="chap-num-

title">#payment_channels</a>
Neste capítulo, vamos explorar em mais detalhes como os canais de pagamento funcionam, de
forma significativamente mais aprofundada do que vimos nas partes anteriores do livro. Vamos
examinar a estrutura e o Bitcoin Script das transações de financiamento e compromisso, bem
como o processo usado pelos nós para negociar cada etapa do protocolo.
<a data-type="xref" href="#routing" data-xrefstyle="chap-num-title">#routing</a>

Em seguida, iremos montar vários canais de pagamento em uma rede e rotear um pagamento de
uma ponta à outra. Nesse processo, vamos mergulhar no contrato inteligente hash time-locked
contract (HTLC) e no Bitcoin Script que usamos para construí-lo.
<a data-type="xref" href="#channel_operation" data-xrefstyle="chap-num-

title">#channel_operation</a>
2
Ao juntar os conceitos de um canal de pagamento simples e um pagamento roteado usando
HTLCs, vamos agora analisar como os HTLCs fazem parte da transação de compromisso de cada
canal. Também examinaremos o protocolo para adicionar, liquidar, falhar e remover HTLCs dos
compromissos.
<a data-type="xref" href="#onion_routing" data-xrefstyle="chap-num-

title">#onion_routing</a>
A seguir, vamos analisar como as informações do HTLC são propagadas pela rede dentro do
protocolo de roteamento onion. Vamos observar o mecanismo de criptografia e descriptografia
em camadas que confere à Lightning Network algumas de suas características de privacidade.
<a data-type="xref" href="#gossip" data-xrefstyle="chap-num-title">#gossip</a>

Neste capítulo, vamos analisar como os nós da Lightning Network se encontram e aprendem
sobre os canais publicados para construir um grafo de canais que podem ser usados para
encontrar caminhos pela rede.
<a data-type="xref" href="#path_finding" data-xrefstyle="chap-num-title">>#path_finding</a>

Em seguida, veremos como as informações do protocolo de divulgação são usadas por cada nó
para construir um "mapa" de toda a rede, que pode ser usado para encontrar caminhos de um
ponto a outro para rotear pagamentos. Também analisaremos as inovações existentes no
roteamento de caminhos, como os pagamentos multipartes.
<a data-type="xref" href="#wire_protocol" data-xrefstyle="chap-num-

title">#wire_protocol</a>
A base da Rede Relâmpago é o protocolo peer-to-peer que os nós usam para trocar mensagens
sobre a rede e seus canais. Neste capítulo, vamos ver como essas mensagens são construídas e as
capacidades de extensão incorporadas nas mensagens, com bits de recursos e codificação Type-
Length-Value (TLV).
<a data-type="xref" href="#encrypted_message_transport" data-xrefstyle="chap-num-

title">#encrypted_message_transport</a>
Descendo para a parte mais baixa da rede, vamos examinar o sistema de transporte
criptografado subjacente que garante o sigilo e a integridade de todas as comunicações entre os
nós.
<a data-type="xref" href="#invoices" data-xrefstyle="chap-num-title">#invoices</a>

Uma parte fundamental da Lightning Network são as solicitações de pagamento, também
conhecidas como faturas Lightning. Neste capítulo, vamos analisar a estrutura e codificação de
uma fatura.
Vamos mergulhar!
3
Canais de Pagamento
Neste capítulo, iremos explorar os canais de pagamento e ver como eles são construídos. Vamos
começar com o nó da Alice abrindo um canal para o nó do Bob, com base nos exemplos
apresentados no início deste livro.
As mensagens trocadas pelos nós da Alice e do Bob são definidas em "BOLT #2: Peer Protocol for
Channel Management". As transações criadas pelos nós da Alice e do Bob são definidas em "BOLT
#3: Bitcoin Transaction and Script Formats". Neste capítulo, estamos focando nas partes "Abrir e
Fechar Canais" e "Máquina de Estado de Canal" da arquitetura do protocolo Lightning, destacadas
por um desenho no centro (camada peer-to-peer) na Canais de pagamento no conjunto de
protocolos Lightning.
Figure 1. Canais de pagamento no conjunto de protocolos Lightning
Uma Forma Diferente de Usar o Sistema Bitcoin

A Rede Relâmpago é frequentemente descrita como um "Protocolo Bitcoin de Camada 2", o que a
faz parecer distinta do Bitcoin. Outra forma de descrever a Lightning é como uma "maneira mais
inteligente de usar o Bitcoin" ou simplesmente como uma "aplicação sobre o Bitcoin". Vamos
explorar isso.
Historicamente, as transações de Bitcoin são transmitidas para todos e registradas na blockchain do

Bitcoin para serem consideradas válidas. No entanto, como veremos, se alguém possuir uma
transação de Bitcoin pré-assinada que gaste uma saída 2-de-2 de múltiplas assinaturas (multisig)
que lhes dê a capacidade exclusiva de gastar aquele Bitcoin, essa pessoa efetivamente possui aquele
Bitcoin, mesmo que não transmita a transação.
Você pode pensar na transação de Bitcoin pré-assinada como um cheque pré-datado, que pode ser
descontado a qualquer momento. Ao contrário do sistema bancário tradicional, no entanto, essa
transação não é uma "promessa" de pagamento (também conhecida como IOU - I Owe You), mas um
1
instrumento de pagamento verificável que é equivalente a dinheiro. Desde que o bitcoin
mencionado na transação não tenha sido gasto no momento do resgate (ou no momento em que
você tenta "descontar" o cheque), o sistema Bitcoin garante que essa transação pré-assinada possa
ser transmitida e registrada a qualquer momento. Isso é verdade apenas, é claro, se esta for a única
transação pré-assinada. Dentro da Lightning Network, duas ou mais transações pré-assinadas desse
tipo existem ao mesmo tempo; portanto, precisamos de um mecanismo mais sofisticado para ainda
ter a funcionalidade desse instrumento de pagamento verificável, como você também aprenderá
neste capítulo.
A Rede Relâmpago é simplesmente uma maneira diferente e criativa de usar o Bitcoin. Na Rede
Relâmpago, uma combinação de transações registradas (on-chain) e transações pré-assinadas,
porém retidas (off-chain), formam uma "camada" de pagamentos que é uma forma mais rápida,
barata e privada de utilizar o Bitcoin. Você pode observar essa relação entre as transações de
Bitcoin on-chain e off-chain na Canal de pagamento Lightning composto por transações on-chain e
off-chain.
Figure 2. Canal de pagamento Lightning composto por transações on-chain e off-chain
Relâmpago (ou Lightning) é Bitcoin. É apenas uma maneira diferente de usar o sistema Bitcoin.
Propriedade e Controle do Bitcoin

Antes de entendermos os canais de pagamento, precisamos dar um pequeno passo atrás e entender
como a propriedade e o controle funcionam no Bitcoin.
Quando alguém diz que "possui" bitcoins, geralmente significa que eles conhecem a chave privada
de um endereço de Bitcoin que possui algumas saídas de transações não gastas (see
[bitcoin_fundamentals_review]). A chave privada permite que eles assinem uma transação para
gastar esses bitcoin, transferindo-os para um endereço diferente. No Bitcoin, a "posse" de bitcoin
pode ser definida como a capacidade de gastar esses bitcoin.
2
É importante ressaltar que o termo "posse", conforme utilizado no Bitcoin, é distinto do termo
"posse" utilizado no sentido legal. Um ladrão que possui as chaves privadas e pode gastar bitcoin é
um proprietário de fato desses bitcoin, mesmo que não seja um proprietário legal.
A posse de bitcoin é somente sobre o controle das chaves e à capacidade de gastar o bitcoin
com essas chaves. Como diz o famoso ditado do Bitcoin: "Suas chaves, suas moedas—não são
suas chaves, não são suas moedas."
Diversidade de Propriedade (Independente) e Multisig
A propriedade e o controle das chaves privadas nem sempre estão nas mãos de uma única pessoa. É
aí que as coisas se tornam interessantes e complicadas. Sabemos que mais de uma pessoa pode vir
a conhecer a mesma chave privada, seja por meio de roubo ou porque o detentor original da chave
faz uma cópia e a dá a outra pessoa. Todos esses indivíduos são proprietários? Em um sentido
prático, sim, porque qualquer uma das pessoas que conhece a chave privada pode gastar os bitcoin
sem a aprovação de outras pessoas.
O Bitcoin também possui endereços de múltiplas assinaturas (multisig), nos quais são necessárias
várias chaves privadas para assinar antes de gastar (see [multisig]). Do ponto de vista prático, a
propriedade em um endereço de múltiplas assinaturas depende do quórum (K) e do total (N)
definido no esquema K-de-N. Um esquema 1-de-10 em multisig permitiria que qualquer 1 (K) dos 10
(N) signatários assinasse para gastar uma quantidade de bitcoin bloqueada nesse endereço. Isso é
semelhante ao cenário em que 10 pessoas possuem uma cópia da mesma chave privada e qualquer
uma delas pode gastá-la independentemente.
Propriedade Conjunta Sem Controle Independente
Também existe o cenário em que ninguém possui o quórum. Em um esquema 2-de-2, como o
utilizado na Lightning Network, nenhum dos signatários pode gastar os bitcoin sem obter uma
assinatura da outra parte. Quem possui os bitcoin nesse caso? Na realidade, ninguém possui a
propriedade porque ninguém tem controle. Cada parte possui o equivalente a uma cota de voto na
decisão, mas ambos os votos são necessários. Um problema chave (com trocadilho) com um
esquema 2-de-2, tanto no Bitcoin quanto na lei, é o que acontece se uma das partes não estiver
disponível, ou se houver um impasse na votação e qualquer uma das partes se recusar a cooperar.
Prevenindo Bitcoin "Bloqueado" e Não-Gastável
Se um dos dois signatários de uma multisig 2-de-2 não puder ou não quiser assinar, os fundos se
tornam não gastáveis. Esse cenário não ocorre apenas por acidente (perda das chaves), mas
também pode ser usado como uma forma de chantagem por qualquer uma das partes: "Eu não vou
assinar a menos que você me pague uma parte dos fundos".
Os canais de pagamento na Lightning são baseados em um endereço multisig 2-de-2, com os dois
parceiros do canal como signatários do multisig. No momento, os canais são financiados apenas por
um dos dois parceiros do canal: quando você escolhe "abrir" um canal, você deposita fundos no
endereço multisig 2-de-2 por meio de uma transação. Assim que essa transação for minerada e os
fundos estiverem no multisig, você não poderá recuperá-los sem a cooperação do seu parceiro do
3
canal, pois você precisa da assinatura deles (também) para gastar os bitcoin.
Na próxima seção, ao analisarmos como abrir (criar) um canal Relâmpago, veremos como podemos
evitar a perda de fundos ou qualquer cenário de chantagem entre os dois parceiros,
implementando um protocolo de justiça para a construção do canal com a ajuda de transações pré-
assinadas que gastam a saída multisig de forma que os pares no canal tenham a capacidade
exclusiva de gastar uma das saídas, que codifica a quantidade de bitcoin que eles possuem no
canal.
Construindo um Canal de Pagamento

Em [what_is_payment_channel], descrevemos os canais de pagamento como uma relação financeira
entre dois nós da Lightning, que é estabelecida através do financiamento de um endereço multisig
2-de-2 pelos dois parceiros do canal.
Vamos supor que Alice queira construir um canal de pagamento que lhe permita se conectar
diretamente à loja do Bob. Primeiro, os dois nós (o de Alice e o de Bob) precisam estabelecer uma
conexão de internet entre si, para que possam negociar um canal de pagamento.
Chaves Privadas e Públicas do Nó
Cada nó na Lightning Network é identificado por uma chave pública do nó. A chave pública
identifica exclusivamente o nó específico e geralmente é apresentada como uma codificação
hexadecimal. Por exemplo, René Pickhardt atualmente executa um nó da Lightning (ln.rene-
pickhardt.de) que é identificado pela seguinte chave pública do nó:
02a1cebfacb2674143b5ad0df3c22c609e935f7bc0ebe801f37b8e9023d45ea7b8
Cada nó gera uma chave privada raiz quando é inicializado pela primeira vez. A chave privada é
mantida em sigilo o tempo todo (nunca compartilhada) e armazenada com segurança na carteira
do nó. A partir dessa chave privada, o nó deriva uma chave pública que é o identificador do nó e é
compartilhada com a rede. Como o espaço de chaves é enorme, desde que cada nó gere a chave
privada aleatoriamente, ele terá uma chave pública única, o que permite identificá-lo de forma
exclusiva na rede.
Endereço de Rede do Nó
Além disso, cada nó também anuncia um endereço de rede pelo qual ele pode ser alcançado, em
um dos vários formatos possíveis:
TCP/IP
Um endereço IPv4 ou IPv6 e número da porta TCP
TCP/Tor
Um endereço "onion" Tor e número de porta TCP
O identificador de endereço de rede é escrito como Address:Port, o que é consistente com os
4
padrões internacionais para identificadores de rede, como utilizados, por exemplo, na web.
Por exemplo, o nó de René com a chave pública do nó 02a1ceb...45ea7b8 atualmente anuncia seu
endereço de rede como o endereço TCP/IP:
172.16.235.20:9735
A porta TCP padrão para a Lightning Network é 9735, mas um nó pode optar por escutar em
qualquer porta TCP.
Identificadores de Nó
Juntos, a chave pública do nó e o endereço de rede são escritos no seguinte formato, separados por
um sinal de @, como NodeID@Address:Port.
Portanto, o identificador completo do nó de René seria:
02a1cebfacb2674143b5ad0df3c22c609e935f7bc0ebe801f37b8e9023d45ea7b8
@172.16.235.20:9735
O alias do nó de René é ln.rene-pickhardt.de; no entanto, esse nome existe apenas para melhor
legibilidade. Todo operador de nó pode anunciar o alias que desejar, e não há um mecanismo
que impeça os operadores de nós de selecionar um alias que já esteja sendo usado. Portanto,
para se referir a um nó, é necessário usar o esquema NodeID@Address:Port.
O identificador mencionado anteriormente é frequentemente codificado em um código QR,

tornando mais fácil para os usuários escaneá-lo caso queiram conectar seu próprio nó ao nó
específico identificado por esse endereço.
Assim como os nós do Bitcoin, os nós da Relâmpago anunciam sua presença na Rede Relâmpago
por meio do "gossiping" (divulgação) de sua chave pública do nó e endereço de rede. Dessa forma,
outros nós podem encontrá-los e manter um inventário (banco de dados) de todos os nós
conhecidos aos quais podem se conectar e trocar mensagens definidas no protocolo de mensagens
P2P da Lightning.
Conectando Nós como Pares Diretos
Para que o nó da Alice se conecte ao nó do Bob, ela precisará da chave pública do nó do Bob ou do
endereço completo contendo a chave pública, o endereço IP ou Tor e a porta. Como o Bob possui
uma loja, o endereço do nó do Bob pode ser obtido a partir de uma fatura ou página de pagamento
da loja na web. A Alice pode escanear um código QR que contenha o endereço e instruir seu nó a se
conectar ao nó do Bob.
Uma vez que Alice se conectou ao nó de Bob, seus nós agora são pares diretamente conectados.
5
Para abrir um canal de pagamento, dois nós devem primeiro estar conectados como pares
diretos, estabelecendo uma conexão pela internet (ou Tor).
Construindo o Canal
Agora que os nós da Alice e do Bob na Lightning estão conectados, eles podem iniciar o processo de
construção de um canal de pagamento. Nesta seção, iremos revisar as comunicações entre seus nós,
conhecidas como o Protocolo de Pares da Lightning para Gerenciamento de Canais, e o protocolo
criptográfico que eles usam para construir transações Bitcoin.
Descrevemos dois protocolos diferentes nesse cenário. Primeiro, há um protocolo de

mensagens, que estabelece como os nós da Lightning se comunicam pela internet e quais
mensagens eles trocam entre si. Segundo, há o protocolo criptográfico, que estabelece como os
dois nós constroem e assinam transações de Bitcoin.
Protocolo de Pares para Gerenciamento de Canal
O Protocolo de Pares da Lightning para o Gerenciamento de Canais é definido em BOLT #2: Peer
Protocol for Channel Management. Neste capítulo, iremos revisar com mais detalhes as seções
"Estabelecimento do Canal" e "Fechamento do Canal" do BOLT #2.
Fluxo de Mensagens de Estabelecimento do Canal
O estabelecimento do canal é alcançado por meio da troca de seis mensagens entre os nós da Alice e
do Bob (três de cada peer): open_channel, accept_channel, funding_created, funding_signed,
funding_locked e funding_locked. As seis mensagens são mostradas como um diagrama de
sequência temporal na O fluxo de mensagens de estabelecimento de canal.
6
Figure 3. O fluxo de mensagens de estabelecimento de canal
Na O fluxo de mensagens de estabelecimento de canal, os nós da Alice e do Bob são representados

pelas linhas verticais "A" e "B" em cada lado do diagrama. Um diagrama de sequência temporal
como esse mostra o tempo fluindo para baixo e as mensagens fluindo de um lado para o outro entre
os dois pares de comunicação. As linhas são inclinadas para baixo para representar o tempo
decorrido necessário para transmitir cada mensagem, e a direção da mensagem é mostrada por
uma seta no final de cada linha.
O estabelecimento do canal envolve três partes. Primeiro, os dois pares de comunicação

comunicam suas capacidades e expectativas, com Alice iniciando uma solicitação por meio de
open_channel e Bob aceitando a solicitação do canal por meio de accept_channel.
Em segundo lugar, Alice constrói as transações de financiamento e reembolso (conforme veremos

posteriormente nesta seção) e envia funding_created para Bob. Outro nome para a transação
"reembolso" é uma transação de "compromisso", pois ela se compromete com a distribuição atual
dos saldos no canal. Bob responde enviando de volta as assinaturas necessárias com
funding_signed. Essa interação é a base do protocolo criptográfico para garantir a segurança do
canal e evitar roubos. Agora, Alice irá transmitir a transação de financiamento (on-chain) para
estabelecer e ancorar o canal de pagamento. A transação precisará ser confirmada na blockchain
do Bitcoin.
O nome da mensagem funding_signed pode ser um pouco confuso. Essa mensagem não
contém uma assinatura para a transação de financiamento, mas sim contém a assinatura de
7
Bob para a transação de reembolso que permite que Alice recupere seus bitcoin da multisig.
Uma vez que a transação tenha confirmações suficientes (conforme definido pelo campo
minimum_depth na mensagem accept_channel), Alice e Bob trocam mensagens funding_locked e o
canal entra no modo de operação normal.
A mensagem open_channel
O nó da Alice solicita um canal de pagamento com o nó do Bob enviando uma mensagem

open_channel. A mensagem contém informações sobre as expectativas da Alice para a configuração
do canal, que o Bob pode aceitar ou recusar.
A estrutura da mensagem open_channel (retirada do BOLT #2) é mostrada no A mensagem

open_channel.
Example 1. A mensagem open_channel
[chain_hash:chain_hash]
[32*byte:temporary_channel_id]
[u64:funding_satoshis]
[u64:push_msat]
[u64:dust_limit_satoshis]
[u64:max_htlc_value_in_flight_msat]
[u64:channel_reserve_satoshis]
[u64:htlc_minimum_msat]
[u32:feerate_per_kw]
[u16:to_self_delay]
[u16:max_accepted_htlcs]
[point:funding_pubkey]
[point:revocation_basepoint]
[point:payment_basepoint]
[point:delayed_payment_basepoint]
[point:htlc_basepoint]
[point:first_per_commitment_point]
[byte:channel_flags]
[open_channel_tlvs:tlvs]
Os campos contidos nessa mensagem especificam os parâmetros do canal que Alice deseja, assim
como várias configurações do nó da Alice que refletem as expectativas de segurança para a
operação do canal.
Alguns dos parâmetros de construção do canal estão listados aqui:
chain_hash
Isso identifica qual blockchain (por exemplo, Bitcoin mainnet) será usada para esse canal.
Geralmente, é o hash do bloco de gênese dessa blockchain.
8
funding_satoshis
A quantidade que Alice usará para financiar o canal, que é a capacidade total do canal.
channel_reserve_satoshis
O saldo mínimo, em satoshis, reservado em cada lado de um canal. Voltaremos a esse ponto
quando falarmos sobre penalidades.
push_msat
Um valor opcional que Alice irá "empurrar" imediatamente para Bob como um pagamento ao
financiar o canal. Definir esse valor como qualquer coisa diferente de 0 significa efetivamente
presentear dinheiro ao seu parceiro de canal e deve ser usado com cautela.
to_self_delay
Um parâmetro de segurança muito importante para o protocolo. O valor na mensagem
open_channel é usado na transação de compromisso do respondente, e o valor accept_channel na
do iniciador. Essa assimetria existe para permitir que cada lado expresse por quanto tempo o
outro lado precisa esperar para reivindicar unilateralmente os fundos em uma transação de
compromisso. Se Bob, a qualquer momento, fechar unilateralmente o canal contra a vontade de
Alice, ele se compromete a não acessar seus próprios fundos pelo atraso definido aqui. Quanto
maior esse valor, mais segurança Alice tem, mas mais tempo Bob pode ter seus fundos
bloqueados.
funding_pubkey
A chave pública que Alice contribuirá para o multisig 2-de-2 que ancorará este canal.
X_basepoint
Chaves mestras, usadas para derivar chaves filhas para várias partes das transações de
compromisso, revogação, pagamento roteado (HTLCs) e transações de fechamento. Elas serão
usadas e explicadas nos capítulos subsequentes.
Se você deseja entender os outros campos e mensagens do protocolo de pares da Lightning que
não discutimos neste livro, sugerimos que você os consulte nas especificações BOLT. Essas
mensagens e campos são importantes, mas não podem ser abordados com detalhes suficientes
no escopo deste livro. Queremos que você entenda os princípios fundamentais o suficiente
para que possa preencher os detalhes lendo a especificação do protocolo (BOLTs).
A mensagem accept_channel
Em resposta à mensagem open_channel de Alice, Bob envia de volta a mensagem accept_channel

mostrada no A mensagem accept_channel.
Example 2. A mensagem accept_channel
[u64:dust_limit_satoshis]
[u64:max_htlc_value_in_flight_msat]
[u64:channel_reserve_satoshis]
9
[u64:htlc_minimum_msat]
[u32:minimum_depth]
[u16:to_self_delay]
[u16:max_accepted_htlcs]
[point:funding_pubkey]
[point:revocation_basepoint]
[point:payment_basepoint]
[point:delayed_payment_basepoint]
[point:htlc_basepoint]
[point:first_per_commitment_point]
[accept_channel_tlvs:tlvs]
Como você pode ver, isso é semelhante à mensagem open_channel e contém as expectativas do nó
do Bob e os valores de configuração.
Os dois campos mais importantes em accept_channel que Alice usará para construir o canal de
pagamento são:
funding_pubkey
A chave pública que o nó do Bob contribui para o endereço multisig 2-de-2 que ancora o canal.
minimum_depth
O número de confirmações que o nó do Bob espera para a transação de financiamento antes de
considerar o canal "aberto" e pronto para uso.
A Transação de Financiamento
Assim que o nó da Alice recebe a mensagem accept_channel do Bob, ele tem as informações
necessárias para construir a transação de financiamento que ancora o canal na blockchain do
Bitcoin. Como discutido em capítulos anteriores, um canal de pagamento da Lightning é ancorado
por um endereço multisig 2-de-2. Primeiro, precisamos gerar esse endereço multi-assinatura para
nos permitir construir a transação de financiamento (e a transação de reembolso, conforme
descrito posteriormente).
Gerando um Endereço de Múltiplas Assinaturas
A transação de financiamento envia uma certa quantidade de bitcoin (funding_satoshis da

mensagem open_channel) para uma saída de multisig 2-de-2 que é construída a partir das chaves
públicas funding_pubkey de Alice e Bob.
O nó de Alice constrói um script de assinatura múltipla como mostrado aqui:
<pre data-type="programlisting">2 <Alice_funding_pubkey>

<Bob_funding_pubkey> 2 CHECKMULTISIG
</pre>
Note que, na prática, as chaves de financiamento são deterministicamente ordenadas (usando a

ordem lexicográfica da forma serializada e comprimida das chaves públicas) antes de serem
colocadas no script de testemunha. Ao concordar com essa ordem ordenada com antecedência,
10
garantimos que ambas as partes construirão uma saída de transação de financiamento idêntica,
que é assinada pela assinatura da transação de compromisso trocada.
Este script é codificado como um endereço Bitcoin Pay-to-Witness-Script-Hash (P2WSH), que se

parece com isso:
bc1q89ju02heg32yrqdrnqghe6132wek25p6sv6e564znvrvez7tq5zqt4dn02
Construindo a Transação de Financiamento
O nó da Alice agora pode construir uma transação de financiamento, enviando a quantidade

acordada com o Bob (funding_satoshis) para o endereço multisig 2-de-2. Vamos supor que
funding_satoshis seja 140.000 e a Alice esteja gastando uma saída de 200.000 satoshis e criando um
troco de 60.000 satoshis. A transação será algo parecido com: Alice constrói a transação de
financiamento.
Figure 4. Alice constrói a transação de financiamento
Alice não transmite essa transação porque fazê-lo colocaria seus 140.000 satoshis em risco. Uma vez
gastos para o multisig 2-de-2, não há como Alice recuperar seu dinheiro sem a assinatura de Bob.
Canais de Pagamento com Financiamento Duplo
Na implementação atual da Lightning, os canais são financiados apenas pelo nó que inicia o
canal (Alice em nosso exemplo). Canais de financiamento duplo (dual-funded) foram
propostos, mas ainda não foram implementados. Em um canal de financiamento duplo, tanto
Alice quanto Bob contribuiriam com inputs para a transação de financiamento. Canais de
financiamento duplo exigem um fluxo de mensagens e protocolo criptográfico um pouco
mais complexos, por isso ainda não foram implementados, mas estão planejados para uma
atualização futura nas especificações Lightning BOLTs. A implementação c-lightning inclui
uma versão experimental de uma variante de canais de financiamento duplo.
Segurando Transações Assinadas Sem Transmití-las
Uma característica importante do Bitcoin que possibilita a Lightning é a capacidade de construir e

assinar transações, mas não transmiti-las. A transação é válida em todos os aspectos, mas até ser
transmitida e confirmada na blockchain do Bitcoin, ela não é reconhecida e suas saídas não podem
11
ser gastas porque ainda não foram criadas na blockchain. Utilizaremos essa capacidade várias
vezes na Lightning Network, e o nó da Alice usa essa capacidade ao construir a transação de
financiamento: segurando-a e não a transmitindo ainda.
Reembolso Antes do Financiamento
Para evitar perda de fundos, Alice não pode colocar seus bitcoin em uma estrutura 2-de-2 até que
tenha uma forma de obter um reembolso caso algo dê errado. Essencialmente, ela deve planejar a
"saída" (exit) do canal antes de entrar nesse acordo.
Considere a construção legal de um acordo pré-nupcial, também conhecido como "prenup". Quando
duas pessoas se casam, seu dinheiro é vinculado legalmente (dependendo da jurisdição). Antes de
se casarem, eles podem assinar um acordo que especifica como separar seus bens caso dissolvam
seu casamento por meio de divórcio.
Podemos criar um acordo semelhante no Bitcoin. Por exemplo, podemos criar uma transação de
reembolso, que funciona como um acordo pré-nupcial, permitindo que as partes decidam como os
fundos em seu canal serão divididos antes que seus fundos sejam efetivamente bloqueados no
endereço de financiamento de múltiplas assinaturas.
Construindo a Transação de Reembolso Pré-assinada
Alice irá construir a transação de reembolso imediatamente após construir (mas não transmitir) a
transação de financiamento. A transação de reembolso gasta o valor do 2-de-2 multisig de volta
para a carteira de Alice.Chamamos essa transação de reembolso de uma transação de compromisso
porque ela compromete ambos os parceiros do canal a distribuir o saldo do canal de forma justa.
Como Alice financiou o canal sozinha, ela recebe o saldo inteiro, e tanto Alice quanto Bob se
comprometem a reembolsar Alice com essa transação.
Na prática, é um pouco mais complicado, como veremos nos próximos capítulos, mas por enquanto
vamos simplificar e assumir que se parece com Alice também constrói a transação de reembolso.
Figure 5. Alice também constrói a transação de reembolso
12
Mais adiante neste capítulo, veremos como mais transações de compromisso podem ser feitas para
distribuir o saldo do canal em quantidades diferentes.
Encadeando Transações Sem Transmití-las
Portanto, agora Alice construiu as duas transações mostradas na Alice também constrói a transação
de reembolso. Mas você pode estar se perguntando como isso é possível. Alice ainda não transmitiu
a transação de financiamento para a blockchain do Bitcoin. Para todos na rede, essa transação não
existe. A transação de reembolso é construída de forma a gastar uma das saídas da transação de
financiamento, mesmo que essa saída ainda não exista. Como é possível gastar uma saída que
ainda não foi confirmada na blockchain do Bitcoin?
A transação de reembolso ainda não é uma transação válida. Para que ela se torne válida, duas
coisas devem acontecer:
• A transação de financiamento deve ser transmitida para a rede Bitcoin. (Para garantir a
segurança da Lightning Network, também exigiremos que ela seja confirmada pela blockchain
do Bitcoin, embora isso não seja estritamente necessário para encadear transações.)
• A entrada da transação de reembolso precisa das assinaturas de Alice e Bob.
No entanto, mesmo que essas duas coisas não tenham acontecido e mesmo que o nó da Alice não
tenha transmitido a transação de financiamento, ela ainda pode construir a transação de
reembolso. Ela pode fazer isso porque pode calcular o hash da transação de financiamento e
referenciá-lo como uma entrada na transação de reembolso.
Viu como Alice calculou 6da3c2...387710 como o hash da transação de financiamento? Se e quando
a transação de financiamento for transmitida, esse hash será registrado como o ID da transação de
financiamento. Portanto, a saída 0 da transação de financiamento (a saída do endereço 2-de-2) será
então referenciada como ID de saída 6da3c2...387710:0. A transação de reembolso pode ser
construída para gastar essa saída da transação de financiamento, mesmo que ela ainda não exista,
porque Alice sabe qual será seu identificador assim que for confirmada.
Isso significa que Alice pode criar uma transação encadeada referenciando uma saída que ainda
não existe, sabendo que a referência será válida se a transação de financiamento for confirmada,
tornando também a transação de reembolso válida. Como veremos na próxima seção, esse "truque"
de encadear transações antes de serem transmitidas requer um recurso muito importante do
Bitcoin que foi introduzido em agosto de 2017: o Segregated Witness (Testemunha Separada).
Resolvendo Maleabilidade (Testemunha Segregada)
Alice precisa depender que o ID da transação de financiamento seja conhecido antes da

confirmação. Mas antes da introdução do Segregated Witness (SegWit) em agosto de 2017, isso não
era suficiente para proteger Alice. Devido à maneira como as transações eram construídas, com as
assinaturas (testemunhas) incluídas no ID da transação, era possível para um terceiro (por
exemplo, Bob) transmitir uma versão alternativa de uma transação com um ID de transação
modificado. Isso é conhecido como maleabilidade de transação, e antes do SegWit, esse problema
tornava difícil implementar canais de pagamento de tempo indeterminado de forma segura.
Se Bob pudesse modificar a transação de financiamento de Alice antes de ser confirmada e
13
produzir uma réplica com um ID de transação diferente, Bob poderia tornar a transação de
reembolso de Alice inválida e se apossar de seus bitcoin. Alice estaria à mercê de Bob para obter
uma assinatura e liberar seus fundos, e poderia ser facilmente chantageada. Bob não poderia
roubar os fundos, mas poderia impedir que Alice os recuperasse.
A introdução do SegWit tornou os IDs de transação não confirmados imutáveis do ponto de vista de
terceiros, o que significa que Alice pode ter certeza de que o ID da transação de financiamento não
será alterado. Como resultado, Alice pode ter confiança de que, se obtiver a assinatura de Bob na
transação de reembolso, ela terá uma maneira de recuperar seu dinheiro. Agora, ela tem uma
maneira de implementar o equivalente do Bitcoin a um acordo pré-nupcial antes de bloquear seus
fundos na multisig.
Você pode ter se perguntado como Bob seria capaz de alterar (malear) uma transação criada e
assinada por Alice. Bob certamente não possui as chaves privadas de Alice. No entanto, as
assinaturas ECDSA para uma mensagem não são únicas. Saber uma assinatura (que está
incluída em uma transação válida) permite produzir muitas assinaturas com aparências
diferentes que ainda são válidas. Antes do SegWit remover as assinaturas do algoritmo de
resumo da transação, Bob poderia substituir a assinatura por uma assinatura válida
equivalente que produzisse um ID de transação diferente, quebrando a cadeia entre a
transação de financiamento e a transação de reembolso.
A mensagem funding_created
Agora que Alice construiu as transações necessárias, o fluxo de mensagens para a construção do
canal continua. Alice envia a mensagem funding_created para Bob. Você pode ver o conteúdo dessa
mensagem aqui:
A mensagem do funding_created
[sha256:funding_txid]
[u16:funding_output_index]
[signature:signature]
Com esta mensagem, Alice fornece a Bob as informações importantes sobre a transação de
financiamento que ancora o canal de pagamento:
funding_txid
Este é o ID da transação (TxID) da transação de financiamento e é usado para criar o ID do canal
uma vez que o canal seja estabelecido.
funding_output_index
Este é o índice da saída, para que Bob saiba qual saída da transação (por exemplo, saída 0) é a
saída multisig 2-de-2 financiada por Alice. Isso também é usado para formar o ID do canal.
Finalmente, Alice também envia a signature correspondente à chave pública de financiamento de

Alice (funding_pubkey) e usada para gastar da multisig 2-de-2. Isso é necessário para Bob, pois ele
14
também precisará criar sua própria versão de uma transação de compromisso. Essa transação de
compromisso precisa de uma assinatura de Alice, que ela fornece a ele. Observe que as transações
de compromisso de Alice e Bob têm aparências ligeiramente diferentes, portanto, as assinaturas
serão diferentes. Saber como a transação de compromisso da outra parte se parece é crucial e faz
parte do protocolo para fornecer uma assinatura válida.
No protocolo Lightning, frequentemente vemos nós enviando assinaturas em vez de

transações inteiras assinadas. Isso ocorre porque ambos os lados podem reconstruir a mesma
transação e, portanto, apenas a assinatura é necessária para torná-la válida. Enviar apenas a
assinatura e não a transação inteira economiza bastante largura de banda de rede.
Após receber a mensagem funding_created de Alice, Bob agora conhece o ID da transação de

financiamento e o índice da saída. O ID do canal é feito por um bit-a-bit "exclusivo ou" (XOR) do ID
da transação de financiamento e índice de saída:
channel_id = funding_txid XOR funding_output_index
Mais precisamente, um channel_id, que é a representação de 32 bytes de uma UTXO de

financiamento, é gerado ao realizar uma operação XOR nos 2 bytes inferiores do TxID de
financiamento com o índice da saída de financiamento.
Bob também precisará enviar a Alice sua assinatura para a transação de reembolso, com base na
chave pública de financiamento de Bob funding_pubkey que formou a multisig 2-de-2. Embora Bob já
tenha sua transação de reembolso local, isso permitirá que Alice complete a transação de
reembolso com todas as assinaturas necessárias e tenha certeza de que seu dinheiro pode ser
reembolsado caso algo dê errado.
Bob constrói uma mensagem funding_signed e a envia para Alice. Aqui estão os conteúdos dessa
mensagem:
[channel_id:channel_id]
Transmitindo a Transação de Financiamento
Ao receber a mensagem funding_signed de Bob, Alice agora possui as duas assinaturas necessárias
para assinar a transação de reembolso. Seu "plano de saída" está agora seguro e, portanto, ela pode
transmitir a transação de financiamento sem medo de ter seus fundos bloqueados. Se algo der
errado, Alice pode simplesmente transmitir a transação de reembolso e recuperar seu dinheiro,
sem precisar de mais ajuda de Bob.
Agora, Alice envia a transação de financiamento para a rede Bitcoin para que ela possa ser
15
minerada na blockchain. Tanto Alice quanto Bob estarão monitorando essa transação e aguardando
por um minimum_depth de confirmações (por exemplo, seis confirmações) na blockchain do
Bitcoin.
Claro, Alice usará o Protocolo Bitcoin para verificar se a assinatura que Bob lhe enviou é
realmente válida. Essa etapa é muito crucial. Se, por algum motivo, Bob estivesse enviando
dados incorretos para Alice, seu "plano de saída" seria sabotado.
======= A mensagem funding_locked
Assim que a transação de financiamento atingir o número necessário de confirmações, tanto Alice
quanto Bob enviam a mensagem funding_locked um para o outro e o canal está pronto para uso.
Enviando Pagamentos Pelo Canal

O canal foi configurado, mas em seu estado inicial, toda a capacidade (140.000 satoshis) está do lado
de Alice. Isso significa que Alice pode enviar pagamentos para Bob através do canal, mas Bob ainda
não tem fundos para enviar a Alice.
Nas próximas seções, mostraremos como os pagamentos são feitos através do canal de pagamento e
como o estado do canal, channel state, é atualizado.
Vamos supor que Alice queira enviar 70.000 satoshis para Bob para pagar sua conta na cafeteria de
Bob.
Dividindo o Saldo
Em princípio, enviar um pagamento de Alice para Bob é apenas uma questão de redistribuir o saldo
do canal. Antes do pagamento ser enviado, Alice possui 140.000 satoshis e Bob não possui nenhum.
Após o pagamento de 70.000 satoshis ser enviado, Alice terá 70.000 satoshis e Bob terá 70.000
satoshis.
Portanto, tudo o que Alice e Bob precisam fazer é criar e assinar uma transação que gaste o 2-de-2
multisig para dois outputs pagando a Alice e Bob os saldos correspondentes. Chamamos essa
transação atualizada de "transação de compromisso" (commitment transaction).
Alice e Bob operam o canal de pagamento avançando o estado do canal por meio de uma série de
compromissos. Cada compromisso atualiza os saldos para refletir os pagamentos que foram
realizados pelo canal. Tanto Alice quanto Bob podem iniciar um novo compromisso para atualizar
o canal.
Na Múltiplas transações de compromisso vemos várias transações de compromisso.
A primeira transação de compromisso mostrada na Múltiplas transações de compromisso é a

transação de reembolso que Alice construiu antes de financiar o canal. No diagrama, esta é a
Commitment #0. Após Alice pagar a Bob 70.000 satoshis, a nova transação de compromisso
(Commitment #1) tem duas saídas pagando a Alice e Bob seus saldos respectivos. Incluímos também
duas transações de compromisso subsequentes (Commitment #2 e Commitment #3), que
16
representam Alice pagando a Bob mais 10.000 satoshis e depois 20.000 satoshis, respectivamente.
Cada transação de compromisso assinada e válida pode ser usada por qualquer um dos parceiros
do canal a qualquer momento para fechar o canal, transmitindo-a para a rede Bitcoin. Como ambos
possuem a transação de compromisso mais recente e podem usá-la a qualquer momento, eles
também podem apenas mantê-la e não transmiti-la. É a garantia de uma saída justa do canal.
Figure 6. Múltiplas transações de compromisso
Compromissos Concorrentes
Você pode estar se perguntando como é possível que Alice e Bob tenham várias transações de
compromisso, todas elas tentando gastar a mesma saída 2-de-2 da transação de financiamento.
Essas transações de compromisso não estão em conflito?Não se trata de um "gasto duplo" que o
sistema Bitcoin é projetado para impedir?
De fato! Na verdade, dependemos da capacidade do Bitcoin de prevenir um gasto duplo para que a
Lightning funcione. Não importa quantas transações de compromisso Alice e Bob construam e
assinem, apenas uma delas pode ser confirmada de fato.
Desde que Alice e Bob mantenham essas transações e não as transmitam, a saída do financiamento
17
não será gasta. No entanto, se uma transação de compromisso for transmitida e confirmada, ela
gastará a saída de financiamento. Se Alice ou Bob tentarem transmitir mais de uma transação de
compromisso, apenas uma delas será confirmada e as outras serão rejeitadas como tentativas (e
falhas) de gastos duplos.
Se mais de uma transação de compromisso for transmitida, existem vários fatores que
determinarão qual delas será confirmada primeiro: a quantidade de taxas incluídas, a velocidade
de propagação dessas transações concorrentes, a topologia da rede, entre outros. Basicamente, isso
se torna uma corrida sem um resultado previsível. Isso não parece muito seguro. Parece que
alguém poderia trapacear.
Trapaceando com Transações de Compromisso Antigas
Vamos analisar mais cuidadosamente as transações de compromisso na Múltiplas transações de

compromisso. Todas as quatro transações de compromisso estão assinadas e são válidas. No
entanto, apenas a última reflete com precisão os saldos mais recentes do canal. Neste cenário
específico, Alice tem a oportunidade de trapacear ao transmitir um compromisso anterior e
conseguir a confirmação no blockchain do Bitcoin. Vamos supor que Alice transmita o Commitment
#0 e o tenha confirmado: ela efetivamente encerrará o canal e ficará com todos os 140.000 satoshis.
Na verdade, neste exemplo específico, qualquer compromisso, exceto o Commitment #3, melhora a
posição de Alice e permite que ela "cancele" pelo menos parte dos pagamentos refletidos no canal.
No próximo tópico, veremos como a Lightning Network resolve esse problema—evitando que
transações de compromisso antigas sejam utilizadas pelos parceiros do canal por meio de um
mecanismo de revogação e penalidades. Existem outras maneiras de evitar a transmissão de
transações de compromisso antigas, como canais eltoo, mas elas requerem uma atualização do
Bitcoin chamada de religação de entradas (veja [bitcoin_prot_17]).
Revogando Transações de Compromisso Antigas
Transações Bitcoin não expiram e não podem ser "canceladas". Elas também não podem ser
interrompidas ou censuradas depois de terem sido transmitidas. Então, como podemos "revogar"
uma transação que outra pessoa possui e que já foi assinada?
A solução utilizada no Lightning é outro exemplo de um protocolo de justiça.Em vez de tentar

controlar a capacidade de transmitir uma transação, existe um mecanismo de penalidade (penalty
mechanism) incorporado que garante que não seja do interesse de um potencial trapaceiro
transmitir uma transação de compromisso antiga. Eles sempre podem transmiti-la, mas
provavelmente perderão dinheiro se o fizerem.
A palavra "revogar" é um equívoco porque implica que compromissos antigos são de alguma
forma tornados inválidos e não podem ser transmitidos e confirmados. Mas esse não é o caso,
uma vez que transações válidas de Bitcoin não podem ser revogadas. Em vez disso, o protocolo
Lightning usa um mecanismo de penalidade para punir o parceiro do canal que transmite um
compromisso antigo.
Existem três elementos que compõem o mecanismo de revogação e penalidade do protocolo
18
Lightning:
Transações de compromisso assimétricas

As transações de compromisso de Alice são ligeiramente diferentes das mantidas por Bob.
Gasto com atraso

O pagamento para a parte que possui a transação de compromisso é atrasado (bloqueado no
tempo), enquanto o pagamento para a outra parte pode ser reivindicado imediatamente.
Chaves de revogação: São usadas para desbloquear uma opção de penalidade para compromissos
antigos.
Vamos analisar esses três elementos separadamente.
Transações de Compromisso Assimétricas
Alice e Bob possuem transações de compromisso ligeiramente diferentes. Vamos dar uma olhada
específica no Commitment #2 da Múltiplas transações de compromisso, com mais detalhes na
Transação de compromisso #2.
Figure 7. Transação de compromisso #2
Alice e Bob possuem duas variações diferentes dessa transação, como ilustrado na Transações de
compromisso assimétricas.
19
Figure 8. Transações de compromisso assimétricas
Por convenção, dentro do protocolo Lightning, nos referimos aos dois parceiros do canal como self
(também conhecido como local) e remote, dependendo de qual lado estamos olhando. As saídas que
pagam cada parceiro do canal são chamadas de to_local e to_remote, respectivamente.
Na Transações de compromisso assimétricas vemos que Alice possui uma transação que paga
60.000 satoshis para si mesma (to_self, pode ser gasto pelas chaves de Alice) e 80.000 satoshis para
o parceiro remoto (to_remote, pode ser gasto pelas chaves de Bob).
Bob possui a imagem espelhada dessa transação, onde o primeiro output é de 80.000 satoshis para
si mesmo (to_self, pode ser gasto pelas chaves de Bob), e 60.000 satoshis para o parceiro remoto
(to_remote, pode ser gasto pelas chaves de Alice).
Gastos Atrasados (Com Bloqueio de Tempo) Para Si Mesmo (to_self)
Usar transações assimétricas permite que o protocolo atribua facilmente a culpa à parte que está
trapaceando. Uma invariante que a parte que está transmitindo sempre deve esperar garante que a
parte "honesta" tenha tempo para refutar a alegação e revogar seus fundos. Essa assimetria é
manifestada na forma de saídas diferentes para cada lado: a saída to_local está sempre bloqueada
pelo tempo (timelocked) e não pode ser gasta imediatamente, enquanto a saída to_remote não está
bloqueada pelo tempo e pode ser gasta imediatamente.
Na transação de compromisso mantida por Alice, por exemplo, a saída to_local que a paga está
bloqueada pelo tempo de 432 blocos, enquanto a saída to_remote que paga Bob pode ser gasta
imediatamente (veja Transações de compromisso assimétricas e com atraso). A transação de
compromisso de Bob para o Commitment #2 é a imagem espelhada: sua própria saída (to_local)
está bloqueada pelo tempo, e a saída to_remote de Alice pode ser gasta imediatamente.
20
Figure 9. Transações de compromisso assimétricas e com atraso
Isso significa que se Alice fechar o canal ao transmitir e confirmar a transação de compromisso que
ela possui, ela não poderá gastar seu saldo por 432 blocos, mas Bob poderá reivindicar seu saldo
imediatamente. Se Bob fechar o canal usando a transação de compromisso que ele possui, ele não
poderá gastar sua saída por 432 blocos, enquanto Alice poderá gastar a dela imediatamente.
O atraso está lá por uma razão: permitir que a parte remota exerça uma opção de penalidade se um
antigo compromisso (revogado) for transmitido pela outra parte do canal. Vamos examinar as
chaves de revogação e a opção de penalidade a seguir.
O atraso é negociado por Alice e Bob durante a troca inicial de mensagens de construção do canal,
como um campo chamado to_self_delay. Para garantir a segurança do canal, o atraso é
dimensionado em relação à capacidade do canal—o que significa que um canal com mais fundos
terá atrasos mais longos nos outputs to_self nos compromissos. O nó de Alice inclui um
to_self_delay desejado na mensagem open_channel. Se Bob considerar isso aceitável, seu nó inclui o
mesmo valor para to_self_delay na mensagem accept_channel. Se eles não concordarem, então o
canal é rejeitado (veja A Mensagem de Desligamento).
Chaves de Revogação
Como discutimos anteriormente, a palavra "revogação" é um pouco enganosa porque ela sugere
que a transação "revogada" não pode ser usada.
Na verdade, a transação revogada pode ser usada, mas se for usada e tiver sido revogada, então um
dos parceiros do canal pode pegar todos os fundos do canal criando uma transação de penalidade.
A forma como isso funciona é que a saída to_local não apenas possui um bloqueio temporal, mas
também possui duas condições de gasto no script: ela pode ser gasta por self após o atraso do
bloqueio temporal ou pode ser gasta por remote imediatamente com uma chave de revogação para
esse compromisso.
Portanto, em nosso exemplo, cada lado possui um compromisso de transação que inclui uma opção
de revogação na saída to_local, conforme mostrado na Compromissos assimétricos, com atraso e
revogáveis.
21
Figure 10. Compromissos assimétricos, com atraso e revogáveis
A Transação de Compromisso
Agora que entendemos a estrutura das transações de compromisso e a razão de precisarmos de
compromissos assimétricos, com atraso e revogáveis, vamos examinar o Bitcoin Script que
implementa isso.
A primeira saída (to_local) de uma transação de compromisso é definida em: BOLT #3:
Commitment Transaction, to_local Output, como segue:
OP_IF
# Penalty transaction
<revocationpubkey>
OP_ELSE
<to_self_delay>
OP_CHECKSEQUENCEVERIFY
OP_DROP
<local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG
Este é um script condicional (veja [conditional_scripts]), o que significa que a saída pode ser gasta
se qualquer das duas condições for atendida. A primeira cláusula permite que a saída seja gasta por
qualquer pessoa que possa assinar pela <revocationpubkey>. A segunda cláusula é bloqueada por
tempo por blocos <to_self_delay> e só pode ser gasto após esse número de blocos por qualquer
pessoa que possa assinar a <local_delayedpubkey>. Em nosso exemplo, nós havíamos definido o
timelock <to_self_delay> para 432 blocos, mas esse é um atraso configurável que é negociado pelos
dois parceiros do canal. A duração do bloqueio temporal to_self_delay geralmente é escolhida
proporcionalmente à capacidade do canal, ou seja, canais com capacidade maior (mais fundos) têm
bloqueios temporais to_self_delay mais longos para proteger as partes envolvidas.
22
A primeira cláusula permite que a saída seja gasta por qualquer pessoa que possa assinar por
<revocationpubkey>. Um requisito crítico para a segurança desse script é que a outra parte não
possa assinar unilateralmente com a revocationpubkey. Para entender por que isso é importante,
considere o cenário em que a outra parte viola um compromisso previamente revogado. Se eles
puderem assinar com essa chave, eles podem simplesmente usar a cláusula de revogação para si
mesmos e roubar todos os fundos do canal. Em vez disso, derivamos a revocationpubkey para cada
estado com base em informações de ambas as partes (local e remota). Um uso inteligente da
criptografia simétrica e assimétrica é utilizado para permitir que ambas as partes calculem a chave
pública revocationpubkey, mas apenas permitir que a parte honesta calcule a chave privada com
base em suas informações secretas, conforme detalhado em Revogação e Derivações Secretas de
Compromisso.
Revogação e Derivações Secretas de Compromisso
Cada lado envia um revocation_basepoint durante as mensagens iniciais de negociação do

canal, assim como um first_per_commitment_point. O revocation_basepoint é estático ao longo
da vida útil do canal, enquanto cada novo estado do canal será baseado em um novo
first_per_commitment_point.
Com base nessas informações, a revocationpubkey para cada estado do canal é derivada por
meio da seguinte série de operações de curva elíptica e hashing:
revocationpubkey = revocation_basepoint * sha256(revocation_basepoint ||

per_commitment_point) + per_commitment_point * sha256(per_commitment_point ||
revocation_basepoint)
Devido à propriedade comutativa dos grupos abelianos nos quais as curvas elípticas são
definidas, uma vez que o per_commitment_secret (a chave privada para o
per_commitment_point) seja revelado pela parte remota, é possível a parte self derivar a chave
privada para o revocationpubkey por meio da seguinte operação:
revocation_priv = (revocationbase_priv * sha256(revocation_basepoint ||

per_commitment_point)) + (per_commitment_secret * sha256(per_commitment_point ||
revocation_basepoint)) mod N
Para entender por que isso funciona na prática, observe que podemos reordenar (comutar) e
expandir o cálculo da chave pública na fórmula original para revocationpubkey:
revocationpubkey = G*(revocationbase_priv * sha256(revocation_basepoint ||

per_commitment_point) + G*(per_commitment_secret * sha256(per_commitment_point ||
revocation_basepoint))
= revocation_basepoint * sha256(revocation_basepoint ||
per_commitment_point) + per_commitment_point * sha256(per_commitment_point ||
revocation_basepoint))
Em outras palavras, a revocationbase_priv só pode ser derivada (e usada para assinar a
23
revocationpubkey) pela parte que conhece ambas a revocationbase_priv e o
per_commitment_secret. Esse pequeno truque é o que torna o sistema de revogação baseado
em chave pública usado na Lightning Network seguro.
O timelock usado na transação de compromisso com

CHECKSE⁠QUENCEVERIFY é um timelock relativo. Ele conta os blocos
decorridos a partir da confirmação dessa saída. Isso significa que ela não poderá ser gasta até
o bloco to_self_delay após essa transação de compromisso ser transmitida e confirmada.
A segunda saída (to_remote) da transação de compromisso é definida em BOLT #3: Commitment

Transaction, to_remote Output, e na forma mais simples como um Pay-to-Witness-Public-Key-Hash
(P2WPKH) por <remote_pubkey>, significando que ela simplesmente paga o dono que pode assinar
por <remote_pubkey>.
Agora que definimos as transações de compromisso em detalhes, vamos ver como Alice e Bob
avançam o estado do canal, criam e assinam novas transações de compromisso e revogam
transações de compromisso antigas.
Avançando o Estado do Canal

Para avançar o estado do canal, Alice e Bob trocam duas mensagens: commitment_signed e
revoke_and_ack. A mensagem commitment_signed pode ser enviada por qualquer uma das partes
do canal quando elas têm uma atualização para o estado do canal. A outra parte do canal pode
então responder com a mensagem revoke_and_ack para revogar o compromisso antigo e
reconhecer o novo compromisso.
Na Fluxo de mensagens de confirmação e revogação observamos Alice e Bob trocando dois pares de
mensagens commitment_signed e revoke_and_ack. O primeiro fluxo mostra uma atualização de
estado iniciada por Alice (da esquerda para a direita, commitment_signed), à qual Bob responde (da
direita para a esquerda, revoke_and_ack). O segundo fluxo mostra uma atualização de estado
iniciada por Bob e respondida por Alice.
24
Figure 11. Fluxo de mensagens de confirmação e revogação
A Mensagem commit_signed
A estrutura da mensagem commitment_signed é definida em BOLT #2: Peer Protocol,

commitment_signed, e mostrada aqui:
The commitment_signed message
[u16:num_htlcs]
[num_htlcs*signature:htlc_signature]
channel_id
O identificador do canal
signature
A assinatura para o novo compromisso remoto
num_htlcs
O número de HTLCs atualizados neste compromisso
htlc_signature
As assinaturas para as atualizações
O uso de HTLCs para comprometer atualizações será explicado em detalhes em [htlcs] e no

[channel_operation].
25
A mensagem commitment_signed de Alice fornece a Bob a assinatura necessária (a parte de Alice
do 2-de-2) para uma nova transação de compromisso.
A Mensagem revoke_and_ack
Agora que Bob tem uma nova transação de compromisso, ele pode revogar o compromisso anterior
fornecendo a Alice uma chave de revogação e construir o novo compromisso com a assinatura de
Alice.
A mensagem revoke_and_ack é definida em BOLT #2: Peer Protocol, revoke_and_ack, e mostrada

aqui:
The revoke_and_ack message
[32*byte:per_commitment_secret]
[point:next_per_commitment_point]
channel_id
Este é o identificador do canal.
per_commitment_secret
Usado para gerar uma chave de revogação para o compromisso anterior (antigo), efetivamente
revogando-o.
next_per_commitment_point
Usado para construir uma revocation_pubkey para o novo compromisso, de modo que ele possa
ser revogado posteriormente.
Revogação e Recompromisso
Vamos examinar mais de perto essa interação entre Alice e Bob.
Alice está fornecendo a Bob os meios para criar um novo compromisso. Em troca, Bob está
revogando o compromisso antigo para assegurar a Alice que ele não o utilizará. Alice só pode
confiar no novo compromisso se ela tiver a chave de revogação para punir Bob por publicar o
compromisso antigo. Do ponto de vista de Bob, ele pode revogar com segurança o compromisso
antigo, fornecendo a Alice as chaves para penalizá-lo, pois ele possui uma assinatura para um novo
compromisso.
Quando Bob responde com a mensagem revoke_and_ack, ele fornece a Alice um

per_commitment_secret. Esse segredo pode ser usado para construir a chave de assinatura de
revogação para o compromisso antigo, o que permite que Alice confisque todos os fundos do canal
exercendo uma penalidade.
Assim que Bob tiver fornecido esse segredo a Alice, ele nunca deve transmitir aquele compromisso
antigo. Se ele o fizer, ele dará a Alice a oportunidade de penalizá-lo, tomando os fundos.
Essencialmente, Bob está dando a Alice a capacidade de responsabilizá-lo por transmitir um
compromisso antigo e, efetivamente, ele revogou sua capacidade de usar aquele compromisso
26
antigo.
Assim que Alice receber o revoke_and_ack de Bob, ela pode ter certeza de que Bob não pode
transmitir o compromisso antigo sem ser penalizado. Agora, ela possui as chaves necessárias para
criar uma transação de penalidade caso Bob transmita um compromisso antigo.
Trapaça e Penalidade na Prática
Na prática, tanto Alice quanto Bob devem monitorar possíveis fraudes. Eles monitoram a
blockchain do Bitcoin em busca de quaisquer transações de compromisso relacionadas aos canais
que estão operando. Se eles identificarem uma transação de compromisso confirmada na
blockchain, eles verificarão se é o compromisso mais recente. Se for um compromisso "antigo", eles
devem imediatamente construir e transmitir uma transação de penalidade. A transação de
penalidade gasta ambas as saídas to_local e to_remote, encerrando o canal e enviando ambos os
saldos para o parceiro prejudicado no canal.
Para facilitar o acompanhamento dos números de compromisso dos compromissos revogados por
ambas as partes, cada compromisso realmente codifica o número do compromisso nos campos de
tempo de bloqueio e sequência de uma transição. Dentro doprotocolo, essa codificação especial é
referida como dicas de estado (state hints). Supondo que uma parte conheça o número de
compromisso atual, ela é capaz de usar as dicas de estado para reconhecer facilmente se um
compromisso transmitido foi revogado e, se sim, qual número de compromisso foi violado, já que
esse número é usado para buscar facilmente qual segredo de revogação deve ser usado na árvore
de segredos de revogação (shachain).
Em vez de codificar a dica de estado à mostra, é utilizada uma dica de estado obfuscada. Essa
obfuscação é alcançada primeiramente realizando uma operação XOR entre o número de
compromisso atual e um conjunto de bytes aleatórios gerados de forma determinística utilizando as
chaves públicas de financiamento de ambas as partes do canal. Um total de 6 bytes, distribuídos
entre o campo de tempo de bloqueio (locktime) e sequência (sequence) (24 bits do locktime e 24 bits
da sequência), são utilizados para codificar a dica de estado dentro da transação de compromisso,
portanto, são necessários 6 bytes aleatórios para a operação XOR. Para obter esses 6 bytes, ambas as
partes obtêm o hash SHA-256 da chave de financiamento do iniciador concatenada com a chave de
financiamento do respondedor. Antes de codificar a altura atual do compromisso, o número inteiro
é submetido a uma operação XOR com esse obfuscador de dica de estado e, em seguida, codificado
nos 24 bits inferiores do campo de tempo de bloqueio e nos 64 bits superiores da sequência.
Vamos revisar nosso canal entre Alice e Bob e mostrar um exemplo específico de uma transação de
penalidade. Na Compromissos revogados e atuais vemos os quatro compromissos no canal entre
Alice e Bob. Alice fez três pagamentos para Bob:
• 70.000 satoshis pagos e comprometidos a Bob com o Commitment #1
27
Figure 12. Compromissos revogados e atuais
Com cada compromisso, Alice revogou o compromisso anterior (mais antigo). O estado atual do
canal e o saldo correto são representados pelo Commitment #3. Todos os compromissos anteriores
foram revogados, e Bob possui as chaves necessárias para emitir transações de penalidade contra
eles, caso Alice tente transmitir algum deles.
Alice pode ter um incentivo para trapacear porque todas as transações de compromisso anteriores
dariam a ela uma proporção maior do saldo do canal do que ela tem direito. Digamos, por exemplo,
que Alice tentou transmitir o Commitment #1. Essa transação de compromisso pagaria 70.000
satoshis para Alice e 70.000 satoshis para Bob. Se Alice conseguisse transmitir e gastar sua saída
to_local, ela estaria efetivamente roubando 30.000 satoshis de Bob, revertendo seus dois últimos
pagamentos a Bob.
Alice decide correr um grande risco e transmitir o Commitment #1 revogado, para roubar 30.000
satoshis de Bob. Na Alice trapaceando nós observamos o antigo compromisso de Alice que ela
transmite para o blockchain do Bitcoin.
28
Figure 13. Alice trapaceando
Como você pode ver, o antigo compromisso de Alice possui duas saídas, uma pagando a ela mesma
70.000 satoshis (saída to_local) e outra pagando 70.000 satoshis a Bob. Alice não pode gastar sua
saída de 70.000 satoshis to_local ainda, pois ela está bloqueada por um prazo de 432 blocos (3 dias).
Agora, ela está esperando que Bob não perceba durante os próximos três dias.
Infelizmente para Alice, o nó de Bob está monitorando diligentemente a blockchain do Bitcoin e ele
vê uma transação de compromisso antiga sendo transmitida e, eventualmente, confirmada na
blockchain.
O nó de Bob imediatamente transmitirá uma transação de penalidade. Uma vez que esse
compromisso antigo foi revogado por Alice, Bob possui o per_commitment_secret que Alice lhe
enviou. Ele usa esse segredo para construir uma assinatura para a revocation_pubkey. Enquanto
Alice precisa esperar 432 blocos, Bob pode gastar ambas as saídas imediatamente. Ele pode gastar a
saída to_remote com suas chaves privadas, pois ela era destinada a pagar a ele de qualquer
29
maneira. Ele também pode gastar a saída destinada a Alice com uma assinatura da chave de
revogação. O nó de Bob transmite a transação de penalidade mostrada na Traição e Penalidade.
Figure 14. Traição e Penalidade
A transação de penalidade de Bob paga 140.000 satoshis para sua própria carteira, assumindo toda
a capacidade do canal. Alice não apenas falhou em trapacear, mas também perdeu tudo na
tentativa!
A Reserva do Canal: Garantindo Comprometimento no Jogo
Você pode ter percebido que existe uma situação especial que precisa ser lidada. Se Alice pudesse
continuar gastando seu saldo até chegar a zero, ela estaria em uma posição para encerrar o canal
ao transmitir uma transação de compromisso antiga sem correr o risco de uma penalidade: ou a
transação de compromisso revogada tem sucesso após o atraso, ou o trapaceiro é pego, mas não há
consequência porque a penalidade é zero. Do ponto de vista da teoria dos jogos, é dinheiro grátis
tentar trapacear nessa situação. É por isso que a reserva do canal está em jogo, para que um
trapaceiro em potencial sempre enfrente o risco de uma penalidade.
Encerrando o Canal (Fechamento Cooperativo)

Até agora, examinamos as transações de compromisso como uma possível forma de encerrar um
canal de forma unilateral. Esse tipo de encerramento de canal não é ideal, pois impõe um período
de tempo de bloqueio ao parceiro do canal que o utiliza.
Uma forma melhor de encerrar um canal é através do fechamento cooperativo. No fechamento

cooperativo, os doisparceiros do canal negociam uma transação de compromisso final chamada de
transação de fechamento (closing transaction) que paga a cada parte seu saldo imediatamente para
a carteira de destino de sua escolha. Em seguida, o parceiro que iniciou o processo de
encerramento do canal transmitirá a transação de fechamento.
O fluxo de mensagens de fechamento é definido em BOLT #2: Peer Protocol, Channel Close, e é
mostrado na O fluxo de mensagem de fechamento do canal.
30
Figure 15. O fluxo de mensagem de fechamento do canal
A Mensagem de Desligamento
O encerramento do canal começa quando um dos dois parceiros do canal envia a mensagem
shutdown. O conteúdo dessa mensagem é mostrado aqui:
The shutdown message
[u16:len]
[len*byte:scriptpubkey]
channel_id
O identificador do canal que desejamos encerrar
len
O tamanho do script da carteira de destino para a qual esse parceiro do canal deseja receber seu
saldo.
scriptpubkey
Um script Bitcoin da carteira de destino, em um dos formatos de endereço Bitcoin "padrão"
(P2PKH, P2SH, P2WPKH, P2WSH, etc.; veja o [glossary])
Vamos supor que Alice envie a mensagem shutdown para Bob para encerrar o canal deles. Alice
31
especificará um script Bitcoin que corresponda ao endereço Bitcoin da sua carteira. Ela está
dizendo a Bob: vamos criar uma transação de fechamento que pague o meu saldo para esta
carteira.
Bob responderá com sua própria mensagem shutdown, indicando que ele concorda em encerrar o
canal de forma cooperativa. Sua mensagem shutdown incluirá o script para o endereço de sua
carteira.
Agora, tanto Alice quanto Bob têm o endereço preferido da carteira um do outro, e eles podem
construir transações de fechamento idênticas para liquidar o saldo do canal.
A Mensagem closing_signed
Supondo que o canal não tenha compromissos ou atualizações pendentes e que os parceiros do
canal tenham trocado as mensagens shutdown mostradas na seção anterior, eles agora podem
concluir esse fechamento cooperativo.
O financiador do canal (Alice em nosso exemplo) começa enviando uma mensagem closing_signed
para Bob. Essa mensagem propõe uma taxa de transação para a transação na blockchain e inclui a
assinatura de Alice (a assinatura multisig 2-de-2) para a transação de fechamento. A mensagem
closing_signed é mostrada aqui:
The closing_signed message
[u64:fee_satoshis]
channel_id
O identificador do canal
fee_satoshis
A taxa proposta para a transação na blockchain, em satoshis
signature
A assinatura do remetente para a transação de fechamento
Quando Bob recebe isso, ele pode responder com uma mensagem closing_signed própria. Se ele
concorda com a taxa proposta, ele simplesmente retorna a mesma taxa proposta e sua própria
assinatura. Se ele não concorda, ele deve propor uma taxa fee_satoshis diferente.
Essa negociação pode continuar com mensagens closing_signed de ida e volta até que os dois
parceiros do canal concordem com uma taxa.
Uma vez que Alice recebe uma mensagem closing_signed com a mesma taxa que ela propôs em sua
última mensagem, a negociação está concluída. Alice assina e transmite a transação de fechamento,
e o canal é encerrado.
32
A Transação de Fechamento Cooperativo
A transação de fechamento cooperativo se parece com a última transação de compromisso com a

qual Alice e Bob concordaram. No entanto, ao contrário da última transação de compromisso, ela
não possui bloqueios de tempo ou chaves de revogação de penalidade nas saídas. Uma vez que
ambas as partes cooperam para produzir essa transação e não farão mais compromissos, não há
necessidade dos elementos assimétricos, atrasados e revogáveis nessa transação.
Normalmente, os endereços usados na transação de fechamento cooperativo são gerados novos

para cada canal que está sendo encerrado. No entanto, também é possível que ambos os lados
travem um endereço de "entrega" para ser usado para enviar os fundos liquidados de forma
cooperativa. Dentro do namespace TLV (Type-Length-Value) das mensagens open_channel e
accept_channel, ambos os lados são livres para especificar um "script de encerramento prévio".
Comumente, esse endereço é derivado de chaves que residem em armazenamento a frio (cold
storage). Essa prática serve para aumentar a segurança dos canais: se um dos parceiros do canal for
de alguma forma hackeado, o invasor não será capaz de encerrar o canal de forma cooperativa
usando um endereço que eles controlam. Em vez disso, o parceiro honesto e não comprometido do
canal se recusará a cooperar no encerramento do canal se o endereço de encerramento prévio
especificado não for usado. Essa característica cria efetivamente um "loop fechado", restringindo o
fluxo de fundos para fora de um determinado canal.
Alice transmite uma transação mostrada na A transação de fechamento cooperativa para fechar o
canal.
Figure 16. A transação de fechamento cooperativa
Assim que essa transação de fechamento for confirmada no blockchain do Bitcoin, o canal estará
encerrado. Agora, Alice e Bob podem gastar suas saídas como desejarem.
Conclusão
Nesta seção, examinamos os canais de pagamento com muito mais detalhes. Analisamos três fluxos
de mensagens usados por Alice e Bob para negociar o financiamento, compromissos e
encerramento do canal. Também mostramos a estrutura das transações de financiamento,
compromisso e fechamento, e examinamos os mecanismos de revogação e penalidade.
Como veremos nos próximos capítulos, HTLCs são usados até mesmo para pagamentos locais entre
os parceiros do canal. Eles não são necessários, mas o protocolo é muito mais simples se os
pagamentos locais (em um único canal) e os pagamentos roteados (em vários canais) forem feitos
33
da mesma forma.
Em um único canal de pagamento, o número de pagamentos por segundo está apenas limitado pela
capacidade de rede entre Alice e Bob. Desde que os parceiros do canal consigam enviar alguns
bytes de dados de ida e volta para concordar com um novo saldo do canal, eles efetivamente
realizaram um pagamento. É por isso que podemos obter uma capacidade de pagamento muito
maior na Lightning Network (fora da cadeia) em comparação com a capacidade de transações que
podem ser processadas pela blockchain do Bitcoin (na cadeia).
Nas próximas seções, discutiremos o roteamento, os HTLCs e seu uso nas operações de canal.
34
Roteando em uma Rede de Canais de
Pagamento
Neste capítulo, finalmente veremos como os canais de pagamento podem ser conectados para
formar uma rede de canais de pagamento por meio de um processo chamado roteamento.
Especificamente, vamos examinar a primeira parte da camada de roteamento, o protocolo "Atomic
and trustless multihop contracts". Isso é destacado por uma desenho do conjunto de protocolos,
mostrado na Roteamento de pagamento atômico no conjunto de protocolos Lightning.
Figure 1. Roteamento de pagamento atômico no conjunto de protocolos Lightning
Roteando um Pagamento
Nesta seção, examinaremos o roteamento sob a perspectiva de Dina, uma jogadora que recebe
doações de seus fãs enquanto transmite suas sessões de jogo.
A inovação dos canais de pagamento roteados permite que Dina receba gorjetas sem precisar
manter um canal separado com cada um de seus fãs que deseja dar gorjeta a ela. Contanto que
exista um caminho de canais bem financiados do espectador até Dina, ela será capaz de receber o
pagamento desse fã.
Na Fãs conectados (in)diretamente a Dina na Lightning Network nós vemos um possível layout de
rede criado por vários canais de pagamento entre os nós Lightning. Todos neste diagrama podem
enviar um pagamento para Dina construindo um caminho. Imagine que o Fã 4 queira enviar um
pagamento para Dina. Você vê o caminho que poderia permitir isso? O Fã 4 poderia rotear um
pagamento para Dina através do Fã 3, Bob e Chan. Da mesma forma, Alice poderia rotear um
pagamento para Dina através de Bob e Chan.
1
Figure 2. Fãs conectados (in)diretamente a Dina na Lightning Network
Os nós ao longo do caminho, do fã até Dina, são intermediários chamados de nós de roteamento no
contexto do roteamento de um pagamento. Não há diferença funcional entre os nós de roteamento
e os nós operados pelos fãs de Dina. Qualquer nó Lightning é capaz de rotear pagamentos através
de seus canais de pagamento.
É importante ressaltar que os nós de roteamento são incapazes de roubar os fundos enquanto
roteiam um pagamento de um fã para Dina. Além disso, os nós de roteamento não podem perder
dinheiro ao participar do processo de roteamento. Os nós de roteamento podem cobrar uma taxa
de roteamento por atuarem como intermediários, embora não sejam obrigados a fazer isso e
possam optar por rotear pagamentos gratuitamente.
Outro detalhe importante é que, devido ao uso do roteamento em camadas (onion routing), os nós
intermediários estão cientes explicitamente apenas do nó que os antecede e do nó que os segue na
rota. Eles não necessariamente saberão quem é o remetente e o destinatário do pagamento. Isso
permite que os fãs usem nós intermediários para pagar Dina, sem vazar informações privadas e
sem correr o risco de roubo.
Esse processo de conectar uma série de canais de pagamento com segurança de ponta a ponta e a
estrutura de incentivos para os nós encaminharem pagamentos é uma das principais inovações da
Lightning Network.
Neste capítulo, vamos mergulhar no mecanismo de roteamento na Lightning Network, detalhando

a maneira precisa pela qual os pagamentos fluem pela rede. Primeiro, vamos esclarecer o conceito
de roteamento (routing) e compará-lo ao de busca de caminho (pathfinding), porque esses termos
muitas vezes são confundidos e usados indiscriminadamente. Em seguida, vamos construir o
protocolo de equidade (justiça): um protocolo atômico, trustless (sem confiança) e multihop (multi-
2
saltos) usado para rotear pagamentos. Para demonstrar como esse protocolo de justiça funciona,
usaremos uma equivalência física de transferência de moedas de ouro entre quatro pessoas. Por
fim, vamos analisar a implementação do protocolo atomico, confiável e multihop atualmente usado
na Lightning Network, chamado de contrato de tempo bloqueado por hash (Hash Time-Locked
Contract HTLC).
Roteamento versus Busca de Caminho

É importante ressaltar que separamos o conceito de roteamento do conceito de busca de caminho.
Esses dois conceitos muitas vezes são confundidos, e o termo roteamento é frequentemente usado
para descrever ambos os conceitos. Vamos eliminar a ambiguidade antes de prosseguir.
Pathfinding (busca de caminho), abordada no [path_finding], é o processo de encontrar e escolher

um caminho contíguo composto por canais de pagamento que conectam o remetente A ao
destinatário B. O remetente de um pagamento realiza a busca de caminho examinando o channel
graph (grafo de canais) que eles montaram a partir das divulgações de canais realizadas por outros
nós.
Roteamento refere-se à série de interações em toda a rede que tentam encaminhar um pagamento
de um ponto A para outro ponto B, ao longo do caminho previamente selecionado pela busca de
caminho. O roteamento é o processo ativo de enviar um pagamento em um caminho, o que envolve
a cooperação de todos os nós intermediários ao longo desse caminho.
Uma regra importante a ser observada é que é possível que exista um caminho entre Alice e Bob
(talvez até mais de um), porém pode não haver uma rota ativa para enviar o pagamento. Um
exemplo disso é o cenário em que todos os nós que conectam Alice e Bob estão atualmente offline.
Nesse exemplo, é possível examinar o grafo de canais e conectar uma série de canais de pagamento
de Alice para Bob, portanto, um caminho existe. No entanto, como os nós intermediários estão
offline, o pagamento não pode ser enviado e, portanto, nenhuma rota existe.
Criando uma Rede de Canais de Pagamento

Antes de mergulharmos no conceito de pagamento multihop atômico e sem confiança, vamos ver
um exemplo. Vamos voltar para Alice, que, nos capítulos anteriores, comprou um café de Bob com
quem ela tem um canal aberto. Agora, Alice está assistindo a uma transmissão ao vivo de Dina, a
jogadora, e quer enviar uma gorjeta de 50.000 satoshis para Dina através da Lightning Network.
Mas Alice não tem um canal direto com Dina. O que Alice pode fazer?
Alice pode abrir um canal direto com Dina; no entanto, isso exigiria liquidez e taxas on-chain que
podem ser maiores do que o valor da gorjeta em si. Em vez disso, Alice pode usar seus canais
abertos existentes para enviar uma gorjeta para Dina sem precisar abrir um canal diretamente com
ela. Isso é possível, desde que exista um caminho de canais de Alice para Dina com capacidade
suficiente para encaminhar a gorjeta.
Como você pode ver na Uma rede de canais de pagamento entre Alice e Dina, Alice tem um canal
aberto com Bob, o proprietário da cafeteria. Bob, por sua vez, tem um canal aberto com o
desenvolvedor de software Chan, que o ajuda com o sistema de ponto de venda que ele usa em sua
cafeteria. Chan também é o proprietário de uma grande empresa de software que desenvolve o
3
jogo que Dina joga, e eles já têm um canal aberto que Dina usa para pagar a licença do jogo e itens
dentro do jogo.
Figure 3. Uma rede de canais de pagamento entre Alice e Dina
É possível traçar um caminho de Alice para Dina que utiliza Bob e Chan como nós intermediários de
roteamento. Então, Alice pode criar uma rota a partir desse caminho e usá-la para enviar uma
gorjeta de alguns milhares de satoshis para Dina, com o pagamento sendo encaminhado por Bob e
Chan. Essencialmente, Alice pagará Bob, que pagará Chan, que pagará Dina. Não é necessário ter
um canal direto de Alice para Dina.
O principal desafio é fazer isso de uma forma que impeça Bob e Chan de roubar o dinheiro que
Alice deseja enviar para Dina.
Um Exemplo Físico de "Roteamento"

Para entender como a Rede Lightning protege o pagamento durante o roteamento, podemos
compará-la a um exemplo de roteamento de pagamentos físicos com moedas de ouro no mundo
real.
Suponha que Alice queira dar 10 moedas de ouro para Dina, mas não tem acesso direto a Dina. No
entanto, Alice conhece Bob, que conhece Chan, que conhece Dina, então ela decide pedir ajuda a
Bob e Chan. Isso é mostrado na Alice quer pagar a Dina 10 moedas de ouro.
4
Figure 4. Alice quer pagar a Dina 10 moedas de ouro
Alice pode pagar Bob para pagar Chan para pagar Dina, mas como ela pode garantir que Bob ou
Chan não peguem as moedas e fujam depois de recebê-las? No mundo físico, contratos podem ser
usados para realizar uma série de pagamentos com segurança.
Alice poderia negociar um contrato com Bob, que diz:
Eu, Alice, darei a você, Bob, 10 moedas de ouro se você as repassar para Chan.
Embora esse contrato seja bom na teoria, no mundo real, Alice corre o risco de que Bob possa
quebrar o contrato e esperar não ser pego. Mesmo que Bob seja capturado e processado, Alice
enfrenta o risco de que ele possa estar falido e ser incapaz de devolver suas 10 moedas de ouro.
Supondo que esses problemas sejam magicamente resolvidos, ainda não está claro como aproveitar
tal contrato para alcançar nosso objetivo desejado: entregar as moedas para Dina.
Vamos melhorar nosso contrato para incorporar estas considerações:
Eu, Alice, vou reembolsar você, Bob, com 10 moedas de ouro se você puder me
provar (por exemplo, por meio de um recibo) que você entregou 10 moedas de
ouro para Chan.
Você pode se perguntar por que Bob deveria assinar tal contrato. Ele teria que pagar a Chan, mas
no final não receberia nada em troca, e ele corre o risco de que Alice não o reembolse. Bob poderia
oferecer a Chan um contrato semelhante para pagar a Dina, mas da mesma forma, Chan não teria
motivo para aceitá-lo também.
Mesmo deixando de lado o risco, Bob e Chan precisam já ter 10 moedas de ouro para enviar; caso
contrário, eles não seriam capazes de participar do contrato.
Portanto, Bob e Chan enfrentam tanto o risco quanto o custo de oportunidade ao concordarem com
esse contrato, e eles precisariam ser compensados para aceitá-lo.
Alice pode tornar isso atraente tanto para Bob quanto para Chan oferecendo a eles taxas de uma
moeda de ouro cada, se eles transmitirem seu pagamento para Dina.
5
No contrato, então, estaria escrito:
Eu, Alice, reembolsarei você, Bob, com 12 moedas de ouro se você puder me
provar (por exemplo, por meio de um recibo) que você entregou 11 moedas de
ouro a Chan.
Alice agora promete a Bob 12 moedas de ouro. São 10 para serem entregues a Dina e 2 como taxas.
Ela promete 12 a Bob se ele puder provar que repassou 11 para Chan. A diferença de uma moeda de
ouro é a taxa que Bob ganhará por ajudar com esse pagamento específico. Na Alice paga Bob, Bob
paga Chan, Chan paga Dina vemos como esse arranjo permitiria que 10 moedas de ouro chegassem
a Dina por meio de Bob e Chan.
Figure 5. Alice paga Bob, Bob paga Chan, Chan paga Dina
Devido à questão da confiança e ao risco de que Alice ou Bob não cumpram o contrato, todas as
partes decidem usar um serviço de custódia. No início da transação, Alice poderia "travar" essas 12
moedas de ouro em uma custódia que só será paga a Bob quando ele provar que pagou 11 moedas
de ouro para Chan.
Este serviço de custódia é idealizado e não introduz outros riscos (por exemplo, risco de
contraparte). Mais tarde, veremos como podemos substituir a custódia por um contrato inteligente
do Bitcoin. Por enquanto, vamos supor que todos confiam nesse serviço de custódia.
Na Lightning Network, o comprovante (prova de pagamento) poderia assumir a forma de um

segredo que apenas Dina conhece. Na prática, esse segredo seria um número aleatório grande o
suficiente para evitar que outros o adivinhem (normalmente, um número muito, muito grande,
codificado usando 256 bits!).
Dina gera esse valor secreto R de um gerador de números aleatórios.
O segredo poderia então ser comprometido com o contrato incluindo o hash SHA-256 do segredo no
próprio contrato, da seguinte forma:
<li>H = SHA-256(R)</li>
6
</ul>
Chamamos esse hash do segredo do pagamento de payment hash. O segredo que "desbloqueia" o
pagamento é chamado de payment secret.
Por enquanto, vamos manter as coisas simples e assumir que o segredo de Dina é simplesmente a
linha de texto: Dinas secret. Essa mensagem secreta é chamada de payment secret ou payment
preimage.
Para "comprometer-se" com esse segredo, Dina calcula o hash SHA-256, que quando codificado em
hexadecimal, pode ser exibido da seguinte forma:
0575965b3b44be51e8057d551c4016d83cb1fba9ea8d6e986447ba33fe69f6b3
Para facilitar o pagamento de Alice, Dina criará o segredo do pagamento (payment secret) e o hash
do pagamento (payment hash), e enviará o hash do pagamento para Alice. Na Dina envia o segredo
hasheado para Alice observamos que Dina envia o hash do pagamento para Alice por meio de
algum canal externo (linha tracejada), como um e-mail ou mensagem de texto.
Figure 6. Dina envia o segredo hasheado para Alice
Alice não conhece o segredo, mas ela pode reescrever seu contrato para usar o hash do segredo
como prova de pagamento:
Eu, Alice, vou reembolsá-lo, Bob, com 12 moedas de ouro se você puder me
mostrar uma mensagem válida que resulta no hash:`057596`…. Você pode
obter essa mensagem configurando um contrato semelhante com Chan, que
deve configurar um contrato semelhante com Dina. Para garantir que você
seja reembolsado, fornecerei as 12 moedas de ouro a um serviço de custódia
confiável antes de você configurar seu próximo contrato.
Este novo contrato agora protege Alice de Bob não encaminhar para Chan, protege Bob de não ser
reembolsado por Alice e garante que haverá uma prova de que Dina foi finalmente paga por meio
do hash do segredo de Dina.
7
Depois que Bob e Alice concordarem com o contrato, e Bob receber a mensagem do serviço de
custódia de que Alice depositou as 12 moedas de ouro, Bob pode agora negociar um contrato
semelhante com Chan.
Observe que, como Bob está cobrando uma taxa de serviço de 1 moeda, ele só encaminhará 11
moedas de ouro para Chan quando Chan mostrar prova de que ele pagou Dina. Da mesma forma,
Chan também exigirá uma taxa e espera receber 11 moedas de ouro assim que ele provar que
pagou a Dina as 10 moedas de ouro prometidas.
O contrato de Bob com Chan será:
Eu, Bob, reembolsarei você, Chan, com 11 moedas de ouro se você puder me
mostrar uma mensagem válida que gere o hash:`057596`…. Você pode obter
essa mensagem configurando um contrato semelhante com Dina. Para
garantir que você será reembolsado, vou fornecer as 11 moedas de ouro para
um agente de custódia confiável antes de você configurar seu próximo
contrato.
Uma vez que Chan recebe a mensagem do agente de custódia informando que Bob depositou as 11
moedas de ouro, Chan configura um contrato semelhante com Dina:
Eu, Chan, vou te reembolsar, Dina, com 10 moedas de ouro se você puder me
mostrar uma mensagem válida que tenha o hash de:`057596`…. Para
garantir que você será reembolsado após revelar o segredo, vou fornecer as
10 moedas de ouro a um agente de custódia confiável.
Tudo está agora no lugar. Alice tem um contrato com Bob e colocou 12 moedas de ouro em custódia.
Bob tem um contrato com Chan e colocou 11 moedas de ouro em custódia. Chan tem um contrato
com Dina e colocou 10 moedas de ouro em custódia. Agora cabe a Dina revelar o segredo, que é a
pré-imagem do hash que ela estabeleceu como prova de pagamento.
Dina agora envia Dinas secret para Chan.
Chan verifica que Dinas secret é hasheado como 057596…. Chan agora tem a prova de pagamento e
instrui o serviço de custódia a liberar as 10 moedas de ouro para Dina.
Chan agora fornece o segredo para Bob. Bob verifica e instrui o serviço de custódia a liberar as 11
moedas de ouro para Chan.
Bob agora fornece o segredo para Alice. Alice verifica e instrui o serviço de custódia a liberar 12
moedas de ouro para Bob.
Todos os contratos já estão liquidados. Alice pagou um total de 12 moedas de ouro, sendo que 1 foi
recebida por Bob, 1 foi recebida por Chan e 10 foram recebidas por Dina. Com uma cadeia de
contratos como essa em vigor, Bob e Chan não poderiam fugir com o dinheiro, pois eles o
depositaram em custódia primeiro.
8
No entanto, um problema ainda permanece. Se Dina se recusasse a revelar sua pré-imagem secreta,
então Chan, Bob e Alice teriam suas moedas presas em custódia, mas não seriam reembolsados. E
de forma semelhante, se alguém mais ao longo da cadeia deixasse de passar o segredo, a mesma
situação aconteceria. Portanto, embora ninguém possa roubar dinheiro de Alice, todos teriam seu
dinheiro retido permanentemente em depósito.
Felizmente, isso pode ser resolvido adicionando um prazo ao contrato.
Podemos alterar o contrato para que, se não for cumprido dentro de um prazo específico, ele expire
e o serviço de custódia devolva o dinheiro à pessoa que fez o depósito original. Chamamos esse
prazo de timelock.
O depósito é bloqueado com o serviço de custódia por um determinado período de tempo e é

eventualmente liberado mesmo que nenhuma prova de pagamento tenha sido fornecida.
Para levar isso em consideração, o contrato entre Alice e Bob é novamente alterado com uma nova
cláusula:
Bob tem 24 horas para revelar o segredo após a assinatura do contrato. _Se
Bob não fornecer o segredo dentro desse prazo, o depósito de Alice será
reembolsado pelo serviço de custódia e o contrato se tornará inválido.
Bob, é claro, agora precisa garantir que ele receba a prova de pagamento dentro de 24 horas.
Mesmo se ele pagar com sucesso a Chan, se ele receber a prova de pagamento após 24 horas, ele
não será reembolsado. Para remover esse risco, Bob deve estabelecer um prazo ainda mais curto
para Chan.
Por sua vez, Bob alterará seu contrato com Chan da seguinte forma:
Chan tem 22 horas para mostrar o segredo após a assinatura do contrato. Se

ele não fornecer o segredo dentro desse prazo, o depósito de Bob será
reembolsado pelo serviço de custódia e o contrato será invalidado.
Como você deve ter adivinhado, Chan também alterará seu contrato com Dina:
Dina tem 20 horas para mostrar o segredo após a assinatura do contrato. Se

ela não fornecer o segredo até esse momento, o depósito de Chan será
devolvido pelo serviço de custódia e o contrato se tornará inválido.
Com essa cadeia de contratos podemos garantir que, após 24 horas, o pagamento passará com
sucesso de Alice para Bob para Chan para Dina, ou falhará e todos serão reembolsados. Ou o
contrato falha ou é bem-sucedido, não há meio termo.
No contexto da Lightning Network, chamamos essa propriedade de "tudo ou nada" de atomicidade.
Desde que o serviço de garantia seja confiável e cumpra fielmente suas obrigações, nenhuma das
partes terá suas moedas roubadas no processo.
9
A pré-condição para que essa rota funcione é que todas as partes no caminho tenham dinheiro
suficiente para atender à série necessária de depósitos.
Embora isso possa parecer um detalhe menor, veremos mais adiante neste capítulo que esse
requisito é realmente um dos problemas mais difíceis para os nós da LN. Torna-se
progressivamente mais difícil à medida que o tamanho do pagamento aumenta. Além disso, as
partes não podem usar seu dinheiro enquanto ele estiver bloqueado em custódia.
Assim, os usuários que encaminham pagamentos enfrentam um custo de oportunidade ao bloquear

o dinheiro, que é eventualmente reembolsado por meio das taxas de roteamento, como vimos no
exemplo anterior.
Agora que vimos um exemplo de roteamento de pagamentos físicos, veremos como isso pode ser
implementado na blockchain do Bitcoin, sem a necessidade de um serviço de custódia de terceiros.
Para isso, configuraremos os contratos entre os participantes usando o Bitcoin Script. Substituímos
o serviço de custódia de terceiros por smart contracts que implementam um protocolo de justiça.
Vamos entender esse conceito e implementá-lo!
Protocolo de Justiça
Como vimos no primeiro capítulo deste livro, a inovação do Bitcoin está na capacidade de usar
primitivas criptográficas para implementar um protocolo de justiça que substitui a confiança em
terceiros (intermediários) por um protocolo confiável.
No nosso exemplo das moedas de ouro, precisamos de um serviço de custódia para evitar que
qualquer uma das partes descumprisse suas obrigações. A inovação dos protocolos criptográficos
de justiça nos permite substituir o serviço de custódia por um protocolo.
As propriedades do protocolo de justiça que queremos criar são:
Operação sem confiança

Os participantes de um pagamento roteado não precisam confiar uns nos outros, ou em
qualquer intermediário ou terceiro. Em vez disso, eles confiam no protocolo para protegê-los de
trapaças.
Atomicidade
Ou o pagamento é totalmente executado, ou falha e todos são reembolsados. Não há
possibilidade de um intermediário cobrar um pagamento roteado e não encaminhá-lo para o
próximo salto (hop). Assim, os intermediários não podem trapacear ou roubar.
Multi-salto
A segurança do sistema se estende de ponta a ponta para pagamentos roteados por vários canais
de pagamento, assim como ocorre em um pagamento entre as duas pontas de um único canal de
pagamento.
Uma propriedade opcional e adicional é a capacidade de dividir pagamentos em várias partes,

mantendo a atomicidade para o pagamento inteiro. Isso é chamado de pagamentos multipartes
(MPP, Multipart Payments) e será explorado mais detalhadamente em [mpp].
10
Implementando Pagamentos Atômicos Sem Confiança Multi-Salto
Bitcoin Script é flexível o suficiente para permitir dezenas de maneiras de implementar um

protocolo de justiça com as propriedades de atomicidade, operação sem confiança e segurança
multihop. A escolha de uma implementação específica depende de certas compensações entre
privacidade, eficiência e complexidade.
O protocolo de justiça usado atualmente no roteamento da Lightning Network é chamado de

contrato de tempo bloqueado por hash (HTLC, na sigla em inglês). Os HTLCs usam uma pré-imagem
de hash como o segredo que desbloqueia um pagamento, como vimos no exemplo das moedas de
ouro neste capítulo. O destinatário de um pagamento gera um número secreto aleatório e calcula
seu hash. O hash se torna a condição do pagamento e, uma vez que o segredo é revelado, todos os
participantes podem resgatar seus pagamentos recebidos. Os HTLCs oferecem atomicidade,
operação sem confiança e segurança multihop (multi-salto).
Outro mecanismo proposto para implementar o roteamento é um Contrato Bloqueado por Ponto no
Tempo (PTLC, Point Time-Locked Contract). Os PTLCs também alcançam atomicidade, operação sem
confiança e segurança multihop, mas o fazem com maior eficiência e melhor privacidade. A
implementação eficiente dos PTLCs depende de um novo algoritmo de assinatura digital chamado
assinaturas Schnorr, que se espera ser ativado no Bitcoin em 2021.
Revisitando o Exemplo da Gorjeta

Vamos revisitar nosso exemplo da primeira parte deste capítulo. Alice quer dar uma gorjeta para
Dina com um pagamento na Lightning. Digamos que Alice queira enviar 50.000 satoshis para Dina
como gorjeta.
Para que Alice pague Dina, Alice precisará que o nó de Dina gere uma fatura na Lightning.
Discutiremos isso com mais detalhes no [invoices]. Por enquanto, vamos supor que Dina tenha um
website que possa produzir uma fatura na Lightning para gorjetas.
Pagamentos na Lightning podem ser enviados sem uma fatura usando um recurso chamado
keysend, que discutiremos com mais detalhes em [keysend]. Por enquanto, vamos explicar o
fluxo de pagamento mais simples usando uma fatura.
Alice visita o site de Dina, insere a quantia de 50.000 satoshis em um formulário e, em resposta, o
nó da Lightning de Dina gera uma solicitação de pagamento de 50.000 satoshis na forma de uma
fatura da Lightning. Essa interação ocorre pela web e fora da Lightning Network, como mostrado
na Alice solicita fatura no site da Dina.
11
Figure 7. Alice solicita fatura no site da Dina
Como vimos em exemplos anteriores, supomos que Alice não possui um canal de pagamento direto
para Dina. Em vez disso, Alice possui um canal com Bob, Bob possui um canal com Chan e Chan
possui um canal com Dina. Para pagar Dina, Alice deve encontrar um caminho que a conecte a
Dina. Discutiremos esse passo em mais detalhes no [path_finding]. Por enquanto, vamos supor que
Alice consiga reunir informações sobre os canais disponíveis e veja que existe um caminho dela
para Dina, passando por Bob e Chan.
Lembre-se de como Bob e Chan podem esperar uma pequena compensação por encaminhar o
pagamento por meio de seus nós? Alice quer pagar 50.000 satoshis a Dina, mas, como veremos
nas seções seguintes, ela enviará 50.200 satoshis para Bob. Os 200 satoshis extras pagarão 100
satoshis cada para Bob e Chan, como taxa de roteamento.
Agora, o nó de Alice pode construir um pagamento da Lightning. Nas próximas seções, veremos
como o nó de Alice constrói um HTLC para pagar Dina e como esse HTLC é encaminhado ao longo
do caminho de Alice para Dina.
Liquidação On-Chain Versus Off-Chain de HTLCs
O objetivo da Lightning Network é permitir transações off-chain (fora da cadeia de blocos) que
sejam tão confiáveis quanto as transações on-chain (dentro da cadeia de blocos), porque ninguém
pode trapacear. A razão pela qual ninguém pode trapacear é porque a qualquer momento,
qualquer um dos participantes pode levar suas transações fora da cadeia para dentro da cadeia.
Cada transação fora da cadeia está pronta para ser enviada para a blockchain do Bitcoin a qualquer
momento. Assim, a blockchain do Bitcoin atua como um mecanismo de resolução de disputas e
liquidação final, se necessário.
O simples fato de que qualquer transação pode ser levada para a blockchain a qualquer momento é
precisamente o motivo pelo qual todas essas transações podem ser mantidas fora da cadeia. Se você
sabe que tem uma solução de recurso, pode continuar cooperando com os outros participantes e
evitar a necessidade de liquidação na cadeia e taxas adicionais.
Em todos os exemplos que seguem, vamos assumir que qualquer uma dessas transações pode ser
realizada on-chain a qualquer momento. Os participantes escolherão mantê-las off-chain, mas não
há diferença na funcionalidade do sistema, exceto pelas taxas mais altas e pelo atraso imposto pela
12
mineração das transações na blockchain. O exemplo funciona da mesma forma se todas as
transações forem realizadas na blockchain ou fora dela.
Contratos de Hash Bloqueados por Tempo (HTLC)

Nesta sessão explicamos como HTLCs funcionam.
A primeira parte de um HTLC é o hash. Isso se refere ao uso de um algoritmo de hash criptográfico
para se comprometer com um segredo gerado aleatoriamente. O conhecimento desse segredo
permite a realização do pagamento. A função de hash criptográfica garante que seja praticamente
impossível para alguém adivinhar a pré-imagem do segredo, mas é fácil para qualquer pessoa
verificar o hash, e só há uma pré-imagem possível que resolve a condição de pagamento.
Na Alice recebe um hash de pagamento de Dina vemos Alice recebendo uma fatura Relâmpago de
Dina. Dentro dessa faturaDina codificou um hash de pagamento, que é o hash criptográfico de um
segredo produzido pelo nó de Dina.O segredo de Dina é chamado de pré-imagem de pagamento. O
hash de pagamento atua como um identificador que pode ser usado para rotear o pagamento até
Dina. A pré-imagem de pagamento atua como um recibo e prova de pagamento uma vez que o
pagamento estiver completo.
Figure 8. Alice recebe um hash de pagamento de Dina
Na Lightning Network, a pré-imagem de pagamento de Dina não será uma frase como Dinas secret,
mas sim um número aleatório gerado pelo nó de Dina. Vamos chamar esse número aleatório de R.
O nó de Dina calculará um hash criptográfico de R, tal que:
<li>H = SHA-256(R)</li>
</ul>
Nesta equação, H é o hash, ou payment hash e R é o segredo ou payment preimage.
O uso de uma função de hash criptográfica é um elemento que garante a operação sem confiança.
Os intermediários de pagamento não precisam confiar uns nos outros porque eles sabem que
ninguém pode adivinhar o segredo ou falsificá-lo.
13
HTLCs em Bitcoin Script
No nosso exemplo das moedas de ouro, Alice tinha um contrato aplicado por uma garantia como
esta:
Alice reembolsará Bob com 12 moedas de ouro se ele puder mostrar uma
mensagem válida que faça hash para: 0575...f6b3. Bob tem 24 horas para
mostrar o segredo após a assinatura do contrato. Se Bob não fornecer o
segredo dentro desse prazo, o depósito de Alice será reembolsado pelo serviço
de garantia e o contrato será considerado inválido.
Vamos ver como implementar isso como um HTLC em Bitcoin Script. No HTLC implementado em
Bitcoin Script (BOLT #3) nós vemos um Bitcoin Script HTLC como usado atualmente na Rede
Relâmpago. Você pode encontrar esta definição em BOLT #3, Transactions.
Example 1. HTLC implementado em Bitcoin Script (BOLT #3)
# To remote node with revocation key

OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_IF
# To local node via HTLC-success transaction.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node after timeout.
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_CHECKSIG
OP_ENDIF
OP_ENDIF
Nossa, parece complicado! Não se preocupe, vamos dar um passo de cada vez e simplificá-lo.
O Bitcoin Script atualmente usado na Rede Lightning é bastante complexo, pois é otimizado para
eficiência de espaço on-chain, o que o torna muito compacto, porém difícil de ler.
Nas seções a seguir, vamos nos concentrar nos principais elementos do script e apresentar scripts
simplificados que são ligeiramente diferentes do que é realmente usado na Lightning.
A parte principal do HTLC está na linha 10 do HTLC implementado em Bitcoin Script (BOLT #3).
Vamos construí-lo do zero!
14
Pré-imagem de Pagamento e Verificação de Hash
O cerne de um HTLC é o hash, onde o pagamento pode ser feito se o destinatário conhecer a pré-
imagem do pagamento. Alice bloqueia o pagamento para um hash de pagamento específico, e Bob
deve apresentar uma pré-imagem de pagamento para reivindicar os fundos. O sistema Bitcoin pode
verificar se a pré-imagem de pagamento de Bob está correta, fazendo o hash dela e comparando o
resultado com o hash de pagamento que Alice usou para bloquear os fundos.
Essa parte de um HTLC pode ser implementada no Bitcoin Script da seguinte maneira:
OP_SHA256 <H> OP_EQUAL
Alice pode criar uma transação de saída que paga 50.200 satoshis com um script de bloqueio acima,
substituindo <H> pelo valor do hash 0575...f6b3 fornecido por Dina. Em seguida, Alice pode assinar
essa transação e oferecê-la a Bob:
Alice’s offers a 50,200 satoshi HTLC to Bob
OP_SHA256 0575...f6b3 OP_EQUAL
Bob não pode gastar esse HTLC até que ele saiba o segredo de Dina, portanto, gastar o HTLC é
condicionado ao cumprimento do pagamento por Bob até Dina.
Depois que Bob obtiver o segredo de Dina, ele poderá gastar essa saída com um script de
desbloqueio contendo o valor da pré-imagem secreta R.
A combinação do script de desbloqueio com o script de bloqueio resultaria em:
<R> OP_SHA256 <H> OP_EQUAL
O mecanismo Bitcoin Script avaliaria esse script da seguinte forma:
1. R é colocado na pilha.
2. O operador OP_SHA256 pega o valor R da pilha e faz o hash, colocando o resultado H~R~ na pilha.
3. H é colocado na pilha.
4. O operador OP_EQUAL compara H e H~R~. Se forem iguais, o resultado é TRUE, o script está
completo e o pagamento é verificado.
Estendendo HTLCs de Alice para Dina
Agora, Alice irá estender o HTLC através da rede para que ele alcance Dina.
Na Propagando o HTLC pela rede, nós vemos o HTLC propagado pela rede de Alice para Dina. Alice
deu a Bob um HTLC de 50.200 satoshis. Agora, Bob pode criar um HTLC de 50.100 satoshis e
entregá-lo para Chan.
15
Bob sabe que Chan não pode resgatar o HTLC de Bob sem transmitir o segredo, momento em que
Bob também pode usar o segredo para resgatar o HTLC de Alice. Este é um ponto muito importante
porque garante a atomicidade ponta a ponta do HTLC. Para gastar o HTLC, é necessário revelar o
segredo, o que possibilita que outras pessoas também gastem seus HTLCs. Ou todos os HTLCs são
resgatáveis, ou nenhum dos HTLCs é resgatável: atomicidade!
Como o HTLC de Alice é 100 satoshis a mais do que o HTLC que Bob deu a Chan, Bob receberá 100
satoshis como taxa de roteamento se esse pagamento for concluído.
Bob não está correndo riscos e não está confiando em Alice ou Chan. Em vez disso, Bob está
confiando que uma transação assinada, juntamente com o segredo, será resgatável na blockchain
do Bitcoin.
Figure 9. Propagando o HTLC pela rede
Da mesma forma, Chan pode estender um HTLC de 50.000 para Dina. Ele não está arriscando nada
ou confiando em Bob ou Dina. Para resgatar o HTLC, Dina teria que transmitir o segredo, que Chan
poderia usar para resgatar o HTLC de Bob. Chan também ganharia 100 satoshis como taxa de
roteamento.
Retropropagando o Segredo
Depois que Dina recebe um HTLC de 50.000 de Chan, ela agora pode receber o pagamento. Dina
poderia simplesmente comprometer esse HTLC na cadeia e gastá-lo revelando o segredo na
transação de gasto. Ou, em vez disso, Dina pode atualizar o saldo do canal com Chan, fornecendo a
ele o segredo. Não há motivo para incorrer em uma taxa de transação e ir para a cadeia (on-chain).
Então, em vez disso, Dina envia o segredo para Chan, e eles concordam em atualizar seus saldos de
canal para refletir um pagamento Lightning de 50.000 satoshis para Dina. Na Dina liquida o HTLC
de Chan fora da cadeia (off-chain) nós vemos Dina dando o segredo para Chan, cumprindo assim o
HTLC.
16
Figure 10. Dina liquida o HTLC de Chan fora da cadeia (off-chain)
Observe que o saldo do canal de Dina passa de 50.000 satoshis para 100.000 satoshis. O saldo do
canal de Chan é reduzido de 200.000 satoshis para 150.000 satoshis. A capacidade do canal não
mudou, mas 50.000 satoshis foram transferidos do lado de Chan do canal para o lado de Dina do
canal.
Agora, Chan tem o segredo e pagou a Dina 50.000 satoshis. Ele pode fazer isso sem nenhum risco,
porque o segredo permite que Chan resgate o HTLC de 50.100 de Bob. Chan tem a opção de
comprometer esse HTLC na cadeia e gastá-lo revelando o segredo na blockchain do Bitcoin. Mas,
assim como Dina, ele prefere evitar taxas de transação. Então, em vez disso, ele envia o segredo
para Bob para que eles possam atualizar seus saldos de canal para refletir um pagamento Lightning
de 50.100 satoshis de Bob para Chan. Na Chan liquida o HTLC de Bob off-chain nós vemos Chan
enviando o segredo para Bob e recebendo um pagamento em troca.
Figure 11. Chan liquida o HTLC de Bob off-chain
Chan pagou 50.000 satoshis para Dina e recebeu 50.100 satoshis de Bob. Portanto, Chan possui 100
satoshis a mais em seus saldos de canal, que ele ganhou como taxa de roteamento.
Agora, Bob também possui o segredo. Ele pode usá-lo para gastar o HTLC de Alice na cadeia. Ou, ele
pode evitar taxas de transação ao liquidar o HTLC no canal com Alice. Na Bob liquida o HTLC de
17
Alice off-chain nós vemos que Bob envia o segredo para Alice e eles atualizam o saldo do canal para
refletir um pagamento Lightning de 50.200 satoshi de Alice para Bob.
Figure 12. Bob liquida o HTLC de Alice off-chain
Bob recebeu 50.200 satoshi de Alice e pagou 50.100 satoshi para Chan, então ele tem um extra de
100 satoshi em seus saldos de canal provenientes das taxas de roteamento.
Alice recebe o segredo e liquidou o HTLC de 50.200 satoshi. O segredo pode ser usado como um
recibo para provar que Dina foi paga para aquele hash de pagamento específico.
Os saldos finais do canal refletem o pagamento de Alice para Dina e as taxas de roteamento pagas
em cada salto, conforme mostrado na Saldos do canal após o pagamento.
Figure 13. Saldos do canal após o pagamento
Vinculação de Assinatura: Prevenindo o Roubo de HTLCs
Há uma pegadinha. Você notou?
Se Alice, Bob e Chan criarem os HTLCs conforme mostrado na Saldos do canal após o pagamento,
eles enfrentam um pequeno, mas não insignificante, risco de perda. Qualquer um desses HTLCs
pode ser resgatado (gasto) por qualquer pessoa que conheça o segredo. Inicialmente, apenas Dina
conhece o segredo. Dina deve gastar apenas o HTLC de Chan. Mas Dina poderia gastar os três
HTLCs de uma só vez, ou até mesmo em uma única transação de gasto! Afinal, Dina conhece o
segredo antes de qualquer outra pessoa. Da mesma forma, uma vez que Chan conhece o segredo,
18
ele só deve gastar o HTLC oferecido por Bob. Mas e se Chan também gastar o HTLC oferecido por
Alice?
Isso não é sem confiança! Ele falha no recurso de segurança mais importante. Precisamos consertar
isso.
O script do HTLC deve ter uma condição adicional que vincula cada HTLC a um destinatário
específico. Isso é feito exigindo uma assinatura digital que corresponda à chave pública de cada
destinatário, impedindo assim que qualquer outra pessoa gaste aquele HTLC. Como apenas o
destinatário designado tem a capacidade de produzir uma assinatura digital correspondente àquela
chave pública, somente o destinatário designado pode gastar aquele HTLC.
Vamos analisar os scripts novamente levando em consideração essa modificação. O HTLC de Alice
para Bob é modificado para incluir a chave pública de Bob e o operador OP_CHECKSIG.
Aqui está o script HTLC modificado:
OP_SHA256 <H> OP_EQUALVERIFY <Bob's Pub> OP_CHECKSIG
Observe que também alteramos o OP_EQUAL para OP_EQUALVERIFY. Quando um operador

possui o sufixo VERIFY, ele não retorna TRUE ou FALSE na pilha. Em vez disso, ele interrompe a
execução e falha o script se o resultado for falso e continua sem nenhuma saída na pilha se for
verdadeiro.
Para resgatar esse HTLC, Bob deve apresentar um script de desbloqueio que inclua uma assinatura
da chave privada de Bob, bem como a pré-imagem secreta do pagamento, como este exemplo:
<Bob's Signature> <R>
Os scripts de desbloqueio e bloqueio são combinados e avaliados pelo mecanismo de script, como
segue:
<Bob's Sig> <R> OP_SHA256 <H> OP_EQUALVERIFY <Bob's Pub> OP_CHECKSIG
1. +<Bob’s Sig> + é colocado na pilha.
2. R é colocado na pilha.
3. OP_SHA256 retira e faz o hash do valor R do topo da pilha e coloca o resultado H~R~ na pilha.
4. H é colocado na pilha.
5. OP_EQUALVERIFY mostra H e H~R~ e os compara. Se não forem iguais, a execução é

interrompida. Caso contrário, continuamos sem saída para a pilha.
6. A chave pública de Bob, <Bob's Pub>, é inserida na pilha.
7. OP_CHECKSIG retira <Bob's Sig> e <Bob's Pub> da pilha e verifica a assinatura. O resultado
19
(TRUE/FALSE) é inserido na pilha.
Como você pode ver, isso é um pouco mais complicado, mas agora corrigimos o HTLC e garantimos
que apenas o destinatário pretendido possa gastá-lo.
Otimização de Hash
Vamos dar uma olhada na primeira parte do script do HTLC até agora:
OP_SHA256 <H> OP_EQUALVERIFY
Se olharmos isso na representação simbólica anterior, parece que os operadores OP_ ocupam a
maior parte do espaço. Mas isso não é verdade. O Bitcoin Script é codificado em binário, sendo que
cada operador representa um byte. Enquanto isso, o valor <H> que usamos como marcador de
posição para o hash de pagamento é um valor de 32 bytes (256 bits). Você pode encontrar uma lista
de todos os operadores do Bitcoin Script e sua codificação binária e hexadecimal em Bitcoin Wiki:
Script, ou em Appendix D, "Transaction Script Language Operators, Constants, and Symbols," in
Mastering Bitcoin.
Representado em hexadecimal, nosso script HTLC ficaria assim:
a8 0575965b3b44be51e8057d551c4016d83cb1fba9ea8d6e986447ba33fe69f6b3 88
Na codificação hexadecimal, OP_SHA256 é a8 e OP_EQUALVERIFY é 88. O comprimento total deste

script é de 34 bytes, dos quais 32 bytes são o hash.
Conforme mencionado anteriormente, qualquer participante na Lightning Network deve ser capaz
de pegar uma transação off-chain que possuem e levá-la para a blockchain se precisarem executar
sua reivindicação aos fundos. Para levar uma transação para a cadeia de blocos, eles precisariam
pagar taxas de transação aos mineradores, e essas taxas são proporcionais ao tamanho, em bytes,
da transação.
Portanto, queremos encontrar maneiras de minimizar o "peso" das transações on-chain,

otimizando o script o máximo possível. Uma maneira de fazer isso é adicionar outra função de hash
em cima do algoritmo SHA-256, uma que produza hashes menores. A linguagem Bitcoin Script
fornece o operador OP_HASH160 que "faz o hash duas vezes" de uma pré-imagem: primeiro a pré-
imagem é hasheada com SHA-256 e, em seguida, o hash resultante é hasheado novamente com o
algoritmo de hash RIPEMD160. O hash resultante do RIPEMD160 tem 160 bits ou 20 bytes, o que é
muito mais compacto. No Bitcoin Script, essa é uma otimização muito comum que é usada em
muitos dos formatos de endereço comuns.
Então, vamos usar essa otimização em vez disso. Nosso hash SHA-256 é 057596...69f6b3. Passando
por mais uma rodada de hashing com RIPEMD160, obtemos o resultado:
R = "Dinas secret"
H256 = SHA256(R)
H256 = 0575965b3b44be51e8057d551c4016d83cb1fba9ea8d6e986447ba33fe69f6b3
20
H160 = RIPEMD160(H256)
H160 = 9e017f6767971ed7cea17f98528d5f5c0ccb2c71
Alice pode calcular o hash RIPEMD160 do hash de pagamento que Dina fornece e usar o hash mais
curto em seu HTLC, assim como Bob e Chan podem fazer o mesmo!
O script "otimizado" do HTLC ficaria assim:
OP_HASH160 <H160> OP_EQUALVERIFY
Codificado em hexadecimal, é assim:
a9 9e017f6767971ed7cea17f98528d5f5c0ccb2c71 88
Onde OP_HASH160 é a9 e OP_EQUALVERIFY é 88. Este script tem apenas 22 bytes de comprimento!
Economizamos 12 bytes em cada transação que resgata um HTLC on-chain.
Com essa otimização, agora você pode ver como chegamos ao script HTLC mostrado na linha 10 do
HTLC implementado em Bitcoin Script (BOLT #3):
...
# To local node via HTLC-success transaction.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY...
HTLC Cooperativo e Falha por Tempo Limite
Até agora, analisamos a parte do "hash" do HTLC e como funcionaria se todos cooperassem e
estivessem online no momento do pagamento.
O que acontece se alguém ficar offline ou não cooperar? O que acontece se o pagamento não for
bem-sucedido?
Precisamos garantir uma maneira de "falhar de forma graciosa", pois falhas ocasionais no
roteamento são inevitáveis. Existem duas formas de falhar: cooperativamente e com um reembolso
bloqueado por tempo.
A falha cooperativa é relativamente simples: o HTLC é desfeito por todos os participantes do

caminho, removendo a saída do HTLC de suas transações de compromisso sem alterar o saldo.
Vamos analisar como isso funciona em detalhes no [channel_operation].
Vamos analisar como podemos reverter um HTLC sem a cooperação de um ou mais participantes.
Precisamos garantir que, se um dos participantes não cooperar, os fundos não fiquem
simplesmente bloqueados no HTLC para sempre. Isso daria a alguém a oportunidade de reter os
fundos de outro participante como resgate: "Eu vou deixar seus fundos bloqueados para sempre se
você não me pagar resgate."
21
Para evitar isso, cada script do HTLC inclui uma cláusula de reembolso que está vinculada a um
tempo de bloqueio. Lembra do nosso contrato de garantia original? "Bob tem 24 horas para mostrar
o segredo depois que o contrato é assinado. Se Bob não fornecer o segredo até esse momento, o
depósito de Alice será reembolsado."
O reembolso bloqueado por tempo é uma parte importante do script que garante a atomicidade,
para que o pagamento ponta a ponta inteiro tenha sucesso ou falhe de forma graciosa. Não há um
estado de "meio pago" com o qual se preocupar. Em caso de falha, cada participante pode desfazer
cooperativamente o HTLC com seu parceiro de canal ou colocar unilateralmente a transação de
reembolso bloqueado por tempo na cadeia on-chain) para recuperar seu dinheiro.
Para implementar esse reembolso no Bitcoin Script, usamos um operador especial

O⁠P⁠_⁠C⁠H⁠E⁠C⁠K⁠L⁠O⁠C⁠K⁠T⁠I⁠M⁠EV⁠E⁠R⁠I⁠F⁠Y também conhecido como OP_CLTV em resumo. Aqui está o
script, como visto anteriormente na linha 13 do HTLC implementado em Bitcoin Script (BOLT #3):
...
OP_CHECKSIG
...
O operador OP_CLTV pega um tempo de expiração definido como a altura do bloco após a qual essa
transação é válida. Se o tempo de bloqueio da transação não for definido como o mesmo que
<cltv_expiry>, a avaliação do script falha e a transação é inválida. Caso contrário, o script continua
sem nenhuma saída na pilha. Lembre-se de que o sufixo VERIFY significa que esse operador não
gera as saídas TRUE ou FALSE, mas, em vez disso, ele interrompe/falha ou continua sem saída na
pilha.
Essencialmente, o OP_CLTV atua como um "porteiro", impedindo que o script prossiga caso a altura
do bloco <cltv_expiry> não foi atingida na blockchain do Bitcoin.
O operador OP_DROP simplesmente derruba o item mais acima da pilha de script. Isso é necessário
no início porque há um item "excedente" das linhas de script anteriores. É necessário após o
OP_CLTV para remover o item <cltv_expiry> do topo da pilha porque não é mais necessário.
Finalmente, após a limpeza da pilha, deve restar uma chave pública e uma assinatura que o
OP_CHECKSIG pode verificar. Como vimos em Vinculação de Assinatura: Prevenindo o Roubo de
HTLCs, isso é necessário para garantir que apenas o legítimo proprietário dos fundos possa
reivindicá-los, vinculando essa saída à sua chave pública e exigindo uma assinatura.
Bloqueios de Tempo Decrementais
À medida que os HTLCs são estendidos de Alice para Dina, a cláusula de reembolso bloqueada por
tempo (time-locked refund clause) em cada HTLC possui um valor de cltv_expiry diferente. Veremos
isso com mais detalhes no [onion_routing]. Mas basta dizer que, para garantir um desenrolar
ordenado de um pagamento que falha, cada salto precisa esperar um pouco menos pelo reembolso.
A diferença entre os tempos limite para cada salto é chamada de cltv_expiry_delta e é definida por
cada nó e divulgada para a rede, como veremos no [gossip].
22
Por exemplo, Alice define o tempo limite de reembolso no primeiro HTLC para uma altura de bloco
de "atual + 500 blocos" ("atual" sendo a altura do bloco atual). Bob, então, define o tempo limite
cltv_expiry no HTLC para Chan como "atual + 450 blocos". Chan define o tempo limite como "atual +
400 blocos" a partir da altura do bloco atual. Dessa forma, Chan pode obter um reembolso no HTLC
que ele ofereceu a Dina antes de Bob obter um reembolso no HTLC que ele ofereceu a Chan. Bob
pode obter um reembolso no HTLC que ele ofereceu a Chan antes que Alice possa obter um
reembolso pelo HTLC que ela ofereceu a Bob. O decremento do tempo limite evita condições de
corrida e garante que a cadeia de HTLC seja desfeita de trás para frente, do destino para a origem.
Conclusão
Neste capítulo, vimos como Alice pode pagar Dina mesmo que ela não tenha um canal de
pagamento direto. Alice pode encontrar um caminho que a conecte a Dina e rotear um pagamento
por vários canais de pagamento para que chegue a Dina.
Para garantir que o pagamento seja atômico e sem confiança em vários saltos, Alice deve
implementar um protocolo de justiça em cooperação com todos os nós intermediários no caminho.
O protocolo de justiça é atualmente implementado como um HTLC, que compromete fundos a um
hash de pagamento derivado de uma pré-imagem secreta de pagamento.
Cada um dos participantes na rota de pagamento pode estender um HTLC para o próximo
participante, sem se preocupar com roubo ou fundos retidos. O HTLC pode ser resgatado revelando
a pré-imagem secreta do pagamento. Assim que um HTLC chega a Dina, ela revela a pré-imagem,
que flui de volta, resolvendo todos os HTLCs oferecidos.
Por fim, vimos como uma cláusula de reembolso bloqueada por tempo completa o HTLC,
garantindo que cada participante possa obter um reembolso se o pagamento falhar, mas por
qualquer motivo um dos participantes não cooperar na reversão dos HTLCs. Ao sempre ter a opção
de ir para a blockchain para obter um reembolso, o HTLC alcança o objetivo de justiça de
atomicidade e operação sem confiança.
23
Operação de Canal e Encaminhamento de
Pagamentos
Neste capítulo, vamos reunir os canais de pagamento e os contratos hash time bloqueados (HTLCs).
No [payment_channels], explicamos como Alice e Bob constroem um canal de pagamento entre
seus dois nós. Também examinamos os mecanismos de compromisso e penalidade que garantem a
segurança do canal de pagamento. No [routing], analisamos os HTLCs e como eles podem ser
usados para encaminhar um pagamento por um caminho composto por vários canais de
pagamento. Neste capítulo, unimos os dois conceitos ao examinar como os HTLCs são gerenciados
em cada canal de pagamento, como os HTLCs são comprometidos com o estado do canal e como são
liquidados para atualizar os saldos do canal.
Especificamente, discutiremos "Adicionando, liquidando, falhando HTLCs" e a "Máquina de estado

do canal" que forma a sobreposição entre a camada ponto a ponto e a camada de roteamento,
conforme destacado em um esquema na Operação de canais e encaminhamento de pagamentos no
conjunto de protocolos Lightning.
Figure 1. Operação de canais e encaminhamento de pagamentos no conjunto de protocolos Lightning
Local (Canal Único) versus Roteado (Múltiplos Canais)

Mesmo que seja possível enviar pagamentos através de um canal de pagamento simplesmente
atualizando os saldos do canal e criando novas transações de compromisso, o protocolo Lightning
usa HTLCs mesmo para pagamentos "locais" dentro de um canal de pagamento. O motivo para isso
é manter o mesmo design de protocolo, independentemente de o pagamento ter apenas um salto
(através de um único canal de pagamento) ou vários saltos (roteado através de múltiplos canais de
pagamento).
Ao manter a mesma abstração tanto para pagamentos locais quanto remotos, não apenas
simplificamos o design do protocolo, mas também melhoramos a privacidade. Para o destinatário
1
de um pagamento, não há diferença discernível entre um pagamento feito diretamente pelo seu
parceiro de canal e um pagamento encaminhado pelo seu parceiro de canal em nome de outra
pessoa.
Encaminhando Pagamentos e Atualizando

Compromissos com HTLCs
Vamos revisitar nosso exemplo do [routing] para demonstrar como os HTLCs de Alice para Dina são
comprometidos em cada canal de pagamento. Como você se lembra em nosso exemplo, Alice está
pagando a Dina 50.000 satoshis roteando um HTLC por meio de Bob e Chan. A rede é mostrada na
Alice paga Dina com um HTLC roteado via Bob e Chan.
Figure 2. Alice paga Dina com um HTLC roteado via Bob e Chan
Vamos nos concentrar no canal de pagamento entre Alice e Bob e revisar as mensagens e
transações que eles usam para processar este HTLC.
HTLC e Fluxo de Mensagens de Compromisso
O fluxo de mensagens entre Alice e Bob (e também entre qualquer par de parceiros de canal) é
mostrado na O fluxo de mensagens para compromisso HTLC entre parceiros de canal.
2
Figure 3. O fluxo de mensagens para compromisso HTLC entre parceiros de canal
Nós já vimos commitment_signed and revoke_and_ack no [payment_channels]. Agora veremos

como os HTLCs se encaixam no esquema de compromisso. As duas novas mensagens são
update_add_htlc, que Alice usa para solicitar a Bob a adição de um HTLC, e update_fulfill_htlc, que
Bob usa para resgatar o HTLC assim que ele recebe o segredo de pagamento (segredo de Dina).
Encaminhamento de Pagamentos com HTLCs

Alice e Bob começam com um canal de pagamento que possui um saldo de 70.000 satoshis em cada
lado.
Como vimos no [payment_channels], isso significa que Alice e Bob negociaram e cada um possui
transações de compromisso. Essas transações de compromisso são assimétricas, atrasadas e
revogáveis, e se parecem com o exemplo na Transações iniciais de compromisso de Alice e Bob.
3
Figure 4. Transações iniciais de compromisso de Alice e Bob
Adicionando um HTLC
Alice deseja que Bob aceite um HTLC no valor de 50.200 satoshis para encaminhar para Dina. Para
fazer isso, Alice deve enviar os detalhes desse HTLC, incluindo o hash de pagamento e o valor, para
Bob. Bob também precisará saber para onde encaminhá-lo, o que discutiremos em detalhes no
[onion_routing].
Para adicionar o HTLC, Alice inicia o fluxo que vimos na O fluxo de mensagens para compromisso
HTLC entre parceiros de canal enviando a mensagem update_add_htlc para Bob.
A Mensagem update_add_HTLC
Alice envia a mensagem Relâmpago update_add_HTLC para Bob. Essa mensagem é definida em. BOLT
#2: Peer Protocol, update_add_HTLC, e mostrada no exemplo Example 9-1.
Example 1. A mensagem update_add_HTLC
[u64:id]
[u64:amount_msat]
[sha256:payment_hash]
[u32:cltv_expiry]
[1366*byte:onion_routing_packet]
channel_id
Este é o canal que Alice tem com Bob, onde ela deseja adicionar o HTLC. Lembre-se de que Alice
e Bob podem ter vários canais entre si.
4
id
Este é um contador de HTLC e começa em 0 para o primeiro HTLC oferecido a Bob por Alice e é
incrementado para cada HTLC subsequente oferecido.
amount_msat
Este é o valor do HTLC em millisatoshis. No nosso exemplo, isso é igual a 50.200.000 millisatoshis
(ou seja, 50.200 satoshis).
payment_hash
Este é o hash de pagamento calculado a partir da fatura de Dina. É H = RIPEMD160(SHA-256(R)),
onde R é o segredo de Dina, conhecido apenas por ela, e será revelado caso Dina seja paga.
cltv_expiry
Este é o tempo de expiração para este HTLC, que será codificado como um reembolso bloqueado
por tempo no caso do HTLC não atingir Dina dentro desse tempo.
onion_routing_packet
Este é um caminho criptografado em cebola que informa a Bob para onde encaminhar este
HTLC em seguida (para Chan). O roteamento em cebola é abordado em detalhes no
[onion_routing].
Como lembrete, a contabilidade dentro da Lightning Network é feita em unidades de

millisatoshis (milésimos de um satoshi), enquanto a contabilidade do Bitcoin é em satoshis.
Todos os valores nos HTLCs são em millisatoshis, que são arredondados para o satoshi mais
próximo nas transações de compromisso do Bitcoin.
HTLC em Transações de Compromisso
As informações recebidas são suficientes para Bob criar uma nova transação de compromisso. A
nova transação de compromisso possui as mesmas duas saídas to_self e to_remote para o saldo de
Alice e Bob, e uma nova saída representando o HTLC oferecido por Alice.
Já vimos a estrutura básica de um HTLC no [routing]. O script completo de um HTLC oferecido é

definido em BOLT #3: Transactions, Offered HTLC Output e mostrado no Script de saída HTLC
oferecido.
Example 2. Script de saída HTLC oferecido
# Revocation ①
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_HTLCpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_IF
# Redemption ②
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
5
2 OP_SWAP <local_HTLCpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# Refund ③
OP_CHECKSIG
OP_ENDIF
OP_ENDIF
① A primeira cláusula do condicional OP_IF pode ser resgatada por Alice com uma chave de
revogação. Se esse compromisso for posteriormente revogado, Alice terá uma chave de
revogação para reivindicar essa saída em uma transação de penalidade, levando todo o
saldo do canal.
② A segunda cláusula pode ser resgatada pela pré-imagem (segredo de pagamento, ou no

nosso exemplo, o segredo de Dina) se for revelada. Isso permite que Bob reivindique essa
saída se ele tiver o segredo de Dina, o que significa que ele entregou com sucesso o
pagamento para Dina.
③ A terceira e última cláusula é um reembolso do HTLC para Alice se o HTLC expirar sem
chegar a Dina. Ele é bloqueado por tempo com a expiração cltv_expiry. Isso garante que o
saldo de Alice não fique "preso" em um HTLC que não pode ser roteado para Dina.
Há três maneiras de reivindicar essa saída. Tente ler o script e veja se consegue descobrir (lembre-
se de que é uma linguagem baseada em pilha, então as coisas aparecem "invertidas").
Novo Compromisso com Saída HTLC
Agora Bob tem as informações necessárias para adicionar esse script HTLC como uma saída
adicional e criar uma nova transação de compromisso. O novo compromisso de Bob terá 50.200
satoshis na saída HTLC. Essa quantia será retirada do saldo do canal de Alice, então o novo saldo de
Alice será de 19.800 satoshis (70.000 - 50.200 = 19.800). Bob constrói esse compromisso como um
"Commitment #3" tentativo, mostrado na O novo compromisso de Bob com uma saída HTLC.
6
Figure 5. O novo compromisso de Bob com uma saída HTLC
Alice Commits (Compromete)
Logo após enviar a mensagem update_add_htlc, ela se comprometerá com o novo estado do canal,
para que o HTLC possa ser adicionado com segurança por Bob. Bob tem as informações do HTLC e
construiu um novo compromisso, mas ainda não tem esse novo compromisso assinado por Alice.
Alice envia commitment_signed para Bob, com a assinatura para o novo compromisso e para o
HTLC dentro dele. Vimos a mensagem commitment_signed no [payment_channels], mas agora
podemos entender o restante dos campos. Como lembrete, é mostrado no A mensagem
commitment_signed.
Example 3. A mensagem commitment_signed
[u16:num_htlcs]
[num_htlcs*signature:htlc_signature]
7
Os campos num_htlcs e htlc_signature agora fazem mais sentido:
num_htlcs
Este é o número de HTLCs pendentes na transação de compromisso. No nosso exemplo, apenas
um HTLC, o que Alice ofereceu.
htlc_signature
Este é um array de assinaturas (comprimento igual a num_htlcs), contendo assinaturas para as
saídas HTLC.
Alice pode enviar essas assinaturas sem hesitação: ela sempre pode obter um reembolso se o HTLC
expirar sem ser roteado para Dina.
Agora, Bob possui uma nova transação de compromisso assinada, conforme mostrado na Bob tem
um novo compromisso assinado.
Figure 6. Bob tem um novo compromisso assinado
Bob Reconhece o Novo Compromisso e Revoga o Antigo
Agora que Bob tem um novo compromisso assinado, ele precisa reconhecê-lo e revogar o
compromisso antigo.Ele faz isso enviando a mensagem revoke_and_ack, como vimos no
8
[payment_channels] anteriormente. Como lembrete, essa mensagem é mostrada em A mensagem
revoke_and_ack.
Example 4. A mensagem revoke_and_ack
[32*byte:per_commitment_secret]
[point:next_per_commitment_point]
Bob envia o per_commitment_secret que permite a Alice construir uma chave de revogação para
criar uma transação de penalidade gastando o antigo compromisso de Bob. Uma vez que Bob tenha
enviado isso, ele nunca pode publicar o "Commitment #2" sem correr o risco de uma transação de
penalidade e perder todo o seu dinheiro. Portanto, o antigo compromisso é efetivamente revogado.
Bob efetivamente avançou o estado do canal, como mostrado na Bob revogou o antigo
compromisso.
Figure 7. Bob revogou o antigo compromisso
Apesar de Bob ter uma nova transação de compromisso (assinada) e uma saída HTLC dentro dela,
9
ele não pode considerar que seu HTLC foi configurado com sucesso.
Ele precisa primeiro fazer com que Alice revogue seu antigo compromisso, caso contrário, Alice
pode reverter seu saldo para 70.000 satoshis. Bob precisa garantir que Alice também tenha uma
transação de compromisso contendo o HTLC e tenha revogado o antigo compromisso.
É por isso que, se Bob não for o destinatário final dos fundos do HTLC, ele não deve encaminhar o
HTLC ainda, oferecendo um HTLC no próximo canal com Chan.
Alice construiu uma nova transação de compromisso espelhada contendo o novo HTLC, mas ainda
não foi assinada por Bob. Podemos ver isso na O novo compromisso de Alice com uma saída HTLC.
Figure 8. O novo compromisso de Alice com uma saída HTLC
Como descrito no [payment_channels], o compromisso de Alice é a imagem espelhada do de Bob,

pois contém a estrutura assimétrica, adiada e revogável para a revogação e aplicação de
penalidades de compromissos antigos. O saldo de Alice de 19.800 satoshis (após deduzir o valor do
HTLC) está adiado e é revogável. O saldo de Bob de 70.000 satoshis está imediatamente disponível
para resgate.
Em seguida, o fluxo de mensagens para commitment_signed e revoke_and_ack é repetido, mas na

direção oposta. Bob envia commitment_signed para assinar o novo compromisso de Alice, e Alice
responde revogando seu compromisso antigo.
10
Para completar, vamos revisar rapidamente as transações de compromisso à medida que essa
rodada de compromisso/revogação acontece.
Bob Compromete
Agora, Bob envia um commitment_signed de volta para Alice, com suas assinaturas para a nova
transação de compromisso de Alice, incluindo a saída HTLC que ela adicionou.
Agora Alice tem a assinatura para a nova transação de compromisso. O estado do canal é mostrado
na Alice tem um novo compromisso assinado.
Figure 9. Alice tem um novo compromisso assinado
Agora Alice pode confirmar o novo compromisso revogando o antigo. Alice envia a mensagem
revoke_and_ack contendo o per_commitment_point necessário que permitirá a Bob construir uma
chave de revogação e uma transação de penalidade. Assim, Alice revoga seu antigo compromisso.
O estado do canal é mostrado na Alice revogou o antigo compromisso.
11
Figure 10. Alice revogou o antigo compromisso
Múltiplos HTLCs
Em qualquer momento, Alice e Bob podem ter dezenas ou até centenas de HTLCs em um único
canal. Cada HTLC é oferecido e adicionado à transação de compromisso como uma saída adicional.
Portanto, uma transação de compromisso sempre tem duas saídas para os saldos dos parceiros do
canal e qualquer número de saídas de HTLC, uma por HTLC.
Como vimos na mensagem commitment_signed, há uma array para assinaturas de HTLC para que
vários compromissos de HTLC possam ser transmitidos ao mesmo tempo.
O número máximo atual de HTLCs permitidos em um canal é de 483 HTLCs para levar em conta o
tamanho máximo da transação Bitcoin e garantir que as transações de compromisso continuem
sendo transações Bitcoin válidas.
Como veremos na próxima seção, o limite máximo é apenas para HTLCs pendentes, pois, uma vez
que um HTLC é cumprido (ou falha devido a tempo expirado/erro), ele é removido da transação de
compromisso.
12
Cumprimento do HTLC
Agora Bob e Alice têm uma nova transação de compromisso com uma saída adicional de HTLC, e
conseguimos dar um passo importante em direção à atualização de um canal de pagamento .
O novo saldo de Alice e Bob ainda não reflete o fato de que Alice enviou com sucesso 50.200 satoshis
para Bob.
No entanto, os HTLCs agora são configurados de forma que a liquidação segura em troca do
comprovante de pagamento seja possível.
Propagação do HTLC
Vamos supor que Bob continue a corrente e configure um HTLC com Chan para 50.100 satoshis. O
processo será exatamente o mesmo que acabamos de ver entre Alice e Bob. Bob enviará o
update_add_htlc para Chan e, em seguida, eles trocarão as mensagens commitment_signed e
revoke_and_ack em duas rodadas, avançando seu canal para o próximo estado.
Em seguida, Chan fará o mesmo com Dina: oferecer um HTLC de 50.000 satoshis, comprometer-se e
revogar, etc. No entanto, Dina é a destinatária final do HTLC. Dina é a única que conhece o segredo
do pagamento (a pré-imagem do hash do pagamento). Portanto, Dina pode cumprir o HTLC com
Chan imediatamente!
Dina Cumpre o HTLC com Chan
Dina pode liquidar o HTLC enviando uma mensagem update_ful⁠fill_htlc para

Chan. A mensagem update_fulfill_htlc é definida em BOLT #2: Peer Protocol, update_fulfill_htlc e
mostrada aqui:
A mensagem update_fulfill_htlc
[u64:id]
[32*byte:payment_preimage]
É uma mensagem muito simples:
channel_id
O ID do canal no qual o HTLC está comprometido.
id
O ID do HTLC (começamos com 0 e incrementamos para cada HTLC no canal).
payment_preimage
O segredo que prova o pagamento e resgata o HTLC. Esse é o valor R que foi utilizado por Dina
para calcular o hash de pagamento na fatura enviada para Alice.
Quando Chan recebe essa mensagem, ele imediatamente verifica se o payment_preimage (vamos
chamá-lo de R) produz o hash de pagamento (vamos chamá-lo de H) no HTLC que ele ofereceu a
13
Dina. Ele realiza o cálculo de hash da seguinte forma:
<li>H = RIPEMD160(SHA-256 (R))</li>
</ul>
Se o resultado H corresponder ao hash de pagamento no HTLC, Chan pode fazer uma pequena
dança de celebração. Esse tão esperado segredo pode ser usado para resgatar o HTLC e será
repassado ao longo da cadeia de canais de pagamento até chegar a Alice, resolvendo todos os
HTLCs que faziam parte deste pagamento para Dina.
Vamos voltar ao canal de Alice e Bob e observar como eles desfazem o HTLC. Para chegar lá, vamos
supor que Dina enviou o update_fulfill_htlc para Chan, Chan enviou o update_fulfill_htlc para Bob,
e Bob enviou o update_fulfill_htlc para Alice. A pré-imagem do pagamento se propagou de volta até
Alice.
Bob Resolve o HTLC com Alice
Quando Bob enviar o update_fulfill_htlc para Alice, ele conterá a mesma payment_preimage que
Dina selecionou para sua fatura. Essa payment_preimage viajou de volta ao longo do caminho de
pagamento. Em cada etapa, o channel_id será diferente e o id (ID do HTLC) pode ser diferente. Mas
a pré-imagem é a mesma!
Alice também validará a payment_preimage recebida de Bob. Ela comparará o hash dela com o
hash do pagamento no HTLC que ela ofereceu a Bob. Ela também constatará que essa pré-imagem
corresponde ao hash na fatura de Dina. Isso é uma prova de que Dina foi paga.
O fluxo de mensagem entre Alice e Bob é mostrado na O fluxo de mensagens de cumprimento

HTLC.
14
Figure 11. O fluxo de mensagens de cumprimento HTLC
Tanto Alice quanto Bob agora podem remover o HTLC das transações de compromisso e atualizar
seus saldos de canal.
Eles criam novos compromissos (Commitment #4), como mostrado em: O HTLC é removido e os
saldos são atualizados em novos compromissos.
15
Figure 12. O HTLC é removido e os saldos são atualizados em novos compromissos
Em seguida, eles completam duas rodadas de compromisso e revogação. Primeiro, Alice envia o
commitment_signed para assinar a nova transação de compromisso de Bob. Bob responde com
revoke_and_ack para revogar seu antigo compromisso. Uma vez que Bob moveu o estado do canal
para frente, os compromissos ficam como vemos na Alice assina o novo compromisso de Bob e Bob
revoga o antigo.
16
Figure 13. Alice assina o novo compromisso de Bob e Bob revoga o antigo
Por fim, Bob assina o compromisso de Alice enviando uma mensagem commitment_signed. Em
seguida, Alice reconhece e revoga seu antigo compromisso enviando revoke_and_ack para Bob. O
resultado final é que tanto Alice quanto Bob moveram seu estado de canal para o Commitment #4,
removeram o HTLC e atualizaram seus saldos. Seu estado atual do canal é representado pelas
transações de compromisso mostradas na Alice e Bob resolvem o HTLC e atualizam os saldos.
17
Figure 14. Alice e Bob resolvem o HTLC e atualizam os saldos
Removendo um HTLC devido a Erro ou Expiração

Se um HTLC não puder ser cumprido, ele pode ser removido do compromisso do canal usando o
mesmo processo de compromisso e revogação.
Em vez de update_fulfill_htlc, Bob enviaria um update_fail_htlc ou update_fail_malformed_htlc.

Essas duas mensagens são definidas em BOLT #2: Peer Protocol, Removing an HTLC.
A mensagem update_fail_htlc é mostrada a seguir:
18
A mensagem update_fail_htlc
[u64:id]
[u16:len]
[len*byte:reason]
É bastante autoexplicativo. O campo de vários bytes reason é definido em BOLT #4: Onion Routing,
que nós vamos descrever no [onion_routing].
Se Alice recebeu um update_fail_htlc de Bob, o processo se desenrolaria de maneira bastante

semelhante: os dois parceiros de canal removeriam o HTLC, criariam transações de compromisso
atualizadas e passariam por duas rodadas de compromisso/revogação para avançar o estado do
canal para o próximo compromisso. A única diferença é que os saldos finais seriam revertidos para
o que eram antes do HTLC, essencialmente reembolsando Alice pelo valor do HTLC.
Fazendo um Pagamento Local

Neste ponto, você entenderá facilmente por que os HTLCs são usados tanto para pagamentos
remotos quanto locais. Quando Alice paga Bob por um café, ela não apenas atualiza o saldo do
canal e se compromete com um novo estado. Em vez disso, o pagamento é feito com um HTLC, da
mesma forma que Alice pagou Dina. O fato de haver apenas um salto de canal não faz diferença.
Funcionaria assim:
1. Alice pede um café na página da loja de Bob.
2. A loja de Bob envia uma fatura com um hash de pagamento.
3. Alice constrói um HTLC a partir desse hash de pagamento.
4. Alice oferece o HTLC para Bob com update_add_htlc.
5. Alice e Bob trocam compromissos e revogações adicionando o HTLC às suas transações de

compromisso.
6. Bob envia update_fulfill_htlc para Alice com a pré-imagem de pagamento.
7. Alice e Bob trocam compromissos e revogações removendo o HTLC e atualizando os saldos do

canal.
Se um HTLC for encaminhado por vários canais ou apenas cumprido em um único salto de canal, o
processo é exatamente o mesmo.
Conclusão
Neste capítulo, vimos como as transações de compromisso (from [payment_channels]) e HTLCs
(from [routing]) funcionam em conjunto. Vimos como um HTLC é adicionado a uma transação de
compromisso e como ele é cumprido. Vimos como o sistema assimétrico, atrasado e revogável para
fazer cumprir o estado do canal é estendido para os HTLCs.
Também vimos como um pagamento local e um pagamento roteado de várias etapas são tratados
da mesma forma: usando HTLCs.
19
No próximo capítulo, vamos analisar o sistema de roteamento de mensagens criptografadas
chamado onion routing.
20
Onion Routing
Neste capítulo, descreveremos o mecanismo de roteamento em camadas da Lightning Network,
chamado de onion routing. A invenção do onion routing antecede a Lightning Network em 25 anos!
O onion routing foi inventado por pesquisadores da Marinha dos Estados Unidos como um
protocolo de segurança de comunicações. O onion routing é mais famosamente usado pelo Tor, a
sobreposição de internet com roteamento em camadas que permite que pesquisadores, ativistas,
agentes de inteligência e todos os outros usem a internet de forma privada e anônima.
Neste capítulo, estamos focando no SPHINX, roteamento em camadas baseado na origem. É uma
parte da arquitetura do protocolo Lightning, destacado por um diagrama no centro (camada de
roteamento) da Roteamento Onion no conjunto de protocolos Lightning.
Figure 1. Roteamento Onion no conjunto de protocolos Lightning
O roteamento em camadas (onion routing) descreve um método de comunicação criptografada em

que o remetente de uma mensagem cria sucessivas camadas aninhadas de criptografia que são
"descascadas" por cada nó intermediário, até que a camada mais interna seja entregue ao
destinatário pretendido. O termo "onion routing" descreve esse uso de criptografia em camadas que
é removida uma camada de cada vez, assim como a pele de uma cebola.
Cada um dos nós intermediários só pode "descascar" uma camada e ver quem é o próximo no
caminho de comunicação. O roteamento em camadas garante que ninguém, exceto o remetente,
saiba o destino ou o comprimento do caminho de comunicação. Cada intermediário só conhece o
salto anterior e o próximo salto.
A Rede Lightning utiliza uma implementação do protocolo de roteamento em camadas baseada em

[1]
Sphinx, developed in 2009 by George Danezis and Ian Goldberg.
A implementação do roteamento em camadas (onion routing) na Rede Lightning é definida em

BOLT #4: Onion Routing Protocol.
1
Um Exemplo Físico Ilustrando o Roteamento Onion
Existem várias maneiras de descrever o roteamento em camadas (onion routing), mas uma das
mais simples é usar o equivalente físico de envelopes lacrados. Um envelope representa uma
camada de criptografia, permitindo apenas que o destinatário nomeado o abra e leia o conteúdo.
Digamos que Alice queira enviar uma carta secreta para Dina, indiretamente por meio de alguns
intermediários.
Selecionando um Caminho
A Rede Relâmpago utiliza o roteamento de origem (source routing), o que significa que o caminho
de pagamento é selecionado e especificado pelo remetente, e somente pelo remetente. Neste
exemplo, a carta secreta de Alice para Dina será equivalente a um pagamento. Para garantir que a
carta chegue a Dina, Alice irá criar um caminho partindo dela até Dina, usando Bob e Chan como
intermediários.
Pode haver vários caminhos que permitem que Alice alcance Dina. Explicaremos o processo de
seleção do caminho ótimo no [path_finding]. Por enquanto, vamos supor que o caminho
selecionado por Alice usa Bob e Chan como intermediários para chegar a Dina.
Como lembrete, o caminho selecionado por Alice é mostrado na Caminho: Alice para Bob para Chan
para Dina.
Figure 2. Caminho: Alice para Bob para Chan para Dina
Vamos ver como Alice pode usar esse caminho sem revelar informações aos intermediários Bob e
Chan.
Roteamento Baseado na Origem
O roteamento baseado em origem não é como os pacotes são normalmente roteados na

internet hoje em dia, embora o roteamento baseado em origem fosse possível nos primeiros
2
dias. O roteamento da Internet é baseado na comutação de pacotes em cada nó de roteamento
intermediário. Um pacote IPv4, por exemplo, inclui os endereços IP do remetente e do
destinatário, e cada outro nó de roteamento IP decide como encaminhar cada pacote em
direção ao destino. No entanto, a falta de privacidade em um mecanismo de roteamento
desse tipo, onde cada nó intermediário vê o remetente e o destinatário, torna essa uma
escolha inadequada para uso em uma rede de pagamentos.
Construindo as Camadas
Alice começa escrevendo uma carta secreta para Dina. Em seguida, ela lacra a carta dentro de um
envelope e escreve "Para Dina" do lado de fora (see Carta secreta de Dina, lacrada em um envelope).
O envelope representa a criptografia com a chave pública de Dina, para que apenas Dina possa
abrir o envelope e ler a carta.
Figure 3. Carta secreta de Dina, lacrada em um envelope
A carta de Dina será entregue a ela por Chan, que está imediatamente antes de Dina no "caminho".
Então, Alice coloca o envelope de Dina dentro de um envelope endereçado a Chan (see O envelope
de Chan, contendo o envelope selado de Dina). A única parte que Chan pode ler é o destino
(instruções de roteamento): "Para Dina". Selar isso dentro de um envelope endereçado a Chan
representa criptografá-lo com a chave pública de Chan para que apenas Chan possa ler o endereço
do envelope. Chan ainda não pode abrir o envelope de Dina. Tudo o que ele vê são as instruções do
lado de fora (o endereço).
3
Figure 4. O envelope de Chan, contendo o envelope selado de Dina
Agora, essa carta será entregue a Chan por Bob. Então, Alice a coloca dentro de um envelope
endereçado a Bob (see Envelope de Bob, contendo o envelope lacrado de Chan). Como antes, o
envelope representa uma mensagem criptografada para Bob, que só ele pode ler. Bob só pode ler o
lado de fora do envelope de Chan (o endereço), então ele sabe que deve enviá-lo para Chan.
4
Figure 5. Envelope de Bob, contendo o envelope lacrado de Chan
Agora, se pudéssemos olhar através dos envelopes (com raios X!), veríamos os envelopes aninhados
um dentro do outro, como mostrado na Envelopes aninhados.
Figure 6. Envelopes aninhados
5
Descascando as Camadas
Agora, Alice tem um envelope que diz "Para Bob" do lado de fora. Ele representa uma mensagem
criptografada que só Bob pode abrir (descriptografar). Alice começará o processo enviando isso
para Bob. Todo o processo é mostrado na Enviando os envelopes.
Figure 7. Enviando os envelopes
Como você pode ver, Bob recebe o envelope de Alice. Ele sabe que veio de Alice, mas não sabe se
Alice é a remetente original ou apenas alguém encaminhando envelopes. Ele abre e encontra um
envelope dentro que diz "Para Chan". Como está endereçado a Chan, Bob não pode abri-lo. Ele não
sabe o que tem dentro e não sabe se Chan está recebendo uma carta ou outro envelope para
encaminhar. Bob não sabe se Chan é o destinatário final ou não. Bob encaminha o envelope para
Chan.
Chan recebe o envelope de Bob. Ele não sabe que veio de Alice. Ele não sabe se Bob é um
intermediário ou o remetente de uma carta. Chan abre o envelope e encontra outro envelope
dentro, endereçado "Para Dina", que ele não pode abrir. Chan encaminha o envelope para Dina,
sem saber se Dina é a destinatária final.
Dina recebe um envelope de Chan. Ao abri-lo, ela encontra uma carta dentro, então ela sabe que é a
destinatária pretendida dessa mensagem. Ela lê a carta, sabendo que nenhum dos intermediários
sabe de onde ela veio e ninguém mais leu sua carta secreta!
Essa é a essência do roteamento em camadas (onion routing). O remetente envolve uma mensagem
em várias camadas, especificando exatamente como ela será roteada e impedindo que qualquer
intermediário obtenha informações sobre o caminho ou o conteúdo. Cada intermediário remove
uma camada, vê apenas um endereço de encaminhamento e não sabe nada além do nó anterior e
do próximo nó no caminho.
Agora, vamos analisar os detalhes da implementação do roteamento em camadas na Lightning

Network.
6
Introdução ao Onion Routing de HTLCs
O roteamento em camadas na Lightning Network pode parecer complexo à primeira vista, mas
uma vez que você entende o conceito básico, é realmente bastante simples.
Do ponto de vista prático, Alice está informando a cada nó intermediário qual HTLC deve ser
configurado com o próximo nó no caminho.
O primeiro nó, que é o remetente do pagamento ou Alice em nosso exemplo, é chamado de nó de

origem.O último nó, que é o destinatário do pagamento ou Dina em nosso exemplo, é chamado de
nó final.
Cada nó intermediário, ou Bob e Chan em nosso exemplo, é chamado de salto (hop). Cada salto deve
configurar um HTLC de saída para o próximo salto. As informações comunicadas a cada salto por
Alice são chamadas de carga útil do salto (hop payload) ou dados do salto (hop data). A mensagem
que é roteada de Alice para Dina é chamada de cebola (onion) e consiste em mensagens
criptografadas de carga útil do salto ou dados do salto criptografadas para cada salto.
Agora que conhecemos a terminologia usada no roteamento de cebola do Lightning, vamos

reafirmar a tarefa de Alice: Alice deve construir uma cebola com dados do salto, informando a cada
salto como construir um HTLC de saída para enviar um pagamento ao nó final (Dina).
Alice Seleciona o Caminho
Do [routing] sabemos que Alice enviará um pagamento de 50.000 satoshis para Dina por meio de
Bob e Chan. Esse pagamento é transmitido por meio de uma série de HTLCs, conforme mostrado na
Caminho de pagamento com HTLCs de Alice para Dina.
Figure 8. Caminho de pagamento com HTLCs de Alice para Dina
Como veremos no [gossip], Alice é capaz de construir esse caminho para Dina porque os nós
Lightning anunciam seus canais para toda a Rede Relâmpago usando o Protocolo Lightning Gossip.
Após o anúncio inicial do canal, Bob e Chan enviaram uma mensagem adicional channel_update
com sua taxa de roteamento e expectativas de tempo de bloqueio para o roteamento de
7
pagamentos.
A partir dos anúncios e atualizações, Alice conhece as seguintes informações sobre os canais entre
Bob, Chan e Dina:
• Um short_channel_id (ID curto de canal) para cada canal, o que Alice pode usar para referenciar
o canal ao construir o caminho
• Um cltv_expiry_delta (timelock delta), que Alice pode adicionar ao tempo de expiração de cada
HTLC
• Uma fee_base_msat e fee_proportional_millionths, que Alice pode usar para calcular a taxa total
de roteamento esperada por aquele nó para o encaminhamento naquele canal.
Na prática, outras informações também são trocadas, como os maiores (htlc_maximum_msat) e

menores (htlc_minimum_msat) HTLCs que um canal suportará, mas essas informações não são usadas
de forma tão direta durante a construção da rota da cebola, quanto os campos anteriores são.
Essas informações são usadas por Alice para identificar os nós, canais, taxas e bloqueios de tempo
para o seguinte caminho detalhado, mostrado na Um caminho detalhado construído a partir de
canal divulgado e informações de nó.
Figure 9. Um caminho detalhado construído a partir de canal divulgado e informações de nó
Alice já conhece seu próprio canal para Bob e, portanto, não precisa dessas informações para
construir o caminho. Observe também que Alice não precisou de uma atualização de canal de Dina,
pois ela tem a atualização de Chan para o último canal no caminho.
Alice Constrói as Payloads
Existem dois formatos possíveis que Alice pode usar para as informações comunicadas a cada salto:
um formato legado de comprimento fixo chamado hop data e um formato mais flexível baseado em
Type-Length-Value (TLV) chamado hop payload. O formato de mensagem TLV é explicado em mais
detalhes em [tlv]. Isso oferece flexibilidade, permitindo que campos sejam adicionados ao protocolo
conforme necessário.
Ambos formatos são especificados em BOLT #4: Onion Routing Protocol, Packet Structure.
8
Alice começará a construir os dados do salto do final do caminho para trás: Dina, Chan e Bob.
======= Carga (payload) final do nó para Dina
Alice primeiro constrói o payload que será entregue para Dina. Dina não estará construindo um
"outgoing HTLC" porque Dina é o nó final e destinatário do pagamento. Por esse motivo, o payload
para Dina é diferente de todos os outros (usa todos os zeros para o short_channel_id), mas apenas
Dina saberá disso porque estará criptografado na camada mais interna da cebola. Essencialmente,
isso é a "carta secreta para Dina" que vimos no nosso exemplo de envelope físico.
O payload de salto para Dina deve coincidir com as informações na fatura gerada por Dina para
Alice e conterá (pelo menos) os seguintes campos no formato TLV:
amt_to_forward
A quantidade deste pagamento em millisatoshis. Se isso for apenas uma parte de um pagamento
multipartes, o valor será menor que o total. Caso contrário, este é um único pagamento completo
e é igual ao valor da fatura e ao valor total_msat.
outgoing_cltv_value
O bloqueio de tempo de expiração do pagamento definido para o valor min_final_cltv_expiry na
fatura.
payment_secret
Um valor secreto de 256 bits especial da fatura, permitindo que Dina reconheça este pagamento
recebido. Isso também impede uma classe de sondagem que anteriormente tornava as faturas
de valor zero inseguras. A sondagem por nós intermediários é mitigada, pois esse valor é
criptografado apenas para o destinatário, o que significa que eles não podem reconstruir um
pacote final que "pareça" legítimo.
total_msat
O valor total que corresponde à fatura. Isso pode ser omitido se houver apenas uma parte, caso
em que é considerado igual a amt_to_forward e deve ser igual ao valor da fatura.
A fatura que Alice recebeu de Dina especificava o valor como 50.000 satoshis, o que equivale a
50.000.000 millisatoshis. Dina especificou o prazo mínimo de expiração para o pagamento
min_final_cltv_expiry como 18 blocos (3 horas, considerando uma média de 10 minutos por bloco
do Bitcoin). No momento em que Alice está tentando fazer o pagamento, vamos supor que a
blockchain do Bitcoin registrou 700.000 blocos. Portanto, Alice deve definir o outgoing_cltv_value
para uma altura de bloco mínima de 700.018.
Alice constrói a carga útil (payload) do salto para Dina da seguinte forma:
amt_to_forward : 50,000,000
outgoing_cltv_value: 700,018
payment_secret: fb53d94b7b65580f75b98f10...03521bdab6d519143cd521d1b3826
total_msat: 50,000,000
Alice o serializa no formato TLV, como mostrado (simplificado) na O payload de Dina é construído
9
por Alice.
Figure 10. O payload de Dina é construído por Alice
Payload de salto para Chan
Em seguida, Alice constrói o payload de salto para Chan. Isso informará a Chan como configurar um
HTLC de saída para Dina.
O payload de salto para Chan inclui três campos: short_channel_id, amt_to_forward e

outgoing_cltv_value:
short_channel_id: 010002010a42be
amt_to_forward: 50,000,000
Alice serializa esse payload no formato TLV, conforme mostrado (simplificado) na O payload de
Chan é construído por Alice.
Figure 11. O payload de Chan é construído por Alice
Payload de salto para Bob
Por fim, Alice constrói o payload de salto para Bob, que também contém os mesmos três campos
como o payload de salto para Chan, mas com valores diferentes:
short_channel_id: 000004040a61f0
amt_to_forward: 50,100,000
Como você pode ver, o campo amt_to_forward é de 50.100.000 millisatoshis, ou seja, 50.100 satoshis.
Isso ocorre porque Chan espera uma taxa de 100 satoshis para rotear um pagamento para Dina.
Para que Chan possa "ganhar" essa taxa de roteamento, o HTLC de entrada de Chan deve ser 100
satoshis a mais do que o HTLC de saída de Chan. Uma vez que o HTLC de entrada de Chan é o HTLC
de saída de Bob, as instruções para Bob refletem a taxa que Chan ganha. Em termos simples, Bob
10
precisa ser instruído a enviar 50.100 satoshis para Chan, para que Chan possa enviar 50.000
satoshis e ficar com 100 satoshis.
Da mesma forma, Chan espera um delta de bloqueio de tempo de 20 blocos. Portanto, o HTLC de
entrada de Chan deve expirar 20 blocos mais tarde do que o HTLC de saída de Chan. Para alcançar
isso, Alice diz a Bob para fazer seu HTLC de saída para Chan expirar no bloco 700.038-20 blocos
depois do HTLC de Chan para Dina.
As expectativas de taxas e delta de timelock para um canal são definidas pela diferença entre
HTLCs de entrada e saída. Uma vez que o HTLC de entrada é criado pelo nó anterior, a taxa e o
delta de timelock são definidos no payload da cebola para aquele nó anterior. Bob é informado
sobre como criar um HTLC que atenda às expectativas de taxa e timelock de Chan.
Alice serializa esse payload no formato TLV, conforme mostrado (simplificado) na O payload de Bob
é construído por Alice.
Figure 12. O payload de Bob é construído por Alice
Cargas úteis de salto finalizadas
Alice agora construiu os três payloads de salto que serão envolvidos em uma cebola. Uma visão
simplificada dessas cargas é mostrada na Cargas úteis de salto para todos os saltos.
Figure 13. Cargas úteis de salto para todos os saltos
11
Geração de chave
Alice agora deve gerar várias chaves que serão usadas para criptografar as várias camadas na
cebola.
Com essas chaves, Alice pode alcançar um alto grau de privacidade e integridade:
• Alice pode criptografar cada camada da cebola de forma que apenas o destinatário pretendido
possa lê-la.
• Cada intermediário pode verificar se a mensagem não foi modificada.
• Ninguém no caminho saberá quem enviou esta cebola ou para onde ela está indo. Alice não
revela sua identidade como remetente nem a identidade de Dina como destinatária do
pagamento.
• Cada salto só conhece o salto anterior e o próximo salto.
• Ninguém pode saber qual é o comprimento do caminho ou em qual ponto do caminho eles
estão.
Como uma cebola picada, os seguintes detalhes técnicos podem trazer lágrimas aos seus olhos.
Sinta-se à vontade para pular para a próxima seção se estiver confuso. Volte-se a esse
repositório e leia BOLT #4: Onion Routing, Packet Construction, se você quiser aprender mais.
A base para todas as chaves usadas na cebola é um segredo compartilhado que Alice e Bob podem
gerar independentemente usando o algoritmo de Diffie-Hellman de Curva Elíptica (ECDH). A partir
do segredo compartilhado (ss), eles podem gerar independentemente mais quatro chaves adicionais
chamadas rho, mu, um e pad:
rho
Usado para gerar um fluxo de bytes aleatórios a partir de uma cifra de fluxo (usado como um
CSPRNG). Esses bytes são usados para criptografar/descriptografar o corpo da mensagem, bem
como preenchimento de bytes zero durante o processamento de pacotes do Sphinx.
mu
Usado no código de autenticação baseada em hash de mensagem (HMAC) para verificação de
integridade/autenticidade.
um
Usado em relatórios de erros.
pad
Usado para gerar bytes de preenchimento para preencher a cebola em um comprimento fixo.
A relação entre as várias chaves e como elas são geradas é diagramada na Geração de chave Onion.
12
Figure 14. Geração de chave Onion
Chave de sessão de Alice
Para evitar revelar sua identidade, Alice não usa a chave pública do seu próprio nó para construir a
cebola. Em vez disso, Alice cria uma chave temporária de 32 bytes (256 bits) chamada chave privada
de sessão (session private key) e a correspondente chave pública de sessão (session public key). Isso
serve como uma "identidade" temporária e como chave apenas para esta cebola. A partir dessa
chave de sessão, Alice construirá todas as outras chaves que serão usadas nesta cebola.
Detalhes da geração da chave
A geração de chaves, geração de bytes aleatórios, chaves efêmeras e como elas são usadas na
construção de pacotes são especificadas em três seções do BOLT #4:
• Key Generation
• Random Byte Stream
• Packet Construction
Para simplificar e evitar entrar em muitos detalhes técnicos, não incluímos esses detalhes no livro.
Veja os links anteriores se você deseja ver o funcionamento interno.
======= Geração des segredo compartilhado
Um detalhe importante que parece quase mágico é a capacidade de Alice criar um segredo
compartilhado com outro nó simplesmente conhecendo suas chaves públicas.Isso se baseia na
invenção da troca de chaves de Diffie-Hellman (DH) na década de 1970, que revolucionou a
criptografia. O roteamento de cebola do Lightning utiliza o Diffie-Hellman de Curva Elíptica (ECDH)
na curva secp256k1 do Bitcoin. É um truque tão interessante que tentamos explicá-lo de forma
simples em Curva Elíptica Diffie-Hellman Explicada.
13
Curva Elíptica Diffie-Hellman Explicada
Vamos assumir que a chave privada de Alice é a e a chave privada de Bob é b. Utilizando a
curva elíptica, Alice e Bob multiplicam suas chaves privadas pelo ponto gerador G para
produzir suas chaves públicas A e B, respectivamente:
<li>A = aG</li>
<li>B = bG</li>
</ul>
Agora Alice e Bob podem usar a Troca de Chave de Curva Elíptica Diffie-Hellman para criar um
segredo compartilhado ss, um valor que ambos podem calcular independentemente sem
trocar nenhuma informação.
O segredo compartilhado ss é calculado por cada um multiplicando sua própria chave

privada com a chave pública do outro, de modo que:
<li>ss = aB = bA</li>
</ul>
Mas por que essas duas multiplicações resultariam no mesmo valor ss? Acompanhe,
enquanto demonstramos a matemática que prova que isso é possível:
<li>ss</li>
<li>= aB</li>
</ul>
calculado por Alice que conhece a (sua chave privada) e B (chave pública de Bob)
<li>= a(bG)</li>
</ul>
porque sabemos que B = bG, substituímos
<li> = (ab)G</li>
</ul>
por causa da associatividade, podemos mover os parênteses
<li>= (ba)G</li>
</ul>
porque xy = yx (a curva é um grupo abeliano)
<li>= b(aG)</li>
14
</ul>
por causa da associatividade, podemos mover os parênteses
<li>= bA</li>
</ul>
e podemos substituir aG por A.
O resultado bA pode ser calculado independentemente por Bob que conhece b (sua chave
privada) e A (chave pública de Alice).
Mostramos, portanto, que:
<li>ss = aB (Alice pode calcular isto)</li>
<li>ss = bA (Bob pode calcular isto)</li>
</ul>
Portanto, cada um pode calcular independentemente o valor de ss, que pode ser usado como
uma chave compartilhada para criptografar simetricamente segredos entre os dois, sem
precisar comunicar o segredo compartilhado.
Uma característica única do Sphinx como um formato de pacote de mix-net é que, em vez de incluir
uma chave de sessão distinta para cada salto no caminho, o que aumentaria drasticamente o
tamanho do pacote de mix-net,é usado um esquema inteligente de ofuscação (blinding) para
randomizar de forma determinística a chave de sessão em cada salto.
Na prática, esse pequeno truque nos permite manter o pacote de cebola o mais compacto possível,
mantendo as propriedades de segurança desejadas.
A chave de sessão para o salto i é derivada usando a chave pública do nó e o segredo

compartilhado derivado do salto i - 1:
session_key_i = session_key_{i-1} * SHA-256(node_pubkey_{i-1} || shared_secret_{i-1})
Em outras palavras, pegamos a chave de sessão do salto anterior e a multiplicamos por um valor
derivado da chave pública e do segredo compartilhado derivado para esse salto.
Como a multiplicação de curva elíptica pode ser realizada em uma chave pública sem o
conhecimento da chave privada, cada salto é capaz de re-randomizar a chave de sessão para o
próximo salto de maneira determinística.
O criador do pacote onion conhece todos os segredos compartilhados (pois eles criptografaram o
pacote de forma única para cada salto) e, portanto, é capaz de derivar todos os fatores de ofuscação
(blinding).
Essa informação permite que eles derivem todas as chaves de sessão usadas antecipadamente
durante a geração do pacote.
15
Note que o primeiro salto usa a chave de sessão originalmente gerada, pois essa chave é usada para
iniciar o processo de ofuscação das chaves de sessão por cada salto subsequente.
Empacotando as Camadas de Cebola

O processo de empacotar a cebola é detalhado em BOLT #4: Onion Routing, Packet Construction.
Nesta seção, descreveremos esse processo em um nível mais alto e de forma um tanto simplificada,
omitindo alguns detalhes.
Cebolas de comprimento fixo
Mencionamos o fato de que nenhum dos nós intermediários, ou hops, sabe o comprimento do
caminho ou onde eles estão no caminho. Como isso é possível?
Se você tiver um conjunto de direções, mesmo que criptografadas, você não pode dizer a que
distância está do começo ou do fim simplesmente olhando onde na lista de direções você está?
O truque usado no onion routing é sempre manter o caminho (a lista de instruções) com o mesmo
comprimento para cada nó. Isso é alcançado mantendo o pacote de cebola com o mesmo
comprimento em cada etapa.
A cada salto, a carga útil do salto aparece no início da carga útil da cebola, seguida por o que
parecem ser mais 19 cargas úteis do salto. Cada salto se vê como o primeiro de 20 saltos.
A carga útil da cebola é de 1.300 bytes. Cada carga útil de salto é de 65 bytes ou menos
(preenchida para 65 bytes se for menor). Portanto, a carga útil total da cebola pode acomodar
20 cargas úteis de salto (1300 = 20 × 65). O caminho máximo de roteamento da cebola,
portanto, é de 20 saltos.
À medida que cada camada é "descascada", mais dados de preenchimento (essencialmente lixo) são
adicionados no final da carga útil da cebola para que o próximo salto receba uma cebola do mesmo
tamanho e seja novamente o "primeiro salto" na cebola.
O tamanho da cebola é de 1.366 bytes, estruturada como mostrado na O pacote onion:
1 byte
Um byte de versão
33 bytes
Uma chave pública de sessão comprimida (Chave de sessão de Alice) partir da qual o segredo
compartilhado por salto ([shared_secret]) pode ser gerado sem revelar a identidade de Alice.
1,300 bytes
A real carga útil da cebola (onion payload) contendo as instruções para cada salto
32 bytes
Uma soma de verificação (checksum) de integridade HMAC
16
Figure 15. O pacote onion
Uma característica única do Sphinx como um formato de pacote mix-net é que, em vez de incluir
uma chave de sessão distinta para cada salto no roteamento, o que aumentaria significativamente o
tamanho do pacote, é usado um esquema inteligente de ofuscação para randomizar
deterministicamente a chave de sessão em cada salto.
Na prática, esse pequeno truque nos permite manter o pacote de cebola o mais compacto possível,
mantendo as propriedades de segurança desejadas.
Empacotando a Cebola (Esquematizado)
Aqui está o processo de embrulhar a cebola, esboçado a seguir. Volte a esta lista à medida que
exploramos cada etapa com nosso exemplo do mundo real.
Para cada hop, o remetente (Alice) repete o mesmo processo:
1. Alice gera o segredo compartilhado por salto e as chaves rho, mu e pad.
2. Alice gera 1.300 bytes de dados de preenchimento e preenche o campo de carga útil (payload) da
cebola de 1.300 bytes com esses dados de preenchimento.
3. Alice calcula o HMAC para a carga útil do salto (zeros para o último salto).
4. Alice calcula o comprimento do espaço HMAC da carga útil do salto para armazenar o
comprimento em si
5. Alice desloca para a direita a carga útil da cebola pelo espaço calculado necessário para caber a
carga útil do salto. Os dados de "preenchimento" mais à direita são descartados, criando espaço
suficiente à esquerda para a carga útil.
6. Alice insere o comprimento + hop payload + HMAC na frente do campo de carga útil no espaço
criado pelo deslocamento do preenchimento.
7. Alice usa a chave rho para gerar um preenchimento único (one-time pad) de 1.300 bytes.
8. Alice ofusca todo o conteúdo da carga útil da cebola fazendo uma operação XOR com os bytes
gerados a partir de rho.
9. Alice calcula o HMAC da carga útil da cebola usando a chave mu.
10. Alice adiciona a chave pública da sessão (para que o salto possa calcular o segredo
compartilhado).
11. Alice adiciona o número da versão.
12. Alice torna a ocultar de forma determinística a chave de sessão usando um valor derivado de
passar o segredo compartilhado e a chave pública do salto anterior por uma função hash.
17
Em seguida, Alice repete o processo. As novas chaves são calculadas, a carga útil da cebola é
deslocada (descartando mais lixo), a nova carga útil do salto é adicionada à frente, e toda a carga
útil da cebola é criptografada com o fluxo de bytes rho para o próximo salto.
Para o último salto, o HMAC incluído no Passo #3 sobre as instruções em texto simples é, na
verdade, tudo zero. O último salto usa esse sinal para determinar que ele é realmente o último salto
no caminho. Alternativamente, o fato de que o short_chan_id incluído na carga útil para denotar o
"próximo salto" é todo zero também pode ser usado.
Observe que em cada fase a chave mu é usada para gerar um HMAC sobre o pacote de cebola
criptografado (do ponto de vista do nó que processa a carga útil), bem como sobre o conteúdo do
pacote com uma única camada de criptografia removida. Este HMAC externo permite que o nó que
processa o pacote verifique a integridade da cebola (nenhum byte foi modificado). O HMAC interno
é então revelado durante a inversão da rotina de "deslocamento e criptografia" descrita
anteriormente, o qual serve como o HMAC externo para o próximo salto.
Empacotando o Payload do Salto de Dina
Como lembrete, a cebola é embrulhada começando pelo final do caminho, a partir de Dina, o último
nó ou destinatário. Em seguida, o caminho é construído em ordem reversa até chegar ao remetente,
Alice.
Alice começa com um campo vazio de 1.300 bytes, o onion payload de comprimento fixo. Em
seguida, ela preenche o onion payload com uma sequência de bytes pseudo-randômicos chamada
de "preenchimento", que é gerada a partir da chave pad.
Isto é mostrado na Preenchendo a carga útil da cebola com um fluxo de bytes aleatório.
A geração de uma sequência de bytes aleatórios usa o algoritmo ChaCha20, que é um gerador
de números pseudo-aleatórios criptograficamente seguro (CSPRNG, Cryptographic Secure
PseudoRandom Number Generator). Esse algoritmo gera uma sequência determinística longa e
não repetitiva de bytes aparentemente aleatórios a partir de uma semente inicial. Os detalhes
são mostrados em BOLT #4: Onion Routing, Pseudo Random Byte Stream.
Figure 16. Preenchendo a carga útil da cebola com um fluxo de bytes aleatório
Agora, Alice irá inserir o a carga útil do salto de Dina no lado esquerdo do array de 1.300 bytes,
18
deslocando o preenchimento para a direita e descartando qualquer coisa que transborde. Isso é
visualizado na Adicionando a carga útil do nó de Dina.
Figure 17. Adicionando a carga útil do nó de Dina
Outra forma de entender isso é que Alice mede o comprimento da carga útil do salto de Dina,
desloca o preenchimento para a direita para criar um espaço igual no lado esquerdo da carga útil
da cebola, e insere o a carga útil (hop payload) de Dina nesse espaço.
Na próxima linha, vemos o resultado: a carga útil da cebola de 1.300 bytes contém a carga útil do
salto de Dina e, em seguida, o fluxo de bytes de preenchimento preenchendo o restante do espaço.
Em seguida, Alice ofusca toda a carga útil da cebola para que somente Dina possa lê-la.
Para fazer isso, Alice gera uma sequência de bytes usando a chave rho (que Dina também conhece).
Alice utiliza uma operação bit-a-bit exclusivo (bitwise exclusive) ou (XOR) entre os bits da carga útil
da cebola e a sequência de bytes criada a partir de rho. O resultado parece uma sequência de bytes
aleatória (ou criptografada) de comprimento 1.300 bytes. Esta etapa é mostrada na Ofuscando a
carga útil da cebola.
Figure 18. Ofuscando a carga útil da cebola
19
Uma das propriedades do XOR é que, se aplicado duas vezes, retorna aos dados originais. Como
veremos em Bob Desobscurece Sua Payload de Salto, se Dina aplicar a mesma operação XOR com a
sequência de bytes gerada a partir de rho, ela revelará a carga útil original da cebola.
XOR é uma função involutiva, o que significa que se for aplicada duas vezes, ela se desfaz.
Especificamente XOR(XOR(a, b), b) = a. Essa propriedade é amplamente usada na criptografia
de chave simétrica.
Porque apenas Alice e Dina possuem a chave rho (derivada do segredo compartilhado entre Alice e
Dina), somente elas podem fazer isso. Efetivamente, isso criptografa o conteúdo da cebola apenas
para os olhos de Dina.
Finalmente, Alice calcula um código de autenticação de mensagem baseado em hash (HMAC) para a
carga útil de Dina, que utiliza a chave mu como chave de inicialização. Isso é mostrado na
Adicionando uma soma de verificação de integridade HMAC ao payload do salto de Dina.
Figure 19. Adicionando uma soma de verificação de integridade HMAC ao payload do salto de Dina
======= Proteção e Detecção de Repetição no Roteamento em Cebola
O HMAC atua como um checksum seguro e ajuda Dina a verificar a integridade da carga útil do
salto. O HMAC de 32 bytes é anexado à carga útil do salto de Dina.Observe que calculamos o HMAC
sobre os dados criptografados em vez dos dados em texto simples. Isso é conhecido como
"criptografe primeiro e, em seguida, autentique" (encrypt-then-mac) e é a maneira recomendada de
usar um MAC, pois fornece integridade tanto para o texto simples quanto para o texto cifrado.
A criptografia autenticada moderna também permite o uso de um conjunto opcional de bytes de

texto simples a serem autenticados, conhecidos como "dados associados" (associated data). Na
prática, isso geralmente é algo como um cabeçalho de pacote em texto simples ou outras
informações auxiliares. Ao incluir esses dados associados na carga útil a ser autenticada (por meio
de um MAC), o verificador do MAC garante que esses dados associados não foram alterados (por
exemplo, substituindo o cabeçalho em texto simples em um pacote criptografado).
No contexto da Lightning Network, esses dados associados são usados para fortalecer a proteção
20
contra re-envio desse esquema. Como veremos a seguir, a proteção contra reprodução (re-envio)
garante que um atacante não possa retransmitir (reproduzir) um pacote na rede e observar o
caminho resultante. Em vez disso, os nós intermediários são capazes de usar as medidas de
proteção contra reprodução definidas para detectar e rejeitar um pacote reproduzido. O formato
básico do pacote Sphinx usa um registro de todas as chaves secretas efêmeras usadas para detectar
reproduções. Se uma chave secreta for usada novamente, o nó pode detectá-la e rejeitar o pacote.
A natureza dos HTLCs na Lightning Network nos permite fortalecer ainda mais a proteção contra
reprodução (replay) adicionando um incentivo econômico adicional. Lembre-se de que o hash de
pagamento de um HTLC só pode ser usado com segurança (para um pagamento completo) uma vez.
Se um hash de pagamento for usado novamente e passar por um nó que já tenha visto o segredo de
pagamento para aquele hash, então eles podem simplesmente receber os fundos e coletar o valor
total do pagamento sem encaminhá-lo adiante! Podemos usar esse fato para fortalecer a proteção
contra retransmissão, exigindo que o hash de pagamento seja incluído em nosso cálculo HMAC
como dado associado. Com essa etapa adicional, tentar retransmitir um pacote de cebola também
requer que o remetente se comprometa a usar o mesmo hash de pagamento. Como resultado, além
da proteção normal contra repetição, um atacante também corre o risco de perder o valor total do
HTLC repetido.
Uma consideração com o conjunto cada vez maior de chaves de sessão armazenadas para proteção
contra retransmissão é: os nós têm a capacidade de recuperar esse espaço? No contexto da Rede
Relâmpago, a resposta é: sim! Mais uma vez, devido aos atributos únicos da construção do HTLC,
podemos fazer mais uma melhoria em relação ao protocolo base do Sphinx. Dado que os HTLCs são
contratos time-locked (bloqueados por tempo) baseados na altura absoluta do bloco, uma vez que
um HTLC tenha expirado, o contrato é efetivamente encerrado permanentemente. Como resultado,
os nós podem usar a altura de expiração CLTV (operador CHECKLOCKTIMEVERIFY) como um
indicador para saber quando é seguro descartar uma entrada no registro anti-replay.
Empacotando a Carga Útil do Nó de Chan
Na Empacotando a cebola para Chan nós vemos os passos usados para empacotar a carga útil do
salto de Chan na cebola. Esses são os mesmos passos que Alice usou para empacotar a carga útil do
salto de Dina.
21
Figure 20. Empacotando a cebola para Chan
Alice inicia com a carga útil da cebola de 1.300 bytes criada para Dina. Os primeiros 65 bytes (ou
menos) dessa carga útil são a carga útil de Dina obscurecida, e o restante é preenchimento. Alice
precisa ter cuidado para não sobrescrever a carga útil de Dina.
Em seguida, Alice precisa localizar a chave pública efêmera (que foi gerada no início para cada
salto) que será anexada ao início do pacote de roteamento neste salto.
Lembre-se de que, em vez de incluir uma chave pública efêmera única (que o remetente e o nó
intermediário usam em uma operação de ECDH para gerar um segredo compartilhado), o Sphinx
usa uma única chave pública efêmera que é randomizada de forma determinística em cada salto.
Ao processar o pacote, Dina usará seu segredo compartilhado e chave pública para derivar o valor
de ofuscação (b_dina) e usá-lo para re-randomizar a chave pública efêmera, em uma operação
idêntica ao que Alice faz durante a construção inicial do pacote.
Alice adiciona um checksum HMAC interno à carga útil de de Chan e o insere na "frente" (lado
esquerdo) da carga útil da cebola, deslocando a carga útil existente para a direita em uma
quantidade igual. Lembre-se que são efetivamente dois HMACs usados no esquema: o HMAC
externo e o HMAC interno. Neste caso, o HMAC interno de Chan é na verdade o HMAC externo de
Dina.
Agora a carga útil de Chan está na frente da cebola. Quando Chan vê isso, ele não tem ideia de
quantas cargas úteis vieram antes ou depois. Parece sempre ser o primeiro de 20 saltos!
Em seguida, Alice obscurece toda a carga útil por meio de uma operação XOR com a sequência de
bytes gerada a partir da chave rho compartilhada entre Alice e Chan. Apenas Alice e Chan possuem
essa chave rho, e somente eles podem produzir a sequência de bytes para obscurecer e
22
desobscurecer a cebola. Por fim, como fizemos na etapa anterior, calculamos o HMAC externo de
Chan, que ela usará para verificar a integridade do pacote de cebola criptografada.
Empacotando a Carga Útil do Nó de Bob
Na Empacotando a cebola para Bob vemos os passos usados para empacotar a carga útil do salto de
Bob na cebola.
Tudo bem, agora isso é fácil!
Comece com a carga útil da cebola (obscurecida, ou ofuscada) contendo as cargas úteis dos saltos de
Chan e Dina.
Obtenha a chave de sessão para este salto derivada do fator de ofuscação gerado pelo salto anterior.
Inclua o HMAC externo do salto anterior como o HMAC interno deste salto. Insira a carga útil do
salto de Bob no início e desloque tudo para a direita, descartando um trecho do tamanho da carga
útil do salto de Bob do final (que era apenas preenchimento de qualquer maneira).
Obscureça o conjunto inteiro realizando a operação XOR com a chave rho obtida a partir do
segredo compartilhado entre Alice e Bob, dessa forma apenas Bob será capaz de desfazer essa
operação.
Calcule o HMAC externo e insira-o no final do payload do salto de Bob.
Figure 21. Empacotando a cebola para Bob
O Pacote de Cebola Final
O payload (carga útil) final da cebola está pronto para ser enviado a Bob. Alice não precisa
23
adicionar mais cargas úteis de saltos.
Alice calcula um HMAC para o payload da cebola para o proteger criptograficamente com um
checksum que Bob pode verificar.
Alice adiciona uma chave pública de sessão de 33 bytes que será usada por cada salto para gerar
um segredo compartilhado e as chaves rho, mu e pad.
Por fim, Alice coloca o número da versão da cebola (0 atualmente) na frente. Isso permite
atualizações futuras do formato do pacote da cebola.
O resultado pode ser visto na O pacote onion.
Figure 22. O pacote onion
Enviando a Cebola
Nesta seção, vamos analisar como o pacote da cebola é encaminhado e como os HTLCs são
implantados ao longo do caminho.
A mensagem update_add_htlc
Os pacotes de cebola são enviados como parte da mensagem update_add_htlc. Você pode se lembrar
de [update_add_htlc], no [channel_operation], vimos que o conteúdo da mensagem update_add_htlc
é o seguinte:
[u64:id]
[u64:amount_msat]
[sha256:payment_hash]
[u32:cltv_expiry]
[1366*byte:onion_routing_packet]
Você se lembrará que essa mensagem é enviada por um parceiro de canal para solicitar ao outro
parceiro de canal que adicione um HTLC. É assim que Alice vai pedir a Bob para adicionar um
HTLC para pagar Dina. Agora você entende o propósito do último campo, onion_routing_packet,
que tem 1.366 bytes de comprimento. É o pacote de cebola completamente envolto que acabamos
de construir!
24
Alice Envia a Cebola para Bob
Alice enviará a mensagem update_add_htlc para Bob. Vamos ver o que essa mensagem conterá:
channel_id
Este campo contém o ID do canal entre Alice e Bob, que em nosso exemplo é 0000031e192ca1
(veja na Um caminho detalhado construído a partir de canal divulgado e informações de nó).
id
O ID deste HTLC neste canal, começando em 0.
amount_msat
O valor do HTLC: 50.200.000 milisatoshis.
payment_hash
O hash de pagamento RIPEMD160(SHA-256):
9e017f6767971ed7cea17f98528d5f5c0ccb2c71.
cltv_expiry
O timelock de expiração para o HTLC será 700.058. Alice adiciona 20 blocos à expiração definida
na carga útil de Bob de acordo com o cltv_expiry_delta negociado de Bob.
O último pacote de cebola que Alice construiu com todas as cargas úteis de salto!
Bob Verifica a Cebola
Como vimos no [channel_operation], Bob adicionará o HTLC às transações de compromisso e

atualizará o estado do canal com Alice.
Bob irá desembrulhar a cebola que recebeu de Alice da seguinte forma:
1. Bob pega a chave de sessão do pacote de cebola e deriva o segredo compartilhado de Alice-Bob.
2. Bob gera a chave mu a partir do segredo compartilhado e a usa para verificar a soma de
verificação (checksum) HMAC do pacote de cebola.
Agora que Bob gerou a chave compartilhada e verificou o HMAC, ele pode começar a desembrulhar
a carga útil da cebola de 1.300 bytes dentro do pacote de cebola. O objetivo é para Bob recuperar
sua própria carga útil de salto e depois encaminhar a cebola restante para o próximo salto.
Se Bob extrair e remover sua carga útil de salto, a cebola restante não terá 1.300 bytes, será mais
curta! Portanto, o próximo salto saberá que não é o primeiro salto e poderá detectar o comprimento
do caminho. Para evitar isso, Bob precisa adicionar mais preenchimento para reabastecer a cebola.
Bob Gera Preenchimento
Bob gera preenchimento de uma maneira ligeiramente diferente de Alice, mas seguindo o mesmo
princípio geral.
25
Primeiro, Bob estende a carga útil da cebola em 1.300 bytes e os preenche com valores 0. Agora, o
pacote de cebola tem 2.600 bytes de comprimento, sendo que a metade inicial contém os dados
enviados por Alice e a metade seguinte contém zeros. Essa operação é mostrada na Bob estende a
carga útil da cebola em 1.300 bytes (preenchidos com zero).
Figure 23. Bob estende a carga útil da cebola em 1.300 bytes (preenchidos com zero)
Esses espaços vazios serão obscurecidos e se tornarão "preenchimento" pelo mesmo processo que
Bob usa para desobscurecer sua própria carga útil do salto. Vamos ver como isso funciona.
Bob Desobscurece Sua Payload de Salto
A seguir, Bob irá gerar a chave rho a partir da chave compartilhada Alice-Bob. Ele usará isso para
gerar um fluxo de bytes de 2.600 bytes, utilizando o algoritmo ChaCha20.
Os primeiros 1.300 bytes do fluxo de bytes gerado por Bob são exatamente iguais aos gerados
por Alice usando a chave rho.
Em seguida, Bob aplica os 2.600 bytes do fluxo de bytes rho à carga útil da cebola de 2.600 bytes
usando a operação XOR bita-bit (bitwise).
Os primeiros 1.300 bytes serão desobscurecidos por essa operação XOR, pois é a mesma operação
aplicada por Alice e XOR é involutivo. Portanto, Bob irá revelar sua carga útil do salto, seguida por
alguns dados que parecem embaralhados.
Ao mesmo tempo, aplicar o fluxo de bytes rho aos 1.300 zeros que foram adicionados à carga útil da
cebola os transformará em dados de preenchimento aparentemente aleatórios. Essa operação é
mostrada na Bob desobscurece a cebola, obscurece o preenchimento.
26
Figure 24. Bob desobscurece a cebola, obscurece o preenchimento
Bob Extrai o HMAC Externo para o Próximo Salto
Lembre-se de que um HMAC interno é incluído para cada salto, que então se tornará o HMAC
externo para o próximo salto. Nesse caso, Bob extrai o HMAC interno (ele já verificou a integridade
do pacote criptografado com o HMAC externo) e o separa, pois ele o anexará ao pacote
desobscurecido para permitir que Chan verifique o HMAC do pacote criptografado dele.
Bob Remove sua Carga Útil e Desloca a Cebola para a Esquerda
Agora Bob pode remover sua carga útil do salto da frente da cebola e deslocar os dados restantes
para a esquerda. Uma quantidade de dados igual à carga útil do salto de Bob da segunda metade de
preenchimento de 1.300 bytes agora será deslocada para o espaço da carga útil da cebola. Isso é
mostrado na Bob remove a carga útil do salto e desloca o resto para a esquerda, preenchendo a
lacuna com um novo preenchimento.
Agora Bob pode manter os primeiros 1.300 bytes da primeira metade e descartar os 1.300 bytes
estendidos (preenchimento).
Agora Bob tem um pacote de cebola de 1.300 bytes para enviar ao próximo salto. É quase idêntico à
carga de cebola que Alice criou para Chan, exceto que os últimos 65 bytes aproximadamente de
preenchimento foram adicionados por Bob e serão diferentes.
27
Figure 25. Bob remove a carga útil do salto e desloca o resto para a esquerda, preenchendo a lacuna com
um novo preenchimento
Ninguém pode distinguir o preenchimento colocado por Alice do preenchimento colocado por Bob.
O preenchimento é preenchimento! São todos bytes aleatórios de qualquer maneira. Note que se
Bob (ou um de seus outros aliases) estiver presente na rota em duas localizações distintas, então ele
pode distinguir porque o protocolo base sempre usa o mesmo hash de pagamento em toda a rota.
Pagamentos multicaminho atômicos (AMPs, Atomic Multipath Peyments) e Contratos com Tempo
Bloqueado de Ponto (PTLCs, Point Time-Locked Contracts) eliminam o vetor de correlação ao
randomizar o identificador de pagamento em cada rota/salto.
Bob Constrói o Novo Pacote de Cebola
Bob agora copia a carga útil da cebola para o pacote da cebola, acrescenta o HMAC externo para
Chan, re-randomiza a chave de sessão (da mesma forma que Alice, o remetente, faz) com a
operação de multiplicação da curva elíptica e acrescenta um novo byte de versão.
Para re-randomizar a chave de sessão, Bob primeiro calcula o fator de obscurecimento para o seu
salto, usando a sua chave pública de nó e o segredo compartilhado que ele derivou:
b_bob = SHA-256(P_bob || shared_secret_bob)
Com isso gerado, Bob agora re-aleatoriza a chave de sessão realizando uma multiplicação EC
usando sua chave de sessão e o fator de obscurecimento:
session_key_chan = session_key_bob * b_bob
A chave pública session_key_chan será então anexada à frente do pacote de cebola para
28
processamento por Chan.
Bob Verifica os Detalhes do HTLC
A carga útil do salto de Bob contém as instruções necessárias para criar um HTLC para Chan.
No payload (carga útil) do salto, Bob encontra um short_channel_id, amt_to_forward e cltv_expiry.
Primeiro, Bob verifica se ele possui um canal com aquele ID curto. Ele descobre que possui um
canal com Chan.
Em seguida, Bob confirma que o valor de saída (50.100 satoshis) é menor que o valor de entrada
(50.200 satoshis), e portanto as expectativas de taxa de Bob são atendidas.
Da mesma forma, Bob verifica se o cltv_expiry de saída é menor que o cltv_expiry de entrada,
dando a Bob tempo suficiente para reivindicar o HTLC de entrada caso ocorra uma violação.
Bob Envia o update_add_htlc para Chan
Bob agora constrói um HTLC para enviar para Chan, como segue:
channel_id
Este campo contém o ID do canal entre Bob e Chan, que em nosso exemplo é 000004040a61f0
(veja Um caminho detalhado construído a partir de canal divulgado e informações de nó).
id
O ID deste HTLC neste canal, começando em 0.
amount_msat
A quantidade do HTLC é de 50.100.000 millisatoshis.
payment_hash
O hash de pagamento RIPEMD160(SHA-256):
9e017f6767971ed7cea17f98528d5f5c0ccb2c71.
Este é o mesmo que o hash de pagamento do HTLC de Alice.
cltv_expiry
O tempo limite de expiração para o HTLC será de 700.038.
O pacote de cebola reconstruído por Bob após remover sua carga útil do salto.
Chan Encaminha a Cebola
Chan repete exatamente o mesmo processo que Bob:
1. Chan recebe o update_add_htlc e processa a solicitação do HTLC, adicionando-a às transações de

compromisso.
29
2. Chan gera a chave compartilhada Alice-Chan e a subchave mu.
3. Chan verifica o pacote de cebola HMAC, e então extrai a carga útil da cebola de 1.300 bytes.
4. Chan estende o a carga útil da cebola em 1.300 bytes extras, preenchendo-a com zeros.
5. Chan usa a chave rho para produzir 2.600 bytes.
6. Chan usa o fluxo de bytes gerado para XOR e desobscurecer a carga útil da cebola.
Simultaneamente, a operação XOR obscurece os 1.300 zeros extras, transformando-os em
preenchimento.
7. Chan extrai o HMAC interno na carga útil, que se tornará o HMAC externo para Dina.
8. Chan remove sua carga útil de salto e desloca à esquerda a carga útil da cebola pela mesma
quantidade. Algumas das informações de preenchimento geradas nos 1.300 bytes estendidos
movem-se para os primeiros 1.300 bytes, tornando-se parte da carga útil da cebola.
9. Chan constrói o pacote de cebola para Dina com essa carga útil de cebola.
10. Chan cria uma mensagem update_add_htlc para Dina e insere o pacote de cebola dentro dela.
11. Chan envia o update_add_htlc para Dina.
12. Chan re-randomiza novamente a chave de sessão como Bob fez no salto anterior para Dina.
Dina Recebe a Carga Final
Quando Dina recebe a mensagem update_add_htlc de Chan, ela sabe pelo payment_hash que este é
um pagamento para ela. Ela sabe que é o último salto na cebola.
Dina segue exatamente o mesmo processo que Bob e Chan para verificar e desembrulhar a cebola,
exceto que ela não constrói novas informações de preenchimento e não encaminha nada. Em vez
disso, Dina responde a Chan com update_fulfill_htlc para resgatar a HTLC. O update_fulfill_htlc
fluirá de volta ao longo do caminho até chegar a Alice. Todas as HTLCs são resgatadas e os saldos
dos canais são atualizados. O pagamento está completo!
Retornando Erros
Até agora, examinamos a propagação para a frente da cebola estabelecendo os HTLCs e a
propagação para trás do segredo de pagamento desfazendo os HTLCs uma vez que o pagamento é
bem-sucedido.
Existe outra função muito importante do roteamento em cebola: o retorno de erros (error return).
Se houver algum problema com o pagamento, a cebola ou os saltos, devemos propagar um erro de
volta para informar a todos os nós sobre a falha e desfazer quaisquer HTLCs.
Os erros geralmente se enquadram em três categorias: falhas na cebola, falhas de nós e falhas de
canais. Além disso, esses erros podem ser subdivididos em erros permanentes e transitórios. Por
fim, alguns erros contêm atualizações de canal para auxiliar em tentativas futuras de entrega de
pagamento.
Ao contrário das mensagens no protocolo peer-to-peer (P2P) (definido em BOLT #2: Peer
Protocol for Channel Management), erros não são enviados como mensagens P2P, mas são
30
envoltos em pacotes de retorno de cebola e seguem o caminho reverso da cebola (propagação
reversa).
O retorno de erros é definido em BOLT #4: Onion Routing, Returning Errors.
Os erros são codificados pelo nó de retorno (aquele que descobriu um erro) em um pacote de
retorno (return packet) da seguinte forma:
[32*byte:hmac]
[u16:failure_len]
[failure_len*byte:failuremsg]
[u16:pad_len]
[pad_len*byte:pad]
O checksum de verificação HMAC do pacote de retorno é calculado com a chave um, gerada a partir
do segredo compartilhado estabelecido pela cebola.
O nome da chave um é o reverso do nome mu, indicando o mesmo uso, mas na direção oposta
(propagação reversa).
Em seguida, o nó que retorna gera uma chave ammag (inverso da palavra "gamma") e obscurece o
pacote de retorno usando uma operação XOR com uma sequência de bytes gerada a partir do
ammag.
Finalmente, o nó de retorno envia o pacote de retorno para o salto do qual ele recebeu a cebola
original.
Cada salto que recebe um erro irá gerar uma chave ammag e obscurecer novamente o pacote de
retorno usando uma operação XOR com o fluxo de bytes de ammag.
Eventualmente, o remetente (nó de origem) recebe um pacote de retorno. Em seguida, ele irá gerar
chaves ammag e um para cada salto e desobscurecer iterativamente o erro de retorno usando a
operação XOR até revelar o pacote de retorno.
Mensagens de Falha
A failuremsg está definida em BOLT #4: Onion Routing, Failure Messages.
Uma mensagem de falha consiste em um código de falha de dois bytes (failure code) seguido dos
dados aplicáveis a esse tipo de falha.
O byte superior do failure_code é um conjunto de flags binárias que podem ser combinadas
(usando OR binário):
0x8000 (BADONION)
Unparsable onion encrypted by sending peer
31
0x4000 (PERM)
Permanent failure (otherwise transient)
0x2000 (NODE)
Node failure (otherwise channel)
0x1000 (UPDATE)
New channel update enclosed
Os tipos de falhas mostrados na [failure_types_table] são atualmente definidos.
type symbolic name meaning
PERM|1 invalid_realm The realm byte was not

understood by the processing
node
NODE|2 temporary_node_failure General temporary failure of

the processing node
PERM|NODE|2 permanent_node_failure General permanent failure of

the processing node
PERM|NODE|3 required_node_feature_missing The processing node has a

required feature which was not
in this onion
BADONION|PERM|4 invalid_onion_version The version byte was not

understood by the processing
node
BADONION|PERM|5 invalid_onion_hmac The HMAC of the onion was

incorrect when it reached the
processing node
BADONION|PERM|6 invalid_onion_key The ephemeral key was

unparsable by the processing
node
UPDATE|7 temporary_channel_failure The channel from the

processing node was unable to
handle this HTLC, but may be
able to handle it, or others, later
PERM|8 permanent_channel_failure The channel from the

processing node is unable to
handle any HTLCs
PERM|9 required_channel_feature_missi The channel from the

ng processing node requires
features not present in the
onion
32
PERM|10 unknown_next_peer The onion specified a
short_channel_id which doesn’t
match any leading from the
processing node
UPDATE|11 amount_below_minimum The HTLC amount was below

the htlc_minimum_msat of the
channel from the processing
node
UPDATE|12 fee_insufficient The fee amount was below that

required by the channel from
the processing node
UPDATE|13 incorrect_cltv_expiry The cltv_expiry does not

comply with the
cltv_expiry_delta required by
the channel from the processing
node
UPDATE|14 expiry_too_soon The CLTV expiry is too close to

the current block height for safe
handling by the processing
node
PERM|15 incorrect_or_unknown_paymen The payment_hash is unknown to

t_details the final node, the
payment_secret doesn’t match
the payment_hash, the amount
for that payment_hash is too low,
the CLTV expiry of the htlc is
too close to the current block
height for safe handling or
payment_metadata isn’t present
while it should be
18 final_incorrect_cltv_expiry The CLTV expiry in the HTLC is

less than the value in the onion
19 final_incorrect_htlc_amount The amount in the HTLC is less

than the value in the onion
UPDATE|20 channel_disabled The channel from the

processing node has been
disabled
21 expiry_too_far The CLTV expiry in the HTLC is

too far in the future
PERM|22 invalid_onion_payload The decrypted onion per-hop

payload was not understood by
the processing node or is
incomplete
33
23 mpp_timeout The complete amount of the
multi-part payment was not
received within a reasonable
time
BADONION|PERM|24 invalid_onion_blinding An error occurred within the

blinded path
Pagamentos Travados
Na implementação atual da Lightning Network, existe a possibilidade de uma tentativa de

pagamento ficar travada: nem concluída nem cancelada devido a um erro. Isso pode ocorrer devido
a um bug em um nó intermediário, um nó ficando offline durante o processamento de HTLCs ou
um nó malicioso retendo HTLCs sem reportar um erro. Em todos esses casos, o HTLC não pode ser
resolvido até que expire. O timelock (CLTV) definido em cada HTLC ajuda a resolver essa condição
(entre outras possíveis falhas de roteamento HTLC e falhas de canal).
No entanto, isso significa que o remetente do HTLC precisa esperar até o vencimento, e os fundos
comprometidos com esse HTLC permanecem indisponíveis até que o HTLC expire. Além disso, o
remetente não pode tentar novamente o mesmo pagamento, porque se o fizer, corre o risco de
ambos o pagamento original e o refeito serem bem-sucedidos—o destinatário recebe o pagamento
duas vezes. Isso ocorre porque, uma vez enviado, um HTLC não pode ser "cancelado" pelo
remetente—ele precisa falhar ou expirar. Pagamentos travados, embora sejam raros, criam uma
experiência indesejada para o usuário, onde a carteira do usuário não pode pagar nem cancelar um
pagamento.
Uma solução proposta para esse problema é chamada de stuckless payments (pagamentos que não
travam), e ela depende dos Contratos Pontuais com Bloqueio de Tempo (PTLCs), que são contratos
de pagamento que usam uma primitiva criptográfica diferente dos HTLCs (ou seja, adição de ponto
na curva elíptica em vez de um hash e pré-imagem secreta). Os PTLCs são complicados de serem
implementados com o ECDSA, mas são muito mais fáceis com os recursos de assinatura de Schnorr
e Taproot do Bitcoin, que foram recentemente ativados em novembro de 2021. Espera-se que os
PTLCs sejam implementados na Lightning Network após a ativação desses recursos do Bitcoin.
Pagamentos Espontâneos Keysend (Envio de Chaves)

No fluxo de pagamento descrito anteriormente no capítulo, assumimos que Dina recebeu uma
fatura de Alice "fora de banda" ou a obteve por algum mecanismo não relacionado ao protocolo
(normalmente copiar/colar ou varreduras de código QR). Esta característica significa que o processo
de pagamento sempre tem duas etapas: primeiro, o remetente obtém uma fatura e, em segundo
lugar, usa o hash de pagamento (codificado na fatura) para rotear com sucesso um HTLC. A viagem
de ida e volta extra necessária para obter uma fatura antes de efetuar um pagamento pode ser um
gargalo em aplicações que envolvem streaming de micropagamentos através da Lightning. E se
pudéssemos simplesmente "empurrar" um pagamento espontaneamente, sem ter que obter uma
fatura do destinatário primeiro? O protocolo keysend é uma extensão de ponta a ponta (somente o
remetente e receptor estão cientes) para o protocolo Lightning que permite que se empurre
pagamentos espontaneamente.
34
Registros Onion LTV Personalizados
O protocolo moderno Lightning utiliza a codificação TLV (Type-Length-Value) na cebola para

codificar informações que dizem a cada nó para onde e como encaminhar o pagamento.
Aproveitando o formato TLV, a cada informação de roteamento (como o próximo nó para o qual
passar o HTLC) é atribuído um tipo específico (ou chave) codificado como um número inteiro de
comprimento variável BigSize (tamanho máximo de 64 bits). Esses tipos "essenciais" (valores
invertidos abaixo de 65536) são definidos no BOLT #4, junto com o restante dos detalhes de
roteamento da cebola. Tipos de cebola com um valor superior a 65536 são destinados a serem
usados por carteiras e aplicativos como "registros personalizados".
Os registros personalizados permitem que os aplicativos de pagamento anexem metadados

adicionais ou contexto para um pagamento como pares chave/valor na cebola. Como os registros
personalizados estão incluídos na própria carga de cebola, assim como todos os outros conteúdos
de salto, os registros são criptografados de ponta a ponta. Como os registros personalizados
efetivamente consomem uma parte do pacote cebola de 1300 bytes de tamanho fixo, codificando
cada chave e valor de cada registro personalizado reduz a quantidade de espaço disponível para
codificação do resto da rota. Na prática, isso significa que quanto mais espaço de cebola usado para
registros personalizados, mais curta pode ser a rota. Dado que cada pacote HTLC é de tamanho fixo,
os registros personalizados não adicionam nenhum dado adicional a um HTLC; em vez disso, eles
realocam bytes que seriam caso contrário preenchidos com dados aleatórios.
Enviando e Recebendo Pagamentos Keysend
Um pagamento keysend inverte o fluxo típico de um HTLC, onde o destinatário revela uma pré-
imagem secreta ao remetente. Em vez disso, o remetente inclui a pré-imagem dentro da cebola para
o receptor e roteia o HTLC para o receptor. O receptor então descriptografa a carga útil da cebola e
usa a pré-imagem incluída (que deve corresponder ao hash de pagamento do HTLC) para liquidar o
pagamento. Como resultado, os pagamentos keysend podem ser realizados sem primeiro obter uma
fatura do destinatário, pois a pré-imagem é "empurrada" para o receptor. Um pagamento keysend
usa um tipo de registro personalizado TLV de 5482373484 para codificar um valor de pré-imagem de
32 bytes.
Keysend e Registros Personalizados em Aplicativos Lightning
Muitos aplicativos de streaming do Lightning utilizam o protocolo keysend para continuamente

transmitir satoshis para um destino identificado por sua chave pública na rede. Normalmente, um
aplicativo também incluirá metadados, como uma observação gorjeta/doação ou outras
informações no nível do aplicativo, além do registro keysend.
Conclusão
O protocolo de roteamento onion da Lightning Network é adaptado do protocolo Sphinx para
atender melhor às necessidades de uma rede de pagamentos. Como tal, oferece uma grande
melhoria em privacidade e contra-vigilância em comparação com a blockchain público e
transparente do Bitcoin.
No [path_finding] veremos como a combinação de roteamento de origem e roteamento onion é
35
usada por Alice para encontrar um bom caminho e rotear o pagamento para Dina. Para encontrar
um caminho, Alice precisa primeiro conhecer a topologia da rede, que é o tema do [gossip].
[1] George Danezis and Ian Goldberg, "Sphinx: A Compact and Provably Secure Mix Format," in IEEE Symposium on Security and
Privacy (New York: IEEE, 2009), 269–282.
36
Gossip e o Grafo de Canais
Neste capítulo, descreveremos o protocolo de gossip da Lightning Network e como ele é usado pelos
nós para construir e manter um grafo de canais. Também revisaremos o mecanismo de
inicialização DNS usado para encontrar pares com os quais "conversar" por meio do gossip.
A seção "Taxas de roteamento e retransmissão de gossip" é destacada por um esboço que abrange a
camada de roteamento e a camada peer-to-peer na Protocolo de Fofoca (Gossip) no Conjunto de
Protocolos Lightning.
Figure 1. Protocolo de Fofoca (Gossip) no Conjunto de Protocolos Lightning
Como já aprendemos, a Lightning Network utiliza um protocolo de roteamento onion baseado em

origem para entregar um pagamento do remetente ao destinatário. Para fazer isso, o nó remetente
deve ser capaz de construir um caminho de canais de pagamento que o conecte ao destinatário,
como veremos no [path_finding]. Portanto, o remetente deve ser capaz de mapear a Lightning
Network construindo um grafo de canais. O channel graph é o conjunto interconectado de canais
anunciados publicamente e os nós que esses canais interligam.
Como os canais são respaldados por uma transação de financiamento que ocorre na cadeia (on-
chain), alguém poderia erroneamente acreditar que os nós da Lightning poderiam simplesmente
extrair os canais existentes da blockchain do Bitcoin. No entanto, isso só é possível até certo ponto.
As transações de financiamento são endereços Pay-to-Witness-Script-Hash (P2WSH), e a natureza
do script (multisig 2-de-2) só será revelada quando a saída da transação de financiamento for gasta.
Mesmo que a natureza do script seja conhecida, é importante lembrar que nem todos os scripts
multisig 2-de-2 correspondem a canais de pagamento.
Existem ainda mais razões pelas quais olhar para o blockchain do Bitcoin pode não ser útil. Por
exemplo, na Lightning Network, as chaves do Bitcoin que são usadas para assinar são rotacionadas
pelos nós para cada canal e atualização. Portanto, mesmo que pudéssemos detectar de forma
confiável as transações de financiamento na blockchain do Bitcoin, não saberíamos quais dois nós
1
da Lightning Network possuem aquele canal específico.
A Lightning Network resolve esse problema implementando um protocolo gossip (conversa, ou

fofoca). Os protocolos de fofoca são típicos de redes peer-to-peer (P2P) e permitem que os nós
compartilhem informações com toda a rede com apenas algumas conexões diretas com os pares. Os
nós da Lightning estabelecem conexões peer-to-peer criptografadas entre si e compartilham
(gossip) informações que receberam de outros pares. Assim que um nó deseja compartilhar alguma
informação, por exemplo, sobre um novo canal criado, ele envia uma mensagem para todos os seus
pares. Ao receber uma mensagem, um nó decide se a mensagem recebida é nova e, caso seja,
encaminha a informação para seus pares. Dessa forma, se a rede peer-to-peer estiver bem
conectada, todas as novas informações necessárias para o funcionamento da rede serão
eventualmente propagadas para todos os outros pares.
Obviamente, se um novo peer se juntar à rede pela primeira vez, ele precisa conhecer alguns outros
peers na rede para poder se conectar a outros e participar da rede.
Neste capítulo, vamos explorar exatamente como os nós da Lightning descobrem uns aos outros,
descobrem e atualizam seus status de nó e se comunicam entre si.
Quando a maioria se refere à parte rede da Lightning Network ou Rede Relâmpago, eles estão se
referindo ao grafo de canais, que é uma estrutura de dados autenticada única ancorada na
blockchain base do Bitcoin.
No entanto, a Lightning Network também é uma rede peer-to-peer de nós que fazem gossip de
informações sobre canais de pagamento e nós. Geralmente, para que dois pares mantenham um
canal de pagamento, eles precisam se comunicar diretamente, o que significa que haverá uma
conexão peer entre eles. Isso sugere que o grafo de canais é uma sub-rede da rede peer-to-peer. No
entanto, isso não é verdade porque os canais de pagamento podem permanecer abertos mesmo se
um ou ambos os pares ficarem temporariamente offline.
Vamos revisitar alguns dos termos que utilizamos ao longo do livro, analisando especificamente o
que eles significam em termos do grafo de canais e da rede peer-to-peer (see Terminologia das
diferentes redes).
Table 1. Terminologia das diferentes redes
Channel graph Peer-to-peer network
channel connection
open connect
close disconnect
funding transaction encrypted TCP/IP connection
send transmit
payment message
Como a Lightning Network é uma rede peer-to-peer, é necessário algum processo inicial de
inicialização (bootstrapping) para que os pares se descubram. Neste capítulo, acompanharemos a
história de um novo par conectando-se à rede pela primeira vez e examinaremos cada etapa do
processo de inicialização, desde a descoberta inicial de pares até a sincronização e validação do
2
grafo de canais.
Como um passo inicial, nosso novo nó precisa de alguma forma descobrir pelo menos um par que já
esteja conectado à rede e tenha um grafo de canais completo (como veremos mais adiante, não há
uma versão canônica do grafo de canais). Utilizando um dos muitos protocolos de inicialização
iniciais para encontrar esse primeiro par, depois que uma conexão é estabelecida, nosso novo par
agora precisa baixar e validar o grafo de canais. Uma vez que o grafo de canais tenha sido
totalmente validado, nosso novo par estará pronto para começar a abrir canais e enviar
pagamentos na rede.
Após a inicialização inicial, um nó na rede precisa continuar mantendo sua visão do grafo de canais
por meio do processamento de novas atualizações de políticas de roteamento de canais, descoberta
e validação de novos canais, remoção de canais que foram encerrados on-chain e, finalmente, poda
de canais que não enviam um sinal (heartbeat) adequado a cada duas semanas. mais ou menos.
Ao finalizar este capítulo, você entenderá um componente fundamental de uma Rede Relâmpago
peer-to-peer: ou seja, como os pares se descobrem e mantêm uma cópia local (perspectiva) do grafo
de canais. Vamos começar explorando a história de um novo nó que acabou de ser iniciado e
precisa encontrar outros pares para se conectar na rede.
Descoberta de Pares
Nesta seção, vamos acompanhar um novo nó da Lightning que deseja ingressar na rede por meio
de três etapas:
1. Descobrir um grupo de pares de inicialização (bootstrap peers)
2. Baixar e validar o grafo de canais
3. Iniciar o processo de manutenção contínua do próprio grafo de canal
Inicialização P2P
Antes de fazer qualquer outra coisa, nosso novo nó primeiro precisa descobrir um conjunto de
pares que já façam parte da rede. Chamamos esse processo de inicialização de pares, e é algo que
toda rede peer-to-peer precisa implementar corretamente para garantir uma rede robusta e
saudável.
A inicialização de novos pares em redes peer-to-peer existentes é um problema muito bem

estudado, com várias soluções conhecidas, cada uma com suas próprias vantagens e desvantagens
(trade-offs). A solução mais simples para esse problema é simplesmente empacotar um conjunto de
pares de inicialização (bootstrap peers) hardcoded (codificados) no software do nó P2P empacotado.
Isso é simples no sentido de que cada novo nó tem uma lista de pares de inicialização no software
em que estão executando, mas é bastante frágil, pois se o conjunto de pares de inicialização ficar
offline, nenhum novo nó será capaz de ingressar na rede. Devido a essa fragilidade, essa opção
geralmente é usada como um último recurso caso nenhum dos outros mecanismos de inicialização
P2P funcione corretamente.
Em vez de codificar o conjunto de pares de inicialização dentro do próprio software/binário,

podemos permitir que os pares obtenham dinamicamente um conjunto fresco/novo de pares de
3
inicialização que eles possam usar para ingressar na rede. Chamaremos esse processo de
descoberta inicial de pares. Normalmente, aproveitaremos protocolos de internet existentes para
manter e distribuir um conjunto de pares de inicialização. Uma lista não exaustiva de protocolos
que foram usados no passado para realizar a descoberta inicial de pares inclui:
• Domain Name Service (DNS)
• Internet Relay Chat (IRC)
• Hypertext Transfer Protocol (HTTP)
Similar ao protocolo Bitcoin, o principal mecanismo de descoberta inicial de pares usado na

Lightning Network ocorre por meio do DNS. Como a descoberta inicial de pares é uma tarefa crítica
e universal para a rede, o processo foi padronizado em BOLT #10: DNS Bootstrap.
Inicialização DNS
O documento BOLT #10 descreve uma forma padrão de implementar a descoberta de pares usando
o DNS. A inicialização baseada em DNS da Lightning utiliza até três tipos distintos de registros:
• Registros SRV para descobrir um conjunto de chaves públicas de nós.
• Registros A para mapear a chave pública de um nó para seu endereço IPv4 atual.
• Registros AAA para mapear a chave pública de um nó para seu endereço IPv6 atual.
Aqueles que estão um pouco familiarizados com o protocolo DNS podem já estar familiarizados
com os tipos de registro A (nome para endereço IPv4) e AAA (nome para endereço IPv6), mas não
com o tipo SRV. O tipo de registro SRV é usado por protocolos construídos sobre o DNS para
determinar a localização de um serviço específico. No nosso contexto, o serviço em questão é um nó
Lightning, e a localização é o seu endereço IP. Precisamos usar esse tipo adicional de registro
porque, ao contrário dos nós no protocolo Bitcoin, precisamos tanto de uma chave pública quanto
de um endereço IP para nos conectar a um nó. Como veremos no [wire_protocol], o protocolo de
criptografia de transporte usado na Lightning Network requer o conhecimento da chave pública de
um nó antes de estabelecer uma conexão, a fim de implementar o ocultamento de identidade para
os nós na rede.
Fluxo de trabalho de inicialização de um novo par
Antes de mergulhar nos detalhes de BOLT #10, vamos primeiro delinear o fluxo de alto nível de um
novo nó que deseja usar o BOLT #10 para entrar na rede.
Primeiro, um nó precisa identificar um único servidor DNS ou um conjunto de servidores DNS que
entendam o BOLT #10 para que possam ser usados para inicialização P2P.
Embora o BOLT #10 use lseed.bitcoinstats.com como servidor de seed, não existe um conjunto
"oficial" de seeds DNS para esse fim. No entanto, cada uma das principais implementações mantém
seu próprio seed DNS e eles fazem consultas cruzadas nos seeds umas das outras por motivos de
redundância. Na Tabela de servidores de seed DNS do Lightning conhecidos você verá uma lista
não exaustiva de alguns servidores de seed DNS populares.
Table 2. Tabela de servidores de seed DNS do Lightning conhecidos
4
DNS server Maintainer
lseed.bitcoinstats.com Christian Decker
nodes.lightning.directory Lightning Labs (Olaoluwa Osuntokun)
soa.nodes.lightning.directory Lightning Labs (Olaoluwa Osuntokun)
lseed.darosior.ninja Antoine Poinsot
As sementes (seeds) de DNS existem tanto para a rede principal quanto para a rede de teste do
Bitcoin. Pelo bem de nosso exemplo, assumiremos a existência de uma semente de DNS BOLT #10
válida em nodes.lightning.directory.
Em seguida, nosso novo nó emitirá uma consulta SRV para obter um conjunto de candidatos a pares
de inicialização. A resposta à nossa consulta será uma série de chaves públicas codificadas em
bech32. Como o DNS é um protocolo baseado em texto, não podemos enviar dados binários brutos,
portanto, é necessário um esquema de codificação. O BOLT #10 especifica uma codificação bech32
devido ao seu uso no ecossistema mais amplo do Bitcoin. O número de chaves públicas codificadas
retornadas depende do servidor que responde à consulta, bem como de todos os resolvedores que
estão entre o cliente e o servidor autoritativo.
Usando a ferramenta de linha de comando amplamente disponível dig, podemos consultar a versão
de testnet da semente DNS mencionada anteriormente com o seguinte comando:
$ dig @8.8.8.8 test.nodes.lightning.directory SRV
Usamos o argumento @ para forçar a resolução via servidor de nomes do Google (com o endereço
IP 8.8.8.8) porque ele não filtra grandes respostas de consultas SRV. No final do comando,
especificamos que queremos apenas que registros SRV sejam retornados. Uma resposta de exemplo
se parece com Consultando a semente DNS para nós alcançáveis.
Example 1. Consultando a semente DNS para nós alcançáveis
$ dig @8.8.8.8 test.nodes.lightning.directory SRV
; <<>> DiG 9.10.6 <<>> @8.8.8.8 test.nodes.lightning.directory SRV

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43610
;; flags: qr rd ra; QUERY: 1, ANSWER: 25, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;test.nodes.lightning.directory. IN SRV
;; ANSWER SECTION:
test.nodes.lightning.directory. 59 IN SRV 10 10 9735 ①
ln1qfkxfad87fxx7lcwr4hvsalj8vhkwta539nuy4zlyf7hqcmrjh40xx5frs7.test.nodes.lightnin
g.directory. ②
5
test.nodes.lightning.directory. 59 IN SRV 10 10 15735
ln1qtgsl3efj8verd4z27k44xu0a59kncvsarxatahm334exgnuvwhnz8dkhx8.test.nodes.lightnin
g.directory.
[...]
;; Query time: 89 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Dec 31 16:41:07 PST 2020
① Número da porta TCP onde o nó LN pode ser alcançado.
② Chave pública do nó (ID) codificada como um nome de domínio virtual.
Nós truncamos a resposta por questões de brevidade e mostramos apenas duas das respostas
retornadas. As respostas contêm um nome de domínio "virtual" para um nó de destino, e à
esquerda temos a porta TCP onde esse nó pode ser alcançado. A primeira resposta usa a porta TCP
padrão para a Lightning Network: 9735. A segunda resposta usa uma porta personalizada, o que é
permitido pelo protocolo.
A seguir, tentaremos obter o outro pedaço de informação de que precisamos para nos conectar a
nós: o endereço IP dele. Antes de podermos fazer a consulta para isso, no entanto, primeiro faremos
a decodificação da codificação bech32 da chave pública a partir do nome de domínio virtual:
ln1qfkxfad87fxx7lcwr4hvsalj8vhkwta539nuy4zlyf7hqcmrjh40xx5frs7
Decodificando esta string bech32, obtemos a seguinte chave pública válida secp256k1 :
026c64f5a7f24c6f7f0e1d6ec877f23b2f672fb48967c2545f227d70636395eaf3
Agora que temos a chave pública bruta, vamos pedir ao servidor DNS para resolver o host virtual
fornecido para que possamos obter as informações de IP (registro A) para o nó, como mostrado no
[ex1102].
<div id="ex1102" data-type="example">

<h5>Obtendo o endereço de IP mais recente para um nó</h5>
<pre data-type="programlisting">$ dig

ln1qfkxfad87fxx7lcwr4hvsalj8vhkwta539nuy4zlyf7hqcmrjh40xx5frs7.test.nodes.lightning.direct
ory A
; <<>> DiG 9.10.6 <<>>

ory A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41934
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
6
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ln1qfkxfad87fxx7lcwr4hvsalj8vhkwta539nuy4zlyf7hqcmrjh40xx5frs7.test.nodes.lightning.direc
tory. IN A
;; ANSWER SECTION:
ory. 60 IN A X.X.X.X <a class="co" id="comarker1" href="#c01"><img
src="callouts/1.png" alt="1"/></a>
;; Query time: 83 msec

;; SERVER: 2600:1700:6971:6dd0::1#53(2600:1700:6971:6dd0::1)
;; WHEN: Thu Dec 31 16:59:22 PST 2020
;; MSG SIZE rcvd: 138</pre>
<dl class="calloutlist">
<dt><a class="co" id="c01" href="#comarker1"><img src="callouts/1.png" alt="1"/></a></dt>
<dd>O servidor DNS retorna um endereço de IP <code>X.X.X.X</code>. Substituímos
por X's aqui no texto para evitar apresentar um endereço IP real.</dd>
</dl></div>
No comando anterior, consultamos o servidor para obter um endereço IPv4 (Um registro) de
dendereço para nosso nó alvo (substituído por __X.X.X.X__ no exemplo anterior). Agora que temos a
chave pública bruta, o endereço IP e a porta TCP, podemos nos conectar ao protocolo de transporte
do nó em:
026c64f5a7f24c6f7f0e1d6ec877f23b2f672fb48967c2545f227d70636395eaf3@X.X.X.X:9735
Consultar o registro DNS A atual de um determinado nó também pode ser usado para procurar o
conjunto mais recente de endereços. Essas consultas podem ser usadas para sincronizar mais
rapidamente as informações de endereço mais recentes de um nó, em comparação com a espera
por atualizações de endereço na rede gossip (see A Mensagem node_announcement).
Neste ponto de nossa jornada, nosso novo nó Lightning encontrou seu primeiro peer e estabeleceu
sua primeira conexão! Agora podemos começar a segunda fase de inicialização de novos pares:
sincronização e validação do grafo de canal.
Primeiro, vamos explorar mais das complexidades do BOLT #10 em si para obter uma visão mais
profunda de como as coisas funcionam por baixo dos panos.
Opções de Consulta SRV
O BOLT #10 o padrão é altamente extensível devido ao uso de subdomínios aninhados como uma
camada de comunicação para opções de consulta adicionais. O protocolo de inicialização permite
que os clientes especifiquem ainda mais o tipo de nós que estão tentando consultar, em oposição ao
padrão de receber um subconjunto aleatório de nós nas respostas da consulta.
7
O esquema de subdomínio de opções de consulta usa uma série de pares chave-valor, em que a
chave em si é uma letra única e o conjunto restante de texto é o próprio valor.Os seguintes tipos de
consulta existem na versão atual do BOLT #10 documento de padrões:
r
O byte realm (domínio) que é usado para determinar para qual cadeia ou domínio as consultas
devem ser retornadas. Atualmente, o único valor para essa chave é 0, que denota "Bitcoin".
a
Permite que os clientes filtrem os nós retornados com base nos tipos de endereços que eles
anunciam. Por exemplo, isso pode ser usado para obter apenas nós que anunciam um endereço
IPv6 válido. O valor que segue esse tipo é baseado em um campo de bits que indexa o conjunto
de tipos de endereços específicos definidos em BOLT #7. O valor padrão para esse campo é 6, que
representa tanto IPv4 quanto IPv6 (os bits 1 e 2 estão definidos).
l
Uma chave pública de nó válida serializada em formato comprimido. Isso permite que um
cliente faça uma consulta para um nó específico em vez de receber um conjunto de nós
aleatórios.
n
O número de registros a serem retornados. O valor padrão para esse campo é 25.
Um exemplo de consulta com opções de consulta adicionais se parece com o seguinte:
r0.a2.n10.nodes.lightning.directory
Analisando a consulta um par chave-valor de cada vez, obtemos os seguintes insights:
r0
A consulta tem como alvo o domínio Bitcoin
a2
A consulta deseja apenas que endereços IPv4 sejam retornados
n10
Os pedidos de consulta
Tente algumas combinações dos vários sinalizadores (flags) usando a ferramenta de linha de
comando dig do DNS por conta própria.:
dig @8.8.8.8 r0.a6.nodes.lightning.directory SRV
O Grafo de Canais
Agora que nosso novo nó é capaz de usar o protocolo de inicialização DNS para se conectar ao seu
8
primeiro par, ele pode começar a sincronizar o grafo de canais! No entanto, antes de
sincronizarmos o grafo de canais, precisamos aprender exatamente o que queremos dizer com
grafo de canais. Nesta seção, exploraremos a estrutura precisa do grafo de canais e examinaremos
os aspectos únicos do grafo de canais em comparação com a estrutura de dados abstrata grafo
típica, que é bem conhecida/usada no campo da ciência da computação.
Um Grafo Direcionado
Um grafo em ciência da computação é uma estrutura de dados especial composta por vértices
(geralmente chamados de nós) e arestas (também conhecidas como conexões). Dois nós podem
estar conectados por uma ou mais arestas. O grafo de canais também é direcionado, uma vez que
um pagamento pode fluir em qualquer direção ao longo de uma aresta (um canal). Um exemplo de
grafo direcionado é mostrado em. Um grafo direcionado.
Figure 2. Um grafo direcionado
No contexto da Lightning Network, nossos vértices são os próprios nós da Lightning, sendo as
arestas os canais de pagamento que conectam esses nós. Como estamos preocupados com o
roteamento de pagamentos, em nosso modelo, um nó sem arestas (sem canais de pagamento) não é
considerado parte do grafo, pois não é útil.
Porque os canais em si são UTXOs (endereços multisig 2-de-2 financiados), podemos visualizar o
grafo de canais como um subconjunto especial do conjunto de UTXOs do Bitcoin, sobre o qual
podemos adicionar informações adicionais (os nós, etc.) para chegar à estrutura final sobreposta,
que é o grafo de canais. Ancorar componentes fundamentais do grafo de canais na base da
blockchain do Bitcoin significa que é impossível falsificar um grafo de canais válido, o que tem
propriedades úteis quando se trata de prevenção de spam, como veremos mais adiante.
Mensagens do Protocolo Gossip

As informações do grafo de canais são propagadas pela Lightning P2P Network por meio de três
mensagens, que são descritas em BOLT #7:
9
node_announcement
O vértice em nosso grafo que comunica a chave pública de um nó, bem como como alcançar o
nó pela internet e alguns metadados adicionais que descrevem o conjunto de recursos que o nó
suporta.
channel_announcement
Uma prova ancorada na blockchain da existência de um canal entre dois nós individuais.
Qualquer terceiro pode verificar essa prova para garantir que um canal real esteja realmente
sendo anunciado. Semelhante ao node_announcement, esta mensagem também contém
informações que descrevem as capacidades do canal, o que é útil ao tentar rotear um
pagamento.
channel_update
Um par de estruturas que descreve o conjunto de políticas de roteamento para um determinado
canal. As mensagens channel_update vêm em um pair porque um canal é uma borda
direcionada, então cada lado do canal é capaz de especificar sua própria política de roteamento
personalizada.
É importante destacar que cada componente do grafo de canais é autenticado, permitindo que uma
terceira parte verifique se o proprietário de um canal/atualização/nó é realmente aquele que está
enviando uma atualização. Isso efetivamente torna o grafo de canais um tipo único de estrutura de
dados autenticada que não pode ser falsificada. Para autenticação, usamos uma assinatura digital
ECDSA secp256k1 (ou uma série delas) sobre o resumo serializado da própria mensagem. Neste
capítulo, não entraremos nos detalhes específicos da estruturação/serialização de mensagens
usadas na Lightning Network, pois cobriremos essas informações no [wire_protocol].
Com a estrutura de alto nível do grafo de canais delineada, agora iremos nos aprofundar na
estrutura precisa de cada uma das três mensagens usadas para divulgar (to gossip) o grafo de
canais. Também explicaremos como é possível verificar cada mensagem e componente do grafo de
canais.
A Mensagem node_announcement
Primeiro, temos a mensagem node_announcement, que serve a dois propósitos primários:
1. Para anunciar informações de conexão para que outros nós possam se conectar a um nó, seja
para inicializar na rede ou para tentar estabelecer um novo canal de pagamento com esse nó.
2. Para comunicar o conjunto de recursos (capacidades) de nível de protocolo que um nó

entende/suporta. A negociação de recursos entre nós permite que os desenvolvedores
adicionem novos recursos de forma independente e os suportem com qualquer outro nó de
forma opcional.
Ao contrário dos anúncios de canal, os anúncios de nó não são ancorados na base da blockchain.
Portanto, os anúncios de nós são apenas considerados válidos se tiverem propagado com um
anúncio de canal correspondente. Em outras palavras, sempre rejeitamos nós sem canais de
pagamento para garantir que um par malicioso não possa inundar a rede com nós falsos que não
fazem parte do grafo do canal.
10
A estrutura da mensagem node_announcement
A node_announcement é composta pelos seguintes campos:
signature
Uma assinatura ECDSA válida que abrange o resumo serializado de todos os campos listados
abaixo. Essa assinatura deve corresponder à chave pública do nó anunciado.
features
Um vetor de bits que descreve o conjunto de características de protocolo que este nó entende.
Abordaremos este campo com mais detalhes no [feature_bits] sobre a extensibilidade do
protocolo Lightning. Em um nível mais alto, esse campo contém um conjunto de bits que
representam os recursos que um nó entende. Como exemplo, um nó pode indicar que entende o
tipo de canal mais recente.
timestamp
Um carimbo de data e hora codificado em formato Unix epoch. Isso permite que os clientes
executem uma ordenação parcial nas atualizações do anúncio de um nó.
node_id
A chave pública secp256k1 a que este anúncio de nó pertence. Pode haver apenas um único
node_announcement para um determinado nó no grafo de canais em um determinado
momento. Como resultado, um node_announcement pode substituir um node_announcement
anterior para o mesmo nó se tiver um carimbo de data e hora mais alto (mais recente).
rgb_color
Um campo que permite que um nó especifique uma cor RGB para ser associada a ele,
frequentemente usado em visualizações de grafos de canais e diretórios de nós.
alias
Uma sequência UTF-8 para servir como apelido de um determinado nó. Observe que esses
apelidos não precisam ser globalmente únicos, nem são verificados de nenhuma forma.
Portanto, eles não devem ser considerados como uma forma de identidade—pois podem ser
facilmente falsificados.
addresses
Um conjunto de endereços públicos alcançáveis pela internet que estão associados a um
determinado nó. Na versão atual do protocolo, quatro tipos de endereço são suportados: IPv4
(tipo: 1), IPv6 (tipo: 2), Tor v2 (tipo: 3) e Tor v3 (tipo: 4). Na mensagem node_announcement, cada
um desses tipos de endereço é representado por um tipo inteiro que é incluído entre parênteses
após o tipo de endereço.
Validando anúncios de nó
Validar um node_announcement recebido é simples. As seguintes assertivas devem ser mantidas ao

examinar um anúncio de nó:
• Se um node_announcement existente para esse nó já for conhecido, então o campo timestamp

de um novo node_announcement recebido deve ser maior que o anterior.
11
• Com essa restrição, impomos um nível forçado de "atualidade"
• Se nenhum node_announcement existir para o nó fornecido, então um channel_announcement

existente que faça referência a determinado nó (mais sobre isso depois) já deve existir no grafo
de canais local.
• A assinatura incluída deve ser uma assinatura ECDSA válida verificada usando a chave pública
node_id incluída e o resumo duplo-SHA-256 da codificação da mensagem bruta (sem a
assinatura e o cabeçalho do quadro) como a mensagem.
• Todos os endereços incluídos devem ser classificados em ordem crescente com base em seu
identificador de endereço.
• Os bytes incluídos em alias devem ser uma sequência válida UTF-8.
A Mensagem channel_announcement
Em seguida, temos a mensagem channel_announcement, que é usada para anunciar um novo canal
público para a rede em geral. Observe que anunciar um canal é opcional. Um canal só precisa ser
anunciado se for destinado a ser usado para roteamento pela Lightning Network. Nós de
roteamento ativos podem optar por anunciar todos os seus canais. No entanto, certos nós, como nós
móveis, provavelmente não têm a disponibilidade ou o desejo de serem nós de roteamento ativos.
Como resultado, esses nós móveis (que normalmente usam clientes leves para se conectar à rede
P2P do Bitcoin) podem ter apenas canais não anunciados (privados).
======= Canais não anunciados (privados)
Um canal não anunciado não faz parte do conhecido grafo público de canais, mas ainda pode ser
usado para enviar/receber pagamentos. Um leitor atento pode estar se perguntando como um canal
que não faz parte do grafo de canais público consegue receber pagamentos. A solução para esse
problema é um conjunto de "assistentes de busca de caminho" que chamamos de dicas de
roteamento.. Como veremos no [invoices], faturas criadas por nós com canais não anunciados
incluirão informações para ajudar o remetente a rotear para eles, desde que o nó tenha pelo menos
um único canal com um nó de roteamento público existente.
Devido à existência de canais não anunciados, o tamanho real do grafo de canais (tanto os
componentes públicos quanto privados) é desconhecido.
Localizando um canal na blockchain do bitcoin
Como mencionado anteriormente, o grafo de canais é autenticado devido ao uso de criptografia de

chave pública, bem como a blockchain do Bitcoin como um sistema de prevenção de spam. Para
que um nó aceite um novo channel_announcement, o anúncio deve provar que o canal realmente
existe na blockchain do Bitcoin. Esse sistema de prova adiciona um custo inicial para adicionar
uma nova entrada ao grafo de canais (as taxas on-chain que devem ser pagas para criar a UTXO do
canal). Como resultado, mitigamos o spam e garantimos que um nó desonesto na rede não possa
preencher a memória de um nó honesto sem custo com canais falsos.
Dado que precisamos construir uma prova da existência de um canal, uma pergunta natural que
surge é: como "apontar a" ou referenciar um determinado canal para o verificador? Dado que um
canal de pagamento está ancorado em uma saída de transação não gasta (veja [utxo]), um
12
pensamento inicial pode ser tentar anunciar o outpoint completo (txid:index) do canal. Dado que o
outpoint é globalmente único e confirmado na cadeia, isso parece ser uma boa ideia; no entanto,
isso tem uma desvantagem: o verificador deve manter uma cópia completa do conjunto de UTXOs
para verificar os canais. Isso funciona bem para nós completos do Bitcoin, mas clientes que
dependem de verificação leve geralmente não mantêm um conjunto completo de UTXOs. Como
queremos garantir que possamos suportar nós móveis na Lightning Network, somos forçados a
encontrar outra solução.
E se, em vez de referenciar um canal pelo seu UTXO, o referenciássemos com base em sua
"localização" na cadeia? Para fazer isso, precisamos de um esquema que nos permita referenciar
um determinado bloco, em seguida, uma transação dentro desse bloco e, finalmente, uma saída
específica criada por essa transação. Um identificador desse tipo é descrito em BOLT #7 e é
conhecido como um short channel ID, ou scid. O scid é usado no channel_announcement (e no
channel_update), bem como no pacote de roteamento criptografado por cebola incluído nos HTLCs,
como aprendemos no [onion_routing].
O ID curto do canal
Com base nas informações anteriores, temos três informações que precisamos codificar para
referenciar de forma única um determinado canal. Como queremos uma representação compacta,
vamos tentar codificar as informações em um único número inteiro. Nosso formato de inteiro
escolhido é um inteiro de 64 bits unsigned composto por 8 bytes.
Primeiro, a altura do bloco. Usando 3 bytes (24 bits), podemos codificar 16.777.216 blocos. Isso deixa
5 bytes para codificar, respectivamente, o índice da transação e o índice da saída. Vamos usar os
próximos 3 bytes para codificar o índice da transação dentro de um bloco. Isso é mais do que
suficiente, dado que é possível ter apenas dezenas de milhares de transações em um bloco com os
tamanhos de bloco atuais. Isso deixa 2 bytes para codificar o índice da saída do canal dentro da
transação.
Nosso formato scid final se assemelha a:
block_height (3 bytes) || transaction_index (3 bytes) || output_index (2 bytes)
Usando técnicas de compactação de bits, primeiro codificamos os 3 bytes mais significativos como a
altura do bloco, os próximos 3 bytes como o índice da transação e os 2 bytes menos significativos
como o índice da saída que cria a UTXO do canal.
Um ID curto de canal pode ser representado como um único número inteiro (695313561322258433)
ou como uma sequência mais amigável para humanos: 632384x1568x1. Aqui vemos que o canal foi
minerado no bloco 632384, foi a 1568 transação no bloco, e a saída do canal é a segunda (as UTXOs
são indexadas a partir de zero) saída produzida pela transação.
Agora que somos capazes de apontar de forma sucinta para uma determinada saída de
financiamento de canal na cadeia, podemos examinar a estrutura completa da mensagem
channel_announcement, bem como ver como verificar a prova de existência incluída na
mensagem.
13
A estrutura da mensagem channel_announcement
Um channel_announcement comunica principalmente duas coisas:
1. Uma prova de que existe um canal entre o nó A e o nó B, com ambos os nós controlando as
chaves de multisig naquela saída de canal.
2. O conjunto de capacidades do canal (quais tipos de HTLCs ele pode rotear, etc.).
Ao descrever a prova, geralmente nos referimos ao nó 1 e ao nó 2. Dos dois nós conectados por um
canal, o "primeiro" nó é aquele que possui uma codificação de chave pública "menor" quando
comparamos as chaves públicas dos dois nós em formato comprimido hex codificado na ordem
lexicográfica. Correspondentemente, além de uma chave pública do nó na rede, cada nó também
deve controlar uma chave pública dentro da blockchain do Bitcoin.
Semelhante à mensagem node_announcement, todas as assinaturas incluídas na mensagem

channel_announcement devem ser assinadas/verificadas em relação à codificação bruta da
mensagem (sem o cabeçalho) que segue após a assinatura final (porque não é possível para uma
assinatura digital assinar a si mesma).
Dito isso, uma mensagem channel_announcement possui os seguintes campos:
node_signature_1
A assinatura do primeiro nó no resumo da mensagem.
node_signature_2
A assinatura do segundo nó sobre o resumo da mensagem.
bitcoin_signature_1
A assinatura da chave multisig (na saída de financiamento) do primeiro nó sobre o resumo da
mensagem.
bitcoin_signature_2
A assinatura da chave multisig (na saída de financiamento) do segundo nó sobre o resumo da
mensagem.
features
Um vetor de bit de recurso que descreve o conjunto de recursos de nível de protocolo
suportados por este canal.
chain_hash
Um hash de 32 bytes que normalmente é o hash do bloco de gênese da blockchain (por exemplo,
rede principal do Bitcoin) na qual o canal foi aberto.
short_channel_id
O scid que localiza exclusivamente a saída de financiamento do canal dentro da blockchain.
node_id_1
A chave pública do primeiro nó na rede.
14
node_id_2
A chave pública do segundo nó na rede.
bitcoin_key_1
A chave multisig bruta para a saída de financiamento do canal para o primeiro nó na rede.
bitcoin_key_2
A chave multisig bruta para a saída de financiamento do canal para o segundo nó na rede.
Validação do anúncio do canal
Agora que sabemos o que um channel_announcement contém, podemos ver como verificar a
existência do canal on-chain.
Armado com as informações no channel_announcement, qualquer nó do Lightning (mesmo aquele

sem uma cópia completa da blockchain do Bitcoin) pode verificar a existência e autenticidade do
canal de pagamento.
Primeiro, o verificador usará o ID curto de canal (short channel ID) para encontrar qual bloco do
Bitcoin contém a saída de financiamento do canal. Com as informações da altura do bloco, o
verificador pode solicitar apenas esse bloco específico de um nó do Bitcoin. O bloco pode então ser
vinculado de volta ao bloco de gênese seguindo a cadeia de cabeçalhos de bloco para trás
(verificando a prova de trabalho), confirmando que este é de fato um bloco pertencente ao
Em seguida, o verificador usa o número de índice da transação para identificar o ID da transação

que contém o canal de pagamento. A maioria das bibliotecas modernas do Bitcoin permite indexar
a transação de um bloco com base no índice da transação dentro do bloco maior.
Em seguida, o verificador usa uma biblioteca do Bitcoin (na linguagem do verificador) para extrair
a transação relevante de acordo com seu índice dentro do bloco. O verificador irá validar a
transação (verificando se ela está devidamente assinada e produz o mesmo ID de transação quando
hasheada).
Em seguida, o verificador irá extrair a saída Pay-to-Witness-Script-Hash (P2WSH) referenciada pelo

número de índice de saída do ID curto de canal. Este é o endereço da saída de financiamento do
canal. Além disso, o verificador irá garantir que o tamanho do canal alegado corresponda ao valor
da saída produzida no índice de saída especificado.
Por fim, o verificador irá reconstruir o script multisig a partir de bitcoin_key_1 e bitcoin_key_2 e
confirmar que ele produz o mesmo endereço quanto na saída.
O verificador agora verificou independentemente que o canal de pagamento no anúncio está

financiado e confirmado no blockchain do Bitcoin!
A Mensagem channel_update
A terceira e última mensagem usada no protocolo de gossip é a mensagem channel_update. Duas

dessas mensagens são geradas para cada canal de pagamento (uma por cada parceiro do canal)
anunciando suas taxas de roteamento, expectativas de tempo de bloqueio e capacidades.
15
A mensagem channel_update também contém um carimbo de data e hora, permitindo que um nó
atualize suas taxas de roteamento e outras expectativas e capacidades ao enviar uma nova
mensagem channel_update com um carimbo de data e hora mais recente que substitui quaisquer
atualizações mais antigas.
A mensagem channel_update contém os seguintes campos:
signature
Uma assinatura digital correspondente à chave pública do nó, para autenticar a fonte e a
integridade da atualização do canal
chain_hash
O hash do bloco de gênese da cadeia que contém o canal
short_channel_id
O ID curto do canal para identificar o canal
timestamp
O carimbo de data e hora desta atualização, para permitir que os destinatários sequenciem as
atualizações e substituam as atualizações mais antigas
message_flags
Um campo de bit indicando a presença de campos adicionais na mensagem channel_update
channel_flags
Um campo de bit mostrando a direção do canal e outras opções de canal
cltv_expiry_delta
A expectativa delta de bloqueio de tempo (timelock) deste nó para o roteamento (veja
[onion_routing])
htlc_minimum_msat
A quantidade mínima de HTLC que será roteada
fee_base_msat
A taxa básica que será cobrada pelo roteamento
fee_proportional_millionths
A taxa de tarifa proporcional que será cobrada pelo roteamento
htlc_maximum_msat (option_channel_htlc_max)
O valor máximo que será roteado.
Um nó que recebe a mensagem channel_update pode anexar esses metadados à aresta do grafo de
canais para permitir a busca de caminho (pathfinding), como veremos no [path_finding].
16
Manutenção Contínua do Grafo de Canais
A construção de um grafo de canais não é um evento único, mas sim uma atividade contínua.
Conforme um nó é iniciado na rede, ele começará a receber "gossip" na forma das três mensagens
de atualização. Ele usará essas mensagens para imediatamente começar a construir um grafo de
canais validado.
Quanto mais informações um nó recebe, melhor se torna seu "mapa" da Lightning Network e mais
eficiente ele pode ser em encontrar caminhos e entregar pagamentos.
Um nó não apenas adiciona informações ao grafo de canais, mas também acompanha a última vez
em que um canal foi atualizado e exclui canais "antigos" que não foram atualizados há mais de
duas semanas. Além disso, se um nó perceber que outro nó não possui mais canais, ele também o
removerá do grafo.
As informações coletadas pelo protocolo de gossip não são as únicas informações que podem ser
armazenadas no grafo do canal. Diferentes implementações de nós Relâmpago podem adicionar
outros metadados aos nós e canais. Por exemplo, algumas implementações de nós calculam uma
"pontuação" que avalia a "qualidade" de um nó como um par de roteamento. Essa pontuação é
usada como parte do processo de busca de caminho para priorizar ou despriorizar rotas.
Conclusão
Neste capítulo, aprendemos como os nós Relâmpago descobrem uns aos outros, descobrem e
atualizam o status de seus nós, e se comunicam entre si. Aprendemos como os grafos de canais são
criados e mantidos, e exploramos algumas maneiras pelas quais a Rede Relâmpago desencoraja
atores mal-intencionados ou nós desonestos de enviar spam na rede.
17
Busca de Caminho e Entrega de Pagamento
Entregade pagamentos na Rede Relâmpago depende de encontrar um caminho do remetente ao
destinatário, um processo chamado de pathfinding (busca de caminho). Como o roteamento é feito
pelo remetente, ele precisa encontrar um caminho adequado para alcançar o destino. Esse caminho
é então codificado em uma cebola, como vimos no [onion_routing].
Neste capítulo, examinaremos o problema do pathfinding, entenderemos como a incerteza sobre os

saldos dos canais complica esse problema e veremos como uma implementação típica de busca de
caminho tenta resolvê-lo.
Busca de Caminho no Conjunto de Protocolos

Lightning
Busca de caminho, seleção de caminho, pagamentos multiparte (MPP), e o loop de tentativa e erro
de pagamento ocupam a maior parte da camada de pagamento no topo do conjunto de protocolos.
Esses componentes são destacados por um esboço no conjunto de protocolos, mostrado na Entrega
de pagamento no conjunto de protocolos Lightning.
Figure 1. Entrega de pagamento no conjunto de protocolos Lightning
Onde Está o BOLT?
Até agora, analisamos várias tecnologias que fazem parte da Lightning Network e vimos suas
especificações exatas como parte de um padrão BOLT. Você pode ficar surpreso ao descobrir que a
busca de caminho (pathfinding) não faz parte dos BOLTs!
Isso ocorre porque o pathfinding não é uma atividade que requer qualquer forma de coordenação
ou interoperabilidade entre diferentes implementações. Como vimos, o caminho é selecionado pelo
1
remetente. Embora os detalhes do roteamento sejam especificados detalhadamente nos BOLTs, a
descoberta e seleção do caminho são deixadas inteiramente a critério do remetente. Assim, cada
implementação de nó pode escolher uma estratégia/algoritmo diferente para encontrar caminhos.
Na verdade, as diferentes implementações de nó/cliente e carteira podem até competir e usar seu
algoritmo de pathfinding como um ponto de diferenciação.
Busca de Caminho: Que Problema Estamos

Resolvendo?
O termo "pathfinding" pode ser um pouco enganador, pois implica em buscar um único caminho
conectando dois nós. No início, quando a Lightning Network era pequena e não estava bem
interconectada, o problema era de fato encontrar um meio de conectar canais de pagamento para
chegar ao destinatário.
Porém, à medida que a Lightning Network cresceu de forma explosiva, a natureza do problema de
pathfinding mudou. Em meados de -2021, ao terminarmos este livro, a Lightning Network consiste
em 20.000 nós conectados por pelo menos 55.000 canais públicos, com uma capacidade agregada de
quase 2.000 BTC. Um nó possui, em média, 8,8 canais, enquanto os 10 nós mais conectados possuem
entre 400 e 2.000 canais cada. Uma visualização de apenas um pequeno subconjunto do grafo de
canais da LN é mostrada na Uma visualização de parte da Rede Relâmpago em julho de 2021.
Figure 2. Uma visualização de parte da Rede Relâmpago em julho de 2021
A visualização da rede na Uma visualização de parte da Rede Relâmpago em julho de 2021 foi
produzida com um simples script em Python que você pode encontrar em code/lngraph no
repositório do livro.
Se o remetente e o destinatário estiverem conectados a outros nós bem conectados e tiverem pelo
2
menos um canal com capacidade adequada, haverá milhares de caminhos possíveis. O problema
passa a ser selecionar o melhor caminho que garantirá a entrega do pagamento, dentre uma lista de
milhares de caminhos possíveis.
Selecionando o Melhor Caminho
Para selecionar o melhor caminho, primeiro precisamos definir o que queremos dizer com
"melhor". Pode haver diferentes critérios a serem considerados, tais como:
• Caminhos com liquidez suficiente. Obviamente, se um caminho não tem liquidez suficiente para
rotear nosso pagamento, então não é um caminho adequado.
• Caminhos com taxas baixas. Se tivermos vários candidatos, podemos selecionar aqueles com
taxas mais baixas.
• Caminhos com timelocks curtos. Podemos evitar bloquear nossos fundos por muito tempo e,
portanto, selecionar caminhos com bloqueios de tempo mais curtos.
Todos esses critérios podem ser desejáveis em certa medida, e selecionar caminhos que sejam
favoráveis em várias dimensões não é uma tarefa fácil. Problemas de otimização como esse podem
ser complexos demais para resolver a solução "ideal", mas geralmente podem ser resolvidos
aproximadamente para uma solução próxima do ótimo. Isso é uma boa notícia, pois, caso contrário,
o processo de seleção de caminhos seria um problema intratável.
Pathfinding em Matemática e Ciência da Computação
Pathfinding na Rede Relâmpago se enquadra na categoria geral de teoria dos grafos (graph theory)
em matemática e na categoria mais específica de travessia de grafos (graph traversal) na ciência da
computação.
Uma rede como a Lightning Network pode ser representada como uma construção matemática
chamada grafo, onde os nós são conectados uns aos outros por arestas (equivalentes aos canais de
pagamento).A Lightning Network forma um grafo direcionado, pois os nós estão ligados de forma
assimétrica, uma vez que o saldo do canal é dividido entre os dois parceiros do canal e a liquidez do
pagamento é diferente em cada direção.Um grafo direcionado com restrições de capacidade
numérica em suas arestas é chamado de rede de fluxo (flow network), um conceito matemático
utilizado para otimizar redes de transporte e outros tipos de redes semelhantes. Redes de fluxo
podem ser utilizadas como estruturas quando as soluções precisam alcançar um fluxo específico
enquanto minimizam o custo, conhecido como o problema do custo mínimo do fluxo (minimum
cost flow problem - MCFP).
Capacidade, Saldo, Liquidez
Para entender melhor o problema de transportar satoshis do ponto A para o ponto B, precisamos
definir melhor três termos importantes: capacidade, saldo e liquidez. Utilizamos esses termos para
descrever a capacidade de um canal de pagamento para encaminhar um pagamento.
Em um canal de pagamento conectando A←→B:
3
Capacidade
Essa é a quantidade total de satoshis que foram financiados na multisig 2-de-2 com a transação
de financiamento. Isso representa o valor máximo mantido no canal. A capacidade do canal é
anunciada pelo protocolo de gossip (protocolo de fofoca) e é conhecida pelos nós.
Saldo
Essa é a quantidade de satoshis mantidos por cada parceiro do canal que podem ser enviados ao
outro parceiro do canal. Um subconjunto do saldo de A pode ser enviado na direção (A→B) em
direção ao nó B. Um subconjunto do saldo de B pode ser enviado na direção oposta (A←B).
Liquidez
O saldo disponível (subconjunto) que pode ser efetivamente enviada pelo canal em uma direção.
A liquidez de A é igual ao saldo de A menos a reserva do canal e quaisquer HTLCs pendentes
comprometidos por A.
O único valor conhecido pela rede (por meio de anúncios de gossip) é a capacidade agregada do
canal. Uma porção desconhecida dessa capacidade é distribuída como o saldo de cada parceiro. Um
subconjunto desse saldo está disponível para ser enviado pelo canal em uma direção:
<li>capacity = balance(A) + balance(B)</li>
<li>liquidity(A) = balance(A) – channel_reserve(A) – pending_HTLCs(A)</li>
</ul>
Incerteza dos Saldos
Se soubéssemos os saldos exatos de cada canal, poderíamos calcular um ou mais caminhos de

pagamento usando quaisquer dos algoritmos de busca de caminho padrão ensinados em bons
programas de ciência da computação. Mas não conhecemos os saldos dos canais; só conhecemos a
capacidade agregada do canal, que é anunciada pelos nós nos anúncios de canal. Para que um
pagamento seja bem-sucedido, deve haver saldo adequado no lado de envio do canal. Se não
soubermos como a capacidade está distribuída entre os parceiros do canal, não saberemos se há
saldo suficiente na direção em que estamos tentando enviar o pagamento.
Os saldos não são anunciados nas atualizações de canal por duas razões: privacidade e
escalabilidade. Em primeiro lugar, anunciar saldos reduziria a privacidade da Lightning Network,
pois permitiria a vigilância de pagamentos por meio da análise estatística das mudanças nos saldos.
Em segundo lugar, se os nós anunciassem saldos (globalmente) a cada pagamento, a escalabilidade
da Lightning Network seria tão ruim quanto a das transações de Bitcoin na corrente de blocos, que
são transmitidas a todos os participantes. Portanto, os saldos não são anunciados. Para resolver o
problema de busca de caminho diante da incerteza dos saldos, precisamos de estratégias
inovadoras de busca de caminho. Essas estratégias devem estar intimamente relacionadas ao
algoritmo de roteamento usado, que é o roteamento em camadas baseado na origem (source-based
onion routing), onde é responsabilidade do remetente encontrar um caminho pela rede.
O problema da incerteza pode ser descrito matematicamente como um intervalo de liquidez,

indicando os limites inferiores e superiores da liquidez com base nas informações conhecidas. Uma
vez que conhecemos a capacidade do canal e conhecemos o saldo de reserva do canal (o saldo
mínimo permitido em cada extremidade), a liquidez pode ser definida como:
4
<li>min(liquidity) = channel_reserve</li>
<li>max(liquidity) = capacity – channel_reserve</li>
</ul>
ou como um intervalo:
<li>channel_reserve <= liquidity <= (capacity – channel_reserve)</li>
</ul>
Nossa faixa de incerteza de liquidez do canal é a faixa entre a liquidez mínima e máxima possível.
Isso é desconhecido para a rede, exceto pelos dois parceiros do canal. No entanto, como veremos,
podemos usar as falhas de HTLC retornadas de nossas tentativas de pagamento para atualizar
nossa estimativa de liquidez e reduzir a incerteza. Se, por exemplo, recebermos um código de falha
de HTLC que nos informa que um canal não pode cumprir um HTLC que é menor do que nossa
estimativa para a liquidez máxima, isso significa que a liquidez máxima pode ser atualizada para o
valor do HTLC que falhou. Em termos mais simples, se acreditamos que a liquidez pode lidar com
um HTLC de N satoshis e descobrimos que ele falha em entregar M satoshis (onde M é menor),
então podemos atualizar nossa estimativa para M-1 como limite superior. Tentamos encontrar o
teto e nos deparamos com ele, então ele é menor do que pensávamos!
Complexidade da Busca de Caminho
Encontrar um caminho através de um grafo é um problema que os computadores modernos podem

resolver de forma bastante eficiente. Os desenvolvedores geralmente escolhem a busca em largura
(breadth-first search) se as arestas têm pesos iguais. Em casos em que as arestas não têm pesos
iguais, um algoritmo baseado no algoritmo deDijkstra’s é usado, como em A* (pronounced "A-star").
No nosso caso, os pesos das arestas podem representar as taxas de roteamento. Somente arestas
com capacidade maior que a quantidade a ser enviada serão incluídas na pesquisa. Nesta forma
básica, o pathfinding na Rede Relâmpago é muito simples e direto.
No entanto, a liquidez do canal é desconhecida para o remetente. Isso transforma nosso problema
fácil de ciência da computação teórica em um problema real bastante complexo. Agora temos que
resolver um problema de descoberta de caminhos com conhecimento apenas parcial. Por exemplo,
suspeitamos quais arestas podem encaminhar um pagamento porque sua capacidade parece ser
grande o suficiente. Mas não podemos ter certeza a menos que tentemos ou perguntemos
diretamente aos proprietários do canal. Mesmo que pudéssemos perguntar diretamente aos
proprietários do canal, o saldo deles pode mudar no momento em que perguntamos a outros,
calculamos um caminho, construímos uma camada de cebola (onion) e a enviamos. Não apenas
temos informações limitadas, mas essas informações são altamente dinâmicas e podem mudar a
qualquer momento sem o nosso conhecimento.
Simplificando
O mecanismo de busca de caminhos implementado nos nós Lightning é primeiro criar uma lista de
caminhos candidatos, filtrados e ordenados por alguma função. Em seguida, o nó ou carteira
sondará os caminhos (tentando entregar um pagamento) em um loop de tentativa e erro até
encontrar um caminho que entregue o pagamento com sucesso.
5
Essa sondagem é feita pelo nó ou carteira do Lightning e não é observada diretamente pelo
usuário do software. No entanto, o usuário pode suspeitar que a sondagem está ocorrendo se o
pagamento não for concluído instantaneamente.
Embora a sondagem cega não seja ótima e deixe espaço para melhorias, deve-se notar que essa
estratégia simplista funciona surpreendentemente bem para pagamentos menores e nós bem
conectados.
A maioria das implementações de nós e carteiras Lightning melhora essa abordagem ao

ordenar/ponderar a lista de caminhos candidatos. Algumas implementações ordenam os caminhos
candidatos por custo (taxas) ou alguma combinação de custo e capacidade.
Busca de Caminho e Processo de Entrega de

Pagamento
A busca de caminhos e a entrega de pagamentos envolvem várias etapas, que listamos aqui.
Diferentes implementações podem usar algoritmos e estratégias diferentes, mas as etapas básicas
provavelmente serão muito semelhantes:
1. Criar um grafo de canais a partir de anúncios e atualizações contendo a capacidade de cada

canal, e filtrar o grafo, ignorando quaisquer canais com capacidade insuficiente para o valor
que desejamos enviar.
2. Encontrar caminhos conectando o remetente ao destinatário.
3. Ordenar os caminhos por algum peso (isto pode ser uma parte do algoritmo anterior).
4. Tentar cada caminho na ordem até que o pagamento seja bem-sucedido (o loop de tentativa e
erro).
5. Opcionalmente, utilizar os retornos de falha do HTLC para atualizar o nosso grafo, reduzindo a
incerteza.
Podemos agrupar essas etapas em três atividades principais:
• Construção do grafo do canal
• Pathfinding, ou busca de caminho (filtrado e ordenado por algumas heurísticas)
• Tentativa(s) de pagamento
Essas três atividades podem ser repetidas em uma rodada de pagamento se usarmos os retornos de
falha para atualizar o gráfico, ou se estivermos realizando pagamentos multipartes (veja
Pagamentos Multipartes).
Nas próximas seções, examinaremos cada uma dessas etapas com mais detalhes, assim como
estratégias de pagamento mais avançadas.
6
Construção do Grafo do Canal
No [gossip] nós cobrimos as três principais mensagens que os nós usam em sua disseminação
(gossip): node_announcement, channel_announcement e channel_update. Essas três mensagens
permitem que qualquer nó construa gradualmente um "mapa" da Lightning Network na forma de
um grafo de canais. Cada uma dessas mensagens fornece uma peça crítica de informação para o
grafo de canais:
node_announcement
Essa mensagem contém informações sobre um nó na rede Lightning, como seu ID do nó (chave
pública), endereço de rede (por exemplo, IPv4/6 ou Tor), capacidades/recursos, etc.
channel_announcement
Esta mensagem contém a capacidade e o ID de canal de uma canal público (anunciado) entre
dois nós, bem como uma prova da existência e propriedade do canal.
channel_update
Esta mensagem contém as expectativas de taxa e bloqueio temporal (CLTV) de um nó para rotear
um pagamento de saída (do ponto de vista desse nó) por meio de um canal específico.
Em termos de um grafo matemático, o node_announcement fornece as informações necessárias

para criar os nós ou vértices do grafo. O channel_announcement nos permite criar as arestas do
grafo representando os canais de pagamento. Como cada direção do canal de pagamento possui seu
próprio saldo, criamos um grafo direcionado. O channel_update nos permite incorporar taxas e
bloqueios temporais para definir o custo ou peso das arestas do grafo.
Dependendo do algoritmo que vamos usar para busca de caminhos, podemos estabelecer várias
funções de custo diferentes para as arestas do grafo.
Por enquanto, vamos ignorar a função de custo e simplesmente estabelecer um grafo de canais
mostrando nós e canais, usando as mensagens node_announcement e channel_announcement.
Neste capítulo, veremos como Selena tenta encontrar um caminho para pagar a Rashid um milhão
de satoshis. Para começar, Selena está construindo um grafo de canais usando as informações da
disseminação (gossip) da Lightning Network para descobrir nós e canais. Em seguida, Selena
explorará seu grafo de canais para encontrar um caminho para enviar um pagamento a Rashid.
Este é o grafo de canais de Selena. Não existe algo como o grafo de canais, existe apenas sempre um
grafo de canais, e ele é sempre da perspectiva do nó que o construiu. (see A Relação Mapa-
Território).
Selena não constrói um grafo de canais apenas ao enviar um pagamento. Na verdade, o nó de

Selena está continuamente construindo e atualizando um grafo de canais. Desde o momento
em que o nó de Selena inicia e se conecta a qualquer par na rede, ele participará da
disseminação de informações gossip e usará cada mensagem para aprender o máximo possível
sobre a rede.
7
A Relação Mapa-Território
From Wikipedia’s page on the Map-Territory Relation, "A relação mapa-território descreve a
relação entre um objeto e sua representação, como a relação entre um território geográfico e
um mapa dele."
A relação mapa-território é melhor ilustrada em "Sylvie and Bruno Concluded", um conto de

Lewis Carroll que descreve um mapa fictício que possui uma escala 1:1 em relação ao
território mapeado, portanto, tendo uma precisão perfeita, mas se tornando completamente
inútil, pois cobriria todo o território se fosse desdobrado.
O que isso significa para a Lightning Network? A Lightning Network é o território, e um grafo
de canais é um mapa desse território.
Embora possamos imaginar um grafo de canais teórico (ideal Platônico) que represente o
mapa completo e atualizado da Lightning Network, tal mapa é simplesmente a própria
Lightning Network. Cada nó possui seu próprio grafo de canais, que é construído a partir de
anúncios e é necessariamente incompleto, incorreto e desatualizado!
O mapa nunca pode descrever completamente e com precisão o território.
Selena ouve as mensagens node_announcement e descobre outros quatro nós (além de Rashid, o
destinatário pretendido). O grafo resultante representa uma rede de seis nós: Selena e Rashid são o
remetente e o destinatário, respectivamente; Alice, Bob, Xavier e Yan são nós intermediários. O
grafo inicial de Selena é apenas uma lista de nós, mostrada na Anúncios de nós.
Figure 3. Anúncios de nós
Selena também recebe sete mensagens channel_announcement com as capacidades de canal

correspondentes, permitindo que ela construa um "mapa" básico da rede, mostrado na O grafo de
canais. (Os nomes Alice, Bob, Selena, Xavier, Yan e Rashid foram substituídos por suas iniciais: A, B,
S, X e R, respectivamente.)
8
Figure 4. O grafo de canais
Incerteza no grafo do canais
Como você pode ver na O grafo de canais, Selena não conhece os saldos dos canais. Seu grafo de
canais inicial contém o mais alto nível de incerteza.
Mas espere: Selena conhece alguns saldos de canais! Ela conhece os saldos dos canais aos quais o
próprio nó dela está conectado com outros nós. Embora isso possa parecer pouco, é, na verdade,
uma informação muito importante para a construção de um caminho - Selena conhece a liquidez
real de seus próprios canais. Vamos atualizar o grafo de canais para mostrar essa informação.
Usaremos o símbolo "?" para representar os saldos desconhecidos, conforme mostrado na Grafo de
canais com saldos conhecidos e desconhecidos.
Figure 5. Grafo de canais com saldos conhecidos e desconhecidos
Embora o símbolo "?" possa parecer ameaçador, a falta de certeza não é o mesmo que ignorância
completa. Podemos quantificar a incerteza e reduzi-la atualizando o grafo com os HTLCs bem-
sucedidos/fracassados que tentamos.
A incerteza pode ser quantificada, pois conhecemos a liquidez máxima e mínima possível e
podemos calcular probabilidades para faixas menores (mais precisas).
Uma vez que tentamos enviar um HTLC, podemos aprender mais sobre os saldos dos canais: se
9
tivermos sucesso, significa que o saldo foi pelo menos suficiente para transportar a quantia
específica. Enquanto isso, se recebermos um erro de "falha temporária do canal" (temporary
channel failure), a razão mais provável é a falta de liquidez para a quantia específica.
Você pode estar pensando: "Qual é o objetivo de aprender com um HTLC bem-sucedido?"
Afinal, se tivermos sucesso, estamos "prontos". Mas considere que podemos estar enviando
uma parte de um pagamento multipartes. Também podemos estar enviando outros
pagamentos únicos em um curto período de tempo. Qualquer informação que aprendemos
sobre a liquidez é útil para a próxima tentativa!
Incerteza e Probabilidade de Liquidez
Para quantificar a incerteza da liquidez de um canal, podemos aplicar a teoria das probabilidades.
Um modelo básico da probabilidade de entrega do pagamento levará a algumas conclusões óbvias,
mas importantes:
• Pagamentos menores têm mais chances de entrega bem-sucedida em um caminho
• Canais de maior capacidade nos darão uma melhor chance de entrega de pagamento por um
valor específico.
• Quanto mais canais (saltos), menor a chance de sucesso.
Embora essas conclusões possam ser óbvias, elas têm implicações importantes, especialmente para
o uso de pagamentos multipartes. (see Pagamentos Multipartes). A matemática não é difícil de
acompanhar.
Vamos usar a teoria da probabilidade para ver como chegamos a essas conclusões.
Primeiro, vamos supor que um canal com capacidade c tenha liquidez em um dos lados com um
valor desconhecido no intervalo de (0, c) ou "intervalo entre 0 e c". Por exemplo, se a capacidade for
5, então a liquidez estará no intervalo (0, 5). Agora, a partir disso, podemos observar que se
quisermos enviar 5 satoshis, nossa chance de sucesso é apenas 1 em 6 (16,66%), porque só teremos
sucesso se a liquidez for exatamente 5.
De forma mais simples, se os valores possíveis para a liquidez forem 0, 1, 2, 3, 4 e 5, apenas um

desses seis valores possíveis será suficiente para enviar nosso pagamento. Para continuar com este
exemplo, se o valor do nosso pagamento fosse 3, teríamos sucesso se a liquidez fosse 3, 4 ou 5.
Portanto, nossas chances de sucesso são de 3 em 6 (50%). Expressa em termos matemáticos, a
função de probabilidade de sucesso para um único canal é:
$P_c(a) = (c + 1 - a) / (c + 1)$
onde a é a quantidade e c é a capacidade.
A partir da equação, podemos observar que se o valor estiver próximo de 0, a probabilidade será
próxima de 1, enquanto se o valor exceder a capacidade, a probabilidade será zero.
10
Em outras palavras: "Pagamentos menores têm uma melhor chance de serem entregues com
sucesso" ou "Canais com capacidade maior nos dão melhores chances de entrega para um valor
específico" e "Você não pode enviar um pagamento por um canal com capacidade insuficiente."
Agora vamos pensar na probabilidade de sucesso ao longo de um caminho composto por vários
canais. Vamos supor que nosso primeiro canal tenha uma chance de sucesso de 50% (P = 0,5). Em
seguida, se nosso segundo canal também tiver uma chance de sucesso de 50% (P = 0,5), é intuitivo
que nossa chance geral seja de 25% (P = 0,25).
Podemos expressar isso como uma equação que calcula a probabilidade de sucesso de um
pagamento como o produto das probabilidades de cada canal no(s) caminho(s):
$P_{payment} = \prod_{i=1}^n P_i$
Onde Pi é a probabilidade de sucesso em um caminho ou canal, e Ppayment é a probabilidade geral de

um pagamento bem-sucedido por todos os caminhos/canais.
A partir da equação, podemos observar que, como a probabilidade de sucesso em um único canal é
sempre menor ou igual a 1, a probabilidade ao longo de vários canais irá cair exponencialmente.
Em outras palavras, "Quanto mais canais (saltos) você utilizar, menor será a chance de sucesso."
Há muita teoria matemática e modelagem por trás da incerteza da liquidez nos canais.
Trabalhos fundamentais sobre modelagem dos intervalos de incerteza da liquidez dos canais
podem ser encontrados no artigo "Security and Privacy of Lightning Network Payments with
Uncertain Channel Balances" pelo coautor deste livro Pickhardt et al.
Taxas e Outras Métricas de Canal
A seguir, nosso remetente adicionará informações ao grafo a partir das mensagens channel_update
recebidas dos nós intermediários. Como lembrete, a mensagem channel_update contém uma
riqueza de informações sobre um canal e as expectativas de um dos parceiros do canal.
Na Taxas de grafo de canal e outras métricas de canal vemos como Selena pode atualizar o grafo de
canais com base nas mensagens channel_update de A, B, X e Y. Observe que o ID do canal e a
direção do canal (incluída em channel_flags) informam a Selena a qual canal e qual direção essa
atualização se refere. Cada parceiro do canal dissemina uma ou mais mensagens channel_update
para anunciar suas expectativas de taxa e outras informações sobre o canal. Por exemplo, no canto
superior esquerdo, vemos a mensagem channel_update enviada por Alice para o canal A-B e a
direção de A para B. Com essa atualização, Alice informa à rede quanto ela cobrará em taxas para
rotear um HTLC para Bob por esse canal específico. Bob pode anunciar uma atualização do canal
(não mostrada neste diagrama) para a direção oposta com expectativas de taxa completamente
diferentes. Qualquer nó pode enviar uma nova mensagem channel_update para alterar as taxas ou
expectativas de timelock a qualquer momento.
11
Figure 6. Taxas de grafo de canal e outras métricas de canal
As informações sobre taxas e timelocks são muito importantes, não apenas como métricas de
seleção de caminho. Como vimos no [onion_routing], o remetente precisa somar as taxas e os
timelocks (cltv_expiry_delta) em cada salto para criar a cebola. O processo de cálculo das taxas
ocorre do destinatário para o remetente, em sentido contrário, ao longo do caminho, pois cada salto
intermediário espera um HTLC de entrada com valor e timelock de expiração maiores do que o
HTLC de saída que eles enviarão para o próximo salto. Portanto, por exemplo, se Bob deseja 1.000
satoshis em taxas e 30 blocos de atraso de expiração para enviar um pagamento para Rashid, esse
valor e delta do atraso de expiração devem ser adicionados ao HTLC de Alice.
Também é importante destacar que um canal deve ter liquidez suficiente não apenas para o valor
do pagamento, mas também para as taxas acumuladas de todos os saltos subsequentes. Mesmo que
o canal de Selena para Xavier (S→X) tenha liquidez suficiente para um pagamento de 1 milhão de
satoshis, ele não possui liquidez suficiente quando consideramos as taxas. Precisamos saber as
taxas porque apenas os caminhos que possuem liquidez suficiente para tanto o pagamento quanto
todas as taxas serão considerados..
12
Encontrando Caminhos Candidatos
Encontrar um caminho adequado através de um grafo direcionado como este é um problema de
ciência da computação bem estudado (conhecido amplamente como o problema do caminho mais
curto), que pode ser resolvido por uma variedade de algoritmos, dependendo da otimização
desejada e das restrições de recursos.
O algoritmo mais famoso para resolver esse problema foi inventado pelo matemático holandês E.
W. Dijkstra em 1956, conhecido simplesmente como o algoritmo de Dijkstra Dijkstra’s algorithm.
Além do algoritmo original de Dijkstra, existem muitas variações e otimizações, como A* ("A-star"),
que é um algoritmo baseado em heurísticas.
Como mencionado anteriormente, a "busca" deve ser aplicada em sentido contrário para levar em
conta as taxas acumuladas do destinatário ao remetente. Assim, o algoritmo de Dijkstra, A* ou
algum outro algoritmo poderia buscar um caminho do destinatário ao remetente, utilizando as
taxas, a liquidez estimada e o delta de timelock (ou alguma combinação) como função de custo para
cada salto.
Usando um desses algoritmos, Selena calcula vários caminhos possíveis para Rashid, classificados
pelo caminho mais curto:
1. S→A→B→R
2. S→X→Y→R
3. S→X→B→R
4. S→A→B→X→Y→R
Mas, como vimos anteriormente, o canal S→X não tem liquidez suficiente para um pagamento de 1
milhão de satoshis quando as taxas são consideradas. Portanto, os Caminhos 2 e 3 não são viáveis.
Isso deixa os Caminhos 1 e 4 como possíveis caminhos para o pagamento.
Com dois caminhos possíveis, Selena está pronta para tentar efetuar o pagamento!
Entrega de Pagamento (Loop de Tentativa e Erro)

O nóde Selena inicia o loop de tentativa e erro construindo os HTLCs, montando a cebola e tentando
efetuar o pagamento. Para cada tentativa, existem três resultados possíveis:
• Um resultado bem-sucedido (update_fulfill_htlc)
• Um erro (update_fail_htlc)
• Um pagamento "travado" sem resposta (nem sucesso nem falha)
Se o pagamento falhar, ele pode ser refeito por meio de um caminho diferente atualizando o grafo
(alterando as métricas de um canal) e recalculando um caminho alternativo.
Nós analisamos o que acontece se o pagamento ficar "travado" em[stuck_payments]. O detalhe

importante é que um pagamento preso é o pior resultado, porque não podemos tentar novamente
com outro HTLC, uma vez que tanto o pagamento preso quanto a tentativa de repetição podem
13
eventualmente ser concluídos e causar um pagamento duplicado.
Primeira Tentativa (Caminho #1)
Selena tenta o primeiro caminho (S→A→B→R). Ela constrói a cebola e a envia, mas recebe um
código de falha do nó de Bob. Bob relata um temporary channel failure com um channel_update
identificando o canal B→R como o que não pode entregar. Essa tentativa é mostrada na A tentativa
do Caminho #1 falha.
Figure 7. A tentativa do Caminho #1 falha
======= Aprendendo com o fracasso
A partir desse código de falha, Selena deduzirá que Bob não possui liquidez suficiente para
entregar o pagamento a Rashid naquele canal. Importante destacar que essa falha reduz a
incerteza da liquidez daquele canal! Anteriormente, o nó de Selena assumia que a liquidez no lado
de Bob do canal estava em algum lugar na faixa de (0, 4 milhões). Agora, ela pode assumir que a
liquidez está na faixa de (0, 999999). Da mesma forma, Selena agora pode assumir que a liquidez
daquele canal no lado de Rashid está na faixa de (1 milhão, 4 milhões), em vez de (0, 4 milhões).
Selena aprendeu muito com essa falha.
Segunda Tentativa (Caminho #4)
Agora, Selena tenta o quarto caminho candidato (S→A→B→X→Y→R). Este é um caminho mais
longo e incorrerá em mais taxas, mas agora é a melhor opção para a entrega do pagamento.
Felizmente, Selena recebe uma mensagem update_fulfill_htlc de Alice, indicando que o pagamento
foi bem-sucedido, como mostrado na A tentativa do Caminho #4 foi bem-sucedida.
14
Figure 8. A tentativa do Caminho #4 foi bem-sucedida
Aprendendo com o sucesso
Selena também aprendeu muito com esse pagamento bem-sucedido. Agora ela sabe que todos os
canais no caminho S→A→B→X→Y→R tinham liquidez suficiente para entregar o pagamento. Além
disso, ela agora sabe que cada um desses canais moveu o valor do HTLC (1M + taxas) para o outro
lado do canal. Isso permite que Selena recalcule a faixa de liquidez no lado receptor de todos os
canais nesse caminho, substituindo a liquidez mínima por 1M + taxas.
======= Conhecimento obsoleto?
Selena agora possui um "mapa" muito melhor da Lightning Network (pelo menos no que diz
respeito a esses sete canais). Esse conhecimento será útil para quaisquer pagamentos subsequentes
que Selena tente fazer.
No entanto, esse conhecimento se torna desatualizado à medida que os outros nós enviam ou
roteiam pagamentos. Selena nunca verá nenhum desses pagamentos (a menos que ela seja a
remetente). Mesmo que ela esteja envolvida no roteamento de pagamentos, o mecanismo de
roteamento em cebola significa que ela só pode ver as mudanças para um salto (seus próprios
canais).
Portanto, o nó de Selena deve considerar por quanto tempo manter esse conhecimento antes de
assumir que ele está desatualizado e não mais útil.
Pagamentos Multipartes
Os pagamentos multipartes (MPP) são um recurso que foi introduzido na Lightning Network em
2020 e já estão amplamente disponíveis. Os pagamentos multipartes permitem que um pagamento
seja dividido em várias partes, que são enviadas como HTLCs por vários caminhos diferentes até o
destinatário pretendido, preservando a atomicidade do pagamento geral. Nesse contexto,
atomicidade significa que ou todas as partes HTLC de um pagamento são eventualmente cumpridas
ou o pagamento inteiro falha e todas as partes HTLC também falham. Não há possibilidade de um
pagamento parcialmente bem-sucedido.
Os pagamentos multipartes representam uma melhoria significativa na Lightning Network, pois
15
tornam possível enviar quantias que não "caberiam" em um único canal, dividindo-as em quantias
menores para as quais há liquidez suficiente. Além disso, os pagamentos multipartes
demonstraram aumentar a probabilidade de um pagamento bem-sucedido, em comparação com
um pagamento em um único caminho.
Agora que o MPP está disponível, é melhor considerar um pagamento em um único caminho
como uma subcategoria de um MPP. Essencialmente, um único caminho é apenas um
multipart de tamanho um. Todos os pagamentos podem ser considerados como pagamentos
multipartes, a menos que o tamanho do pagamento e a liquidez disponível tornem possível a
entrega com uma única parte.
Usando MPP
MPP não é algo que um usuário selecionará, mas sim uma estratégia de busca de caminho e entrega
de pagamento em um nó. Os mesmos passos básicos são implementados: criar um grafo, selecionar
caminhos e executar o loop de tentativa e erro. A diferença é que durante a seleção de caminho
também devemos considerar como dividir o pagamento para otimizar a entrega.
Em nosso exemplo, podemos observar algumas melhorias imediatas em nosso problema de busca
de caminho que se tornam possíveis com o MPP. Primeiro, podemos utilizar o canal S→X, que tem
uma liquidez conhecida insuficiente para transportar 1 milhão de satoshis mais taxas. Ao enviar
uma parte menor ao longo desse canal, podemos usar caminhos que anteriormente não estavam
disponíveis. Segundo, temos a liquidez desconhecida do canal B→R, que é insuficiente para
transportar o valor de 1 milhão, mas pode ser suficiente para transportar uma quantia menor.
Dividindo pagamentos
A pergunta fundamental é como dividir os pagamentos. Mais especificamente, qual é o número

ideal de divisões e as quantias ideais para cada divisão?
Essa é uma área de pesquisa em andamento, onde surgem estratégias inovadoras. Pagamentos
multipartes levam a uma abordagem algorítmica diferente dos pagamentos em um único caminho,
mesmo que soluções de caminho único possam surgir a partir de uma otimização multipartes (ou
seja, um único caminho pode ser a solução ideal sugerida por um algoritmo de busca de caminho
multipartes).
Se você se lembra, descobrimos que a incerteza da liquidez/saldos leva a algumas conclusões (um
tanto óbvias) que podemos aplicar na busca de caminhos MPP, nomeadamente:
• Pagamentos menores têm uma chance maior de sucesso.
• Quanto mais canais você usar, a chance de sucesso se torna (exponencialmente) menor.
A partir do primeiro desses insights, podemos concluir que dividir um pagamento grande (por
exemplo, 1 milhão de satoshis) em pagamentos menores aumenta a chance de que cada um desses
pagamentos menores tenha sucesso. O número de caminhos possíveis com liquidez suficiente será
maior se enviarmos quantidades menores.
Para levar essa ideia ao extremo, por que não dividir o pagamento de 1 milhão de satoshis em um
16
milhão de partes separadas de um satoshi cada? Bem, a resposta está no nosso segundo insight:
como estaríamos usando mais canais/caminhos para enviar nossos milhões de HTLCs de um único
satoshi, nossa chance de sucesso diminuiria exponencialmente.
Se não for óbvio, os dois insights anteriores criam um ponto ideal onde podemos maximizar nossas
chances de sucesso: dividir em pagamentos menores, mas não com muitas divisões!
Quantificar esse equilíbrio ideal de tamanho/número de divisões para um determinado grafo de

canais está além do escopo deste livro, mas é uma área de pesquisa ativa. Algumas implementações
atuais utilizam uma estratégia muito simples de dividir o pagamento em duas metades, quatro
quartos, etc.
Para saber mais sobre o problema de otimização conhecido como fluxos de custo mínimo
envolvidos ao dividir pagamentos em diferentes tamanhos e alocá-los em caminhos, consulte o
artigo "Optimally Reliable & Cheap Payment Flows on the Lightning Network" pelo coautor
deste livro René Pickhardt and Stefan Richter.
Em nosso exemplo, o nó de Selena tentará dividir o pagamento de 1 milhão de satoshis em 2 partes,

com 600 mil e 400 mil satoshis, respectivamente, e enviá-los por dois caminhos diferentes. Isso é
mostrado em Enviando duas partes de um pagamento multipartes.
Devido ao fato de que agora o canal S→X pode ser utilizado e (felizmente para Selena) o canal B→R
tem liquidez suficiente para 600 mil satoshis, as 2 partes são bem-sucedidas ao longo de caminhos
que anteriormente não eram possíveis.
Figure 9. Enviando duas partes de um pagamento multipartes
Tentativa e Erro em Várias Rodadas
Pagamentos multipartes levam a um loop de tentativa e erro ligeiramente modificado para a

entrega do pagamento. Como estamos tentando vários caminhos em cada tentativa, temos quatro
possíveis resultados:
17
• Todas as partes foram bem-sucedidas, o pagamento foi bem-sucedido
• Algumas partes são bem-sucedidas, outras falham com erros retornados
• Todas as partes falham com erros retornados
• Algumas partes estão travadas, não há retorno de erros
No segundo caso, onde algumas partes falham com erros retornados e outras partes têm sucesso,
agora podemos repetir o loop de tentativa e erro, mas apenas para o valor residual.
Vamos supor, por exemplo, que Selena tinha um grafo de canais muito maior com centenas de
caminhos possíveis para chegar a Rashid. Seu algoritmo de busca de caminhos pode encontrar uma
divisão de pagamento ótima consistindo em 26 partes de tamanhos variados. Após tentar enviar
todas as 26 partes na primeira rodada, 3 dessas partes falharam com erros.
Se essas 3 partes consistissem, por exemplo, em 155 mil satoshis, então Selena reiniciaria o esforço
de busca de caminhos, apenas para os 155 mil satoshis. A próxima rodada poderia encontrar
caminhos completamente diferentes (otimizados para o valor residual de 155 mil) e dividir o valor
de 155 mil em divisões completamente diferentes!
Embora pareça que 26 partes divididas sejam muitas, testes na Lightning Network
conseguiram entregar com sucesso um pagamento de 0,3679 BTC dividindo-o em 345 partes.
Além disso, o nó de Selena atualizaria o grafo de canais usando as informações obtidas a partir dos
sucessos e erros da primeira rodada para encontrar os caminhos e divisões mais otimizados para a
segunda rodada.
Vamos supor que o nó de Selena calcule que a melhor maneira de enviar os 155 mil satoshis
restantes seja dividindo-os em 6 partes: 80 mil, 42 mil, 15 mil, 11 mil, 6.5 mil e 500 satoshis. Na
próxima rodada, Selena recebe apenas um erro, indicando que a parte de 11 mil satoshis falhou.
Novamente, Selena atualiza o grafo de canais com base nas informações obtidas e executa a busca
de caminhos novamente para enviar os 11 mil satoshis restantes. Desta vez, ela tem sucesso com 2
partes de 6 mil e 5 mil satoshis, respectivamente.
Este exemplo de envio de pagamento em várias rodadas usando MPP é mostrado na Enviando um
pagamento em várias rodadas com MPP.
18
Figure 10. Enviando um pagamento em várias rodadas com MPP
No final, o nó de Selena usou 3 rodadas de busca de caminhos para enviar os 1 milhão de satoshis
em 30 partes.
Conclusão
Neste capítulo, exploramos a busca de caminhos e a entrega de pagamentos. Vimos como usar o
grafo de canais para encontrar caminhos do remetente ao destinatário. Também vimos como o
remetente tentará entregar pagamentos em um caminho candidato e repetirá em um loop de
tentativa e erro.
Também examinamos a incerteza da liquidez do canal (do ponto de vista do remetente) e as

implicações que isso tem para a busca de caminhos. Vimos como podemos quantificar a incerteza e
usar a teoria das probabilidades para obter algumas conclusões úteis. Também vimos como
podemos reduzir a incerteza aprendendo com pagamentos bem-sucedidos e fracassados.
Por fim, vimos como o recurso de pagamentos multipartes recém-implementado nos permite
dividir os pagamentos em partes, aumentando a probabilidade de sucesso mesmo para pagamentos
maiores.
19
Protocolo Wire: Estrutura e Extensibilidade
Neste capítulo, mergulhamos no protocolo wire da Rede Relâmpago e também cobrimos todas as
várias alavancas de extensibilidade que foram incorporadas no protocolo. No final deste capítulo,
um leitor ambicioso deve ser capaz de escrever seu próprio analisador (parser) de protocolo wire
para a Rede Relâmpago. Além de ser capaz de escrever um analisador de protocolo wire
personalizado, um leitor deste capítulo obterá uma compreensão profunda dos vários mecanismos
de atualização que foram incorporados ao protocolo.
Camada de Mensagens no Conjunto de Protocolos

Lightning
A camada de mensagens, detalhada neste capítulo, consiste em "Estrutura e formato de mensagem",
codificação "Type-Length-Value" e "Feature bits". Esses componentes são destacados por um
esquema no conjunto de protocolos, conforme mostrado na Camada de mensagens no conjunto de
protocolos Lightning.
Figure 1. Camada de mensagens no conjunto de protocolos Lightning
Estruturando o Wire
Começamos descrevendo a estrutura de alto nível da estruturação do wire dentro do protocolo.
Quando dizemos estruturação, queremos dizer a maneira como os bytes são empacotados no wire
para codificar uma mensagem de protocolo específica. Sem conhecimento do sistema de
estruturação usado no protocolo, uma sequência de bytes no wire seria semelhante a uma série de
bytes aleatórios porque nenhuma estrutura foi imposta. Aplicando estruturação adequada para
decodificar esses bytes no wire, poderemos extrair estrutura e, finalmente, analisar essa estrutura
em mensagens de protocolo em nossa linguagem de alto nível.
É importante observar que a Lightning Network é um protocolo _criptografado_de_ponta_a_ponta,
1
e a estruturação do wire em si está encapsulada dentro de uma camada de transporte de
mensagens também criptografada. Como vemos no [encrypted_message_transport], a Rede
Relãmpago utiliza uma variante personalizada do Protocolo Noise para lidar com a criptografia do
transporte. Dentro deste capítulo, sempre que fornecermos um exemplo de estrutura da
comunicação, assumimos que a camada de criptografia já foi removida (ao decodificar) ou que
ainda não criptografamos o conjunto de bytes antes de enviá-los pelo wire (codificação).
Estruturação Wire de Alto Nível
Com isso dito, estamos prontos para descrever o esquema de alto nível usado para codificar
mensagens no wire:
• As mensagens no wire começam com um campo do tipo 2 bytes, seguido por uma carga útil da
mensagem (message payload).
• A própria carga útil da mensagem pode ter até 65 KB de tamanho.
• Todos os números inteiros são codificados em big-endian (ordem de rede).
• Quaisquer bytes que seguem após uma mensagem definida podem ser ignorados com
segurança.
Sim, isso mesmo. Como o protocolo depende de uma camada de criptografia encapsulante no
protocolo de transporte, não precisamos de um comprimento explícito para cada tipo de
mensagem. Isso ocorre porque a criptografia do transporte funciona no nível da mensagem,
portanto, quando estamos prontos para decodificar a próxima mensagem, já sabemos o número
total de bytes da própria mensagem. Usando 2 bytes para o tipo de mensagem (codificado em big-
endian), significa que o protocolo pode ter até 2^16 - 1 ou 65.535 mensagens distintas. Além disso,
como sabemos que todas as mensagens devem ter menos de 65 KB, isso simplifica nosso processo
de análise, pois podemos usar um buffer de tamanho fixo e manter limites estritos na quantidade
total de memória necessária para analisar uma mensagem wire recebida.
O último ponto permite um grau de compatibilidade retroativa (backward) porque os novos nós
podem fornecer informações nas mensagens de comunicação que os nós mais antigos (que podem
não entendê-las) podem ignorar com segurança. Conforme veremos posteriormente, essa
característica, combinada com um formato de extensibilidade de mensagem wire muito flexível,
permite que o protocolo alcance compatibilidade progressiva (forward) também.
Codificação de Tipo
Com esse contexto de alto nível fornecido, agora começamos pela camada mais primitiva: a análise
(parsing) dos tipos primitivos. Além de codificar números inteiros, o Protocolo Lightning também
permite a codificação de uma ampla variedade de tipos, incluindo fatias de bytes de comprimento
variável, chaves públicas de curva elíptica, endereços Bitcoin e assinaturas. Quando descrevemos a
estrutura das mensagens wire posteriormente neste capítulo, nos referimos ao tipo de alto nível (o
tipo abstrato) em vez da representação de nível inferior desse tipo. Nesta seção, removemos essa
camada de abstração para garantir que nosso futuro analisador (parser) de wire seja capaz de
codificar/decodificar corretamente qualquer um dos tipos de alto nível.
Na Tipos de mensagens de alto nível, mapeamos o nome de um determinado tipo de mensagem

para a rotina de alto nível usada para codificar/decodificar o tipo.
2
Table 1. Tipos de mensagens de alto nível
Tipo de alto nível Estrutura Comentário

node_alias Uma sequência de bytes de Ao decodificar, rejeitar se o
comprimento fixo de 32 bytes conteúdo não for uma string
UTF-8 válida
channel_id Uma sequência de bytes de Dado um ponto de saída
comprimento fixo de 32 bytes (outpoint), é possível convertê-
que mapeia um ponto de saída lo para um channel_id ao pegar
para um valor de 32 bytes o TxID do ponto de saída e
realizar uma operação XOR com
o índice (interpretado como os
2 bytes inferiores).
short_chan_id Um inteiro não assinado de 64 Composto pela altura do bloco
bits (uint64) (24 bits), índice da transação (24
bits) e índice de saída (16 bits),
empacotados em 8 bytes
milli_satoshi Um número inteiro não Representa a milésima (1000th)
assinado de 64 bits (uint64) parte de um satoshi
satoshi Um número inteiro não A unidade básica do bitcoin
assinado de 64 bits (uint64)
pubkey Uma chave pública secp256k1 Ocupa um comprimento fixo de
codificada no formato 33 bytes no wire
comprimido, ocupando 33 bytes
sig Uma assinatura ECDSA da curva Codificada como uma sequência
elíptica secp256k1 de bytes de comprimento fixo
de 64 bytes, empacotada como R
|| S
uint8 Um inteiro de 8 bits
[]byte Uma sequência de bytes de Prefixado com um inteiro de 16
comprimento variável bits que indica o comprimento
dos bytes
color_rgb Codificação de cores RGB Codificado como uma série de
inteiros de 8 bits
net_addr A codificação de um endereço Codificado com um prefixo de 1
de rede byte que indica o tipo de
endereço, seguido pelo
conteúdo do endereço
Na próxima seção, descrevemos a estrutura de cada mensagem wire, incluindo o tipo de prefixo da
mensagem junto com o conteúdo do corpo da mensagem.
3
Extensões de Mensagens Tipo-Comprimento-Valor
(Type-Length-Value)
Anteriormente neste capítulo, mencionamos que as mensagens podem ter um tamanho de até 65
KB e que, se durante a análise (parsing) de uma mensagem, sobrarem bytes extra, então esses bytes
devem ser ignorados. À primeira vista, esse requisito pode parecer arbitrário; no entanto, essa
exigência permite a evolução desacoplada e dessincronizada do próprio Protocolo Relâmpago.
Discutiremos isso com mais detalhes no final do capítulo. Mas antes, vamos direcionar nossa
atenção para exatamente para que esses "bytes extras" no final de uma mensagem podem ser
usados.
O Formato de Mensagem Protocolo Buffers
O formato de serialização de mensagens Protocol Buffers (Protobuf) começou como um formato

interno usado no Google e se tornou um dos formatos de serialização de mensagens mais populares
utilizados globalmente pelos desenvolvedores. O formato Protobuf descreve como uma mensagem
(geralmente uma estrutura de dados relacionada a uma API) é codificada no wire e decodificada na
outra ponta. Existem vários "compiladores Protobuf" disponíveis em dezenas de linguagens, que
atuam como uma ponte que permite que qualquer linguagem codifique um Protobuf que possa ser
decodificado por um decodificador compatível em outra linguagem. Essa compatibilidade de
estrutura de dados entre linguagens diferentes permite uma ampla gama de inovações, pois é
possível transmitir estruturas e até mesmo estruturas de dados com tipos através de fronteiras de
linguagem e abstração.
Protobufs também são conhecidos por sua flexibilidade em lidar com mudanças na estrutura das
mensagens subjacentes. Contanto que o esquema de numeração dos campos seja seguido, é possível
que uma versão mais recente de Protobufs inclua informações dentro de um Protobuf que podem
ser desconhecidas para qualquer leitor mais antigo. Quando o leitor antigo encontra o novo
formato serializado, se houver tipos/campos que ele não entenda, ele simplesmente os ignora. Isso
permite que clientes antigos e novos coexistam, pois todos os clientes podem analisar (parse) uma
parte do formato de mensagem mais recente.
Compatibilidade Progressiva e Retroativa
Os Protobufs são extremamente populares entre desenvolvedores porque possuem suporte

integrado tanto para compatibilidade progressiva quanto retroativa. A maioria das pessoas
desenvolvedoras está provavelmente familiarizada com o conceito de compatibilidade retroativa.
Em termos simples, o princípio afirma que quaisquer alterações no formato de mensagem ou API
devem ser feitas de uma maneira que não quebre o suporte para clientes mais antigos. Nos
exemplos anteriores de extensibilidade do Protobuf, a compatibilidade retroativa é alcançada
garantindo que as novas adições ao formato Protobuf não afetem as partes conhecidas pelos
leitores mais antigos. Já a compatibilidade progressiva, por outro lado, é tão importante para
atualizações dessincronizadas, mas é menos conhecida. Para que uma alteração seja compatível
progressivamente, os clientes devem simplesmente ignorar qualquer informação que não
entendam. O mecanismo de soft fork para atualizar o sistema de consenso do Bitcoin pode ser
considerado tanto compatível progressiva quanto retroativamente: quaisquer clientes que não são
atualizados ainda podem usar o Bitcoin e, se encontrarem quaisquer transações que não entendam,
4
simplesmente as ignoram, pois seus fundos não estão usando esses novos recursos.
Formato Tipo-Comprimento-Valor (Type-Length-Value,

TLV)
Para ser capaz de atualizar as mensagens de forma compatível progressiva e retroativamente, além
dos bits de recurso (mais sobre isso posteriormente), a Lightning Network utiliza um formato de
serialização de mensagens personalizado chamado Tipo-Comprimento-Valor (Type-Length-Value,
ou TLV). O formato foi inspirado no amplamente utilizado formato Protobuf e incorpora muitos
conceitos, simplificando significativamente a implementação e o software que interage com a
análise de mensagens. Um leitor curioso pode perguntar: "por que não usar apenas Protobufs?" Em
resposta, as pessoas desenvolvedoras da Lightning responderiam que conseguimos obter a melhor
extensibilidade dos Protobufs, ao mesmo tempo em que nos beneficiamos de uma implementação
menor e, portanto, menor risco de ataques. Na versão 3.15.6, o compilador Protobuf tem mais de
656.671 linhas de código. Em comparação, a implementação do formato de mensagem TLV do LND
possui apenas 2,3 mil linhas de código (incluindo testes).
Com o contexto necessário apresentado, agora estamos prontos para descrever o formato TLV em
detalhes. Uma extensão de mensagem TLV é uma sequência de registros TLV individuais. Um único
registro TLV possui três componentes: o tipo do registro, o comprimento do registro e, por fim, o
valor opaco do registro:
type
Um inteiro que representa o nome do registro sendo codificado
length
O comprimento do registro
value
O valor opaco do registro
Tanto o type quanto o length são codificados usando um inteiro de tamanho variável inspirado no
inteiro de tamanho variável (varint) usado no protocolo P2P do Bitcoin, chamado de BigSize para
simplificar.
Codificação de Inteiro BigSize
IEm sua forma mais completa, um inteiro BigSize pode representar valores de até 64 bits. Ao
contrário do formato varint do Bitcoin, o formato BigSize em vez disso codifica os inteiros usando
uma ordem de bytes big-endian.
O varint BigSize possui dois componentes: o discriminante e o corpo. No contexto do inteiro BigSize
, o discriminante comunica ao decodificador o tamanho do inteiro de tamanho variável que o
segue. Lembre-se de que o aspecto único dos inteiros de tamanho variável é que eles permitem que
um analisador (parser) use menos bytes para codificar inteiros menores do que maiores,
economizando espaço. A codificação de um inteiro BigSize segue uma das quatro opções a seguir:
1. Se o valor for menor que 0xfd (253): Nesse caso, o discriminante não é realmente usado, e a
5
codificação é simplesmente o próprio inteiro. Isso nos permite codificar números muito
pequenos sem qualquer sobrecarga adicional.
2. Se o valor for menor ou igual a 0xffff (65535): O discriminante é codificado como 0xfd, o que
indica que o valor que segue é maior que 0xfd, mas menor que 0xffff. O número é então
codificado como um inteiro de 16 bits. Incluindo o discriminante, podemos codificar um valor
maior que 253, mas menor que 65.535 usando 3 bytes.
3. Se o valor for menor que 0xffffffff (4294967295): O discriminante é codificado como 0xfe. O
corpo é codificado usando um inteiro de 32 bits, incluindo o discriminante, e podemos codificar
um valor menor que 4.294.967.295 usando 5 bytes.
4. Caso contrário, apenas codificamos o valor como um inteiro de 64 bits em tamanho real
(completo).
Restrições de Codificação TLV
Dentro do contexto de uma mensagem TLV, os tipos de registro abaixo de 2^16 são considerados
reservados para uso futuro. Tipos além dessa faixa devem ser usados para extensões de mensagem
"personalizadas" usadas por protocolos de aplicação de nível mais alto.
O value (valor) de um registro depende do type (tipo). Em outras palavras, ele pode ter qualquer
formato, pois os analisadores (parsers) tentarão interpretá-lo com base no contexto do próprio tipo.
Codificação Canônica TLV
Um problema com o formato Protobuf é que a codificação da mesma mensagem pode gerar um
conjunto completamente diferente de bytes quando codificada por duas versões diferentes do
compilador. Essas instâncias de codificação não canônica não são aceitáveis no contexto da
Lightning, pois muitas mensagens contêm uma assinatura do resumo da mensagem. Se for possível
que uma mensagem seja codificada de duas maneiras diferentes, seria possível quebrar
inadvertidamente a autenticação de uma assinatura ao recodificar uma mensagem usando um
conjunto ligeiramente diferente de bytes no wire.
Para garantir que todas as mensagens codificadas sejam canônicas, as seguintes restrições são
definidas durante a codificação:
• Todos os registros dentro de uma sequência TLV devem ser codificados em ordem de tipo
estritamente crescente.
• Todos os registros devem codificar pelo menos os campos type e length. Em outras palavras, a
menor representação BigSize para um inteiro deve ser usada em todos os momentos.
• Cada type só pode aparecer uma vez em uma determinada sequência TLV.
Além dessas restrições de codificação, uma série de requisitos de interpretação em um nível mais
alto também é definida com base na aridade (número de argumentos) de um determinado inteiro
type. Aprofundaremos esses detalhes mais adiante no capítulo, quando descrevermos como o
Protocolo Lightning é atualizado na prática e na teoria.
6
Feature Bits e Extensibilidade do Protocolo
Devido à natureza descentralizada da Rede Relâmpago, nenhuma entidade única pode impor uma
mudança ou modificação de protocolo a todos os usuários do sistema. Essa característica também é
observada em outras redes descentralizadas, como o Bitcoin. No entanto, ao contrário do Bitcoin,
não é necessário uma amplo consenso para mudar um subconjunto da Lightning Network. A Rede
Relâmpago é capaz de evoluir livremente sem uma forte exigência de coordenação, pois, ao
contrário do Bitcoin, não é necessário um consenso global na Rede Relâmpago. Devido a esse fato e
aos diversos mecanismos de atualização incorporados na Rede Relâmpago, apenas os participantes
que desejam usar esses novos recursos da Rede Relâmpago precisam fazer a atualização, e então
eles podem interagir entre si.
Nesta seção, exploramos as várias maneiras pelas quais as pessoas desenvolvedoras e usuárias
podem projetar e implantar novos recursos na Rede Relâmpago. Os criadores da Lightning Network
original sabiam que havia muitas direções possíveis para a rede e o protocolo subjacente. Como
resultado, eles se certificaram de implementar vários mecanismos de extensibilidade dentro do
sistema, que podem ser usados para atualizá-lo parcial ou totalmente de forma desacoplada,
dessincronizada e descentralizada.
Feature Bits como um Mecanismo de Descoberta de Atualização
Um leitor atento pode ter percebido as várias localizações em que os feature bits são incluídos no
Protocolo Lightning. Um feature bit é um campo de bits que pode ser usado para anunciar o
entendimento ou a adesão a uma possível atualização do protocolo de rede. Os feature bits são
comumente atribuídos em pares, o que significa que cada novo recurso ou atualização potencial
sempre define dois bits dentro do campo de bits. Um dos bits sinaliza que o recurso anunciado é
opcional, o que significa que o nó tem conhecimento sobre o recurso (feature) e pode usá-lo, mas
não o considera necessário para a operação normal. O outro bit sinaliza que o recurso é obrigatório,
o que significa que o nó não continuará a operação se um potencial par não entender esse recurso.
Usando esses dois bits (opcional e obrigatório), podemos construir uma matriz de compatibilidade
simples que os nós/usuários podem consultar para determinar se um par é compatível com um
recurso desejado, conforme mostrado na Matriz de compatibilidade de feature bit.
Table 2. Matriz de compatibilidade de feature bit
Tipo de bit Remoto opcional Remoto obrigatório Remoto desconhecido
Local opcional ✅ ✅ ✅
Local obrigatório ✅ ✅ ❌
Local desconhecido ✅ ❌ ❌
A partir desta matriz de compatibilidade simplificada, podemos observar que, desde que a outra
parte tenha conhecimento sobre o nosso feature bit, podemos interagir com ela usando o protocolo.
Se a outra parte nem sequer souber a qual bit estamos nos referindo e eles exigirem a feature,
então não somos compatíveis com ela. Na rede, os recursos opcionais são sinalizados usando um
número ímpar de bit, enquanto os recursos obrigatórios são sinalizados usando um número par de
bit. Como exemplo, se um par sinalizar que conhece uma feature que usa o bit 15, então sabemos
que esta é uma feature opcional e podemos interagir com ele ou responder às suas mensagens
7
mesmo que não conheçamos a feature. Se eles em vez disso sinalizarem a feature usando o bit 16,
então sabemos que esta é uma feature obrigatória e não podemos interagir com ele a menos que
nosso nó também entenda essa feature.
As pessoas desenvolvedoras da Lightning criaram uma frase fácil de lembrar que codifica essa
matriz: "é aceitável ser ímpar" ("it’s OK to be odd", em inglês). Essa regra simples permite uma
variedade de interações no protocolo, pois uma simples operação de bitmask entre dois vetores de
feature bits permite que os pares determinem se determinadas interações são compatíveis ou não.
Em outras palavras, os feature bits são usados como um mecanismo de descoberta de atualização:
eles permitem facilmente que os pares entendam se são compatíveis ou não com base nos conceitos
de feature bits opcionais, obrigatórios e desconhecidos.
Feature bits são encontrados nas mensagens node_announcement, channel_announcement e init dentro
do protocolo. Como resultado, essas três mensagens podem ser usadas para sinalizar o
conhecimento e/ou compreensão das atualizações do protocolo em andamento na rede. Os feature
bits encontrados na mensagem node_announcement permitem que um par determine se suas
conexões são compatíveis ou não. Os feature bits dentro de mensagens channel_announcement
permitem que um peer determine se um determinado tipo de pagamento ou HTLC pode transitar
através de um dado peer ou não. Os feature bits dentro da mensagem init permitem que peers
entendam se eles podem manter a conexão, e também que features são negociadas durante a vida
útil de uma determinada conexão.
TLV para Compatibilidade Progressiva ou Retroativa
Como aprendemos anteriormente neste capítulo, os registros TLV podem ser usados para estender
as mensagens de maneira compatível tanto para frente (progressiva) quanto para trás (retroativa).
Com o tempo, esses registros têm sido usados para estender mensagens existentes sem quebrar o
protocolo, aproveitando a área "indefinida" (undefined) dentro de uma mensagem além do
conjunto de bytes conhecidos.
Como exemplo, o protocolo original da Lightning Network não possuía o conceito de "maior valor
de HTLC" que poderia transitar por um canal de acordo com uma política de roteamento.
Posteriormente, o campo max_htlc foi adicionado à mensagem channel_update para introduzir
gradualmente esse conceito ao longo do tempo. Pares que recebem uma channel_update que define
esse campo, mas não têm conhecimento da atualização, não são afetados pela mudança, mas têm
seus HTLCs rejeitados se estiverem além do limite. Por outro lado, pares mais recentes são capazes
de analisar (parse), verificar e utilizar o novo campo.
Aqueles familiarizados com o conceito de soft forks no Bitcoin podem notar algumas semelhanças
entre os dois mecanismos. Ao contrário dos soft forks de consenso no Bitcoin, as atualizações na
Lightning Network não requerem um consenso esmagador para serem adotadas. Em vez disso, no
mínimo, apenas dois pares dentro da rede precisam entender uma nova atualização para começar
a usá-la. Comumente, esses dois pares podem ser o destinatário e o remetente de um pagamento, ou
podem ser os parceiros de canal de um novo canal de pagamento.
Uma Taxonomia de Mecanismos de Atualização
Em vez de existir um único mecanismo de atualização amplamente utilizado na rede (como soft
forks no Bitcoin), existem vários mecanismos de atualização possíveis dentro da Lightning
8
Network. Nesta seção, enumeramos esses mecanismos de atualização e fornecemos um exemplo
real de seu uso no passado.
======= Atualizações internas da rede
Começamos com o tipo de atualização que requer a maior coordenação em nível de protocolo: as
atualizações internas da rede. Uma atualização interna da rede é caracterizada por aquela que
requer que todos os nós em um caminho de pagamento em potencial entendam o novo recurso.
Essa atualização é semelhante a qualquer atualização na internet que exige atualizações em nível
de hardware na parte central do roteamento. No contexto da Lightning Network, no entanto,
lidamos apenas com software puro, o que torna essas atualizações mais fáceis de serem
implementadas, mas ainda exigem uma coordenação muito maior do que qualquer outro
mecanismo de atualização na rede.
Um exemplo desse tipo de atualização na rede foi a introdução de uma codificação TLV para as
informações de roteamento codificadas nos pacotes de cebola (onion packets). O formato anterior
utilizava um formato de mensagem de comprimento fixo codificado manualmente para comunicar
informações como o próximo salto. Porque esse formato era fixo, isso significava que novas
atualizações em nível de protocolo não eram possíveis. A mudança para o formato TLV mais
flexível significou que, após essa atualização, qualquer tipo de feature que modificasse o tipo de
informação comunicada em cada salto poderia ser implementada conforme necessário.
Vale ressaltar que a atualização do TLV onion foi uma espécie de atualização "soft" interna da rede,
no sentido de que, se um pagamento não estivesse utilizando nenhuma feature (recurso) novo além
além dessa nova codificação de informações de roteamento, então um pagamento poderia ser
transmitido usando um conjunto misto de nós.
======= Atualizações de ponta a ponta
Para contrastar com a atualização interna da rede, nesta seção descrevemos a atualização de rede
de ponta a ponta (end-to-end). Esse mecanismo de atualização difere da atualização interna da
rede, pois requer apenas que as "pontas" do pagamento, o remetente e o destinatário, realizem a
atualização.
Esse tipo de atualização permite uma ampla variedade de inovação irrestrita dentro da rede.
Devido à natureza criptografada de cebola dos pagamentos na rede, aqueles que encaminham
HTLCs no centro da rede podem nem mesmo saber que novos recursos estão sendo utilizados.
Um exemplo de uma atualização de ponta a ponta na rede foi a implementação de pagamentos

multipartes (MPP). MPP é um recurso em nível de protocolo que permite que um único pagamento
seja dividido em várias partes ou caminhos, para serem reunidos no destinatário para liquidação. A
implementação do MPP foi acompanhada de um novo feature bit no nível do node_announcement,
que indica que o destinatário sabe como lidar com pagamentos parciais. Supondo que um
remetente e um destinatário saibam um do outro (possivelmente por meio de uma fatura BOLT
#11), eles podem usar o novo recurso sem nenhuma negociação adicional.
Outro exemplo de uma atualização de ponta a ponta são os vários tipos de pagamentos espontâneos
implementados na rede. Um tipo inicial de pagamento espontâneo chamado keysend funcionou
simplesmente inserindo a pré-imagem de um pagamento dentro da cebola criptografada. Ao
receber, o destinatário descriptografaria a pré-imagem e a usaria para liquidar o pagamento.
9
Porque o pacote inteiro é criptografado de ponta a ponta, esse tipo de pagamento era seguro, pois
nenhum dos nós intermediários é capaz de desembrulhar completamente a cebola para revelar a
pré-imagem do pagamento.
Atualizações em Nível de Construção de Canal
A última categoria ampla de atualizações são aquelas que ocorrem no nível de construção do canal,
mas que não modificam a estrutura do HTLC amplamente utilizado dentro da rede. Quando
dizemos construção do canal, nos referimos a como o canal é financiado ou criado. Como exemplo,
o tipo de canal eltoo pode ser implementado na rede usando um novo feature bit no nível de
node_announcement bem como um feature bit no nível de channel_announcement. Apenas os dois pares
de nós nos lados dos canais precisam entender e anunciar esses novos recursos (features). Esse par
de canais pode então ser usado para encaminhar qualquer tipo de pagamento, desde que o canal o
suporte.
Outro exemplo é o formato de canal de anchor outputs (saídas de âncora), que permite que a taxa
de comprometimento seja ajustada por meio do mecanismo de gerenciamento de taxas Child-Pays-
For-Parent (CPFP) do Bitcoin..
Conclusão
O protocolo de comunicação (wire protocol) da Lightning é incrivelmente flexível e permite
inovação rápida e interoperabilidade sem um consenso estrito. É uma das razões pelas quais a
Lightning Network está experimentando um desenvolvimento muito mais rápido e é atraente para
muitas pessoas desenvolvedoras, que de outra forma poderiam considerar o estilo de
desenvolvimento do Bitcoin muito conservador e lento..
10
O Transporte de Mensagens Criptografadas
da Lightning
Neste capítulo, revisaremos o transporte de mensagens criptografadas da Lightning Network, às
vezes chamado deProtocolo Brontide, que permite que os nós estabeleçam comunicação
criptografada de ponta a ponta (end-to-end encrypted communication), autenticação e verificação
de integridade.
Parte deste capítulo inclui detalhes altamente técnicos sobre o protocolo de criptografia e os
algoritmos de criptografia usados no transporte criptografado do Lightning. Você pode decidir
pular essa seção se não estiver interessado nessas informações.
===Transporte Criptografado no Conjunto de Protocolos Lightning
O componente de transporte da Rede Relâmpago e seus vários componentes são mostrados na parte
mais à esquerda da camada de conexão de rede na Transporte de mensagens criptografadas no
conjunto de protocolos Lightning.
Figure 1. Transporte de mensagens criptografadas no conjunto de protocolos Lightning
Introdução
Ao contrário da rede P2P padrão do Bitcoin, cada nó na Lightning Network é identificado por uma
chave pública única que serve como sua identidade. Por padrão, essa chave pública é usada para
criptografar, de ponta a ponta, todas as comunicações dentro da rede. A criptografia por padrão no
nível mais baixo do protocolo garante que todas as mensagens sejam autenticadas, sejam imunes a
ataques de "homem do meio" (Man-In-The-Middle, MITM) e espionagem por terceiros, e garante
privacidade no nível fundamental de transporte. Neste capítulo, aprenderemos detalhadamente
1
sobre o protocolo de criptografia usado pela Lightning Network. Ao final deste capítulo, o leitor
estará familiarizado com o estado da arte em protocolos de mensagens criptografadas, bem como
com as várias propriedades que um protocolo desse tipo oferece à rede. Vale mencionar que o
cerne do transporte de mensagem criptografada é agnóstico em relação ao seu uso no contexto da
Lightning Network (Rede Relâmpago). Como resultado, o transporte personalizado de mensagem
criptografada usado pela Lightning pode ser utilizado em qualquer contexto que exija comunicação
criptografada entre duas partes.
O Grafo de Canais como Infraestrutura de Chave

Pública Descentralizada
Como aprendemos no [routing], cada nó possui uma identidade de longo prazo que é usada como
identificador para um vértice durante a busca de caminhos e também é utilizada nas operações
criptográficas assimétricas relacionadas à criação de pacotes de roteamento criptografados em
camadas (onion routing). Essa chave pública, que serve como identidade de longo prazo do nó, está
incluída na resposta de inicialização do DNS (Domain Name System), bem como incorporada dentro
do grafo de canais. Como resultado, antes que um nó tente se conectar a outro nó na rede P2P (peer-
to-peer), ele já conhece a chave pública do nó com o qual deseja se conectar.
Além disso, se o nó ao qual está sendo conectado já possui uma série de canais públicos dentro do
grafo, então o nó conectado é capaz de verificar ainda mais a identidade desse nó. Como o grafo de
canais inteiro é totalmente autenticado, pode-se considerá-lo como uma espécie de infraestrutura
de chave pública descentralizada (Public Key Infrastructure, PKI): para registrar uma chave, um
canal público deve ser aberto na blockchain do Bitcoin,e quando um nó não possui mais canais
públicos, ele é efetivamente removido da PKI.
Porque a Relâmpago é uma rede descentralizada, é imperativo que nenhuma entidade central seja
designada como detentora do poder para fornecer uma identidade de chave pública dentro da rede.
Em vez de uma entidade central, a Lightning Network utiliza a blockchain do Bitcoin como um
mecanismo de mitigação de ataques Sybil, pois obter uma identidade na rede tem um custo
tangível: a taxa necessária para criar um canal na blockchain, bem como o custo de oportunidade
do capital alocado aos canais. No processo de essencialmente estabelecer uma PKI específica para o
domínio, a Lightning Network consegue simplificar significativamente seu protocolo de transporte
criptografado, pois não precisa lidar com todas as complexidades associadas ao TLS, o protocolo de
Segurança da Camada de Transporte.
Por Que Não TLS?

Leitores familiarizados com o sistema TLS podem estar se perguntando neste momento: por que o
TLS não foi utilizado, apesar das desvantagens do sistema de PKI existente? De fato, é um fato que
"certificados autoassinados" podem ser usados para contornar efetivamente o sistema global de PKI
existente, simplesmente afirmando a identidade de uma determinada da chave pública entre um
conjunto de pares. No entanto, mesmo com o sistema de PKI existente fora do caminho, o TLS
apresenta várias desvantagens que levaram os criadores da Lightning Network a optar por um
protocolo de criptografia personalizado mais compacto.
Para começar, o TLS é um protocolo que existe há várias décadas e como resultado, evoluiu ao
2
longo do tempo à medida que novos avanços foram feitos no campo da criptografia de transporte.
No entanto, ao longo do tempo, essa evolução fez com que o protocolo se tornasse volumoso e
complexo. Ao longo das últimas décadas, várias vulnerabilidades no TLS foram descobertas e
corrigidas, e cada evolução aumentou ainda mais a complexidade do protocolo. Devido à idade do
protocolo, existem várias versões e iterações, o que significa que um cliente precisa entender
muitas das iterações anteriores do protocolo para se comunicar com uma grande parte da internet
pública, aumentando ainda mais a complexidade de implementação.
No passado, várias vulnerabilidades de segurança de memória foram descobertas em

implementações amplamente utilizadas de SSL/TLS. Incluir tal protocolo em cada nó da Lightning
aumentaria a superfície de ataque dos nós expostos à rede peer-to-peer pública. Para aumentar a
segurança da rede como um todo e minimizar a superfície de ataque explorável, os criadores da
Lightning Network optaram por adotar o Framework de Protocolo Noise. O Noise, como um
protocolo, internaliza várias lições de segurança e privacidade aprendidas ao longo do tempo,
devido à contínua análise do protocolo TLS ao longo de décadas. De certa forma, a existência do
Noise permite que a comunidade "comece de novo" de maneira eficaz, com um protocolo mais
compacto e simplificado que retém todos os benefícios adicionais do TLS.
A Estrutura do Protocolo de Ruído

O Framework de Protocolo Noise é um protocolo de criptografia de mensagens moderno, extensível
e flexível, projetado pelos criadores do Protocolo Signal. O Protocolo Signal é um dos protocolos de
criptografia de mensagens mais amplamente utilizados no mundo. É usado tanto pelo Signal
quanto pelo WhatsApp, que juntos são utilizados por mais de um bilhão de pessoas ao redor do
mundo. O framework Noise é resultado de décadas de evolução tanto na academia quanto na
indústria de protocolos de criptografia de mensagens. A Lightning utiliza o Framework de
Protocolo Noise para implementar um protocolo de criptografia orientado a mensagens, utilizado
por todos os nós para se comunicarem entre si.
Uma sessão de comunicação utilizando o Noise possui duas fases distintas: a fase de handshake
(aperto de mão) e a fase de troca de mensagens. Antes que duas partes possam se comunicar entre
si, elas precisam primeiro chegar a um segredo compartilhado conhecido apenas por elas, que será
utilizado para criptografar e autenticar as mensagens enviadas uma à outra.Uma variante de um
acordo de chave autenticado é utilizada para chegar a uma chave compartilhada final entre as duas
partes. No contexto do protocolo Noise, esse acordo de chave autenticado é referido como um
handshake. Uma vez que o handshake tenha sido concluído, ambos os nós podem começar a enviar
mensagens criptografadas um para o outro. Cada vez que os pares precisam se conectar ou
reconectar entre si, uma nova iteração do protocolo de handshake é executada, garantindo que o
sigilo futuro seja alcançado (o vazamento da chave de uma transcrição anterior não compromete
transcrições futuras).
Porque o Protocolo Noise permite que um projetista de protocolo escolha entre várias primitivas
criptográficas, como criptografia simétrica e criptografia de chave pública, é comum que cada
variante do Protocolo Noise seja referida por um nome único. No espírito do "Noise" (Ruído), cada
variante do protocolo seleciona um nome derivado de algum tipo de "ruído". No contexto daRede
Relâmpago, a variante do Protocolo Noise utilizada é às vezes chamada de Brontide. Um brontide é
um ruído baixo e ondulante, similar ao que se ouviria durante uma tempestade distante.
3
Transporte Criptografado da Relâmpago em detalhes
Nesta seção, iremos analisar o protocolo de transporte criptografado da Lightning e aprofundar nos
detalhes dos algoritmos criptográficos e do protocolo utilizados para estabelecer comunicações
criptografadas, autenticadas e com integridade assegurada entre pares. Sinta-se à vontade para
pular esta seção se considerar esses nível de detalhe assustador.
Noise_XK: O Handshake Noise da Rede Relâmpago
O Protocolo Noise é extremamente flexível, pois oferece vários apertos de mão (handshakes), cada
um com diferentes propriedades de segurança e privacidade, para que um implementador de
protocolo possa escolher. Uma exploração aprofundada de cada um dos apertos de mão e suas
várias vantagens e desvantagens está além do escopo deste capítulo. Dito isso, a Lightning Network
utiliza um aperto de mão específico chamado Noise_XK.A propriedade única fornecida por esse
aperto de mão é o ocultamento de identidade: para que um nó inicie uma conexão com outro nó, ele
deve primeiro conhecer sua chave pública. Mecanicamente, isso significa que a chave pública do
respondedor nunca é realmente transmitida durante o contexto do aperto de mão. Em vez disso,
uma série inteligente de verificação de Diffie-Hellman de Curva Elíptica (ECDH) e código de
autenticação de mensagem (MAC) é usada para autenticar o respondedor.
Notação de Handshake e Fluxo de Protocolo
Cada aperto de mão geralmente consiste em várias etapas. Em cada etapa, algum material
(possivelmente) criptografado é enviado para a outra parte, uma operação ECDH (ou várias) é
realizada, tendo como resultado que o handshake seja "misturado" em um transcript do protocolo.
Esse transcript serve para autenticar cada etapa do protocolo e ajuda a frustrar uma forma de
ataque de "homem no meio". No final do aperto de mão, são geradas duas chaves, ck e k, que são
usadas para criptografar mensagens (k) e rotacionar chaves (ck) ao longo da vida útil da sessão.
No contexto de um handshake, s geralmente é uma chave pública estática de longo prazo. No nosso
caso, o sistema criptográfico de chave pública utilizado é baseado em curvas elípticas, instanciado
com a curva secp256k1 , que também é usada em outras partes do Bitcoin. Várias chaves efêmeras
são geradas ao longo do handshake. Utilizamos e para se referir a uma nova chave efêmera.
Operações de ECDH entre duas chaves são notadas como a concatenação de duas chaves. Por
exemplo, ee representa uma operação ECDH entre duas chaves efêmeras.
Visão Geral de Alto Nível
Usando a notação apresentada anteriormente, podemos descrever sucintamente o Noise_XK como

segue:
Noise_XK(s, rs):
<- rs
...
-> e, e(rs)
<- e, ee
-> s, se
4
O protocolo começa com a "pré-transmissão" da chave estática do respondedor (rs) para o iniciador.
Antes de executar o handshake, o iniciador deve gerar sua própria chave estática (s). Durante cada
etapa do handshake, todo o material enviado pela rede e as chaves enviadas/usadas são
incrementalmente hasheados em um resumo de handshake, h. Esse resumo nunca é enviado pela
rede durante o handshake, sendo usado como "dados associados" quando a criptografia autenticada
com dados associados (AEAD - authenticated encryption with associated data) é enviada pela rede.
Dados Associados (Associated Data, AD) permite que um protocolo de criptografia autentique
informações adicionais juntamente com um pacote de texto cifrado. Em outros domínios, o AD pode
ser um nome de domínio ou uma porção de texto simples do pacote.
A existência de `h` garante que, se uma parte de uma mensagem de handshake

transmitida
for substituída, a outra parte irá perceber. Em cada etapa, é feita uma verificação do
resumo
MAC. Se a verificação do MAC for bem-sucedida, a parte receptora sabe que
o aperto de mão foi concluído com sucesso até aquele ponto. Caso contrário, se a
verificação
do MAC falhar em algum momento, o processo de aperto de mão (handshake) falhou e a
conexão
deve ser encerrada.
O protocolo também adiciona uma nova informação a cada mensagem de handshake: uma versão
do protocolo. A versão inicial do protocolo é 0. No momento da escrita, nenhuma nova versão do
protocolo foi criada. Como resultado, se um nó receber uma versão diferente de 0, ele deve rejeitar
a tentativa de início de aperto de mão.
Quanto às primitivas criptográficas, o SHA-256 é usado como a função de hash escolhida, secp256k1
é a curva elíptica utilizada e ChaChaPoly-130 é a construção AEAD (criptografia simétrica).
Cada variante do Protocolo Noise possui uma sequência de caracteres ASCII única usada para se
referir a ela. Para garantir que duas partes estejam usando a mesma variante do protocolo, a
sequência de caracteres ASCII é hasheada em um resumo, que é usado para inicializar o estado
inicial do handshake. No contexto do Lightning Network, a sequência de caracteres ASCII que
descreve o protocolo é Noise_XK_secp256k1_ChaChaPoly_SHA256.
Handshake em Três Atos
A porção do aperto de mão pode ser separada em três "atos" distintos. O aperto de mão completo
leva 1,5 viagens de ida-e-volta entre o iniciador e o respondente. Em cada ato, uma única
mensagem é enviada entre as duas partes. A mensagem handshake é uma carga útil de tamanho
fixo (fixed-sized payload), prefixada pela versão do protocolo.
O Protocolo Noise utiliza uma notação inspirada em orientação a objetos para descrever o
protocolo em cada etapa. Durante a configuração do estado de handshake, cada lado irá inicializar
as seguintes variáveis:
ck
A chaining key (chave de encadeamento). Este valor é o hash acumulado de todas as saídas ECHD
5
anteriores. No final do handshake, ck é usado para derivar as chaves de criptografia para
mensagens Lightning.
h
The handshake hash (hash do handshake). Esse valor é o hash acumulado de todos os dados de
handshake que foram enviados e recebidos até agora durante o processo de handshake.
temp_k1, temp_k2, temp_k3

As intermediate keys (chaves intermediárias). Elas são usadas para criptografar e descriptografar
as cargas úteis de tamanho zero AEAD no final de cada mensagem de handshake.
e
O par de chaves efêmeras (ephemeral key pair) de uma parte. Para cada sessão, um nó deve gerar
uma nova chave efêmera com uma forte aleatoriedade criptográfica.
s
Par de chaves estático static keypair de uma parte ( ls para local, rs para remoto).
Dado esse handshake mais o estado da sessão de mensagens, em seguida, definiremos uma série de
funções que operarão no handshake e no estado das mensagens. Ao descrever o protocolo de
handshake, usaremos essas variáveis de maneira semelhante a pseudocódigo para reduzir a
prolixidade da explicação de cada etapa do protocolo. Definiremos as primitivas funcionais do
handshake da seguinte forma:
ECDH(k, rk)
Executa uma operação Diffie–Hellman de Curva Elíptica usando k, que é uma chave privada
secp256k1 válida, e rk, que é uma chave pública válida.
O valor retornado é o SHA-256 do formato compactado do ponto gerado.
HKDF(salt,ikm)
Uma função definida em RFC 5869, avaliada com um campo info de comprimento zero.
Todas as invocações de HKDF retornam implicitamente 64 bytes de aleatoriedade criptográfica

usando o componente extrair e expandir (extract-and-expand) do HKDF.
encryptWithAD(k, n, ad, plaintext)

Saídas encrypt(k, n, ad, plaintext).
Onde encrypt é uma avaliação de ChaCha20-Poly1305 (variante da Internet Engineering Task

Force) com os argumentos passados, com nonce n codificado como 32 zero bits, seguido por um
valor de 64 bits little-endian. Nota: isto segue a convenção do Protocolo Noise, em vez do nosso
endian normal.
decryptWithAD(k, n, ad, ciphertext)

Saídas decrypt(k, n, ad, ciphertext).
Onde decrypt é uma avaliação de ChaCha20-Poly1305 (variante IETF) com os argumentos

passados, com nonce n codificado como 32 zero bits, seguido por um valor de 64 bits little-endian.
6
generateKey()
Gera e retorna um novo par de chaves secp256k1.
Onde o objeto retornado por generateKey possui dois atributos:`.pub`, que retorna um objeto
abstrato representando a chave pública; e .priv, que representa a chave privada usada para
gerar a chave pública
Onde o objeto também possui um único método: .serializeCompressed()
a || b
Isso denota a concatenação de duas strings de bytes a e b.
Inicialização do estado da sessão de handshake
Antes de iniciar o processo de handshake, ambas as partes precisam inicializar o estado inicial que
será usado para avançar o processo de handshake. Para começar, ambas as partes precisam
construir o resumo inicial do handshake, chamado de digest h.
1. h = SHA-256(__protocolName__)
Onde __protocolName__ = "Noise_XK_secp256k1_ChaChaPoly_SHA256" codificado como uma

string ASCII.
2. ck = h
3. h = SHA-256(h || __prologue__)
Onde __prologue__ é a string ASCII: lightning.
Além do nome do protocolo, também adicionamos um "prólogo" (prologue) adicional que é usado
para vincular ainda mais o contexto do protocolo à Lightning Network.
Para concluir a etapa de inicialização, ambas as partes misturam a chave pública do respondente
no resumo do handshake. Como esse resumo é usado enquanto os dados associados a um texto
cifrado de comprimento zero (apenas o MAC) são enviados, isso garante que o iniciador realmente
conheça a chave pública do respondente.
• O nó iniciador mistura a chave pública estática do nó respondente
serializada no formato comprimido do Bitcoin

h = SHA-256(h || rs.pub.serializeCompressed())
• O nó respondente mistura sua chave pública estática local, serializada
no formato comprimido do Bitcoin

h = SHA-256(h || ls.pub.serializeCompressed())
Atos de handshake
Após a inicialização inicial do handshake, podemos começar a execução real do processo de

handshake. O handshake é composto por uma série de três mensagens enviadas entre o iniciador e
7
o respondente, doravante referidas como "atos" (acts). Como cada ato é uma única mensagem
enviada entre as partes, um handshake é concluído em um total de 1,5 viagens de ida e volta (0,5
para cada ato).
("Diffie-Hellman Key Exchange (DHKE)"O primeiro ato completa a parte inicial da troca de chaves
triplo Diffie-Hellman (DH) incremental (usando uma nova chave efêmera gerada pelo iniciador) e
também garante que o iniciador realmente conhece a chave pública de longo prazo do
respondente. Durante o segundo ato, o respondente transmite ao iniciador a chave efêmera que
deseja usar para a sessão, e mais uma vez mistura incrementalmente essa nova chave no triplo DH
handshake. Durante o terceiro e último ato, o iniciador transmite sua chave pública estática de
longo prazo ao respondente e executa a operação DH final para misturá-la no segredo
compartilhado final resultante.
Ato Um
-> e, es
O Ato Um é enviado do iniciador para o respondente. Durante o Ato Um, o iniciador tenta atender a
um desafio implícito feito pelo respondente. Para completar esse desafio, o iniciador deve conhecer
a chave pública estática do respondente.
A mensagem de handshake tem exatamente 50 bytes: 1 byte para a versão do handshake, 33 bytes
para a chave pública efêmera comprimida do iniciador e 16 bytes para a tag poly1305.
Ações do remetente:
1. e = generateKey()
2. h = SHA-256(h || e.pub.serializeCompressed())
A chave efêmera recém-gerada é acumulada no resumo do handshake em andamento..
3. es = ECDH(e.priv, rs)
O iniciador realiza um ECDH (Diffie-Hellman de curva elíptica) entre sua nova chave efêmera
gerada e a chave pública estática do nó remoto.
4. ck, temp_k1 = HKDF(ck, es)
Uma nova chave temporária de criptografia é gerada, a qual é usada para gerar o MAC de
autenticação.
5. c = encryptWithAD(temp_k1, 0, h, zero)
Onde zero é um texto simples de comprimento zero.
6. h = SHA-256(h || c)
Finalmente, o texto cifrado gerado é acumulado no resumo de autenticação do handshake.

handshake em andamento..
8
7. Enviar m = 0 || e.pub.serializeCompressed() || c para o respondente através do buffer de
rede.
Ações do receptor:
1. Ler exatamente 50 bytes do buffer de rede.
2. Analisar (parse) a mensagem lida (m) em v, re e c:
◦ Onde v é o primeiro byte de m, re são os próximos 33 bytes de m, e c são os últimos 16 bytes de

m.
◦ Os bytes brutos (raw) da chave pública efêmera da parte remota (re) devem ser
desserializados em um ponto na curva usando coordenadas afins, conforme codificado pelo
formato composto serializado da chave.
3. Se v for uma versão de handshake não reconhecida, o respondente deve abortar a tentativa de
conexão.
4. h = SHA-256(h || re.serializeCompressed())
O respondente acumula a chave efêmera do iniciador no resumo de autenticação do handshake.
5. es = ECDH(s.priv, re)
O respondente realiza um ECDH (Diffie-Hellman de curva elíptica) entre sua chave privada
estática e a chave pública efêmera do iniciador.
6. ck, temp_k1 = HKDF(ck, es)
Uma nova chave temporária de criptografia é gerada, que em breve será usada para verificar o
MAC de autenticação.
7. p = decryptWithAD(temp_k1, 0, h, c)
Se a verificação do MAC nesta operação falhar, significa que o iniciador não conhece a chave
pública estática do respondente. Nesse caso, o respondente deve encerrar a conexão sem enviar
mais mensagens.
8. h = SHA-256(h || c)
O texto cifrado recebido é misturado no resumo do handshake. Esta etapa serve para garantir
que a carga útil (payload) não tenha sido modificada por um ataque de homem no meio (Man-
in-the-Middle, MITM).
Ato Dois
<- e, ee
O Ato Dois é enviado do respondente para o iniciador. O Ato Dois ocorrerá somente se o Ato Um
tiver sido bem-sucedido. O Ato Um é considerado bem-sucedido se o respondente conseguiu
descriptografar corretamente e verificar o MAC da tag enviada ao final do Ato Um.
9
O handshake possui exatamente 50 bytes: 1 byte para a versão do handshake, 33 bytes para a chave
pública efêmera comprimida do respondente e 16 bytes para a tag poly1305 .
1. e = generateKey()
2. h = SHA-256(h || e.pub.serializeCompressed())
A chave efêmera recém-gerada é acumulada no resumo do handshake em andamento..
3. ee = ECDH(e.priv, re)
Onde re é a chave efêmera do iniciador, que foi recebida durante o Ato Um.
4. ck, temp_k2 = HKDF(ck, ee)
autenticação.
5. c = encryptWithAD(temp_k2, 0, h, zero)
6. h = SHA-256(h || c)
Finalmente, o texto cifrado gerado é acumulado no resumo de autenticação do handshake.

handshake em andamento..
7. Enviar m = 0 || e.pub.serializeCompressed() || c para o iniciador pelo buffer de rede.
2. Analisar (parse) a mensagem lida (m) em v, re e c:
Onde v é o primeiro byte de m, re são os próximos 33 bytes de m, e c são os últimos 16 bytes de m.
conexão.
4. h = SHA-256(h || re.serializeCompressed())
5. ee = ECDH(e.priv, re)
Onde re é a chave pública efêmera do respondente.
Os bytes brutos (raw) da chave pública efêmera da parte remota (re) devem ser desserializados
em um ponto na curva usando coordenadas afins, conforme codificado pelo formato composto
serializado da chave.
6. ck, temp_k2 = HKDF(ck, ee)
10
autenticação.
7. p = decryptWithAD(temp_k2, 0, h, c)
Se a verificação do MAC nesta operação falhar, então o iniciador deve encerrar a conexão sem
enviar mais mensagens.
8. h = SHA-256(h || c)
O texto cifrado recebido é misturado no resumo do handshake. Esta etapa serve para garantir
que a carga útil (payload) não tenha sido modificada por um ataque de homem no meio (Man-
in-the-Middle, MITM).
Ato Três
-> s, se
O Ato Três é a fase final no acordo de chave autenticada descrito nesta seção. Este ato é enviado do
iniciador para o respondente como uma etapa conclusiva. O Ato Três é executado somente se o Ato
Dois tiver sido bem-sucedido. Durante o Ato Três, o iniciador transporta sua chave pública estática
para o respondente, criptografada com forte segurança para frente (forward secrecy), usando a
chave secreta derivada HKDF acumulada até este ponto do handshake.
O handshake possui exatamente 66 bytes: 1 byte para a versão do handshake, 33 bytes para a chave
pública estática criptografada com a cifra de fluxo ChaCha20, 16 bytes para a tag da chave pública
criptografada gerada pela construção AEAD e 16 bytes para uma tag de autenticação final.
1. c = encryptWithAD(temp_k2, 1, h, s.pub.serializeCompressed())
Onde s é a chave pública estática do iniciador.
2. h = SHA-256(h || c)
3. se = ECDH(s.priv, re)
Onde re é a chave pública efêmera do respondente.
4. ck, temp_k3 = HKDF(ck, se)
O segredo compartilhado intermediário final é misturado à chave de encadeamento em

execução.
5. t = encryptWithAD(temp_k3, 0, h, zero)
6. sk, rk = HKDF(ck, zero)
Onde zero é um texto simples de comprimento zero, sk é a chave a ser usada pelo iniciador para
11
criptografar mensagens para o respondente, e rk é a chave a ser usada pelo iniciador para
descriptografar mensagens enviadas pelo respondente.
As chaves de criptografia finais, a serem usadas para enviar e receber mensagens pela duração
da sessão, são geradas.
7. rn = 0, sn = 0
Os nonces de envio e recebimento são inicializados com 0.
8. Enviar m = 0 || c || t pelo buffer de rede.
2. Analisar (parse) a mensagem lida (m) em v, c e t:
Onde v é o primeiro byte de m, c são os próximos 49 bytes de m, e t são os últimos 16 bytes de m.
conexão.
4. rs = decryptWithAD(temp_k2, 1, h, c)
Neste ponto, o respondente recuperou a chave pública estática do iniciador.
5. h = SHA-256(h || c)
6. se = ECDH(e.priv, rs)
Onde e é a chave efêmera original do respondente.
7. ck, temp_k3 = HKDF(ck, se)
8. p = decryptWithAD(temp_k3, 0, h, t)
Se a verificação do MAC nesta operação falhar, o respondente deve encerrar a conexão sem
mais mensagens.
9. rk, sk = HKDF(ck, zero)
Onde zero é um texto simples de comprimento zero, rk é a chave a ser usada pelo respondente
para descriptografar as mensagens enviadas pelo iniciador, e sk é a chave a ser usada pelo
respondente para criptografar mensagens para o iniciador.
As chaves de criptografia finais, a serem usadas para enviar e receber mensagens pela duração
da sessão, são geradas.
10. rn = 0, sn = 0
Os nonces de envio e recebimento são inicializados como 0.
12
Criptografia de mensagem de transporte
Ao concluir o Ato Três, ambas as partes derivaram as chaves de criptografia, que serão usadas para
criptografar e descriptografar mensagens pelo restante da sessão.
As mensagens reais do Protocolo Lightning são encapsuladas em textos cifrados usando AEAD
(Authenticated Encryption with Associated Data). Cada mensagem é prefixada com outro texto
cifrado AEAD, que codifica o comprimento total da mensagem Lightning subsequente (sem incluir o
MAC).
O tamanho máximo de qualquer mensagem Lightning não deve exceder 65.535 bytes. Um tamanho
máximo de 65.535 simplifica os testes, facilita o gerenciamento de memória e ajuda a mitigar
ataques de esgotamento de memória.
Para dificultar a análise de tráfego, o prefixo de comprimento de todas as mensagens Lightning

criptografadas também é criptografado. Além disso, uma tag de 16 bytes Poly-1305 é adicionada ao
prefixo de comprimento criptografado para garantir que o comprimento do pacote não tenha sido
modificado durante a transmissão e também para evitar a criação de um oráculo de
descriptografia.
A estrutura dos pacotes no wire se assemelha ao diagrama na Estrutura do pacote criptografado.
Figure 2. Estrutura do pacote criptografado
O comprimento da mensagem prefixada é codificado como um inteiro de 2 bytes big-endian, com

um comprimento máximo total do pacote de 2 + 16 + 65,535 + 16 = 65,569 bytes.
13
Criptografia e envio de mensagens
Para criptografar e enviar uma mensagem Lightning (m) para o fluxo de rede, dada uma chave de
envio (sk) e um nonce (sn), as seguintes etapas são concluídas:
1. Let l = len(m).
Onde len obtém o comprimento em bytes da mensagem do Lightning.
2. Serializar l em 2 bytes codificados como um inteiro big-endian.
3. Criptografar l (usando ChaChaPoly-1305, sn e sk) para obter lc (18 bytes).
◦ O nonce sn é codificado como um número little-endian de 96 bits. Como o nonce

decodificado é de 64 bits, o nonce de 96 bits é codificado como 32 bits de zeros à esquerda
seguidos por um valor de 64 bits.
◦ O nonce sn deve ser incrementado após esta etapa.
◦ Um pedaço de bytes de comprimento zero deve ser passado como o AD (dados associados).
4. Finalmente, criptografe a própria mensagem (m) usando o mesmo procedimento usado para
criptografar o prefixo de comprimento. Vamos chamar esse texto cifrado criptografado de c.
O nonce sn deve ser incrementado após esta etapa.
5. Enviar lc || c sobre o buffer de rede.
Recebendo e descriptografando mensagens
Para descriptografar a próxima mensagem no fluxo de rede, as seguintes etapas são concluídas:
2. Deixar o prefixo de comprimento criptografado ser conhecido como lc.
3. Descriptografar lc (usando ChaCha20-Poly1305, rn e rk) para obter o tamanho do pacote

criptografado l.
◦ Um pedaço de bytes de comprimento zero deve ser passado como o AD (dados associados).
◦ O nonce rn deve ser incrementado após esta etapa.
4. Ler exatamente l + 16 bytes do buffer de rede e deixar os bytes serem conhecidos como c.
5. Descriptografar c (usando ChaCha20-Poly1305, rn e rk) para obter o pacote em texto simples

descriptografado p.
O nonce rn deve ser incrementado após esta etapa.
Rotação de chave de mensagem Lightning
Trocar as chaves regularmente e esquecer as chaves anteriores é útil para evitar a descriptografia
de mensagens antigas, no caso de vazamento posterior das chaves (ou seja, segredo retroativo).
A rotação de chaves é realizada para cada chave (sk e rk) individualmente. Uma chave deve ser
rotacionada após uma parte criptografar ou descriptografar 1.000 vezes com ela (ou seja, a cada 500
mensagens). Isso pode ser feito corretamente ao rotacionar a chave assim que o nonce dedicado a
14
ela exceder 1.000.
A rotação de chave para uma chave k é realizada seguindo os seguintes passos:
1. Seja ck a chave de encadeamento obtida no final do Ato Três.
2. ck', k' = HKDF(ck, k)
3. Redefinir o nonce da chave para n = 0.
4. k = k'
5. ck = ck'
Conclusão
A criptografia de transporte subjacente da Lightning é baseada no Protocolo Noise e oferece
garantias sólidas de segurança de privacidade, autenticidade e integridade para todas as
comunicações entre os pares da Lightning.
Ao contrário do Bitcoin, onde os pares frequentemente se comunicam "no claro" (sem criptografia),
todas as comunicações da Lightning são criptografadas ponto a ponto. Além da criptografia de
transporte (peer-to-peer, ou ponto a ponto), na Lightning Network, os pagamentos também são
criptografados em pacotes de cebola (hop-to-hop, ou salto a salto) e os detalhes do pagamento são
enviados fora da banda (out-of-band) entre o remetente e o destinatário (end-to-end, ou ponta a
ponta). A combinação de todos esses mecanismos de segurança é cumulativa e fornece uma defesa
em camadas contra desanonimização, ataques de homem no meio (MITM) e vigilância de rede.
Claro, não existe segurança perfeita e veremos no [security_and_privacy] que essas propriedades
podem ser degradadas e atacadas. No entanto, a Lightning Network melhora significativamente a
privacidade em relação ao Bitcoin.
15
Solicitações de Pagamento Relâmpago
Neste capítulo, iremos analisar os pedidos de pagamento do Lightning, ou como são mais
conhecidas, as Lightning invoices (faturas Relâmpago).
Faturas no Conjunto de Protocolos Relâmpago

Pedidos de pagamento, também conhecidos como faturas, fazem parte da camada de pagamento e
são exibidos no canto superior esquerdo da Solicitações de pagamento no conjunto de protocolos
Lightning.
Figure 1. Solicitações de pagamento no conjunto de protocolos Lightning
Introdução
Conforme aprendemos ao longo do livro, são necessários pelo menos dois dados para concluir um
pagamento Relâmpago: um hash de pagamento e um destino. Como o SHA-256 é usado na Rede
Relâmpago para implementar os HTLCs, essa informação requer 32 bytes para ser comunicada. Por
outro lado, os destinos são simplesmente a chave pública secp256k1 do nó que deseja receber um
pagamento. O objetivo de um pedido de pagamento no contexto da Rede Relâmpago é comunicar
essas duas informações do remetente para o destinatário. O formato amigável para QR code, usado
para comunicar as informações necessárias para concluir um pagamento do destinatário para o
remetente é descrito em BOLT #11: Invoice Protocol for Lightning Payments. Na prática, mais do
que apenas o hash de pagamento e o destino são comunicados em um pedido de pagamento para
tornar a codificação mais completa.
1
Pedidos de Pagamento Relâmpago versus Endereços
Bitcoin
Uma pergunta comumente feita quando as pessoas encontram pela primeira vez um pedido de
pagamento Relâmpago é: por que não é possível usar um formato de endereço estático normal em
vez disso?
Para responder a essa pergunta, você deve primeiro internalizar como a Relâmpago difere do
Bitcoin na camada base como método de pagamento. Comparado a um endereço Bitcoin, que pode
ser usado para fazer um número potencialmente ilimitado de pagamentos (embora reutilizar um
endereço Bitcoin possa comprometer a privacidade), um pedido de pagamento Relâmpago deve ser
usado apenas uma vez. Isso ocorre porque enviar um pagamento para um endereço Bitcoin
essencialmente usa um sistema de criptografia de chave pública para "codificar" o pagamento de
uma maneira que apenas o verdadeiro "dono" daquele endereço Bitcoin pode resgatá-lo.
Em contraste, para completar um pagamento Relâmpago, o destinatário deve revelar um "segredo"

a toda a rota de pagamento, incluindo o remetente. Isso pode ser interpretado como o uso de uma
espécie de criptografia simétrica específica do domínio, pois a pré-imagem do pagamento é, para
fins práticos, um nonce (número usado apenas uma vez). Se o remetente tentar fazer outro
pagamento usando aquele mesmo hash de pagamento, ele corre o risco de perder fundos, pois o
pagamento pode não ser realmente entregue ao destino. É seguro presumir que, após a pré-imagem
ser revelada, todos os nós no caminho a manterão indefinidamente. Então, em vez de encaminhar o
HTLC para coletar uma taxa de roteamento quando o pagamento é concluído, eles podem
simplesmente liquidar o pagamento naquela instância e receber o valor total do pagamento em
troca. Portanto, é inseguro usar um pedido de pagamento mais de uma vez.
Existem novas variantes do pedido de pagamento original da Relâmpago que permitem que o
remetente os reutilize quantas vezes desejar. Essas variantes invertem o fluxo normal de
pagamento, pois o remetente transmite uma pré-imagem dentro da carga útil de cebola
criptografada para o destinatário, que é o único capaz de descriptografá-lo e liquidar o pagamento.
Alternativamente, assumindo um mecanismo que permita que o remetente solicite normalmente
um novo pedido de pagamento ao destinatário, então um protocolo interativo pode ser usado para
permitir um certo grau de reutilização do pedido de pagamento.
BOLT #11: Serialização e Interpretação de Pedidos de

Pagamento da Lightning
Nesta seção, descreveremos o mecanismo usado para codificar o conjunto de informações
necessárias para concluir um pagamento na Rede Relâmpago. Como mencionado anteriormente, o
hash do pagamento e o destino são a quantidade mínima de informações necessárias para concluir
um pagamento. No entanto, na prática, mais informações, como informações de prazo (timelock),
expiração do pedido de pagamento e possivelmente um endereço de fallback on-chain, também são
comunicadas. O documento de especificação completo está disponível em BOLT #11: Invoice
Protocol for Lightning Payments.
2
Codificação de Pedido de Pagamento na Prática
Primeiro, vamos examinar como um pedido de pagamento real se parece na prática. A seguir está
um exemplo válido de um pedido de pagamento que poderia ter sido usado para completar um
pagamento na rede principal da Lightning Network no momento em que foi criada:
lnbc2500u1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysx
xatsyp3k7enxv4jsxqzpuaztrnwngzn3kdzw5hydlzf03qdgm2hdq27cqv3agm2awhz5se903vruatf
hq77w3ls4evs3ch9zw97j25emudupq63nyw24cg27h2rspfj9srp
O Prefixo Legível por Humanos
Olhando a sequência, podemos identificar uma parte que podemos analisar visualmente, enquanto
o restante parece apenas um conjunto aleatório de caracteres. A parte que pode ser analisada por
um humano é chamada de prefixo legível por humanos. Isso permite que uma pessoa extraia
rapidamente algumas informações relevantes de um pedido de pagamento com apenas um olhar.
Neste caso, podemos ver que esse pagamento é para a instância da rede principal da Lightning
Network (lnbc), e está solicitando 2.500 uBTC (microbitcoin), ou 25.000.000 satoshis. A última parte
é referida como a porção de dados e usa um formato extensível para codificar as informações
necessárias para completar um pagamento.
Cada versão ou instância da Lightning Network (rede principal, rede de testes, etc.) possui seu
próprio prefixo legível por humanos (veja Prefixos da rede BOLT #11). Isso permite que o software
cliente e também os humanos determinem rapidamente se um pedido de pagamento pode ser
atendido pelo seu nó ou não.
Table 1. Prefixos da rede BOLT #11
Rede Prefixo BOLT #11
mainnet lnbc
testnet lntb
simnet/regtest lnbcrt
A primeira parte do prefixo legível por humanos é uma expressão compacta do valor do pedido de
pagamento. O valor compacto é codificado em duas partes. Primeiro, um número inteiro é usado
como o valor base. Em seguida, é adicionado um multiplicador que nos permite especificar
aumentos distintos na ordem de grandeza em relação ao valor base. Se retornarmos ao nosso
exemplo inicial, podemos pegar a parte 2500u e diminuí-la por um fator de 1.000 para usar 2500m ou
(2.500 mBTC) em vez disso. Como regra geral, para determinar o valor de uma fatura rapidamente,
pegue o fator base e o multiplique pelo multiplicador.
Uma lista completa dos multiplicadores atualmente definidos é apresentada na Multiplicadores de

valores BOLT #11.
Table 2. Multiplicadores de valores BOLT #11
3
Multiplicador Unidade Bitcoin Fator de multiplicação
m milli 0.001
u micro 0.000001
n nano 0.000000001
p pico 0.000000000001
bech32 e o Segmento de Dados
Se a parte "ilegível" parecer familiar, é porque ela usa o mesmo esquema de codificação que os
endereços Bitcoin compatíveis com SegWit usam atualmente, conhecido como bech32. Descrever o
esquema de codificação bech32 está fora do escopo deste capítulo. Em resumo, é uma forma
sofisticada de codificar sequências curtas que possui propriedades muito boas de correção e
detecção de erros.
A porção de dados pode ser separada em três seções:
• O carimbo de data/hora (timestamp)
• Zero ou mais pares de valores-chave marcados
• A assinatura de toda a fatura
O carimbo de data e hora é expresso em segundos desde o ano de 1970, ou o Unix Epoch. Esse
carimbo de tempo permite que o remetente determine a idade do pedido de pagamento e, como
veremos posteriormente, permite ao destinatário forçar uma fatura a ser válida apenas pelo
período de tempo que ele desejar.
Similar ao formato TLV que aprendemos em [tlv], o formato de fatura BOLT #11 utiliza uma série de
pares chave-valor extensíveis para codificar informações necessárias para satisfazer um
pagamento. Como pares chave-valor são usados , é fácil adicionar novos valores no futuro caso um
novo tipo de pagamento ou requisito/funcionalidade adicional seja introduzido.
Por fim, uma assinatura é incluída que abrange todo o pedido de pagamento e é assinada pelo
destinatário do pagamento. Essa assinatura permite que o remetente verifique que o pedido de
pagamento foi realmente criado pelo destinatário do pagamento. Ao contrário dos pedidos de
pagamento do Bitcoin que não são assinados, isso nos permite garantir que uma entidade específica
tenha assinado o pedido de pagamento. A assinatura em si é codificada usando um ID de
recuperação, que permite o uso de uma assinatura mais compacta que permite a extração da chave
pública. Ao verificar a assinatura, o ID de recuperação extrai a chave pública, e então a verifica em
relação à chave pública incluída no pedido de pagamento.
Campos de Fatura Marcados
Os campos marcados da fatura são codificados no corpo principal da fatura. Esses campos
representam diferentes pares chave-valor que expressam informações adicionais que podem
ajudar a completar o pagamento ou informações que são obrigatórias para completar o pagamento.
Como é utilizada uma leve variante do bech32 cada um desses campos está realmente no domínio
"base 5".
4
Um determinado campo de marcação (tag field) é composto por três componentes:
• O tipo do campo (5 bits)
• O comprimento dos dados do campo (10 bits)
• Os próprios dados, que têm tamanho comprimento * 5 bytes
Uma lista completa de todos os campos de marcação definidos atualmente é dada em Campos de
fatura marcados no BOLT #11 .
Table 3. Campos de fatura marcados no BOLT #11
Field tag Comprimento dos dados Uso

p 52 O hash de pagamento SHA-256.
s 52 Um segredo de 256 bits que
aumenta a privacidade de
ponta a ponta de um
pagamento, mitigando a
sondagem por nós
intermediários.
d Variável A descrição, uma breve
sequência UTF-8 do objetivo do
pagamento.
n 53 A chave pública do nó de
destino.
h 52 Um hash que representa uma
descrição do próprio
pagamento. Isso pode ser usado
para se comprometer a uma
descrição que tenha mais de
639 bytes de comprimento.
x Variável O tempo de expiração, em
segundos, do pagamento. O
valor padrão é de 1 hora (3.600)
se não for especificado.
c Variável O min_cltv_expiry a ser usado
para o último salto na rota. O
valor padrão é 9 se não for
especificado.
f Variável Um endereço de fallback on-
chain a ser usado para
completar o pagamento caso o
pagamento não possa ser
concluído na Rede Relâmpago.
5
Field tag Comprimento dos dados Uso
r Variável Uma ou mais entradas que
permitem ao destinatário
fornecer ao remetente arestas
efêmeras adicionais para
completar o pagamento.
9 Variável Um conjunto de valores de 5
bits que contêm os feature bits
necessários para completar o
pagamento.
Os elementos contidos no campo r são comumente chamados de dicas de roteamento. Eles

permitem que o destinatário comunique um conjunto extra de arestas que podem ajudar o
remetente a completar seu pagamento. As dicas de roteamento são geralmente usadas quando o
destinatário possui alguns ou todos os canais privados e deseja orientar o remetente para essa
parte "não mapeada" do grafo de canais. Uma dica de roteamento codifica efetivamente as mesmas
informações que uma mensagem de channel_update normal. A própria atualização é empacotada
em um único valor com os seguintes campos:
• A pubkey do nó de saída na aresta (264 bits)
• O short_channel_id da aresta "virtual" (64 bits)
• A taxa base (fee_base_msat) da aresta (32 bits)
• A taxa proporcional (fee_proportional_millionths) (32 bits)
• O delta de expiração do CLTV (cltv_expiry_delta) (16 bits)
A parte final do segmento de dados é o conjunto de feature bits que comunica ao remetente a
funcionalidade necessária para concluir um pagamento. Por exemplo, se um novo tipo de
pagamento for adicionado no futuro que não seja compatível com o tipo de pagamento original
(backward compatible), então o destinatário pode definir um feature bit obrigatório para
comunicar que o pagador precisa entender esse recurso para concluir o pagamento.
Conclusão
Como vimos, os pedidos de pagamento são muito mais do que apenas uma solicitação de um valor.
Eles contêm informações críticas sobre como fazer o pagamento, como dicas de roteamento, a
chave pública do nó de destino, chaves efêmeras para aumentar a segurança e muito mais.
6
Segurança e Privacidade na Rede Relâmpago
Neste capítulo, examinamos algumas das questões mais importantes relacionadas à segurança e
privacidade da Rede Relâmpago. Primeiro, consideraremos a privacidade, o que significa, como
avaliá-la e algumas medidas que você pode tomar para proteger sua própria privacidade ao usar a
rede Relâmpago. Em seguida, exploraremos alguns ataques comuns e técnicas de mitigação.
Por Que a Privacidade é Importante?

A proposta de valor fundamental das criptomoedas é o dinheiro resistente à censura. O Bitcoin
oferece aos participantes a possibilidade de armazenar e transferir sua riqueza sem interferência
de governos, bancos ou corporações. A Lightning Network (Rede Relâmpago) continua essa missão.
Ao contrário de soluções de escalabilidade triviais, como bancos de Bitcoin custodiais, a Rede

Relâmpago tem como objetivo escalar o Bitcoin sem comprometer a custódia própria, o que deve
levar a uma maior resistência à censura no ecossistema do Bitcoin. No entanto, a Lightning
Network opera sob um modelo de segurança diferente, o que introduz novos desafios de segurança
e privacidade.
Definições de Privacidade
A pergunta "A Relâmpago é privada?" não tem uma resposta direta. A privacidade é um tópico
complexo; muitas vezes é difícil definir precisamente o que queremos dizer com privacidade,
especialmente se você não é um pesquisador em privacidade. Felizmente, os pesquisadores em
privacidade utilizam processos para analisar e avaliar as características de privacidade dos
sistemas, e nós também podemos usá-los! Vamos ver como um pesquisador de segurança pode
buscar responder à pergunta "A Relâmpago é privada?" em dois passos gerais.
Primeiro, um pesquisador de privacidade definiria um modelo de segurança que especifica o que

um adversário é capaz de fazer e o que ele busca alcançar. Em seguida, eles descreveriam as
propriedades relevantes do sistema e verificariam se ele atende aos requisitos.
Processo para Avaliar Privacidade

Um modelo de segurança é baseado em um conjunto de suposições de segurança subjacentes. Em
sistemas criptográficos, essas suposições geralmente estão centradas nas propriedades matemáticas
das primitivas criptográficos, como cifras, assinaturas e funções de hash. As suposições de
segurança da Lightning Network são que as assinaturas ECDSA, a função de hash SHA-256 e outras
funções criptográficas usadas no protocolo se comportem dentro de suas definições de segurança.
Por exemplo, assumimos que é praticamente impossível encontrar uma pré-imagem (e segunda
pré-imagem) de uma função de hash. Isso permite que a Rede Relâmpago dependa do mecanismo
HTLC (que usa a pré-imagem de uma função hash) para a atomicidade dos pagamentos de vários
saltos: ninguém, exceto o destinatário final, pode revelar o segredo do pagamento e resolver o
HTLC. Também assumimos um grau de conectividade na rede, ou seja, que os canais da Lightning
formam um grafo conectado. Portanto, é possível encontrar um caminho de qualquer remetente
para qualquer destinatário. Por fim, assumimos que as mensagens de rede são propagadas dentro
de determinados intervalos de tempo limite.
1
Agora que identificamos algumas de nossas suposições subjacentes, vamos considerar alguns
possíveis adversários.
Aqui estão alguns possíveis modelos de adversários na Rede Relâmpago. Um nó de

encaminhamento "honesto-mas-curioso" pode observar os valores dos pagamentos, os nós
imediatamente anteriores e posteriores e o grafo dos canais anunciados com suas capacidades. Um
nó muito bem conectado pode fazer o mesmo, mas em uma escala maior. Por exemplo, considere as
desenvolvedoras de uma carteira popular que mantêm um nó ao qual seus usuários se conectam
por padrão. Este nó seria responsável por rotear uma grande parte dos pagamentos de e para os
usuários dessa carteira. O que acontece quando vários nós estão sob controle adversarial? Se dois
nós mal-intencionados colaboradores estiverem no mesmo caminho de pagamento, eles podem
entender que estão encaminhando HTLCs pertencentes ao mesmo pagamento, pois os HTLCs
possuem o mesmo hash de pagamento.
Pagamentos multipartes (see [mpp]) permitem que os usuários obscureçam os valores de seus
pagamentos, considerando que os tamanhos de divisão não são uniformes.
Quais podem ser os objetivos de um atacante na Relâmpago? A segurança da informação

geralmente é descrita em termos de três propriedades principais: confidencialidade, integridade e
disponibilidade.
Confidencialidade
A informação só chega aos destinatários pretendidos.
Integridade
As informações não são alteradas no trânsito.
Disponibilidade
O sistema está funcionando a maior parte do tempo.
As propriedades importantes da Rede Relâmpago estão principalmente relacionadas à

confidencialidade e disponibilidade. Algumas das propriedades mais importantes a serem
protegidas incluem:
• Somente o remetente e o destinatário sabem o valor do pagamento.
• Ninguém pode vincular remetentes e destinatários.
• Um usuário honesto não pode ser impedido de enviar e receber pagamentos.
Para cada objetivo de privacidade e modelo de segurança, há uma certa probabilidade de sucesso
de um invasor. Essa probabilidade depende de vários fatores, como o tamanho e a estrutura da
rede. Outras coisas sendo iguais, geralmente é mais fácil atacar com sucesso uma pequena rede do
que uma grande. Da mesma forma, quanto mais centralizada for a rede, mais capaz um invasor
pode ser se os nós "centrais" estiverem sob seu controle. Obviamente, o termo centralização deve
ser definido com precisão para construir modelos de segurança em torno dele, e há muitas
definições possíveis de quão centralizada é uma rede. Por fim, como rede de pagamentos, a Rede
Relâmpago depende de estímulos econômicos. O tamanho e a estrutura das taxas afetam o
algoritmo de roteamento e, portanto, podem tanto ajudar o atacante ao encaminhar a maioria dos
2
pagamentos por meio de seus nós quanto impedir que isso aconteça.
Conjunto de Anonimato
O que significa desanonimizar alguém? Em termos simples, a desanonimização implica em associar
uma determinada ação à identidade real de uma pessoa no mundo real, como seu nome ou
endereço físico. Na pesquisa de privacidade, a noção de desanonimização é mais matizada.
Primeiro, não estamos necessariamente falando de nomes e endereços. Descobrir o endereço IP ou
número de telefone de alguém também pode ser considerado desanonimização. Uma informação
que permite vincular a ação de um usuário às suas ações anteriores é chamada de identidade. Em
segundo lugar, a desanonimização não é binária; um usuário não é totalmente anônimo nem
completamente desanonimizado. Em vez disso, a pesquisa de privacidade analisa o anonimato em
comparação com o conjunto de anonimato.
O conjunto de anonimato (anonymity set) é uma noção central na pesquisa de privacidade. Refere-
se ao conjunto de identidades tal que, do ponto de vista de um invasor, uma determinada ação pode
corresponder a qualquer um no conjunto. Considere um exemplo da vida real. Imagine que você
conhece uma pessoa em uma rua da cidade. Qual é o conjunto de anonimato deles do seu ponto de
vista? Se você não os conhece pessoalmente e sem nenhuma informação adicional, seu anonimato é
aproximadamente igual à população da cidade, incluindo viajantes. Se você também considerar sua
aparência, poderá estimar aproximadamente sua idade e excluir os residentes da cidade que
obviamente são mais velhos ou mais jovens do que a pessoa em questão do conjunto de anonimato.
Além disso, se você perceber que a pessoa entra no escritório da Empresa X usando um crachá
eletrônico, o conjunto de anonimato é reduzido ao número de funcionários e visitantes da empresa
X. Por fim, você pode notar a placa do carro que eles usaram para chegar ao local. Se você é um
observador casual, isso não lhe dá muito. No entanto, se você for um funcionário da prefeitura e
tiver acesso ao banco de dados que relaciona números de placas de veículos a nomes, você pode
reduzir o conjunto de anonimato para apenas algumas pessoas: o proprietário do veículo e
quaisquer amigos próximos ou parentes que possam ter usado o carro emprestado.
Este exemplo ilustra alguns pontos importantes. Primeiro, cada bit de informação pode aproximar
o adversário de seu objetivo. Pode não ser necessário reduzir o conjunto de anonimato para o
tamanho de um. Por exemplo, se o adversário planeja um ataque de negação de serviço (DoS)
direcionado e pode derrubar 100 servidores, o conjunto de anonimato de 100 é suficiente. Em
segundo lugar, o adversário pode correlacionar informações de diferentes fontes. Mesmo que um
vazamento de privacidade pareça relativamente benigno, nunca sabemos o que ele pode alcançar
em combinação com outras fontes de dados. Finalmente, especialmente em ambientes
criptográficos, o atacante sempre tem o "último recurso" de uma busca por força bruta. Primitivas
criptográficas são projetadas para que seja praticamente impossível adivinhar um segredo como
uma chave privada. No entanto, cada bit de informação aproxima o adversário desse objetivo e, em
algum momento, torna-se alcançável.
Em termos da Relâmpago, desanonimizar geralmente significa derivar uma correspondência entre

pagamentos e usuários identificados por IDs de nó. A cada pagamento pode ser atribuído um
conjunto de anonimato do remetente e um conjunto de anonimato do destinatário. Idealmente, o
conjunto de anonimato consiste em todos os usuários da rede. Isso garante que o invasor não tenha
nenhuma informação. No entanto, a rede real vaza informações que permitem a um invasor
reduzir a busca. Quanto menor o conjunto de anonimato, maior a chance de desanonimização bem-
3
sucedida.
Diferenças Entre a Rede Relâmpago e o Bitcoin em

Termos de Privacidade
Embora seja verdade que as transações na rede Bitcoin não associem identidades do mundo real
aos endereços Bitcoin, todas as transações são transmitidas em texto claro e podem ser analisadas.
Várias empresas foram estabelecidas para remover o anonimato dos usuários de Bitcoin e outras
criptomoedas.
À primeira vista, a Relâmpago oferece melhor privacidade do que o Bitcoin porque os pagamentos
da Relâmpago não são transmitidos para toda a rede. Embora isso melhore a privacidade de base,
outras propriedades do protocolo Lightning podem tornar os pagamentos anônimos mais
desafiadores. Por exemplo, pagamentos maiores podem ter menos opções de roteamento. Isso pode
permitir que um adversário que controle nós bem capitalizados encaminhe a maioria dos
pagamentos de grande valor e descubra os valores dos pagamentos e provavelmente outros
detalhes. Com o tempo, à medida que a Lightning Network cresce, isso pode se tornar menos
problemático.
Outra diferença relevante entre Lightning e Bitcoin é que os nós Lightning mantêm uma identidade
permanente, enquanto os nós Bitcoin não. Uma usuária sofisticada de Bitcoin pode facilmente
alternar os nós usados para receber dados do blockchain e transmitir transações. Um usuário da
Lightning, ao contrário, envia e recebe pagamentos por meio dos nós que usou para abrir seus
canais de pagamento. Além disso, o protocolo Lightning pressupõe que os nós de roteamento
anunciem seu endereço IP, além de seu ID de nó. Isso cria uma conexão permanente entre os IDs de
nó e os endereços IP, o que pode ser perigoso, considerando que um endereço IP é frequentemente
um passo intermediário em ataques de anonimato relacionados à localização física do usuário e, na
maioria dos casos, à identidade no mundo real. É possível usar a Lightning sobre a rede Tor, mas
muitos nós não utilizam essa funcionalidade, como pode ser observado em statistics collected from
node announcements.
Uma usuária da Lightning, ao enviar um pagamento, tem seus vizinhos como parte do seu conjunto
de anonimato. Especificamente, um nó de roteamento conhece apenas os nós imediatamente
anteriores e posteriores. O nó de roteamento não sabe se seus vizinhos imediatos na rota de
pagamento são o remetente ou o destinatário final. Portanto, o conjunto de anonimato de um nó no
Lightning é aproximadamente igual ao de seus vizinhos (veja O conjunto de anonimato de Alice e
Bob constitui seus vizinhos).
4
Figure 1. O conjunto de anonimato de Alice e Bob constitui seus vizinhos
Uma lógica similar se aplica aos receptores de pagamento. Muitos usuários abrem apenas um
punhado de canais de pagamento, limitando assim seu conjunto de anonimato. Além disso, na
Lightning, o conjunto de anonimato é estático ou, pelo menos, muda lentamente. Em contraste,
pode-se obter conjuntos de anonimato significativamente maiores em transações CoinJoin on-
chain. As transações CoinJoin com conjuntos de anonimato maiores que 50 são bastante frequentes.
Normalmente, os conjuntos de anonimato em uma transação CoinJoin correspondem a um
conjunto de usuários que muda dinamicamente.
Por fim, os usuários da Lightning também podem ter o serviço negado, tendo seus canais
bloqueados ou esgotados por um invasor. Encaminhar pagamentos requer capital—um recurso
escasso!—para ser temporariamente bloqueado em HTLCs (Hashed Time-Locked Contracts) ao
longo da rota. Um atacante pode enviar muitos pagamentos, mas falhar em finalizá-los, ocupando o
capital de usuários honestos por longos períodos. Esse vetor de ataque não está presente (ou pelo
menos não é tão óbvio) no Bitcoin.
Em resumo, embora alguns aspectos da arquitetura da Lightning Network sugiram que ela
representa um avanço em termos de privacidade em comparação com o Bitcoin, outras
propriedades do protocolo podem facilitar ataques à privacidade. Pesquisas minuciosas são
necessárias para avaliar quais garantias de privacidade a Lightning Network oferece e melhorar o
estado das coisas.
As questões discutidas nesta parte do capítulo resumem as pesquisas disponíveis mid-2021. No

entanto, esta área de pesquisa e desenvolvimento está crescendo rapidamente. Ficamos felizes em
informar que os autores estão cientes de várias equipes de pesquisa que atualmente estão
trabalhando na privacidade da Lightning Network.
Agora vamos revisar alguns dos ataques à privacidade da LN que foram descritos na literatura
acadêmica.
Ataques à Lightning
Pesquisas recentes descrevem várias maneiras pelas quais a segurança e privacidade da Lightning
Network podem ser comprometidas.
Observando Valores de Pagamento
Um dos objetivos de um sistema de pagamento que preserva a privacidade é ocultar de partes não
5
envolvidas o valor do pagamento. A Lightning Network é uma melhoria em relação à Camada 1
(Layer 1) nesse aspecto. Enquanto as transações de Bitcoin são transmitidas em texto claro e podem
ser observadas por qualquer pessoa, os pagamentos na Lightning Network viajam apenas por
alguns nós ao longo do caminho do pagamento. No entanto, os nós intermediários veem o valor do
pagamento, embora esse valor do pagamento possa não corresponder ao valor total real do
pagamento (veja [mpp]). Isso é necessário para criar um novo HTLC a cada salto. A disponibilidade
dos valores dos pagamentos para os nós intermediários não representa uma ameaça imediata. No
entanto, um nó intermediário que seja honesto, mas curioso pode usá-lo como parte de um ataque
maior.
Vinculando Remetentes e Destinatários
Um atacante pode estar interessado em descobrir o remetente e/ou o destinatário de um pagamento

para revelar certas relações econômicas. Essa violação de privacidade pode prejudicar a resistência
à censura, pois um nó intermediário pode censurar pagamentos para ou de determinados
destinatários ou remetentes. Idealmente, vincular remetentes a destinatários não deveria ser
possível para ninguém além do remetente e do destinatário.
Nas seções a seguir, vamos considerar dois tipos de adversários: o adversário fora do caminho (off-
path) e o adversário no caminho (on-path). Um adversário fora do caminho (off-path) tenta
identificar o remetente e o destinatário de um pagamento sem participar do processo de
roteamento do pagamento. Um adversário no caminho (on-path) pode aproveitar qualquer
informação que possa obter ao rotear o pagamento de interesse.
Primeiro, vamos considerar o adversário fora-do-caminho (off-path). No primeiro passo desse

cenário de ataque, um adversário-fora-do-caminho poderoso deduz os saldos individuais em cada
canal de pagamento por meio de sondagem (descrito em uma seção subsequente) e forma uma
imagem instantânea da rede no momento t1. Para simplificar, vamos considerar t1 igual a 12:05. Em
seguida, o adversário realiza sondagens na rede novamente em um momento posterior t2, que
consideraremos como 12:10. O atacante, então, compara as imagens instantâneas às 12:10 ae 12:05
e usa as diferenças entre as duas imagens para inferir informações sobre os pagamentos que
ocorreram, observando os caminhos que foram alterados. No caso mais simples, se apenas um
pagamento ocorreu entre 12:10 e 12:05, o adversário observaria um único caminho em que os
saldos tenham sido alterados pelos mesmos valores. Assim, o adversário aprende praticamente
tudo sobre esse pagamento: o remetente, o destinatário e o valor. Se vários caminhos de pagamento
se sobrepõem, o adversário precisa aplicar heurísticas para identificar essa sobreposição e separar
os pagamentos.
Agora, vamos direcionar nossa atenção para um adversário no-caminho (on-path). Um adversário
desse tipo pode parecer complexo. No entanto, em junho de 2020, pesquisadores perceberam que o
nó único mais central observed cerca de 50% de todos os pagamentos na LN, enquanto os quatro
nós mais centrais observed em média 72% dos pagamentos.. Essas descobertas enfatizam a
relevância do modelo de atacante no caminho (on-path). Mesmo que os intermediários em um
caminho de pagamento saibam sobre apenas seu sucessor e predecessor, existem vários
vazamentos que um nó intermediário malicioso ou honesto, mas curioso, pode usar para inferir o
remetente e o destinatário.
O adversário no-caminho pode observar o valor de qualquer pagamento roteado, bem como os
intervalos de tempo (timelock deltas) (veja [onion_routing]). Portanto, o adversário pode excluir
6
qualquer nó do conjunto de anonimato do remetente ou do destinatário com capacidades inferiores
ao valor roteado. Portanto, observamos um trade-off (troca) entre privacidade e valores de
pagamento. Normalmente, quanto maior for o valor do pagamento, menores serão os conjuntos de
anonimato. Observamos que esse vazamento poderia ser minimizado com pagamentos multipartes
ou com canais de pagamento de grande capacidade. Da mesma forma, os canais de pagamento com
pequenos deltas de timelock poderiam ser excluídos de um caminho de pagamento. Mais
precisamente, um canal de pagamento não pode ser utilizado para um pagamento se o tempo
restante em que o pagamento pode ficar bloqueado for maior do que o que o nó intermediário
estaria disposto a aceitar. Essa possibilidade de vazamento pode ser evitada ao aderir às chamadas
rotas sombra.
Um dos vazamentos mais sutis e poderosos que um adversário no-caminho pode promover é a
análise de tempo. Um adversário no-caminho pode manter um log (registro) para cada pagamento
roteado, juntamente com a quantidade de tempo que leva para um nó responder a uma solicitação
HTLC. Antes de iniciar o ataque, o invasor aprende as características de latência de cada nó na
Lightning Network enviando solicitações a eles. Naturalmente, isso pode ajudar a determinar a
posição exata do adversário no caminho de pagamento. Além disso, como foi demonstrado
recentemente, um atacante pode determinar com sucesso o remetente e o destinatário de um
pagamento a partir de um conjunto de remetentes e destinatários possíveis usando estimadores
baseados em tempo.
Por fim, é importante reconhecer que vazamentos desconhecidos ou não estudados provavelmente
existem e podem ajudar nas tentativas de desanonimização. Por exemplo, como diferentes carteiras
da Lightning aplicam algoritmos de roteamento diferentes, mesmo saber qual algoritmo de
roteamento é aplicado pode ajudar a excluir certos nós como remetentes e/ou destinatários de um
pagamento.
Revelando Saldos de Canal (Sondagem)
Os saldos dos canais da Lightning são feitos para serem ocultados por motivos de privacidade e
eficiência. Um nó da Lightning só conhece os saldos dos canais adjacentes a ele. O protocolo não
fornece uma maneira padrão de consultar o saldo de um canal remoto.
No entanto, um atacante pode revelar o saldo de um canal remoto em um ataque de sondagem

(probing attack). Na segurança da informação, sondagem se refere à técnica de enviar solicitações a
um sistema alvo e tirar conclusões sobre seu estado privado com base nas respostas recebidas.
Os canais da Lightning são propensos a sondagem. Lembre-se de que um pagamento padrão na

Lightning começa com o destinatário criando um segredo de pagamento aleatório e enviando seu
hash para o remetente. Observe que, para os nós intermediários, todos os hashes parecem
aleatórios. Não há como saber se um hash corresponde a um segredo real ou foi gerado
aleatoriamente.
O ataque de sondagem procede da seguinte maneira. Digamos que o atacante Mallory queira
revelar o saldo de Alice em um canal público entre Alice e Bob. Suponha que a capacidade total
desse canal seja de 1 milhão de satoshis. O saldo de Alice pode ser qualquer valor entre zero e 1
milhão de satoshis (para ser preciso, a estimativa é um pouco mais apertada devido à reserva do
canal, mas não levamos isso em consideração aqui para simplificar). Mallory abre um canal com
Alice com 1 milhão de satoshis e envia 500.000 satoshis para Bob por meio de Alice, usando um
7
número aleatório como o hash do pagamento. É claro que esse número não corresponde a nenhum
segredo de pagamento conhecido. Portanto, o pagamento falhará. A pergunta é: como exatamente o
pagamento falhará?
Existem dois cenários. Se Alice tiver mais de 500.000 satoshis em seu lado do canal para Bob, ela
encaminha o pagamento. Bob descriptografa a cebola de pagamento e percebe que o pagamento é
destinado a ele. Ele verifica sua lista local de segredos de pagamento e procura pela pré-imagem
que corresponde ao hash do pagamento, mas não encontra nenhum. Seguindo o protocolo, Bob
retorna o erro "hash de pagamento desconhecido" (unknown payment hash) para Alice, que o
repassa para Mallory. Como resultado, Mallory sabe que o pagamento poderia ter sido bem-sucedido
se o hash de pagamento fosse real. Portanto, Mallory pode atualizar sua estimativa do saldo de
Alice de "entre zero e 1 milhão" para "entre 500.000 e 1 milhão". Outro cenário acontece se o saldo
de Alice for inferior a 500.000 satoshis. Nesse caso, Alice não consegue encaminhar o pagamento e
retorna o erro "saldo insuficiente" para Mallory. Mallory atualiza sua estimativa de "entre zero e 1
milhão" para "entre zero e 500.000".
Observe que, em qualquer caso, a estimativa de Mallory se torna duas vezes mais precisa após
apenas uma sondagem! Ela pode continuar sondando, escolhendo a próxima quantidade de
sondagem de modo que divida o intervalo de estimativa atual pela metade. <a id="__indexterm-22"
type="indexterm"></a>Esta técnica de pesquisa bem conhecida é chamada de busca
binária (binary search). Com a pesquisa binária, o número de sondagens é
logarítmico na precisão desejada. Por exemplo, para obter o saldo de Alice em um canal
de 1 milhão de satoshis até um único satoshi, Mallory só teria que realizar log2
(1,000,000) ≈ 20 sondagens. Se uma sondagem leva 3 segundos, um canal pode ser sondado
com precisão em apenas cerca de um minuto!
A sondagem do canal pode ser ainda mais eficiente. Em sua variante mais simples, Mallory se
conecta diretamente ao canal que deseja sondar. É possível sondar um canal sem abrir um canal
para um de seus pontos finais (endpoints)? Imagine que agora Mallory quer sondar um canal entre
Bob e Charlie, mas não quer abrir outro canal, o que requer o pagamento de taxas on-chain e a
espera pela confirmação das transações de financiamento. Em vez disso, Mallory reutiliza seu canal
existente para Alice e envia uma sonda ao longo da rota Mallory → Alice → Bob → Charlie. Mallory
pode interpretar o erro de "hash de pagamento desconhecido" da mesma forma que antes: a
sondagem alcançou o destino; portanto, todos os canais ao longo da rota têm saldos suficientes para
encaminhá-la. Mas e se Mallory receber o erro "saldo insuficiente" (insufficient balance)? Isso
significa que o saldo é insuficiente entre Alice e Bob, ou entre Bob e Charlie?
No protocolo Lightning atual, as mensagens de erro relatam não apenas qual erro ocorreu, mas
também onde ele ocorreu. Assim, com um tratamento de erros mais cuidadoso, Mallory agora sabe
qual canal falhou. Se este for o canal de destino, ela atualiza suas estimativas; caso contrário, ela
escolhe outra rota para o canal de destino. Ela ainda obtém informações adicionais sobre os saldos
dos canais intermediários, além do canal de destino.
O ataque de sondagem pode ainda ser usado para vincular remetentes e receptores, conforme
descrito na seção anterior.
Neste ponto, você pode se perguntar: por que a Lightning Network faz um trabalho tão ruim na
proteção dos dados privados de seus usuários? Não seria melhor não revelar ao remetente por que
e onde o pagamento falhou? Na verdade, esta poderia ser uma contramedida potencial, mas tem
8
desvantagens significativas. A Lightning precisa encontrar um equilíbrio cuidadoso entre
privacidade e eficiência. Lembre-se de que os nós regulares não conhecem as distribuições de saldo
em canais remotos. Portanto, os pagamentos podem falhar (e geralmente falham) devido ao saldo
insuficiente em um salto intermediário. As mensagens de erro permitem que o remetente exclua o
canal com falha da consideração ao construir outra rota. Uma popular carteira Lightning até
realiza sondagens internamente para verificar se uma rota construída pode realmente lidar com
um pagamento.
Existem outras contramedidas potenciais contra sondagem de canal. Primeiro, é difícil para um
invasor mirar canais não anunciados. Em segundo lugar, os nós que implementam o roteamento
just-in-time (JIT) podem ser menos propensos ao ataque. Finalmente, como os pagamentos
multipartes tornam o problema da capacidade insuficiente menos grave, os desenvolvedores do
protocolo podem considerar ocultar alguns detalhes do erro sem prejudicar a eficiência.
Negação de Serviço
Quando recursos são disponibilizados publicamente, há o risco de que invasores possam tentar
tornar esse recurso indisponível executando um ataque de negação-de-serviço (DoS). Geralmente,
isso é alcançado pelo invasor bombardeando um recurso com solicitações, que são indistinguíveis
de consultas legítimas. Os ataques raramente resultam em perda financeira do alvo, além do custo
de oportunidade de seu serviço estar fora do ar, e têm apenas a intenção de afligir o alvo.
As mitigações típicas para ataques DoS exigem autenticação para solicitações a fim de separar os
usuários legítimos dos mal-intencionados. Essas mitigações implicam um custo trivial para os
usuários regulares, mas atuarão como um desestímulo suficiente para um invasor que lança
solicitações em grande escala. Medidas anti-negação de serviço podem ser vistas em toda a
internet—sites aplicam limites de taxa para garantir que nenhum usuário possa consumir toda a
atenção de seu servidor, sites de críticas de filmes exigem autenticação de login para manter
afastados os membros irritados do r/prequelmemes (grupo Reddit), e serviços de dados vendem
chaves de API para limitar o número de consultas.
DoS em bitcoin
No Bitcoin, a largura de banda que os nós usam para transmitir transações e o espaço que
disponibilizam para a rede na forma de seu mempool são recursos disponíveis publicamente.
Qualquer nó na rede pode consumir largura de banda e espaço de mempool enviando uma
transação válida. Se essa transação for minerada em um bloco válido, eles pagarão taxas de
transação, o que adiciona um custo ao uso desses recursos de rede compartilhados.
No passado, a rede Bitcoin enfrentou uma tentativa de ataque DoS, onde os invasores enviaram
spam à rede com transações de baixa taxa. Muitas dessas transações não foram selecionadas pelos
mineradores devido às suas baixas taxas de transação, permitindo que os atacantes consumissem
recursos da rede sem pagar as taxas. Para lidar com esse problema, foi estabelecida uma taxa
mínima de retransmissão de transações, que define uma taxa limite que os nós exigem para
propagar transações. Essa medida garantiu amplamente que as transações que consomem recursos
de rede acabarão por pagar suas taxas de cadeia (chain fees). A taxa mínima de retransmissão é
aceitável para usuários regulares, mas prejudicaria financeiramente os invasores se eles tentassem
enviar spam para a rede. Embora algumas transações possam não ser incluídas em blocos válidos
em ambientes de altas taxas, essas medidas têm sido amplamente eficazes em dissuadir esse tipo de
9
spam.
DoS n Lightning
Da mesma forma que o Bitcoin, a Lightning Network cobra taxas pelo uso de seus recursos
públicos, mas, neste caso, os recursos são os canais públicos e as taxas são cobradas na forma de
taxas de roteamento. A capacidade de rotear pagamentos através dos nós em troca de taxas
proporciona à rede um grande benefício de escalabilidade—nós que não estão diretamente
conectados ainda podem realizar transações—mas isso ocorre ao custo de expor um recurso
público que deve ser protegido contra ataques de negação de serviço (DoS).
Quando um nó da Lightning encaminha um pagamento em seu nome, ele utiliza dados e largura de
banda de pagamento para atualizar sua transação de compromisso, e o valor do pagamento é
reservado em seu saldo do canal até que seja liquidado ou falhe. Em pagamentos bem-sucedidos,
isso é aceitável porque o nó acaba pagando suas taxas. Pagamentos fracassados não incorrem em
taxas no protocolo atual. Isso permite que os nós encaminhem pagamentos com falha sem custos
através de qualquer canal. Isso é ótimo para os usuários legítimos, que não gostariam de pagar por
tentativas malsucedidas, mas também permite que os atacantes consumam os recursos dos nós sem
custos—assim como as transações de baixa taxa no Bitcoin que acabam nunca pagando as taxas dos
mineradores.
No momento da escrita, uma discussão está em andamento ongoing na lista de discussão lightning-
dev sobre a melhor maneira de lidar com essa questão.
Ataques DoS Conhecidos
Existem dois ataques de negação de serviço (DoS) conhecidos em canais públicos da LN que tornam
um canal de destino ou um conjunto de canais de destino inutilizáveis. Ambos os ataques envolvem
o encaminhamento de pagamentos por meio de um canal público e, em seguida, mantendo-os até o
tempo limite, maximizando assim a duração do ataque. O requisito de falhar os pagamentos para
não pagar taxas é bastante simples de ser atendido, pois nós maliciosos podem simplesmente
redirecionar os pagamentos para si mesmos. Na ausência de taxas para pagamentos falhos, o único
custo para o atacante é o custo on-chain de abrir um canal para despachar esses pagamentos, o que
pode ser trivial em ambientes com taxas baixas.
Commitment Jamming
Os nós da Lightning atualizam seu estado compartilhado usando transações de compromisso

assimétricas, nas quais HTLCs (Hashed Time-Locked Contracts) são adicionados e removidos para
facilitar pagamentos. Cada parte está limitada a um total de 483 HTLCs na transação de
compromisso por vez. Um ataque de congestionamento (jamming) de canal permite que um
atacante torne um canal inutilizável ao encaminhar 483 pagamentos através do canal alvo e
mantendo-os até que eles expirem.
É importante observar que esse limite foi escolhido nas especificações para garantir que todos os
HTLCs possam ser resgatados em uma single justice transaction (transação de justiça única).
Embora esse limite possa ser aumentado, as transações ainda são limitadas pelo tamanho do bloco,
portanto, o número de slots disponíveis provavelmente permanecerá limitado.
10
Bloqueio de Liquidez do Canal
Um ataque de bloqueio de liquidez de canal é comparável a um ataque de obstrução (jamming) de

canal, pois direciona os pagamentos por meio de um canal e os mantém de forma que o canal fique
inutilizável. Em vez de bloquear slots no compromisso do canal, esse ataque roteia grandes HTLCs
por meio de um canal de destino, consumindo toda a largura de banda disponível do canal. O
compromisso de capital deste ataque é maior do que o ataque de obstrução (jamming) de
compromisso, pois o nó atacante precisa de mais fundos para rotear pagamentos falhados pelo
alvo.
Desanonimização Entre Camadas

Redes de computadores são frequentemente estruturadas em camadas. A estrutura em camadas
permite a separação de preocupações (separation of concerns) e torna todo o sistema gerenciável.
Ninguém conseguiria projetar um site se fosse necessário entender toda a pilha TCP/IP, incluindo a
codificação física dos bits em um cabo óptico. Cada camada deve fornecer a funcionalidade para a
camada acima de uma maneira limpa. Idealmente, a camada superior deve perceber uma camada
inferior como uma caixa preta. Na realidade, porém, as implementações não são ideais e os
detalhes vazam para a camada superior. Esse é o problema das abstrações vazadas (leaky
abstractions).
No contexto do Lightning, o protocolo LN depende do protocolo Bitcoin e da rede P2P LN. Até este
ponto, consideramos apenas as garantias de privacidade oferecidas pela Lightning Network de
forma isolada. No entanto, a criação e o fechamento de canais de pagamento são inerentemente
executados na blockchain do Bitcoin. Consequentemente, para uma análise completa das provisões
de privacidade da Lightning Network, é preciso considerar cada camada da pilha tecnológica com a
qual os usuários podem interagir. Especificamente, um adversário de desanonimização pode e irá
usar dados fora da cadeia (off-chain) e dentro da cadeia (on-chain) para agrupar ou vincular nós da
Lightning Network (LN) aos respectivos endereços do Bitcoin.
Atacantes que tentam desanonimizar usuários da LN podem ter diversos objetivos, em um contexto
de múltiplas camadas:
• Agrupar endereços Bitcoin pertencentes ao mesmo usuário (Camada 1). Chamamos esses
entidades Bitcoin.
• Agrupar nós da LN pertencentes ao mesmo usuário (Camada 2).
• Vincular de forma inequívoca conjuntos de nós da LN aos conjuntos de entidades Bitcoin que os
controlam.
Existem várias heurísticas e padrões de uso que permitem a um adversário agrupar endereços
Bitcoin e nós da LN pertencentes aos mesmos usuários da LN. Além disso, esses agrupamentos
podem ser vinculados entre camadas usando outras heurísticas de vinculação entre camadas
poderosas. O último tipo de heurísticas, técnicas de vinculação entre camadas, enfatiza a
necessidade de uma visão holística da privacidade. Especificamente, devemos considerar a
privacidade no contexto de ambas as camadas juntas.
11
Agrupamento de Entidades Bitcoin On-Chain
As interações da Lightning Network com a blockchain são permanentemente refletidas no grafo das
entidades Bitcoin. Mesmo que um canal seja fechado, um atacante pode observar qual endereço
financiou o canal e para onde as moedas são enviadas após o seu fechamento. Para esta análise,
vamos considerar quatro entidades separadas. Abrir um canal causa um fluxo monetário de uma
entidade de origem (source entity) para uma entidade de financiamento (funding entity); fechar um
canal causa um fluxo de uma entidade de liquidação (settlement entity) para uma entidade de
destino (destination entity).
No início de 2021, Romiti et al. identificou quatro heurísticas que permitem o agrupamento dessas
entidades. Duas delas capturam certos comportamentos de vazamento de financiamento e as
outras duas descrevem comportamentos de vazamento de liquidação.
Heurística de estrela (financiamento)

Se um componente contém uma entidade de origem que encaminha fundos para uma ou mais
entidades de financiamento, é provável que essas entidades de financiamento sejam controladas
pelo mesmo usuário. Heurística da serpente (financiamento): Se um componente contém uma
entidade de origem que encaminha fundos para uma ou mais entidades, que por sua vez são
usadas como entidades de origem e financiamento, então é provável que todas essas entidades
sejam controladas pelo mesmo usuário. Heurística do coletor (liquidação): Se um componente
contém uma entidade de destino que recebe fundos de uma ou mais entidades de liquidação, é
provável que essas entidades de liquidação sejam controladas pelo mesmo usuário. Heurística
de proxy (liquidação): Se um componente contém uma entidade de destino que recebe fundos de
uma ou mais entidades, que por sua vez são usadas como entidades de liquidação e destino,
então é provável que essas entidades sejam controladas pelo mesmo usuário.
Vale ressaltar que essas heurísticas podem produzir resultados falsos positivos. Por exemplo, se as
transações de vários usuários não relacionados forem combinadas em uma transação CoinJoin,
então a heurística da estrela ou do proxy podem produzir resultados falsos positivos. Isso pode
acontecer se os usuários estiverem financiando um canal de pagamento a partir de uma transação
CoinJoin. Outra possível fonte de falsos positivos poderia ser o fato de uma entidade poder
representar vários usuários se os endereços agrupados forem controlados por um serviço (por
exemplo, uma corretora) ou em nome de seus usuários (carteira custodial). No entanto, esses falsos
positivos podem ser filtrados de forma eficaz.
======= Contramedidas Se as saídas das transações de financiamento não forem reutilizadas para
abrir outros canais, a heurística da serpente não funcionará. Se os usuários evitassem financiar
canais de uma única fonte externa e evitassem arrecadar fundos em uma única entidade externa
de destino, as outras heurísticas não produziriam resultados significativos.
Agrupamento de Nós da Lightning Off-Chain
Os nós da LN anunciam apelidos, por exemplo, LNBig.com. Aliases podem melhorar a usabilidade
do sistema. No entanto, os usuários tendem a usar apelidos semelhantes para seus próprios nós
diferentes. Por exemplo, é provável que LNBig.com Billing seja de propriedade do mesmo usuário
que o nó com o alias LNBig.com. Com base nessa observação, é possível agrupar nós da LN
aplicando seus apelidos de nó. Especificamente, os nós da LN são agrupados em um único endereço
se seus apelidos (aliases) forem semelhantes com relação a uma determinada métrica de
12
similaridade de strings.
Outro método para agrupar nós da LN é aplicar seus endereços IP ou endereços do Tor. Se o mesmo
endereço IP ou endereço do Tor corresponder a diferentes nós da LN, é provável que esses nós
sejam controlados pelo mesmo usuário.
======= Contramedidas Para obter mais privacidade, os apelidos devem ser suficientemente
diferentes uns dos outros. Embora a divulgação pública de endereços IP possa ser inevitável para os
nós que desejam ter canais de entrada na Lightning Network, a possibilidade de rastreamento entre
nós do mesmo usuário pode ser mitigada se os clientes de cada nó forem hospedados com
diferentes provedores de serviços e, portanto, diferentes endereços IP.
Vinculação entre Camadas: Nós da Lightning e Entidades Bitcoin
Associar nós da LN a entidades Bitcoin é uma séria violação da privacidade, que é agravada pelo
fato de que a maioria dos nós da LN expõem publicamente seus endereços IP. Tipicamente, um
endereço IP pode ser considerado como um identificador único de um usuário. Dois padrões de
comportamento amplamente observados revelam conexões entre nós da LN e entidades Bitcoin:
Reutilização de moeda
Sempre que os usuários fecham canais de pagamento, eles recebem de volta as moedas
correspondentes. No entanto, muitos usuários reutilizam essas moedas ao abrir um novo canal.
Essas moedas podem ser efetivamente vinculadas a um nó comum da LN.
Reutilização de entidades: Normalmente, os usuários financiam seus canais de pagamento a partir

de endereços Bitcoin correspondentes à mesma entidade Bitcoin.
Esses algoritmos de vinculação entre camadas podem ser dificultados se os usuários possuírem
vários endereços não agrupados ou utilizarem várias carteiras para interagir com a Lightning
Network.
A possível desanonimização das entidades Bitcoin ilustra a importância de considerar a

privacidade de ambas as camadas simultaneamente, em vez de uma por vez.
Grafo Lightning
A Lightning Network, como o nome sugere, é uma rede ponto-a-ponto de canais de pagamento.
Portanto, muitas de suas propriedades (privacidade, robustez, conectividade, eficiência de
roteamento) são influenciadas e caracterizadas pela sua natureza de rede.
Nesta seção, discutimos e analisamos a Lightning Network sob a perspectiva da ciência das redes.
Estamos particularmente interessados em compreender o grafo de canais da LN, sua robustez,
conectividade e outras características importantes.
Como o Grafo LN Se Parece na realidade?
Poderíamos esperar que a Lightning Network seja um grafo aleatório, no qual as arestas são
formadas aleatoriamente entre os nós. Se esse fosse o caso, então a distribuição de graus da
Lightning Network seguiria uma distribuição normal Gaussiana. Em particular, a maioria dos nós
13
teria aproximadamente o mesmo grau e não esperaríamos nós com graus extraordinariamente
grandes. Isso ocorre porque a distribuição normal diminui exponencialmente para valores fora do
intervalo em torno do valor médio da distribuição. A representação de um grafo aleatório (como
vimos na [lngraph]) se assemelha a uma topologia de rede em malha. Parece descentralizado e não
hierárquico: cada nó parece ter a mesma importância. Além disso, os grafos aleatórios têm um
grande diâmetro. Especificamente, o roteamento em tais grafos é desafiador porque o caminho
mais curto entre quaisquer dois nós é moderadamente longo.
No entanto, em contraste marcante, o grafo LN é completamente diferente.
Grafo LN hoje
Lightning é uma rede financeira. Assim, o crescimento e a formação da rede também são
influenciados por incentivos econômicos. Sempre que um nó se junta à Lightning Network, ele
pode querer maximizar sua conectividade com outros nós para aumentar sua eficiência de
roteamento. Esse fenômeno é chamado de preferência por conexões (preferential attachment, ou
apego preferencial). Esses incentivos econômicos resultam em uma rede fundamentalmente
diferente de um grafo aleatório.
Com base em capturas de canais publicamente anunciados, a distribuição de grau da Lightning

Network segue uma função de lei de potência (power-law function). Em tal grafo, a grande maioria
dos nós possui poucas conexões com outros nós, enquanto apenas um punhado de nós possui
numerosas conexões. Em um nível mais amplo, essa topologia de grafo se assemelha a uma estrela:
a rede possui um núcleo bem conectado e uma periferia com conexões mais fracas. Redes com
distribuição de grau em lei de potência também são chamadas de redes livres de escala. Essa
topologia é vantajosa para o roteamento de pagamentos de forma eficiente, mas propensa a certos
ataques baseados na topologia.
======= Ataques baseados em topologia
Um adversário pode querer perturbar a Lightning Network e decidir que seu objetivo é
desmantelar toda a rede em vários componentes menores, tornando o roteamento de pagamentos
praticamente impossível em toda a rede. Um objetivo menos ambicioso, mas ainda malicioso e
grave, poderia ser derrubar apenas determinados nós da rede. Essa interrupção pode ocorrer tanto
no nível dos nós quanto no nível das arestas.
Vamos supor que um adversário possa derrubar qualquer nó na Lightning Network. Por exemplo,
ele pode atacá-los com um ataque de negação de serviço distribuído (DDoS) ou torná-los não
operacionais de qualquer forma. Acontece que se o adversário escolher nós aleatoriamente, redes
livres de escala como a Lightning Network são robustas contra ataques de remoção de nós. Isso
ocorre porque um nó aleatório está localizado na periferia com um pequeno número de conexões,
portanto, desempenhando um papel insignificante na conectividade da rede. No entanto, se o
adversário for mais cauteloso, ele pode mirar nos nós mais bem conectados. Não
surpreendentemente, a Lightning Network e outras redes livres de escala não são robustas contra
ataques direcionados de remoção de nós.
Por outro lado, o adversário poderia ser mais furtivo. Vários ataques baseados em topologia visam
um único nó ou um único canal de pagamento. Por exemplo, um adversário pode estar interessado
em esgotar propositadamente a capacidade de um determinado canal de pagamento. Mais
14
geralmente, um adversário pode esgotar toda a capacidade de saída de um nó para excluí-lo do
mercado de roteamento. Isso poderia ser facilmente obtido roteando pagamentos através do nó
alvo com valores equivalentes à capacidade de saída de cada canal de pagamento. Após concluir
esse chamado ataque de isolamento de nó, a vítima não pode mais enviar ou rotear pagamentos, a
menos que receba um pagamento ou reequilibre seus canais.
Para concluir, mesmo por design, é possível remover arestas e nós da rede roteável da Lightning
Network. No entanto, dependendo do vetor de ataque utilizado, o adversário pode ter que fornecer
mais ou menos recursos para realizar o ataque.
A Temporalidade da Lightning Network.
A Lightning Network é uma rede dinamicamente em constante mudança, sem permissões. Os nós
podem livremente entrar ou sair da rede, eles podem abrir e criar canais de pagamento a qualquer
momento que desejarem. Portanto, uma única captura estática do grafo da LN é enganosa.
Precisamos considerar a temporalidade e a natureza em constante mudança da rede. No momento,
o grafo da LN está crescendo em termos do número de nós e canais de pagamento. Seu diâmetro
efetivo também está diminuindo; ou seja, os nós estão se aproximando uns dos outros, como
podemos ver na O crescimento constante da Lightning Network em nós, canais e capacidade
bloqueada (até setembro de 2021).
Figure 2. O crescimento constante da Lightning Network em nós, canais e capacidade bloqueada (até
setembro de 2021)
Nas redes sociais, é comum ocorrer o fechamento de triângulos. Especificamente, em um grafo

onde os nós representam pessoas e as amizades são representadas como arestas, é esperado que
triângulos surjam no grafo. Um triângulo, nesse caso, representa amizades entre três pessoas em
pares. Por exemplo, se Alice conhece Bob e Bob conhece Charlie, é provável que em algum
momento Bob apresente Alice a Charlie. No entanto, esse comportamento seria estranho na
Lightning Network. Os nós simplesmente não são incentivados a fechar triângulos, pois eles
15
poderiam simplesmente ter roteado pagamentos em vez de abrir um novo canal de pagamento.
Surpreendentemente, o fechamento de triângulos é uma prática comum na Lightning Network. O
número de triângulos estava crescendo constantemente antes da implementação de pagamentos
multipartes. Isso é contraditório e surpreendente, considerando que os nós poderiam simplesmente
rotear pagamentos pelos dois lados do triângulo em vez de abrir o terceiro canal. Isso pode
significar que as ineficiências de roteamento incentivaram os usuários a fechar triângulos e não
recorrer ao roteamento. Esperamos que os pagamentos multipartes ajudem a aumentar a eficácia
do roteamento de pagamentos..
Centralização na Rede Lightning

Uma métrica comum para avaliar a centralidade de um nó em um grafo é a sua centralidade de
intermediação (betweenness centrality). A dominância do ponto central é uma métrica derivada da
centralidade de intermediação, usada para avaliar a centralidade de uma rede. Para uma definição
precisa de dominância do ponto central, o leitor é encaminhado para Freeman’s work.
Quanto maior for a dominância do ponto central de uma rede, mais centralizada a rede será.
Podemos observar que a Lightning Network tem uma dominância maior do ponto central (ou seja,
é mais centralizada) do que um grafo aleatório (grafo Erdős–Rényi) ou um grafo livre de escala
(grafo Barabási–Albert) de tamanho igual.
De forma geral, nosso entendimento sobre a natureza dinâmica do grafo de canais da LN é bastante
limitado. É frutífero analisar como as mudanças de protocolo, como os pagamentos multipartes,
podem afetar a dinâmica da Lightning Network. Seria benéfico explorar de forma mais
aprofundada a natureza temporal do grafo da LN.
Incentivos Econômicos e Estrutura do Grafo

O grafo da LN se forma espontaneamente, e os nós se conectam uns aos outros com base em
interesse mútuo. Como resultado, os incentivos impulsionam o desenvolvimento do grafo. Vejamos
alguns dos incentivos relevantes:
• Incentivos racionais:
◦ Os nós estabelecem canais para enviar, receber e encaminhar pagamentos (ganhar taxas).
◦ O que torna mais provável que um canal seja estabelecido entre dois nós que agem
racionalmente?
• Incentivos altruístas:
◦ Os nós estabelecem canais "para o bem da rede".
◦ Embora não devamos basear nossas suposições de segurança no altruísmo, até certo ponto,
o comportamento altruístico impulsiona o Bitcoin (aceitando conexões de entrada, servindo
blocos).
◦ Que papel isso desempenha na Lightning?
Nas primeiras fases da Lightning Network, muitos operadores de nós afirmaram que as taxas de
roteamento obtidas não compensam os custos de oportunidade decorrentes do bloqueio de
liquidez. Isso indicaria que operar um nó pode ser impulsionado principalmente por incentivos
16
altruístas "em prol do bem da rede". Isso pode mudar no futuro se a Lightning Network tiver um
tráfego significativamente maior ou se surgir um mercado para taxas de roteamento. Por outro
lado, se um nó deseja otimizar suas taxas de roteamento, ele minimizaria os comprimentos médios
de caminho mais curto para todos os outros nós. Em outras palavras, um nó que busca lucro
tentará se posicionar no centro do grafo de canais ou próximo a ele.
Conselhos Práticos para os Usuários Protegerem Sua

Privacidade
Ainda estamos nas fases iniciais da Lightning Network. Muitas das preocupações listadas neste
capítulo provavelmente serão abordadas à medida que ela amadurece e cresce. Enquanto isso,
existem algumas medidas que você pode tomar para proteger seu nó contra usuários maliciosos;
algo tão simples quanto atualizar os parâmetros padrão com os quais seu nó é executado pode ser
muito eficaz para fortalecer seu nó.
Canais Não Anunciados

Se você pretende usar a Lightning Network para enviar e receber fundos entre nós e carteiras que
você controla e não tem interesse em rotear pagamentos de outros usuários, não há muita
necessidade de anunciar seus canais para o restante da rede. Você pode abrir um canal entre, por
exemplo, seu computador desktop executando um nó completo e seu celular executando uma
carteira Lightning, e simplesmente abrir mão do anúncio do canal discutido no
[ch03_How_Lightning_Works]. Esses canais são às vezes chamados de canais "privados", mas é mais
correto se referir a eles como canais "não anunciados" porque eles não são estritamente privados.
Os canais não anunciados não serão conhecidos pelo restante da rede e normalmente não serão
usados para encaminhar pagamentos de outros usuários. Eles ainda podem ser usados para
encaminhar pagamentos se outros nós forem informados sobre eles; por exemplo, uma fatura pode
conter dicas de roteamento que sugerem um caminho com um canal não anunciado. No entanto,
supondo que você abriu um canal não anunciado apenas com você mesmo, você obtém uma certa
medida de privacidade. Como você não está expondo seu canal para a rede, você reduz o risco de
um ataque de negação de serviço em seu nó. Você também pode gerenciar mais facilmente a
capacidade desse canal, uma vez que ele será usado apenas para receber ou enviar diretamente
para o seu nó.
Existem também vantagens em abrir um canal não anunciado com uma parte conhecida com a
qual você realiza transações frequentemente. Por exemplo, se Alice e Bob frequentemente jogam
pôquer por bitcoin, eles podem abrir um canal para enviar suas vitórias de um lado para o outro.
Em condições normais, esse canal não será usado para encaminhar pagamentos de outros usuários
ou cobrar taxas. E uma vez que o canal não será conhecido pelo restante da rede, quaisquer
pagamentos entre Alice e Bob não podem ser inferidos rastreando as alterações na capacidade de
roteamento do canal. Isso confere certa privacidade a Alice e Bob; no entanto, se um deles decidir
tornar os outros usuários cientes do canal, como incluí-lo nas sugestões de roteamento (routing
hints) de uma fatura, então essa privacidade será perdida.
Também é importante mencionar que, para abrir um canal não anunciado, uma transação pública
deve ser feita na blockchain do Bitcoin. Portanto, é possível inferir a existência e o tamanho do
17
canal se uma parte mal-intencionada estiver monitorando a blockchain em busca de transações de
abertura de canal e tentando correspondê-las aos canais na rede. Além disso, quando o canal é
encerrado, o saldo final do canal será tornando público assim que for registrado na blockchain do
Bitcoin. No entanto, como as transações de abertura e compromisso são pseudônimas, não será
uma tarefa simples conectá-las de volta a Alice ou Bob. Além disso, a atualização Taproot de 2021
torna difícil distinguir entre transações de abertura e fechamento de canal e outros tipos
específicos de transações de Bitcoin. Portanto, embora os canais não anunciados não sejam
completamente privados, eles oferecem alguns benefícios em termos de privacidade quando
utilizados com cuidado.
Considerações de Roteamento
Como visto em Negação de Serviço, nós que abrem canais públicos se expõem ao risco de uma série
de ataques em seus canais. Embora estejam sendo desenvolvidas medidas de mitigação no nível do
protocolo, existem muitas etapas que um nó pode tomar para se proteger contra ataques de
negação de serviço em seus canais públicos:
Tamanho mínimo de HTLC: Ao abrir um canal, o seu nó pode definir o tamanho mínimo de HTLC
que ele aceitará. Definir um valor mais alto garante que cada um dos seus slots de canal disponíveis
não possa ser ocupado por um pagamento muito pequeno. Limitação de taxa: Muitas
implementações de nós permitem que os nós aceitem ou rejeitem dinamicamente os HTLCs que são
encaminhados por meio do seu nó. Algumas diretrizes úteis para um limitador de taxa
personalizado são as seguintes:
+ Limite o número de slots de compromisso que um único peer pode consumir 
Monitore as taxas de falha de um único peer e limite a taxa se suas falhas aumentarem
repentinamente. Canais de sombra: Nós que desejam abrir grandes canais para um único destino
podem, em vez disso, abrir um único canal público para o destino e apoiá-lo com outros canais
privados chamados <a href='https://anchor.fm/tales-from-the-crypt/episodes/197-Joost-Jager-
ekghn6'>canais de sombra</a>. Esses canais ainda podem ser usados para roteamento, mas não são
anunciados para possíveis atacantes.
Aceitando Canais
Atualmente, os nós Lightning enfrentam dificuldades em obter liquidez de entrada inicial. Embora
existam algumas soluções pagas para adquirir liquidez de entrada, como serviços de troca (swap),
mercados de canais e serviços pagos de abertura de canal de hubs conhecidos, muitos nós aceitarão
com prazer qualquer solicitação de abertura de canal que pareça legítima para aumentar sua
liquidez de entrada.
Voltando ao contexto do Bitcoin, isso pode ser comparado à forma como o Bitcoin Core trata suas
conexões de entrada e saída de forma diferente, com a preocupação de que o nó possa ser
eclipsado. Se um nó estabelece uma conexão de entrada com o seu nó Bitcoin, você não tem como
saber se o iniciador o selecionou aleatoriamente ou se está direcionando especificamente seu nó
com intenções maliciosas. Suas conexões de saída não precisam ser tratadas com tanta suspeita,
pois o nó pode ter sido selecionado aleatoriamente a partir de um conjunto de vários pares
potenciais ou você pode ter se conectado intencionalmente ao nó manualmente.
18
O mesmo pode ser dito na Lightning. Quando você abre um canal, é feito com intenção, mas
quando uma parte remota abre um canal para o seu nó, você não tem como saber se esse canal será
usado para atacar o seu nó ou não. Conforme observado em vários artigos, o custo relativamente
baixo de iniciar um nó e abrir canais para alvos é um dos principais fatores que facilitam os
ataques. Se você aceita canais de entrada, é prudente impor algumas restrições aos nós dos quais
você aceita canais de entrada. Muitas implementações expõem ganchos de aceitação de canal que
permitem personalizar as políticas de aceitação de canais de acordo com suas preferências.
A questão de aceitar ou rejeitar canais é uma questão filosófica. E se chegarmos a uma Rede
Relâmpago onde novos nós não possam participar porque não conseguem abrir nenhum canal?
Nossa sugestão é não definir uma lista exclusiva de "mega-hubs" dos quais você aceitará canais,
mas sim aceitar canais de uma maneira que se adeque às suas preferências de risco.
Algumas estratégias potenciais são:
Sem risco
Não aceite nenhum canal de entrada.
Baixo risco
Aceite canais de um conjunto conhecido de nós com os quais você já teve canais abertos com
sucesso.
Médio risco
Aceita apenas canais de nós que estão presentes no grafo por um período mais longo e possuem
alguns canais de longa duração. Maior risco: Aceite qualquer canal de entrada e implemente as
mitigações descritas em Considerações de Roteamento.
Conclusão
Em resumo, privacidade e segurança são assuntos complexos e com nuances, e embora muitos
pesquisadores e desenvolvedores estejam buscando melhorias em toda a rede, é importante que
todos que participam da rede entendam o que podem fazer para proteger sua própria privacidade e
aumentar a segurança em nível individual.
Referências e Leituras Adicionais

Neste capítulo, utilizamos várias referências de pesquisas em andamento sobre a segurança do
Lightning. Você pode encontrar artigos e trabalhos úteis listados por tópico nas seguintes listas:
Privacidade e ataques de sondagem
• Jordi Herrera-Joancomartí et al. "On the Difficulty of Hiding the Balance of Lightning Network
Channels". Asia CCS '19: Proceedings of the 2019 ACM Asia Conference on Computer and
Communications Security (July 2019): 602–612.
• Utz Nisslmueller et al. "Toward Active and Passive Confidentiality Attacks on Cryptocurrency
Off-Chain Networks." arXiv preprint, https://arxiv.org/abs/2003.00003 (2020).
• Sergei Tikhomirov et al. "Probing Channel Balances in the Lightning Network." arXiv preprint,
19
https://arxiv.org/abs/2004.00333 (2020).
• George Kappos et al. "An Empirical Analysis of Privacy in the Lightning Network." arXiv
preprint, https://arxiv.org/abs/2003.12470 (2021).
• Zap código-fonte com função de sondagem.
Ataques de congestionamento
• Ayelet Mizrahi and Aviv Zohar. "Congestion Attacks in Payment Channel Networks." arXiv
preprint, https://arxiv.org/abs/2002.06564 (2020).
Considerações de roteamento
• Marty Bent, interview with Joost Jager, Tales from the Crypt, podcast audio, October 2, 2020,
https://anchor.fm/tales-from-the-crypt/episodes/197-Joost-Jager-ekghn6.
20
Conclusão
Em apenas alguns anos, a Lightning Network passou de um artigo técnico (whitepaper) para uma
rede global em rápido crescimento. Como segunda camada do Bitcoin, ela cumpriu a promessa de
pagamentos rápidos, baratos e privados. Além disso, ela desencadeou uma tsunami de inovação,
permitindo que os desenvolvedores se libertem das restrições da marcha sincronizada, do consenso
rígido que existe no desenvolvimento do Bitcoin.
A inovação na Lightning Network está ocorrendo em diversos níveis:
• No protocolo principal do Bitcoin, fornecendo uso e demanda para novos opcodes Bitcoin
Script, algoritmos de assinatura e otimizações
• No nível do protocolo Lightning, com novos recursos (features) implantados rapidamente em

toda a rede
• No nível do canal de pagamento, com novas construções e aprimoramentos de canal
• Como recursos distintos de adesão opcional implantados de ponta a ponta por implementações
independentes, remetentes e destinatários podem utilizá-los caso desejem
• Com novos e empolgantes Aplicativos Lightning (LApps) construídos sobre os clientes e

protocolos
Vejamos como essas inovações estão mudando a Lightning agora e no futuro próximo.
Inovação Descentralizada e Assíncrona

A Lightning não está vinculada ao consenso rígido, como ocorre com o Bitcoin. Isso significa que
diferentes clientes da Lightning podem implementar recursos diferentes e negociar suas interações
(see [feature_bits]). Como resultado, a inovação na Lightning Network está ocorrendo em um ritmo
muito mais rápido do que no Bitcoin.
Não apenas a Lightning está avançando rapidamente, mas também está criando demanda por
novos recursos no sistema Bitcoin. Muitas inovações recentes e planejadas no Bitcoin são
motivadas e justificadas pelo seu uso na Lightning Network. De fato, a Lightning Network é
frequentemente mencionada como um exemplo de caso de uso para muitos dos novos recursos.
Inovações no Protocolo Bitcoin e Bitcoin Script
O sistema Bitcoin é, por necessidade, um sistema conservador que precisa preservar a

compatibilidade com as regras de consenso para evitar bifurcações não planejadas na blockchain
ou partições na rede P2P. Como resultado, novos recursos exigem muita coordenação e testes antes
de serem implementados na rede principal (mainnet), o sistema em produção.
Aqui estão algumas das inovações atuais ou propostas no Bitcoin que são motivadas pelos casos de
uso na Lightning Network:
Neutrino
Um protocolo de cliente leve com recursos aprimorados de privacidade em relação ao protocolo
SPV legado. O Neutrino é principalmente utilizado por clientes da Lightning para acessar a
1
Assinaturas Schnorr
Introduzidas como parte do soft fork Taproot, as assinaturas Schnorr permitirão contratos
flexíveis de Ponto Bloqueado no Tempo (Point Time-Locked Contracts, PTLCs) para a construção
de canais na Lightning. Isso pode, em particular, fazer uso de assinaturas revogáveis em vez de
transações revogáveis.
Taproot
Também faz parte do soft fork de novembro de 2021 que introduz as assinaturas Schnorr. O
Taproot permite que scripts complexos sejam visualizados como pagamentos de um único
pagador e um único beneficiário, indistinguíveis do tipo mais comum de pagamento no Bitcoin.
Isso permitirá que transações cooperativas (mútuas) de encerramento de canais da Lightning
sejam indistinguíveis de pagamentos simples e aumentará a privacidade dos usuários da LN.
Input rebinding
Religação de entrada, também conhecido pelos nomes SIGHAS_NOINPUT ou
SIGHASH_ANYPREVOUT, essa atualização planejada na linguagem Bitcoin Script é motivada
principalmente por contratos inteligentes avançados, como o protocolo de canal eltoo.
Covenants
Atualmente em estágios iniciais de pesquisa, os covenants permitem que transações criem
saídas que restrinjam transações futuras que as gastam. Esse mecanismo poderia aumentar a
segurança dos canais da Lightning, tornando possível impor listas de permissões de endereços
nas transações de compromisso.
Inovação no Protocolo Lightning
O protocolo ponto a ponto (P2P) da Lightning é altamente extensível e passou por muitas mudanças
desde sua criação. A regra "Está tudo bem em ser ímpar" usada nos feature bits (see [feature_bits])
garante que os nós possam negociar os recursos que suportam, possibilitando várias atualizações
independentes do protocolo.
Extensibilidade TLV
O mecanismo Type-Length-Value (Tipo-Comprimento-Valor) (veja [tlv]) para a extensão do

protocolo de mensagens é extremamente poderoso e já possibilitou a introdução de várias novas
capacidades na Lightning, enquanto mantendo tanto a compatibilidade progressiva (forward)
quanto retroativa (backward). Um exemplo proeminente, que está atualmente em desenvolvimento
e faz uso disso, é o embaralhamento de caminhos (path blinding) e pagamentos de trampolim
(trampoline payments). Isso permite que um destinatário se oculte do remetente, mas também
permite que clientes móveis enviem pagamentos sem a necessidade de armazenar o grafo completo
de canais em seus dispositivos, utilizando uma terceira parte à qual não precisam revelar o
destinatário final.
Construção do Canal de Pagamento
Os canais de pagamento são uma abstração operada por dois parceiros de canal. Desde que ambos
2
estejam dispostos a executar um novo código, eles podem implementar simultaneamente uma
variedade de mecanismos de canal. Na verdade, pesquisas recentes sugerem que os canais podem
até ser atualizados dinamicamente para um novo mecanismo, sem fechar o canal antigo e abrir um
novo tipo de canal.
eltoo
Um mecanismo de canal proposto que utiliza o input-rebinding (religação de entrada) para
simplificar significativamente a operação dos canais de pagamento e eliminar a necessidade do
mecanismo de penalidade. Ele requer um novo tipo de assinatura Bitcoin antes de poder ser
implementado.
Recursos de Ponta a Ponta com Adesão Opcional.
Contratos de Ponto Bloqueado no Tempo (Point Time-Locked Contracts, PTLCs)

Uma abordagem diferente em relação aos HTLCs, os PTLCs podem aumentar a privacidade,
reduzir as informações vazadas para os nós intermediários e operar de forma mais eficiente do
que os canais baseados em HTLCs.
Canais grandes
Canais grandes ou Wumbo foram introduzidos de forma dinâmica na rede sem exigir
coordenação. Canais que suportam pagamentos grandes são anunciados como parte das
mensagens de anúncio de canal e podem ser utilizados de forma opcional.
Pagamentos multipartes (Multipart Payments, MPP)

O MPP também foi introduzido de forma opcional, mas, ainda melhor, exige apenas que o
remetente e o destinatário de um pagamento usem o MPP. O restante da rede simplesmente
roteia os HTLCs como se fossem pagamentos de uma única parte.
Roteamento JIT (Just-In-Time): Um método opcional que pode ser usado pelos nós de roteamento
para aumentar sua confiabilidade e proteger a si mesmos contra spam.
Keysend
Uma atualização introduzida independentemente por implementações de clientes da Lightning,
que permite que o remetente envie dinheiro de forma "não solicitada" e assíncrona, sem a
necessidade de uma fatura prévia.
[1]
HODL invoices
Pagamentos em que o último HTLC não é coletado, comprometendo o remetente com o
pagamento, mas permitindo que o destinatário adie a coleta até que alguma outra condição seja
satisfeita, ou cancele a fatura sem coleta. Isso também foi implementado independentemente
por diferentes clientes da Lightning e pode ser usado de forma opcional.
Serviços de mensagens roteadas em camadas de cebola

O mecanismo de roteamento em camadas de cebola e o banco de dados de chaves públicas
subjacente dos nós podem ser usados para enviar dados que não estão relacionados a
pagamentos, como mensagens de texto ou postagens em fóruns. O uso da Lightning para
possibilitar mensagens pagas como solução para posts de spam e ataques Sybil (spam) é outra
inovação que foi implementada independentemente do protocolo central.
3
Ofertas (Offers)
Atualmente proposto como BOLT #12, mas já implementado por alguns nós, esse é um protocolo
de comunicação para solicitar faturas (recorrentes) de nós remotos por meio de mensagens em
camadas de cebola (Onion messages).
Aplicativos Lightning (LApps)

Embora ainda estejam em seus estágios iniciais, já estamos presenciando o surgimento de
aplicativos interessantes na Lightning. Amplamente definidos como um aplicativo que utiliza o
Protocolo Lightning ou um cliente Lightning como componente, os LApps (Lightning Applications)
são a camada de aplicação da Lightning. Um exemplo proeminente é o LNURL, que fornece uma
funcionalidade semelhante às ofertas do BOLT #12, mas apenas por meio de HTTP e endereços
Lightning. Ele funciona em cima de offers (ofertas) para fornecer aos usuários um endereço no
estilo de e-mail para o qual outras pessoas podem enviar fundos, enquanto o software nos
bastidores solicita uma fatura ao endpoint LNURL do nó. Mais LApps estão sendo desenvolvidos
para jogos simples, aplicativos de mensagens, microsserviços, APIs pagáveis, dispensadores pagos
(por exemplo, bombas de combustível), sistemas de negociação de derivativos e muito mais.
Preparar, Apontar, Já!

O futuro parece promissor. A Lightning Network está levando o Bitcoin a novos mercados e
aplicações inexplorados. Equipado com o conhecimento deste livro, você pode explorar essa nova
fronteira ou até mesmo se juntar como um pioneiro e abrir um novo caminho.
[1] A palavra HODL surgiu a partir de uma forma errada e empolgada de escrever a palavra HOLD, que foi gritada em um fórum
para encorajar as pessoas a não venderem o bitcoin em pânico.

Dominando A Rede Relâmpago

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Dominando A Rede Relâmpago

Enviado por

Direitos autorais:

Formatos disponíveis

Glossário

sistema criptográfico assimétrico

Bitcoin Improvement Proposal (BIP)

Diffie–Hellman Key Exchange (DHKE)

Elliptic Curve Digital Signature Algorithm (ECDSA)

características globais (globalfeatures field)

hash-based message authentication code (HMAC)

hash time-locked contract (HTLC)

just-in-time (JIT) routing

Lightning Network, Lightning Network Protocol, Lightning Protocol

Lightning Network protocol suite

Lightning Network node, Lightning node

local features (field: localfeatures)

multipart payments (MPP)

network connection layer

Proof of Work (PoW)

Point Time-Locked Contract (PTLC)

Revocable Sequence Maturity Contract (RSMC)

script, Bitcoin Script

ScriptSig (aka signature script)

secret key (chave privada)

Segregated Witness (SegWit)

Secure Hash Algorithm (SHA)

short channel ID (scid)

verificação simplificada de pagamento (SPV)

SPHINX Mix Format

unspent transaction output (UTXO)

Os watchtowers também monitoram a blockchain do Bitcoin e podem enviar uma transação de

Baseando-se na ideia de canais de pagamento, inicialmente proposta pelo inventor do Bitcoin,

Em 2019, Andreas M. Antonopoulos, Olaoluwa Osuntokun e René Pickhardt concordaram em

Convenções Usadas Neste livro

Constant width bold

Constant width italic

Este elemento significa uma nota geral.

Este elemento indica um aviso ou precaução.

Usando Exemplos de Código

Mastering the Lightning Network é oferecido sob a Licença Atribuição-NãoComercial-

Referências a Empresas e Produtos

Endereços e Transações Neste Livro

O’Reilly Online Learning

Como Nos Contatar

Para notícias e informações sobre nossos livros e cursos, visite o http://oreilly.com.

Encontre-nos no Facebook: http://facebook.com/oreilly

Siga-nos no Twitter: http://twitter.com/oreillymedia

Assista-nos no YouTube: http://www.youtube.com/oreillymedia

Entrando em Contato com Andreas

Inscreva-se no canal do Andreas no YouTube: https://www.youtube.com/aantonop

Curta a página do Andreas no Facebook: https://www.facebook.com/AndreasMAntonopoulos

Siga Andreas no Twitter: https://twitter.com/aantonop

Conecte-se com Andreas no LinkedIn: https://linkedin.com/company/aantonop

Entrando em Contato com René

Inscreva-se no canal do René no YouTube: https://www.youtube.com/user/RenePickhardt

Siga René no Twitter: https://twitter.com/renepickhardt

Conecte-se com René no LinkedIn: https://www.linkedin.com/in/rene-pickhardt-80313744

Entrando em Contato com Olaoluwa Osuntokun

Siga Olaoluwa no Twitter: https://twitter.com/roasbeef

Obrigado a todos por me apoiarem ao longo desta jornada.

Agradecimentos de Olaoluwa Osuntokun

• Aaqil Aziz (@batmanscode)

• Alexander Gnip (@quantumcthulhu)

• Alpha Q. Smith (@alpha_github_id)

• Ben Skee (@benskee)

• Brian L. McMichael (@brianmcmichael)