Topic: Possible bug in decoderawtransaction in 16.02? (Read 363 times)

Nice to see this get fixed, as you commented before, no one talk about that second parameter for decoderawtransaction, the true at end makes the difference. avoiding the problem. Maybe you can change the topic to Fixed and close the thread now.  

Thanks, very informative. I didn't know decoderawtranscaction was intended to be used during transaction creation steps.

Yes, this does indeed work! The documentation found at https://bitcoin.org/en/developer-reference#decoderawtransaction doesn't list the second parameter. According to the documentation decoderawtransaction only takes a single parameter. Guess the documentation isn't up to date here.

One last question about the heuristic in this specific case: It's pretty clear the assumption made this was a transaction without witness data is wrong based on the fact it's reporting a negative value as an amount. So shouldn't the "heuristic algoritm" reassess itself when the output generated was clearly wrong:

Yes, this does indeed work! The documentation found at https://bitcoin.org/en/developer-reference#decoderawtransaction doesn't list the second parameter. According to the documentation decoderawtransaction only takes a single parameter. Guess the documentation isn't up to date here.

One last question about the heuristic in this specific case: It's pretty clear the assumption made this was a transaction without witness data is wrong based on the fact it's reporting a negative value as an amount. So shouldn't the "heuristic algoritm" reassess itself when the output generated was clearly wrong:


I might be oversimplifying things here but it seems to me this would lead to a lot less incorrect assumptions from heuristics.

This is a known issue and unfortunately it cannot be fixed without a fork. The issue lies with the format of a segwit transaction itself. A segwit transaction, under some circumstances, can be interpreted as either a 0 input, 1 output transaction, or as a witness transaction. Since getrawtransaction fetches transactions from blocks themselves or from the mempool, the transaction must be a valid network transaction and thus witness serialization can be attempted safely as a first step and only deserializing as non-witness if the witness deserialization fails.

However, decoderawtransaction behaves differently as it is intended to be used during the transaction creation steps. This means that it must be able to handle 0-input, 1 output transactions (which are inherently non-witness) as users may create a 0-input, 1 output transaction, decode it, and then pass it to fundrawtransaction to get inputs. But because some 0-input, 1 output transactions can be interpreted as witness transactions, and some witness transactions can be interpreted as 0-input, 1 output transactions, decoderawtransaction does not always succeed to decoding a transaction correctly. It uses some heuristics in order to decrease the number of false decodings, but sometimes, as you can clearly see, it's wrong.

Fortunately, if you know that a transaction is witness you can set the iswitness argument (added in 0.16) to true to tell it explicitly to decode the transaction as witness. You can set it to false for non-witness decoding. Not setting it uses the heuristics.

So your command will be something like:

bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4 true

Results in:
{
   "result": {
      "txid": "00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4",
      "hash": "68749aae9aeb5d1a6971ed16e0244f648aadcffbfe8ff6c6eec6fbeb1e43e1c7",
      "version": 1,
      "size": 249,
      "vsize": 168,
      "locktime": 0,
      "vin": [
         {
            "txid": "d77c1bc59aea11eff5a289d8e79b92d7c19a06e993eeb44be6bbda8fc3e45f68",
            "vout": 0,
            "scriptSig": {
               "asm": "001422234e073571fde8414ae49a8fb294c712a96c88",
               "hex": "16001422234e073571fde8414ae49a8fb294c712a96c88"
            },
            "txinwitness": [
               "30440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e7 74304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff87901",
               "02355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e"
            ],
            "sequence": 4294967295
         }
      ],
      "vout": [
         {
            "value": 2.57409060,
            "n": 0,
            "scriptPubKey": {
               "asm": "OP_HASH160 85fdf348463ede1237e06e471cce02746b9220fd OP_EQUAL",
               "hex": "a91485fdf348463ede1237e06e471cce02746b9220fd87",
               "reqSigs": 1,
               "type": "scripthash",
               "addresses": [
                  "3DuW1qNmzF3BtrbVSornifUb9EseA8KAGE"
               ]
            }
         },
         {
            "value": 0.20000000,
            "n": 1,
            "scriptPubKey": {
               "asm": "OP_DUP OP_HASH160 eee47d625f1e4a72e579ca884363ebda0f11f4b1 OP_EQUALVERIFY OP_CHECKSIG",
               "hex": "76a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac",
               "reqSigs": 1,
               "type": "pubkeyhash",
               "addresses": [
                  "1Nn9YQSAkLXU1d51fnkxmXSbB8DXePWnMh"
               ]
            }
         }
      ],
      "hex": "01000000000101685fe4c38fdabbe64bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd70 00000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f000000 0017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47 d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e 69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd 9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279 cd76255a4e643b9e00000000",
      "blockhash": "0000000000000000013aa3efc9b6e19ec6b43f55596a5e7246de92e881537297",
      "confirmations": 57144,
      "time": 1504306950,
      "blocktime": 1504306950
   },
   "error": null,
   "id": null
}

Interesting found, i checked this possible bug/problem with Bitcoin Core 0.16.2 (txindex disabled, so i just try decoderawtransaction) and few explorer/services with getrawtransaction/decoderawtransaction show different result.

Gonna try it after reindexing is done.

That's referring to bitcoin core before 0.15.0. As I've posted multiple times now that's not the case for me. So the original question remains why this is (still) happening with 0.16.02?

Anyone who can do this simple test with running the latest version of bitcoin core (0.16.02) and list their result:

Ok, i found some one with the same problem and the explanation:


Please take a look to https://github.com/bitcoin/bitcoin/issues/11157 'Fail to decode transaction correctly.'

That transaction is a witness transaction, but 0.14.2 is interpreting it as non-witness, which is why the hash is the same as the txid and there are no inputs. 0.15.0 interprets it fine.

Please post the output from: And let's verify if you have the core version 0.16.2

I ran into a transaction which I can't decode properly using bitcoin-cli decoderawtransaction:


So no inputs, and a negative output value without any address. Does anyone have an idea what's going on here?

I thought maybe somehow my local files got corrupted but I did the same thing at http://chainquery.com/bitcoin-api/decoderawtransaction and got the exact same result.

What version of bitcoin core are you running? That might be the issue here, as it is probably(?) not recognizing the payment script.