BiblePay - New Coin Launch - Official Thread

[znffal]

account   to set Default Withdrawal Address
Then account--withdraw to your wallet address

Thanks, I will do that! When I go there my Default withdraw address is my username. I change that for my public key, right?

edit: Ok I did it, changed to my key and it worked perfectly.
Thanks

[1715546825]

1715546825

[1715546825]

1715546825

[1715546825]

1715546825

[1715546825]

1715546825

[oliwer21]

Yay, 1 day and my hps2 droped from 11k to 5-6k... ofc   NOTHING changed. Wallet hash still 19k.
Any idea why?

[PhaseshiftUK]

<snip>
Do you run win or linux?

Linux. I almost wonder if its not compiled correctly to take advantage of all of the processor features.

Did you compile with the "-march=native" flag?

No, do I need to do that?  I just followed the instructions on reddit, which looking back, might not be the best

You don't need to, but adding the -march=native flag to the compiler will turn on optimisations for the processor that you are compiling on.

[PhaseshiftUK]

How can I compile the biblepay src in a fast computer in Ubuntu and copy the compiled program to a slow computer and run? Which compile option should I use? Right now, I copied the compiled program and it says a lot of libraries are missing.

You should be able to run the executable on the slower machine (provided you didn't turn on any compile-time optimisations that are not compatible with that slower machine), however the executable does rely on a number of libraries.  At a guess:

libdb4.8-dev libdb4.8++-dev
(or the self-compiled DB4 option)

libboost-all-dev libssl-dev libevent-dev

libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev
(but only if you compiled with the GUI enabled).

[Ryan Dugan]

I have been mining on a 2600k i7 it is not so profitable but it is better then nothing since the pc stays on. I am glad to support the network though I really hope the price goes up it deserves better rewards and is rare much to rare to be at the current cost. Anyway nice coin been mining 24/7.

[sharpshot]

I find setting up the wallet and mining is easy with windows.  Didn't have any luck following the Linux instructions.  Hope that can be simplified soon.  Hope to see this coin doing well in the future.

[znffal]

Hi all,

I am brand new to biblepay and mining. I set up my laptop to mine on 3 of my 4 cores and managed to get 200 coins in 24 hours. I would like to try to run 3 miners on 3 cores (multiple instances) to see how that goes. I don't want to try this before double checking the steps are correct.
Are the steps below correct?

In a terminal type

Code:

$ cd ~
$ cp -r .biblepaycore/ .biblepaycore2/
$ cd /usr/local/bin
$ ./biblepayd -daemon
$ ./biblepayd -daemon -datadir=/home/myusername/.biblepaycore2

Then I add the below code to biblepay.conf in .biblepaycore2

Code:

rpcport=39001

Then run the following code (in the terminal, or in the biblepay wallet console?)

Code:

$ ./biblepayd -daemon -datadir=/home/inblue/.biblepaycore2 -listen=0

And so this should just start two wallet/miners, right?

Then in a terminal (or in biblepay wallet console?) type

Code:

./biblepay-cli -datadir=/home/inblue/.biblepaycore2 getmininginfo

Presumably I need to go into the config files and change the name of my miner for each one I set up.

Anything I have missed?

[bible_pay]

Actually now I'm pretty convinced that the issue is either with the pool or the miner or both.  Bible_pay says that every miner is mining on the same difficulty, that right there leads me to believe that the pool can't keep up with the shares submitted.  Of course there is no output to see so you can't tell how many shares you are submitting that are valid or invalid.  Then there are these 2 posts:

http://forum.biblepay.org/index.php?topic=17.0
http://forum.biblepay.org/index.php?topic=18.0

If multiple threads are hashing the same share that would explain why there is such a big difference between local and pool hashrate, and why multiple daemons work best.

Just to reiterate this again:
- All shares issued by the pool are the same difficulty
- HPS2 is supposed to be different than HPS
- HPS2 is based on how many shares you solved in the current round, while HPS is based on your CPU clock hashes per sec.
- The pool is not behind and is able to handle the load (I know because I wrote it, deployed it, and I monitor the performance counters)

You can see clearly that when viewing the leaderboard, the same machines are at the top- and we have a consistent list of users per hashpersec2 reported in the same places. (IE randomness is not a primary factor).

There are certain people here on this thread that are unhappy that lower end processors achieve a higher HPS than their proc.  That is a personal problem.
All the code is public domain, you are all free to download it from github and run variations of the miner on your bench if you think there is some inconsistency with your processor.

The KEY ISSUE that some people are not grasping with biblepay is this:

A high percentage of processor power in the biblehash algorithm is going to querying the node vector itself, not wasting CPU cycles on the hashing.  So if you want to look at this another way, you are being comepensated 60% for running a node, and the rest for the speed.  Im happy we ended up like this as it gives everyone a chance to jump in and receive some BBP.

My main concern is to ensure the algo does not get ported to an ASIC or a GPU.  Im busy over in our other forum deploying code to enable governance.
We need to ensure that we can service our 100+ orphans and create a full decentralized IT infrastructure to support the orphans far far into the future. 

[oliwer21]

Actually now I'm pretty convinced that the issue is either with the pool or the miner or both.  Bible_pay says that every miner is mining on the same difficulty, that right there leads me to believe that the pool can't keep up with the shares submitted.  Of course there is no output to see so you can't tell how many shares you are submitting that are valid or invalid.  Then there are these 2 posts:

http://forum.biblepay.org/index.php?topic=17.0
http://forum.biblepay.org/index.php?topic=18.0

If multiple threads are hashing the same share that would explain why there is such a big difference between local and pool hashrate, and why multiple daemons work best.

Just to reiterate this again:
- All shares issued by the pool are the same difficulty
- HPS2 is supposed to be different than HPS
- HPS2 is based on how many shares you solved in the current round, while HPS is based on your CPU clock hashes per sec.
- The pool is not behind and is able to handle the load (I know because I wrote it, deployed it, and I monitor the performance counters)

You can see clearly that when viewing the leaderboard, the same machines are at the top- and we have a consistent list of users per hashpersec2 reported in the same places. (IE randomness is not a primary factor).

There are certain people here on this thread that are unhappy that lower end processors achieve a higher HPS than their proc.  That is a personal problem.
All the code is public domain, you are all free to download it from github and run variations of the miner on your bench if you think there is some inconsistency with your processor.

The KEY ISSUE that some people are not grasping with biblepay is this:

A high percentage of processor power in the biblehash algorithm is going to querying the node vector itself, not wasting CPU cycles on the hashing.  So if you want to look at this another way, you are being comepensated 60% for running a node, and the rest for the speed.  Im happy we ended up like this as it gives everyone a chance to jump in and receive some BBP.

My main concern is to ensure the algo does not get ported to an ASIC or a GPU.  Im busy over in our other forum deploying code to enable governance.
We need to ensure that we can service our 100+ orphans and create a full decentralized IT infrastructure to support the orphans far far into the future. 

I would say its PR balbling... personal problem ofc... when people show you problem suddenly you saying its a open soure LOL
And your wallet is wasting cpu power cuz svirus posted on official forum that wallet give same shares for all threads (really?!?!)
And even inblue show same thing on his multi worker experiment...
And what you do just pushing to masternodes:)

