BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

Hi Orbis,
Try starting biblepayd first, then after its started try this:
/biblepay-cli -headlesspodcpassword exec podcpasswordlength
Then type the password, press <enter>

Then mine, and it should work.
As far as the error in getmininginfo, just wait a little longer.

I remember testing this the night I wrote it, but forgot the parameter must include the full 4 words as above...  Ill modify the release notes when releasing tonight.  Let me know if it works for you now.

Of course I started with biblepayd
Then /biblepay-cli -headlesspodcpassword exec podcpasswordlength
Then typed the password
Then get a shower and after that getmining still gives me CPID error
After stoping biblepay it gives me this error:

Code: [Select]

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
what():  boost: mutex lock failed in pthread_mutex_lock: Invalid argument

EDIT: tested on 3 different PCs. same result everywhere. with walletpassphrase is unlock successful.

Of course I started with biblepayd
Then /biblepay-cli -headlesspodcpassword exec podcpasswordlength
Then typed the password
Then get a shower and after that getmining still gives me CPID error
After stoping biblepay it gives me this error:

Code: [Select]

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
what():  boost: mutex lock failed in pthread_mutex_lock: Invalid argument

EDIT: tested on 3 different PCs. same result everywhere. with walletpassphrase is unlock successful.

Its mining for me

bible1:~/biblepay/src$ ./biblepay-cli -headlesspodcpassword exec podcpasswordlength

I do receive the mutex error when I stop the node, but I can see after setting the password the cpid signing error is gone...

Are you sure its not mining for you?

Today I did not receive a reward.  Looking at my tx history, no evidence of a PODC Update tx since 3.11.18 at 08:17 local time.  Was on 1.1.1.0, so upgraded to 1.1.1.1 (although was under the impression that was not required until Thursday).  Restarted wallet, ran exec podcupdate and got the PODC Update tx, but concerned why there was no tx in about 36 hours.

Today I did not receive a reward.  Looking at my tx history, no evidence of a PODC Update tx since 3.11.18 at 08:17 local time.  Was on 1.1.1.0, so upgraded to 1.1.1.1 (although was under the impression that was not required until Thursday).  Restarted wallet, ran exec podcupdate and got the PODC Update tx, but concerned why there was no tx in about 36 hours.

The only reason I can think of is if the wallet was locked or if you didn't have enough stake balance. I think you would need to go through the log file to find out.

Today I did not receive a reward.  Looking at my tx history, no evidence of a PODC Update tx since 3.11.18 at 08:17 local time.  Was on 1.1.1.0, so upgraded to 1.1.1.1 (although was under the impression that was not required until Thursday).  Restarted wallet, ran exec podcupdate and got the PODC Update tx, but concerned why there was no tx in about 36 hours.

Hmmm, not sure if you are using QT/headless or win/lin for the controller but other than ensure that getmininginfo shows no errors after a few mins after boot (to ensure wallet is not locked or throwing a sign error), try checking the log for this:

UTXOUpdate Processed (258) over 1 CPID(s) successfully.
Look for any errors after that entry in the timespan that you were affected in, maybe the wallet threw an error?

Going forward I think the key is ensuring at least 1 thread is running with HPS > 0 and the poolinfo1: row is empty (that is where the errors are shown currently for unable to sign CPID).

Wallet was on Windows 7.

Only odd part of the debug log was

Code: [Select]

13 13:56:24  InstantSend : AllOutPointReady 0.000000, IsLockedInstantSendTransaction 0.000000, bool 1.000000
2018-03-13 13:56:24  InstantSend : AllOutPointReady 0.000000, IsLockedInstantSendTransaction 0.000000, bool 1.000000

repeated close to 100 times, one different statement in that run was

2018-03-13 13:56:24  InstantSend : AllOutPointReady 1.000000, IsLockedInstantSendTransaction 1.000000, bool 1.000000
2018-03-13 13:56:24  CInstantSend::ProcessTxLockRequest successful
2018-03-13 13:56:24  InstantSend : AllOutPointReady 1.000000, IsLockedInstantSendTransaction 1.000000, bool 1.000000

Then had

2018-03-13 13:56:29  InstantSend : AllOutPointReady 1.000000, IsLockedInstantSendTransaction 1.000000, bool 1.000000
2018-03-13 13:57:32 UpdateTip: new best=76c342e700a149155566862dc4ecda777398cf95442ed8bbd0b5ac41be8629b7  height=34370  log2_work=58.86532  tx=130988  date=2018-03-13 13:57:00 progress=0.999998  cache=1.8MiB(2269tx)
2018-03-13 13:57:32 ProcessNewBlock : ACCEPTED
2018-03-13 13:57:49 CInstantSend::CreateTxLockCandidate -- new, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24
2018-03-13 13:57:49 CInstantSend::ProcessTxLockRequest -- accepted, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24
2018-03-13 13:57:49  InstantSend : AllOutPointReady 0.000000, IsLockedInstantSendTransaction 0.000000, bool 1.000000
2018-03-13 13:57:49  CInstantSend::ProcessTxLockRequest successful
2018-03-13 13:57:49 TXLOCKREQUEST -- Transaction Lock Request accepted, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24, peer=816
2018-03-13 13:57:49 CInstantSend::CreateTxLockCandidate -- creating birth, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24
2018-03-13 13:57:49 CInstantSend::CreateTxLockCandidate -- update empty, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24
2018-03-13 13:57:49 CInstantSend::ProcessTxLockRequest -- accepted, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24
2018-03-13 13:57:49  InstantSend : AllOutPointReady 0.000000, IsLockedInstantSendTransaction 0.000000, bool 1.000000

Also for some reason after updating to 1.1.1.1 the whole thing crashed (overnight)

last lines before the crash were
2018-03-14 10:37:57 ProcessNewBlock : ACCEPTED
2018-03-14 10:43:39  VerifyDistributedBurnTransaction::PASS for CPID A895052039C2E80B20C388ACC8AC47E1
2018-03-14 10:43:43  VerifyDistributedBurnTransaction::PASS for CPID A895052039C2E80B20C388ACC8AC47E1
2018-03-14 16:29:41




Wallet was on Windows 7.

Only odd part of the debug log was

Code: [Select]

13 13:56:24  InstantSend : AllOutPointReady 0.000000, IsLockedInstantSendTransaction 0.000000, bool 1.000000
2018-03-13 13:56:24  InstantSend : AllOutPointReady 0.000000, IsLockedInstantSendTransaction 0.000000, bool 1.000000

repeated close to 100 times, one different statement in that run was

2018-03-13 13:56:24  InstantSend : AllOutPointReady 1.000000, IsLockedInstantSendTransaction 1.000000, bool 1.000000
2018-03-13 13:56:24  CInstantSend::ProcessTxLockRequest successful
2018-03-13 13:56:24  InstantSend : AllOutPointReady 1.000000, IsLockedInstantSendTransaction 1.000000, bool 1.000000

Then had

2018-03-13 13:56:29  InstantSend : AllOutPointReady 1.000000, IsLockedInstantSendTransaction 1.000000, bool 1.000000
2018-03-13 13:57:32 UpdateTip: new best=76c342e700a149155566862dc4ecda777398cf95442ed8bbd0b5ac41be8629b7  height=34370  log2_work=58.86532  tx=130988  date=2018-03-13 13:57:00 progress=0.999998  cache=1.8MiB(2269tx)
2018-03-13 13:57:32 ProcessNewBlock : ACCEPTED
2018-03-13 13:57:49 CInstantSend::CreateTxLockCandidate -- new, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24
2018-03-13 13:57:49 CInstantSend::ProcessTxLockRequest -- accepted, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24
2018-03-13 13:57:49  InstantSend : AllOutPointReady 0.000000, IsLockedInstantSendTransaction 0.000000, bool 1.000000
2018-03-13 13:57:49  CInstantSend::ProcessTxLockRequest successful
2018-03-13 13:57:49 TXLOCKREQUEST -- Transaction Lock Request accepted, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24, peer=816
2018-03-13 13:57:49 CInstantSend::CreateTxLockCandidate -- creating birth, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24
2018-03-13 13:57:49 CInstantSend::CreateTxLockCandidate -- update empty, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24
2018-03-13 13:57:49 CInstantSend::ProcessTxLockRequest -- accepted, txid=157a2f1520b375523a3ea5cabef282eeaed7993b412ce40b138c456ae481ff24
2018-03-13 13:57:49  InstantSend : AllOutPointReady 0.000000, IsLockedInstantSendTransaction 0.000000, bool 1.000000

