appendrawchange to a raw tx including asset issue

Question

This example tx has been signed & sent successfully on the chain; it 

1) sends 4 native asset from party A to party B

2) issues a new asset to a 2 of 2 multisig address

It's inputs are an unspent output of the native asset from the purchaser (A) to pay for the tx, and a unspent input signed by the issuer (B). 

I'd like to return change to A, but using appendrawchange (before any signing) results in an error:

Error: Unconfirmed issue transaction in input

The appendrawchange call is 

<txhex> ,1bbSCJn8Ziz9Z3EsBycbStjxrqyNsfYPeaPpvb,

I found another question from a couple years back that looks to be the same issue; that response says the issue was resolved in alpha 19

https://www.multichain.com/qa/1131/appendrawchange-throws-insufficient-funds-why?show=1131#q1131

I'm using V2.0.2

Am I missing something obv, or is this a known issue / regression?

Thanks,

-T

 

{

    "txid": "dc7237e18581e2e9abbc39e8c71b679cbb918ded7ecb5a4a4a326e4b25404ab2",

    "version": 1,

    "locktime": 0,

    "vin": [

        {

            "txid": "27bcf56d24a356306f6c8ef82515dffb68657017566b33e1b4ee8b01dd45724f",

            "vout": 0,

            "scriptSig": {

                "asm": "",

                "hex": ""

            },

            "sequence": 4294967295

        },

        {

            "txid": "17cf9c8d79d27ada6bea37cd19392c5d85888e172c6b13ed0c3763801c385079",

            "vout": 0,

            "scriptSig": {

                "asm": "",

                "hex": ""

            },

            "sequence": 4294967295

        }

    ],

    "vout": [

        {

            "value": 0,

            "n": 0,

            "scriptPubKey": {

                "asm": "OP_HASH160 7aea63c9c90256ccdef5cee2b7e493919dadf0b8 OP_EQUAL 73706b670100000000000000 OP_DROP",

                "hex": "a9147aea63c9c90256ccdef5cee2b7e493919dadf0b8870c73706b67010000000000000075",

                "reqSigs": 1,

                "type": "scripthash",

                "addresses": [

                    "4GcRSJJKbD64fDy81U77EcG3cxTeYD3wKe21kh"

                ]

            },

            "assets": [

                {

                    "name": null,

                    "issuetxid": null,

                    "assetref": null,

                    "qty": null,

                    "raw": 1,

                    "type": "issuefirst"

                }

            ]

        },

        {

            "value": 4,

            "n": 1,

            "scriptPubKey": {

                "asm": "OP_DUP OP_HASH160 aa0662d72928316f52031fe83120996ea6994795 OP_EQUALVERIFY OP_CHECKSIG",

                "hex": "76a914aa0662d72928316f52031fe83120996ea699479588ac",

                "reqSigs": 1,

                "type": "pubkeyhash",

                "addresses": [

                    "1PypeJZgeCXpXFKcqKDFBMR4SAejWxeBtsVEC8"

                ]

            }

        },

        {

            "value": 0,

            "n": 2,

            "scriptPubKey": {

                "asm": "73706b6e01000114454d422d34476352534a4a4b624436346644793800410401000000000201000005117b6906637573746f6d536904646174617d OP_DROP OP_RETURN",

                "hex": "3b73706b6e01000114454d422d34476352534a4a4b624436346644793800410401000000000201000005117b6906637573746f6d536904646174617d756a",

                "type": "nulldata"

            }

        }

    ],

    "issue": {

        "type": "issuefirst",

        "name": "EMB-4GcRSJJKbD64fDy8",

        "multiple": 1,

        "open": false,

        "details": {

            "custom": "data"

        }

    }

}

Answer 1

Thanks for your question. Just to help us isolate the problem, can you please post the full output of decoderawtransaction for the input transactions with txids:

27bcf56d24a356306f6c8ef82515dffb68657017566b33e1b4ee8b01dd45724f
17cf9c8d79d27ada6bea37cd19392c5d85888e172c6b13ed0c3763801c385079

Then, please try applying the workaround cited in that question you linked to, to use preparelockunspentfrom to create a substitute UTXO instead of the one directly from the issuance transaction, and using that instead.

Comments

