Did you run the chia db upgrade ?
PS C:\Users\user-name\Appdata\Local\chia-blockchain\app-1.3.5\resources\app.asar.unpacked\daemon> .\chia db upgrade
1 Like
Seems like I didnt, my bad. Already initiated it via CLI, should be done in 15 minutes or soâŚ
EDIT: nope, it will take much longer, I am stuck at converting coin_store phase right nowâŚ
1 Like
When its done, check your config.yaml on main node and wallet section. The wallet may still say v1 but the code is talking to the v2 db, (says the guys in keybase) so you can just edit it to be happy.
1 Like
Current db size is 82,813,292KB on my node now.
1 Like
OK nice, so it is somewhere around 50% of the v1 size, good to hear that.
Yeah, that is the retarded part. The code doesnât care (to some extent) what config.yaml is trying to enforce. Somehow, the dev that implemented bc db update added config.yaml change, but the other guy that worked on wallet db had no clue why it is needed (as apparently it was not affecting him), even though we are at v1.3.5.
When you get your bc to v2, the wallet code will try to switch to use that bc only (i.e., not connecting anymore to remote full nodes). It looks like that this process is a bit buggy (well, whatâs new), so this is what I had at #6 above. Just start at that point and work your way down.
Again, donât fret if the wallet will not show the latest transactions, give it plenty of time (an hour / two each time you run full wallet sync), and if at that point it will still not show the latest, kill your wallet db, and let it sync from scratch and be patient again (again a couple of hours or so). This time, your wallet will basically piggy back to your full node (recognizing it as a trusted one), and most likely clear all the problems it got during the transition from peers to your local full node.
By the way, the bc upgrade process takes about 1 hour, if you have a fast CPU and NVMe holding bc db. Some people reported 2-3 hours. That process is actually disk intensive, what it means it may interfere with the normal node operation (if transactions level is higher than normal). So, I would rather stop the node, and give all the resources to that process. This also has the benefit of bc db not being used, what makes it a bit safer to do the upgrade (IMO).
And as they say in Chicago, reboot early and reboot often, as chiaâs shutdown process is also buggy.
1 Like
Yes indeed, the shutdown process is not optimal. My farm is sitting on Samsung 970 EVO PRO and got some i5 9th gen with 16 gigs of fast ram, so it is going pretty quick. I am currently at 40000k coins, should be done in less than hour.
So after finishing the conversion, I will kill the GUI and processes, remove v1 mainnet file, link config.yaml paths to both v2 (mainnet and db) and that should be all�
I would not remove bc v1 file, but rather keep it for a week or so, in case something goes South.
Most likely not, this is where the wallet db dance starts. What will happen is that once you start chia, it will take some time to sync bc db. Most likely during that time the wallet gets confused, and may go bad. So, once you have bc db fully synced, I would stop it again, and kill wallet db, just to make sure that nothing is lurking there. It was just too many reports from other people about their wallets being screwed around that time that it is better to be proactive.
By the way, you donât need much RAM on the harvester, but on your full node, any extra RAM is used by OS for file cache (there is some registry setting for large cache that is worth to add). That cache is helping with db operations, especially during dust storms (or like those db upgrades). So, I would get another 16 GB of RAM, if you can fit it in your box. The CPU and NVMe you have are more than enough to run it smootly.
1 Like
OK, seems like a bit more fun here 
I must admit that mining eth on GPUs is a lot more easier but also not very challenging. Chia is at least from my point of view more like learning on the job aka trial-and-error procedure (which costed me money, sadly⌠not just time). Also we all surely spent a lot of time optimizing plot creation, actually 2 times (OG and then NFT plots).
1 Like
I guess what is frustrating that things like that wallet db v1/v2 nonsense is not fixed, even though it was introduced in v1.3.0. Looking at the current stats, there are around 150k nodes that need to go through that process. This change already has the template (bc update is done right), so not that it would require much time, but rather one dev spending his coffee break to get it done. Yet, Chia prefers to push problems like this on those 150k nodes out there. Just mind boggling for me.
I checked that github thread you started. Consider it more like a car with square wheels - you donât push, it will not move forward. Most likely you get an answer if that is something easy. If that is something rare, it may just turn stale if you are not pushing. So, once you get stable on v1.3.5, just update that with your plot check results and ask what else you can eventually do to get that guy engaged. And just keep pinging on it from time to time. It would be really interesting what will happen when you win the next block with Space.
By the way, I donât think that you have enough plots to go solo (there is another active thread with people being 5x-10x behind right now, so factor that in as well). I mean, you can go solo with just one plot (or rather having just a handful of plots makes it more like a lotto, so worth going solo), but when you join a pool, you get some extra stats (points / stales / duplicates / âŚ), so you can further fine tune your farm. The 1% or so that it cost you is money well spent (at least IMO).
1 Like
I absolutely agree, there is just a lot of things which are tricky and not clear at all. It is easy to make a mistake or to forget something which may (and probably will) cost you money from potential or realized block rewards.
OK, so it seems like DB update went well, I did have both v1 and v2 files in my mainnet/db folder, client still synced the v1 file tho. So I killed the client and all related services via CLI, moved v1 db file of size 150 gb out of the folder, kept v2 there only (current size a bit under 80 gigs). In config, full_node link was already switched to v2, wallet still linked to v1 - as you mentioned. So I changed it manually to V2 and now it seems like I am fully synced - mainnet and wallet as well (v2 mainnet file quickly caught up the missing 6-7 hours), pooling with Space pool (checked also with chia plotnft show command - all of my plots farming_to_pool status with space pool), client version 1.3.5.
Yes, I will increase the effort and push it more, hope someone will notice and get back with any resolution.
Regarding solo vs. pool - yes I know, I just did have my sixth sense kicked in about a month ago and it was (exceptionally) a good one - I hit 6 blocks with my 2679 plots in last 30 days. Sadly, half of them went to flexpool wrongfully.
1 Like
Hi, so I prepared the print screen. I can also upload non-compressed pdf somewhere and paste the link here, if the pics quality will be low.
I can see the pics are really small, so here is the link for pdf: https://drive.google.com/file/d/1Q0DYoIG5rRjeMcv_g8lQMARKr3UVayNI/view?usp=sharing
As I mentioned earlier, if you ask me, I would rather try to keep this thread only for the potential problem you may still have, and donât pollute it with anything else. Once you hit the next block, and the problem will still there, maybe we could gather all the info needed to document what happens. If we would be able to produce that info, I would use whatever we gather, and maybe try to revisit what you collected so far, and eventually update it respective to what we gather here. Although, I would do it in another thread.
Also, whoever is on this forum has slightly different interests, different experience / expertise. I have seen people doing magic analyzing transactions (I am not one of those). However, each and every time I saw that, they had the full transaction data. So, when you mask that info in those files, I doubt that anyone from those people will have something good enough to eventually check something. I do understand that this is borderline privacy issue, but so far, I have not seen on this forum anyone complaining that the info that was used / needed to do those analysis was used inappropriately.
Also, if you want to start that process right away, again I would rather say not to mix it with this thread, and really start a new one. Sure, this is basically one case, but people attention is short, and easily diverted when posts hit different problems. At least that is how I would see.
1 Like
Actually, I would suggest that you change your three rcv. addresses to a newly generated one. This way, it will be maybe easier to see what happened just on that one address (when it was created, what pool was depositing to it, where those 1.75 rewards went, âŚ).
1 Like
Im really not sure much can be analysed here⌠( address wise ).
We know coins have been claimed that shouldnt have been from the nft.
This makes me think either theres a serious problem with the pooling protocol, or possibly user error, or a pool having the ability to claim a reward they shouldnt.
As some have supplied certain keys to pools to sign for them, this introduces another possibility, that the pool is a bad actor. ( im unsure if thats even feasible as im not sure which keys allow access to what, or what keys the op has possibly sent to some other entity.)
1 Like
That is kind of my point with this thread. I would like to see whether the problem is still there, and if it is, be able to save all the logs, or other relevant info, e.g., pool screenshots, etc. Maybe that will eventually point where the problem is, and maybe will have enough info to have Chiaâs devs to pick it up.
Flex was rather a reputable pool, so I would not think that it was done intentionally by them. With the info so far, it doesnât look like an user error as well. So, it may be as you said some rarely seen pooling error, or maybe some problem with bc handling pool changes events (kind of like dust storm related, but those problems didnât happen during any of known / bigger dust storms).
Therefore, I am not really so keen right now to look at those images right now, as I am really waiting to see how the new win will be processed. (Although, maybe v1.3.5 somehow cleans up the issue when processing wallet data, and we will not see it anymore.)
Assuming that the problem is still there, and it is really code related (a rarely seen bug), I really donât like how Flex handled it so far, as I donât see that they have any data on hand to support it one way or another, but rather speaking âfinders, keepersâ language. Whatever Chris quoted / provided is just a bunch of BS and whining, at lest so far, so that doesnât make me warm and fuzzy about what happened.
2 Likes
Me either.
When i joined space i must have had a reward unclaimed on my nft, or pending to my nft, when i looked at space portal it clearly showed i had a reward that they had claimed that was due to me alone.
After a quick verification with them they sent the whole reward to me.
It seems flex is happy to not bother checking and just distribute any claimed rewards with no thought to fairness. Really puts me of them tbh.
2 Likes
Few more thoughts. Once you win the block, donât claim it, if needed, donât act on anything. Just report, and start collecting the info / taking screenshots. Maybe this way, you could gather more relevant things to show how the process worked.
Maybe one more thing that you could do. Go back to your github post, and bullet list what you have done so far (e.g., upgraded to 1.3, resynced from scratch, increased log level to INFO, âŚ) and ask emlowe whether he would suggest anything else you could do, to be able to better troubleshoot it in case it happens again.
1 Like