Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Beacon advertisement drains balance #2321

Closed
sibebleuze opened this issue Sep 10, 2021 · 17 comments
Closed

Beacon advertisement drains balance #2321

sibebleuze opened this issue Sep 10, 2021 · 17 comments
Labels

Comments

@sibebleuze
Copy link

Bug Report

Current behavior
My Gridcoin wallet did an automatic beacon advertisement last night, with the expected withdrawal of 0.5 GRC. I didn't notice at first, but at the same time, my whole wallet was drained and now has a balance of 0 GRC. The weird thing is that if I look it up on a block explorer, the address it was sent to belongs to my CPID, same as the the address it was sent from. However, my wallet says 0 GRC, as can be seen on the screenshot below.

Expected behavior
Beacon advertisement uses a small amount of GRC, for example 0.5 GRC, and leaves the rest of the wallet untouched.

Steps to reproduce:
Wait for automatic beacon renewal I think. The last thing I did myself was consolidate my whole balance to 1 address. This was approximately 18 hours before the beacon was renewed.

Screenshots
Pay attention to the last two transactions and the current balance. These are the ones involved in this issue.
Schermafbeelding 2021-09-10 114403

Gridcoin version
Gridcoin v5.3.2.0-gfe6ab878a

Machine specs

  • OS: Windows 10
  • CPU: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
  • RAM: 16 GB
  • Disk size: 237 GB
  • Disk Type (HD/SSD): SSD

Extra information
contents of debug.log file: https://pastebin.com/nmVXK88F
the beacon renewal transaction which drained my wallet: https://www.gridcoinstats.eu/tx/96c4ac8bfdfb1e5b81d32d9a32cbf3f956c9610595e10c40f13994c94b7410ab
summary on the address it was sent from (note my CPID): https://www.gridcoinstats.eu/address/SF3UktSxkFm1CZXvNRBkEra2gHjbbF1Qit
summary on the address it was sent to (note the exact same CPID): https://www.gridcoinstats.eu/address/RzaJyJLZ7gqSC6sfqr6ybJWiu4T1mkZdHc

I really would like to have my balance restored to its former state, so if anyone knows what happened here or how I can fix it, please let me know.

@sibebleuze sibebleuze added the bug label Sep 10, 2021
@sibebleuze
Copy link
Author

Update: I opened my wallet on Ubuntu and after syncing it appears the balance draining transaction wasn't there. I will try to resync on Windows now to see if that gets rid of it there too. If so, I will close and hope it never happens again.

@div72
Copy link
Member

div72 commented Sep 10, 2021

If you haven't resynced, could you show the transaction details for both of the transactions?

@sibebleuze
Copy link
Author

Ok so resyncing (from zero) did not fix it on Windows. The bogus transaction just shows up again. I have pasted the transaction details below (they are exactly the same, but this is actually what I got out of both transactions in the client: Transactions>right click>Show transaction details):

For the expected transaction (-0.5 GRC): https://pastebin.com/AbeYLMM7
For the unexpected transaction (-5846 GRC): https://pastebin.com/EPfN7MiM

Would a complete reinstall of Gridcoin be able to fix more than the resync I already did?
What I did to resync is close Gridcoin client, delete everything from %appdata%\GridcoinResearch except gridcoinresearch.conf and wallet.dat (and maybe gridcoinresearch.json too, not sure about that one), then start the client again and wait a couple hours.

I'm a little more at ease now than I was a few hours ago since I saw the balance was still there on Ubuntu, but I would like to get it fixed on Windows too as I will be spending a considerable amount of time there as well.

@sibebleuze
Copy link
Author

sibebleuze commented Sep 10, 2021

For comparison, these are the transaction details when I get them from the Ubuntu client (which I believe to be the correct ones): https://pastebin.com/NA2yBGQP
These do in fact differ from the ones in the previous comment that I got from Windows, so maybe the differences can help sort out what happened.
Based on this, I am starting to think this is a GUI issue and not as I first thought a blockchain issue.
One addition that may be of importance which I didn't think of earlier: when this transaction occurred, I had my Ubuntu client open. It is only later when I switched to Windows and synced there that I ran into this issue.

@div72
Copy link
Member

div72 commented Sep 10, 2021

Do you run two instances of the wallet at the same time?
Was the beacon re-advertised from the Ubuntu wallet?
Does dumpprivkey RzaJyJLZ7gqSC6sfqr6ybJWiu4T1mkZdHc return anything on Windows? (Do not post the output if it returns the private key, only the error.)

@jamescowens
Copy link
Member

