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

It worked! The funny thing is that I didn't even have to exec podcupdate to see the utxoamount again.

Some samples

2hr before updating (still with 1.1.1.1):
3abf4bdd39b918de8354df6143ac53f5948d7a16ea1b454ea7ee82e6570923b7

After updating to 1.1.1.2
632d8ec195e01a3679d0928196da7739e2e3912592dab84afa353bd1880c9a4a

Great!  Yes looking at getrawtransaction 632d8, it looks correct now.  Awesome.

Yes, doing the exec search utxoweight 9689, I can see your weight now.

Thats good we have this flowing out earlier in the cycle before we have a lot of researchers, as that malformed sig could be a crash risk, although I see the code handled the malformed sigs OK but would rather not see it iterating over hundreds of malformed sigs obviously.

It was the biblehash functions late block threshhold feature.  The feature considers a block late after 15 mins, then reduces difficulty to make it 90% easier to solve by anyone (including non cpids).  The average amount of late blocks added 20% to the daily duration of blocks, despite having 420 seconds set in DGW (which is our difficulty algorithm).  So to fix it we now undershoot it by 20% - that teamed up with some 15.01 minute blocks averages out to 7 mins now.

Thank you for the clear explanation I understand.

In other news: I got an unbanked pool-payment again!! 

Rob, Don't know if you know but there seems to be a problem with the blockchain. We are stuck on 36079.

Didn't get a payment again with my pool-unbanked-account 

Code: [Select]

36285 3/23/2018 9:35:55 AM jaapgvk_unbanked_poolCPID 8791a036b545f35e9ebd9333922738ac 0.059 1986929 15044 0 0 5069682 1 0 299 299 1 4
I did get a payment today Just keeping you updated. Let's see how it rolls from here...

I'm trying to change the number of threads on a linux machine but I'm getting this error:

biblepay-cli setgenerate true 4
terminate called after throwing an instance of 'std::runtime_error'
  what():  CWallet::GenerateNewKey(): AddKey failed

It crashes the daemon and I have to restart it.

Noticed setgenerate true will only go up to 3. Set to 4 threads and it will crash.

Debug.log

Code: [Select]

2018-03-26 03:25:18  ** Started 3.000000 BibleMiner threads. **
2018-03-26 03:25:20
BiblepayMiner -- terminated
2018-03-26 03:25:20
BiblepayMiner -- terminated
2018-03-26 03:25:21  Starting Thread #0.000000 with Bible #0.000000      2018-03-26 03:25:21 BibleMiner -- started thread 0.000000
2018-03-26 03:25:21  MinerSleep 0.000000
2018-03-26 03:25:21  Starting Thread #1.000000 with Bible #0.000000      2018-03-26 03:25:21 BibleMiner -- started thread 1.000000
2018-03-26 03:25:21  MinerSleep 0.000000
2018-03-26 03:25:21  Starting Thread #2.000000 with Bible #0.000000      BibleMiner -- started thread 2.000000
2018-03-26 03:25:21  MinerSleep 0.000000
2018-03-26 03:25:21  Starting Thread #3.000000 with Bible #0.000000      BibleMiner -- started thread 3.000000
2018-03-26 03:25:21  MinerSleep 0.000000
2018-03-26 03:25:21  ** Started 4.000000 BibleMiner threads. **
2018-03-26 03:25:22 keypool added key 1102, size=1000
2018-03-26 03:25:22 init message: Loading wallet... (110.09 %)
2018-03-26 03:25:33


Is anyone else getting the message in Boinic that there is no work to do ?

Is anyone else getting the message in Boinic that there is no work to do ?

Yeah, it seems like Rosetta@home has run out of work for the moment. You can check the server-status here:
https://boinc.bakerlab.org/rosetta/server_status.php

(It does say 'Tasks ready to send 18124'  on that page somewhere, but I don' t know what that means exactly.)

There is work trickling down, probably from workers who have passed the due-date. Can' t really find any news about this. Maybe they are adjusting the work. There was something similar going on with the Android tasks about two weeks ago.

Or maybe it' s because they can't handle the growth of Biblepay

Didn't get a payment again with my pool-unbanked-account 

Code: [Select]

36285 3/23/2018 9:35:55 AM jaapgvk_unbanked_poolCPID 8791a036b545f35e9ebd9333922738ac 0.059 1986929 15044 0 0 5069682 1 0 299 299 1 4
I did get a payment today Just keeping you updated. Let's see how it rolls from here...

Also got a payment today. And I also signed up another pool-unbanked-testaccount that also got payed.

Seems that not getting payed a few superblocks ago was just a one-off thing...

encryptwallet  seems to be missing from the cli help.

I got an error last night on 1.1.1.4.

gzip: /home/biblepay/.biblepaycore/SAN/user2.gz: unknown method 50 -- not supported

I've got three exactly the same payments in BBP in a row on my unbanked testaccount:

http://explorer.biblepay.org:3001/address/BNfb6uMyeAHDwZs538gzxS2k2iqbz8NWQj

CPID: 8791a036b545f35e9ebd9333922738ac

Coincidence or bug?

I've got three exactly the same payments in BBP in a row on my unbanked testaccount:

http://explorer.biblepay.org:3001/address/BNfb6uMyeAHDwZs538gzxS2k2iqbz8NWQj

CPID: 8791a036b545f35e9ebd9333922738ac

Coincidence or bug?

Got another two exactly the same payouts in a row.

Getting these errors on my linux machine.

************************
EXCEPTION: NSt8ios_base7failureB5cxx11E       
String length limit exceeded: iostream error       
biblepay in ProcessMessages()       



************************
EXCEPTION: NSt8ios_base7failureB5cxx11E       
String length limit exceeded: iostream error       
biblepay in ProcessMessages()       



************************
EXCEPTION: NSt8ios_base7failureB5cxx11E       
String length limit exceeded: iostream error       
biblepay in ProcessMessages()       



************************
EXCEPTION: NSt8ios_base7failureB5cxx11E       
String length limit exceeded: iostream error       
biblepay in ProcessMessages()

I just leave a quick note to say that my windows wallet has stopped to send automatic PoDC updates a few days ago. I tried to restart and all that but to no avail.
 
Currently I'm doing it manually every 12h to keep on staking. I don't know where to start checking but when I have a bit more time IŽll check the logs in case I see something evident.