BiblePay - New Coin Launch - Official Thread - page 92.

seasonw

hero member

Activity: 714

Merit: 500

Quote from: inblue on September 11, 2017, 08:26:47 AM

Quote

"poolinfo3": "HEALTH_DOWN"

Even though I can access the pool in web browser normally. And the miner doesn't seem to be reverting to solo mining.

Same problem in my mining wallet too with message of "HEALTH_DOWN", I think the pool is having some issue too. I checked with the current block height, and the value is -1 Shocked

Is there any cli command to disable pool? I just don't want to restart the wallet daemon as I have to remove the debug.log.

inblue

full member

Activity: 462

Merit: 103

Quote

"poolinfo3": "HEALTH_DOWN"

Even though I can access the pool in web browser normally. And the miner doesn't seem to be reverting to solo mining.

Shoko943

newbie

Activity: 27

Merit: 0

Well, looks like I spoke too soon. After deleting the debug.log file and waiting for a little bit, it went back to the normal chain.

I'm guessing w/e is supposed to check the blocks was busy doing something else? =D. Maybe something to do with the spam in the debug.log file Tongue

EDIT: It's still doing it with the debug.log removed. I have a machine that is 10 blocks ahead Sad

Will see if it recovers by itself.

inblue

full member

Activity: 462

Merit: 103

Quote from: bitcoinsrule01 on September 11, 2017, 01:51:14 AM

Quote from: inblue on September 11, 2017, 01:47:43 AM

Quote from: bitcoinsrule01 on September 11, 2017, 01:38:46 AM

Quote from: bible_pay on September 10, 2017, 10:41:01 PM

No, this is with all switches off, the only way to do it is to delete debug.log while client is running.

EDIT: When its deleted while running, it will stop writing log data.

Is there a way to delete the debug.log on Windows when the file is being locked while the wallet is running?

Google "Windows unlocker". I don't know which program is free/best/easiest, but any one should do the trick.

Tried that but they all kill the process associated with the file. In this case the wallet itself. When you start up the wallet again it recreates the debug.log and starts filling it up again. Need to figure out a way to delete the file without killing the wallet process while deleting.

I found a way to open the wallet without writing to the debug.log file!

Just add this argument to the target of the biblepay-qt:

Quote

-printtoconsole
Send trace/debug info to console instead of debug.log file

But actually it will not send it to console either. And if you delete debug.log before starting the wallet, you will see that debug.log will not even be created at all.

So this seems to alleviate the disk I/O load for now.

emdes

full member

Activity: 159

Merit: 100

Quote from: oliwer21 on September 11, 2017, 05:14:29 AM

Pool hash has rised 2x?
Pph has droped to 0.00018
My ryzen 1700x droped from 400000 to 5000.

Sent you a PM

Shoko943

newbie

Activity: 27

Merit: 0

I'm not sure if anyone else is having the same issue but for some reasons my blockchain gets "corrupted?" after some time where it seems to start mining a fork or something else.

For example this is what I get on block 7084 on one of my machine:

{
  "hash": "8c730d6e8a1d4c45093e8d8d7d3b2f2dac98a664f85e56072abffa2050631fdf",
  "confirmations": 1,
  "size": 201,
  "height": 7084,
  "version": 536870913,
  "merkleroot": "ec5eef26f1c79a4dd530ffd1ac0bab9c46d019e3c15092ad801d91bb56faf82a",
  "tx": [
   "ec5eef26f1c79a4dd530ffd1ac0bab9c46d019e3c15092ad801d91bb56faf82a"
  ],
  "time": 1505120369,
  "mediantime": 1505118040,
  "hrtime": "09-11-2017 08:59:29",
  "nonce": 23832,
  "bits": "1d7c0cf8",
  "difficulty": 0.008061099778296693,
  "chainwork": "0000000000000000000000000000000000000000000000000000000c17a7b833",
  "subsidy": 20000,
  "blockversion": "1.0.2.9",
  "masternodereward": 0,
  "previousblockhash": "4f66df3d07cabf9ab95e1fc12cc16e7dc3dfc712c058dbef1dd5eefb0bf6fcb8",
  "verses": "Exo|5|7| Ye shall no more give the people straw to make brick, as heretofore: let them go and gather straw for themselves.\r\nIsa|33|22| For the LORD is our judge, the LORD is our lawgiver, the LORD is our king; he will save us.\r\nGen|17|5| Neither shall thy name any more be called Abram, but thy name shall be Abraham; for a father of many nations have I made thee.\r\nJos|10|7| So Joshua ascended from Gilgal, he, and all the people of war with him, and all the mighty men of valour.\r\nCo1|7|12| But to the rest speak I, not the Lord: If any brother hath a wife that believeth not, and she be pleased to dwell with him, let him not put her away.\r\nJer|22|7| And I will prepare destroyers against thee, every one with his weapons: and they shall cut down thy choice cedars, and cast them into the fire.\r\nIsa|13|14| And it shall be as the chased roe, and as a sheep that no man taketh up: they shall every man turn to his own people, and flee every one into his own land.\r\nCo1|15|52| In a moment, in the twinkling of an eye, at the last trump: for the trumpet shall sound, and the dead shall be raised incorruptible, and we shall be changed.\r\n84b8a4ebe96b209a9161e747d4dd8878fd6679a280d067ffc3be74aa69029d4d",
  "satisfiesbiblehash": "false",
  "satisfiesbiblehash_tx": "false",
  "biblehash": "000e9ef458f6d28ea18278d962fa6b6a493106fb695c7dbe333f30f74cbb2936",
  "biblehash_tx": "00308933a940e6ce6fdae882ce7b481668fd6aa7f018eaace3aa3d2d724cca45",
  "prayers": ""
}

What is really strange is that the "satisfiesbiblehash" would alternate between true and false depending on when I'm doing show block 7084. On the other hand, "atisfiesbiblehash_tx" would always stay false. I also have some blocks added to my wallet that aren't showing on my other machines. I'm guessing these are not from the main chain. The only way to fix that it is for me to redownload the whole blockchain.

I also noticed that I seem to find quite a lot of orphan blocks.

oliwer21

full member

Activity: 126

Merit: 100

Pool hash has rised 2x?
Pph has droped to 0.00018
My ryzen 1700x droped from 400000 to 5000.

inblue

full member

Activity: 462

Merit: 103

I have more findings:

Wallet often crashes on limited storage (probably because of debug.log), sometimes you can just restart it, but sometimes it won't start and shows this error:

Quote

Error: Failed to load masternode cache from mncache.dat

Then I just delete the mncache.dat file and it will start again. But in any case the wallet will be stuck at some previous block and sync 1 block per about 10 minutes, so it's very difficult to catch the top of the chain.

Maybe the crashes have something to do with the size of debug.log, as the file grows to about 10 GB before the wallet crashes, which is all of the available space on the disk used up.

The debug.log seems to grow at a speed which is correlated to the hashrate of the machine.

Also I noticed that in the /.biblepaycore/ folder, besides peers.dat, there are now these files, which are empty:

Quote

peers.dat.46fc
peers.dat.5250
peers.dat.5631
peers.dat.5b62
peers.dat.db55
peers.dat.e0cf
peers.dat.f92a

Next, the mining starts even though the wallet is not fully synced to the top of the chain.

Also, when I type "setgenerate false", CPU will still work for a few minutes and then it will stop, but on getmininginfo, it will still show poolmining as true, even though biblepay-generate shows false and hashps is 0.

inblue

full member

Activity: 462

Merit: 103

Quote from: seasonw on September 10, 2017, 09:40:40 PM

3. I restart wallet in my i7 windows machine, hashrate dropped from 160k to 5k, whereas my other windows machine remain same hashrate as previous (I did not restart the wallet). And yet, after restarting my i7 wallet, it is very laggy, some new calculation required more cpu power?

