Cómo confirmar que se confirmó mi propia transacción de doble gasto

En este momento, las transacciones en la red de prueba casi siempre se gastan dos veces con un nuevo txid (posible debido a la maleabilidad de tx). Esto es bastante bueno para fines de prueba.

Entonces, me pregunto: cuando realicé un pago y tengo txId 'XXX', este pago a veces se confirma con un nuevo txId 'YYY' que no conozco. ¿Cómo puedo (usando bitcoind json-rpc) saber que mi pago con txId 'XXX' fue confirmado?

estoy viendo lo mismo! Veo mi utx empujado transmitido en la red y luego está en el bloque con un txid diferente (nunca veo el utx alterado transmitido, ¡creo que los mineros los están cambiando cuando los ponen en el bloque!?)
No son necesariamente los mineros. Cualquiera puede cambiar ligeramente las firmas de la transacción de manera que sigan siendo válidas y de esta manera generar un nuevo hash tx. Que esto sea posible se llama maleabilidad de transacción. Supongo que alguien está haciendo esto con todas las transacciones que se transmiten en la red de prueba en este momento y de alguna manera lo logra para que se completen antes de que lo hagas la mayor parte del tiempo. Vea mi respuesta sobre cómo manejarlo.
nunca veo el utx alterado transmitido
Yo tampoco. Creo que tu propio cliente lo rechaza porque ya tienes esa transacción. Pero cuando otros clientes vean primero la transacción en conflicto, rechazarán la suya.
XXX se convierte en YYY, no hay 2 transacciones; si las hubiera, ¡tendría que ver ambas transmitidas! En su lugar, solo verá XXX antes de que se convierta en YYY en el bloque.
¡mira a este tío! bitcoin.stackexchange.com/a/52576/14316 muy interesante (¡acerca de que no vemos YYY transmitido!)

Respuestas (2)

Antes de marcar su pregunta como 'respondida' considere esto:

Si su cliente bitcon no ve tx YYY pero solo ve XXX broadcast-ed, entonces parecería que solo el bloque que almacenó su cliente contiene la referencia a txid YYY (que su cliente nunca almacenó).

En su respuesta, señala https://bitcoin.org/en/release/v0.12.0#wallet-negative-confirmations-and-conflict-detection como el método que viene al rescate... En su escenario de ejemplo transaction B , 'beats ' transaction A en una carrera por gastar los mismos insumos...

Este método de detección funciona si su cliente ha visto transmisiones de red de XXX ( transaction A) y YYY ( transaction B) (¡porque esto sería un gasto doble donde YYY venció a XXX!)

Pero dado que su cliente nunca ha oído hablar de YYY (aparte de su referencia sin salida en un bloque) , ¿cómo podrá el cliente usar este método cuando tx YYY se grabó/guardó/almacenó en la memoria de la unidad de su PC como XXX?

Mi respuesta (si puede confirmar que tx YYY solo su cliente no puede encontrarlo) es;

Parece que algunos/muchos mineros están cambiando txids (a través de la maleabilidad)

Testnet3 podría estar roto/bajo un ataque no intencional de un código inseguro porque los txid maleados en los bloques no apuntan a nada almacenado en la memoria, mientras que los tx que se almacenan son gastos válidos: el txid no siempre está presente en el bloque.

... como si el minero estuviera decapitando a algunos txs

relacionado: testnet3 maleabilidad frecuente de tx y ¿Cómo vio esto blockr.io?

¡Escucho la red de una manera completamente diferente a ti y veo lo mismo! No digo que tenga razón, pero si puede probar que esta respuesta es incorrecta, ¡sería interesante! ¡Me pregunto qué magia vudú está pasando aquí!

En realidad, la respuesta es que recibirá un recuento de confirmación negativo en este caso. (La documentación de bitcoin es simplemente terrible...)

Consulte las notas de la versión de bitcoin core de 0.12.0 - sección "Wallet: Confirmaciones negativas y detección de conflictos"

https://bitcoin.org/en/release/v0.12.0

nota de actualización : en caso de una confirmación negativa (conflicto detectado), asegúrese de buscar todos los tx principales de ese tx y ver si ese se confirmó

Cómo confirmar que se confirmó mi propia transacción de doble gasto
RespuestasAquíPolítica de privacidad1y, 0v