Also for some reason after updating to 1.1.1.1 the whole thing crashed (overnight)

last lines before the crash were
2018-03-14 10:37:57 ProcessNewBlock : ACCEPTED
2018-03-14 10:43:39  VerifyDistributedBurnTransaction::PASS for CPID A895052039C2E80B20C388ACC8AC47E1
2018-03-14 10:43:43  VerifyDistributedBurnTransaction::PASS for CPID A895052039C2E80B20C388ACC8AC47E1
2018-03-14 16:29:41




Nope, nothing in the log related to a PODC update (didnt see the word PODC in there).

Please surround long snippet posts with the code tags.

Regarding the crash we will need to ask you or a volunteer to run it on linux in valgrind mode.

Its mining for me

bible1:~/biblepay/src$ ./biblepay-cli -headlesspodcpassword exec podcpasswordlength

I do receive the mutex error when I stop the node, but I can see after setting the password the cpid signing error is gone...

Are you sure its not mining for you?

Tested today again and now it works
I don't know why it didn't worked before.
But now looks fine. Thanks for it.
I wonder whether it was tested by someone else.

Do you plan to make someting with those mutex error?

Not sure why it would have failed to do the update.  Again, was on 1.1.1.0, Win 7 wallet.  Upgraded to 1.1.1.1, crashed once, no crash since.  No PoDC tx being the issue.  Not mad about missing out on the Superblock reward but can imagine how if I was spending hundreds on a VPN that would be different.  Me, I'm a supporter of the coin, understand things happen.  But want to know what logs will be required to better troubleshoot.

How do I associate my CPID with my other machines, So I can pool mine, without messing up the burn transaction on my PODC machine?

How do I associate my CPID with my other machines, So I can pool mine, without messing up the burn transaction on my PODC machine?

You can't, the CPID can only be used with one wallet at a time. You can copy the wallet to the other machines and just have one do the podc updates.

I also tried 1.1.1.1 and it said unable to sign CPID when I was mining on Purepool.

Not sure why it would have failed to do the update.  Again, was on 1.1.1.0, Win 7 wallet.  Upgraded to 1.1.1.1, crashed once, no crash since.  No PoDC tx being the issue.  Not mad about missing out on the Superblock reward but can imagine how if I was spending hundreds on a VPN that would be different.  Me, I'm a supporter of the coin, understand things happen.  But want to know what logs will be required to better troubleshoot.

Thanks!
So far all I can think of is your controller wallet might have stopped mining, but I cant imagine why.
The first thread, thread zero, has to have a HPS > 0 for the PODC update to work.
As far as what it logs, it should always log "PODCUpdate" in the log - and then something after it.

I suppose this will all come out in the wash.  Ive been mining on my dev machine controller wallet for 4 days now and have gotten in every superblock and each PODC update, but I realize there are still some situations out there that are unaccounted for.

Please see the PODC Update section regarding frequency, on an unrelated note if anyone is interested in *when* the miner sends it:
https://wiki.biblepay.org/Distributed_Computing#PODC_Updates

How do I associate my CPID with my other machines, So I can pool mine, without messing up the burn transaction on my PODC machine?

All you can do is copy the wallet.dat out to the other mining machine, and mine from that machine.  It will sign those pool packets with your primary cpid then.

Some people have recommended starting a second CPID, but I do not recommend that, as we have a rule that you must be in the prior superblock with magnitude to receive payments, and therefore that second cpid would not be helping the network.  And in lieu of that Im going to work with Lich to stop that reward in the pool on both of our pools so we can reward the *real* CPIDs more BBP asap.

Tested today again and now it works
I don't know why it didn't worked before.
But now looks fine. Thanks for it.
I wonder whether it was tested by someone else.

Do you plan to make someting with those mutex error?

Yes, let me take a look at the mutex.  I think all that is happening is its locking the mutex and then when leveldb gets flushed it is unlocked when the thread is aborted.

The main concern I have is to ensure the wallet is flushed during exit.  I have reports here that some coins on bittrex take 35 seconds to exit because they have so many keys.  Ours is definitely getting flushed, and thats my main concern so we dont corrupt users wallets and allow them to lose any funds.

Luckily we have wallet backups also.