I think this may be true, because I have the same problem with my i7-2600k. It has a very low hashrate compared to the other machines proportionally as of before f7000. Maybe i7 is not efficient for the new algo?

inblue

full member

Activity: 462

Merit: 103

Quote from: inblue on September 11, 2017, 01:17:29 AM

getinfo

Code:

"version": 1000209,
"protocolversion": 70707,
"walletversion": 61000,
"wallet_fullversion": "1.0.2.9",
"balance": 0.00000000,
"privatesend_balance": 0.00000000,
"blocks": 7054,
"timeoffset": -1,
"connections": 3,
"proxy": "",
"difficulty": 0.006172447647924,
"testnet": false,
"keypoololdest": 1502470912,
"keypoolsize": 999,
"unlocked_until": 0,
"paytxfee": 0.00000000,
"relayfee": 0.00010000,
"errors": "Warning: We do not appear to fully agree with our peers! You may need to upgrade, or other nodes may need to upgrade."

Also, this instance is very slowly syncing one block at a time, is syncs one block per about 15 minutes and is still behind. Now it's on 7057 (7064 is the top). Also, timeoffset is now 0.

Take a look at getpeerinfo:

Code:

[
{
"id": 29,
"addr": "88.198.33.231:40000",
"addrlocal": "35.197.45.161:40018",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1505109024,
"lastrecv": 1505109024,
"bytessent": 2480,
"bytesrecv": 33689,
"conntime": 1505108303,
"timeoffset": 0,
"pingtime": 0.147173,
"minping": 0.14695,
"version": 70707,
"subver": "/Biblepay Core:1.0.2.9/",
"inbound": false,
"startingheight": 7061,
"banscore": 50,
"synced_headers": -1,
"synced_blocks": -1,
"inflight": [
],
"whitelisted": false
},
{
"id": 31,
"addr": "176.9.26.154:40000",
"addrlocal": "35.197.45.161:34138",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1505109081,
"lastrecv": 1505109022,
"bytessent": 3300,
"bytesrecv": 32468,
"conntime": 1505108542,
"timeoffset": 0,
"pingtime": 0.148628,
"minping": 0.14855,
"version": 70707,
"subver": "/Biblepay Core:1.0.2.9/",
"inbound": false,
"startingheight": 7045,
"banscore": 50,
"synced_headers": -1,
"synced_blocks": -1,
"inflight": [
],
"whitelisted": false
}
]

Notice the startingheight, synced_headers and synced_blocks on the above peers and how the startingheight is different on those two peers.

Another instance is stuck at block 7024 and it doesn't have the above error. Now look at the getpeerinfo from this instance:

Code:

[
{
"id": 5,
"addr": "104.207.130.51:40000",
"addrlocal": "35.196.242.180:49276",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1505109222,
"lastrecv": 1505109222,
"bytessent": 2486,
"bytesrecv": 32718,
"conntime": 1505107781,
"timeoffset": 0,
"pingtime": 0.09922499999999999,
"minping": 0.099138,
"version": 70707,
"subver": "/Biblepay Core:1.0.2.9/",
"inbound": false,
"startingheight": 7061,
"banscore": 0,
"synced_headers": 7063,
"synced_blocks": 7023,
"inflight": [
],
"whitelisted": false
},
{
"id": 6,
"addr": "88.99.245.124:40000",
"addrlocal": "35.196.242.180:36486",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1505109222,
"lastrecv": 1505109222,
"bytessent": 2672,
"bytesrecv": 33024,
"conntime": 1505107782,
"timeoffset": 0,
"pingtime": 0.102876,
"minping": 0.102876,
"version": 70707,
"subver": "/Biblepay Core:1.0.2.9/",
"inbound": false,
"startingheight": 7061,
"banscore": 0,
"synced_headers": 7063,
"synced_blocks": 7023,
"inflight": [
],
"whitelisted": false
},
{
"id": 7,
"addr": "97.99.69.33:40000",
"addrlocal": "35.196.242.180:51114",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1505109239,
"lastrecv": 1505109223,
"bytessent": 2706,
"bytesrecv": 32934,
"conntime": 1505107782,
"timeoffset": -1,
"pingtime": 0.046025,
"minping": 0.046025,
"version": 70707,
"subver": "/Biblepay Core:1.0.2.9/",
"inbound": false,
"startingheight": 7061,
"banscore": 50,
"synced_headers": 7063,
"synced_blocks": 7023,
"inflight": [
],
"whitelisted": false
},
{
"id": 8,
"addr": "176.36.154.195:40000",
"addrlocal": "35.196.242.180:42296",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1505109223,
"lastrecv": 1505109223,
"bytessent": 2672,
"bytesrecv": 33521,
"conntime": 1505107783,
"timeoffset": 8,
"pingtime": 0.128466,
"minping": 0.128308,
"version": 70707,
"subver": "/Biblepay Core:1.0.2.9/",
"inbound": false,
"startingheight": 7061,
"banscore": 0,
"synced_headers": 7063,
"synced_blocks": 7023,
"inflight": [
],
"whitelisted": false
},
{
"id": 9,
"addr": "94.130.23.112:40000",
"addrlocal": "35.196.242.180:33312",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1505109224,
"lastrecv": 1505109224,
"bytessent": 2748,
"bytesrecv": 33773,
"conntime": 1505107783,
"timeoffset": 0,
"pingtime": 0.103057,
"minping": 0.102777,
"version": 70707,
"subver": "/Biblepay Core:1.0.2.9/",
"inbound": false,
"startingheight": 7061,
"banscore": 0,
"synced_headers": 7063,
"synced_blocks": 7023,
"inflight": [
],
"whitelisted": false
},
{
"id": 10,
"addr": "109.169.86.14:40000",
"addrlocal": "35.196.242.180:44156",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1505109227,
"lastrecv": 1505109227,
"bytessent": 2562,
"bytesrecv": 32915,
"conntime": 1505107786,
"timeoffset": -7,
"pingtime": 0.091626,
"minping": 0.08931500000000001,
"version": 70707,
"subver": "/Biblepay Core:1.0.2.9/",
"inbound": false,
"startingheight": 7061,
"banscore": 0,
"synced_headers": 7063,
"synced_blocks": 7023,
"inflight": [
],
"whitelisted": false
},
{
"id": 11,
"addr": "108.61.204.234:40000",
"addrlocal": "35.196.242.180:47066",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1505109228,
"lastrecv": 1505109194,
"bytessent": 2828,
"bytesrecv": 32704,
"conntime": 1505107858,
"timeoffset": -1,
"pingtime": 0.049552,
"minping": 0.049078,
"version": 70707,
"subver": "/Biblepay Core:1.0.2.9/",
"inbound": false,
"startingheight": 7061,
"banscore": 0,
"synced_headers": 7063,
"synced_blocks": 7023,
"inflight": [
],
"whitelisted": false
},
{
"id": 12,
"addr": "144.76.79.109:40000",
"addrlocal": "35.196.242.180:43166",
"services": "0000000000000005",
"relaytxes": true,
"lastsend": 1505109228,
"lastrecv": 1505109229,
"bytessent": 2251,
"bytesrecv": 32386,
"conntime": 1505108388,
"timeoffset": 0,
"pingtime": 0.103012,
"minping": 0.102744,
"version": 70707,
"subver": "/Biblepay Core:1.0.2.9/",
"inbound": false,
"startingheight": 7061,
"banscore": 0,
"synced_headers": 7063,
"synced_blocks": 7023,
"inflight": [
],
"whitelisted": false
}
]

Now look again at the startingheight, synced_headers and synced_blocks.

Also, the old main node has banscore 50 lol.

bitcoinsrule01

newbie

Activity: 8

Merit: 0

Quote from: inblue on September 11, 2017, 01:47:43 AM

