TL;DR : ¿ En qué parte de este código el cliente SV se da cuenta de que no está procesando una cadena de bloques ABC?
Esta imagen motivó mi pregunta.
Hay un par de implementaciones diferentes mutuamente incompatibles ( supongo que de todos modos ) del software cliente de criptomonedas Bitcoin Cash...
Mi pregunta asume que cada implementación procesa sus respectivas transacciones utilizando reglas de procesamiento de blockchain similares pero incompatibles entre sí.
¿Es normal ejecutar una implementación de cliente de Bitcoin Cash SV en una red Bitcoin Cash ABC? ¿Y viceversa? Entonces, ¿cómo sabe una implementación que la red en la que se está ejecutando es ( in ) compatible con sus reglas de procesamiento particulares?
Ninguno de los clientes verifica concretamente que esté en la cadena incorrecta: BCH y BSV tuvieron una división sucia.
Ninguno cambió la magia de la red, ni tampoco cambió su formato de transacción, por lo que sus nodos continuaron comunicándose y las transacciones permanecieron reproducibles de una red a otra. Como menciona MCCCS , las dos redes comenzaron a seguir mejores cadenas distintas cuando cada lado incluía transacciones que no eran válidas para la otra red. En ese momento, los nodos completos todavía estaban conectados a una combinación de nodos de ambos protocolos. Recibirían anuncios para bloques de cualquier cadena. A medida que descargan el primer bloque con los nuevos códigos de operación que solo estaban permitidos en uno u otro protocolo ( OP_MULyOP_DATASIGVERIFY), los nodos intentarían validar el bloque y encontrarían que el bloque del otro protocolo no es válido. En ese momento, prohibirían el nodo que ofrecía el bloque no válido y reemplazarían el par con otra conexión. Creo que al menos desconectarían o prohibirían por completo a cualquier compañero nuevo que también siga la cadena no válida (desde la perspectiva de este nodo) cuando se conecten. Presuntamente, esto provocó la rotación de pares en ambos lados hasta que cada nodo finalmente hizo suficientes conexiones con los nodos que ejecutan el mismo protocolo que ellos.
La captura de pantalla que vinculó se publicó unos diez días después de la división, por lo que es posible que la reorganización de la topología aún estuviera en curso en ese momento (o la captura de pantalla se creó unos días antes de que se volviera a publicar). Especialmente los servicios que monitorean la población de nodos también podrían haber estado ejecutando nodos rastreadores especiales que en realidad no estaban ejecutando el software de nodo completo y, por lo tanto, no anunciaban bloques, por lo que quizás se habrían retrasado al notar la división de la topología.
ellos no
Tienen reglas de consenso diferentes, pero a veces comunes. Hay dos bloques de bifurcación que compiten con diferentes reglas de ordenación de transacciones y algunas transacciones con OP_MULo OP_DATASIGVERIFY. Uno de los bloques es válido para ese cliente, seguido de muchos bloques válidos. A veces, procesan transacciones de ambas redes, ya que la protección de reproducción es opcional. Simplemente procesan si algo es válido, o no si no lo es.
algoHolic
MCCCS