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

[bible_pay]

Sun, you were asking about 'stratum requested a work restart'.  So I went through a certain amount of pain trying to reduce the chatiness and learned that in stratum its not as simple as just setting a poll setting and resetting the work restart request (as one would believe because of the interval passing).  There are many factors that influence the work restart:  rpc polling duration, merkle root changes (or tx list changes), someone mining the current rounds difficulty, stratum timeout between client-server, etc.

So basically what we have now when someone goes to run a pool, we have some pretty good defaults setup (they can be overridden in the config files).  The client polls for new blocks every 30 seconds, but it also finds new transactions when shares are submitted.  The biggest issue here is the bbpminer external miner has a default timeout (that I have not changed) of 120 seconds, and, if you dont talk to the server within 120 seconds, the client hangs up and starts a new stratum connection.  So the server must always send something to client within that amount of time.  (IE refresh the work).

So in our case, we send updates when either someone found a pobh solution for that diff, or, the 115 seconds is about to expire - then we send new work.

In the future I might increase the timeout on the client then we can increase the timeout on the server later, but it appears to be working relatively well now.
So this is why your client will sometimes hash longer (or shorter) and getting the 'request a work restart' message. 

Nice work on this Rob. Stability seems to really be improving. Question for you on payments. I have 4 workers that have been running against the pool for a few days. What i have noticed is that when payments are made only 1 of 4 workers ever gets a payment eventhough they have all been submitting shares. Are you grouping payments by source ips as all of mine would be natted to the same source ip possibly? Just seems strange only 1 would get paid. Let me know. Thanks

You have 4 workers running on which pool is it?

[jsheets1970]

Sun, you were asking about 'stratum requested a work restart'.  So I went through a certain amount of pain trying to reduce the chatiness and learned that in stratum its not as simple as just setting a poll setting and resetting the work restart request (as one would believe because of the interval passing).  There are many factors that influence the work restart:  rpc polling duration, merkle root changes (or tx list changes), someone mining the current rounds difficulty, stratum timeout between client-server, etc.

So basically what we have now when someone goes to run a pool, we have some pretty good defaults setup (they can be overridden in the config files).  The client polls for new blocks every 30 seconds, but it also finds new transactions when shares are submitted.  The biggest issue here is the bbpminer external miner has a default timeout (that I have not changed) of 120 seconds, and, if you dont talk to the server within 120 seconds, the client hangs up and starts a new stratum connection.  So the server must always send something to client within that amount of time.  (IE refresh the work).

So in our case, we send updates when either someone found a pobh solution for that diff, or, the 115 seconds is about to expire - then we send new work.

In the future I might increase the timeout on the client then we can increase the timeout on the server later, but it appears to be working relatively well now.
So this is why your client will sometimes hash longer (or shorter) and getting the 'request a work restart' message. 

Nice work on this Rob. Stability seems to really be improving. Question for you on payments. I have 4 workers that have been running against the pool for a few days. What i have noticed is that when payments are made only 1 of 4 workers ever gets a payment eventhough they have all been submitting shares. Are you grouping payments by source ips as all of mine would be natted to the same source ip possibly? Just seems strange only 1 would get paid. Let me know. Thanks

You have 4 workers running on which pool is it?

NOMP

[bible_pay]

Sun, you were asking about 'stratum requested a work restart'.  So I went through a certain amount of pain trying to reduce the chatiness and learned that in stratum its not as simple as just setting a poll setting and resetting the work restart request (as one would believe because of the interval passing).  There are many factors that influence the work restart:  rpc polling duration, merkle root changes (or tx list changes), someone mining the current rounds difficulty, stratum timeout between client-server, etc.

So basically what we have now when someone goes to run a pool, we have some pretty good defaults setup (they can be overridden in the config files).  The client polls for new blocks every 30 seconds, but it also finds new transactions when shares are submitted.  The biggest issue here is the bbpminer external miner has a default timeout (that I have not changed) of 120 seconds, and, if you dont talk to the server within 120 seconds, the client hangs up and starts a new stratum connection.  So the server must always send something to client within that amount of time.  (IE refresh the work).

