Wrong transaction using bitcoin-cli and multiple op_return #14868

Using bitcoin-cli in order to generate a transaction with two op_return generate a wrong transaction.

bitcoin-cli createrawtransaction "[]" "{\"data\":\"ee\", \"data\":\"ff\"}"
0200000000020000000000000000036a01ee0000000000000000036a01ee00000000

Decoding the hex I obtain the following transaction with two op_return with the same value.

bitcoin-cli decoderawtransaction "0200000000020000000000000000036a01ee0000000000000000036a01ee00000000"
{
  "txid": "ed4b691958a573c8569177606c77905ecd07c36eb5eec443f17a45427bb9f5fc",
  "hash": "ed4b691958a573c8569177606c77905ecd07c36eb5eec443f17a45427bb9f5fc",
  "version": 2,
  "size": 34,
  "vsize": 34,
  "weight": 136,
  "locktime": 0,
  "vin": [
  ],
  "vout": [
    {
      "value": 0.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_RETURN -110",
        "hex": "6a01ee",
        "type": "nulldata"
      }
    },
    {
      "value": 0.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_RETURN -110",
        "hex": "6a01ee",
        "type": "nulldata"
      }
    }
  ]
}

This incorrect behavior is related to the duplicate key "data" in the JSON passed to the "createrawtransaction" command.

The problem is related to the use of outputs[name_].getValStr() in an JSON with duplicated keys https://github.com/bitcoin/bitcoin/blob/master/src/rpc/rawtransaction.cpp#L432

Although this kind of transaction wouldn't be relayed, I thought about two possible solutions:

• raise an error as it happens for the use of two identical addresses, maybe calling JSONRPCError(RPC_INVALID_PARAMETER ... if more than one "data" field is recognized - easier to implement,
• creation of the transaction correctly containing the two different op_returns, maybe need to pass one array in the data field of the passed JSON (like "data": ["ee", "ff"]) - maybe require API change.

Hi @valerio-vaccaro, deliberately choosing to correctly create the transaction, it looks i fixed this issue in https://github.com/isghe/bitcoin/tree/fix-createrawtransaction-master (and in https://github.com/isghe/bitcoin/tree/fix-createrawtransaction-v0.17.0.1 ). In my tests looks to be ok. Please can you check too?

$ ./src/bitcoin-cli createrawtransaction "[]" "[{\"mguLQ6eGCHpnmRrDwAjbPpYAHjxY6GneeQ\":\"0.1\"}, {\"data\":\"ee\"}, {\"muLYgM1L3gCzLs1bPX5cVzx3ax1f4vBcpN\":\"0.2\"},{\"data\":\"ff\"}]" | xargs ./src/bitcoin-cli decoderawtransaction
{
  "txid": "54c6fbd3b3266a4aec43ca2ed0829ac9f419dfe4a7f751a037859453f47a070a",
  "hash": "54c6fbd3b3266a4aec43ca2ed0829ac9f419dfe4a7f751a037859453f47a070a",
  "version": 2,
  "size": 102,
  "vsize": 102,
  "weight": 408,
  "locktime": 0,
  "vin": [
  ],
  "vout": [
    {
      "value": 0.10000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 0f33ba85fcad50a78088c115ec65b0a7ab30e3de OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9140f33ba85fcad50a78088c115ec65b0a7ab30e3de88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mguLQ6eGCHpnmRrDwAjbPpYAHjxY6GneeQ"
        ]
      }
    },
    {
      "value": 0.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_RETURN -110",
        "hex": "6a01ee",
        "type": "nulldata"
      }
    },
    {
      "value": 0.20000000,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 9799e353a07f1d08ab8d191408cd509ff772eabb OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9149799e353a07f1d08ab8d191408cd509ff772eabb88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "muLYgM1L3gCzLs1bPX5cVzx3ax1f4vBcpN"
        ]
      }
    },
    {
      "value": 0.00000000,
      "n": 3,
      "scriptPubKey": {
        "asm": "OP_RETURN -127",
        "hex": "6a01ff",
        "type": "nulldata"
      }
    }
  ]
}

@valerio-vaccaro it would be interesting to try the sequence explained in $ bitcoin-cli help fundrawtransaction:

Examples:

Create a transaction with no inputs
> bitcoin-cli createrawtransaction "[]" "{\"myaddress\":0.01}"

Add sufficient unsigned inputs to meet the output value
> bitcoin-cli fundrawtransaction "rawtransactionhex"

Sign the transaction
> bitcoin-cli signrawtransaction "fundedtransactionhex"

Send the transaction
> bitcoin-cli sendrawtransaction "signedtransactionhex"

Thanks @isghe, the patch work well (tested on MacOS and Linux) and generate the right transaction; fundrawtransaction and signrawtransaction correctly works on the generated transaction.

I renamed the branch to fix-createrawtransaction-multi-OP_RETURN, proceed with PR