BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[Borgholio]

For me it seems that the wallet prefers the funded ABN instead of the unfunded.  Exec getabnweight shows I have over 400k but it still goes for the funded worker instead.  Also in a maybe-related note, when I disabled the funded ABN worker in my config file last night, it seems I stopped mining about 4 hours ago even though I have enough ABN.

[1715089140]

1715089140

[1715089140]

1715089140

[1715089140]

1715089140

[bible_pay]

1) On using cli to enter headlesspassword, and having it switch back, I believe it takes about 3 minutes.  Please let me know if it didn't eventually switch?  If it didn't I can take a look at that switching time.  It might have taken one whole block to switch because the miner had a valid ABN for that block.

2) On the received stale block, yes, I am aware of that one, but it should be very little computer time - IE like when the machine is just getting started with mining, or switching over etc.  It usually only happens when the pool is having trouble supplying you with an abn and it delays for a few seconds.  Let me know if you see this happening more than .01% of the time.

Thanks. So I tried again and just discovered, that my wallet crashed. The debug.log says the following:

Code:

2019-07-14 14:30:54 mncon thread start
2019-07-14 14:30:54 msghand thread start
2019-07-14 14:30:54 BibleMiner -- started thread 0.000000 
2019-07-14 14:30:54 BibleMiner -- started thread 1.000000 
2019-07-14 14:30:55 BibleMiner -- started thread 2.000000 
2019-07-14 14:30:55 BibleMiner -- started thread 3.000000 
2019-07-14 14:30:55 BibleMiner -- started thread 4.000000 
2019-07-14 14:30:55 BibleMiner -- started thread 5.000000 
2019-07-14 14:30:55 BibleMiner -- started thread 6.000000 
2019-07-14 14:30:55 BibleMiner -- started thread 7.000000 
2019-07-14 14:30:55  ** Started 8.000000 BibleMiner threads. ** 

2019-07-14 14:30:55 init message: Done loading
2019-07-14 14:30:55 GUI: Platform customization: "windows"
2019-07-14 14:30:55 GUI: PaymentServer::LoadRootCAs: Loaded  45  root certificates
2019-07-14 14:31:05 P2P peers available. Skipped DNS seeding.
2019-07-14 14:31:05 dnsseed thread exit
2019-07-14 14:31:31 CMasternodeSync::SwitchToNextAsset -- Completed MASTERNODE_SYNC_WAITING in 37s
2019-07-14 14:31:31 CMasternodeSync::SwitchToNextAsset -- Starting MASTERNODE_SYNC_LIST
2019-07-14 14:32:07 CMasternodeSync::SwitchToNextAsset -- Completed MASTERNODE_SYNC_LIST in 36s
2019-07-14 14:32:07 CMasternodeSync::SwitchToNextAsset -- Starting MASTERNODE_SYNC_MNW
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: 113aca603335c10791ab9b2a8ac7a4122e2fc2be05dd64d2e151f01dfc0e06e0-0
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: 4a09dfd51d8e6e47037b0dd5d39566aca0ce7c6b0c81709372a9c0342a5b5a38-1
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: 4f330f92e3a70151858dc1fa357554da24a3f4340681691dca21764e5a1af35c-0
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: 020e4ee1236441048c591f7530edf5d1abce894c7214a2dd9f19700fcd3ac9ff-0
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: dca42ac3a2dfa5f591fcbb78f645c589b4ef8f2d8e1bbaeb4cc8b8817094326e-1
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: dd17f2a0276b9fe9b840535b276ac1afef2a65ecc015aea486bd27024bb836a7-1
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: b41c94da60464af65ab40bf6d02d34f6973e802c4cc51246167fa778948ba830-1
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: a870ad7760c31d82cc63e886e2dd2550e86e9f61ff1a27376a91bad210e88eb2-1
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: 6a71575dd5a1630c6f057316af0e55dc3c75f86e0003182748111417752834ec-1
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: 2e7a6a1743e4fd304cc36d0e7c43e1fe7a5ba5c4c051349796b16185f65f854b-1
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: c7b366502f3761dd2317eb515c8d9efd79fa414597852c468d8e23d26c16fc54-1
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: d4553a544d1e44c2b91da43a894033bbd2689b195ab228c97928e9bbf1ec9aa3-1
2019-07-14 14:32:14 CMasternodeMan::AskForMN -- Asking peer 207.246.75.36:0 for missing masternode entry for the first time: 4c2be1fa9e090b5e8a5ff5dcc1374991c954c0edb136db1a4ae9e1c227242b31-1
2019-07-14 14:32:19 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: 113aca603335c10791ab9b2a8ac7a4122e2fc2be05dd64d2e151f01dfc0e06e0-0
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: 4a09dfd51d8e6e47037b0dd5d39566aca0ce7c6b0c81709372a9c0342a5b5a38-1
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: 4f330f92e3a70151858dc1fa357554da24a3f4340681691dca21764e5a1af35c-0
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: 020e4ee1236441048c591f7530edf5d1abce894c7214a2dd9f19700fcd3ac9ff-0
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: dca42ac3a2dfa5f591fcbb78f645c589b4ef8f2d8e1bbaeb4cc8b8817094326e-1
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: dd17f2a0276b9fe9b840535b276ac1afef2a65ecc015aea486bd27024bb836a7-1
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: b41c94da60464af65ab40bf6d02d34f6973e802c4cc51246167fa778948ba830-1
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: a870ad7760c31d82cc63e886e2dd2550e86e9f61ff1a27376a91bad210e88eb2-1
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: 6a71575dd5a1630c6f057316af0e55dc3c75f86e0003182748111417752834ec-1
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: 2e7a6a1743e4fd304cc36d0e7c43e1fe7a5ba5c4c051349796b16185f65f854b-1
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: c7b366502f3761dd2317eb515c8d9efd79fa414597852c468d8e23d26c16fc54-1
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: d4553a544d1e44c2b91da43a894033bbd2689b195ab228c97928e9bbf1ec9aa3-1
2019-07-14 14:32:20 CMasternodeMan::AskForMN -- Asking new peer 45.63.77.194:0 for missing masternode entry: 4c2be1fa9e090b5e8a5ff5dcc1374991c954c0edb136db1a4ae9e1c227242b31-1
2019-07-14 14:32:26 CMasternodeMan::AskForMN -- Asking new peer 95.216.205.238:0 for missing masternode entry: c7b366502f3761dd2317eb515c8d9efd79fa414597852c468d8e23d26c16fc54-1
2019-07-14 14:32:43 CMasternodeSync::SwitchToNextAsset -- Completed MASTERNODE_SYNC_MNW in 36s
2019-07-14 14:32:43 CMasternodeSync::SwitchToNextAsset -- Starting MASTERNODE_SYNC_GOVERNANCE
2019-07-14 14:32:56 MNGOVERNANCEOBJECT -- Governance object is invalid - Failed to find Masternode UTXO, missing masternode=c490450211be2cd1ed8bcdaab45bbba83e329b3b364798622fde42ddcec29b87-1

2019-07-14 14:32:56 Misbehaving: dns1.biblepay.org peer=1 (0 -> 1)
2019-07-14 14:32:56 MNGOVERNANCEOBJECT -- Governance object is invalid - Failed to find Masternode UTXO, missing masternode=3e2365737715e3968dcfbc2cd47529705ef2e33b1413902a6ae0f813a88379b3-1

2019-07-14 14:32:56 Misbehaving: dns1.biblepay.org peer=1 (1 -> 2)
2019-07-14 14:32:56 MNGOVERNANCEOBJECT -- Governance object is invalid - Failed to find Masternode UTXO, missing masternode=3e2365737715e3968dcfbc2cd47529705ef2e33b1413902a6ae0f813a88379b3-1

