Hay una bifurcación suave en curso de las reglas de consenso de Bitcoin. Si bien todo parece ir bien, este artículo contiene información importante y listas de verificación para mineros y operadores de pools que no deben ignorarse.
Si tiene alguna duda, los mineros y operadores de pools pueden contactarnos.
TL;DR
-
Verifique que todos sus nodos se hayan actualizado a Bitcoin Core 0.12.1 o software compatible. Esto debe suceder antes del bloque #419328. Tenga en cuenta que si su cliente GBT implementa el protocolo correctamente, deberá aplicar el parche PR #8176 (parche) o utilizar Bitcoin Knots, que ya lo incluye.
-
Si codifica la versión del bloque, desactive el bit 0 del campo de versión antes del bloque 419328, o preferiblemente deje de codificarlo y deje que bitcoind lo haga automáticamente.
-
Utilice un valor nLockTime de 0xffffffff para la transacción de generación para evitar cualquier conflicto potencial con BIP113.
-
Si tienes que utilizar un valor de nLockTime diferente, debes seguir las instrucciones cuidadosamente.
Estado de la bifurcación suave CSV
La bifurcación suave «CSV» ha alcanzado el umbral «bloqueado» requerido para proceder a la activación. De los 2016 bloques del n.° 415296 al n.° 417311, 1946 (96,53 %) señalaron la preparación para el softfork BIP68, BIP112 y BIP113 (“CSV”). A partir del bloque #417312 (21/06/2016 05:18:58 UTC), el softfork CSV se encuentra ahora en un período de gracia «bloqueado» durante aproximadamente 2 semanas hasta el bloque 419327. Después de eso, los nuevos BIP68, BIP112 y Las reglas BIP113 serán activadas y aplicadas por la red. Ha superado el “punto de no retorno” y es irreversible sin una reversión masiva de la cadena de bloques.
Para todos los mineros
Durante el período de gracia, todos los mineros deben actualizar a Bitcoin Core 0.12.1 o cualquier implementación que admita el softfork CSV. En la práctica, al momento de escribir este artículo, Bitcoin Core y Knots 0.12.1 son las únicas versiones que admiten el softfork CSV. Los mineros deben verificar nuevamente para asegurarse de que todos los nodos de minería y los nodos de respaldo se hayan actualizado. No hacerlo puede resultar en la generación de bloques no válidos o hacer que sus nodos se basen en bloques no válidos, causando bifurcaciones de cadena y pérdidas monetarias para los mineros involucrados y los usuarios generales de Bitcoin.
Para mineros que codificaron manualmente la versión del bloque
De forma predeterminada, Bitcoin Core configura y desactiva automáticamente los bits de versión según sea necesario; sin embargo, somos conscientes de que algunos mineros codifican los números de versión del bloque. Recomendamos encarecidamente no codificar la versión en bloque porque puede introducir riesgos al sistema Bitcoin porque la versión indica compatibilidad con ciertas reglas de consenso.
Si un minero inadvertidamente tiene nodos que no soportan las reglas indicadas por la versión del bloque, podría causar que se produzcan bloques no válidos y podría hacer que el minero siga y construya sobre una cadena no válida. En resumen, al no utilizar el valor predeterminado proporcionado por bitcoind, aumenta el riesgo de desacoplar la señalización de las reglas de bloqueo y la aplicación de las reglas de bloqueo.
A diferencia del softfork IsSuperMajority utilizado en BIP33/66/65, en el sistema softfork BIP9, ningún bloque quedará huérfano debido a un número de versión incorrecto (siempre que la versión sea >= 4, que es requerida por BIP65). Por lo tanto, no debería haber ningún incentivo para que los mineros codifiquen la versión en bloque, lo que aumentaría innecesariamente la carga de mantenimiento y los riesgos de error humano.
Sin embargo, si configura manualmente la versión del bloque según esta recomendación, DEBE tomar medidas específicas. Ahora que se alcanzó el período de gracia del “punto sin retorno” para CSV, debe desarmar el bit 0 de la versión CSV. Esto significa que si estaba señalando 0x20000001, debe señalar 0x20000000. Esto DEBE cambiarse antes del bloque #419328 o activará mensajes de «softfork desconocido» en los registros de todos los nodos compatibles con BIP9. Para obtener más información, consulte las preguntas frecuentes sobre Version Bits.
No seguir este consejo puede activar el sistema de advertencia de actualización de todos los nodos compatibles con BIP9 en la red, lo que será muy perjudicial.
Para los mineros que permiten que bitcoind configure la versión del bloque automáticamente, no se requiere ninguna otra acción. Tenga en cuenta que seguirá generando bloques con la versión 0x20000001 hasta el bloque #419328, momento en el que se desactivará automáticamente el bit 0.
Con respecto al campo nLockTime de la transacción de generación
Esto es poco común, pero los mineros que usan el campo nLockTime deben prestar especial atención debido a la activación de BIP113.
Si un minero está interfiriendo con el nLockTime de la transacción de generación de alguna manera, debe asegurarse de que el valor, si se interpreta como una marca de tiempo UNIX (es decir, >= 500000000), debe ser menor que el valor medio de la marca de tiempo de los últimos 11 bloques. , a menos que la nSequence de la transacción de generación sea exactamente 0xffffffff.
Si no utiliza el campo nLockTime de la transacción de generación, utilice un valor de 0.
No seguir las instrucciones anteriores puede provocar la generación de bloques no válidos, lo que provocará una bifurcación de la cadena y una pérdida monetaria de los mineros afectados y de los usuarios generales de Bitcoin.
