BiblePay - New Coin Launch - Official Thread

[SquidConqueror]

You are more than welcome.  I was hoping it would help...let me know if any other info on my end can assist.

[bible_pay]

Ok, things are looking better than they appear behind the scenes... From the pool it appears that there is a huge disparity between the big dogs and the small miners, but this appears to be a farce... Im doing some more checking before I post an update as to why this is occurring.  It appears to be RAID related.

Also, the errors in the debug: I believe a workaround exists.  More checking required.

Ill be back in 15 minutes.

[616westwarmoth]

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.

[seasonw]

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  

[SquidConqueror]

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!

[seasonw]

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 

[bible_pay]

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.

[bible_pay]

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  

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]

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.

[seasonw]

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]

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.

[inblue]

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."

[bitcoinsrule01]

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]

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]

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]

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.

[inblue]

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]

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:

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:

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.

[oliwer21]

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

[Shoko943]

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.