2019-07-14 14:32:56 Misbehaving: dns1.biblepay.org peer=1 (2 -> 3)
2019-07-14 14:33:19 CMasternodeSync::SwitchToNextAsset -- Completed MASTERNODE_SYNC_GOVERNANCE in 36s
2019-07-14 14:33:19 CMasternodeSync::SwitchToNextAsset -- Sync has finished
2019-07-14 14:40:17 UpdateTip: new best=507c5a2c6b32b31671c03256d1966bd3a82fe67fc7a009b0c7a7c0daaf34197e height=131671 version=0x2000000c log2_work=59.51026570 tx=1093486 date='2019-07-14 14:39:34' progress=1.000000 cache=0.0MiB(0txo)
2019-07-14 14:40:17 {PNB}: ACC  
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131672, block.nbits 469813929.000000, next work 469835151.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131672, block.nbits 469813929.000000, next work 469835151.000000 (code 16)
2019-07-14 14:40:28 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131672, block.nbits 469813929.000000, next work 469835151.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131672, block.nbits 469813929.000000, next work 469835151.000000 (code 16)
2019-07-14 14:40:28 ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131672, block.nbits 469813929.000000, next work 469835151.000000 (code 16)
2019-07-14 14:40:29 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131672, block.nbits 469813929.000000, next work 469835151.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131672, block.nbits 469813929.000000, next work 469835151.000000 (code 16)
2019-07-14 14:45:14 UpdateTip: new best=8c954bcdeaa8d96b42b5bfff1fe3cde064c9f8b1255cf27488a6112babb5773b height=131672 version=0x2000000c log2_work=59.51026743 tx=1093488 date='2019-07-14 14:44:54' progress=1.000000 cache=0.0MiB(0txo)
2019-07-14 14:45:14 {PNB}: ACC  
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000 (code 16)
2019-07-14 14:45:33 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000 (code 16)
2019-07-14 14:45:33 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000 (code 16)
2019-07-14 14:45:34 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000 (code 16)
2019-07-14 14:45:34 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000 (code 16)
2019-07-14 14:45:34 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000 (code 16)
2019-07-14 14:45:34 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000 (code 16)
2019-07-14 14:45:35 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131673, block.nbits 469835151.000000, next work 469829560.000000 (code 16)
2019-07-14 14:50:49 UpdateTip: new best=631b278232c5a2efe1893b9920db1b7c9e536bd3fdd6c596f47639488c8f607a height=131673 version=0x2000000c log2_work=59.51026931 tx=1093491 date='2019-07-14 14:50:48' progress=1.000000 cache=0.0MiB(0txo)
2019-07-14 14:50:49 {PNB}: ACC  
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000 (code 16)
2019-07-14 14:51:39 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000 (code 16)
2019-07-14 14:51:39 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000 (code 16)
2019-07-14 14:51:40 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000 (code 16)
2019-07-14 14:51:40 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000 (code 16)
2019-07-14 14:51:40 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000 (code 16)
2019-07-14 14:51:40 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000 (code 16)
2019-07-14 14:51:41 
ContextualCheckBlockHeader::FAILED incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 131674, block.nbits 469829560.000000, next work 469834125.000000 (code 16)

Could this be correlated to the dual worker id?

(that happened before I even unlocked the wallet again)

Did it silently exit or was there an exception on the screen?  The screen exception is probably the most helpful in this case.

Is this the latest 64 bit version from yesterday or the day before (1441), and what is the 'version' from 'exec getabnweight'?
Log is not revealing.

Also, I still need to know if the "old crash" (pre ABN) that you experienced on windows 10 went away in this new version - IE did it just crash once this time and its been working and stable and solved?

[Gilligan_M]

Afternoon, I've had two silent crashes on win 10, one occuring about 6am EST, and another around 2:30pm EST.

[Borgholio]

For me it seems that the wallet prefers the funded ABN instead of the unfunded.  Exec getabnweight shows I have over 400k but it still goes for the funded worker instead.  Also in a maybe-related note, when I disabled the funded ABN worker in my config file last night, it seems I stopped mining about 4 hours ago even though I have enough ABN.

As an update, I'm mining normally again.  Before I had the following error when I ran getmininginfo:

"gsc_errors": "low abn weight 0",

That error has since vanished, so the gsc could somehow have been interfering with my ABN.  Although the whole time I was getting this notice so I thought it was ok:

"abninfo": "ABN: OK; ABN: OK; ABN: OK; ABN: OK; ",

Exec getabnweight was showing this:


{
  "Command": "getabnweight",
  "version": 2.4,
  "weight": 492855.5429745371,
  "total_required": 237881
}

[bible_pay]

Afternoon, I've had two silent crashes on win 10, one occuring about 6am EST, and another around 2:30pm EST.

Does this mean in your case the 1.4.4.1 version didnt do anything for windows 10 stability, and you are just as unstable as you were before we started adding ABNs?

Also, did running with litemode=1 change anything?