So in our case, we send updates when either someone found a pobh solution for that diff, or, the 115 seconds is about to expire - then we send new work.

In the future I might increase the timeout on the client then we can increase the timeout on the server later, but it appears to be working relatively well now.
So this is why your client will sometimes hash longer (or shorter) and getting the 'request a work restart' message. 

Nice work on this Rob. Stability seems to really be improving. Question for you on payments. I have 4 workers that have been running against the pool for a few days. What i have noticed is that when payments are made only 1 of 4 workers ever gets a payment eventhough they have all been submitting shares. Are you grouping payments by source ips as all of mine would be natted to the same source ip possibly? Just seems strange only 1 would get paid. Let me know. Thanks

You have 4 workers running on which pool is it?

NOMP

Send me the addresses, can't check anything with no data.

[sunk818]

Code:

09:55:29 exec price
09:55:30
{
  "Command": "price",
  "consensus_price": 0.000261121124,
  "qt_phase": 60,
  "qt_prior_phase": 60,
  "qt_future_phase": 60,
  "qt_enabled": true,
  "cur_price": "0.000322452709",
  "BBP/BTC": "0.000000035000",
  "BTC/USD": 9212.93455
}

What is the difference between consensus_price and cur_price?

I see on coingecko and cmc that 3 sat is about 0.0003xx

Could you explain more on consensus_price works?

[jsheets1970]

Sun, you were asking about 'stratum requested a work restart'.  So I went through a certain amount of pain trying to reduce the chatiness and learned that in stratum its not as simple as just setting a poll setting and resetting the work restart request (as one would believe because of the interval passing).  There are many factors that influence the work restart:  rpc polling duration, merkle root changes (or tx list changes), someone mining the current rounds difficulty, stratum timeout between client-server, etc.

So basically what we have now when someone goes to run a pool, we have some pretty good defaults setup (they can be overridden in the config files).  The client polls for new blocks every 30 seconds, but it also finds new transactions when shares are submitted.  The biggest issue here is the bbpminer external miner has a default timeout (that I have not changed) of 120 seconds, and, if you dont talk to the server within 120 seconds, the client hangs up and starts a new stratum connection.  So the server must always send something to client within that amount of time.  (IE refresh the work).

So in our case, we send updates when either someone found a pobh solution for that diff, or, the 115 seconds is about to expire - then we send new work.

In the future I might increase the timeout on the client then we can increase the timeout on the server later, but it appears to be working relatively well now.
So this is why your client will sometimes hash longer (or shorter) and getting the 'request a work restart' message. 

Nice work on this Rob. Stability seems to really be improving. Question for you on payments. I have 4 workers that have been running against the pool for a few days. What i have noticed is that when payments are made only 1 of 4 workers ever gets a payment eventhough they have all been submitting shares. Are you grouping payments by source ips as all of mine would be natted to the same source ip possibly? Just seems strange only 1 would get paid. Let me know. Thanks

You have 4 workers running on which pool is it?

NOMP

Send me the addresses, can't check anything with no data.

Sent

[sunk818]

Sun, you were asking about 'stratum requested a work restart'.  So I went through a certain amount of pain trying to reduce the chatiness and learned that in stratum its not as simple as just setting a poll setting and resetting the work restart request (as one would believe because of the interval passing).  There are many factors that influence the work restart:  rpc polling duration, merkle root changes (or tx list changes), someone mining the current rounds difficulty, stratum timeout between client-server, etc.

1) I am not getting any more duplicate share errors so that is good. Most of my pool mining is ASIC based and I do see the "Stratum requested work restart" sometimes. I'm reading several times per minute is normal.

2) Worker stats seems to reset the hashing stats occasionally? http://nomp.biblepay.org/workers

3) What kind of payment scheme does the pool use? Is it pay-per-share (PPS)? PPLNS? https://coinguides.org/pps-vs-pplns/

4) Finally got paid 137 BBP after 12 hours. So, that is working too...

[bible_pay]

Sun, you were asking about 'stratum requested a work restart'.  So I went through a certain amount of pain trying to reduce the chatiness and learned that in stratum its not as simple as just setting a poll setting and resetting the work restart request (as one would believe because of the interval passing).  There are many factors that influence the work restart:  rpc polling duration, merkle root changes (or tx list changes), someone mining the current rounds difficulty, stratum timeout between client-server, etc.

So basically what we have now when someone goes to run a pool, we have some pretty good defaults setup (they can be overridden in the config files).  The client polls for new blocks every 30 seconds, but it also finds new transactions when shares are submitted.  The biggest issue here is the bbpminer external miner has a default timeout (that I have not changed) of 120 seconds, and, if you dont talk to the server within 120 seconds, the client hangs up and starts a new stratum connection.  So the server must always send something to client within that amount of time.  (IE refresh the work).

So in our case, we send updates when either someone found a pobh solution for that diff, or, the 115 seconds is about to expire - then we send new work.

In the future I might increase the timeout on the client then we can increase the timeout on the server later, but it appears to be working relatively well now.
So this is why your client will sometimes hash longer (or shorter) and getting the 'request a work restart' message. 

Nice work on this Rob. Stability seems to really be improving. Question for you on payments. I have 4 workers that have been running against the pool for a few days. What i have noticed is that when payments are made only 1 of 4 workers ever gets a payment eventhough they have all been submitting shares. Are you grouping payments by source ips as all of mine would be natted to the same source ip possibly? Just seems strange only 1 would get paid. Let me know. Thanks

You have 4 workers running on which pool is it?

NOMP

Send me the addresses, can't check anything with no data.

Sent

Thanks, looks like nomp is sending separate tx's out to all addresses.

[bible_pay]

Sun, you were asking about 'stratum requested a work restart'.  So I went through a certain amount of pain trying to reduce the chatiness and learned that in stratum its not as simple as just setting a poll setting and resetting the work restart request (as one would believe because of the interval passing).  There are many factors that influence the work restart:  rpc polling duration, merkle root changes (or tx list changes), someone mining the current rounds difficulty, stratum timeout between client-server, etc.

1) I am not getting any more duplicate share errors so that is good. Most of my pool mining is ASIC based and I do see the "Stratum requested work restart" sometimes. I'm reading several times per minute is normal.

2) Worker stats seems to reset the hashing stats occasionally? http://nomp.biblepay.org/workers

3) What kind of payment scheme does the pool use? Is it pay-per-share (PPS)? PPLNS? https://coinguides.org/pps-vs-pplns/

4) Finally got paid 137 BBP after 12 hours. So, that is working too...

1) Yes, from what I can see its working properly (even when it resets client work, because its giving fresh work to be less likely to find duplicate pobh hashes).

2)  Yes, stats reset when the block changes.  We are hashing a current 'round' as a group, then we reset.

3) According to nomps docs, they use PROP which is PPS (payment per share) with a reward for only the miners that were present during the block being hashed.  This is very similar to what I did in pool.biblepay.org.

4) Great!  Yes, the payments that are emitting look correct now.  I don't see any orphans over 24 hours, and all the txids are in the dedicated wallet.

[bible_pay]

Code:

09:55:29 exec price
09:55:30
{
  "Command": "price",
  "consensus_price": 0.000261121124,
  "qt_phase": 60,
  "qt_prior_phase": 60,
  "qt_future_phase": 60,
  "qt_enabled": true,
  "cur_price": "0.000322452709",
  "BBP/BTC": "0.000000035000",
  "BTC/USD": 9212.93455
}

What is the difference between consensus_price and cur_price?

I see on coingecko and cmc that 3 sat is about 0.0003xx

Could you explain more on consensus_price works?

Consensus price is the price the sancs agreed we were worth in the last superblock (IE an agreed upon price).  That price was the price where bitcoins value was agreed upon at that time.  The BBP price is our midpoint in satoshi, so thats generally the easy part (IE the 3.5 part).  Then we use the consensus price for the next 24 hours for wallet calculations, like cameroon-ones fiat value, etc.

[bible_pay]

** Nomp transparency **


I added two new reports to pool.biblepay.org today:

Nomp/Nomp Leaderboard:

This shows the current round (IE all the miners participating in hashing the current best height), with their percentage contributed (shares solved/total shares solved) ranked by % descending.  This updates once every 3 mins.  