To be clear many from top of leaderboard are running on linux and they now they probably run multi deamon.
Write on first site its a linux cpu mining coin or 4 core win and all will be happy:)

[616westwarmoth]

I would say its PR balbling... personal problem ofc... when people show you problem suddenly you saying its a open soure LOL
And your wallet is wasting cpu power cuz svirus posted on official forum that wallet give same shares for all threads (really?!?!)
And even inblue show same thing on his multi worker experiment...
And what you do just pushing to masternodes:)

To be clear many from top of leaderboard are running on linux and they now they probably run multi deamon.
Write on first site its a linux cpu mining coin or 4 core win and all will be happy:)

Well, the spirit of open source is if you don't accept his answer, you are free to look at the code.  So he has said repeatedly that there is not a significant problem, so either accept it, or don't.  If you don't you are free to examine the code or move on.

InBlu's experiment showed that there was a significant difference between 10 CPU with one miner (29k HPS2) and 10 CPU with 10 miners (120k HPS2) and a moderate difference with 10 miners on 1 CPU machines (170k HPS2).   To me this says a portion of the overhead is in the wallet and maybe something with RAM.  This is in line though with the coin being ASIC and GPU resistant.

If you don't trust the Dev, then find and fix the problem for us all.  But this Dev has been very active and this coin is benefiting because of it.

[oliwer21]

InBlu's experiment showed that there was a significant difference between 10 CPU with one miner (29k HPS2) and 10 CPU with 10 miners (120k HPS2) and a moderate difference with 10 miners on 1 CPU machines (170k HPS2).   To me this says a portion of the overhead is in the wallet and maybe something with RAM.  This is in line though with the coin being ASIC and GPU resistant.

Watch what wrote svirus on biblepay forum about shares and i think inblue make workaround of it by running many miners.

[616westwarmoth]

