About tx error: setting INVALID flag.

Question

Hi,

We are doing high speed load testing.
We are currently testing multichain 1.01 (protocol 10009) on three ubuntu Linux servers.
 

Each of the three servers executes the 'send' command at the maximum speed to the other two servers.
The following '... was not accepted to mempool, setting INVALID flag' error will occured.

If appropriate time delay was given between sends, the above problem does not occur.

'... setting INVALID flag'
This error seems to be caused by sending transactions at a high speed between the servers.
Sending a transaction at high speed only from one server does not cause this error.

Once this error occurs, it will continue to appear.
What causes this error, and how do you remove the transaction?

Or what settings or methods are needed to prevent this error?

 

 

$ multichain-cli mc getinfo
{"method":"getinfo","params":[],"id":1,"chain_name":"mc"}

{
    "version" : "1.0.1",
    "nodeversion" : 10001901,
    "protocolversion" : 10009,
    "chainname" : "mc",
    "description" : "MultiChain mc",
    "protocol" : "multichain",
    "port" : 18823,
    "setupblocks" : 60,
    "nodeaddress" : "mc@192.168.1.19:18823",
    "burnaddress" : "1XXXXXXWvuXXXXXXMRXXXXXXhAXXXXXXYw8FG8",
    "incomingpaused" : false,
    "miningpaused" : false,
    "walletversion" : 60000,
    "balance" : 4354999.81247900,
    "walletdbversion" : 2,
    "reindex" : false,
    "blocks" : 1052,
    "timeoffset" : 0,
    "connections" : 2,
    "proxy" : "",
    "difficulty" : 0.00000006,
    "testnet" : false,
    "keypoololdest" : 1506388291,
    "keypoolsize" : 2,
    "paytxfee" : 0.00000000,
    "relayfee" : 0.00000000,
    "errors" : ""
}

$ uname -a
Linux lee-VirtualBox 4.10.0-35-generic #39~16.04.1-Ubuntu SMP Wed Sep 13 09:02:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ tail -f debug.log
...
2017-09-26 01:31:42 MultiChainMiner: Block Found - 0000244ee3c2044c6eb165e1b2fafe9b3d7ec888a6303fb0623403637a25dcf7, prev: 000033bfe67e433c54fc2f8bde68ddeeccd98f4da1be12c45b8ee3d3cea82cb6, height: 925, txs: 1
2017-09-26 01:31:42 UpdateTip:            new best=0000244ee3c2044c6eb165e1b2fafe9b3d7ec888a6303fb0623403637a25dcf7  height=925  log2_work=17.854868  tx=236837  date=2017-09-26 01:31:42 progress=1.000000  cache=0
2017-09-26 01:31:42 Tx ce97c141e6706dfaf9827b08fc576b4b02f21e868df2989f29aa4d267f103f68 was not accepted to mempool, setting INVALID flag
2017-09-26 01:31:42 Tx d995de804747eb0220257acba4b84ef95417aa77df48d588ff4651587df9b174 was not accepted to mempool, setting INVALID flag
2017-09-26 01:31:42 Tx e42b84605f15825d0b16e364ba6648174bb948cce82a9b1484606b863203efa7 was not accepted to mempool, setting INVALID flag
2017-09-26 01:31:42 Tx cb4a0d59da89a58eafa17d2ad3d2ebe8ccba4d1cf211a801c8745bcc30950374 was not accepted to mempool, setting INVALID flag
2017-09-26 01:31:42 Tx aae69b2dd30342df80a74779b67c3a1071fb5648b9f1b7cb71a51d27cb2a81fb was not accepted to mempool, setting INVALID flag
2017-09-26 01:31:42 Tx 79e2974d3c97eb3d0aa21ae4658d7bd1c6763f4f8a0806e2d7fd573026937924 was not accepted to mempool, setting INVALID flag
2017-09-26 01:31:42 Tx 1014bf1146f05f94eef946e83f39e01de85faa7a883b1de5f7ae21b6bcfac3bf was not accepted to mempool, setting INVALID flag
2017-09-26 01:31:42 Tx eaf616dd305e8497a9beb939b4dd3f1bbf4055cc8ad59e48aac97800c73b18f3 was not accepted to mempool, setting INVALID flag
2017-09-26 01:31:42 Tx 6176e7dc76511700289a46027383710937d407f2e6a247a72d9d7fa51fd75051 was not accepted to mempool, setting INVALID flag

Answer 1

It sounds like each node might be issuing 'send' commands using the same originating from address? If so you cannot use multiple nodes for load balancing transactions from the same address in this way, because two nodes may simultaneously attempt to spend the same output from a previous transaction. This leads to a "double spend" which shows up as an invalid transaction.

If your goal is load testing, please ensure that each node has a different address that it uses for sending assets. Also ensure that nodes that are receiving many incoming transactions use auto-combining (see runtime parameters), or explicitly call the combineunspent command, to prevent inflation of unspent transaction outputs (which slows down sending). You can monitor this via the utxocount field of getwalletinfo.