BiblePay - New Coin Launch - Official Thread

[inblue]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together. 

I started linux upgrades.  they will take at least an hour anyway .  thanks Bible_pay

Yeah, "make" takes around half an hour on high spec machines. Is there a way to only build changed files, like src/main.cpp and src/pow.cpp?

[maarekelets]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together. 

Do you know when the Windows version will hit the website to DL? The reason I ask is that Endpoint Antivirus (my workplace's choice for antivirus) has red flagged the 64 bit version's download link (not the file but the link) so I have to go through a bunch of fun phone gymnastics to get it downloaded and copied over here.

I will do a git pull for linux at 10AM and start the recompile, that should give some time.

[noob101]

What do you have against windows users LOL,  .
According to me there is not much difference between a Aisic miner, aGPU rig and a server running multiple CPUs. I am glad this algo support small miners.  I was really getting disgruntled with all the hardcore miners getting most of the coin. This is however besides the point.
I would like to mention for the record:
I have an Acer i3 1.7Ghz with 4GB ram.  I get about the same constant in amount of coins regardless of what happens, give or take a few here and there.  This is +- 1200 a day if I were to run 24 hours non stop. 
The change in algo did not affect me much.
I did not get many banned peer issues.
My wallet is stable.
I have no withdrawal from pool to wallet issues. 
I had the whole bad block error thing in my error log, but it did not affect my wallet or my miner.
I upgraded to 1.0.3.1 hassle free.
I am running the miner on 3 threads.
My cpu temp stays around and below 50 degrees.
I do not get any lag or interference from miner in the background while working on my laptop.

And I am very impressed with how the coin is managed.  Hat off to the dev.

 
 

[tiras]

BTW 5k coins of reward per block on pool and huge drop of hash is worth of mine for small miners...

@inblue what is your best cpu on witch you got such big hash?

Ahh... This is another topic I wanted to start, but I was too lazy. There are obviously some big changes in this new algo in ways I still don't quite understand. It seems that the algo actually favors mid-range and small miners, because stronger machines don't bring proportionally as much HPS2 (real HPS measured by pool). Now it's much better to have 10 small machines which have 8 threads each than to have 1 big machine which has 80 threads.

Here is a rough comparison of my miners:

blu1    = 16 cores, genproclimit 32, 64k HPS, 42k HPS2
blu2-3 = 24 cores, genproclimit 48, 64k HPS, 42k HPS2
blu4    = 40 cores, genproclimit 80, 55k HPS, 27k HPS2
blu5-9 =   2 cores, genproclimit   8, 17k HPS, 35k HPS2

First of all, why do blu2 and 3 have the same hashrate as blu1? In the previous algo they had about 530k while blu1 had about 350k, and these numbers are exactly proportionate to the number of cores (24 cores = 530k hps, 16 cores = 350k hps, divide them and you'll see, about 22k per core). Now both the 16 core one and the 24 core ones have the same hashrate, as if the CPU on the 24 core machines is not used to its fullest, but it is, it has 100% usage.

But the real mystery here is how in the world does a $20/mo shared VPS (blu5-9) outperform a $250/mo dedicated enterprise machine (blu4)? In the previous algo the high-spec machine was at the top of the leaderboard at around 830k hashrate and the cheap VPSs had around 70k each.

I second this analysis.  well done. 
 another thing to mention is that 1.0.3.1 linux outperfomed win version running on a higher end hardware.
 in my case ryzen7 with linux had x10 times hashrate compared to win.

[tiras]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together.  

I started linux upgrades.  they will take at least an hour anyway .  thanks Bible_pay

Yeah, "make" takes around half an hour on high spec machines. Is there a way to only build changed files, like src/main.cpp and src/pow.cpp?

lunux miners deserve some bounty for the troubles with babysitting 1.0.3.1  : )

[bible_pay]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together. 

I started linux upgrades.  they will take at least an hour anyway .  thanks Bible_pay

Yeah, "make" takes around half an hour on high spec machines. Is there a way to only build changed files, like src/main.cpp and src/pow.cpp?

On my debian box, I do partial non-clean builds, and all I do is run a script that does the git pull origin master, then I skip over to 'make' (dont configure or autogen), and it builds a lot faster.

[bible_pay]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together.  

I started linux upgrades.  they will take at least an hour anyway .  thanks Bible_pay

Yeah, "make" takes around half an hour on high spec machines. Is there a way to only build changed files, like src/main.cpp and src/pow.cpp?

lunux miners deserve some bounty for the troubles with babysitting 1.0.3.1  : )

At least linux users can make a script to upgrade easier than the windows users.
Its probably going to be necessary anyway if you want to run multiple masternodes.

[bible_pay]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together. 

Do you know when the Windows version will hit the website to DL? The reason I ask is that Endpoint Antivirus (my workplace's choice for antivirus) has red flagged the 64 bit version's download link (not the file but the link) so I have to go through a bunch of fun phone gymnastics to get it downloaded and copied over here.

I will do a git pull for linux at 10AM and start the recompile, that should give some time.

I think it will be ready in about 90 minutes, it looks like its halfway done compiling.

I see c-cex is still down for maintenance; hopefully they had a lot of unrelated work to do.  Probably reindexing the database.

[bible_pay]

I get it. Do you happen to have the info on how many Windows users there are, compared to the Linux users?

This is just a guess, since I dont have those figures, although that brings up a good point, that we should make an attempt to grab those figures for development purposes.

Based on my experience with other coins, believe it or not, its usually an 80% windows download rate, 20% linux (1% mac).
However, I believe with BiblePay, we have a handful of grass-root linux supporters who seem to run a high quantity of nodes (IE they seem to
 have excess money laying around for hobbies, and/or have some relationship to cloudmining).  We might be attracting people who deal with excess PC resources, being the only coin that hasnt been exploited by GPUs.

Anyway, Im going to guess that out of 750 users, 70% are still PC users, but I believe personally that if you went with node count, we would be along the lines of 1000 nodes with 50% being linux nodes...  So the linux count is probably skewed due to ROI and huge quantity per hobbyist.

(There are stories on the internet of some coins that tried to launch as linux-only, and they always died.)

[tiras]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together.  

I started linux upgrades.  they will take at least an hour anyway .  thanks Bible_pay

Yeah, "make" takes around half an hour on high spec machines. Is there a way to only build changed files, like src/main.cpp and src/pow.cpp?

lunux miners deserve some bounty for the troubles with babysitting 1.0.3.1  : )

At least linux users can make a script to upgrade easier than the windows users.
Its probably going to be necessary anyway if you want to run multiple masternodes.

I must say this project made me a linux user.  I used to play with *nix years ago just for fun .   so I have to do everything hard way .   learning bash scripting  is the next thing to have fun with

and running masternodes will be my next big goal .

[svirusxxx2]

vrs2.hostv.pl - node updated

Code:

vrs2 ~ $ ./biblepay/src/biblepay-cli getpeerinfo | grep subver | sort | uniq -c        
      1     "subver": "/Biblepay Core:1.0.2.2/",
     83     "subver": "/Biblepay Core:1.0.3.1/",
      6     "subver": "/Biblepay Core:1.0.3.2/",

[bible_pay]

Correct, exactly, you nailed it. Well, ideologically I guess it's not bad to favor the mid to small miners for high decentralization purposes, but I am still wondering from the technical side of things, is that a bug in the algo or something.

Alrighty a guess and some homework for you is all I can offer on this today:

So the old algorithm had an outer loop of 1000 X11 hashes and an inner loop of one biblepay hash, meaning that if you ran 80 threads on x11-bbp pre F7000, that distributed thread could conduct its hashing without the resources of the full node.  (Whenever the miner needs to access the resources of the full node, for example, asking it for AES/md5/chaining the KJV together) grabbing the pindex bestblockindex map, it is in a way locking the thread for a few milliseconds and grabbing its data and then continuing.  In the NEW world, in F7000, its hashing only one X11 hash (for the blockindex), yet 1000 BibleHashes of work being expended per loop.  So its no longer able to decentralize a thread with just a math problem (IE x11 solution), and come back and join the rest of the threads, instead, its doing a lot of biblehash->askfullnode->biblehash->askfullnode, etc.