Hmm... Very interesting. My guess is that @sibebleuze has been running two wallets with the same keys at the same time, and of course they both tried to advertise a new beacon at the same time. Has a repairwallet been attempted on the Windows node?

@jamescowens
Copy link
Member

... And... @sibebleuze you are not supposed to be running two wallets at the same time with the same keys...

@sibebleuze
Copy link
Author

sibebleuze commented Sep 10, 2021

@div72 the dumpprivkey RzaJyJLZ7gqSC6sfqr6ybJWiu4T1mkZdHc is not known on Windows, whereas it is on Ubuntu.
dumpprivkey SF3UktSxkFm1CZXvNRBkEra2gHjbbF1Qit returns a value on both OSs (this is the address my entire balance was in before the beacon advertisement).
The beacon was re-advertised on Ubuntu wallet, so I guess it was transferred to another address that Windows wallet doesn't know about. I do not run two at the same time, but alternate between two. They are saved on different hard drives (dual boot Windows and Ubuntu on 2 drives) but one is a copy of the other (I started out on Windows, then added Ubuntu). I do have a shared partition that both OSs can access, would it work if both the Windows client and the Ubuntu client access the same wallet file/data folder?
Otherwise I will just stop running Gridcoin on one of the two OSs so that I don't run into this again.
Thanks already to both of you for your help and insight into what I'm doing (wrong).

@jamescowens
Copy link
Member

An automatic readvertisement uses the same key.

@div72
Copy link
Member

div72 commented Sep 10, 2021

@sibebleuze As long as they both have the same BDB version and they're not running at the same time, it shouldn't be a problem. Please also check if they have the same addresses as the keypool might have been re-filled.

@jamescowens They are talking about the change address, I suppose they either exhausted their keypool or IsMine does not check the addresses in the keypool(most likely).

@jamescowens
Copy link
Member

@sibebleuze The PPA for Ubuntu uses BDB version 5.3 whereas the Windows executable uses BDB 4.8. You will not be able to cross utilize the same wallet.dat file for both. (Unless you convince me to make you a special build of the Windows with BDB 5.3 compiled in instead... ) :)

@jamescowens
Copy link
Member

@div72... that makes sense. The change return UTXO on the beacon transaction on the node that did not initiate the transaction will not be seen as IsMine(). On the node that initiaited the transaction, the keypool was utilized for the change address of the return, and so shows as IsMine() and is credited to the wallet's balance.

We should think about checking the addresses in the keypool for the IsMine filter. I wonder if there are any downsides to that? This whole thing is an artifact of running two wallets with (initially) the same set of keys at the same time...

@jamescowens
Copy link
Member

Ah... a better idea would be to modify the beacon advertisement transaction to use the originating address as the change address...

@jamescowens
Copy link
Member

We should go look at that.

@sibebleuze
Copy link
Author

I've had a look at the whole thread again and got some ideas. I decided to first try 'repairwallet', which was suggested somewhere along the way, but didn't do anything.
What did work for me was to take the output of dumpprivkey RzaJyJLZ7gqSC6sfqr6ybJWiu4T1mkZdHc (from the client where the beacon renewal was performed) and use it to execute importprivkey on the other OS.
This way both clients know about the address where my coins are now and I'm good until at least the next beacon advertisement. As said before huge thanks for the explanations and help along the way.
I'll leave it up to you guys to decide whether you want to change something about what happens at beacon renewal or not, but as far as I'm concerned, I'm out of here, so feel free to close if you want.

@div72
Copy link
Member

div72 commented Sep 10, 2021

(Unless you convince me to make you a special build of the Windows with BDB 5.3 compiled in instead... ) :)

@jamescowens May I persuade you to go BDB 5.3 in normal builds? I will eventually(before the next century at least) get around porting sqlite wallets but I'd prefer if we could get everyone to 5.3 for now.

We should think about checking the addresses in the keypool for the IsMine filter. I wonder if there are any downsides to that? This whole thing is an artifact of running two wallets with (initially) the same set of keys at the same time...

I thought about the same thing but I am a bit worried about the possible performance impact. Be reminded that this issue would also affect people using a backup before a beacon advertisement.

Ah... a better idea would be to modify the beacon advertisement transaction to use the originating address as the change address...

Agreed. It might have a little privacy impact as it'll prevent people from crafting beacon advertisement transaction to send coins but that does sound a bit too far-fetched and using Monero at that stage would be a better idea.

@div72
Copy link
Member

div72 commented Sep 10, 2021

Closing this in favour of #2326.

@sibebleuze Please note that while that solution did work for now, using two copies is messy and you will have to manually sync the files.

@div72 div72 closed this as completed Sep 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants