BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[dave_bbp]

So I tried logging on and off several times, this didn't help. Having logged in I can open another tab and don't need to log in again, so this is working.
Then I checked the cookies my browser saved from pool.biblepay.org and I think I found the mistake: the credentials_password cookie saves a wrong value for my pw (double-checked this by deleting it, logging off and on again, same mistake). The problem seems to be that my pool-pw uses a semicolon ( ; ) in the middle of the word and this seems to create a problem for the cookie, because the cookie-pw stops at the letter before the ";". I will try and change my pw again without diacritical signs and see if that helps.

One of my computers just crashed again, I disabled SSL, let's hope for the best. :-D


Edit:
Oh, you beat me to it by posting the update, I'm gonna give this a try then, let's see how it works out over night.

Seems to have worked as expected over night. I tried 3 different things:
a) one machine with 1.0.7.5 and SSL enabled --> crashed
b) one machine with 1.0.7.5 and SSL disabled --> worked
c) one machine with 1.0.7.6 and SSL enabled --> worked

So this was definitely and solely an SSL issue, which is fixed in 76; thanks again.

Regarding the pool login: now without the semicolon in my password the pool page works like a charm and does not kick me out every couple of minutes, so problem solved I guess.

Only "problem" remaining is: why is the (only existing) pool hitting less than 20% of the blocks. 

[1715459632]

1715459632

[1715459632]

1715459632

[1715459632]

1715459632

[1715459632]

1715459632

[1715459632]

1715459632

[hvdb]

So I tried logging on and off several times, this didn't help. Having logged in I can open another tab and don't need to log in again, so this is working.
Then I checked the cookies my browser saved from pool.biblepay.org and I think I found the mistake: the credentials_password cookie saves a wrong value for my pw (double-checked this by deleting it, logging off and on again, same mistake). The problem seems to be that my pool-pw uses a semicolon ( ; ) in the middle of the word and this seems to create a problem for the cookie, because the cookie-pw stops at the letter before the ";". I will try and change my pw again without diacritical signs and see if that helps.

One of my computers just crashed again, I disabled SSL, let's hope for the best. :-D


Edit:
Oh, you beat me to it by posting the update, I'm gonna give this a try then, let's see how it works out over night.

Seems to have worked as expected over night. I tried 3 different things:
a) one machine with 1.0.7.5 and SSL enabled --> crashed
b) one machine with 1.0.7.5 and SSL disabled --> worked
c) one machine with 1.0.7.6 and SSL enabled --> worked

So this was definitely and solely an SSL issue, which is fixed in 76; thanks again.

Regarding the pool login: now without the semicolon in my password the pool page works like a charm and does not kick me out every couple of minutes, so problem solved I guess.

Only "problem" remaining is: why is the (only existing) pool hitting less than 20% of the blocks. 

So I updated to 1.0.7.6 and most miners keeped working.
However some crashed.
I don't see a direct reason why... there is no error or exception.
Any idea?

Code:

