Pages:
Author

Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 73. (Read 243376 times)

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
#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
Quote
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.


full member
Activity: 1176
Merit: 111
#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
Quote
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
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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.

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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.

newbie
Activity: 150
Merit: 0
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?
full member
Activity: 1176
Merit: 111
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
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
** 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.



full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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.

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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... Smiley


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.

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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.

full member
Activity: 1176
Merit: 111
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... Smiley

newbie
Activity: 60
Merit: 0
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
full member
Activity: 1176
Merit: 111
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?
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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.

newbie
Activity: 60
Merit: 0
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
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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?

newbie
Activity: 60
Merit: 0
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
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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. 

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
All blocks solved up to this point were paid out of pool.biblepay.org, also (IE Nomp sent out what it knew about, but pool.biblepay also paid them). 
The way the payments are *supposed* to work, Nomp writes the blockhashes down in the database, and wait for them to mature.  After 120 blocks, it pays the recipients within 30 mins.  We have yet to see any sanity in the process, but once I see a few come in on QT Ill start tracking these babies.
Rob, I'm on NOMP pool almost from beggining, but I did'nt received any payment yet.
My worker was B4z5SQtK9hMFkDdAzpMuJXNcPyFhFBPPc1. I started as funded, with pool.biblepay worker, but after ABN shut down I mine standalone.
I put to the pool only few VPS, but It would be very bad luck to not have any share in solved blocks.
It would be good to see miner statistics (history), lik it's on other pools. I understand that this is beta and maybe this is the future future, but now I'm not able to see my results.
So I mine on pool for few days without any payment and I don't know why Smiley Sad
With actual diff it's not possible to mine solo for me, so I'm moving to pool.biblepay for now Smiley

Nomp hasnt started working until 10AM yesterday.  I believe the bug was fixed around noon yesterday, but now, it has solved 11 blocks in about 23 hours, at 2.89 mh.  So now it looks like its working correctly.  (I sent you an estimated earning for the first day from my account since I already erased nomps data up to 10 am yesterday).

But anyway, for the 11 we solved today, you should get your own piece as these 9 blocks confirm today- let me know if you get your appropriate hashpower reward.

As far as stats, I plan on exposing the stats at pool.biblepay.org for each address in a report so we can see the HPS by address per block number etc.  Im going to try to do this in a light optional way so even if we have more nomp pools a person can still check the history.  With nomp its possible to run a full blown mysql server, and you get the history, but Im not going to do that path now as I think we are only missing a couple things - payout ratios and block history.  I dont want to increase the reqs to run a biblepay pool to start to require dbas and all the other dependencies and support when the pool is doing 95% of what its supposed to now; I think we just need a few stats for the time being.  Then we can focus on PODC 2.0 and refine it more as we go.

full member
Activity: 1260
Merit: 115
I looked into starting my own country, its not easy, at all

I looked into getting another citizenship, if I was a descendant of a few countries it might be easier,
I could buy my way, but it costs a TON of money, so that was a dead end too

Cant wait for a big decentralized exchange (DEX), I like bisq but its pretty small still,
what are the top DEXs right now?

https://hackernoon.com/top-10-decentralized-crypto-exchanges-for-a-successful-proofofkeys-in-2019-478dc38cff7a
https://blockonomi.com/decentralized-exchanges/
https://coinsutra.com/best-decentralized-exchanges-dex/
https://coinfunda.com/best-decentralized-exchanges/
https://blog.lumiwallet.com/top-decentralized-exchange-dex/

John Mcafee launched a DEX but its only ethereum tokens right now
https://bitcoinist.com/john-mcafee-launches-non-custodial-dex-on-ethereum/
https://twitter.com/officialmcafee
Pages:
Jump to: