Ich bin verwirrt über die Darstellung des Bitcoin-Betrags im "value"
Feld einer Rohtransaktion.
Wenn ich zum Beispiel 0,05 BTC ausgeben möchte, welcher Wert ist der richtige?
"value" : 0.05
"value" : 50000000
Oder ist beides erlaubt? Es scheint, dass bitcoin-cli sendfrom ...
die erstere Darstellung generiert wird, und eine schnelle Überprüfung einiger Transaktionen auf blockchain.info zeigte nur Transaktionen, die die letztere verwenden.
Ich verfolge derzeit das Beispiel spend-p2sh-txout.py von python-bitcoinlib, in dem eine Rohtransaktion erstellt wird, die die Satoshi-Darstellung verwendet.
In meiner Anwendung wird die folgende Transaktion im regtest
Modus erstellt, der über blockchain.info dekodiert wird :
{
"lock_time":0,
"size":224,
"inputs":[
{
"prev_out":{
"index":0,
"hash":"bf7a52d8ddbc2faf3f110fe7aef4fb2ef68058ab607c381a098062bc2f53d613"
},
"script":"483045022100dbbcce4fcf6ff6af11c5c365fe736a01ed6808e3a7369f5a54285f3cf7b91b7002202bc38a8b7631d0749ec519d28ae87885a3881afc52b741aec55b8952bda81ef501410468d77eb31494cb851898661e8359f7388283317c7e79cf979af7c99c379a5a641cc476663d0e8a91c458f6c86fdd8b76e3db3e0e06ba0527748690fae4673b13"
}
],
"version":1,
"vin_sz":1,
"hash":"985ca8c35dd2e0bd4c583a3254352f740445fb0c19cca6922a3f71458ede6246",
"vout_sz":1,
"out":[
{
"script_string":"OP_DUP OP_HASH160 cadcdc47fcdbeeb3ad212b4a4657d7b4da759a82 OP_EQUALVERIFY OP_CHECKSIG",
"address":"1KVe5QTdQ4cXfqmtJBxqKQrei5zvCmRpWh",
"value":10000000,
"script":"76a914cadcdc47fcdbeeb3ad212b4a4657d7b4da759a8288ac"
}
]
}
Diese Transaktion soll einfach die Gelder weiterleiten, die durch vorherige manuelle Transaktionen erhalten wurden, die über erstellt bitcoin-cli -regtest sendfrom alice mtx3RXD3DVgc1BDSeHRFkSVcmSw8BfdbS2 0.1
wurden, wobei alice
sich ein bestehendes Konto befindet. Die Transaktion sieht wie folgt aus:
{
"hex" : "01000000021fe8d299c9a91892895a7cf1bd03519cc41e37deb723e32abd4d54b089be361000000000494830450221008ea7e7ab056daf158561329f7879c4cddb6dce741be106572902d50aab9e1c110220531e3cbfd2491412d9ddc6f04c77d2e9153b8e76df3676cd1d40cd81700c723901ffffffff9745aa1ff0c8d4f9079e93a30c08ac85f3c1dc6870a2272c59e2915d05f76c40010000006b48304502210085a3a69fdb2242bea5b7fa2bb3889e2d0c04d80614cde72053ba0b63e0acef9c022068b04f769a67ce896c09b0c43efd2d53542a6530f51b0d5144bea06e8ffea98a01210222485cf467f5359416d5dcf20293adce14bd6039cffc246ae7d6f49f541ae3b6ffffffff0227d80f00000000001976a9147b441644e981eaa7b9acbb66ddd029540ae3771388ac80969800000000001976a914935850c4a25f44f4e057aa2109a885537056727288ac00000000",
"txid" : "bf7a52d8ddbc2faf3f110fe7aef4fb2ef68058ab607c381a098062bc2f53d613",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "1036be89b0544dbd2ae323b7de371ec49c5103bdf17c5a899218a9c999d2e81f",
"vout" : 0,
"scriptSig" : {
"asm" : "30450221008ea7e7ab056daf158561329f7879c4cddb6dce741be106572902d50aab9e1c110220531e3cbfd2491412d9ddc6f04c77d2e9153b8e76df3676cd1d40cd81700c723901",
"hex" : "4830450221008ea7e7ab056daf158561329f7879c4cddb6dce741be106572902d50aab9e1c110220531e3cbfd2491412d9ddc6f04c77d2e9153b8e76df3676cd1d40cd81700c723901"
},
"sequence" : 4294967295
},
{
"txid" : "406cf7055d91e2592c27a27068dcc1f385ac080ca3939e07f9d4c8f01faa4597",
"vout" : 1,
"scriptSig" : {
"asm" : "304502210085a3a69fdb2242bea5b7fa2bb3889e2d0c04d80614cde72053ba0b63e0acef9c022068b04f769a67ce896c09b0c43efd2d53542a6530f51b0d5144bea06e8ffea98a01 0222485cf467f5359416d5dcf20293adce14bd6039cffc246ae7d6f49f541ae3b6",
"hex" : "48304502210085a3a69fdb2242bea5b7fa2bb3889e2d0c04d80614cde72053ba0b63e0acef9c022068b04f769a67ce896c09b0c43efd2d53542a6530f51b0d5144bea06e8ffea98a01210222485cf467f5359416d5dcf20293adce14bd6039cffc246ae7d6f49f541ae3b6"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.01038375,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 7b441644e981eaa7b9acbb66ddd029540ae37713 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9147b441644e981eaa7b9acbb66ddd029540ae3771388ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mrkiyR5zrvxZtCucHYZTXfs3t2Kz9UNuVS"
]
}
},
{
"value" : 0.10000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 935850c4a25f44f4e057aa2109a8855370567272 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914935850c4a25f44f4e057aa2109a885537056727288ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mtx3RXD3DVgc1BDSeHRFkSVcmSw8BfdbS2"
]
}
}
],
"blockhash" : "0000c177c89fab9ff7b59be7d38b61c94c3b8492a3633863c382fba73f0ede0c",
"confirmations" : 6,
"time" : 1420621337,
"blocktime" : 1420621337
}
bitcoind
Die von meiner Anwendung erstellte Transaktion wird von meiner lokalen Instanz abgelehnt , debug.log
sagt:
ERROR: CheckInputs() : 985ca8c35dd2e0bd4c583a3254352f740445fb0c19cca6922a3f71458ede6246 value in < value out
Im Moment vermute ich, dass der Fehler durch die unterschiedlichen Darstellungen verursacht wird, oder übersehe ich ein anderes Problem?
Nachdem ich den Kommentar von George berücksichtigt hatte, fand ich heraus, dass sich die Ergebnisse des Parsens von Rohtransaktionen tatsächlich zwischen der lokalen Verwendung bitcoind
und dem Parsen der Transaktion durch blockchain.info unterscheiden.
Das heißt, beide Darstellungen sind gleichwertig und es gibt keinen Unterschied zwischen der tatsächlichen Transaktion.
Da meine Transaktion abgelehnt wurde, habe ich dies überprüft, indem ich Folgendes verwendet habe:
bitcoin-cli -regtest decoderawtransaction 01000000012db211b32295f7ca3e9cdd9f3f0ea12bd938f8fc62c372f1147882dea35a197e000000008b4830450220772661303176b4505f16c512edfdc0dda7a480ace7f4dd23275902e0575c1e8b022100d356bd2e8b4abd366a6e71abaeb689f682edeae42355c638cbb0be4a3df5a924014104aa69850ffcdb48814354c2a9828611a54d9baafa215c8756eb2b53597f0beeef9a393071b12ab535282ae62778b103a8b3de4ecd4505f33343d58ca9bb4f1d2effffffff0180f0fa02000000001976a91426fc9e0484367d611996e0ccf583aa9976a0c98488ac00000000
Vorher war mir dieser Befehl nicht bekannt und ich habe blockchain.info verwendet .
Ich habe dies in meiner Frage aktualisiert und hervorgehoben.
Nachdem ich das geklärt hatte, fand ich heraus, dass der Fehler ( tx-hash value in < value out
) von meiner Anwendung verursacht wurde. Ich ging davon aus, dass die Ausgabeadresse, die mir wichtig ist, immer die erste in der Transaktion ist (dh "n" : 0
).
Der Fehler wird tatsächlich durch unterschiedliche Darstellungen verursacht.
In tx 985ca8c35dd2e0bd4c583a3254352f740445fb0c19cca6922a3f71458ede6246
versuchen Sie, 10.000.000 Bitcoins an die Adresse zu senden, 1KVe5QTdQ4cXfqmtJBxqKQrei5zvCmRpWh
während Sie zu diesem Zweck eine einzige Ausgabe im Wert von 0,01038375 Bitcoins ausgeben.
createrawtransaction
konstruktionsbedingt wird nicht geprüft, ob die Gesamtmenge der Eingaben gleich oder größer als die Gesamtmenge der Ausgaben ist. signrawtransaction
kümmert sich auch nicht wirklich darum, also kommt es darauf an , wer sendrawtransaction
diese Prüfung durchführt, und wenn inputs value
< outputs value
, schlägt sie mit dieser Meldung fehl: CheckInputs() : tx-hash value in < value out
.
Rmn
"value" : 2249930000
, dh die Satoshi-Darstellung.Benutzer11221
blockchain.info
Antwort? Ich würde vorschlagen, dass Sie verwendengetrawtransaction tx-id 1
, um diese Abfrage durchzuführen und Ihre Frage zu aktualisieren, und dann können wir vielleicht eine Lösung für Ihr Problem finden.Rmn
testnet
und in entwickleregtest
, also habe ich keine Blockchain-Datei ... würde ziemlich lange dauern, um es jetzt zu bekommen. Ich werde es jedoch überprüfentestnet
und meine Frage aktualisieren.Benutzer11221
regtest
wird die Blockchain im laufenden Betrieb generiert, sodass Sie nicht wirklich etwas anderes von anderen verbundenen Knoten herunterladen müssen (die Ihnen, falls vorhanden, auf jeden Fall gehören sollten).Rmn
bitcoind
vs.blockchain.info
... Also werde ich meine ganze Frage umformulieren.