Also, what exec getabnweight version do you show? (It should be 2.x)?

[bible_pay]

windows 10(64bit) wallet 1.4.4.1(h)    cant connet to the pool..   I dont have problem connecting to the pool on windows 7 (64bit)

addnode=explorer.biblepay.org

pool=http://pool.biblepay.org

poolport=80

workerid=KMIS    *note (Funded worker)

genproclimit=60

minersleep=0

gen=1

----------------------------

"blocks": 131417,
  "currentblocksize": 2484,
  "currentblocktx": 2,
  "difficulty": 3493.889791328252,
  "errors": "",
  "pooledtx": 2,
  "chain": "main",
  "genproclimit": 60,
  "networkhashps": 454494.8052647252,
  "hashps": 0,
  "minerstarttime": "07-13-2019 09:25:23",
  "hashcounter": 0,
  "pooledtx": 2,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "abninfo": "Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti

Paste the full output of getnining info. Looks to me like it could not find your miner name and reverted you to solo mining or your use is not listed as funded. So grab a snapshot of your worker list also. That might be setup wromg

Yes, and I see a lot of windows10 users appear to not edit the correct biblepay.conf file.

Please navigate to:
%appdata%\biblepayevolution

Create the biblepay.conf there.  Then look at it in DOS, and ensure its called "biblepay.conf" not "biblepay.conf.conf.txt" etc.

Happy mining!

im sure im on the right biblepay.conf... also looked it at DOS, it doest NOT have the .TXT extention.

I see the problem; please change pool=http to pool=https://  (Evo only supports HTTPS).
Remove poolport also.

already replaced http to https and omitted poolport. same im on solo mining. windows 10 64bit...  win7 64bit no problem

Then please try 'genproclimit=9' in your config file, and restart and confirm your getmininginfo shows 9 for genproclimit?

yes my genproclimit became 9 in getmininginfo.  but poolmining is still false.

Ok good, at least we know the biblepay.conf is the exact and correct one.

Could you try this:

First, delete the contents of your biblepay.conf in notepad. 
Then re-type all of it with one <ENTER> between each row.

Then re-save it and try again.

If it does not connect to the pool, please paste the contents here.

[dave_bbp]

Did it silently exit or was there an exception on the screen?  The screen exception is probably the most helpful in this case.

Is this the latest 64 bit version from yesterday or the day before (1441), and what is the 'version' from 'exec getabnweight'?
Log is not revealing.

Also, I still need to know if the "old crash" (pre ABN) that you experienced on windows 10 went away in this new version - IE did it just crash once this time and its been working and stable and solved?

Nope, just silently exiting. getabnweight shows version 2.4 (client is latest from webpage). Some time ago it exited again, but log isn't really helpful again.

I think I'll now go back to Win7 compatibility mode and leaving the second workerid commented out, let's see if it's stable over night.

[Gilligan_M]

Afternoon, I've had two silent crashes on win 10, one occuring about 6am EST, and another around 2:30pm EST.

Does this mean in your case the 1.4.4.1 version didnt do anything for windows 10 stability, and you are just as unstable as you were before we started adding ABNs?

Also, did running with litemode=1 change anything?

Also, what exec getabnweight version do you show? (It should be 2.x)?

15:31:54

exec getabnweight 125000 1


15:31:54

{
  "Command": "getabnweight",
  "version": 2.2,
  "weight": 880160.7734490741,
  "total_required": 395461,
  "coin_age_data_pre_select": "1000.0000(2.05)=[2046.12] depth=434,  <ROW>1270.5400(2.09)=[2651.10] depth=443,  <ROW>192442.9022(2.09)=[401718.22] depth=443,  <ROW>",
  "weight 125000.00": 406415.4386111111,
  "total_required 125000.00": 194713
}


15:32:01

getmininginfo


15:32:01

{
  "blocks": 131714,
  "currentblocksize": 1855,
  "currentblocktx": 1,
  "difficulty": 2898.175787728027,
  "errors": "",
  "pooledtx": 0,
  "chain": "main",
  "genproclimit": 7,
  "networkhashps": 448849.7124697737,
  "hashps": 126001.257634149,
  "minerstarttime": "07-14-2019 18:41:58",
  "hashcounter": 378314114,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; ",
  "poolinfo2": "Submitting Solution 07-14-2019 19:31:10; Submitting Solution 07-14-2019 19:31:09; Submitting Solution 07-14-2019 19:31:09; Submitting Solution 07-14-2019 19:31:09; ",
  "poolinfo3": "",
  "abninfo": "ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ",
  "gsc_errors": "",
  "poolmining": true,
  "pool_url": "https://pool.biblepay.org",
  "required_abn_weight": 125000
}


