Patch de análise da rede Monero ainda aguarda aprovação para integração｜Aprovação na revisão não significa que já foi corrigido｜XMR a 530: prefiro esperar
Minha postura é neutra, com alguma cautela. O PR #11487, apresentado em 4 de outubro no repositório oficial de código do Monero, trata do cache de metadados usado pelo cliente HTTP ao processar respostas em blocos. Segundo o autor, se um nó remoto mantiver incompleta a linha que indica o tamanho de um bloco ou o marcador de fim, o cliente poderá continuar acumulando dados em cache e a analisá-los repetidamente. O patch pretende limitar o tamanho dos metadados de cada bloco e limpar o cache antigo ao fim da resposta, para evitar que bytes residuais sejam interpretados incorretamente no pedido seguinte. A página indica que um revisor já aprovou a alteração, mas o PR continua marcado como Open e inclui uma etiqueta indicando que é necessário fazer backport para versões antigas. A aprovação na revisão representa progresso na análise do código; não significa que o patch tenha sido integrado ou lançado, muito menos que todos os nós da rede já tenham sido atualizados.
Por que vale a pena os traders prestarem atenção a isto? A privacidade e a resistência à censura são centrais para a proposta de valor do XMR. No entanto, entre as carteiras dos utilizadores comuns, os nós remotos e os servidores continuam a existir limites de engenharia relacionados com protocolos de rede, consumo de recursos e gestão de versões. Esta proposta trata sobretudo da análise de dados pelo cliente e da limpeza de estado. Não prova que a criptografia da privacidade tenha sido comprometida, e não há informações oficiais que indiquem que alguém tenha perdido moedas por causa disto. A discussão do PR também distingue explicitamente o limite de tamanho dos metadados do limite de tamanho do corpo inteiro da resposta: este último afeta respostas RPC grandes, mas normais. Não se deve exagerar o alcance de um patch e afirmar que «todos os riscos de negação de serviço foram resolvidos». Na minha avaliação independente, a manutenção de segurança contribui para a fiabilidade a longo prazo, mas o seu impacto marginal no preço atual da moeda é muito menor do que o de uma divulgação de vulnerabilidade real, do lançamento de uma versão oficial ou de alterações nos depósitos e levantamentos das plataformas de negociação.
Como é que o mercado já reagiu? No momento em que escrevo, o par XMR/USD na Kraken está a cerca de 530,58 dólares, com máxima de 533,51 e mínima de 515,51 nas últimas 24 horas, e abertura diária em 519,43. O preço está acima da abertura diária e próximo do topo do intervalo, mas não há provas que permitam atribuir a subida à revisão de código de há uma semana. A zona de 533,5 é uma resistência de curto prazo, e a zona de 515,5 é um suporte. Se o preço ultrapassar a resistência, mas recuar rapidamente e perder os 525, a hipótese de continuação da subida fica invalidada. Se a comunidade confirmar posteriormente a integração do patch, a versão em que será lançado e o alcance da atualização pelos utilizadores, esses pontos também devem ser registados separadamente; uma única etiqueta Open não substitui o processo completo.
Se fosse eu a negociar, não entraria agora: manteria a posição em 0% e consideraria apenas uma compra à vista condicionada, sem recorrer a alavancagem elevada. Só tentaria uma posição comprada com, no máximo, 0,4% do capital total se o fecho de uma hora ficasse acima de 534 e o preço respeitasse a zona de 529–534 num reteste. O primeiro objetivo seria 542–546; ao atingir essa zona, reduziria a posição para metade e manteria o restante até perto de 555. Se o preço voltasse a ficar abaixo de 529 no fecho de uma hora, reduziria para metade a posição restante; se caísse abaixo de 522, acionaria o stop-loss e fecharia tudo. Se caísse primeiro abaixo de 515,5, cancelaria diretamente o plano de compra e aguardaria sem posição, em vez de aumentar a posição à medida que o preço cai. Para mim, o estado do patch de segurança deve ser confirmado no repositório de código e nos registos de lançamento oficiais; as decisões de negociação, por sua vez, só devem ser tomadas com base no preço, no orçamento de risco e na disciplina de stop-loss.
Fontes: PR #11487 e registos de revisão no GitHub oficial do Monero; cotações públicas da Kraken. #XMR
Isto é apenas uma observação pessoal do mercado e não constitui aconselhamento de investimento.
Minha postura é neutra, com alguma cautela. O PR #11487, apresentado em 4 de outubro no repositório oficial de código do Monero, trata do cache de metadados usado pelo cliente HTTP ao processar respostas em blocos. Segundo o autor, se um nó remoto mantiver incompleta a linha que indica o tamanho de um bloco ou o marcador de fim, o cliente poderá continuar acumulando dados em cache e a analisá-los repetidamente. O patch pretende limitar o tamanho dos metadados de cada bloco e limpar o cache antigo ao fim da resposta, para evitar que bytes residuais sejam interpretados incorretamente no pedido seguinte. A página indica que um revisor já aprovou a alteração, mas o PR continua marcado como Open e inclui uma etiqueta indicando que é necessário fazer backport para versões antigas. A aprovação na revisão representa progresso na análise do código; não significa que o patch tenha sido integrado ou lançado, muito menos que todos os nós da rede já tenham sido atualizados.
Por que vale a pena os traders prestarem atenção a isto? A privacidade e a resistência à censura são centrais para a proposta de valor do XMR. No entanto, entre as carteiras dos utilizadores comuns, os nós remotos e os servidores continuam a existir limites de engenharia relacionados com protocolos de rede, consumo de recursos e gestão de versões. Esta proposta trata sobretudo da análise de dados pelo cliente e da limpeza de estado. Não prova que a criptografia da privacidade tenha sido comprometida, e não há informações oficiais que indiquem que alguém tenha perdido moedas por causa disto. A discussão do PR também distingue explicitamente o limite de tamanho dos metadados do limite de tamanho do corpo inteiro da resposta: este último afeta respostas RPC grandes, mas normais. Não se deve exagerar o alcance de um patch e afirmar que «todos os riscos de negação de serviço foram resolvidos». Na minha avaliação independente, a manutenção de segurança contribui para a fiabilidade a longo prazo, mas o seu impacto marginal no preço atual da moeda é muito menor do que o de uma divulgação de vulnerabilidade real, do lançamento de uma versão oficial ou de alterações nos depósitos e levantamentos das plataformas de negociação.
Como é que o mercado já reagiu? No momento em que escrevo, o par XMR/USD na Kraken está a cerca de 530,58 dólares, com máxima de 533,51 e mínima de 515,51 nas últimas 24 horas, e abertura diária em 519,43. O preço está acima da abertura diária e próximo do topo do intervalo, mas não há provas que permitam atribuir a subida à revisão de código de há uma semana. A zona de 533,5 é uma resistência de curto prazo, e a zona de 515,5 é um suporte. Se o preço ultrapassar a resistência, mas recuar rapidamente e perder os 525, a hipótese de continuação da subida fica invalidada. Se a comunidade confirmar posteriormente a integração do patch, a versão em que será lançado e o alcance da atualização pelos utilizadores, esses pontos também devem ser registados separadamente; uma única etiqueta Open não substitui o processo completo.
Se fosse eu a negociar, não entraria agora: manteria a posição em 0% e consideraria apenas uma compra à vista condicionada, sem recorrer a alavancagem elevada. Só tentaria uma posição comprada com, no máximo, 0,4% do capital total se o fecho de uma hora ficasse acima de 534 e o preço respeitasse a zona de 529–534 num reteste. O primeiro objetivo seria 542–546; ao atingir essa zona, reduziria a posição para metade e manteria o restante até perto de 555. Se o preço voltasse a ficar abaixo de 529 no fecho de uma hora, reduziria para metade a posição restante; se caísse abaixo de 522, acionaria o stop-loss e fecharia tudo. Se caísse primeiro abaixo de 515,5, cancelaria diretamente o plano de compra e aguardaria sem posição, em vez de aumentar a posição à medida que o preço cai. Para mim, o estado do patch de segurança deve ser confirmado no repositório de código e nos registos de lançamento oficiais; as decisões de negociação, por sua vez, só devem ser tomadas com base no preço, no orçamento de risco e na disciplina de stop-loss.
Fontes: PR #11487 e registos de revisão no GitHub oficial do Monero; cotações públicas da Kraken. #XMR
Isto é apenas uma observação pessoal do mercado e não constitui aconselhamento de investimento.