¿Es la maleabilidad de la transacción un problema al recibir pagos?

Supongamos que estoy usando el cliente original para recibir pagos. ¿Es posible el siguiente escenario?

Mi billetera recibe una notificación de una transacción no confirmada con id 12 en la que una de las salidas es una dirección que me pertenece.

Alguien cambia la identificación de la transacción a 13 y se la transmite al minero que encuentra el siguiente bloque.

Mi billetera recibe una notificación de un bloque que contiene una transacción con id 13 en el que una de las salidas es una dirección que me pertenece.

La transacción con id 13 obtiene 6 confirmaciones, pero la transacción con 12 se atasca en mi billetera como una transacción no confirmada.

Si muestro a mis clientes sus transacciones no confirmadas, entonces el cliente verá una transacción confirmada con id 13 y una transacción no confirmada con id 12. ¿Es correcto? ¿O QT eliminará automáticamente la primera transacción?

¿Qué puedo hacer para prevenir esto?

Creo que su Bitcoin-Qt descartaría su conocimiento de t12 tan pronto como se confirme t13 , ya que son gastos dobles entre sí.
Gracias. ¿Puede señalarme una parte determinada del código fuente donde pueda verificar para asegurarme?
@AntonAnsgar Aquí es donde ocurre la eliminación de transacciones obsoletas. removeConflictscomprueba el grupo de memoria en busca de entradas en conflicto aquí .
@JacobTorba ¿Puedes escribir una respuesta para que pueda marcarla como válida? Gracias.
@AntonAnsgar lo tienes.

Respuestas (2)

Si espera una transacción confirmada, estará bien. El error común que cometen las personas/los grandes intercambios es cuando construyen transacciones de "retiro" a partir de transacciones de "depósito" no confirmadas. Esos invalidan rápidamente debido a las reglas de doble gasto. El cliente de Satoshi hace esto como último recurso cuando selecciona salidas no gastadas.

El código que lo trata está aquí , removeConflictsestá definido aquí .

Tengo transacciones que están atascadas en mi billetera. Lo que quiero decir es que tengo dos TX que tienen las mismas entradas, las mismas salidas. Uno de ellos está confirmado. El otro está esperando sin confirmar. Tengo varios TX que están atascados así. ¿Alguna idea de por qué podrían haber sido creados? Estas transacciones son en su mayoría transacciones recibidas. También hay una transacción de envío donde tengo las mismas entradas y salidas pero diferentes ID de TX para 3 transacciones. De nuevo uno de ellos se confirma. Los otros dos están atascados. Realmente necesito ayuda con esto. Muchas gracias.
Ese método elimina las transacciones en conflicto del grupo de memoria, no de la billetera.
@PieterWullie Gracias. No sé qué hace realmente el grupo de memoria, le echaré un vistazo. ¿Pero eso significa que están en la billetera para siempre? ¿Cómo puedo deshacerme de ellos? ¿Y crees que esto es lo que está pasando con la situación que describí en esta pregunta: bitcoin.stackexchange.com/questions/22663/…
Acabo de darme cuenta de la respuesta de Pieter a la pregunta: bitcoin.stackexchange.com/questions/22663/… que el código removeConflicts existente no se ocupa de este problema.

Una transacción no confirmada no se puede gastar. Fin de la historia de verdad.

Pero en aras de la integridad, si intenta gastarlo, su transacción también permanecerá sin confirmar con la persona a la que pagó. Ninguna de estas transacciones entrará jamás en la cadena de bloques.

La pregunta no es si se puede gastar. La pregunta es si la situación descrita en la pregunta es posible.
No, esto no es posible.
¿En serio? ¿Cómo? ¿Sabes qué parte del código fuente va a eliminar la primera transacción?
Acabo de enterarme de que sí es posible. Ver: bitcoin.stackexchange.com/questions/22663/…