{
  "blockhash": "0070f3a991a39de1714f18d96d2f7ed63e2895d54dc10f251b0b6275a77c1ad5",
  "blocktime": 1571409975,
  "confirmations": 269,
  "hex": "0100000001a5ea06e45ec4617ddab3b76ad34769d955dbf693ab4ff7869a55769e64f843d7010000006b483045022100b93c13de34efcd2d75a332472fcfe15418518d7cef9c5f77292bdc240e6ee1bd02206e8c25dfe8c10e958ab7c09a74b0cf096f9a5c3104eb5418c3db4e2219217efc012102faa7112eff97389f144ba070c5881b0810746a5e801073f73fbb39b1c2ce3c35ffffffff0200000000000000001976a914aa0662d72928316f52031fe83120996ea699479588ac10010000000000001976a914aa0662d72928316f52031fe83120996ea699479588ac00000000",
  "locktime": 0,
  "time": 1571409975,
  "txid": "27bcf56d24a356306f6c8ef82515dffb68657017566b33e1b4ee8b01dd45724f",
  "version": 1,
  "vin": [
    {
      "scriptSig": {
        "asm": "3045022100b93c13de34efcd2d75a332472fcfe15418518d7cef9c5f77292bdc240e6ee1bd02206e8c25dfe8c10e958ab7c09a74b0cf096f9a5c3104eb5418c3db4e2219217efc01 02faa7112eff97389f144ba070c5881b0810746a5e801073f73fbb39b1c2ce3c35",
        "hex": "483045022100b93c13de34efcd2d75a332472fcfe15418518d7cef9c5f77292bdc240e6ee1bd02206e8c25dfe8c10e958ab7c09a74b0cf096f9a5c3104eb5418c3db4e2219217efc012102faa7112eff97389f144ba070c5881b0810746a5e801073f73fbb39b1c2ce3c35"
      },
      "sequence": 4294967295,
      "txid": "d743f8649e76559a86f74fab93f6db55d96947d36ab7b3da7d61c45ee406eaa5",
      "vout": 1
    }
  ],
  "vout": [
    {
      "n": 0,
      "scriptPubKey": {
        "addresses": [
          "1PypeJZgeCXpXFKcqKDFBMR4SAejWxeBtsVEC8"
        ],
        "asm": "OP_DUP OP_HASH160 aa0662d72928316f52031fe83120996ea6994795 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914aa0662d72928316f52031fe83120996ea699479588ac",
        "reqSigs": 1,
        "type": "pubkeyhash"
      },
      "value": 0
    },
    {
      "n": 1,
      "scriptPubKey": {
        "addresses": [
          "1PypeJZgeCXpXFKcqKDFBMR4SAejWxeBtsVEC8"
        ],
        "asm": "OP_DUP OP_HASH160 aa0662d72928316f52031fe83120996ea6994795 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914aa0662d72928316f52031fe83120996ea699479588ac",
        "reqSigs": 1,
        "type": "pubkeyhash"
      },
      "value": 0.272
    }
  ]
}

---