Nomp/Nomp Block History:

This shows the NOMP history (the history started at block 153716).
This will give us the ability to drill into the total hashpower contributed by miner-address after a block is solved.
NOTE: We currently only have the TXID of the block subsidy in this table.  Let's wait until we have at least 10 blocks solved, then I will start populating the subsidy amount.

So here is an example of how you can use this data:
You can look at the data and find we solved a certain height (when the TXID is populated).  Then you can see your % of contribution to that block by looking at SharePercentage.  

You should receive a payment for the Subsidy * SharePercentage approx. 12 hours after that block is solved.

In a couple days, I will add a Paid Block History report to show specific blocks that nomp paid, and we may be able to add in the subsidy breakdown also (so you can match up the amount received with the subsidy on the row).

Also we can add hashrates soon.

[sunk818]

I added two new reports to pool.biblepay.org today:

You don't mind running a pool or maintaining stats? I thought the idea of a open-source pool was to offload that responsibility from you and let others run with it?

Is PoBH (BiblePay) something NOMP repo would accept as a custom algo?
https://github.com/zone117x/node-open-mining-portal/commits/master

[orbis]

I added two new reports to pool.biblepay.org today:

Rob, thank you for that share payment, but to this NOMP stats.
Why it's needed to join other site to view stats from NOMP pool.
Almost everyone from this conversation is now registered on pool.biblepay.org, but you're expecting new miner to join BBP every day.
How they'll found that exists another site where are other stats related to their miners?
I think that it'll be good to have this stats on NOMP pool.
Or this state is only temporary?

[bible_pay]

I added two new reports to pool.biblepay.org today:

You don't mind running a pool or maintaining stats? I thought the idea of a open-source pool was to offload that responsibility from you and let others run with it?

Is PoBH (BiblePay) something NOMP repo would accept as a custom algo?
https://github.com/zone117x/node-open-mining-portal/commits/master

I don't mind running pool.biblepay *until* we move letter writing to DSQL.

#2:  Pool.biblepay can also display other nomp pools stats; the nomp pool sends pool.biblepay the pools receive address with each record; so, I can add more leaderboards for other pools in a few seconds, IE:  "Orbis nomp pool" etc.

#3:  I doubt POBH should be submitted, because our code is so different it wont work in nomp.  We have our own github fork of nomp now.  Anyway, Im going to be discussing another idea with MIP soon that might break POBH in the future.  Lets talk about that first.

[bible_pay]

I added two new reports to pool.biblepay.org today:

Rob, thank you for that share payment, but to this NOMP stats.
Why it's needed to join other site to view stats from NOMP pool.
Almost everyone from this conversation is now registered on pool.biblepay.org, but you're expecting new miner to join BBP every day.
How they'll found that exists another site where are other stats related to their miners?
I think that it'll be good to have this stats on NOMP pool.
Or this state is only temporary?

Well the problem is Nomp doesnt have a weblist UI, or the capability to crunch the data.  If you want to commit that to nomp you can, but Im trying to clear my plate so I can write PODC 2.0 for biblepay (in contrast to improving nomp).

Im just exposing the stats because I already have that UI available in pool.biblepay, and the stats can be exposed for any nomp pool now that adds the option in the config file.

If you want to run nomp, you can optionally go with nomp-mysql, and that branch does have stats exposed and might work, you can feel free to first get our branch running then merge in the Mysql module and try it out.  Maybe it already shows the extra history.

[sunk818]

#3:  I doubt POBH should be submitted, because our code is so different it wont work in nomp.  We have our own github fork of nomp now.  Anyway, Im going to be discussing another idea with MIP soon that might break POBH in the future.  Lets talk about that first.

The thought there was that if someone is operating a NOMP pool, adding BBP would be easy with some minor changes. Not sure what that would look like... But anyway, having an external miner and pool is amazing in two weeks!

If you want to run nomp, you can optionally go with nomp-mysql, and that branch does have stats exposed and might work, you can feel free to first get our branch running then merge in the Mysql module and try it out.  Maybe it already shows the extra history.

