Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 579. (Read 243376 times)

You may need to open your taskmanager and set the BBP wallet priority to low. Are you interested in PoBH mining (heat mining) or PoDC (cancer mining)

edit the settings in boinc,  there is an option that defaults to not run when 25% of cpu is used, up this to 75-90?

So I have Rosetta and BBP wallet downloaded. Rosetta works fine until I start the BBP wallet and then I get CPU is busy on the Rosetta software, will I still be able to mine?

Wow, what a weird coincidence
But great that you could solve it ^^

So I have a mini-update on last nights debacle delaying the daily superblock.  I traced the corrupted CPID record down to CPID 6cf45c3b with a magnitude of .576 and RAC of 2617.  It looks like what happened is the user associated his CPID from his home PC wallet once, then went to the pool, associated the CPID with the home address using the pool, (which is for unbanked only), but the user has both non-arm RAC and RAC, then associated the same CPID back at home with the force command during the same time 36080 was being voted on.  Since the sancs were in the middle of voting for 36080, the contract with the highest votes had an unsigned CPID payment address at the time the vote was being approved, (in position 13), meaning the superblock had 1 invalid address in it but yet +1 valid payments, which made the entire contract invalid, but yet the wallet itself kept asking Is this superblock valid, and received a Yes, therefore it did not want to pass (to the next block via heat mining) - (which I still like that as we did not Lose all the payments, so that rule itself is good).

So the good news is the upcoming next block does not have this problem in it  -  as this CPID is now associated with a signed wallet, so we have a little more time for a fix + deploy.  In the mean time I have added business logic to prevent this problem (requiring Sanctuaries to upgrade). 

Normal users and exchanges do not need to upgrade.  This leisure should be out by the evening.

Everything looks fine. In fact you are included into next block, check with "exec testvote" and you will see your address in the list (the second to last, 934.4 reward at block 36285)

Just in case, update to latest version 1.1.1.2 whenever possible.


 

But the seed on good soil stands for those with a noble and good heart, who hear the word, retain it, and by persevering produce a crop.

Thanks for looking into this. Here's the output of exec getboincinfo:


My biblepay version is "wallet_fullversion": "1.1.1.1"

One of the PODCupdate transaction IDs (latest one actually): 9c1010cbea50c3f4b75abe495809efe5c153fff53a72c4bae487606cfb742ae6-000

Let me know if you need anything else

I get TaskWeight: 100 and UXTOWeight: 50001, which is okay since I have >50001 coins in my wallet. A bit misleading, pool.biblepay.org shows TaskWeight: 100 and UXTOWeight: 100, I assume that means UXTOamount which gets you 100% of rewards...
Another strange thing, pool.biblepay.org actually shows some magnitude (~0.7), but executing getboincinfo from my wallet shows 0. I confirm that both CPID are the same (the one registred on pool, and the one that getboincinfo shows).

As stated above, please post "exec getboincinfo" results, your current wallet version, and if possible, one of the transactions id's of the latest PoDC updates so we can check.

when you do exec getboincinfo
what do you guys get back for TaskWeight and UXTOWeight?

I was having the same question as you.
BTW, Is it clear for me how RAC and Credits are extracted but can someone explain to me how the "Magnitude" is calculated?
Thanks!

When do you actually get coins after superblock?

I have been running BOINC for around 3 days, and have 58,779 total credit and 4,696.95 RAC. My wallet, that mines always with genproclimit=1, ran multiple PODC updates (I can see them in "Transactions" tab). I still haven't received any transaction regarding PODC, thou I have received some transactions from purepool for heat mining. "exec getboincinfo" shows 0 for magnitude, which is strange (since it shows RAC correctly).

I'm curious what the issue with payment #13 was,  was it deliberate, or just an edge case.

Nice work Rob. Thanks for fixing that

It worked, thank you Jesus!

So the issue was the 13th PODC payment was corrupted, I dont know why yet, but Ill be analyzing the bad block and looking for a future solution for tomorrows block.

The great news is everyone got paid except recipient 13.

Looks like it's working now on miner end, also PODC updates are now being confirmed. Not sure about rewards.

Now vote in the fixed superblock:

gobject vote-many d8d6d4b43046c7a8f14acd2dfc31a49206e6e3e5b0e1e370a5797d2248a0c40f
funding yes

Sancs, please vote down the current bad podc superblock:

gobject vote-many e41abd03827ac74114b118e602bd04d2cd9c0a4cde96f5b78c96f2695f8059b8 funding no

Thanks, on the road but luckily I have the laptop, checking into this... so far it appears the daily superblock failed and the chain wont accept a normal block in place of it...

Checking....