¿Cómo utiliza una billetera salidas no confirmadas como entradas después de transacciones no confirmadas?

Tengo 10 btc en la dirección A.

Usando una transacción sin procesar, envío 5btc de A a B y configuro la dirección de cambio como A en sí misma. Ahora, debido a que la transacción de A a B no está confirmada, no puedo gastar los 5 btc restantes.

Pero vi que la billetera QT puede hacer esto. Ex:

Tengo 10 btc en la dirección A. Envío 5 btc a B. La billetera crea una nueva dirección C y la establece como dirección de cambio. Luego intento usar los 5 btc en la billetera y funciona. Me permite enviar desde la dirección C.

1) ¿La billetera está utilizando salidas no confirmadas como entradas aquí?

2) Si es así, ¿cómo se hace esto y cómo puedo hacerlo usando transacciones sin procesar?

3) Si no, ¿qué está pasando aquí?

Respuestas (4)

¿La billetera está usando salidas no confirmadas como entradas aquí?

Sí.

Si es así, ¿cómo se hace esto?

A excepción de las transacciones de base de monedas, las transacciones son independientes de los bloques. Una transacción que gasta una entrada no confirmada se ve exactamente igual que una transacción que gasta una entrada confirmada.

Es seguro que Bitcoin-Qt gaste cambios no confirmados porque sabe que la entrada es válida y se confirmará en algún momento (aunque probablemente lentamente). No sería seguro para Bitcoin-Qt gastar entradas no confirmadas que él mismo no creó porque es posible que nunca se confirmen, lo que resulta en fondos inmovilizados de forma permanente. (Versiones muy antiguas de Bitcoin cometieron este error, pero se corrigió después de problemas generalizados).

¿Cómo puedo hacerlo usando transacciones sin procesar?

Puede crear la transacción createrawtransactionnormalmente, pero deberá proporcionar signrawtransactioninformación adicional sobre la transacción no confirmada en su segundo parámetro.

createrawtransaction admite el gasto de entradas no confirmadas; consulte gist.github.com/gavinandresen/3966071#file-twoofthree-sh-L42 para ver un ejemplo.
@gavinandresen Mirando más, me parece que los dos estamos equivocados. En su ejemplo, createrawtransactionen realidad no mira el proporcionado redeemScripto scriptPubKeyAFAICT. createrawtransactionusa cualquier dato que le des, y ni siquiera usa la base de datos de bloques. signrawtransactionnecesita redeemScripty scriptPubKeypara transacciones no confirmadas.

Parece que Bitcoin QT puede hacer referencia a sus propias transacciones no confirmadas, lo cual es un poco peligroso. Considera esto:

La primera transacción (A a B) podría llegar a la cadena de bloques después de la segunda (C a...) o podría no llegar en absoluto. En este caso, la segunda transacción no se realizará porque no será válida hasta que ocurra la primera. Aunque la segunda transacción existe dentro de Bitcoin QT, probablemente no se envíe hasta que se realice la primera.

Si desea hacer esto con transacciones sin procesar, puede crear ambas transacciones al mismo tiempo, solo sepa que la segunda no será válida (y, por lo tanto, será rechazada por la cadena de bloques) hasta que se complete la primera.

"La primera transacción (A a B) podría llegar a la cadena de bloques después de la segunda"... Creo que debes aclarar esto... la segunda transacción nunca se incluiría en un bloque a menos que la primera estuviera en el mismo o bloque anterior
@RentFree Gracias por la aclaración. Sí, la segunda transacción en realidad no estaría "en" la cadena de bloques porque no sería válida sin la primera.

Bitcoin-QT trata el cambio como aceptable para gastar depende de que el propio cliente lo haya creado dentro de sí mismo. Creando transacción con el cambio createrawtransaction como no confirmado. Bu enviar desde no.

Tengo entendido que, técnicamente, la primera confirmación es contra su propia copia de blockchain.

Entonces, aunque la transacción no se confirme en un bloque, el cliente es consciente de que es poco probable que esta transacción de cambio sea rechazada.

De hecho lógicamente no se puede rechazar si la transacción fue creada correctamente.

Podría ser rechazado debido a una tarifa de transacción insuficiente
Podría ser rechazado si se gasta el doble y la transacción de doble gasto tiene una tarifa más alta