So what we did was we loaded the system by clicking on one of the fingerprints of the three. In the past, I was always loading up chia by inputting my mnemonics. I’m thinking about bringing chia down and bringing it back up with my mnemonics vs the fingerprint to see if that helps. Any thoughts?
Afaik they’re one and the same expressed differently, I’d guess the fingerprint is just a hash of the mnemonic.
@drhicom the file is located:
If no Chia GUI is available, refer to the “config.yaml” file and search for “xch_target_address” field
Halftime…I will go close chia and bring it back up with the mnemonics. More to come.
1 Like
I closed chia out, brought chia back up. I’m on 1.2.9. There are three fingerprints all with different addresses. I’m thinking one was created when I was a solo farmer, one was created when I was with MAXIO and when they went under I went to Space. Does that make any sense or am I off base?
As initially mentioned, I really don’t know much about multiple wallets.
Is it possible that Larry is farming on two wallets, and that block went just to another wallet?
How did you switch from solo to MaxIo? Did you delete all your OG plots, and plotted new ones? Also, when switching from MaxIo, did you replot again, or just switched the pool?
Also, when running plot check, will it show just the current wallet plots as good, and those other as potentially bad, or you need to check every single one for contracts?
Great question…Need some more brian power here…LOL…We should be able to track down the .25? that’s what blockchain is all about.
@Jacek in my peer connections, I now only have 8 even though we set the file to 20. Also, the speed on the nodes is very small. Prior to closing chia down, I still had a gig being shown. I’m synched and I do not need that speed, but shouldn’t it try for 20 connections? It is acting as if port forwarding is not turned on which we know is not the case.
No, after MAXIO went away, I just left the pool and joined space via the URL. Very easy process.
If you did that, that is not creating a new wallet. So, the question is how you got those three, and whether it is possible to farm on two at the same time.
Could you check on your NVMe in wallets/db folder how many wallets are there (each will be ~15GB ending with sqlite)…
Yes, that would be good for the whole network, but I am not sure whether that would improve anything on your side. Again, the sync process runs with about 2Mbps speed, and I doubt that it depends on how many peers you are connected to, as it smells like it is just talking to one peer at a time.
I would bump it up to 30 peers, and watch what will happen.
Also, today, I lost power, and was watching Chia starting. Every time a new peer connected, it stayed at 0 height, and after a few secs, the height got adjusted. What it mans (I think) is that if anyone sees those peers with 0 height, that implies that his node is SOL for whatever reason, and cannot properly chat with those peers. Therefore, no point to kill those peers, as that is a local problem. The main reason that I think that this is the case is that we all would be seeing those 0 height nodes left and right, and we don’t. Also, as someone suggested that it only happens when you restart chia implies that chia lost sync, and is basically screwed up on the syncing process, thus cannot chat with those peers. (Wrong conclusion that was really promoted during / after dust storm.)
Sorry that was my mistake. My wallet is also 7GB.
So, you have just one fully synced wallet. I would try to restart chia, select another fingerprint, and check how fast it is updating. My guess is minutes, but I have never done it. If it is fast, I would let it fully sync, and check the addresses for that wallet and its pool. Then would do the same thing for the third fingerprint. Maybe one of those extra fingerprints will have that .25 XCH. Also, when you will be doing that, check on the pool side, whether there are any plots for that pool.
Maybe before doing that, delete that first file there (178…44.sqlite).
Oh, and I would check those wallets while still on 10 peers. Every single peer is adding load on blockchain db, and we know that that part really sucks. Once you check those wallets, then bump those peers to 30.
Yes, that’s correct. I forgot about it. The original folder is wallet/db, as looks like the guy that added that part had no clue that he could just rename that db folder to wallet, and be done with that (standard copy-and-paste mistake). When we moved those dbs to NVMe, we didn’t use that extra folder (no need for that extra depth).
Ok…deleted the file…I’m going to wait until tomorrow to do the test on the other two mnemonics as my payout from space is coming up at 2215 tonight.
What do you think is causing these sporadic errors?
2021-11-18T18:52:34.152 full_node chia.full_node.mempool_manager: WARNING add_spendbundle 04fb069447b4595b8dbb859a18f230f9324c510df6c7dab5ab8f65597f493c3e took 1.32 seconds. Cost: 1512177655 (13.747% of max block cost)
2021-11-18T19:00:53.525 full_node chia.full_node.mempool_manager: WARNING add_spendbundle 33234dceee70d4997395fb0245be9026f88274a858204f22675a8f598f304d79 took 1.01 seconds. Cost: 1165593967 (10.596% of max block cost)
As you know we don’t have a speed/throughput issue at any level. The rig is 100% to chia and nothing else and when we perf mon, nothing is getting tasked heavily.
1 Like
I really rarely check my logs. Although, about a month ago, those things started to pop up, and there were discussions around those. I think that consensus is just to ignore those. It would be good, if chia would move those logs to DEBUG level, as those only clutter the INFO level.
That is maybe not really true. I was watching my NVMe today (when chia was starting / syncing), and I saw that db access was kind of heavy, but with really little chunks (I think), still that db suffered (basically choking that NVMe with Kbps speed). I am still on v1.2.6, so cannot say whether v1.2.10/11 are any better, but I would not bet much that it is. I read post mortem for dust storm, and basically what was done is what I have also originally stated. If that was not in place day one, I really don’t know what they were thinking writing that code. However, this brings me on a tangent again.
Till tomorrow.
1 Like
I’m no expert by any means but I don’t think you can actually farm on two wallets. But you can have two wallet addresses that receive payouts. The Farmer and Pool reward addresses in the Farm section of the GUI in case of OG or solo farming with NFT plots, and the Farmer reward address in Farm section (for the .25 xch) plus the pool payout address in the Pool section (for daily payouts from your pool) in case of using a pool with NFT plots. When using a cold wallet for instance your receive addresses are on some other wallet then the one coupled to the keys your farming on, on purpose! But it always take some kind of manipulation, in the GUI, in the config.yaml, on purpose or by accident…
Also see https://github.com/Chia-Network/chia-blockchain/wiki/Chia-Keys-Management#2-keys-farming-key–cold-storage-key
(This is from the pre NFT era so does not mention the pool payout address but the same principle applies)
2 Likes
Thank you! Now I got it.
I really don’t understand why life has to be so complicated. How much extra work would it require to duplicate that “Farmer reward address” in the Pool section, next to the “Payout Address.” That would let you just check one place, and be done with this crap.
So, forgive me for that dumb question about farming on two wallets. As you pointed out, it looks like that .25 XCH address (Farmer reward address) is most likely pointing to one of those other wallets that Larry somehow got created. Hopefully, tomorrow Larry will sync all those extra wallets, and one will turn up with that .25 XCH.
Although, someone mentioned that if you make a mistake in your payout address, XCH will still be sent to that garbage address (without barfing on the sender side). In such case, whatever was sent there is basically lost. Is that a possibility?
1 Like
Yes I think so. Those crypto addresses are long and a typo is easily made. But without a centralized ledger I would not know how a client could check for non-existent or wrong address-usage. User beware…
Are you saying that those addresses are buried in the wallet, and not really in clear in the blockchain? If that would be the case, how sites like chiaexplorer would be able to pull info on those addresses? Or, I am again missing something?
I just checked chiaexplorer, and provided my good address, and a bad one (changed a couple of chars). In both cases, chiaexplorer seems to think that those are good addresses. Of course, the good one has some XCH, the bad is blank. Maybe the question is when such address is created in the blockchain. Is it assumed that all addresses are valid (e.g., those with say exact number of chars, etc.), or rather when you create a new address it is written to the blockchain. If it is the latter, then chiaexplorer should not be able to find a bad address, as such that would be the check that it is garbage. I really don’t know much about that side.
No it must be on the blockchain as you say. But traversing the entire blockchain just to check if an address really exists is maybe a bit to much to ask. Although sites like chiaexplorer.com are really quick with searches for addresses. Maybe it’s feasible then, don’t know. But still user beware, its crypto so you are on your own, no friendly helpdesk agents from the bank to call.
Also i don’t think ChiaExplorer runs on a low powered database engine…
1 Like
That’s true, but my understanding is that chia only operates on local dbs, not on the network (yes, getting updates from the network, but the rest is local). So, that should not take too much to check it. Plus, if pool is sending it, that is potentially as powerful, or maybe even better H/W than chiaexplorer.
Lastly, when you are on chia UI, and let say enter a garbage address in that pool section, chia has all the time it needs to walk through that local db to make sure that no mistake has been made, and warn you about such mistakes.
What chiaexplorer may be doing is similar to what local chia does for wallet - it grabs the whole blockchain, and then extracts those addresses to a secondary db that is used for lookups. That can speed up the lookup process a bit.
Thank you @xkredr59 , I learned something new today 
This time, it is my time to go to bed.
1 Like
On second thought i don’t think its feasible to precheck for valid addresses.
Your wallet can generate a multitude of different secondary addresses. I think an address is only included in the blockchain as part of a transaction, not before. So if i were to generate an next address o n my wallet and send that to you requesting say 1000xch please, you using that address (thank you) will include that specific address as part of a blockchain transaction, but not before. So any correctly formatted recieve address will do and will be part of the blockchain after being used in a transaction.