Resumo em um minuto
O BIP 110 propõe uma mudança temporária nas regras de consenso do Bitcoin para limitar algumas formas de armazenamento de dados arbitrários.
Ele foi desenhado como um soft fork, isto é, uma restrição adicional: blocos aceitos por quem aplica o BIP 110 continuam dentro das regras antigas, mas alguns blocos aceitos pelo Bitcoin Core podem ser rejeitados por nodes que aplicam o BIP 110.
Para canais Lightning comuns, o risco principal não está no formato das transações. Os scripts usados atualmente por canais padrão cabem nos limites propostos, e UTXOs criados antes da ativação são expressamente isentos pelas regras do BIP.
O risco importante é indireto: uma ativação contestada pode fazer grupos de nodes e mineradores acompanharem históricos diferentes.
Um node Lightning herda a visão da blockchain do seu backend Bitcoin. Se esse backend estiver acompanhando uma chain diferente daquela em que uma contraparte publicou o fechamento ou um estado antigo do canal, o node pode não reagir dentro do prazo necessário.
Em termos práticos:
Não há motivo técnico, neste momento, para fechar em massa canais Lightning padrão.
Desligar o node durante uma incerteza é pior do que mantê-lo online.
O operador precisa saber qual backend Bitcoin está usando e quais regras ele aplica.
Perto das alturas críticas, convém evitar operações on-chain não essenciais.
Divergências de altura, hash ou chainwork exigem investigação — não uma troca automática de software.
A sinalização baixa reduz a probabilidade de adoção ampla, mas não elimina completamente o risco de uma chain minoritária.
Este artigo não toma posição a favor ou contra o BIP 110. O objetivo é proteger a operação Lightning enquanto a discussão acontece.
1. O que é o BIP 110?
BIP significa Bitcoin Improvement Proposal: um documento técnico que descreve uma possível mudança no Bitcoin.
Um BIP não se torna regra apenas porque recebeu um número ou porque seu status documental aparece como Complete.
No caso do BIP 110, Complete significa que seus autores consideram a especificação completa. Não significa que a rede Bitcoin aprovou ou ativou a proposta.
Bitcoin não possui uma votação central ou um comitê que aprove mudanças em nome de todos.
O BIP 110, chamado de Reduced Data Temporary Softfork, propõe aplicar por aproximadamente um ano restrições como:
scriptPubKeysnovos limitados a 34 bytes, com exceção deOP_RETURNde até 83 bytes;determinados dados empurrados para scripts e itens de witness limitados a 256 bytes;
restrições temporárias a anexos Taproot, control blocks grandes e alguns recursos ainda não utilizados por canais Lightning implantados hoje;
isenção para o gasto de UTXOs criados antes da altura de ativação.
O objetivo declarado pelos proponentes é reduzir o uso do Bitcoin para armazenamento de dados arbitrários.
Os críticos questionam a eficácia técnica, a forma de ativação, o precedente de restringir usos que hoje são válidos e, principalmente, o risco de divisão da chain.
Fontes para acompanhar os dois lados:
2. Soft fork não significa “sem risco de split”
Um soft fork cria regras mais restritivas.
Imagine dois conjuntos:
Regras atuais: aceitam um conjunto maior de blocos.
Regras do BIP 110: aceitam somente um subconjunto desses blocos.
Um Bitcoin Core sem o BIP 110 pode aceitar tanto um bloco compatível quanto um bloco incompatível com o BIP 110.
Um node que aplica o BIP 110 rejeita o segundo caso.
Isso preserva a compatibilidade em uma direção, razão pela qual a proposta é classificada tecnicamente como soft fork. Entretanto, se uma parte relevante da rede produzir e aceitar blocos que a outra parte rejeita, podem existir dois históricos concorrentes.
Portanto, estas duas frases podem ser verdadeiras ao mesmo tempo:
O BIP 110 foi especificado como soft fork.
Uma ativação contestada pode provocar uma divisão persistente ou temporária da chain.
Chamar todo o evento simplesmente de “hard fork” não descreve corretamente a relação entre as regras.
Por outro lado, dizer que “por ser soft fork não pode haver split” também seria incorreto.
3. As alturas que realmente importam
O BIP 110 usa o bit 4 da versão dos blocos e um mecanismo de ativação diferente dos soft forks mais conservadores do passado.
Os principais marcos são:
Sinalização voluntária: mineradores podem sinalizar usando o bit 4.
Lock-in antecipado: 1.109 de 2.016 blocos, ou 55%, sinalizando dentro de um período de dificuldade.
Sinalização obrigatória: blocos
961.632a963.647.Lock-in obrigatório máximo: altura
963.648.Ativação máxima: altura
965.664.Duração: 52.416 blocos depois da ativação efetiva.
Durante a janela obrigatória, um node que aplica o BIP 110 rejeita blocos que não sinalizam o bit 4.
Se o lock-in não ocorrer antecipadamente, as novas restrições entram em vigor um período de 2.016 blocos depois do lock-in obrigatório.
As datas de calendário são apenas estimativas. Blocos não chegam exatamente a cada dez minutos.
O que vale para o software são as alturas, não uma data marcada no calendário.
No retrato consultado em 24 de julho de 2026, o monitor público mostrava:
Tip
959.355.19 blocos sinalizando em 1.756 já minerados no período.
Taxa de sinalização de aproximadamente 1,08%.
2.277 blocos até a altura
961.632.
Esses números mudam a cada bloco. Use sempre o monitor atualizado e compare as informações públicas com o seu próprio Bitcoin Core.
4. Por que isso interessa à Lightning?
Um canal Lightning mantém a maior parte da atividade fora da blockchain. Mesmo assim, a segurança final do canal depende do Bitcoin.
Cada participante possui transações que representam estados sucessivos do saldo.
Se alguém publicar um estado antigo de maneira indevida, a outra parte possui uma janela de tempo para detectar o evento e reagir na blockchain.
Fechamentos forçados, penalidades, expiração de HTLCs, âncoras e fee bumping dependem de quatro condições:
Enxergar a chain relevante.
Enxergá-la a tempo.
Conseguir publicar uma transação.
Pagar uma taxa suficiente para confirmá-la.
O LND não decide sozinho qual é a “chain correta”. Ele pergunta isso ao backend Bitcoin configurado.
Se o backend observar o histórico errado, o LND também observará o histórico errado.
Uma analogia simples: o LND é o sistema de segurança de uma loja e o Bitcoin Core é a câmera.
O alarme pode estar funcionando perfeitamente, mas não reagirá a um incidente que aconteceu em uma câmera diferente.
5. O BIP 110 quebra transações Lightning padrão?
As evidências disponíveis indicam que não.
A análise técnica publicada pela Amboss compara os limites do BIP 110 com as construções usadas por canais Lightning padrão:
Novos output scripts são limitados a 34 bytes; outputs de canais usam até 34 bytes.
Dados de script e witness abrangidos são limitados a 256 bytes; scripts de canais padrão ficam abaixo desse limite.
Witness v0, Taproot e P2A permanecem permitidos e são as versões usadas pelos canais implantados.
Taproot annex e outros recursos temporariamente restringidos não são utilizados por canais Lightning comuns implantados hoje.
Além disso, a própria especificação isenta inputs que gastam UTXOs criados antes da ativação.
Um funding output de canal confirmado antes da ativação não passa a ser magicamente inválido.
Isso não é uma garantia sobre qualquer construção imaginável. Exigem revisão específica:
canais experimentais ou protocolos fora dos BOLTs usuais;
scripts Taproot feitos manualmente;
carteiras com transações pré-assinadas e caminhos de gasto incomuns;
contratos que dependam de Taproot annex,
OP_SUCCESS, control blocks profundos ou versões futuras de witness;pesquisas como LN-Symmetry, que ainda não representam os canais LND comuns em produção.
Para um node LightningOS com LND padrão e canais padrão, o risco de incompatibilidade direta é considerado baixo.
O risco de acompanhar uma chain diferente continua separado e merece atenção.
6. Como fundos poderiam ser perdidos?
Um split não entrega automaticamente os sats do canal a um atacante.
Para ocorrer uma perda, vários eventos adicionais precisam se combinar. O cenário mais preocupante seria:
Duas chains continuam avançando.
Seu backend Bitcoin acompanha apenas uma delas.
Uma contraparte publica um estado antigo do canal na outra chain.
Seu node e suas watchtowers não observam essa outra chain.
O prazo de contestação expira.
A contraparte consegue gastar os fundos naquela chain.
Outros problemas possíveis incluem:
fechamento confirmado em uma chain e ausente ou reorganizado na outra;
HTLCs expirando de formas diferentes entre os históricos;
mempools congestionadas e taxas elevadas durante fechamentos urgentes;
depósitos aceitos com poucas confirmações sendo reorganizados;
a mesma transação sendo reproduzida nas duas chains pela ausência de replay protection;
exchanges, swaps e outros serviços pausando operações até escolherem qual ativo ou histórico aceitar.
O valor econômico de uma eventual chain minoritária também é incerto.
“Ter moedas nas duas chains” não significa dobrar a riqueza. Liquidez, preço, suporte de carteiras e capacidade de movimentar os fundos podem ser muito diferentes.
7. Quatro cenários para entender o risco
Cenário A — A sinalização cresce e há convergência
Mineradores passam a sinalizar, o limiar é atingido e a maior parte do ecossistema converge para os blocos compatíveis.
Nesse cenário:
Um node que aplica o BIP 110 segue essa chain.
Um Bitcoin Core sem essas regras também pode segui-la, pois os blocos compatíveis com o BIP continuam válidos pelas regras antigas.
Canais Lightning padrão continuam funcionando.
O risco residual fica concentrado em operações incomuns, congestionamento e eventuais softwares não preparados.
Este seria o cenário de ativação mais limpo.
Cenário B — Quase ninguém sinaliza
A sinalização continua muito baixa.
Quando a janela obrigatória começa, nodes que aplicam o BIP rejeitam a maioria dos blocos produzidos pela rede.
Nesse cenário:
Bitcoin Core tende a continuar acompanhando a chain com mais trabalho válido pelas regras atuais.
Um backend que aplica o BIP pode parar ou avançar muito lentamente, aceitando apenas os raros blocos sinalizadores.
Um LND ligado a esse backend pode parecer online, mas estar observando uma chain atrasada.
Para Lightning, “backend sincronizado” não pode significar apenas que o processo está rodando.
É preciso comparar altura, hash e chainwork com fontes independentes.
Cenário C — Uma chain minoritária persiste
Uma fração relevante do hashrate mantém blocos compatíveis com o BIP, enquanto outra chain possui mais trabalho.
Nesse cenário:
Existem dois históricos vivos.
Nodes não enforcing normalmente escolhem a chain com maior trabalho acumulado entre as que consideram válidas.
Nodes enforcing permanecem na melhor chain que também respeita o BIP 110.
Exchanges, serviços, carteiras e operadores podem escolher lados diferentes.
Esse cenário exige cuidado com canais, depósitos, swaps e transações reproduzidas.
Não existe um botão automático capaz de saber qual chain terá maior valor econômico no futuro.
Cenário D — Disputa equilibrada e reorganizações
Duas chains acumulam trabalho relevante, mercados tratam ambas como valiosas e a liderança pode oscilar.
Nesse cenário:
confirmações tornam-se menos confiáveis;
reorganizações podem ser mais profundas;
canais podem fechar de maneira diferente em cada chain;
taxas e demanda por blockspace podem aumentar;
decisões precipitadas de fechamento podem piorar a exposição.
Este é o cenário mais complexo, mas não é o cenário indicado pela sinalização observada no momento desta publicação.
8. Bitcoin Core, Knots e LightningOS
O LightningOS executa LND e pode usar um Bitcoin Core local ou um backend Bitcoin remoto, dependendo da configuração.
Na tela do monitor, uma identificação como /Satoshi:31.0.0/ indica um backend Bitcoin Core.
Bitcoin Core não aplica as regras do BIP 110. Ele valida blocos conforme as regras de consenso que implementa e escolhe, entre as chains válidas para ele, aquela com maior trabalho acumulado.
Uma versão do Bitcoin Knots configurada para aplicar o BIP 110 adiciona as restrições descritas neste artigo. Ela pode rejeitar blocos que o Core aceita.
Isso não torna automaticamente um software “seguro” e o outro “perigoso” em todos os cenários.
Core possui flexibilidade para acompanhar a chain de maior trabalho que continue válida nas regras atuais.
Um node BIP 110 garante que não acompanhará blocos que violem as novas regras, mesmo que esses blocos tenham mais trabalho.
Se houver split, escolher uma regra de consenso também significa escolher quais históricos o backend está autorizado a observar.
Trocar de cliente no meio de uma divergência, reutilizando o mesmo datadir sem um procedimento validado, cria riscos adicionais.
Históricos aceitos, blocos marcados como inválidos e chainstate podem precisar de reconsideração ou reindexação.
Não faça uma troca emergencial apenas copiando comandos publicados em redes sociais.
9. O que o monitor do LightningOS realmente informa
O monitor implementado no LightningOS é somente informativo.
Ele:
lê o Bitcoin backend ativo;
calcula localmente a sinalização do bit 4;
consulta a API pública do monitor do BIP 110;
compara tip, período e contagem de blocos sinalizadores;
informa a fase e a proximidade das alturas programadas;
não altera Bitcoin Core, LND, canais ou configurações.
Quando aparece Sources match, isso significa que o cálculo local e a fonte pública concordam na amostra comparada.
Não significa, sozinho, que foi provado matematicamente que não existe split.
A API pública do BIP 110 não fornece o hash do bloco ou chainwork. Por isso:
igualdade de altura e sinalização é um bom sinal operacional;
divergência de contagem é um alerta útil;
confirmação forte de que duas fontes estão na mesma chain exige comparar hashes de bloco;
detectar qual chain possui maior peso econômico exige informações além de hash e hashrate.
O badge Janela obrigatória próxima também não significa que um fork foi detectado.
É uma classificação preventiva do LightningOS, exibida quando a sinalização está abaixo do limiar e faltam no máximo dois períodos de dificuldade para a janela obrigatória.
10. Plano prudente para operadores do Clube BRLN
Agora, antes da janela
1. Confirme o backend Bitcoin
Saiba se o LND usa Bitcoin Core local ou um RPC remoto e quem controla esse backend.
2. Mantenha LND e Bitcoin Core saudáveis
Verifique sincronização, disco, relógio do sistema e conectividade.
3. Revise os backups
Confirme seed, Static Channel Backup e procedimento de recuperação. Não armazene a seed no mesmo equipamento do node.
4. Mantenha UTXOs confirmados para taxas
Uma reserva on-chain separada ajuda em CPFP, anchor bump e fechamentos urgentes.
5. Revise canais problemáticos
Se já existe um canal offline ou que você fecharia de qualquer forma, prefira um fechamento cooperativo e antecipado.
6. Não feche canais bons por pânico
Fechamentos em massa consomem taxas, destroem posições de liquidez e podem congestionar a rede.
7. Evite trocar de implementação impulsivamente
Uma mudança de regras de consenso precisa de decisão consciente e plano de reversão.
Próximo da altura 961.632
1. Mantenha o node online e monitorado
Desligar LND ou bitcoind reduz sua capacidade de defesa.
2. Evite operações on-chain não essenciais
Isso inclui opens, closes, splices e swaps que dependam de transações on-chain.
3. Evite grandes recebimentos on-chain com poucas confirmações
Durante uma divergência, confirmações podem ter um significado diferente em cada histórico.
4. Acompanhe a sinalização de pools grandes
Não observe apenas o percentual agregado. Uma mudança de comportamento de um grande pool pode alterar o cenário rapidamente.
5. Compare hashes recentes com mais de uma fonte independente
Altura igual não é prova suficiente de que duas fontes estão na mesma chain.
6. Teste alertas e watchtowers
Uma watchtower ligada à mesma visão errada da chain não resolve a divergência.
7. Avalie a exposição a novos HTLCs
Para nodes de roteamento muito conservadores, reduzir temporariamente novos HTLCs pode limitar obrigações com prazo durante uma instabilidade comprovada.
Essa deve ser uma resposta a sinais concretos, não a rumores.
Se uma divergência for detectada
Não desligue o node.
Suspenda novas operações on-chain não essenciais.
Não force-close canais em massa.
Compare altura, best block hash, chainwork e ritmo de blocos em fontes independentes.
Registre horários, hashes, peers, logs e versão do backend.
Não troque Core por Knots, ou Knots por Core, no mesmo datadir sem procedimento específico.
Procure coordenação técnica do Clube BRLN antes de uma ação irreversível.
Se houver fechamento ou HTLC com prazo ativo, trate-o como incidente urgente.
11. O que não fazer
Não interpretar baixa sinalização como garantia de risco zero.
Não interpretar um badge amarelo como prova de fork.
Não assumir que “mais nodes” equivale automaticamente a “mais hashrate” ou “maior valor econômico”.
Não assumir que uma chain com mais hashrate hoje necessariamente terá maior valor amanhã.
Não aceitar depósitos grandes com confiança normal durante uma divergência confirmada.
Não importar seeds ou macaroons em ferramentas sugeridas por desconhecidos.
Não seguir “suporte técnico” recebido por mensagem privada.
Não executar comandos como
invalidateblock,reconsiderblockoureindexsem entender o histórico que será afetado.Não publicar backups, channel databases, seeds, macaroons ou credenciais RPC para pedir ajuda.
Eventos de consenso atraem golpes.
O risco social pode ser maior e mais imediato que o risco técnico.
12. Perguntas frequentes
Posso perder todos os fundos apenas porque uso LND?
Não.
Canais padrão não se tornam inválidos automaticamente. Uma perda exigiria uma combinação adicional de split, visão errada da chain, evento de canal com prazo e falha de reação.
O objetivo da preparação é impedir essa combinação.
Preciso fechar todos os canais?
Não há justificativa técnica geral para fechar canais padrão em massa.
Feche antecipadamente apenas canais que já possuem uma razão operacional para serem encerrados.
É melhor desligar o node e esperar?
Não.
Um canal não “pausa” porque seu node foi desligado. Prazos on-chain continuam correndo.
Mantenha Bitcoin Core e LND online.
Uma watchtower resolve tudo?
Não.
Ela ajuda contra a publicação de um estado antigo, mas precisa observar a chain onde o evento acontece.
Uma watchtower presa à mesma chain minoritária não enxerga a chain concorrente.
Sources match prova que não existe fork?
Não.
Isso prova apenas que as fontes concordaram nos dados comparados.
A confirmação de chain exige hashes; a confirmação de relevância econômica exige ainda mais contexto.
Bitcoin Core adotará automaticamente o BIP 110?
Não há código de enforcement do BIP 110 no Bitcoin Core.
Contudo, por ser um soft fork, se a chain compatível com o BIP 110 tiver mais trabalho, seus blocos também serão válidos para o Core. Nesse caso, o Core pode acompanhá-la sem aplicar as restrições por conta própria.
O BIP 110 já foi aprovado?
Não existe uma aprovação central.
A especificação está completa, mas adoção por software, mineradores, usuários e agentes econômicos é uma questão separada.
E se nada acontecer?
Esse continua sendo um resultado plausível.
Mesmo assim, melhorar uptime, backups, reserva de taxas e monitoramento deixa o node mais seguro contra muitos outros incidentes.
Conclusão
O debate público costuma apresentar duas certezas opostas:
“Não existe risco algum.”
ou:
“Todos perderão fundos.”
Nenhuma delas descreve bem a situação.
Para Lightning, a pergunta útil não é apenas “você apoia o BIP 110?”.
A pergunta realmente importante é:
Qual chain o backend do seu LND está observando — e essa é a mesma chain em que seus canais precisam ser defendidos?
Até que haja evidência de divergência, a conduta prudente é simples:
manter o node online;
usar um backend conhecido;
acompanhar dados locais e públicos;
preservar capacidade de fee bump;
evitar operações on-chain desnecessárias perto das alturas críticas;
não tomar decisões irreversíveis com base em redes sociais.
Calma não significa passividade.
Significa preparar-se antes, monitorar fatos e agir apenas quando o risco observado justificar a ação.
Leituras e fontes
Aviso: este material é educacional e operacional. Não substitui a análise individual do seu node, das suas implementações, dos seus canais ou aconselhamento financeiro.