TxCount not incrementing linearly

Question

While performing some benchmarking stress tests (simply spamming transactions) I noticed that the txcount (getwalletinfo) is not incrementing linearly.  Could the peer to peer network be the problem? How can I avoid that? Is there a way to determine the total number of confirmed transactions?

Answer 1

This is fixed in version 1.0.6 of MultiChain, just released. The fix will also be included in 2.0 alpha 4 to be released next week.

Answer 2

The txcount of getwalletinfo is only a count of transactions stored in that particular node's wallet, because they are of special interest to that node (relating to its addresses, or a subscribed asset or stream). It is a not a count of transactions on the blockchain as a whole.

Comments

Yes I am aware of this. However, since I am only spamming from one wallet it should be the total amount of transactions on the whole chain. It should increment linearly. Why so and is there a better way to retrieve the total amount of transactions?

---

OK, so can you please explain the exact behavior you're expecting, and what you're seeing instead. I'm not sure what you mean by "incrementing linearly".

---

Alright. My goal is a benchmark giving me some statistics how many transactions per seconds are possible.
I've set up four powerful nodes all connected in a Gigabit nework. Then I created a stream and started to spam items from one single wallet through the RPC interface. When I retrieve the current values of getwalletinfo I expected the value of txcount to continuously increment. Instead the value decreases from e.g. 1000 transactions to 900 transactions one second later. In the next second it will increase up to 1100 tx and then down again. Overall the amount of transactions increases but its not a linear curve which I would expect since the blockchain in immutable.

I wonder what causes this behaviour and if there is a more elegant solution in benchmarking the blockchain.

---

Thanks for the broader explanation. This does not sound like the correct behavior, and I will ask the team about it.

Answer 3

So the answer is that this txcount value includes both the on-disk database of wallet transactions, as well as transactions relevant to the wallet in the memory pool of unconfirmed transactions. Some transactions can appear in both places, leading to double counting, but this is temporary (since the memory pool is a transient place). We'll aim to fix this in the next maintenance release. For now I hope you can work around it, since it's just a cosmetic reporting issue.