2018-01-04 23:02:32 CMasternodePayments::FillBlockPayee -- Masternode payment 693702923735.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:02:32 CMasternodePayments::FillBlockPayee -- Masternode payment 693702923735.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:03:47 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:07 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:26 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:31 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:07:38 msghand thread interrupt
2018-01-04 23:07:38 addcon thread interrupt
2018-01-04 23:07:38 opencon thread interrupt
2018-01-04 23:07:38 net thread interrupt
2018-01-04 23:07:38 scheduler thread interrupt
2018-01-04 23:07:38 mnbcon thread interrupt
2018-01-04 23:07:39 PrepareShutdown: In progress...
2018-01-04 23:07:39 StopNode()
2018-01-04 23:07:51 Verifying mncache.dat format...
2018-01-04 23:07:51 Loaded info from mncache.dat  93ms
2018-01-04 23:07:51      Masternodes: 84, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 84, nDsqCount: 15347
2018-01-04 23:07:51 Writting info to mncache.dat...
2018-01-04 23:07:51 Written info to mncache.dat  690ms
2018-01-04 23:07:51      Masternodes: 84, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 7, entries in Masternode list we asked for: 0, masternode index size: 84, nDsqCount: 15472
2018-01-04 23:07:51 mncache.dat dump finished  784ms
2018-01-04 23:07:51 Verifying mnpayments.dat format...
2018-01-04 23:07:52 Loaded info from mnpayments.dat  484ms
2018-01-04 23:07:52      Votes: 24388, Blocks: 2541
2018-01-04 23:07:52 Writting info to mnpayments.dat...
2018-01-04 23:07:54 Written info to mnpayments.dat  1807ms
2018-01-04 23:07:54      Votes: 25812, Blocks: 2684
2018-01-04 23:07:54 mnpayments.dat dump finished  2293ms
2018-01-04 23:07:54 Verifying governance.dat format...
2018-01-04 23:07:55 Loaded info from governance.dat  1295ms
2018-01-04 23:07:55      Governance Objects: 15 (Proposals: 13, Triggers: 1, Watchdogs: 1/1, Other: 0; Seen: 69), Votes: 0
2018-01-04 23:07:55 Writting info to governance.dat...
2018-01-04 23:07:56 Written info to governance.dat  773ms
2018-01-04 23:07:56      Governance Objects: 15 (Proposals: 13, Triggers: 1, Watchdogs: 1/1, Other: 0; Seen: 70), Votes: 691
2018-01-04 23:07:56 governance.dat dump finished  2068ms
2018-01-04 23:07:56 Verifying netfulfilled.dat format...
2018-01-04 23:07:56 Loaded info from netfulfilled.dat  40ms
2018-01-04 23:07:56      Nodes with fulfilled requests: 8
2018-01-04 23:07:56 Writting info to netfulfilled.dat...
2018-01-04 23:07:56 Written info to netfulfilled.dat  0ms
2018-01-04 23:07:56      Nodes with fulfilled requests: 9
2018-01-04 23:07:56 netfulfilled.dat dump finished  40ms
2018-01-04 23:08:17 Shutdown: done

[sharpshot]

As the 2 exchanges are unusable at the moment, I wonder if it would be worth looking at BiblePay having it's own exchange?  All we would need is one of the big coins with low transaction fees to exchange with.  I would be happy just to buy and sell BiblePay with Litecoin.  As some of these exchanges are a one man operation, with many coins, would it be that difficult to do with just BiblePay and one other coin?  If some of the fees went towards the orphans, then it would be even better.  I think it could also make it much easier for newbies to buy BiblePay, they could get Litecoin or whatever was chosen from Coinbase and then just use the BiblePay exchange.

[bible_pay]

So I tried logging on and off several times, this didn't help. Having logged in I can open another tab and don't need to log in again, so this is working.
Then I checked the cookies my browser saved from pool.biblepay.org and I think I found the mistake: the credentials_password cookie saves a wrong value for my pw (double-checked this by deleting it, logging off and on again, same mistake). The problem seems to be that my pool-pw uses a semicolon ( ; ) in the middle of the word and this seems to create a problem for the cookie, because the cookie-pw stops at the letter before the ";". I will try and change my pw again without diacritical signs and see if that helps.

One of my computers just crashed again, I disabled SSL, let's hope for the best. :-D


Edit:
Oh, you beat me to it by posting the update, I'm gonna give this a try then, let's see how it works out over night.

Seems to have worked as expected over night. I tried 3 different things:
a) one machine with 1.0.7.5 and SSL enabled --> crashed
b) one machine with 1.0.7.5 and SSL disabled --> worked
c) one machine with 1.0.7.6 and SSL enabled --> worked

So this was definitely and solely an SSL issue, which is fixed in 76; thanks again.

Regarding the pool login: now without the semicolon in my password the pool page works like a charm and does not kick me out every couple of minutes, so problem solved I guess.

Only "problem" remaining is: why is the (only existing) pool hitting less than 20% of the blocks. 

So I updated to 1.0.7.6 and most miners keeped working.
However some crashed.
I don't see a direct reason why... there is no error or exception.
Any idea?