I have read almost every post here and on the forum.  I agree there is a modest issue out there, but it is one that affects a very few miners.  So why concentrate on that issue if no one can say what is causing it?  The Dev has his plate overly full, I don't believe the issue is one out of line with the goal of the coin (CPU only) so on the high end of things, the coin may not behave as expected since it is actively resisting GPU and ASIC mining and really, at the point you're running 10 CPU with 32 threads, you're starting to get in the GPU ballpark.  So again, I fail to see that as a deal breaking issue.  Since I lack the programming skills to assess a solution, I would advise if someone more capable also feels it is an issue and one they can solve, then open up the code and solve it.

[slovakia]

anybody started biblepain and doesnt know how it works?  

[oliwer21]

I have read almost every post here and on the forum.  I agree there is a modest issue out there, but it is one that affects a very few miners.  So why concentrate on that issue if no one can say what is causing it?  The Dev has his plate overly full, I don't believe the issue is one out of line with the goal of the coin (CPU only) so on the high end of things, the coin may not behave as expected since it is actively resisting GPU and ASIC mining and really, at the point you're running 10 CPU with 32 threads, you're starting to get in the GPU ballpark.  So again, I fail to see that as a deal breaking issue.  Since I lack the programming skills to assess a solution, I would advise if someone more capable also feels it is an issue and one they can solve, then open up the code and solve it.

Do you know how to run few miners on windows? Cuz inblue told how to run on linux but tried on win and no luck.

[616westwarmoth]

I have read almost every post here and on the forum.  I agree there is a modest issue out there, but it is one that affects a very few miners.  So why concentrate on that issue if no one can say what is causing it?  The Dev has his plate overly full, I don't believe the issue is one out of line with the goal of the coin (CPU only) so on the high end of things, the coin may not behave as expected since it is actively resisting GPU and ASIC mining and really, at the point you're running 10 CPU with 32 threads, you're starting to get in the GPU ballpark.  So again, I fail to see that as a deal breaking issue.  Since I lack the programming skills to assess a solution, I would advise if someone more capable also feels it is an issue and one they can solve, then open up the code and solve it.

Do you know how to run few miners on windows? Cuz inblue told how to run on linux but tried on win and no luck.

I've not tried but here is a link to how to do it in Dash https://www.dash.org/forum/threads/guide-to-run-multiple-wallets-on-pc.4995/.

I would suspect you can do it in much the same way with Biblepay.  Most coins are easier to do stuff on Linux if you know how due to their Linux underpinnings, but usually you can get similar results with Windows.

I doubt you'll see much difference unless you're running a Ryzen or eight core chip, and even then, I'm not so sure.  But I'll test it as well and we can compare notes.

[bileq]

I have read almost every post here and on the forum.  I agree there is a modest issue out there, but it is one that affects a very few miners.  So why concentrate on that issue if no one can say what is causing it?  The Dev has his plate overly full, I don't believe the issue is one out of line with the goal of the coin (CPU only) so on the high end of things, the coin may not behave as expected since it is actively resisting GPU and ASIC mining and really, at the point you're running 10 CPU with 32 threads, you're starting to get in the GPU ballpark.  So again, I fail to see that as a deal breaking issue.  Since I lack the programming skills to assess a solution, I would advise if someone more capable also feels it is an issue and one they can solve, then open up the code and solve it.

Do you know how to run few miners on windows? Cuz inblue told how to run on linux but tried on win and no luck.

I've not tried but here is a link to how to do it in Dash https://www.dash.org/forum/threads/guide-to-run-multiple-wallets-on-pc.4995/.

I would suspect you can do it in much the same way with Biblepay.  Most coins are easier to do stuff on Linux if you know how due to their Linux underpinnings, but usually you can get similar results with Windows.

I doubt you'll see much difference unless you're running a Ryzen or eight core chip, and even then, I'm not so sure.  But I'll test it as well and we can compare notes.

i guess multiple miners, multiple wallets can be running under different users on windows.
create some users on your local computer, then run as with different user wallet program

[nsummy]

I would say its PR balbling... personal problem ofc... when people show you problem suddenly you saying its a open soure LOL
And your wallet is wasting cpu power cuz svirus posted on official forum that wallet give same shares for all threads (really?!?!)
And even inblue show same thing on his multi worker experiment...
And what you do just pushing to masternodes:)

To be clear many from top of leaderboard are running on linux and they now they probably run multi deamon.
Write on first site its a linux cpu mining coin or 4 core win and all will be happy:)

Well, the spirit of open source is if you don't accept his answer, you are free to look at the code.  So he has said repeatedly that there is not a significant problem, so either accept it, or don't.  If you don't you are free to examine the code or move on.

