Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 725. (Read 243376 times)
January 06, 2018, 06:55:08 AM
It's 86 masternodes. About 205 blocks are split between them. 205/86 = 2.38. I assume that one MN will receive 2 rewards per day. But for example B9dk5UzLjDu42V2TkrL1pMkFDLcFrPzzR4 it received one reward yesterday. That's all right? Can this be related to the watchman version (MN ver.103)? Well thank you.
January 06, 2018, 06:30:11 AM
Dear Rob
Can you tell me?
Why? Our mining project to get low coins?
Maybe i am error for test , the info below
1 PC = 24 core = share 48
1 PC = 24 core (tested 1 of 1vCPU = total 24 vPC ) = share 91
1 PC = 24 core (tested 1 of 4vCPU = total 6 vPC) = share 62
Same PC ~Same Ram ~Same network
Big Share= get more coin or not?
I called top of 3 big dog to tested . This is correct detail data.
Please fix the problem.
If you feel this is good at BBP future that you keep doing that.
Big pool fee is ok , I support.
But low coin of day that is not good.
I hope BBP will being just，fair and open.
I don't want any misunderstanding . Please explain. Love BBP Love this coin.
Thanks Rob ,Have are nice day
From Hong Kong ...Man
This problem is since... relese. Earlier in old topic Rob said he wont change it because he want to support small minners with low core cpus.Can you tell me?
Why? Our mining project to get low coins?
Maybe i am error for test , the info below
1 PC = 24 core = share 48
1 PC = 24 core (tested 1 of 1vCPU = total 24 vPC ) = share 91
1 PC = 24 core (tested 1 of 4vCPU = total 6 vPC) = share 62
Same PC ~Same Ram ~Same network
Big Share= get more coin or not?
I called top of 3 big dog to tested . This is correct detail data.
Please fix the problem.
If you feel this is good at BBP future that you keep doing that.
Big pool fee is ok , I support.
But low coin of day that is not good.
I hope BBP will being just，fair and open.
I don't want any misunderstanding . Please explain. Love BBP Love this coin.
Thanks Rob ,Have are nice day
From Hong Kong ...Man
But I think, You already know from this topic that multiwallet is your 24 core cpu best friend
especially since Rob takeoff limitation of solutions per ip from pool?I had finished the test about the gain of BBP.
Testing equipment : Machine A & B are Dual L5630 CPU (2.4Ghz 8Core16Thread), all setting are same except cpu core setting
Machine C : AMD Ryzen Pro 1700X (3.4Ghz 8Core16Thread)
-----------------
machine A:
each VM with 2 core (around 410HSP) , Total 8 VM in 9hours BBP Gain = 196.2544
BBP per hour = 21.80604444
machine B :
each VM with 1 core(around 200HSP) , Total 16VM in 9hours BBP Gain = 486.0898
BBP per hour = 54.00997778
Machine C :
All CPU resource used by one BBP process(8500HSP), Each Day = 309.3764
BBP per hour = 12.89068333
This is undoubtedly a disadvantage for high-performance machines in current BBP calculate method.
High cost of high-performance machines but the return rate is lower than the low performance machine.
For example, John pay $ 1000 a day for machine rent to get 5000 BBP
Peter pay $200 a day and gets the same 5000 BBP
I do not think anyone wants to be John....
January 06, 2018, 06:25:49 AM
Can GPU dig this coin?
If not, will the GPU be developed in the future?
AFAIK... GPU have a very slow access to memory, this coin have bible verses in hashing algorithms , so GPU can little inrease other things (like openssl-md5), but not all.If not, will the GPU be developed in the future?
So in future we can increase hashing power, but it will be about few % ... OR...
decrease power, when CPU will wait for for GPU for operation
January 06, 2018, 04:01:57 AM
Yesterday I received the first "auto-payout" from the pool. The feature itself works, but how is it configured? My available balance for payout was something like 700 BBP (not counting the immature of course), but the auto-payout transmitted a very odd 39.7342? Since then nothing more has happened. What is the threshold for the auto-withdrawal?
Also I would really appreciate if the auto-withdrawal would transmit only whole BBP and not fractions of it (up to now I managed to keep my wallet absolutely clean of every fractional values....). This is not only an aesthetical request but also eases things up for tax-purposes later (German bureaucracy...).
Thanks.
On another note: the inital positive effect of the pool adjustments seems to have dried out a little bit, still <25% blocks...
Also I would really appreciate if the auto-withdrawal would transmit only whole BBP and not fractions of it (up to now I managed to keep my wallet absolutely clean of every fractional values....). This is not only an aesthetical request but also eases things up for tax-purposes later (German bureaucracy...).
Thanks.
On another note: the inital positive effect of the pool adjustments seems to have dried out a little bit, still <25% blocks...
January 06, 2018, 03:37:08 AM
Dear Rob
Can you tell me?
Why? Our mining project to get low coins?
Maybe i am error for test , the info below
1 PC = 24 core = share 48
1 PC = 24 core (tested 1 of 1vCPU = total 24 vPC ) = share 91
1 PC = 24 core (tested 1 of 4vCPU = total 6 vPC) = share 62
Same PC ~Same Ram ~Same network
Big Share= get more coin or not?
I called top of 3 big dog to tested . This is correct detail data.
Please fix the problem.
If you feel this is good at BBP future that you keep doing that.
Big pool fee is ok , I support.
But low coin of day that is not good.
I hope BBP will being just，fair and open.
I don't want any misunderstanding . Please explain. Love BBP Love this coin.
Thanks Rob ,Have are nice day
From Hong Kong ...Man
This problem is since... relese. Earlier in old topic Rob said he wont change it because he want to support small minners with low core cpus.Can you tell me?
Why? Our mining project to get low coins?
Maybe i am error for test , the info below
1 PC = 24 core = share 48
1 PC = 24 core (tested 1 of 1vCPU = total 24 vPC ) = share 91
1 PC = 24 core (tested 1 of 4vCPU = total 6 vPC) = share 62
Same PC ~Same Ram ~Same network
Big Share= get more coin or not?
I called top of 3 big dog to tested . This is correct detail data.
Please fix the problem.
If you feel this is good at BBP future that you keep doing that.
Big pool fee is ok , I support.
But low coin of day that is not good.
I hope BBP will being just，fair and open.
I don't want any misunderstanding . Please explain. Love BBP Love this coin.
Thanks Rob ,Have are nice day
From Hong Kong ...Man
But I think, You already know from this topic that multiwallet is your 24 core cpu best friend
especially since Rob takeoff limitation of solutions per ip from pool? January 06, 2018, 03:26:04 AM
Can GPU dig this coin?
If not, will the GPU be developed in the future?
No, and... NO If not, will the GPU be developed in the future?
January 06, 2018, 02:29:45 AM
rob, it looks like you hit the problem, number of solved blocks are increasing... huraaay
Yeah, I will be very happy if we get back to half solved by the pool, and lose this deficit and enable auto pay, and on top of that our diff will probably double, which makes us more attractive to the world.That begs to question, what else can we do to make it better. Ill take a look at what I can do to make the core more unique for solo miners also.
Ill add 10 more receiving addresses now and see if we can get this thing purring overnight.
hmm but it does not goes up overnight
start was ok, we hit more blocks that usually but then same numbers...
January 06, 2018, 01:29:42 AM
199 blocks away from superblock!
Sounds good! Hey we are close to overtaking Doge in price. .00000057 compared to .00000068. Go Orphans!
Orphan Memes are better than Doges.
Orphan Memes? Are you freaking serious?!?
January 06, 2018, 01:18:28 AM
Can GPU dig this coin?
If not, will the GPU be developed in the future?
If not, will the GPU be developed in the future?
January 06, 2018, 12:36:08 AM
Dear Rob
Can you tell me?
Why? Our mining project to get low coins?
Maybe i am error for test , the info below
1 PC = 24 core = share 48
1 PC = 24 core (tested 1 of 1vCPU = total 24 vPC ) = share 91
1 PC = 24 core (tested 1 of 4vCPU = total 6 vPC) = share 62
Same PC ~Same Ram ~Same network
Big Share= get more coin or not?
I called top of 3 big dog to tested . This is correct detail data.
Please fix the problem.
If you feel this is good at BBP future that you keep doing that.
Big pool fee is ok , I support.
But low coin of day that is not good.
I hope BBP will being just，fair and open.
I don't want any misunderstanding . Please explain. Love BBP Love this coin.
Thanks Rob ,Have are nice day
From Hong Kong ...Man
Can you tell me?
Why? Our mining project to get low coins?
Maybe i am error for test , the info below
1 PC = 24 core = share 48
1 PC = 24 core (tested 1 of 1vCPU = total 24 vPC ) = share 91
1 PC = 24 core (tested 1 of 4vCPU = total 6 vPC) = share 62
Same PC ~Same Ram ~Same network
Big Share= get more coin or not?
I called top of 3 big dog to tested . This is correct detail data.
Please fix the problem.
If you feel this is good at BBP future that you keep doing that.
Big pool fee is ok , I support.
But low coin of day that is not good.
I hope BBP will being just，fair and open.
I don't want any misunderstanding . Please explain. Love BBP Love this coin.
Thanks Rob ,Have are nice day
From Hong Kong ...Man
January 05, 2018, 06:45:25 PM
as i mentioned few days ago, add email notification for stopped miners
Ill try to look into this tomorrow. January 05, 2018, 06:43:42 PM
I have a side project for someone who might want to track our Deflationary feature and make a monitoring department out of it:
If someone wants to grab the code and take a look at GetBlockSubsidy, you will see a function in there that decreases our emission by 1.5% per month or 19.5% per year.
It would be nice to post here the next block we decrease our subsidy, then we can make a wiki page out of it to refer to in the future.
I think even though this sounds simple, this will be a large component of the cornerstone of success here at biblepay.
Then once per month we can all look forward to the deflationary block number to hit, and realize the subsidy is going down by 1.5% and therefore everyone gets a "raise" theoretically.
If someone wants to grab the code and take a look at GetBlockSubsidy, you will see a function in there that decreases our emission by 1.5% per month or 19.5% per year.
It would be nice to post here the next block we decrease our subsidy, then we can make a wiki page out of it to refer to in the future.
I think even though this sounds simple, this will be a large component of the cornerstone of success here at biblepay.
Then once per month we can all look forward to the deflationary block number to hit, and realize the subsidy is going down by 1.5% and therefore everyone gets a "raise" theoretically.
Just as a very crude start, we need to make a wiki page for this soon, but for a reference as to exactly when our block numbers kick over for our next monthly deflation target:
Block AccumulatedDepreciationLevel Subsidy
06150 .0150 14775
12300 .0300 14550
18450 .0450 14325
24600 .0600 14100
30750 .0750 13875
So what this means is at block 24600, the same block as our superblock, our monthly deflation measure kicks in and lowers the subsidy from ~14325 to ~14100.
Block AccumulatedDepreciationLevel Subsidy
06150 .0150 14775
12300 .0300 14550
18450 .0450 14325
24600 .0600 14100
30750 .0750 13875
So what this means is at block 24600, the same block as our superblock, our monthly deflation measure kicks in and lowers the subsidy from ~14325 to ~14100.
Reposting to see if anyone is interested in programming BiblePay's deflation
Sorry to bring this back to the top, but my understanding was the deflationary 1.5% was compounding, which the main.ccp confirms.
Code:
iDeflationRate = .015; // 1.5% per month, compounded monthly (19.5% per year with compounding)
Our deflationary effect is compounded as we reduce the block reward 12 times per year, at a rate of 1.5% per reduction instance, giving a total effect of 19.5% annually (since the deflation percent is multipled by smaller and smaller gross numbers over time), in contrast to a one time annual deduction of only 18% (IE 12*1.5).
The subsidy level emitted per month however, in the rows above, offer a glimpse of the static emission per block, but not of the declining curve of the total money supply.
January 05, 2018, 06:25:31 PM
as i mentioned few days ago, add email notification for stopped miners
January 05, 2018, 06:20:47 PM
rob, it looks like you hit the problem, number of solved blocks are increasing... huraaay
Yeah, I will be very happy if we get back to half solved by the pool, and lose this deficit and enable auto pay, and on top of that our diff will probably double, which makes us more attractive to the world.That begs to question, what else can we do to make it better. Ill take a look at what I can do to make the core more unique for solo miners also.
Ill add 10 more receiving addresses now and see if we can get this thing purring overnight.
January 05, 2018, 06:18:03 PM
rob, it looks like you hit the problem, number of solved blocks are increasing... huraaay
January 05, 2018, 06:17:28 PM
199 blocks away from superblock!
Sounds good! Hey we are close to overtaking Doge in price. .00000057 compared to .00000068. Go Orphans!
Orphan Memes are better than Doges.
January 05, 2018, 06:03:04 PM
199 blocks away from superblock!
January 05, 2018, 05:32:39 PM
PROOF OF BIBLEHASH (POBh) wew can i lear it at where?
http://pool.biblepay.org/Docs/BiblePay_White_Paper.pdf
January 05, 2018, 05:29:58 PM
PROOF OF BIBLEHASH (POBh) wew can i lear it at where?
January 05, 2018, 05:20:38 PM
Changes to the Pool to help investigate the percentage of blocks Solved by the Pool miners:
I've been investigating the distinct solved blocks by the pool over 24 hours and see that the pools percent dropped to 17% from approx. 45% two weeks ago, despite having an increase in hashpower and an increase in distinct miner count.
Looking at the mining template that is given to every miner, I came to the conclusion that one possibility is everyone together is trying to solve the same block (since the pool only has one address, and our distinct transaction count in the block is relatively low). I was thinking maybe everyone is doing the same work without realizing it, and that means as we increase the load on the pool, the problem actually gets worse (as diff increases, more miners do exactly the same work).
So to investigate this I analyzed the top 1000 solutions in the last 15 minutes and sure enough, about 15% of the solutions appear to be exactly the same.
So in light of this I am adding two new features to the pool to attempt to "potentially" measure and or solve this problem:
#1: We now require unique solutions for every miner. So any miner who sends the same solution as another miner, the early bird gets the share, the later solution gets marked as SOLUTION_STALE and then the core asks the pool for a new piece of work. (This will probably cause the big dogs in the pool to lose some shares, relatively speaking compared to small dogs, but we'll see).
#2: Since I want to eliminate the possibility of a duplicated block template across the pool, I have requested the pool to have 7 receiving addresses, starting now. Now, the pool will check its receive address list whenever doing block checking. It will also issue a random receiving address in the block template, thereby creating a more unique template per miner. This is now in prod.
Let us monitor the pool for the next 24 hours and see if we have an uptick in pool based solutions.
I've been investigating the distinct solved blocks by the pool over 24 hours and see that the pools percent dropped to 17% from approx. 45% two weeks ago, despite having an increase in hashpower and an increase in distinct miner count.
Looking at the mining template that is given to every miner, I came to the conclusion that one possibility is everyone together is trying to solve the same block (since the pool only has one address, and our distinct transaction count in the block is relatively low). I was thinking maybe everyone is doing the same work without realizing it, and that means as we increase the load on the pool, the problem actually gets worse (as diff increases, more miners do exactly the same work).
So to investigate this I analyzed the top 1000 solutions in the last 15 minutes and sure enough, about 15% of the solutions appear to be exactly the same.
So in light of this I am adding two new features to the pool to attempt to "potentially" measure and or solve this problem:
#1: We now require unique solutions for every miner. So any miner who sends the same solution as another miner, the early bird gets the share, the later solution gets marked as SOLUTION_STALE and then the core asks the pool for a new piece of work. (This will probably cause the big dogs in the pool to lose some shares, relatively speaking compared to small dogs, but we'll see).
#2: Since I want to eliminate the possibility of a duplicated block template across the pool, I have requested the pool to have 7 receiving addresses, starting now. Now, the pool will check its receive address list whenever doing block checking. It will also issue a random receiving address in the block template, thereby creating a more unique template per miner. This is now in prod.
Let us monitor the pool for the next 24 hours and see if we have an uptick in pool based solutions.
That sounds like a very possible cause. Right now I'm seeing quite the effect on the shares: overall I think shares dropped a little bit, but the more significant change is that my small miners (genproclimit=1) have completely disappeared from the list (despite still mining and showing hashps>200 in "getmininginfo"). So it seems that the slow machines currently drop out completely from time to time because they don't hit legit shares fast enough? Let's see how it all works out in a couple of hours or tomorrow.
I am having the same problem
Same here...
Look at the work list the small miners are there but looking at the leaderboard, they are gone...
Also shares is indeed a (lot) lower, but if we hit more blocks it should in the end be the same right?
Jump to: