¿Cómo se usó FORKID en Bitcoin Cash en el punto de bifurcación original y en todas las actualizaciones desde entonces?

Referencias:

https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/replay-protected-sighash.md

https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2018-nov-upgrade.md

Me parece que en el punto de bifurcación original, Bitcoin-ABC agregó un valor adicional 0x40llamado SIGHASH_FORKIDXor'ed con las banderas SIGHASH estándar para producir un byte SIGHASH que es incompatible con Bitcoin Core. Esto proporciona protección de reproducción para todas las transacciones firmadas con claves públicas ECDSA.

Preguntas:

¿Se FORKIDactualiza con cada "actualización de protocolo", por ejemplo, la actualización reciente de "anomalía magnética"? ¿Si no, porque no?

Parece que la actualización de mayo de 2019 cambiará FORKIDa 0xFF0001pero la especificación menciona que "las billeteras que siguen a la actualización no deberían tener que cambiar nada". -- ¿Cómo es eso posible?

¿Cambió Bitcoin-SV FORKIDpor su reciente bifurcación de Bitcoin-ABC? ¿Hay alguna protección de reproducción entre esas dos cadenas?

Respuestas (1)

El propósito de "después de cierto tiempo, establezca FORKID en 0xSMTHNG" es mantener viva la cadena anterior pero separada, en caso de un error en la bifurcación dura. Después de una bifurcación dura de Bitcoin Cash, digamos en noviembre de 2018, si está utilizando un cliente incompatible, un cliente que cumple con mayo de 2018, realizará transacciones con un FORKID que comienza con 0xFF00, y esas transacciones no serán válidas en la nueva cadena. . Las billeteras no deberían aplicar esta regla, ya que se supone que no son nodos y que no están interesados ​​en (algunas de) las nuevas reglas de consenso, que suelen ser pequeños cambios, como nuevos códigos de operación.

Trivia: Bitcoin SV se derivó de Bitcoin ABC y cumplió con mayo de 2018. Si no cometieran esto , habría protección de repetición.

1. ¿Te refieres a mayo de 2019? (no 2019) 2. ¿BCH ha incrementado el FORKID con cada hard fork? Ha habido algunos ya y no creo que lo hayan hecho. 3. ¿No son las billeteras literalmente lo que UTILIZA SIGHASH? ¿Solo nos referimos a billeteras SPV aquí? ¿No tendrían que seguir la regla FORKID para incluir tx en la cadena? 4. No entiendo la lógica con 0xdead, ¿qué está pasando ahí?
1) No, mayo de 2018 2) No, ForkId se cambia si un cliente que admite las reglas de consenso actuales pero no las reglas del próximo consenso se ejecuta después de la próxima fecha de bifurcación. Siempre ha sido 0 en Bitcoin Cash principal (no en las bifurcaciones muertas) 3) Sí, esa regla es confusa e ilógica. Asume que las billeteras no necesitan actualizarse para bifurcaciones duras y solo sus backends lo hacen. 4) Los nodos cambian el valor válido de forkid en caso de una bifurcación dura que no admitan, para mantener viva la cadena anterior y con protección de repetición bidireccional. No dude en hacer más preguntas si algo no está claro.
Lo tengo. Gracias. Mi malentendido fue que FORKID se activa al no actualizar los nodos en el momento de la bifurcación. Lo tenía al revés :-)
¿Cómo se usó FORKID en Bitcoin Cash en el punto de bifurcación original y en todas las actualizaciones desde entonces?
RespuestasAquíPolítica de privacidad1y, 0v