<p>After considering the comment by <a href="https://bitcoin.stackexchange.com/questions/35327/value-field-in-raw-transaction-rounded-bitcoins-float-or-satoshis#comment40107_35330">George</a>, I found out that indeed the results of parsing raw transaction differs between using <code>bitcoind</code> locally and letting blockchain.info parse the transaction.</p>

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

<p>Since my transaction was being rejected, I checked this by using:</p>

<pre><code>bitcoin-cli -regtest decoderawtransaction 01000000012db211b32295f7ca3e9cdd9f3f0ea12bd938f8fc62c372f1147882dea35a197e000000008b4830450220772661303176b4505f16c512edfdc0dda7a480ace7f4dd23275902e0575c1e8b022100d356bd2e8b4abd366a6e71abaeb689f682edeae42355c638cbb0be4a3df5a924014104aa69850ffcdb48814354c2a9828611a54d9baafa215c8756eb2b53597f0beeef9a393071b12ab535282ae62778b103a8b3de4ecd4505f33343d58ca9bb4f1d2effffffff0180f0fa02000000001976a91426fc9e0484367d611996e0ccf583aa9976a0c98488ac00000000
</code></pre>

<p>Before, I was not aware of this command and used <a href="https://blockchain.info/decode-tx" rel="nofollow noreferrer">blockchain.info</a>.</p>

<p>I have updated and highlighted this in my question.</p>

<p>After getting this clear, I found out that the error (<code>tx-hash value in &lt; value out</code>) 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., <code>"n" : 0</code>).</p>

CC BY-SA 3.0
2015-01-08T07:13:33.110Z
2015-01-08T07:13:33.110Z
2017-04-13T12:47:33.660Z
Rmn
<p>I am getting confused about the Bitcoin amount presentation in a raw transaction's <code>"value"</code> field.</p>

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

<pre><code>"value" : 0.05
"value" : 50000000
</code></pre>

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

<p>I am currently following the example <a href="https://github.com/petertodd/python-bitcoinlib/blob/master/examples/spend-p2sh-txout.py" rel="nofollow">spend-p2sh-txout.py</a> of python-bitcoinlib, in which a raw transaction is being created that uses the Satoshi representation.</p>

<p>Im my application, the following transaction is being created in the <code>regtest</code> mode, <strong><em>decoded via <a href="https://blockchain.info/decode-tx" rel="nofollow">blockchain.info</a></em></strong>:</p>

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

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

<pre><code>{
    "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
}
</code></pre>

<p>The transaction created by my application is being rejected by my local <code>bitcoind</code> instance, <code>debug.log</code> says:</p>

<pre><code>ERROR: CheckInputs() : 985ca8c35dd2e0bd4c583a3254352f740445fb0c19cca6922a3f71458ede6246 value in &lt; value out
</code></pre>

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

<bitcoind><raw-transaction><python>
"value" field in raw transaction: Rounded Bitcoins (float) or Satoshis?
Rmn
# "value" field in raw transaction: Rounded Bitcoins (float) or Satoshis?

(Asked by: username_0 on 2015-01-07)

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](https://github.com/petertodd/python-bitcoinlib/blob/master/examples/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](https://blockchain.info/decode-tx)***:

```
{
   "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?

**Tags:** bitcoind, raw-transaction, python


---

## 1 answers

### Answer by username_0 on 2015-01-08. Score: 2 | Accepted answer

After considering the comment by [George](https://bitcoin.stackexchange.com/questions/35327/value-field-in-raw-transaction-rounded-bitcoins-float-or-satoshis#comment40107_35330), 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](https://blockchain.info/decode-tx).

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`).


---

