Grin: Grins lost after cancelling transaction

[lehnberg]

From user "Arthur" on Grin-forum:

I believe that I could possibly have lost around 5k grins because of a bug in the test net.

Yesterday I was messing around with grin commands and trying all different things, when I’ve realized >that after canceling a transaction, my locked funds didn’t return to my wallet and were gone forever.

Here is my current wallet txs and wallet info, 12 hours after the bug:
https://pastebin.com/QBARnzpR 4 (I believe the bug happened at transaction 178 - line 364 of the >pastebin)

And here is all the grin commands I’ve run in the session that the bug occurred:
https://pastebin.com/69Ge0Pbe 1 (Bug happened after line 743)

Another thing I’ve noticed, is that yesterday some transactions I’ve tried to make returned this error, >even though I had more than enough “currently spendable” grins in my wallet:

grin wallet send -d "http://108.196.200.233:13415" 20.0
2018-10-31T00:23:43.983935175-03:00 WARN grin - Using wallet configuration file at /home/arthur/.grin/grin-wallet.toml
2018-10-31T00:23:46.214033101-03:00 ERROR grin::cmd::wallet - Tx not created: Error { inner: 

Not enough funds. Required: 20005000000, Available: 0 }

This last behaviour occurred in line 73,119,170 and 214 of the above pastebin.

Have anyone ever experienced anything like this?

[hashmap]

It happened to me, after cancelling a tx and some additional operations my balance was quite off. But in my case I was running a malfunctioning (for unrelated test purpose) version of grin so I decided it was my fault. I restored my balance with grin wallet restore.

[aacoimbra]

After some tests I believe I've managed to replicate the bug.

Let's analyze a transaction where the sender sends 10 grins to himself.

Running grin wallet send 10 -d "http://0.0.0.0:13415" will generate two transactions in grin wallet txs e.g.:

243  Received Tx          2c33b04d-bd11-4e72-8ffd-05b5806bb8d9  2018-11-02 02:28:03  true        2018-11-02 02:29:23  0            1             10.0             0.0             None   10.0            None 
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 244  Send Tx               2c33b04d-bd11-4e72-8ffd-05b5806bb8d9  2018-11-02 02:28:03  true        2018-11-02 02:29:03  31           1             1955.828         1965.829        0.001  -10.001         Exists 

If you cancel the transaction 244 by typing grin wallet cancel -i 244, the transaction 243 will still deliver the 10 grins from and to the user wallet, but the transaction 244 that was suppose to deliver the transaction change (all users remaining funds) will not happen. In this case tx 244 should return 1955.828 to the user as change, but canceling it will not cancel the original transaction as a whole, only the second part.

And if I were to run grin wallet cancel -243 instead, only the first part of the transaction would be canceled.

[yeastplume]

@aacoimbra When you send grins to another wallet, there is 1 entry created in either wallet. The sender creates a transaction with their own unique id, and all their associated inputs and outputs are associated with it. The receiver also creates a tx log entry in their wallet, referencing their output(s). These transaction log entries are not linked to each other (other than by slate UUID), they're just references maintained separately in each wallet.

If you're sending grins to yourself, then you're acting as both recipient and sender, and you have 2 transactions to cancel from the log (a send tx and a recieve tx), not just one.

Also, in the example above where you're sending grins to yourself via http, you've sent and received the transaction and posted it to the chain in one operation (grin wallet send). Cancelling the transaction at that point won't work, and put your wallet into a bad state as the tx has already been posted and will show up on the chain within a few blocks. A wallet restore is probably the best solution here at the moment.

Admittedly none of this is obvious or ideal, and we need better ways of dealing with these situations.

[yeastplume]

wallet check is implemented to handle these situations now