{
  "blockhash": "0070f3a991a39de1714f18d96d2f7ed63e2895d54dc10f251b0b6275a77c1ad5",
  "blocktime": 1571409975,
  "confirmations": 269,
  "hex": "0100000002b4c6401f0655d5ed4209fd105117781ca453a8d6281fd2cc734a20a619db2cde010000006b483045022100b659724c9c69839a907ba6dcbd6fa5f4acc2e785fd0015b85f2376af4fd27a4f0220284bcbdf2ff2494b800d1d9d306ee6c2fcf745deb0b7de088313327ac1e687f9012103922fb9ae84ee402ee243d2afb54c0b2f082e23a149e27e66e74a1bde4ac5e7b0ffffffff3754400d6b78bf21167b8ddf0b5e441b2e0fc2720b13e256a24ffd0f1c7b08fd000000006b483045022100a742efa2fb01c07745f60d32a2f50583f97aed4c5a119d987f2d32a35094abbc022008c092ec040a2fd74f4fead4551f397cd079819d72dc88bd99c84d62855963f3012103922fb9ae84ee402ee243d2afb54c0b2f082e23a149e27e66e74a1bde4ac5e7b0ffffffff02a8610000000000001976a9144c73630535db19d31620f73750ececa80f83a9c388acfb260000000000001976a914a47ab7ba0faf7992ed8902f2d712b9f24e6ba15288ac00000000",
  "locktime": 0,
  "time": 1571409975,
  "txid": "17cf9c8d79d27ada6bea37cd19392c5d85888e172c6b13ed0c3763801c385079",
  "version": 1,
  "vin": [
    {
      "scriptSig": {
        "asm": "3045022100b659724c9c69839a907ba6dcbd6fa5f4acc2e785fd0015b85f2376af4fd27a4f0220284bcbdf2ff2494b800d1d9d306ee6c2fcf745deb0b7de088313327ac1e687f901 03922fb9ae84ee402ee243d2afb54c0b2f082e23a149e27e66e74a1bde4ac5e7b0",
        "hex": "483045022100b659724c9c69839a907ba6dcbd6fa5f4acc2e785fd0015b85f2376af4fd27a4f0220284bcbdf2ff2494b800d1d9d306ee6c2fcf745deb0b7de088313327ac1e687f9012103922fb9ae84ee402ee243d2afb54c0b2f082e23a149e27e66e74a1bde4ac5e7b0"
      },
      "sequence": 4294967295,
      "txid": "de2cdb19a6204a73ccd21f28d6a853a41c78175110fd0942edd555061f40c6b4",
      "vout": 1
    },
    {
      "scriptSig": {
        "asm": "3045022100a742efa2fb01c07745f60d32a2f50583f97aed4c5a119d987f2d32a35094abbc022008c092ec040a2fd74f4fead4551f397cd079819d72dc88bd99c84d62855963f301 03922fb9ae84ee402ee243d2afb54c0b2f082e23a149e27e66e74a1bde4ac5e7b0",
        "hex": "483045022100a742efa2fb01c07745f60d32a2f50583f97aed4c5a119d987f2d32a35094abbc022008c092ec040a2fd74f4fead4551f397cd079819d72dc88bd99c84d62855963f3012103922fb9ae84ee402ee243d2afb54c0b2f082e23a149e27e66e74a1bde4ac5e7b0"
      },
      "sequence": 4294967295,
      "txid": "fd087b1c0ffd4fa256e2130b72c20f2e1b445e0bdf8d7b1621bf786b0d405437",
      "vout": 0
    }
  ],
  "vout": [
    {
      "n": 0,
      "scriptPubKey": {
        "addresses": [
          "1BLJ8nshJmLwnWDWArrNs5DNqdY1GTqBbwYXkN"
        ],
        "asm": "OP_DUP OP_HASH160 4c73630535db19d31620f73750ececa80f83a9c3 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9144c73630535db19d31620f73750ececa80f83a9c388ac",
        "reqSigs": 1,
        "type": "pubkeyhash"
      },
      "value": 25
    },
    {
      "n": 1,
      "scriptPubKey": {
        "addresses": [
          "1PEMHcztboAv7XpbKJWH3HFPqycK5TYgkVeCUX"
        ],
        "asm": "OP_DUP OP_HASH160 a47ab7ba0faf7992ed8902f2d712b9f24e6ba152 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914a47ab7ba0faf7992ed8902f2d712b9f24e6ba15288ac",
        "reqSigs": 1,
        "type": "pubkeyhash"
      },
      "value": 9.979
    }
  ]
}

---

I'm 90% confident that appendrawchange after the workaround works; it's been a couple days, but I'm pretty sure I saw that. However - the exchange is no longer atomic in that case, no? The issuer will have sent the issue TX; if the purchase isn't completed, will that asset still exist (tho it'll still be owned by the issuer)?

Answer 2

Thanks for the extra details. I think the problem is this. This transaction you are passing to appendrawchange is issuing a new asset. And this is a problem for appendrawchange because it doesn't yet know the total quantity of the asset that you want to issue (since it is not yet issued) in order to know how much you may want to put in the change output. We could look into this for the next release, and assume that you don't want to put any of the new asset in the change output. But I think in this case your best bet is simply to calculate the change output quantity in your application,, and then use appendrawtransaction to add the extra output instead of appendrawchange.

Comments

Sounds good. Perhaps the appendrawchange call could include an option for indicating which asset you want to create change for?

This is not my use case, but in a (admittedly contrived) scenario for an atomic exchange of m units of asset A from user X for n units of asset B from user Y, user X would want their asset A change, and Y would want their B change.

Do I understand correctly that the first user to appendrawchange would get all the change for both assets?

---

Yes, that's right - appendrawchange puts all the remaining change in a single output. For more complex cases you should use appendrawtransaction. Note also that MultiChain has a bunch of built-in functionality for facilitating atomic exchanges: https://www.multichain.com/developers/atomic-exchange-transactions/