Code:

2018-01-04 23:02:32 CMasternodePayments::FillBlockPayee -- Masternode payment 693702923735.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:02:32 CMasternodePayments::FillBlockPayee -- Masternode payment 693702923735.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:03:47 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:07 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:26 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:31 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:07:38 msghand thread interrupt
2018-01-04 23:07:38 addcon thread interrupt
2018-01-04 23:07:38 opencon thread interrupt
2018-01-04 23:07:38 net thread interrupt
2018-01-04 23:07:38 scheduler thread interrupt
2018-01-04 23:07:38 mnbcon thread interrupt
2018-01-04 23:07:39 PrepareShutdown: In progress...
2018-01-04 23:07:39 StopNode()
2018-01-04 23:07:51 Verifying mncache.dat format...
2018-01-04 23:07:51 Loaded info from mncache.dat  93ms
2018-01-04 23:07:51      Masternodes: 84, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 84, nDsqCount: 15347
2018-01-04 23:07:51 Writting info to mncache.dat...
2018-01-04 23:07:51 Written info to mncache.dat  690ms
2018-01-04 23:07:51      Masternodes: 84, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 7, entries in Masternode list we asked for: 0, masternode index size: 84, nDsqCount: 15472
2018-01-04 23:07:51 mncache.dat dump finished  784ms
2018-01-04 23:07:51 Verifying mnpayments.dat format...
2018-01-04 23:07:52 Loaded info from mnpayments.dat  484ms
2018-01-04 23:07:52      Votes: 24388, Blocks: 2541
2018-01-04 23:07:52 Writting info to mnpayments.dat...
2018-01-04 23:07:54 Written info to mnpayments.dat  1807ms
2018-01-04 23:07:54      Votes: 25812, Blocks: 2684
2018-01-04 23:07:54 mnpayments.dat dump finished  2293ms
2018-01-04 23:07:54 Verifying governance.dat format...
2018-01-04 23:07:55 Loaded info from governance.dat  1295ms
2018-01-04 23:07:55      Governance Objects: 15 (Proposals: 13, Triggers: 1, Watchdogs: 1/1, Other: 0; Seen: 69), Votes: 0
2018-01-04 23:07:55 Writting info to governance.dat...
2018-01-04 23:07:56 Written info to governance.dat  773ms
2018-01-04 23:07:56      Governance Objects: 15 (Proposals: 13, Triggers: 1, Watchdogs: 1/1, Other: 0; Seen: 70), Votes: 691
2018-01-04 23:07:56 governance.dat dump finished  2068ms
2018-01-04 23:07:56 Verifying netfulfilled.dat format...
2018-01-04 23:07:56 Loaded info from netfulfilled.dat  40ms
2018-01-04 23:07:56      Nodes with fulfilled requests: 8
2018-01-04 23:07:56 Writting info to netfulfilled.dat...
2018-01-04 23:07:56 Written info to netfulfilled.dat  0ms
2018-01-04 23:07:56      Nodes with fulfilled requests: 9
2018-01-04 23:07:56 netfulfilled.dat dump finished  40ms
2018-01-04 23:08:17 Shutdown: done

Its possible that 1075 let a bad block in (not a security problem, but marked as bad) and that prevents the tip from being read, possibly, please try deleting chainstate -R and blocks -R on that particular node.

[bible_pay]

As the 2 exchanges are unusable at the moment, I wonder if it would be worth looking at BiblePay having it's own exchange?  All we would need is one of the big coins with low transaction fees to exchange with.  I would be happy just to buy and sell BiblePay with Litecoin.  As some of these exchanges are a one man operation, with many coins, would it be that difficult to do with just BiblePay and one other coin?  If some of the fees went towards the orphans, then it would be even better.  I think it could also make it much easier for newbies to buy BiblePay, they could get Litecoin or whatever was chosen from Coinbase and then just use the BiblePay exchange.

