2 wins in just under six months with a 20 day ETW is not, “doing just fine”. It should be closer to 9 wins. Only two wins in 6 months with 3649 plots is not as bad as getting struck by lightning but it is still too far out of the likely spectrum and I would continue looking for an underlying issue.
Oldschool issues like response times to recent problems with “underpowered nodes” (Chia Inc has yet to explain exactly what is underpowered) there are many reasons why you can miss winning blocks and many smart people and good tools to help you find them and optimize your setup.
Even is huntingground is just super unlucky, a thorough check and system optimization can only make his luck better, even if no single source problem is identified.
Yes, that was the OP’s original question.
Taking into account he started with zero plots 6 months ago and he’s still plotting it’s save to say that the 20 days ETW was not during all those months. Even then there have been some pointers for and checks done by @huntingground but nothing really strange came up. Well, one thing very strange and that is the reward address in his config not being in his wallet so the GUI showed zero all the time. And now two questions remain… how did this ‘strange’ address get there and how to recover the 2.25 rewards sent to that address… Answerring the first one may be the only route to answerring the second…
If you belong to a pool, using time for ETW is rather useless. You can have your farm down for a month, and then when you start it again, it will tell you that it is XYZ weeks, but you are already one month in without submitting a single partial.
On the other hand, using pool rewards is a better way of looking at that, as it describes how many partials your farm submitted (excluding stales). Therefore, for every 1.75 XCH (excluding pool fees), you should have on average one win. This approach removes time and plots ramping up from the equation.
@huntingground If you think that you have never generated two mnemonics, then I would assume that one of the pools that you have used changed that. Since you have started early, did you belong to some unofficial pool (e.g., hpool) while using OG plots that could do that swap on your behalf? What pools did you use before. As @Bones pointed out, the fact that those coins are still there, rather indicate that the behavior was not malicious (e.g., compromised system / third party software), and point either at something you did or some pool you belonged to did.
That is assuming that the pool was malicious. Maybe that was a new pool that had some bugs there at that time. We have to assume that this swap happened not when the first block was won, but rather right after the very first plots were generated, and pools were just starting up (May, June ?).
So, a list of all pools that were used would be nice, as potentially someone went already through that problem with one of those pools, and maybe such pool would know how to access such wallet (if that is the case, of course).
I think it was never possible for a pool to change something in a clients config. The reward addresses can only be changed by someone with (remote) access to the client, by manipulating GUI settings or straight into config.yaml.
Well thats my take on it anyways;-)
And indeed a merry christmas and happy holidays for all here
I do hope this thread will come to some kind of conclusion.
Most of all for @huntingground but this kind of thing keeps bugging me.
One more try from my side, @Huntington:
Did you ‘play’ with the light wallet beta at some time?
The light wallet generates child addresses from the master key by another method, so funds to those addresses are not recognized by the standard wallet.
Still part of the wallet, but only visible/recognized on the light wallet.
So generating a new address on the light wallet and then setting this up as reward addresses in your client could give the same effect. Standard wallet does not recognize it as a valid child address and can’t show funds there. Light wallet would show those funds just fine.
Nah, you didn’t change anything in the client config…
" So what is happening to people? Are they being hacked? Maybe, but probably not. It looks like are two main things going on: the first is that users who have or have had multiple keys on their system are farming to their second key with the farming rewards set to the first. This is actually a preferred security architecture, farming to a wallet not accessible to your farming machine. It is nice to know its setup like that. That’s what happened to this reddit user here, and I have seen a lot of users find their missing XCH in another wallet they control.
The second situation might not be such a pleasant outcome. The OG pools, like Hpool (EDIT: it has been brought to my attention that Hpool’s client uses a different mechanism to capture rewards and is likely not changing xch_target_address) and Core-Pool, work by using a custom client to change your reward address to one they control. Foxypool doesn’t do this and the farmer keeps the 0.25xch reward, but the other custom pools do pool the entire 2xch reward. Because of this while you have their software installed they redirect all block rewards to their wallets and then split them up amongst their farmers. So people are finding that even after they have left their OG pool and joined an on-chain pool that they still lose their farmer reward portion when they farm a block.
I spoke a little bit about this to the developer of Core Pool, and he said they have absolutely seen this problem. That they go to great lengths to prevent it from happening but that it still can. He says they have had a “Leave Pool” option in their software that puts everything back to normal using a config_bak.yaml file they create during original installation but that there are situations where a farmer doesn’t activate that functionality by losing power or turning windows off without closing the software it won’t properly revert the address. The other situation that can be shocking to people is if they are farming both Core-Pool and NFT plots to an on-chain pool the Core-Pool client will capture the farmer reward portion for Core-Pool regardless of which plot wins the block. But they are dealing with this too, they are sending the 0.25xch back to their farmers and their newest software version will automatically handle that portion. They have also been returning rewards to people who contact them and they really do seem to be trying to sort this out for their users."
You mean you have two .sqlite files in ~/.chia/mainnet/wallet/db?
If so the fingerprint is the last 10 digits before the ‘.’
If you have two fingerprints you have at some time had two mnemonics.
I think if the first one has no hashes it means no sub/child addresses were generated for that wallet (no sure but make sense?)
That would support the assumption a chia client on first use builds config.yaml, containing the first wallet address from the first set of keys generated or imported and never changes it. Only by manipulating GUI or config.yaml by the user can ‘overwrite’ farmer and pool reward addresses. And you didn’t.
Problem is that first set of keys/fingerprint somehow escaped your attention.
All this on the assumption you have two .sqlite files of course…
Here is an idea. I don’t know what operating system you are using.
1- Close all chia process
2- Rename all chia and chia-blockchain folder. For windows: c:\users\USERNAME.old_chia and C:\Users\USERNAME\AppData\Local\old_chia-blockchain
3- Uninstall and reinstall chia application.
4- You may see all key with old key at chia startup
do you think the key may be saved in registry somewhere?
-Yes. keys are always stored. Unless you delete it manually from the chia app.
Maybe config.yaml is wrong. The keys are still on your computer. If you haven’t formatted this computer since you started chia. I don’t know where the keys are stored. Maybe in the registry.
I know this because when the new chia version comes out, I back up the old folders. I uninstall Chia and always do a clean install. I just move DB files from old folders to new folder.
