"value" field in raw transaction: Rounded Bitcoins (float) or Satoshis?

Question

I am getting confused about the Bitcoin amount presentation in a raw transaction's "value" field.

If i want to spend 0.05 BTC, for instance, which of these is the correct value?

"value" : 0.05
"value" : 50000000

Or are both allowed? It seems that bitcoin-cli sendfrom ... generates the former representation, and a quick check of some transactions on blockchain.info just showed transactions using the latter one.

I am currently following the example spend-p2sh-txout.py of python-bitcoinlib, in which a raw transaction is being created that uses the Satoshi representation.

Im my application, the following transaction is being created in the regtest mode, decoded via blockchain.info:

{
   "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"
      }
   ]
}

This transaction is meant to simply relay the funds received by previous manual transaction created via bitcoin-cli -regtest sendfrom alice mtx3RXD3DVgc1BDSeHRFkSVcmSw8BfdbS2 0.1, where alice is an existing account. The transaction looks as follows:

{
    "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
}

The transaction created by my application is being rejected by my local bitcoind instance, debug.log says:

ERROR: CheckInputs() : 985ca8c35dd2e0bd4c583a3254352f740445fb0c19cca6922a3f71458ede6246 value in < value out

Right now, I am suspecting that the error is caused by the different representations, or am I missing another problem?

Answer 1

After considering the comment by George, I found out that indeed the results of parsing raw transaction differs between using bitcoind locally and letting blockchain.info parse the transaction.

I.e., both representations are equivalent and there is no difference between the actual transaction.

Since my transaction was being rejected, I checked this by using:

bitcoin-cli -regtest decoderawtransaction 01000000012db211b32295f7ca3e9cdd9f3f0ea12bd938f8fc62c372f1147882dea35a197e000000008b4830450220772661303176b4505f16c512edfdc0dda7a480ace7f4dd23275902e0575c1e8b022100d356bd2e8b4abd366a6e71abaeb689f682edeae42355c638cbb0be4a3df5a924014104aa69850ffcdb48814354c2a9828611a54d9baafa215c8756eb2b53597f0beeef9a393071b12ab535282ae62778b103a8b3de4ecd4505f33343d58ca9bb4f1d2effffffff0180f0fa02000000001976a91426fc9e0484367d611996e0ccf583aa9976a0c98488ac00000000

Before, I was not aware of this command and used blockchain.info.

I have updated and highlighted this in my question.

After getting this clear, I found out that the error (tx-hash value in < value out) was caused by my application. I was assuming that the output address I care about is always the first one on the transaction (i.e., "n" : 0).

Answer 2

The error is caused indeed by different representations.

In tx 985ca8c35dd2e0bd4c583a3254352f740445fb0c19cca6922a3f71458ede6246 you are trying to send 10,000,000 bitcoins to address 1KVe5QTdQ4cXfqmtJBxqKQrei5zvCmRpWh while spending for that purpose a single output of value of 0.01038375 bitcoins.

createrawtransaction by design will not check if the inputs' total amount is equal or bigger in value than the outputs' total amount. signrawtransaction doesn't really care about this either so it all comes down to sendrawtransaction which performs this check and if inputs value < outputs value it fails with this message: CheckInputs() : tx-hash value in < value out.