ABN appears to be fine, on the debug.log it was similar to the ones that I have posted to you before as well.

At first I thought it was because I pushed my theadlimit up to 8 from 7, utilizing 100% of my CPU, but it occured again when I was only running 7 threads.


I have not tried litemode yet, I will give it a go now (restarting miner.)

quick edit: I'd have to say the miner is 90% more stable than what it was initially. It ran for a day and a half before the early morning crash.

another edit: I switched on litemode, (litemode=1 in biblepay.conf) but I had to RPC the miner to start mining (setgenerate true) after unlocking my encrypted wallet. (It was giving me this error even after unlocking the wallet)


15:38:18

getmininginfo


15:38:18

{
  "blocks": 131716,
  "currentblocksize": 1753,
  "currentblocktx": 1,
  "difficulty": 3169.410964597423,
  "errors": "",
  "pooledtx": 1,
  "chain": "main",
  "genproclimit": 7,
  "networkhashps": 446194.0693028863,
  "hashps": 0,
  "minerstarttime": "07-14-2019 19:37:43",
  "hashcounter": 0,
  "pooledtx": 1,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; ",
  "poolinfo2": "RM_07-14-2019 19:37:43; RMC_07-14-2019 19:37:43; RMC_07-14-2019 19:37:44; RMC_07-14-2019 19:37:44; RMC_07-14-2019 19:37:44; RMC_07-14-2019 19:37:43; RMC_07-14-2019 19:37:43; ",
  "poolinfo3": "",
  "abninfo": "Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; ",
  "gsc_errors": "low abn weight 0",
  "poolmining": true,
  "pool_url": "https://pool.biblepay.org",
  "required_abn_weight": 125000
}

[bbptoshi]

Thanks.  I did the 1 click sanctuary script and got version 1.4.3.3.  What would I do in this case?

This means something went wrong when replacing older binaries, as the current published version is 1.4.3.9.
Try to stop daemon manually then, download latest script version and then run

./masternode-setup.sh -u -n

This should run an unattended update.

Thanks MIP.  Sorry, I meant originally I did that and got 1.4.3.3.  I am simply running your script again now to upgrade.  Thanks!

edit: It worked perfectly, and even auto-started.  Thanks!

[bible_pay]

Did it silently exit or was there an exception on the screen?  The screen exception is probably the most helpful in this case.

Is this the latest 64 bit version from yesterday or the day before (1441), and what is the 'version' from 'exec getabnweight'?
Log is not revealing.

Also, I still need to know if the "old crash" (pre ABN) that you experienced on windows 10 went away in this new version - IE did it just crash once this time and its been working and stable and solved?

Nope, just silently exiting. getabnweight shows version 2.4 (client is latest from webpage). Some time ago it exited again, but log isn't really helpful again.

I think I'll now go back to Win7 compatibility mode and leaving the second workerid commented out, let's see if it's stable over night.

Ok, and on win7 compatibility mode, is that actually keeping it from crashing?  That would be a huge clue for us if it is. 

I might have to go out and buy or build a windows10 box.

[bible_pay]

Afternoon, I've had two silent crashes on win 10, one occuring about 6am EST, and another around 2:30pm EST.

Does this mean in your case the 1.4.4.1 version didnt do anything for windows 10 stability, and you are just as unstable as you were before we started adding ABNs?

Also, did running with litemode=1 change anything?

Also, what exec getabnweight version do you show? (It should be 2.x)?

15:31:54

exec getabnweight 125000 1


15:31:54

{
  
  "total_required 125000.00": 194713
}


15:32:01

getmininginfo


15:32:01


Code:

{
  
  "abninfo": "ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ",
  "gsc_errors": "",
  "poolmining": true,
  "pool_url": "https://pool.biblepay.org",
  "required_abn_weight": 125000
}

ABN appears to be fine, on the debug.log it was similar to the ones that I have posted to you before as well.