I was originally thinking along those lines also for a while, I was considering writing a generic exchange inside the pool, but recently, we have been working with a couple of the bigger exchanges, the info should be available soon.

[bible_pay]

So I tried logging on and off several times, this didn't help. Having logged in I can open another tab and don't need to log in again, so this is working.
Then I checked the cookies my browser saved from pool.biblepay.org and I think I found the mistake: the credentials_password cookie saves a wrong value for my pw (double-checked this by deleting it, logging off and on again, same mistake). The problem seems to be that my pool-pw uses a semicolon ( ; ) in the middle of the word and this seems to create a problem for the cookie, because the cookie-pw stops at the letter before the ";". I will try and change my pw again without diacritical signs and see if that helps.

One of my computers just crashed again, I disabled SSL, let's hope for the best. :-D


Edit:
Oh, you beat me to it by posting the update, I'm gonna give this a try then, let's see how it works out over night.

Seems to have worked as expected over night. I tried 3 different things:
a) one machine with 1.0.7.5 and SSL enabled --> crashed
b) one machine with 1.0.7.5 and SSL disabled --> worked
c) one machine with 1.0.7.6 and SSL enabled --> worked

So this was definitely and solely an SSL issue, which is fixed in 76; thanks again.

Regarding the pool login: now without the semicolon in my password the pool page works like a charm and does not kick me out every couple of minutes, so problem solved I guess.

Only "problem" remaining is: why is the (only existing) pool hitting less than 20% of the blocks.  

Great to hear, thanks!  Let me take a look at this 20% block thing in detail next.

EDIT: Btw, I just realized when you fixed your problem with the removal of the semicolon, the cookie actually contained your password, the one you typed in on the UI, that was not intentional thats a bug, that is supposed to be hashed first.  So this will be fixed in the next pool release also so that the password is never stored anywhere.

[dave_bbp]

Great to hear, thanks!  Let me take a look at this 20% block thing in detail next.

EDIT: Btw, I just realized when you fixed your problem with the removal of the semicolon, the cookie actually contained your password, the one you typed in on the UI, that was not intentional thats a bug, that is supposed to be hashed first.  So this will be fixed in the next pool release also so that the password is never stored anywhere.

Haha yes, I was already wondering why the cookie contained my password in "clear type", that did not seem very secure to me. 

[bible_pay]

Great to hear, thanks!  Let me take a look at this 20% block thing in detail next.

EDIT: Btw, I just realized when you fixed your problem with the removal of the semicolon, the cookie actually contained your password, the one you typed in on the UI, that was not intentional thats a bug, that is supposed to be hashed first.  So this will be fixed in the next pool release also so that the password is never stored anywhere.

Haha yes, I was already wondering why the cookie contained my password in "clear type", that did not seem very secure to me. 

Yeah, I dont like that, its released now if you want to look at the new cookie.

Still looking into this distinct solved count by the pool.... Honing in on the block template given to every miner at the same time with one pool address in it.

[bible_pay]

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.

[seasonw]

I believe CoinsMarkets exchange is back online!

https://coinsmarkets.com/trade-BTC-BBP.htm

Not really, I can view the page but still have difficulty to login...

I believe the DDOS issue haven't solved yet.

[togoshigekata]

I guess I spoke too soon, now Im getting 502 error, sigh, but I was on and did see sell and buy orders going through for BiblePay

[dave_bbp]

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.

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.

[616westwarmoth]

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.

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.

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)

[nomad1307]

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.

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

[zer01112]

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.

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

[hvdb]

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.

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?

[bible_pay]

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.

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?

Yeah, the distinct nonce rule is hitting the little ones pretty hard, let me take a look at if we can enforce a distinct nonce after one share per miner, that would at least keep the list full and allow people to know they are hashing.

[CoinMenX]

PROOF OF BIBLEHASH (POBh) wew can i lear it at where?

[togoshigekata]

PROOF OF BIBLEHASH (POBh) wew can i lear it at where?

http://pool.biblepay.org/Docs/BiblePay_White_Paper.pdf

[togoshigekata]

199 blocks away from superblock!