Quote from: bitcoinsrule01 on September 11, 2017, 01:38:46 AM

Quote from: bible_pay on September 10, 2017, 10:41:01 PM

No, this is with all switches off, the only way to do it is to delete debug.log while client is running.

EDIT: When its deleted while running, it will stop writing log data.

Is there a way to delete the debug.log on Windows when the file is being locked while the wallet is running?

Google "Windows unlocker". I don't know which program is free/best/easiest, but any one should do the trick.

Tried that but they all kill the process associated with the file. In this case the wallet itself. When you start up the wallet again it recreates the debug.log and starts filling it up again. Need to figure out a way to delete the file without killing the wallet process while deleting.

inblue

full member

Activity: 462

Merit: 103

Quote from: bitcoinsrule01 on September 11, 2017, 01:38:46 AM

Quote from: bible_pay on September 10, 2017, 10:41:01 PM

No, this is with all switches off, the only way to do it is to delete debug.log while client is running.

EDIT: When its deleted while running, it will stop writing log data.

Is there a way to delete the debug.log on Windows when the file is being locked while the wallet is running?

Google "Windows unlocker". I don't know which program is free/best/easiest, but any one should do the trick.

bitcoinsrule01

newbie

Activity: 8

Merit: 0

Quote from: bible_pay on September 10, 2017, 10:41:01 PM

Quote from: seasonw on September 10, 2017, 10:39:46 PM

Quote from: bible_pay on September 10, 2017, 10:10:57 PM

Regarding the hashrate: The problem is the big dogs have a RAID advantage because they have SSDs and multiple disks. The small guys have a single debug.log. We are spamming the log, and slowing the hashing down.

Any settings to disable writing data to debug.log?

No, this is with all switches off, the only way to do it is to delete debug.log while client is running.

EDIT: When its deleted while running, it will stop writing log data.

Is there a way to delete the debug.log on Windows when the file is being locked while the wallet is running?

inblue

full member

Activity: 462

Merit: 103

getinfo

Code:

"version": 1000209,
  "protocolversion": 70707,
  "walletversion": 61000,
  "wallet_fullversion": "1.0.2.9",
  "balance": 0.00000000,
  "privatesend_balance": 0.00000000,
  "blocks": 7054,
  "timeoffset": -1,
  "connections": 3,
  "proxy": "",
  "difficulty": 0.006172447647924,
  "testnet": false,
  "keypoololdest": 1502470912,
  "keypoolsize": 999,
  "unlocked_until": 0,
  "paytxfee": 0.00000000,
  "relayfee": 0.00010000,
  "errors": "Warning: We do not appear to fully agree with our peers! You may need to upgrade, or other nodes may need to upgrade."

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: seasonw on September 10, 2017, 10:39:46 PM

Quote from: bible_pay on September 10, 2017, 10:10:57 PM

Regarding the hashrate: The problem is the big dogs have a RAID advantage because they have SSDs and multiple disks. The small guys have a single debug.log. We are spamming the log, and slowing the hashing down.

Any settings to disable writing data to debug.log?

No, this is with all switches off, the only way to do it is to delete debug.log while client is running.

EDIT: When its deleted while running, it will stop writing log data.

seasonw

hero member

Activity: 714

Merit: 500

Quote from: bible_pay on September 10, 2017, 10:10:57 PM

Regarding the hashrate: The problem is the big dogs have a RAID advantage because they have SSDs and multiple disks. The small guys have a single debug.log. We are spamming the log, and slowing the hashing down.

Any settings to disable writing data to debug.log?

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

All-

F7000 had a hitch.
Sorry about that all.

Each piece of the problem has a temporary workaround, and most of this resolves itself at block 7256.

In the mean time, here is an update on each flaw and workaround between block 7000-7256:

1) Pool hashpersec2 disparity between big dogs and small miners: During the phase of 7000-7256, the client is spamming the debug.log in a very severe way. The big miners have multiple fast disk drives and RAID, so they are hashing faster because the drive is writing the errors in the log in parallel (in contrast to the small miners slow hard drive with serial errors).

