BBP wallet download is showing a size of only 23kb for me.
Please try now  . |
|
|
|
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. |
|
|
|
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. |
|
|
|
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? |
|
|
|
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  {
"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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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)? |
|
|
|
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: 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? |
|
|
|
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? |
|
|
|
I am still have some confusion about the abn and pog. Will the abn mining affect the coin age for pog and how?
Yes, ABN will affect POG, but only to the degree that you are actually solving blocks. If you had 256,000 total coin*age in the wallet, and you create an ABN for 128k, you still have 256K coin*age for the GSC transmission for POG (If you didnt solve a block). But if You did solve a block before the gsc transmission hits, the GSC txid creator would only have 128K to work with. If your GSC percent is set at .50, it would only be able to send a GSC of 64K coin age. You can also type 'exec createabn nnnnn' with the amount you specify (such as 128000), and it will show you which coins are allocated toward the ABN, and that would give you an idea which coins would be spent (if you solve a block) and not available for the next gsc. So basically: Pog & ABN share the same UTXO base. |
|
|
|
if i mined as funded worker, how many percent do i get compare to the one who funded me?
It's stated at the pool's "About" page under "Funded miner ABN fee (Funded Block Solve Ratio):" (currently 50 %). @Rob: just tested the dual mining feature in my Windows wallet by restarting my wallet with the 2 IDs in the config and simply not unlocking it for ABN. It correctly switched to funded, nice work there. Then I used the cli with headlesspassword to unlock the wallet, but it never switched back, although my abnweight was far above the current requirement. How long should it usually take to switch back? I waited maybe half an hour. The linux wallets don't have this feature yet, right? Because on those it didn't work. btw: watching getmininginfo today sometimes showed "received a stale block form the pool... Please wait". Any chance to avoid this? 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. |
|
|
|
if i mined as funded worker, how many percent do i get compare to the one who funded me?
Its a dynamic ratio (in the About page of the pool), currently at 50%. So the funded worker gets debited 50% of their hashpower, while the non-funded workers run at full hashpower. Then the rewards are paid based on HPS as usual (so the pool keeps zero of the ABN fees). |
|
|
|
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. |
|
|
|
I remember Dave_BBP and Gilligan had a Windows10 mining crash issue, please let us know if the last release solved the problem.
In case this answer was for me, I updated my post with more info just now. And yes, Im in windows 10. Also, please check this out, and see Moving the Wallet section: https://wiki.biblepay.org/Evolution_UpgradeSomehow the remote console is stucked, and rejecting any connection that I try, so I won't have access till Monday. However, I assure you that I have followed the steps and that I am running evolution. Even the icons for mined BBPs are different (they are like birds). I am probably not using the last version that you posted here, but the last but one (the last mandatory). Should I do a 'biblepay-qt --erasechain' first of all? I have seen in reddit someone with the same problem as me, but that, after running that command, his BBPs, including the old mined ones in the BOINC era, went to zero (which does not make sense). Ok, no problem and I wish you the best on recovering it all. Technically, the last mandatory 1.4.0.1, is still "good enough" to use and mine on, but we had a GSC issue a couple weeks ago where we recommended everyone upgrade, and to erase the chain (just in case a node tried to go on the lower proto version sanc side). So yes, if your node doesnt agree with https://chainz.cryptoid.info/bbp/ , please start with ./biblepay-qt -erasechain=1 And let it resync. Its a wives tail that you will lose all your BBP. That comes from the very true fact that if you start with 0 legal coins, and mine on a fork 100% of the time, all the BBP mined on the fork will be lost. But during a resync, all official main-chain BBP is still in the wallet. |
|
|
|
Evening Rob!
I'd reply via email but I've been tied on time recently,
as per your request, I tested out funded ABN and non-funded, both of which work without hassle for me. Personally, I found that by reducing my hardware print down to 1 PC (with the most hashpower) I have stopped finding so many blocks and have started building ABN much better, mining without issue or random program closure.
Great work on it all so far, when / how should we expect to see the payout from funded ABN mining, to those with ABN supplying?
Awesome! I "think" the crash is resolved that you had reported, so feel free to try the higher thread limit etc. To find the funded miner payout ration, please click About in the pool and look for Funded Miner ABN fee. Its on a sliding dynamic scale now. |
|
|
|
I remember Dave_BBP and Gilligan had a Windows10 mining crash issue, please let us know if the last release solved the problem.
Although I wasn't mining a lot over the last couple of days, when I did my wallet never crashed afair. (Still running the exe in Win7 compatibility mode btw, not sure if this has any use). Thanks, just to give you an update, while debugging the new funded ABN feature in 1.4.4.1, I did find a "sensitive area" that could have been the problem with windows 10 - and fixed it in 1.4.4.1h. So now if you would like to, you can try non lite mode and regular windows 10 mode to see if its resolved. |
|
|
|
Is it possible to use the funded ABN in the pool as a backup? Say if I have enough ABN for single block and I burn it, will I continue to mine with funded ABN? Thanks!
This feature is ready in beta. Does anyone have a windows machine available to test dual abn/non-abn mining? Ok, whoever wants to test this dual mining feature (this is where you set up two pool workerids, one without a funded ABN and one with a funded ABN, you enter both of these in your biblepay config file, and the wallet prefers to use your non-funded ABN as long as possible (until it runs out), then it switches to the funded ABN for a while). It does switch back to non-funded when your coin-age increases again. Setup Guide: https://wiki.biblepay.org/Quick_Start (Search for Dual Funded) Download the windows version from: www.biblepay.org(We need to know this feature works before building a release for the public). |
|
|
|
Is it possible to use the funded ABN in the pool as a backup? Say if I have enough ABN for single block and I burn it, will I continue to mine with funded ABN? Thanks!
This feature is ready in beta. Does anyone have a windows machine available to test dual abn/non-abn mining? |
|
|
|
I remember Dave_BBP and Gilligan had a Windows10 mining crash issue, please let us know if the last release solved the problem.
In case this answer was for me, I updated my post with more info just now. And yes, Im in windows 10. Also, please check this out, and see Moving the Wallet section: https://wiki.biblepay.org/Evolution_Upgrade |
|
|
|
|
Show Posts
