Let’s discuss it with core devs at next meeting (at 3rd time).
My suggestion is to fix this critical bug that affects usability for both users and exchanges at node level to automate rebroadcasting process on Dandelion phase.
@Yeastplume should know how to do it the best for sure as he is more experienced at this part since beginning.
Just caught this bug upon withdrawal from one known exchange, 1 of 9 txs is not getting any confirmation, asked to repost through support. Some kind automation on this weird bug is must have. Usually users don’t keep a wallet open, especially at CLI mode, adding extra step/option for wallet to check txs timeout here is dirty hack imo, if node is trying to broadcast tx and failing somewhere, it can simply try to rebroadcast it again with some limit of attempts without interaction from user/wallet I guess.
Seems like you are right, 2nd party is dropping tx for some reason as status of this amount is under Awaiting Finalization, possibly some tor connection issue, still could not reproduce same error at local environment, weird thing exchange is waiting for blockchain confirmation as there is no special status, just Confirmed flag is in false status. Possibly timeout on wallet level can fix issue for them, we still don’t know what kind of implementation they are using as there is no direct communication with their devs…
I had same issue with Tor before when I was sender, reported on Keybase@06.10.2023.
Currently there aren’t many nodes, i wonder what happens if none of them is in fluff phase.
The guy sent coin, they were not received, were missing from his wallet. He was refunded/given,…The missing amount. So, yes, I think I can say the coins were lost without causing much controversy.
My main question has still not been answered.
Anyway, I did a test send to an exchange, the coins got there with no problem. Just one thing though, I noticed that in the output, it had a number 4x the amount. I thought it was strange as the input was always the same as what I sent to the wallet. So I did another test send, and sent the same amount again, but about 3x, if I remember correctly, was recorded in the output. I wrote down what was in the wallet this time to see what was being deducted, and it was about 3x the amount being sent.
The right amount was returned to my wallet a little while later.
But why does it even have to deduct from my balance so much more than what I have sent? Say I had to make more than one transaction and needed that reduced amount, does it even send if I do not have 3x, or 4x the amount…?
It’s not a big deal, the right amount was displayed later, just thought I would mention it.
Coins can’t be lost, at each point in time either exchange has them or the user. My guess is that it was refunded because it took longer than expected to find the bug.
What do you mean with “output had a number 4x the amount” and with “the input was always the same as what I sent to the wallet”? Imagine you have 2 UTXO’s, one with 3 grin and one with 17 grin. Now imagine that you send 5 grin to the exchange → the wallet selected UTXO with 17 grin as input and it shows your balance as 3 (utxo with 17 is unavailable at the moment, so you don’t yet have 12 grin from this transaction) for some time and then after some time it showed 15 (3 from old utxo and 12 from new one, created in the transaction where you sent 5 to the exchange)? If you’re talking about this then that’s just implementation detail. You can either deduct 17 from your balance (because the other 12 are not usable at the moment) or do it the way grin-wallet does it and display 2 numbers, total balance (15) and available balance (3, later changes to 15).
Thanks, makes sense. I was reading it as sent/received.
Hi everyone!
new here. Are there any videos explaining how to set up the new wallet. all of the ones I can find seem to be from a much older version…
thanks!
If you mean a video where you compile the wallet and node. This is a recent video how on how to set up the node and wallet on a raspberry pi:
Grin node on rasoberry pi
If you mean setting up a wallet without compiling yourself. It is just a one click install for Windows.
I agree that in grin you need to have a rebroadcast button because the transaction is only sent to one person which can drop it (iirc grin-wallet cli has a “repost” command).
