Wie verwendet ein Wallet unbestätigte Ausgaben als Eingaben nach unbestätigten Transaktionen?

Ich habe 10 BTC auf Adresse A.

Mit einer Rohtransaktion sende ich 5 BTC von A nach B und setze die Änderungsadresse als A selbst. Da die Transaktion von A nach B nicht bestätigt ist, kann ich die restlichen 5 BTC nicht ausgeben.

Aber ich habe gesehen, dass die QT-Wallet dies kann. Ex:

Ich habe 10 BTC auf Adresse A. Ich sende 5 BTC an B. Das Wallet erstellt eine neue Adresse C und legt sie als Änderungsadresse fest. Dann versuche ich, die 5 BTC auf der Brieftasche zu verwenden, und es funktioniert. Es erlaubt mir, von Adresse C zu senden.

1) Verwendet das Wallet hier unbestätigte Ausgaben als Eingaben?

2) Wenn ja, wie macht es das und wie kann ich es mit Rohtransaktionen machen?

3) Wenn nicht, was ist hier los?

Antworten (4)

Verwendet das Wallet hier unbestätigte Outputs als Inputs?

Ja.

Wenn ja, wie macht es das

Mit Ausnahme von Coinbase-Transaktionen sind Transaktionen unabhängig von Blöcken. Eine Transaktion, die eine unbestätigte Eingabe ausgibt, sieht genauso aus wie eine Transaktion, die eine bestätigte Eingabe ausgibt.

Es ist sicher für Bitcoin-Qt, unbestätigtes Wechselgeld auszugeben, da es weiß, dass die Eingabe gültig ist und irgendwann (wenn auch wahrscheinlich langsam) bestätigt wird. Es wäre für Bitcoin-Qt nicht sicher, unbestätigte Eingaben auszugeben, die es nicht selbst erstellt hat, da sie möglicherweise nie bestätigt werden, was zu dauerhaft gebundenen Mitteln führt. (Sehr alte Versionen von Bitcoin haben diesen Fehler gemacht, aber er wurde nach weit verbreiteten Problemen korrigiert.)

Wie kann ich es mit rohen Transaktionen machen?

Sie können die Transaktion createrawtransactionnormal erstellen, aber Sie müssen signrawtransactioneinige zusätzliche Informationen über die unbestätigte Transaktion in ihrem zweiten Parameter angeben.

createrawtransaction unterstützt die Ausgabe unbestätigter Eingaben; siehe gist.github.com/gavinandresen/3966071#file-twoofthree-sh-L42 für ein Beispiel.
@gavinandresen Wenn ich mir das genauer anschaue, scheint es mir, dass wir beide falsch liegen. Betrachtet in Ihrem Beispiel createrawtransactionnicht wirklich das bereitgestellte redeemScriptoder scriptPubKeyAFAICT. createrawtransactionverwendet alle Daten, die Sie ihm geben, und es verwendet nicht einmal die Blockdatenbank. signrawtransactionbenötigt redeemScriptund scriptPubKeyfür unbestätigte Transaktionen.

Es sieht so aus, als könnte Bitcoin QT auf seine eigenen unbestätigten Transaktionen verweisen, was ziemlich gefährlich ist. Bedenken Sie:

Die erste Transaktion (A nach B) kann in der Blockchain nach der zweiten (C nach ...) ankommen oder gar nicht ankommen. In diesem Fall wird die zweite Transaktion nicht durchgeführt, da sie nicht gültig ist, bis die erste erfolgt. Auch wenn die zweite Transaktion innerhalb von Bitcoin QT existiert, wird sie wahrscheinlich erst versendet, wenn die erste durchgegangen ist.

Wenn Sie dies mit rohen Transaktionen tun möchten, können Sie beide Transaktionen gleichzeitig erstellen, wissen Sie nur, dass die zweite ungültig ist (und daher von der Blockchain abgelehnt wird), bis die erste durchgeht.

"Die erste Transaktion (A nach B) könnte nach der zweiten in der Blockkette ankommen" ... Ich denke, Sie müssen dies klarstellen ... die 2. Transaktion würde niemals in einen Block aufgenommen, es sei denn, die 1. wäre in derselben oder früherer Block
@RentFree Danke für die Klarstellung. Ja, die 2. Transaktion würde es nicht wirklich in die Blockchain schaffen, da sie ohne die erste ungültig wäre.

Bitcoin-QT, das das Wechselgeld als in Ordnung betrachtet, hängt davon ab, ob der Client es selbst erstellt hat. Transaktion erstellen mit createrawtransaction change als unbestätigt. Bu sendfrom nicht.

Mein Verständnis ist, dass technisch gesehen die erste Bestätigung gegen Ihre eigene Blockchain-Kopie erfolgt.

Obwohl die Transaktion möglicherweise nicht in einem Block bestätigt wird, ist sich der Kunde bewusst, dass diese Änderungstransaktion wahrscheinlich nicht abgelehnt wird.

Tatsächlich kann es logischerweise nicht abgelehnt werden, wenn die Transaktion korrekt erstellt wurde.

Es könnte aufgrund einer nicht ausreichenden Transaktionsgebühr abgelehnt werden
Es könnte abgelehnt werden, wenn es doppelt ausgegeben wird und die Transaktion mit doppelter Ausgabe eine höhere Gebühr hat