

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.
"\nMark in-wallet transaction <txid> as abandoned\n"
                "This will mark this transaction and all its in-wallet descendants as abandoned which will allow\n"
                "for their inputs to be respent.  It can be used to replace \"stuck\" or evicted transactions.\n"
                "It only works on transactions which are not included in a block and are not currently in the mempool.\n"
                "It has no effect on transactions which are already abandoned.\n",
                {
                    {"txid", RPCArg::Type::STR_HEX,  false,  "", "The transaction id"},
                }}
                .ToString() +
            "\nResult:\n"
            "\nExamples:\n"
            + HelpExampleCli("abandontransaction", "\"1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d\"")
            + HelpExampleRpc("abandontransaction", "\"1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d\"")
        );
    }
    
    
    pwallet->BlockUntilSyncedToCurrentChain();
    auto locked_chain = pwallet->chain().lock();
    LOCK(pwallet->cs_wallet);
    uint256 hash(ParseHashV(request.params[0], "txid"));
    if (!pwallet->mapWallet.count(hash)) {
        throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, "Invalid or non-wallet transaction id");
    }
    if (!pwallet->AbandonTransaction(*locked_chain, hash)) {
        throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, "Transaction not eligible for abandonment");
    }
    return NullUniValue;
}
static UniValue backupwallet(const JSONRPCRequest& request)