Testnet tx reaparece después de 90 bloques

En algún momento, el nodo Geth local informó tx 2e7a57c55a7cb28d0e233d7745210dba93c09f14c5df4e879db1a530a79a842a en el bloque 1369316 en testnet. Luego desapareció de la cadena en algún momento durante los siguientes 1-12 bloques.

El nodo geth local muestra los datos de la transacción en relación con su copia actual de la cadena de bloques; incluso si la transacción con el hash respectivo está presente en la copia, no significa que haya sido confirmada por la red (primero debe ser retransmitida y minada. Solo entonces se agrega a la cadena de bloques).

Ese mismo tx reapareció después de 90 bloques en el bloque 1369406 y ahora es parte de la cadena de bloques.

Una transacción no puede "(re)aparecer" en el sentido de que solo puede existir una sola transacción en la cadena de bloques con un hash de transacción para que la cadena de bloques sea válida.

Si "desapareció", es probable que ocurra uno de los siguientes escenarios:

• la transacción fue manipulada "intencionalmente" por uno o más nodos (a través de la manipulación de bits) y retransmitida a la red. El resto de la red lo marcó como no válido y, por lo tanto, no se agregó a la cadena de bloques (por cadena de bloques me refiero a toda la cadena de bloques con la que está de acuerdo la red)
• la transacción aún existía en las copias de la cadena de bloques de los nodos que se validaron y sincronizaron con los nodos que anteriormente la marcaron como no válida (afortunadamente, las implementaciones actuales de Ethereum penalizan a los nodos que transmiten transacciones no válidas (y no al nodo que realizó la transacción))
• se realizó un ataque del 51 % (aunque es poco probable debido al costo y la ausencia de ganancias monetarias en la red de prueba) y el atacante manipuló el pedido de transacciones.
• Ethereum utiliza el protocolo GHOST para incentivar la minería de cadenas de bloques (cuyos bloques se denominan tíos de la cadena principal válida) que tienen datos no válidos pero encabezados válidos hasta una cierta altura (las tarifas para extraer bloques tío se reducen exponencialmente por bloque). Es posible que su transacción haya aterrizado en un bloque de este tipo y se haya vuelto a sincronizar más tarde con el bloque principal (ya que era válido tanto para el encabezado como para los datos)

Estábamos en el entendimiento de que esperar 12 cuadras sería suficiente.

Realmente no puede usar un valor absoluto (de 12) bloques. El número "suficiente" de confirmaciones depende de los nodos de minería y sus bloques anunciados. Es seguro decir que cuanto mayor sea el número de confirmaciones, mejor (más nodos "han acordado" en la cadena de bloques).

¿Es esto causado por una bifurcación o un ataque de repetición? En caso afirmativo, ¿cómo se debe manejar esto?

Es muy poco probable que sea causado por una bifurcación, ya que todos los mineros tendrían que ponerse de acuerdo para extraer una nueva cadena de bloques a partir de un bloque determinado.

Bueno, siguiendo el principio de la cadena de bloques de que cualquiera puede unirse y contribuir con cualquier poder minero, no se puede mitigar (por las implementaciones actuales de Ethereum). Una solución sería usar cadenas de bloques autorizadas (es decir, eris ) que permitan ACL en los pares que se unen a la red.