search

vault713 / wallet713

A wallet that makes it easy to send, store, and swap Grin.
Apache License 2.0
196 stars 74 forks source link

Transactions failed, coins locked up & awaiting conf for 18 billion grin #142

Closed damanzo closed 5 years ago

damanzo commented 5 years ago

Hi all,

I was trying out wallet 713 and when trying to send 1 grin to a friend using contact list I got a weird tx. It locked up my grin (still locked up after 14 hours and can't cancel it) and it says that i'm awaiting 18446744072.702552795 grin.

damanzo commented 5 years ago

Went back to normal after sending new transactions. Weird txs still appear in my tx log tho. with net difference of 18 billion

lehnberg commented 5 years ago

Thanks for raising this issue. Could you walk me through the exact steps of how this happened? I will try to reproduce it

damanzo commented 5 years ago

Hi Lehnberg,

I'm not sure I can get back to the wallet713 logs so in order to see exactly what I did, but from memory: contacts add @XXX send 1 --to @XXX

I don't recall doing anything different than that, however I was doing back and forth txs with another friend in the meantime, so maybe something happened at this level, sorry if this is not enough to help you figure out what happenned. If there is a way to get back to the logs I'll go and fetch more precise info

IstoraMandiri commented 5 years ago

I also ran into this issue, and can suggest an approach to reproduce.

I was playing around with sending transactions between two wallet713 instances, using the issue_send_tx api programatically. I think you can force things to go awry if the amount is small, the num_change_outputs is high, and selection_strategy_use_all is false.

For instance;

      amount: 3,
      minimumConfirmations: 1,
      method: "grinbox",
      dest: "xxxx",
      maxOutputs: 1,
      numChangeOutputs: 100,
      selectionStrategyIsUseAll: false

In my case, the slate exchange appears to have failed.

The sender cli looks like:

> info

____ Wallet Summary Info - Account 'default' as of height xxxx ____

 Total                            | xxx
 Awaiting Confirmation (< 10)     | 18xxxxxxxxx.xxxxxxxxx
 Locked by previous transaction   | xxxx
 -------------------------------- | -------------
 Currently Spendable              | xxxx

After running check on the sender:

wallet713> check
checking and repairing... please wait as this could take a few minutes to complete.
check and repair done!
wallet713> info

____ Wallet Summary Info - Account 'default' as of height xxx ____

 Total                            | xxx
 Awaiting Confirmation (< 10)     | 0.000000000
 Locked by previous transaction   | xxx
 -------------------------------- | -------------
 Currently Spendable              | xxx

After running check, I try another transaction (as above), which also fails:

The receiver sees:

slate [xxxx] received from [xxx] for [xxxx] grins
error: failed receiving slate!

I was able to get things working by trying a transaction that used reasonable defaults (higher amount, lower num_change_outpus and selection_strategy_use_all to true).

Hope this helps.

jaspervdm commented 5 years ago

Thanks for these steps, I will investigate!

IstoraMandiri commented 5 years ago

@jaspervdm please check gitter for DM from me

IstoraMandiri commented 5 years ago

I also get this problem if a transaction fails for some other reason;

wallet713> send 0.01 --to https://127.0.0.1:3417
error: http request error
 61  Sent Tx      ad1679d5  https://127.0.0.1:3417                                          2019-04-24 07:50:02                                   18446744073.694553375

Seems that the balances can be 'fixed' this by running txs, finding the latest transaction id then running cancel -i [txId].

cgilliard commented 5 years ago

I think you can reproduce this issue by sending to your own address. I have tried this several times and it consistently happens with this same number as others are reporting. You cannot fix it in wallet713, but if you copy your seed file into a grin full node, and run grin wallet restore, the funds become spendable again.

cgilliard commented 5 years ago

Bug is in selection.rs line 315. You are defining coins within this inner scope and when you get outside of the loop it reverts back to the outer scope "coins". You need to make coins mutable and copy the variable over before exiting the loop.

jaspervdm commented 5 years ago

@cgilliard Thanks for researching it! That is definitely a bug. I have implemented a fix and will merge it in shortly. From my testing so far it seems that it was indeed responsible for this specific issue.