Possible bug in decoderawtransaction in 16.02?

[TheArchaeologist]

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

Code:

bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4

Returns this raw transaction:
01000000000101685fe4c38fdabbe64bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e00000000

Decode by:
bitcoin-cli decoderawtransaction 01000000000101685fe4c38fdabbe64bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e00000000

Returns:
{
  "txid": "68749aae9aeb5d1a6971ed16e0244f648aadcffbfe8ff6c6eec6fbeb1e43e1c7",
  "hash": "68749aae9aeb5d1a6971ed16e0244f648aadcffbfe8ff6c6eec6fbeb1e43e1c7",
  "version": 1,
  "size": 249,
  "vsize": 249,
  "locktime": 0,
  "vin": [
  ],
  "vout": [
    {
      "value": -49104543721.81252095,
      "n": 0,
      "scriptPubKey": {
        "asm": "b4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede12 e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93 OP_RIPEMD160 9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402 3e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879 33 23605 OP_OR 796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b OP_NUMNOTEQUAL",
        "hex": "4bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e",
        "type": "nonstandard"
      }
    }
  ]
}

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.

Edit: This is running the latest version (16.02) of bitcoind with tx-index enabled.

[1714003336]

1714003336

[1714003336]

1714003336

[1714003336]

1714003336

[1714003336]

1714003336

[AdolfinWolf]

I get the following (Using https://live.blockcypher.com/btc/decodetx/):

Code:

{
    "addresses": [
        "3PM64WMcNgGCkeAyGYuDX4TMxM4QuQuu7Z", 
        "3DuW1qNmzF3BtrbVSornifUb9EseA8KAGE", 
        "1Nn9YQSAkLXU1d51fnkxmXSbB8DXePWnMh"
    ], 
    "block_height": -1, 
    "block_index": -1, 
    "confirmations": 0, 
    "double_spend": false, 
    "fees": 72484, 
    "hash": "00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4", 
    "inputs": [
        {
            "addresses": [
                "3PM64WMcNgGCkeAyGYuDX4TMxM4QuQuu7Z"
            ], 
            "age": 483040, 
            "output_index": 0, 
            "output_value": 277481544, 
            "prev_hash": "d77c1bc59aea11eff5a289d8e79b92d7c19a06e993eeb44be6bbda8fc3e45f68", 
            "script": "16001422234e073571fde8414ae49a8fb294c712a96c88", 
            "script_type": "pay-to-script-hash", 
            "sequence": 4294967295, 
            "witness": [
                "30440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff87901", 
                "02355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e"
            ]
        }
    ], 
    "outputs": [
        {
            "addresses": [
                "3DuW1qNmzF3BtrbVSornifUb9EseA8KAGE"
            ], 
            "script": "a91485fdf348463ede1237e06e471cce02746b9220fd87", 
            "script_type": "pay-to-script-hash", 
            "value": 257409060
        }, 
        {
            "addresses": [
                "1Nn9YQSAkLXU1d51fnkxmXSbB8DXePWnMh"
            ], 
            "script": "76a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac", 
            "script_type": "pay-to-pubkey-hash", 
            "value": 20000000
        }
    ], 
    "preference": "high", 
    "received": "2018-09-05T18:23:04.696897369Z", 
    "relayed_by": "54.224.245.11", 
    "size": 140, 
    "total": 277409060, 
    "ver": 1, 
    "vin_sz": 1, 
    "vout_sz": 2
}

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

I'm curious as well as to what exactly makes these two services give different outputs.

[TheArchaeologist]

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

I'm running latest version of core with -txindex enabled and fully synced:

Code:

bitcoin-cli getnetworkinfo

Returns:
  "version": 160200,
  "subversion": "/Satoshi:0.16.2/",
  "protocolversion": 70015,
  "localservices": "000000000000040d",
  "localrelay": true,
  "timeoffset": 0,
  "networkactive": true,
   ......

Anyone with a full node runnig who can try the same as I did?

[seoincorporation]

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

Code:

bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4

Returns this raw transaction:
01000000000101685fe4c38fdabbe64bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e00000000

Decode by:
bitcoin-cli decoderawtransaction 01000000000101685fe4c38fdabbe64bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e00000000

Returns:
{
  "txid": "68749aae9aeb5d1a6971ed16e0244f648aadcffbfe8ff6c6eec6fbeb1e43e1c7",
  "hash": "68749aae9aeb5d1a6971ed16e0244f648aadcffbfe8ff6c6eec6fbeb1e43e1c7",
  "version": 1,
  "size": 249,
  "vsize": 249,
  "locktime": 0,
  "vin": [
  ],
  "vout": [
    {
      "value": -49104543721.81252095,
      "n": 0,
      "scriptPubKey": {
        "asm": "b4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede12 e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93 OP_RIPEMD160 9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402 3e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879 33 23605 OP_OR 796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b OP_NUMNOTEQUAL",
        "hex": "4bb4ee93e9069ac1d7929be7d889a2f5ef11ea9ac51b7cd7000000001716001422234e073571fde8414ae49a8fb294c712a96c88ffffffff0224c0570f0000000017a91485fdf348463ede1237e06e471cce02746b9220fd87002d3101000000001976a914eee47d625f1e4a72e579ca884363ebda0f11f4b188ac024730440220768f93a61c9630eea0553d2a1a8e69ffb3307681c7561cbc8a17643b82e44f3402203e774304ea44bcc4f1269cf4a7a4652c49eacbd9250d57e71d769fdc52cff879012102355c851b796e318091b404efab45e9fc34cf6184aa0bb279cd76255a4e643b9e",
        "type": "nonstandard"
      }
    }
  ]
}

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.

http://chainquery.com/bitcoin-api/getinfo

Code:

{
	"result": null,
	"error": {
		"code": -32601,
		"message": "getinfo\n\nThis call was removed in version 0.16.0. Use the appropriate fields from:\n- getblockchaininfo: blocks, difficulty, chain\n- getnetworkinfo: version, protocolversion, timeoffset, connections, proxy, relayfee, warnings\n- getwalletinfo: balance, keypoololdest, keypoolsize, paytxfee, unlocked_until, walletversion\n\nbitcoin-cli has the option -getinfo to collect and format these in the old format."
	},
	"id": null
}

As AdolfinWolf say, this is a better source: https://live.blockcypher.com/btc/decodetx/

Please post the output from:

Code:

bitcoin-cli getinfo

And let's verify if you have the core version 0.16.2

[TheArchaeologist]

Please post the output from:

Code:

bitcoin-cli getinfo

And let's verify if you have the core version 0.16.2

As requested:

Code:

bitcoin-cli -getinfo 

{
  "version": 160200,
  "protocolversion": 70015,
  "walletversion": 130000,
  "balance": 0.00000000,
  "blocks": 540088,
  "timeoffset": 0,
  "connections": 8,
  "proxy": "",
  "difficulty": 6727225469722.534,
  "testnet": false,
  "keypoololdest": 1504256530,
  "keypoolsize": 1000,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "warnings": ""
}

And to be complete the output i get when using bitcoin-cli getinfo (so not -getinfo) as you requested):
error code: -32601
error message:
getinfo