To ensure full fairness in the pool, I switched the pool over to payment per share. HashesPerSec2 is now based on solved shares. The shares are now all equal weight (hence the reason the big dogs are solving so many). I changed the leaderboard to sort on hashespersec2 descending (to allow us to see the realized hashing).

SPAM Workaround: To work around the spam problem up to block 7256, you can manually delete your debug.log while the client is running.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: seasonw on September 10, 2017, 09:40:40 PM

1. After F7000, I noticed a lot of these message, what is this about?

2. And I have a machine in ubuntu stopped working after 7000, I restart it, error message said index database corrupted, I removed .biblepaycore and reload all database, but it stucked at 7022, same message as SquidConqueror did. Then I did a tricky solution which is to copy .biblepaycore from my other ubuntu machine, problem solved. But then my hashrate dropped from 400k to 40k, my other machine remain same hashrate as previous.

3. I restart wallet in my i7 windows machine, hashrate dropped from 160k to 5k, whereas my other windows machine remain same hashrate as previous (I did not restart the wallet). And yet, after restarting my i7 wallet, it is very laggy, some new calculation required more cpu power?

Thanks Wink

Regarding the Invalid solution, its only happening about 1 in 100 hits to the pool. Im going to be giving a technical reason soon, but the short answer is it should go away at block 7256.

Regarding index database corrupted, same problem, should be a short term problem until 7256. Ill explain in a minute.

Regarding the hashrate: The problem is the big dogs have a RAID advantage because they have SSDs and multiple disks. The small guys have a single debug.log. We are spamming the log, and slowing the hashing down.

More in a minute.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: SquidConqueror on September 10, 2017, 09:41:20 PM

Quote from: 616westwarmoth on September 10, 2017, 09:34:41 PM

Quote from: rorschach1 on September 10, 2017, 03:38:19 PM

Idea is not bad but how much billions circulating now? I afraid that soon this coin will be priced at very low than 1 satoshi

Not even a billion in circ, you want to see a coin with billions already, go to Linda. Started about the same time and WAAYYYY ahead coin wise but not in the 1 satoshi range yet. BBP probably never going to break out and be a $100 coin, but to think it'll drop below 1 sat is very pessimistic.

There are REAL WORLD uses for this coin! Those who are less fortunate than most are getting some well needed care. Most coins do not even have a purpose....this coin may never be $100...but it is worth that much and more to those it helps!

+1 For that. I wouldn't want anything to do with (us becoming) some slimy investment, and who needs another blockchain if it does not add any new value?

I personally feel we have to pull our own weight, and I think we should not stop IT engineering until we do come up with some novel permanent value add for crypto. One thing I learned in church today that I added to my pie in the sky list: The volunteer pastor has some kind of part time job where he consults with governments on trying to integrate God back into the government processes, he mentioned, he flies to various places that invite him for ideas - in politics and classrooms etc. I was thinking thats something we could potentially do with Biblepay, is consult with companies who want to add God into the process. I dont think we are anywhere near a dead end of $1, with God anything is possible.

seasonw

hero member

Activity: 714

Merit: 500

Quote from: 616westwarmoth on September 10, 2017, 09:34:41 PM

Quote from: rorschach1 on September 10, 2017, 03:38:19 PM

Idea is not bad but how much billions circulating now? I afraid that soon this coin will be priced at very low than 1 satoshi

Not even a billion in circ, you want to see a coin with billions already, go to Linda. Started about the same time and WAAYYYY ahead coin wise but not in the 1 satoshi range yet. BBP probably never going to break out and be a $100 coin, but to think it'll drop below 1 sat is very pessimistic.

rorschach1, you are way too pessimistic...

Check this out, total supply of biblepay comparing with some popular coins with total supply more than biblepay and yet most of them already billions in circulation. And their prices are great Grin

Topic: BiblePay - New Coin Launch - Official Thread - page 92. (Read 119833 times)