Há um soft fork em andamento nas regras de consenso do Bitcoin. Embora tudo pareça estar indo bem, este artigo contém informações importantes e listas de verificação para mineradores e operadores de pools que não devem ser ignoradas.
Se houver alguma dúvida, mineradores e operadores de pool podem entrar em contato conosco.
DR
-
Verifique se todos os seus nós foram atualizados para Bitcoin Core 0.12.1 ou software compatível. Isso deve acontecer antes do bloco #419328. Observe que se o(s) seu(s) cliente(s) GBT implementarem o protocolo corretamente, você precisará corrigir RP #8176 (correção) ou usar Nós Bitcoin que já o inclui.
-
Se você codificar a versão do bloco, desative o bit 0 do campo de versão antes do bloco 419328 ou, de preferência, pare de codificá-lo e deixe o Bitcoind fazer isso automaticamente.
-
Use um valor nLockTime de 0xffffffff para a transação de geração para evitar qualquer conflito potencial com o BIP113.
-
Se você precisar usar um valor nLockTime diferente, deverá seguir as instruções cuidadosamente.
Status do soft fork CSV
O soft fork “CSV” atingiu o limite “travado” necessário para prosseguir com a ativação. Dos blocos de 2016 de #415296 a #417311, 1.946 (96,53%) sinalizaram a prontidão para o BIP68, BIP112 e BIP113 (“CSV”). A partir do bloco #417312 (21/06/2016 05:18:58 UTC), o softfork CSV está agora em um período de carência “travado” por cerca de 2 semanas até o bloco 419327. Depois disso, o novo BIP68, BIP112 e BIP113 as regras serão ativadas e aplicadas pela rede. Ultrapassou o “ponto sem retorno” e é irreversível sem uma reversão massiva do blockchain.
Para todos os mineiros
Durante o período de carência, todos os mineradores devem atualizar para o Bitcoin Core 0.12.1 ou qualquer implementação que suporte o softfork CSV. Na prática, no momento em que este artigo foi escrito, Bitcoin Core e Knots 0.12.1 são as únicas versões que suportam o softfork CSV. Os mineradores devem verificar novamente para garantir que todos os nós de mineração e nós de backup foram atualizados. Não fazer isso pode resultar na geração de blocos inválidos ou fazer com que seus nós se baseiem em quaisquer blocos inválidos, causando bifurcações de cadeia e perdas monetárias para os mineradores envolvidos e usuários gerais de Bitcoin.
Para mineradores que codificaram manualmente a versão do bloco
Por padrão, o Bitcoin Core define e desativa automaticamente os bits de versão conforme necessário, no entanto, sabemos que alguns mineradores codificam os números de versão do bloco. Aconselhamos fortemente contra a codificação da versão do bloco porque isso pode apresentar riscos ao sistema Bitcoin porque a versão sinaliza suporte para certas regras de consenso.
Se um minerador inadvertidamente tiver quaisquer nós que não suportem as regras indicadas pela versão do bloco, isso poderá causar a produção de blocos inválidos e poderá fazer com que o minerador siga e construa uma cadeia inválida. Em suma, ao não utilizar o valor padrão fornecido pelo bitcoind, aumenta o risco de dissociação da sinalização das regras de bloqueio e da aplicação das regras de bloqueio.
Ao contrário do softfork IsSuperMajority usado no BIP33/66/65, no sistema softfork BIP9, nenhum bloco ficará órfão devido a um número de versão incorreto (desde que a versão seja >= 4, o que é exigido pelo BIP65). Portanto, não deve haver incentivo para os mineradores codificarem a versão em bloco, o que aumentaria desnecessariamente a carga de manutenção e os riscos de erro humano.
No entanto, se você estiver configurando manualmente a versão do bloco de acordo com esta recomendação, você DEVE tomar medidas específicas. Agora que o período de carência do “ponto sem retorno” foi atingido para CSV, você deve desabilitar o bit da versão CSV, bit 0. Isso significa que se você estava sinalizando 0x20000001, você deveria sinalizar 0x20000000. Isso DEVE ser alterado antes do bloco #419328 ou você acionará mensagens de “softfork desconhecido” nos logs de todos os nós compatíveis com BIP9. Para obter mais informações, consulte as Perguntas frequentes sobre bits de versão.
O não cumprimento deste conselho pode acionar o sistema de aviso de atualização de todos os nós compatíveis com BIP9 na rede, o que será muito perturbador.
Para mineradores que permitem que o bitcoind defina a versão do bloco automaticamente, nenhuma ação adicional é necessária. Observe que ele continuará gerando blocos com a versão 0x20000001 até o bloco #419328, ponto em que o bit 0 será automaticamente desativado.
Com relação ao campo nLockTime da transação de geração
Isso é incomum, mas os mineradores que usam o campo nLockTime devem prestar atenção extra devido à ativação do BIP113.
Se um minerador estiver interferindo de alguma forma no nLockTime da transação de geração, ele deverá certificar-se de que o valor, se interpretado como um carimbo de data/hora UNIX (ou seja, >= 500000000), deve ser menor que o valor mediano do carimbo de data/hora dos últimos 11 blocos. , a menos que a nSequence da transação de geração seja exatamente 0xffffffff.
Se você não usar o campo nLockTime da transação de geração, use um valor 0.
O não cumprimento das instruções acima pode resultar na geração de blocos inválidos, causando uma bifurcação da cadeia e perda monetária dos mineradores envolvidos e dos usuários gerais do Bitcoin.
