Comportamiento del cliente de Bitcoin en caso de bifurcación

¿Qué sucede cuando una cadena bifurcada se vuelve más larga que la cadena de bloques principal?

Supongamos que la cadena bifurcada que acaba de alargarse no tiene transacciones, por lo que es como si cada transacción en los últimos n bloques nunca hubiera ocurrido.

Según tengo entendido, el cliente oficial de Bitcoin reconocerá que las transacciones recientes que envió ya no existen y las retransmitirá. Por pregunta es,

  • ¿A qué antigüedad se volverán a emitir las transacciones? ¿Se volverá a emitir una transacción que tiene años? ¿Cuál es el corte?
  • ¿Se vuelve a emitir la transacción exacta o se crea una transacción equivalente? es decir, ¿intentará enviar exactamente los mismos Bitcoins (que, debido a la bifurcación, es posible que ya no sean de su propiedad) o creará una transacción equivalente basada en los Bitcoins que todavía posee? ¿Qué pasa si el cliente no tiene suficientes Bitcoins?

Editar: Como ya no puedo encontrar dónde lo vi por primera vez, supongo que también debería preguntar: ¿el cliente oficial, de hecho, vuelve a emitir transacciones en caso de una bifurcación de la cadena de bloques?

Respuestas (2)

Las transacciones que haya enviado se volverán a enviar para siempre (cada 30 minutos más o menos), incluso si no tienen posibilidad de entrar en la cadena porque ahora no son válidas. Se envían las mismas transacciones, no se crean nuevas.

Este conflicto es con la respuesta de sipa. Usted escribió "incluso si no tienen posibilidad de entrar en la cadena porque ahora no son válidos" y él escribió "bajo la condición de que sean válidos en la nueva cadena". ¿Quién tiene razón?
Estábamos hablando de cosas diferentes: * el propietario de la transacción retransmitirá bajo la condición de que su transacción no sea aceptada (más), incluso si no tiene ninguna posibilidad. * otros nodos, en el caso de una reorganización, volverán a mover las transacciones al grupo de memoria, si son válidas en la nueva cadena. Esto no está relacionado con la retransmisión.

En el caso de una reorganización, las transacciones que se 'perdieron' en la cadena más larga anterior se vuelven a mover al grupo de memoria, con la condición de que sean válidas en la nueva cadena. Esto significa que si las entradas ya no existen en la nueva cadena, se pierden. Así es precisamente como funciona un "ataque de doble gasto": intente bifurcar la cadena y gastar las monedas en ambas ramas.

El efecto de mover las transacciones de vuelta al grupo de memoria es solo que el cliente no las olvida (no las volverá a anunciar ni las descargará de los pares cuando se le informe), y si el nodo es un minero, serán candidatos para su inclusión. en el siguiente bloque creado.

En general, esto significa que no hay retransmisiones: los mineros y el resto de la red hacen todo lo posible para no olvidarse de estas transacciones perdidas. Sin embargo, si eso falla, y por alguna razón (tarifa muy baja, por ejemplo) la transacción no sobrevive, es responsabilidad del nodo que originalmente envió la transacción para retransmitirla. Entonces, sí, también hay retransmisiones, pero solo por parte del propietario original, y solo cuando detecta que la transacción no está o ya no está en la cadena de bloques.

Siempre es una transacción idéntica de byte por byte, no un equivalente usando diferentes entradas.

"bajo la condición de que sean válidos en la nueva cadena": ¿dónde está esta condición en el código? Lo acabo de escanear pero no lo veo.
::Reorganizar en main.cpp resucita las transacciones perdidas alimentándolas al grupo AcceptToMemory, que realiza las mismas comprobaciones que se realizan en las transacciones que llegan como un mensaje tx.
Lo hace, pero lo hace antes de que se llame a RemoveFromMemoryPool para las transacciones que estaban en la mejor bifurcación anterior, por lo que los cheques podrían pasar debido a transacciones que solo existían en la rama anterior, y pronto dejarán de serlo. ya existe?
vConnect es la lista de transacciones en la sucursal recién conectada.
> "no se volverá a anunciar" Por lo tanto, no es lo mejor para el remitente volver a anunciar si planea duplicar el gasto. Suena como un vector de ataque para abordar.