InBlu's experiment showed that there was a significant difference between 10 CPU with one miner (29k HPS2) and 10 CPU with 10 miners (120k HPS2) and a moderate difference with 10 miners on 1 CPU machines (170k HPS2).   To me this says a portion of the overhead is in the wallet and maybe something with RAM.  This is in line though with the coin being ASIC and GPU resistant.

If you don't trust the Dev, then find and fix the problem for us all.  But this Dev has been very active and this coin is benefiting because of it.

Incorrect.  I have yet to see the pool software show up on github.  So the coin creator runs the only pool for the coin, which is closed and proprietary. And when people politely point out problems and issues, instead of acknowledging them, the response is that this is all by design and is open-source, etc.  If this coin is designed for people with low computing power to be able to mine that is great.  But on the same token (no pun intended), maybe the coin creator should not be running a pool that makes up the majority of the hashrate.  To solomine this coin right now would be a waste of time. I realize this is a new coin, beta pool, etc but there is a certain amount of customer service and public relations that go along with launching any successful venture.  Alienating and dismissing early supporters who really just want to help and iron out the bugs is not the way to make this a long term project.  The bottom line is this coin is using the a modified version of the old and defunct built-in dash/bitcoin miner along with code that allows it to work on exactly one pool.

[doutor_broncco]

I think this coin needs a new logo. Better design. Nothing against the current one, respect for the designer, but it seems too bland and made in a hurry. We all could propose a design, then vote and sugest inprovements. If the dev agrees, of course. 

[bible_pay]

I think this coin needs a new logo. Better design. Nothing against the current one, respect for the designer, but it seems too bland and made in a hurry. We all could propose a design, then vote and sugest inprovements. If the dev agrees, of course. 

Yeah, I did agree that we should have a logo contest also at least 30 pages back.  I am willing to stake the first $500 for it, and let the community vote on the logo files.

Keep in mind, I want an entire logo pack : the scalables, the pngs, the jpegs, the svgs, all of it, so this is a $750 job.

[bible_pay]

I would say its PR balbling... personal problem ofc... when people show you problem suddenly you saying its a open soure LOL
And your wallet is wasting cpu power cuz svirus posted on official forum that wallet give same shares for all threads (really?!?!)
And even inblue show same thing on his multi worker experiment...
And what you do just pushing to masternodes:)

To be clear many from top of leaderboard are running on linux and they now they probably run multi deamon.
Write on first site its a linux cpu mining coin or 4 core win and all will be happy:)

Well, the spirit of open source is if you don't accept his answer, you are free to look at the code.  So he has said repeatedly that there is not a significant problem, so either accept it, or don't.  If you don't you are free to examine the code or move on.

InBlu's experiment showed that there was a significant difference between 10 CPU with one miner (29k HPS2) and 10 CPU with 10 miners (120k HPS2) and a moderate difference with 10 miners on 1 CPU machines (170k HPS2).   To me this says a portion of the overhead is in the wallet and maybe something with RAM.  This is in line though with the coin being ASIC and GPU resistant.

If you don't trust the Dev, then find and fix the problem for us all.  But this Dev has been very active and this coin is benefiting because of it.

Incorrect.  I have yet to see the pool software show up on github.  So the coin creator runs the only pool for the coin, which is closed and proprietary. And when people politely point out problems and issues, instead of acknowledging them, the response is that this is all by design and is open-source, etc.  If this coin is designed for people with low computing power to be able to mine that is great.  But on the same token (no pun intended), maybe the coin creator should not be running a pool that makes up the majority of the hashrate.  To solomine this coin right now would be a waste of time. I realize this is a new coin, beta pool, etc but there is a certain amount of customer service and public relations that go along with launching any successful venture.  Alienating and dismissing early supporters who really just want to help and iron out the bugs is not the way to make this a long term project.  The bottom line is this coin is using the a modified version of the old and defunct built-in dash/bitcoin miner along with code that allows it to work on exactly one pool.

No, the pool is not closed and proprietary, its open source along with the github wallet.

If you think I am "lying" on this forum about Anything then this wallet is not for you.    Have I lied about anything here?  What kind of dev would I be?

Running a pool that forces the majority of the hashrate?  Only one person has come forward to run a pool, and he is currently following the instructions. West do you want to send him the same instructions?  Am I hiding anything? 

This is a project for the orphans. 

Alienating?  Ive been working with everyone who doesnt have a bad mouth and a bad attitude.  Id rather work with Christians.  I replied with my view, and no one has posted anything yet that is a higher priority than sanctuary code and our orphans.  The bible hash is doing its job and Im very happy of that.