Transação de Compromisso
Visualize saldos, to_local, to_remote e HTLCs em um estado de canal
Uma commitment transaction é a transação Bitcoin pré-assinada que permite fechar um canal Lightning unilateralmente. Cada lado mantém sua própria versão da transação, gastando a funding output do canal e distribuindo o estado atual entre to_local, to_remote e, se houver pagamentos em voo, saídas HTLC.
Esta ferramenta monta um estado fictício de canal para mostrar a assimetria entre a versão de Alice e a versão de Bob. Ela também mostra por que dust_limit_satoshis, HTLC offered/received e anchor outputs mudam o que aparece na transação publicada. Ela não usa dados reais de carteira e não deve receber backup de canal, seed, mnemonic, chave privada, macaroon ou qualquer dado sensível.
Conteúdo
Ferramenta
Transação de Compromisso
Fonte primária
A referência central é a BOLT 3, que define o formato das transações e scripts: funding output, commitment transaction, chaves derivadas, scripts de to_local, scripts de HTLC, dust trimming, anchors e regras de fee. A BOLT 5 entra quando a commitment aparece on-chain: quais saídas precisam ser observadas, quais transações de segunda etapa podem ser necessárias e como a contraparte reage a um estado revogado.
A ferramenta abaixo é intencionalmente menor que a BOLT 3. Ela não serializa uma transação Bitcoin real; ela transforma os conceitos principais em uma tabela que ajuda a responder: "se este lado publicar sua versão agora, quais tipos de saída eu devo esperar?".
Saídas
| Saída | O que representa | Por que importa |
|---|---|---|
| to_local | Saldo local de quem publica aquela versão da commitment. | Fica atrasado por to_self_delay e pode ser punido se o estado for antigo. |
| to_remote | Saldo da contraparte na mesma commitment transaction. | Normalmente é imediatamente gastável pela contraparte. |
| HTLC | Pagamento pendente que ainda não foi cumprido nem falhou. A perspectiva define se é offered ou received. | Usa condições de hash e tempo; pode virar saída on-chain em fechamento unilateral se não for removido por dust. |
| anchor | Saída pequena usada em canais com anchors para facilitar CPFP. | Ajuda a aumentar a taxa depois da publicação, quando a feerate combinada antes ficou baixa demais. |
O ponto mais fácil de errar é que to_local e to_remote não são nomes globais para "Alice" e "Bob". Eles são nomes relativos à commitment transaction que está sendo vista. Na versão de Alice, o to_local é Alice. Na versão de Bob, o to_local é Bob.
Exemplo trabalhado
Use os valores padrão da ferramenta:
- capacidade do canal:
1.000.000 sats; - saldo liquidado da Alice:
600.000 sats; - HTLCs oferecidos por Alice:
10.000 sats; - HTLCs recebidos por Alice:
5.000 satse300 sats; dust_limit:546 sats.
O saldo liquidado do Bob é calculado como:
1.000.000 - 600.000 - 10.000 - 5.000 - 300 = 384.700 sats Na versão de Alice, to_local aponta para Alice e fica atrasado por to_self_delay. O HTLC de 10.000 sats aparece como offered, porque Alice o ofereceu. Os HTLCs de 5.000 sats e 300 sats aparecem como received; o de 300 sats fica marcado como trimmed se o dust_limit continuar em 546 sats.
Troque para a versão de Bob. O saldo econômico do canal é o mesmo, mas a perspectiva muda: o to_local passa a ser Bob, e o HTLC que Alice ofereceu vira um HTLC recebido por Bob. Essa inversão é essencial para entender os scripts de HTLC e as transações de segunda etapa.
Assimetria
A ferramenta permite alternar entre a versão de Alice e a versão de Bob. O ponto central é que as duas versões não são idênticas: na versão que Alice pode publicar, o saldo local de Alice é o to_local atrasado; na versão que Bob pode publicar, o saldo local de Bob é o to_local atrasado.
Essa assimetria é o que torna a penalidade possível. Se Alice publicar um estado antigo, Bob tem uma janela para usar o segredo de revogação daquele estado e tomar a saída atrasada de Alice. Por isso a Lightning depende de monitoramento, backups corretos e, em alguns modelos, watchtowers.
Dust e anchors
Uma saída conceitual nem sempre vira uma saída real na commitment transaction. Se o valor fica abaixo do dust_limit_satoshis aplicável, a saída pode ser removida da transação publicada. Isso é chamado de dust trimming. Na ferramenta, valores abaixo do limite aparecem como trimmed para deixar claro que eles não seriam uma saída independente nesse modelo.
Anchor outputs são outro detalhe importante. Em canais com anchors, a commitment pode incluir saídas pequenas que permitem criar uma transação filha pagando taxa maior por CPFP. Isso importa porque um fechamento unilateral pode acontecer horas ou dias depois da última negociação de feerate, em uma mempool com preço completamente diferente.
A ferramenta mostra anchors como linhas didáticas de 330 sats, mas não recalcula peso, taxa real, serialização, ordenação de outputs, arredondamentos, nem todas as variações modernas de commitment. Use-a para raciocinar sobre papéis e classes de saída, não para assinar ou auditar uma transação real.
Armadilhas comuns
- Tratar
to_localcomo "saldo da Alice" em qualquer contexto. Ele é o saldo local de quem publica aquela versão. - Somar saldos e HTLCs sem perceber que HTLCs pendentes ainda não pertencem definitivamente a nenhum lado.
- Ignorar dust e assumir que todo HTLC pequeno terá uma saída on-chain separada.
- Confundir HTLC offered e received sem declarar a perspectiva da commitment transaction.
- Achar que anchors são uma "taxa". Eles são saídas que viabilizam fee bumping por transações filhas.
- Usar backup de canal, seed, macaroon ou dados reais em uma ferramenta didática de navegador.
Limites
Esta ferramenta mostra o modelo mental, não uma commitment transaction completa da BOLT 3. Ela não simula scripts reais, ordenação de outputs, cálculo exato de fees, assinaturas, transaction weight, CSV/CLTV em witness, transações HTLC-success/HTLC-timeout, transações de penalidade, nem CPFP real.
Para analisar um fechamento real, você precisa considerar os parâmetros negociados no canal, a feerate, o tipo de canal, o estado de cada HTLC, o dust_limit_satoshis, o to_self_delay e as regras de on-chain handling.
Mapa conceitual
Antes de usar esta ferramenta
- Canais de Pagamento a fundo, para entender funding output, commitment transaction e revogação.
- Operação de Canais e Encaminhamento, para entender HTLC, offered/received, CLTV e falhas.
- UTXO e Saídas, para entender o que a commitment está gastando e criando.
Depois de usar esta ferramenta
- Cadeado do HTLC, para isolar o hashlock/timelock.
- Segurança e Privacidade a fundo, para ver estado revogado, watchtowers, jamming, probing e riscos on-chain.
- Sequence e Locktime, para conectar CSV/CLTV ao Bitcoin on-chain.