|
znffal
|
 |
October 03, 2017, 08:49:17 PM |
|
You missed one zero there buddy.  It's $25,000. Silly me  |
|
|
|
|
|
|
|
|
|
|
|
|
|
"I'm sure that in 20 years there will either be very large transaction volume or no volume." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
oliwer21
|
|
October 03, 2017, 10:51:27 PM |
|
I think there is more than likely the issue is that the pool does not take difficulty into consideration. If you have a high hashrate it will give you higher difficulty shares yet it treats your shares no differently than lower difficulty shares. I think that is why running multiple dameons helps. You are essentially saturating your system's cpu and in the process submitting more low difficulty shares. This is just a guess though. For awhile I thought it was the pool not sending work quick enough but cpu usage seems to be stable. The question then becomes, what is the sweet spot to hash the most shares without increasing difficulty? This is all speculation though as you can't even see the miner in action. Kind of ironic that the goal is to stop farm styling mining yet there is only one pool making it difficult to solo mine.
Maybe youre right but with no info from devs we only can guess  |
|
|
|
|
bible_pay (OP)
Full Member
 Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 03, 2017, 11:01:45 PM |
|
and again no answers why 2core got better results in mining like my 2x 10cores/20HT Intel Xeon 2630V4
biblepay beware beware on your announces ,this forum is strong tool for our miners: if wont be miners wont be BIBLEPAY ...
we want answer why 2core is better like 10core?
I know you want answer from developer but I will explain The idea of Biblepay was to make it difficult for farm style mining operations to mint the majority of the biblepay coins. It is the algorithm itself that makes 10 cores less efficient than 2 cores, or something you would have on an old laptop. The idea is to make it so the average person with a simple cpu can have a shot at mining it fruitfully. I would agree with it, but its hard to belive in that when both are working on 100% usage... and you can have bigger hash on 10 core cpu. You have lower hps2 on pool co i dont think its wallet issiue... I think there is more than likely the issue is that the pool does not take difficulty into consideration. If you have a high hashrate it will give you higher difficulty shares yet it treats your shares no differently than lower difficulty shares. I think that is why running multiple dameons helps. You are essentially saturating your system's cpu and in the process submitting more low difficulty shares. This is just a guess though. For awhile I thought it was the pool not sending work quick enough but cpu usage seems to be stable. The question then becomes, what is the sweet spot to hash the most shares without increasing difficulty? This is all speculation though as you can't even see the miner in action. Kind of ironic that the goal is to stop farm styling mining yet there is only one pool making it difficult to solo mine. No this is not the case (LOL, what kind of pool would that be). No the pool hands out equal difficulty work to everyone. As you solve the shares, the work is checked against biblepay to make sure your solution is not only a good hash, but matches the solution in biblepay for the original problem. Then you receive credit for the share. If you were to ask me if we have a speed inconsistency problem, let me say this: I see absolutely no problem in the measurement of HPS or the reward in HPS2 per CPU class in the pool. What I find unusual is how windows machines can achieve an HPS2 of almost as high as linux machines, with HPS showing much lower than than linux HPS. That is it that is my only inconsistency on my mind. Everything else Im happy with, as we are promoting fair mining shares per node. As far as the pool helping, I think the pool provides a fair avenue for mining. Without it you would be out there solo mining. |
|
|
|
|
calxibe
|
|
October 04, 2017, 07:48:00 AM |
|
Could it please be added a version number to the wallet download button at http://biblepay.org/ ? Currently i'm downloading every day and look at the file details to see if there is a new version. |
|
|
|
|
|
|
1oojke
Newbie
Offline
Activity: 4
Merit: 0
|
|
October 04, 2017, 09:18:42 AM |
|
Hi znffal, I answered your questions on reddit, you are pretty much all set up for using the biblepay, you juts need to get some more insights in how to use it Hope my answers help, we may move this discussion to reddit from now on. |
|
|
|
|
|
oliwer21
|
|
October 04, 2017, 11:18:25 AM |
|
and again no answers why 2core got better results in mining like my 2x 10cores/20HT Intel Xeon 2630V4
biblepay beware beware on your announces ,this forum is strong tool for our miners: if wont be miners wont be BIBLEPAY ...
we want answer why 2core is better like 10core?
I know you want answer from developer but I will explain The idea of Biblepay was to make it difficult for farm style mining operations to mint the majority of the biblepay coins. It is the algorithm itself that makes 10 cores less efficient than 2 cores, or something you would have on an old laptop. The idea is to make it so the average person with a simple cpu can have a shot at mining it fruitfully. I would agree with it, but its hard to belive in that when both are working on 100% usage... and you can have bigger hash on 10 core cpu. You have lower hps2 on pool co i dont think its wallet issiue... I think there is more than likely the issue is that the pool does not take difficulty into consideration. If you have a high hashrate it will give you higher difficulty shares yet it treats your shares no differently than lower difficulty shares. I think that is why running multiple dameons helps. You are essentially saturating your system's cpu and in the process submitting more low difficulty shares. This is just a guess though. For awhile I thought it was the pool not sending work quick enough but cpu usage seems to be stable. The question then becomes, what is the sweet spot to hash the most shares without increasing difficulty? This is all speculation though as you can't even see the miner in action. Kind of ironic that the goal is to stop farm styling mining yet there is only one pool making it difficult to solo mine. No this is not the case (LOL, what kind of pool would that be). No the pool hands out equal difficulty work to everyone. As you solve the shares, the work is checked against biblepay to make sure your solution is not only a good hash, but matches the solution in biblepay for the original problem. Then you receive credit for the share. If you were to ask me if we have a speed inconsistency problem, let me say this: I see absolutely no problem in the measurement of HPS or the reward in HPS2 per CPU class in the pool. What I find unusual is how windows machines can achieve an HPS2 of almost as high as linux machines, with HPS showing much lower than than linux HPS. That is it that is my only inconsistency on my mind. Everything else Im happy with, as we are promoting fair mining shares per node. As far as the pool helping, I think the pool provides a fair avenue for mining. Without it you would be out there solo mining. So its ok when 2 core and 8 core cpus have same hps2 and are both are working on 100% cpu usage... Like you said LOL OMFG XD |
|
|
|
|
|
slovakia
|
|
October 04, 2017, 04:01:02 PM |
|
bible_pay where is your answer for my question about suspicious transfer in different 2 wallets with 1 same wallet.dat @west didnt answer me @oliwer by me nobody knows how it work: very sad when devs didnt know how it work ROFL i sent 5 and 10 bibles to CCEX and check: exists next another transfers ... but in main wallet is all OK   https://i.imgur.com/1234xbz.pnghttps://i.imgur.com/KKCKmUB.pngi mined more coins= im almost 6 years miner, but BIBLEPAIN is best confused coin,where main dev doesnt know why is 2core same strong like 10 core hat down it will be continue, this coin will be dead |
|
|
|
|
nsummy
|
|
October 04, 2017, 04:38:45 PM |
|
and again no answers why 2core got better results in mining like my 2x 10cores/20HT Intel Xeon 2630V4
biblepay beware beware on your announces ,this forum is strong tool for our miners: if wont be miners wont be BIBLEPAY ...
we want answer why 2core is better like 10core?
I know you want answer from developer but I will explain The idea of Biblepay was to make it difficult for farm style mining operations to mint the majority of the biblepay coins. It is the algorithm itself that makes 10 cores less efficient than 2 cores, or something you would have on an old laptop. The idea is to make it so the average person with a simple cpu can have a shot at mining it fruitfully. I would agree with it, but its hard to belive in that when both are working on 100% usage... and you can have bigger hash on 10 core cpu. You have lower hps2 on pool co i dont think its wallet issiue... I think there is more than likely the issue is that the pool does not take difficulty into consideration. If you have a high hashrate it will give you higher difficulty shares yet it treats your shares no differently than lower difficulty shares. I think that is why running multiple dameons helps. You are essentially saturating your system's cpu and in the process submitting more low difficulty shares. This is just a guess though. For awhile I thought it was the pool not sending work quick enough but cpu usage seems to be stable. The question then becomes, what is the sweet spot to hash the most shares without increasing difficulty? This is all speculation though as you can't even see the miner in action. Kind of ironic that the goal is to stop farm styling mining yet there is only one pool making it difficult to solo mine. No this is not the case (LOL, what kind of pool would that be). No the pool hands out equal difficulty work to everyone. As you solve the shares, the work is checked against biblepay to make sure your solution is not only a good hash, but matches the solution in biblepay for the original problem. Then you receive credit for the share. If you were to ask me if we have a speed inconsistency problem, let me say this: I see absolutely no problem in the measurement of HPS or the reward in HPS2 per CPU class in the pool. What I find unusual is how windows machines can achieve an HPS2 of almost as high as linux machines, with HPS showing much lower than than linux HPS. That is it that is my only inconsistency on my mind. Everything else Im happy with, as we are promoting fair mining shares per node. As far as the pool helping, I think the pool provides a fair avenue for mining. Without it you would be out there solo mining. I don't want to flat out say you are wrong, but what you are saying does not match up with my experience. Just as a test I took 12 cpu VM, and ran 13 daemons with a max of 2 proc each. HPS2 was half of HPS (pretty much around 10-11k hps, and 4-6k hps2). I increased the the VM to 14 and 16 CPUS with little affect on the HPS2. Then I decided to lower the CPU count while keeping the number of daemons 13. Currently I am using 8 CPUs with these 13 daemons. The HPS has dropped down to about 7 HPS yet HPS2 is 5-6 HPS2. Essentially the lower my computing power, the better the performance. Which does not make sense at all. |
|
|
|
|
|
|
|
oliwer21
|
|
October 04, 2017, 08:18:59 PM |
|
I don't want to flat out say you are wrong, but what you are saying does not match up with my experience. Just as a test I took 12 cpu VM, and ran 13 daemons with a max of 2 proc each. HPS2 was half of HPS (pretty much around 10-11k hps, and 4-6k hps2). I increased the the VM to 14 and 16 CPUS with little affect on the HPS2. Then I decided to lower the CPU count while keeping the number of daemons 13. Currently I am using 8 CPUs with these 13 daemons. The HPS has dropped down to about 7 HPS yet HPS2 is 5-6 HPS2. Essentially the lower my computing power, the better the performance. Which does not make sense at all.
Do you run win or linux? |
|
|
|
|
|
nsummy
|
|
October 05, 2017, 05:39:16 AM |
|
I don't want to flat out say you are wrong, but what you are saying does not match up with my experience. Just as a test I took 12 cpu VM, and ran 13 daemons with a max of 2 proc each. HPS2 was half of HPS (pretty much around 10-11k hps, and 4-6k hps2). I increased the the VM to 14 and 16 CPUS with little affect on the HPS2. Then I decided to lower the CPU count while keeping the number of daemons 13. Currently I am using 8 CPUs with these 13 daemons. The HPS has dropped down to about 7 HPS yet HPS2 is 5-6 HPS2. Essentially the lower my computing power, the better the performance. Which does not make sense at all.
Do you run win or linux? Linux. I almost wonder if its not compiled correctly to take advantage of all of the processor features. |
|
|
|
|
|
PhaseshiftUK
|
|
October 05, 2017, 10:59:28 AM |
|
<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? |
|
|
|
|
slovakia
|
|
October 05, 2017, 11:06:47 AM |
|
JCDenton and whats about that suspicious transfers ?? it looks very bad that when i sent to CCEX few bbl i, i saw in my second wallet with same wallet.dat foreign transactions
|
|
|
|
|
616westwarmoth
|
|
October 05, 2017, 02:16:01 PM |
|
JCDenton and whats about that suspicious transfers ?? it looks very bad that when i sent to CCEX few bbl i, i saw in my second wallet with same wallet.dat foreign transactions
I've not seen any issues with C-Cex, I looked at your message but cannot fully determine what occurred. Did you go through the steps I suggested in PM? |
|
|
|
|
nsummy
|
|
October 05, 2017, 04:00:08 PM |
|
<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 |
|
|
|
|
|
nsummy
|
|
October 05, 2017, 06:43:31 PM |
|
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.0http://forum.biblepay.org/index.php?topic=18.0If 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. |
|
|
|
|
|
znffal
|
|
October 05, 2017, 09:00:06 PM |
|
Hi all quick question if I may.
I have just mined for 24 hours! My first time. On the pool website it says that I have 225 in my balance, and 191 immature. By my math that should mean I have 24 biblepay "available". Should this be showing in my software wallet on my computer? Because it just says balance 0.
Thanks
|
|
|
|
|
|
seeksilence
|
|
October 05, 2017, 09:12:34 PM |
|
account to set Default Withdrawal Address
Then account--withdraw to your wallet address
|
|
|
|
|
seeksilence
|
|
October 05, 2017, 09:16:25 PM |
|
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.
|
|
|
|
|
