O escândalo em torno do OCEAN e do BIP-110: o que a história do hashrate de outra pessoa na cadeia de fork nos ensina
Resumindo: no início de agosto de 2026, alguns dos mineradores conectados ao pool OCEAN descobriram que seus equipamentos estavam minerando blocos na cadeia de fork do soft fork BIP-110 por cerca de 18 horas, embora os próprios mineradores não suportassem esse soft fork. A OCEAN reconheceu o problema publicamente. A razão é que o modelo Stratum padrão do pool sinalizou “para” BIP-110, e alguns dos mineradores que escolheram modelos alternativos sem sinal ainda acabaram amarrados à cadeia de fork. A história levanta questões que vão muito além de apenas um pool: quanto controle um minerador tem sobre os sinais de seu hashrate e o que procurar ao escolher um pool para evitar acabar em uma situação semelhante.
O POOL BTC examina este caso não para julgar um pool específico, mas para extrair dele uma lição prática para aqueles que estão escolhendo onde alocar seu hashrate. Recontamos apenas o que é confirmado pela própria OCEAN e por fontes independentes, sem especulações sobre os motivos e sem avaliação de culpa.
O que aconteceu: cronologia factual
O soft fork do BIP-110 entrou na janela de sinalização obrigatória no bloco 961632. Neste ponto, ele era suportado por cerca de 2,6% do hashrate da rede com o limite exigido de 55%. Essa lacuna é suficiente para que o fork não tivesse chance de ser ativado, mas a própria mecânica de sinalização ainda levou ao surgimento de uma cadeia de fork separada: os blocos que não receberam o sinal exigido de acordo com as regras BIP-110 foram para um ramal, o restante para outro.
A cadeia de fork conseguiu produzir apenas dois blocos, 961.632 e 961.633, e parou aí. A cadeia principal, por sua vez, avançou em mais de 200 blocos, ou seja, a grande maioria da rede continuou a operar como se a cadeia fork não existisse.
O segundo bloco da cadeia fork, 961.634, foi minerado pelo grupo Simple Mining através do protocolo DATUM do pool Ocean. Um detalhe indicativo: a Simple Mining estava minerando através do DATUM sem o sinal BIP-110, embora o próprio pool Ocean sinalizasse “para” esse soft fork por padrão. Isto é confirmado pela fonte CoinDesk: Bitcoin Miner rejeita BIP-110 apesar da mineração através de um pool que suporta É.
O ponto principal da história está em outro lugar. A OCEAN admitiu que por aproximadamente 18 horas, uma parte dos mineradores que escolheram modelos Stratum não BIP-110 e se recusaram tecnicamente a sinalizar para o fork ainda estavam, na verdade, minerando blocos na cadeia do fork sem o seu consentimento. De acordo com o BeInCrypto, a comunidade exigiu então a renúncia da administração do pool, e Adam Back classificou publicamente o incidente como inaceitável. O grupo Roughnecks, que explorou ambos os blocos da cadeia fork, abandonou seu apoio adicional em 9 de agosto, após o qual o hashrate OCEAN caiu drasticamente. Fonte: Mineiros de Bitcoin exigem demissão de liderança oceânica sobre o BIP-110.
Por que isso é tecnicamente possível?
A essência do problema não é o próprio fato da existência de vários modelos Stratum, mas onde o hashrate do minerador é fisicamente direcionado no momento em que o pool ou protocolo alterna ou roteia tarefas. O minerador vê apenas o modelo que foi enviado a ele no momento e geralmente não tem uma maneira fácil de verificar em tempo real para qual cadeia o bloco encontrado irá se o roteamento interno do pool não se comportar conforme o esperado.
No caso do OCEAN, a situação foi complicada pelo fato de o pool oferecer aos mineradores uma escolha: sinalizar para o BIP-110 através do modelo padrão ou escolher um modelo Stratum alternativo sem tal sinal. O próprio fato da escolha deveria proteger os mineiros dissidentes de participarem da bifurcação. De acordo com o pool, na prática isso não protegeu a todos: parte do hashrate que escolheu nominalmente o caminho não-BIP-110 ainda acabou na cadeia de fork por cerca de 18 horas.
Aqui está uma conclusão mais geral que não depende dos detalhes de um incidente específico. A presença de uma opção de seleção na interface do pool não garante que a seleção seja tecnicamente aplicada em todos os níveis de roteamento de tráfego. A diferença entre “um pool oferece uma escolha” e “um pool garante tecnicamente o isolamento do thread” pode não ser perceptível do lado de fora até que ocorra uma falha.
O papel do protocolo DATUM nesta história
É dada especial atenção ao fato de que o bloco 961 634 na cadeia de fork foi minerado pela equipe Simple Mining através do protocolo DATUM do pool Ocean, sem o sinal BIP-110, apesar do próprio pool ter sinalizado “para” por padrão. Isso significa que os mineradores que usam DATUM tinham a capacidade técnica de configurar de forma independente o modelo de bloco e sua sinalização separadamente da política de pool padrão.
DATUM, nesse sentido, está próximo em espírito da ideia de construção de bloco descentralizada, sobre a qual o POOL BTC escreveu em detalhes na análise do Stratum V2 e da Declaração de Trabalho na seção comparações de pool: quanto mais a decisão sobre o conteúdo e a sinalização do bloco permanecer no minerador lado, e não totalmente delegado ao pool, menos o mineiro depende das configurações padrão do pool em situações controversas, como a ativação de um soft fork.
Mas mesmo essa opção de personalização não salvou completamente. O incidente com a ligação de 18 horas de alguns mineradores dissidentes à cadeia de garfos ocorreu paralelamente ao fato de que parte da comunidade, em princípio, tinha capacidade técnica de escolha. Um protocolo avançado reduz o risco, mas não o elimina totalmente se o roteamento do tráfego dentro do pool não for suficientemente transparente.
O que isso significa para a escolha de um pool: perguntas antes de conectar
A história do OCEAN e do BIP-110 não é motivo para tirar uma conclusão sobre a falha de um pool específico. Este é um motivo para formular uma lista de perguntas que devem ser feitas a qualquer pool antes de enviar hashrate para lá, especialmente durante períodos de atualizações de protocolo controversas, como a ativação de soft forks.
Vale a pena entender quais modelos Stratum estão disponíveis e como eles diferem por padrão: se o pool oferece várias opções de conexão, descubra com antecedência qual sinalização está incluída no modelo padrão e o que precisa ser alterado na configuração para obter outro. Separadamente, verifique se o pool garante o isolamento técnico dos fluxos de mineradores com configurações diferentes, pois não só existe a escolha na interface, é importante entender se o tráfego de mineradores com padrões diferentes é realmente roteado separadamente no nível da infraestrutura do pool. É útil descobrir se o pool suporta protocolos como DATUM ou Stratum V2 com Declaração de Trabalho, pois quanto mais controle um minerador puder ter sobre o conteúdo e sinalização de um bloco, menos dependente ele será das decisões padrão do pool.
Também vale a pena observar como o pool comunica antecipadamente atualizações controversas de protocolo. O anúncio público e antecipado da posição do pool em um determinado soft fork e como isso afetará diferentes categorias de mineradores reduz o risco de surpresas no momento da ativação. E, finalmente, faz sentido verificar como o pool reage após o incidente: o reconhecimento do problema, uma explicação pública dos motivos e uma correção técnica falam sobre a disposição do pool de prestar contas à comunidade muito mais do que o silêncio ou a linguagem vaga.
Um conjunto semelhante de critérios deve ser mantido em mente ao escolher um esquema de pagamento, sobre o qual o POOL BTC escreveu em um guia completo para esquemas de pagamento para pools de mineração de PPS a PPS TIDES: quanto mais transparente o pool explica sua própria mecânica, menos surpresas aguardam o minerador mais tarde.
O que um minerador deve fazer agora
Se o tópico de atualizações de protocolo e roteamento de tráfego não é abstrato para você, mas é importante na prática, aqui está o que você deve prestar atenção.
Verifique os modelos atuais do Stratum e as configurações de sinalização do pool antes de se conectar, especialmente durante períodos de discussões ativas sobre soft forks na comunidade. Dê preferência a grupos que expliquem publicamente sua posição sobre mudanças controversas de protocolo com antecedência, em vez de descobrirem isso por você após o incidente. Considere protocolos com controle avançado do lado do minerador, como DATUM ou Stratum V2 com declaração de trabalho, como forma de reduzir a dependência das configurações padrão do pool. Monitore os sinais de reputação da comunidade: as demandas públicas da comunidade ou os comentários de figuras proeminentes do setor geralmente aparecem mais rápido do que as autópsias oficiais do pool.
Se você distribuir hashrate entre vários pools, o incidente OCEAN é outro motivo para comparar suas abordagens à transparência do roteamento de tráfego, e não apenas à comissão. É conveniente visualizar uma comparação de pools com base em parâmetros-chave na seção comparação de pools POOL BTC. Para aqueles que desejam estimar antecipadamente como uma mudança no pool ou em sua política afetará a renda, é útil manter uma calculadora de lucratividade de mineração, e para os titulares de cartões retirarem recompensas, uma revisão dos cartões criptográficos na seção POOL BTC será útil.
Perguntas frequentes
Este incidente significa que a OCEAN agiu de forma maliciosa?
Não, as fontes disponíveis não fazem tal afirmação. A OCEAN reconheceu publicamente o problema, e figuras da comunidade e da indústria como Adam Back consideraram o incidente inaceitável, mas trata-se das consequências do incidente, e não da intenção comprovada. POOL BTC relata apenas fatos confirmados e não tira conclusões sobre razões além do que as próprias fontes disseram.
O que aconteceu com a cadeia de fork BIP-110 no final?
A cadeia de fork produziu apenas dois blocos, 961.632 e 961.633, e parou enquanto a cadeia principal estava à frente de mais de 200 blocos. Com o suporte de apenas cerca de 2,6% do hashrate contra os 55% exigidos, o fork inicialmente não teve chance de obter ativação.
Como posso entender que meu hashrate não terminará em uma situação semelhante em outro pool?
Não há teste universal direto, mas verificando os modelos Stratum disponíveis, perguntando diretamente ao suporte do pool sobre o isolamento técnico do tráfego e preferindo protocolos com controle estendido no lado do minerador, como DATUM ou Stratum V2, reduzem a probabilidade de tal cenário.
Isenção de responsabilidade
O material é apenas para fins informativos e é baseado em dados publicados pela CoinDesk e BeInCrypto em 10 de agosto de 2026. POOL BTC é um site independente de pool, calculadora e comparação de serviços e não é afiliado ao OCEAN Pool. A situação em torno do incidente pode evoluir, por isso recomendamos que você consulte as declarações oficiais atuais da OCEAN e fontes independentes antes de tomar decisões.