At first I thought it was because I pushed my theadlimit up to 8 from 7, utilizing 100% of my CPU, but it occured again when I was only running 7 threads.


I have not tried litemode yet, I will give it a go now (restarting miner.)

quick edit: I'd have to say the miner is 90% more stable than what it was initially. It ran for a day and a half before the early morning crash.

another edit: I switched on litemode, (litemode=1 in biblepay.conf) but I had to RPC the miner to start mining (setgenerate true) after unlocking my encrypted wallet. (It was giving me this error even after unlocking the wallet)


15:38:18

getmininginfo


15:38:18

{
 
  "poolinfo1": "BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; ",
  "poolinfo2": "RM_07-14-2019 19:37:43; RMC_07-14-2019 19:37:43; RMC_07-14-2019 19:37:44; RMC_07-14-2019 19:37:44; RMC_07-14-2019 19:37:44; RMC_07-14-2019 19:37:43; RMC_07-14-2019 19:37:43; ",
  "poolinfo3": "",
  "abninfo": "Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; Unable to Create ABN: Sorry, the wallet must be unlocked to create an anti-botnet transaction.; ",
  "gsc_errors": "low abn weight 0",
  "poolmining": true,
  "pool_url": "https://pool.biblepay.org",
  "required_abn_weight": 125000
}

"ABN appears to be fine, on the debug.log it was similar to the ones that I have posted to you before as well."

->  I believe most of our ABN fringe case issues are solved as Ive stopped hearing complaints on that - and JSheets has been testing that with me via email- and we are down to the final problem that him and Borg are having - the wallet uses the internal ABN, switches to Funded when it needs to and never switches back - I just debugged that and found the bug - re-releasing a new release for that issue now.


At first I thought it was because I pushed my theadlimit up to 8 from 7, utilizing 100% of my CPU, but it occured again when I was only running 7 threads.
I have not tried litemode yet, I will give it a go now (restarting miner.)
quick edit: I'd have to say the miner is 90% more stable than what it was initially. It ran for a day and a half before the early morning crash.

->  OK, this is good to know the stability increased by 90% as of this weeks releases.  Because we are using a new TestBlockValidity routine, and I was wondering if that helped stability on Windows10.  Let me try to hone in on that now,  for this next release, we will try applying this change a little further and let me know if stability increases on Win10 after this next release.

another edit: I switched on litemode, (litemode=1 in biblepay.conf) but I had to RPC the miner to start mining (setgenerate true) after unlocking my encrypted wallet. (It was giving me this error even after unlocking the wallet)

->  Regarding this unlock error message, this should only happen when the wallet cold boots, but if you give it a few minutes of mining, the errors clear and it adjusts (to a locked or non locked wallet), including - the dual-mining feature - it takes a few minutes for errors to clear, etc.

[Gilligan_M]