Here's the bit about mySQL:
https://github.com/zone117x/node-open-mining-portal/wiki/Setting-up-NOMP-for-MPOS-usage

The portal has an MPOS compatibility mode so that the it can function as a drop-in-replacement for python-stratum-mining. This mode can be enabled in the configuration and will insert shares into a MySQL database in the format which MPOS expects. For a direct tutorial see the wiki page Setting up NOMP for MPOS usage.

Don't worry about it Rob. Some of us that are tech savvy can probably take a stab at it. I see the repos already. Do you have any BiblePay specific instructions for installing the two components?

https://github.com/biblepay/node-open-mining-portal
https://github.com/biblepay/node-stratum-pool

[bible_pay]

#3:  I doubt POBH should be submitted, because our code is so different it wont work in nomp.  We have our own github fork of nomp now.  Anyway, Im going to be discussing another idea with MIP soon that might break POBH in the future.  Lets talk about that first.

The thought there was that if someone is operating a NOMP pool, adding BBP would be easy with some minor changes. Not sure what that would look like... But anyway, having an external miner and pool is amazing in two weeks!

If you want to run nomp, you can optionally go with nomp-mysql, and that branch does have stats exposed and might work, you can feel free to first get our branch running then merge in the Mysql module and try it out.  Maybe it already shows the extra history.

Here's the bit about mySQL:
https://github.com/zone117x/node-open-mining-portal/wiki/Setting-up-NOMP-for-MPOS-usage

The portal has an MPOS compatibility mode so that the it can function as a drop-in-replacement for python-stratum-mining. This mode can be enabled in the configuration and will insert shares into a MySQL database in the format which MPOS expects. For a direct tutorial see the wiki page Setting up NOMP for MPOS usage.

Don't worry about it Rob. Some of us that are tech savvy can probably take a stab at it. I see the repos already. Do you have any BiblePay specific instructions for installing the two components?

https://github.com/biblepay/node-open-mining-portal
https://github.com/biblepay/node-stratum-pool

I definitely need to create a deployment document - that would save a lot of time.  Deploy a Biblepay Nomp pool.

Todo:  Create this document.

[orbis]

But anyway, having an external miner and pool is amazing in two weeks!

Totally agree with Sunk.
Thank you Rob for this and I'm really excited about new future features.
PODC (BTW I'm for WCG too) and external miner with NOMP pool could be interesting for newcomers.

[Nipar]

Thanks Rob!! Looking real good on both nomp and the nomp pages on poo.lbiblepay.org
Getting good payments on all 5 miners.
fewer restarts, no duplicates.. AWESOME!!

[bible_pay]

But anyway, having an external miner and pool is amazing in two weeks!

Totally agree with Sunk.
Thank you Rob for this and I'm really excited about new future features.
PODC (BTW I'm for WCG too) and external miner with NOMP pool could be interesting for newcomers.

I've been out for a while and I also agree that it would be nice to have some stats on the standalone (simple) version of nomp.  Without requiring the full blown mysql server.

I will do this:

Ill create the document to install nomp within the next 2 days.
Ill add a bounty for a nomp-stats page (similar to what pool.biblepay has) - after that doc is ready.

After that Ill work on podc 2.0 for the month of November (Im hoping we can have a release where we have a mandatory for sancs and users, but not for exchanges) for the initial phase of 2.0 - meaning we can get started with podc without hurrying to release our .14 branch (since its not ready - we still need chainlocks and we also need to resolve some things with apollon and deterministic sancs before we can finish the next mandatory version).

If no one takes the bounty before the end of Nov, or if time permits Ill try to add some stats to the current version of nomp.

In the mean time we can still use pool.biblepay to drill into the rewards (once we solve more blocks) - I see no blocks have solved in the last 6 hours, probably due to high diff - because everything appears to be working properly.

[bible_pay]

Thanks Rob!! Looking real good on both nomp and the nomp pages on poo.lbiblepay.org
Getting good payments on all 5 miners.
fewer restarts, no duplicates.. AWESOME!!

Thanks, at least the entire bible is now in both the core client and the external miner.

Someone can add 'read a bible verse from the miner' if they want.