This call was removed in version 0.16.0. Use the appropriate fields from:
- getblockchaininfo: blocks, difficulty, chain
- getnetworkinfo: version, protocolversion, timeoffset, connections, proxy, relayfee, warnings
- getwalletinfo: balance, keypoololdest, keypoolsize, paytxfee, unlocked_until, walletversion

bitcoin-cli has the option -getinfo to collect and format these in the old format.

About the same as I posted before with the now used getnetworkinfo. So I am running the latest version.

Can anyone repeat the steps I did with bitcoin core 16.02 running and tx-index enabled since it looks like a bug to me.

[seoincorporation]

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

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 take a look to https://github.com/bitcoin/bitcoin/issues/11157 'Fail to decode transaction correctly.'

[TheArchaeologist]

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

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 take a look to https://github.com/bitcoin/bitcoin/issues/11157 'Fail to decode transaction correctly.'

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:

Code:

bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4

And then:
bitcoin-cli decoderawtransaction <output from previous getrawtransaction>

[ABCbits]

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.

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

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 take a look to https://github.com/bitcoin/bitcoin/issues/11157 'Fail to decode transaction correctly.'

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:

Code:

bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4

And then:
bitcoin-cli decoderawtransaction <output from previous getrawtransaction>

I wonder if that happens because you were using/running older Bitcoin Core which don't recognize witness transaction and then you use newer client, but the client never rescan/ask for witness data to other nodes?

Gonna try it after reindexing is done.

[TheArchaeologist]

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.

Did you get the same results as I did?

Gonna try it after reindexing is done.

Thanks a lot! Keep us posted

[TheArchaeologist]

Just to add another piece to the puzzle: I do get the right response when overriding the second parameter of getrawtransaction to "true", as stated in the  documentation https://bitcoin.org/en/developer-reference#getrawtransaction

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
}

Summing up my experience:
Works:
bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4 true

Fails:
bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4
Followed by using the  output from this step as input to decoderawtransaction
bitcoin-cli decoderawtransaction <output from getrawtransaction above>

Expected:
bitcoin-cli getrawtransaction <txid> true
is equal to
bitcoin-cli getrawtransaction <txid> ->rawtransaction
bitcoin-cli decoderawtransaction <rawtransaction>

[achow101]

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:

Code:

bitcoin-cli decoderawtransaction <tx> true

[TheArchaeologist]

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.

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

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:

Code:

bitcoin-cli decoderawtransaction <tx> true

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:

Code:

Input -> Trying as non witness -> Output is valid -> Done
Input -> Trying as non witness -> Output is invalid -> Trying as witness ->Output is valid -> Done

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

[achow101]

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.

Yeah, those docs tend to lag a few versions. The most up to date versions exist in the code itself. You can get those docs by doing

Code:

bitcoin-cli help <command>

It will give you the help for the command.

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:

Code:

Input -> Trying as non witness -> Output is valid -> Done
Input -> Trying as non witness -> Output is invalid -> Trying as witness ->Output is valid -> Done

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

Indeed, that probably would help. The heuristic currently is actually rather dumb. IIRC it decodes as non-witness first and then checks for whether there are invalid opcodes in the scripts of any inputs. We could certainly have it check the output amounts to see if they are sane (between 0 and 21 million).

[seoincorporation]

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.

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

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:

Code:

bitcoin-cli decoderawtransaction <tx> true

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:

Code:

Input -> Trying as non witness -> Output is valid -> Done
Input -> Trying as non witness -> Output is invalid -> Trying as witness ->Output is valid -> Done

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

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. 

[TheArchaeologist]

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.  

The problem itself isn't fixed in my opinion since the heuristic part still can result in bogus output for decoderawtransaction. The given workaround will only be usable if you can reference a transaction-id. That will not be the case if I constructed a raw transaction which I want to check with decoderawtransaction. Thread should only be closed when this is no longer the case.

This should produce the same outcome (as mentioned before and as a test):

Code:

bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4
bitcoin-cli decoderawtransaction <output from previous getrawtransaction>

VERSUS

bitcoin-cli getrawtransaction 00b09964bf7080b065e3dbc5ff91b778283d5f513008daea3d04d8ff9d5844b4 true

Note the first approach gives the bogus output with a value of -49104543721.81252095. The second output will produce the correct output.