Un borrador de BIP de 2015 sugirió usar un "bit de bifurcación dura":
El bit más significativo en nVersion se define como el bit hardfork. Actualmente, los bloques con este bit de encabezado configurado en 1 no son válidos, ya que BIP34 interpreta nVersion como un número con signo y requiere que sea >=2 (con BIP66, >=3). Entre los 640 bits en el encabezado del bloque, este es el único que es fijo y no tiene ningún propósito y, por lo tanto, es la mejor manera de indicar el despliegue de un hardfork.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
Si los índices de bits aumentan de izquierda a derecha, me imagino que el bit de bifurcación dura ocupa el índice 31, marcado como se muestra a *continuación ( nVersiones un valor de 32 bits).
0 1 2 3
0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1
*
De acuerdo con la propuesta, establecer el bit 31 de nVersiondebería hacer que un bloque sea rechazado como inválido.
BIP-9 impone restricciones adicionales sobre los bits disponibles, específicamente, los bits 0-2 deben configurarse como [0, 0, 1]:
Los bloques en el estado INICIADO obtienen una nVersion cuyo bit de posición de bit se establece en 1. Los 3 bits superiores de dichos bloques deben ser 001, por lo que el rango de valores de nVersion realmente posibles es [0x20000000...0x3FFFFFFF], inclusive.
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
Además, BIP-9 organiza los bits de versión en orden creciente de derecha a izquierda. Es decir, el bit 0 de la versión es el nVersionbit 31, el bit 1 de la versión es nVersionel bit 30, y así sucesivamente.
Pero si este fuera el caso, entonces el bit 0 de la versión estaría fuera de los límites. BIP-9 no dice nada sobre esto y, de hecho, BIP-68 se señaló utilizando la versión bit 0:
Este BIP debe ser implementado por "versionbits" BIP9 usando el bit 0.
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
Mis preguntas son simples:
nVersioníndice de bit es el "bit de bifurcación dura"?Actualización: la fuente de mi confusión fue pensar que nVersionla indexación de bits y la indexación de bits de versión se ejecutaban en direcciones opuestas. El no. Para indicar que está listo para una propuesta utilizando la versión bit 1, por ejemplo, nVersionse establece el bit 1. Las reglas de BIP-9 se activan cuando nVersionse detecta una firma. Esta firma son los bits 29-31 establecidos como 1, 0y 0, respectivamente. Esto deja el bit 31 sin configurar.
La respuesta de Peter aborda la pregunta (1) anterior.
En cuanto a la pregunta (2), la señalización BIP-68 no provocó el rechazo del bloque porque se estaba configurando el bit 0, no el bit 31.
El bit 31 a veces se denomina bit de bifurcación dura.
BIP34 impone una restricción a los números de versión para que sean 2 o superiores. Como la versión de bloque es un entero con signo de 32 bits, establecer su bit más alto da como resultado un número negativo, lo que violaría BIP34.
Como resultado, cualquier uso de ese bit da como resultado un cambio incompatible hacia atrás en las reglas, una bifurcación dura, que es obvia para todos los participantes en el sistema.
Rica Apodaca
pieter wuille
pieter wuille
(nVersion >> X) & 1.Rica Apodaca
nVersionbit 31) como una señal. Entiendo que la funcionalidad de BIP-68 era asignar significado alnSequencecampo. Mi pregunta proviene del mecanismo de implementación para BIP-68, que requiere que los nodos de señalización establezcan elnVersionbit 31. Al menos eso es lo que parece.pieter wuille
Rica Apodaca
pieter wuille
pieter wuille