If there was something I could be curious about, it may be ABN randomly eaten out of my wallet (pool confirms that I didn't have a block found recently) as my weight went from 800k to 400k (not a mining issue, but just curious as to where it went) Is it a part of ABN funding for the funded miners?

[bible_pay]

If there was something I could be curious about, it may be ABN randomly eaten out of my wallet (pool confirms that I didn't have a block found recently) as my weight went from 800k to 400k (not a mining issue, but just curious as to where it went) Is it a part of ABN funding for the funded miners?

When you pool mine, a pool miner could actually use your ABN to solve their block.  (So it wouldnt be that you solved the pool block).

The only thing I can suggest is if you ask us to write a Spent ABN report, then you could see where they were used.  Do you want us to write that?

[Gilligan_M]

If there was something I could be curious about, it may be ABN randomly eaten out of my wallet (pool confirms that I didn't have a block found recently) as my weight went from 800k to 400k (not a mining issue, but just curious as to where it went) Is it a part of ABN funding for the funded miners?

When you pool mine, a pool miner could actually use your ABN to solve their block.  (So it wouldnt be that you solved the pool block).

The only thing I can suggest is if you ask us to write a Spent ABN report, then you could see where they were used.  Do you want us to write that?

Sure, could it be emailed? Also, it's for the sake of curiosity so don't let it impede with any important matters.

[bible_pay]

If there was something I could be curious about, it may be ABN randomly eaten out of my wallet (pool confirms that I didn't have a block found recently) as my weight went from 800k to 400k (not a mining issue, but just curious as to where it went) Is it a part of ABN funding for the funded miners?

When you pool mine, a pool miner could actually use your ABN to solve their block.  (So it wouldnt be that you solved the pool block).

The only thing I can suggest is if you ask us to write a Spent ABN report, then you could see where they were used.  Do you want us to write that?

Sure, could it be emailed? Also, it's for the sake of curiosity so don't let it impede with any important matters.

I just realized we have a report in the wallet that shows sent GSC transmissions for one day (this shows donations, POG points, Healing points) and used coin age on GSC transmissions.

I just modified it to report for the last 7 days on both GSC transmissions and ABN hits.  Then you can see anything that consumes coin age, the height, the date and the txid.

You can also test the new version at the same time; please give us about 30 mins to release it.

I see for example today my ABN was used to solve block 131665 in the pool - but the solver was murof.core7.  What you can do is get the height from the 'exec sentgsc' report (when its released) and then compare it to the blocks history report in the pool.

[bible_pay]

If there was something I could be curious about, it may be ABN randomly eaten out of my wallet (pool confirms that I didn't have a block found recently) as my weight went from 800k to 400k (not a mining issue, but just curious as to where it went) Is it a part of ABN funding for the funded miners?

When you pool mine, a pool miner could actually use your ABN to solve their block.  (So it wouldnt be that you solved the pool block).

The only thing I can suggest is if you ask us to write a Spent ABN report, then you could see where they were used.  Do you want us to write that?

Sure, could it be emailed? Also, it's for the sake of curiosity so don't let it impede with any important matters.

I just realized we have a report in the wallet that shows sent GSC transmissions for one day (this shows donations, POG points, Healing points) and used coin age on GSC transmissions.

I just modified it to report for the last 7 days on both GSC transmissions and ABN hits.  Then you can see anything that consumes coin age, the height, the date and the txid.

You can also test the new version at the same time; please give us about 30 mins to release it.

I see for example today my ABN was used to solve block 131665 in the pool - but the solver was murof.core7.  What you can do is get the height from the 'exec sentgsc' report (when its released) and then compare it to the blocks history report in the pool.

OK, windows 1.4.4.2c is out there, please test it:

exec sentgsc

To see the last 7 days of GSCs & ABNs.

Also, please test the dual mining feature again.

Also please ensure no crash occurs in windows 10.

[Gilligan_M]

If there was something I could be curious about, it may be ABN randomly eaten out of my wallet (pool confirms that I didn't have a block found recently) as my weight went from 800k to 400k (not a mining issue, but just curious as to where it went) Is it a part of ABN funding for the funded miners?

When you pool mine, a pool miner could actually use your ABN to solve their block.  (So it wouldnt be that you solved the pool block).

The only thing I can suggest is if you ask us to write a Spent ABN report, then you could see where they were used.  Do you want us to write that?

Sure, could it be emailed? Also, it's for the sake of curiosity so don't let it impede with any important matters.

I just realized we have a report in the wallet that shows sent GSC transmissions for one day (this shows donations, POG points, Healing points) and used coin age on GSC transmissions.

I just modified it to report for the last 7 days on both GSC transmissions and ABN hits.  Then you can see anything that consumes coin age, the height, the date and the txid.

You can also test the new version at the same time; please give us about 30 mins to release it.

I see for example today my ABN was used to solve block 131665 in the pool - but the solver was murof.core7.  What you can do is get the height from the 'exec sentgsc' report (when its released) and then compare it to the blocks history report in the pool.

OK, windows 1.4.4.2c is out there, please test it:

exec sentgsc

To see the last 7 days of GSCs & ABNs.

Also, please test the dual mining feature again.

Also please ensure no crash occurs in windows 10.

Updating to 1.4.4.2c now, my miner did experience another crash even in litemode.

Will let you know how it goes with the new release.

[Borgholio]

BBP wallet download is showing a size of only 23kb for me.

[bible_pay]

BBP wallet download is showing a size of only 23kb for me.

Please try now  .

[Mart1250]

Maybe this is a known issue, but i get a runtime error when opening the leaderboard.

"This application has requested  the Runtime to terminate  it in an unusual  way. Please contact the application's support team for more information."

Then biblepay crashes.


Mart