multichaind process stops unexpectedly on executing certain api commands.

Question

I executed the following command using multichain-cli, and the multichaind process stops automatically every time I execute the command. Any idea why this happens and how to fix it?

 

Command:

sendwithmetadata 1FhRdVQJmuQSkKQcGQXs3PRpExCPt3R5DdKoJM 0 "73646a666a736667736a676468736a73646a666a736667736a676468736a73646a666a736667736a676468736a73646a666a736667736a676468736a73646a666a736667736a676468736a73646a666a736667736a676468"

 

Response:

{"method":"sendwithmetadata","params":["1FhRdVQJmuQSkKQcGQXs3PRpExCPt3R5DdKoJM",0,"73646a666a736667736a676468736a73646a666a736667736a676468736a73646a666a736667736a676468736a73646a666a736667736a676468736a73646a666a736667736a676468736a73646a666a736667736a676468"],"id":1,"chain_name":"testchain1"}

error: no response from server

Answer 1

Do you see anything in the debug.log file inside your blockchain's directory?

Comments

I'm seeing the following in the last few lines of debug.log after I performed the transaction.

2016-12-29 10:43:23 Running MultiChainMiner with 1 transactions in block (301 bytes)
2016-12-29 10:43:23 MultiChainMiner:
2016-12-29 10:43:23 proof-of-work found
  hash: 0000a0ea99f0fe027d10b015aefd93c8fbbcbbca96a8a5f5dc7d820a11138658
target: 0000ffff00000000000000000000000000000000000000000000000000000000
2016-12-29 10:43:23 CBlock(hash=0000a0ea99f0fe027d10b015aefd93c8fbbcbbca96a8a5f5dc7d820a11138658, ver=3, hashPrevBlock=000014381620ca99504ede009e746940189c67393eab4415207d43a352a8e7db, hashMerkleRoot=0f71a9fa57ecc05d39462c0221793866d089a5cd50f1a92fa3bbbb68f488988b, nTime=1483008203, nBits=1f00ffff, nNonce=16179, vtx=1)
  CTransaction(hash=0f71a9fa57, ver=1, vin.size=1, vout.size=2, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 0264010101062f503253482f)
    CTxOut(nValue=100.00000000, scriptPubKey=OP_DUP OP_HASH160 ae17e5fdc411)
    CTxOut(nValue=0.00000000, scriptPubKey=OP_RETURN 53504b62473045022100)

  vMerkleTree:  0f71a9fa57ecc05d39462c0221793866d089a5cd50f1a92fa3bbbb68f488988b

2016-12-29 10:43:23 generated 100.00
2016-12-29 10:43:23 UpdateTip: new best=0000a0ea99f0fe027d10b015aefd93c8fbbcbbca96a8a5f5dc7d820a11138658  height=356  log2_work=24.479802  tx=1182  date=2016-12-29 10:43:23 progress=1.000000  cache=0
2016-12-29 10:43:23 mchn: Coin selection: Transaction too large

---

Sorry for the delay over the new year's break. Does your wallet contain a very large number of unspent transaction outputs (UTXOs)? The most likely cause would be using a native currency in your blockchain, so that miners collect a lot of block rewards, but the miners don't have send/receive permissions to allow their nodes to auto-combine UTXOs. You can use the listunspent command to see if this is the problem.

---

I faced the same issue with another blockchain. I tried the solution that you have suggested above, but the issue still seems to persist.

I'm finding the following lines in the log:

2017-03-07 11:44:26 ERROR: CheckTransaction() : txout.nValue too high
2017-03-07 11:44:26 ERROR: AcceptToMemoryPool: : CheckTransaction failed
2017-03-07 11:44:26 CommitTransaction() : Error: Transaction not valid: 16: bad-txns-vout-toolarge
2017-03-07 11:44:40 Running MultiChainMiner with 1 transactions in block (302 bytes)
2017-03-07 11:44:41 Running MultiChainMiner with 1 transactions in block (302 bytes)
2017-03-07 11:44:41 MultiChainMiner:
2017-03-07 11:44:41 proof-of-work found
  hash: 00006bad83ffd95f69c16b14d485ce89b890810362939d1d70055bed7be90996
target: 0000ffff00000000000000000000000000000000000000000000000000000000
2017-03-07 11:44:41 CBlock(hash=00006bad83ffd95f69c16b14d485ce89b890810362939d1d70055bed7be90996, ver=3, hashPrevBlock=00005fbf8f3c515a2cedc3ec63f8636add97d7897b1f05b3a34b31da1943a889, hashMerkleRoot=6db412c7bb2736f3281a73c3b0a8600a1277aba7a5c68bb190fa3e6f467c5f4f, nTime=1488887081, nBits=1f00ffff, nNonce=19605, vtx=1)
  CTransaction(hash=6db412c7bb, ver=1, vin.size=1, vout.size=2, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 032cf00b0102062f503253482f)
    CTxOut(nValue=10.00000000, scriptPubKey=OP_DUP OP_HASH160 a02d77e2ffa5)
    CTxOut(nValue=0.00000000, scriptPubKey=OP_RETURN 53504b62473045022100)

  vMerkleTree:  6db412c7bb2736f3281a73c3b0a8600a1277aba7a5c68bb190fa3e6f467c5f4f

2017-03-07 11:44:41 generated 10.00
2017-03-07 11:44:41 UpdateTip: new best=00006bad83ffd95f69c16b14d485ce89b890810362939d1d70055bed7be90996  height=782380  log2_work=35.577534  tx=789229  date=2017-03-07 11:44:41 progress=1.000000  cache=0
2017-03-07 11:44:41 Tx 133f2f3c26b5a15e4fa34dc11b57a7f140d3a88ac82ee34d954f13fa5b2f0133 was not accepted to mempool, setting INVALID flag
2017-03-07 11:44:41 Tx 245987abe00f66400bcf9d9119ccb7f39d1d1f6bb9f7f3baf441037da2c0a2b5 was not accepted to mempool, setting INVALID flag
2017-03-07 11:44:41 Tx 38461d7cf4d3329f8fa70b1f4c0fbb01d451dc6574d6248e3477fe78c6f54a87 was not accepted to mempool, setting INVALID flag
2017-03-07 11:44:41 Tx 57d7ecfd5690b757978a656ad09146e42da1c0ffbf86d678986fc532e8760838 was not accepted to mempool, setting INVALID flag
2017-03-07 11:44:41 Tx 7615158c2ccea4775aef02e4b4b0e19b3647e246a7e4cf5da5e73ec3b426e5f4 was not accepted to mempool, setting INVALID flag
2017-03-07 11:44:41 Tx 85a4764a5e50d1f1a8d63deb78177162d395b9ed90369e8970da7619bfafd0c3 was not accepted to mempool, setting INVALID flag

---

Are you able to post the raw transaction hexadecimal for any of these transactions which are marked INVALID, or were they generated automatically by the auto-combining of unspent transaction outputs?

---

The raw transaction is exceeding 8000 characters. So can't post it here. Should I email it to you?

---

Yes, please do - multichain.debug at gmail dot com - but I'm also curious how this transaction was created?

---

We got it. The quantity in the output is very high, and presumably over the blockchain's defined limit. How was this transaction built? By your code or by MultiChain?

---

Doesn't look like a transaction created by our application, since our application doesn't use native currency at all.

---

OK, thanks, we'll look into it.

---

Alpha 29, just released, should fix this problem. The autocombine functionality, which trims the number of UTXOs for a given address, was generating invalid transactions in your case.