So my guess is this: In f7000, there is a strong reliance on the full nodes availablility, and the thread itself can only do so much work before its waiting around for availablility of the data it needs (like a blockindex for example, from the map).  The reason the kernel cant allow two threads to read the same value simultaneously is that would cause a segfault error.  

So what I recommend is this: Find a way to run multiple copies of biblepay on one server, and do a side by side comparison of those specs with the sum of the hash of biblepay instances.  If the hash throughput is higher on the multiple copies, then we know that I said above is true and the only way to consolidate hardware to high power servers is then to run multiple instances per node.

On a side note if we find that to be the case then that is good- as you said earlier -part of the benefit of requiring the full node is to reward the decentralized full node environment (IE not the people with the biggest nodes) as part of the original vision is to not be greed based but to be service oriented.

[x5650]

Is there a new wallet out¿

[bible_pay]

Is there a new wallet out¿

The linux is checked in, but Im waiting on Win to compile.

Probably 30 more minutes, then Ill post a mandatory upgrade.

[x5650]

Is there a new wallet out¿

The linux is checked in, but Im waiting on Win to compile.

Probably 30 more minutes, then Ill post a mandatory upgrade.

Thanks, will be out for 1h so now i will turn pool mining off.

[inblue]

I get it. Do you happen to have the info on how many Windows users there are, compared to the Linux users?

This is just a guess, since I dont have those figures, although that brings up a good point, that we should make an attempt to grab those figures for development purposes.

Based on my experience with other coins, believe it or not, its usually an 80% windows download rate, 20% linux (1% mac).
However, I believe with BiblePay, we have a handful of grass-root linux supporters who seem to run a high quantity of nodes (IE they seem to
 have excess money laying around for hobbies, and/or have some relationship to cloudmining).  We might be attracting people who deal with excess PC resources, being the only coin that hasnt been exploited by GPUs.

Anyway, Im going to guess that out of 750 users, 70% are still PC users, but I believe personally that if you went with node count, we would be along the lines of 1000 nodes with 50% being linux nodes...  So the linux count is probably skewed due to ROI and huge quantity per hobbyist.

(There are stories on the internet of some coins that tried to launch as linux-only, and they always died.)

Very interesting analysis, thank you. I had the exact same thoughts about Linux hobbyists with money or a relationship to cloud mining or access to a lot of unused PCs, perhaps even in some organization.

Do you think there's a way to make the wallet detect OS version so that you could then run a report command just like with version numbers?

Correct, exactly, you nailed it. Well, ideologically I guess it's not bad to favor the mid to small miners for high decentralization purposes, but I am still wondering from the technical side of things, is that a bug in the algo or something.

Alrighty a guess and some homework for you is all I can offer on this today:

So the old algorithm had an outer loop of 1000 X11 hashes and an inner loop of one biblepay hash, meaning that if you ran 80 threads on x11-bbp pre F7000, that distributed thread could conduct its hashing without the resources of the full node.  (Whenever the miner needs to access the resources of the full node, for example, asking it for AES/md5/chaining the KJV together) grabbing the pindex bestblockindex map, it is in a way locking the thread for a few milliseconds and grabbing its data and then continuing.  In the NEW world, in F7000, its hashing only one X11 hash (for the blockindex), yet 1000 BibleHashes of work being expended per loop.  So its no longer able to decentralize a thread with just a math problem (IE x11 solution), and come back and join the rest of the threads, instead, its doing a lot of biblehash->askfullnode->biblehash->askfullnode, etc.

So my guess is this: In f7000, there is a strong reliance on the full nodes availablility, and the thread itself can only do so much work before its waiting around for availablility of the data it needs (like a blockindex for example, from the map).  The reason the kernel cant allow two threads to read the same value simultaneously is that would cause a segfault error. 

So what I recommend is this: Find a way to run multiple copies of biblepay on one server, and do a side by side comparison of those specs with the sum of the hash of biblepay instances.  If the hash throughput is higher on the multiple copies, then we know that I said above is true and the only way to consolidate hardware to high power servers is then to run multiple instances per node.

On a side note if we find that to be the case then that is good- as you said earlier -part of the benefit of requiring the full node is to reward the decentralized full node environment (IE not the people with the biggest nodes) as part of the original vision is to not be greed based but to be service oriented.

