Outgoing transaction not picked up?

Question

In an experiment, we've created a couple of nodes. One node (say IssueNode) has issued native asset EUR. In one transaction, 1 million EUR has been transferred to wallet on a different node (say WalletNode1). From WalletNode1, 14 EUR has been transferred to address in WalletNode2 using a the command sequence in chapter 6 of getting started, so metadata can be included. At the time we did those experiments, the output of getassetbalances on WalletNode1 and WalletNode2 gave the amounts we expected.

However, for some reason, on WalletNode1, it looks like the last transaction is not picked up anymore. When I issue a getassetbalances, the output shows there is 1 million EUR, instead of the 999986 we expect. Also, the last transaction doesn't show up anymore in listtransactions. We have documented the transaction ID, so we could test whether it was completely lost with getrawtransaction, but this doesn't seem to be the case. The transaction is there, contains the correct outputs (one going to WalletNode2 address and one nulldata with the metadata) and has over 20k confirmations.

In order to try to rectify the situation, we shut down the WalletNode1, removed all files in ~/.multichain/chain1, except for multichain.conf and wallet.dat and reconnected it to the network. After syncing, the situation is still the same.

Is there something we could have done that breaks multichain in this way or have we encountered a bug?

Maybe unrelated, but just to be complete: we notice in the output of listtransactions, the transaction created by preparelockunspent is included twice.

Answer 1

This seemed to be a bug in alpha 9, which is fixed in alpha 10. Since this information is in a comment and not in an answer, I've added this answer. Please see the comments on other answer for details.

Answer 2

Thanks for reporting this. It sounds like it could be a bug and we'd like to look into it. Would you please stop both nodes using multichain-cli [chain-name] stop, then create a .zip file of the chain's directory from each node, then email both files to me (I will send you a private message here with my address).

The double appearance of the preparelockunspent transaction is probably fine, because it shows up multiple times for assets spent, and for assets received.

Also, just confirming you're using alpha 9?

Answer 3

Thanks - we took a look at the directories you sent. We think that what happened is you called preparelockunspent for the EUR 14 but then never actually sent the EUR 14 to the other wallet, i.e. sendrawtransaction was not called or not successful.

Currently the getassetbalances command does not include locked quantities in the node's balance, so that's why it looked like EUR 14 was deducted from the first wallet. Then when you restarted the first node, the locked status was lost (since it's not something that's on the blockchain - it's just in the node's own in-memory state) and the balance went back to the full 1 million EUR.

Does that explanation make sense? BTW your case does highlight that we should perhaps add an option to getaddressbalances and getassetbalances to include locked amounts in the totals.

Comments

The EUR 14 were actually spent in transaction 1064f017a83c7012b6c2164fc0bbd7bbbe8676d29896bb16a58d931f37e5c675, but this one does not show up in listtransactions output when requested on WalletNode1.

---

Thanks for the follow up. Yes, we think we know what caused that problem. There is a bug in alpha 9 in which spending the output from preparelockunspent can lead to a wallet inconsistency. It was also found by another user. It will be fixed in alpha 10, shortly to be released.

---

Do you already have an indication about when alpha 10 will be released?

---

Scheduled for tomorrow. If you use reindex=1 it should clear up the state of this node. We are verifying this is the case on your directory now.

---

FYI alpha 10 has just been released which fixes this problem. and we've verified that running multichaind with the parameter -reindex=1 clears up your wallet inconsistency.

---

Thanks. I've just upgraded to alpha 10 and things seem to be working now.

---

Great! Thanks for letting us know.