A bit more technical lingo than I am able to handle right now, but I got the gist of it. I have some errands to do now, but in the evening or tomorrow I will try to run two nodes on one machine and will report back with the results, to see if your theory is correct (I have a feeling it is).

[bible_pay]

Biblepay v1.0.3.2 - Mandatory Upgrade
https://www.biblepay.org
https://github.com/biblepay/biblepay

- Fix f7000 Low-Subsidy based on High-Diff calculation
- Fix Pool banning issue
- Fix Read Disk error

[616westwarmoth]

Correct, exactly, you nailed it. Well, ideologically I guess it's not bad to favor the mid to small miners for high decentralization purposes, but I am still wondering from the technical side of things, is that a bug in the algo or something.

Alrighty a guess and some homework for you is all I can offer on this today:

So the old algorithm had an outer loop of 1000 X11 hashes and an inner loop of one biblepay hash, meaning that if you ran 80 threads on x11-bbp pre F7000, that distributed thread could conduct its hashing without the resources of the full node.  (Whenever the miner needs to access the resources of the full node, for example, asking it for AES/md5/chaining the KJV together) grabbing the pindex bestblockindex map, it is in a way locking the thread for a few milliseconds and grabbing its data and then continuing.  In the NEW world, in F7000, its hashing only one X11 hash (for the blockindex), yet 1000 BibleHashes of work being expended per loop.  So its no longer able to decentralize a thread with just a math problem (IE x11 solution), and come back and join the rest of the threads, instead, its doing a lot of biblehash->askfullnode->biblehash->askfullnode, etc.

So my guess is this: In f7000, there is a strong reliance on the full nodes availablility, and the thread itself can only do so much work before its waiting around for availablility of the data it needs (like a blockindex for example, from the map).  The reason the kernel cant allow two threads to read the same value simultaneously is that would cause a segfault error.  

So what I recommend is this: Find a way to run multiple copies of biblepay on one server, and do a side by side comparison of those specs with the sum of the hash of biblepay instances.  If the hash throughput is higher on the multiple copies, then we know that I said above is true and the only way to consolidate hardware to high power servers is then to run multiple instances per node.

On a side note if we find that to be the case then that is good- as you said earlier -part of the benefit of requiring the full node is to reward the decentralized full node environment (IE not the people with the biggest nodes) as part of the original vision is to not be greed based but to be service oriented.

Well explained, like Blu I'll have to re-read it again to get a complete understanding.  But I would echo his request on versions, if there would be a way for the Core to report what OS was used, it would be very interesting to know and could lead to some improvements.  Thanks as always for your attention and willingness to work that keeps this coin moving forward.

[inblue]

Code:

************************
EXCEPTION: St13runtime_error
tinyformat: Not enough conversion specifiers in format string
biblepay in ProcessMessages()

2017-09-13 15:34:23 ProcessMessages(block, 191 bytes) FAILED peer=1
2017-09-13 15:34:23 89

************************

I got this error in 1.0.3.2 in debug.log, repeated many times, and it stopped syncing after that. The error started right after block 7099 has been synced.

[togoshigekata]

Code:

************************
EXCEPTION: St13runtime_error
tinyformat: Not enough conversion specifiers in format string
biblepay in ProcessMessages()

2017-09-13 15:34:23 ProcessMessages(block, 191 bytes) FAILED peer=1
2017-09-13 15:34:23 89

************************

I got this error in 1.0.3.2 in debug.log, repeated many times, and it stopped syncing after that. The error started right after block 7099 has been synced.

I am getting a similar error with Windows 32 bit v1.0.3.2 exe

Code:

2017-09-13 15:32:59 init message: Activating best chain...
2017-09-13 15:32:59 

************************
EXCEPTION: St13runtime_error       
tinyformat: Not enough conversion specifiers in format string       
C:\Program Files (x86)\BiblepayCore\biblepay-qt.exe in Runaway exception       

2017-09-13 15:33:02 CDBEnv::EnvShutdown: Error 22 shutting down database environment: Invalid argument
2017-09-13 15:34:21