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

[bible_pay]

give a link to the wallet

Biblepay.org || OP Post

[dave_bbp]

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

"bunch of crap":
-> No, I'm afraid you don't know what you are talking about.  Could you provide one piece of evidence of a way to get around it with a gpu?  Or, you can surely win the 2 mil bounty if you care to?  Please explain.  

All I'm asking for is for you to explain your position in detail.  I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint).

@Rob: his problem is NOT a hypothetical ability to mine with GPU, but a now existing INability to mine with a high power CPU.

@whyme: why don't you redirect your ryzen against WCG and do some PODC instead of simple "heat mining"?

[MIP]

MIP whats cmd for upgrade linux, forgot it, thanks...... good to add on main web in tutorials, missing it there

Using the masternode script
./masternode-install.sh -u -n

Manually
wget https://biblepay.org/biblepayd-evo-x86_64-pc-linux-gnu.tar.gz
tar -xzf biblepayd-evo-x86_64-pc-linux-gnu.tar.gz
#stop daemon, move/copy binaries to replace older, restart daemon

[WhyMe]

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

"bunch of crap":
-> No, I'm afraid you don't know what you are talking about.  Could you provide one piece of evidence of a way to get around it with a gpu?  Or, you can surely win the 2 mil bounty if you care to?  Please explain.  

All I'm asking for is for you to explain your position in detail.  I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint).

For sure I'm complaining ! With the last release I can't anymore use my Ryzen 2600x !
You're trying to lock gpus, it's fine I'm correct with that.
But your modification is too restrictive, "high" cpu hashrate is locked too !
And there's a BIG difference between a Ryzen doing something like 190kHs and a GTX 1070 doing 7MHs no ?

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

"bunch of crap":
-> No, I'm afraid you don't know what you are talking about.  Could you provide one piece of evidence of a way to get around it with a gpu?  Or, you can surely win the 2 mil bounty if you care to?  Please explain.  

All I'm asking for is for you to explain your position in detail.  I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint).

@Rob: his problem is NOT a hypothetical ability to mine with GPU, but a now existing INability to mine with a high power CPU.

@whyme: why don't you redirect your ryzen against WCG and do some PODC instead of simple "heat mining"?

Just finding 1 solo block per day pays more than WCG. And it's winter here, so just doing heat is fine.

[bible_pay]

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

"bunch of crap":
-> No, I'm afraid you don't know what you are talking about.  Could you provide one piece of evidence of a way to get around it with a gpu?  Or, you can surely win the 2 mil bounty if you care to?  Please explain.  

All I'm asking for is for you to explain your position in detail.  I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint).

For sure I'm complaining ! With the last release I can't anymore use my Ryzen 2600x !
You're trying to lock gpus, it's fine I'm correct with that.
But your modification is too restrictive, "high" cpu hashrate is locked too !
And there's a BIG difference between a Ryzen doing something like 190kHs and a GTX 1070 doing 7MHs no ?

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

"bunch of crap":
-> No, I'm afraid you don't know what you are talking about.  Could you provide one piece of evidence of a way to get around it with a gpu?  Or, you can surely win the 2 mil bounty if you care to?  Please explain.  

All I'm asking for is for you to explain your position in detail.  I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint).

@Rob: his problem is NOT a hypothetical ability to mine with GPU, but a now existing INability to mine with a high power CPU.

@whyme: why don't you redirect your ryzen against WCG and do some PODC instead of simple "heat mining"?

Just finding 1 solo block per day pays more than WCG. And it's winter here, so just doing heat is fine.

Just to clarify my position, I'm not against you complaining ... I was under the impression your position was that our GPU restricition was fake.  I just want to clarify that our GPU restriction has been tested from 2017-2018 and it works fine (the logic is sound).

So your talking more about the heat mining environment itself not working, OK, I will look at that now.

Sorry to ruffle your feathers.  Checking.

We are here to provide a quality environment for the miners- we will not tolerate broken software; if something is broken I was not aware of it.

I'll run each of the miners on my windows machine first.

[Borgholio]

With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse?  Thanks!

So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp).  If they are in team bbp, we do not have a minimum rac.

There should be no minimum coin*age reqt either.  The only minimum I am aware of is if a person generates less than .005% of the GSC contract  - then due to rounding, our payment system leaves off the payment (because it considers it zero).  But in this case you should still see some RAC in the leaderboard.  The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row.

Exec rac shows I have 0.99 necessary coin age but my points on the leaderboard are still showing 0.  Thanks!

[bible_pay]

With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse?  Thanks!

So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp).  If they are in team bbp, we do not have a minimum rac.

There should be no minimum coin*age reqt either.  The only minimum I am aware of is if a person generates less than .005% of the GSC contract  - then due to rounding, our payment system leaves off the payment (because it considers it zero).  But in this case you should still see some RAC in the leaderboard.  The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row.

Exec rac shows I have 0.99 necessary coin age but my points on the leaderboard are still showing 0.  Thanks!

You can try to force out an 'exec sendgscc wcg' and see if it gives an error?  If you are still not in the leaderboard please send me the exec rac output.

It might be that you don't have enough coin age for .005% of the rac.

[bible_pay]

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

"bunch of crap":
-> No, I'm afraid you don't know what you are talking about.  Could you provide one piece of evidence of a way to get around it with a gpu?  Or, you can surely win the 2 mil bounty if you care to?  Please explain.  

All I'm asking for is for you to explain your position in detail.  I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint).

For sure I'm complaining ! With the last release I can't anymore use my Ryzen 2600x !
You're trying to lock gpus, it's fine I'm correct with that.
But your modification is too restrictive, "high" cpu hashrate is locked too !
And there's a BIG difference between a Ryzen doing something like 190kHs and a GTX 1070 doing 7MHs no ?

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

"bunch of crap":
-> No, I'm afraid you don't know what you are talking about.  Could you provide one piece of evidence of a way to get around it with a gpu?  Or, you can surely win the 2 mil bounty if you care to?  Please explain.  

All I'm asking for is for you to explain your position in detail.  I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint).

@Rob: his problem is NOT a hypothetical ability to mine with GPU, but a now existing INability to mine with a high power CPU.

@whyme: why don't you redirect your ryzen against WCG and do some PODC instead of simple "heat mining"?

Just finding 1 solo block per day pays more than WCG. And it's winter here, so just doing heat is fine.

Just to clarify my position, I'm not against you complaining ... I was under the impression your position was that our GPU restricition was fake.  I just want to clarify that our GPU restriction has been tested from 2017-2018 and it works fine (the logic is sound).

So your talking more about the heat mining environment itself not working, OK, I will look at that now.

Sorry to ruffle your feathers.  Checking.

We are here to provide a quality environment for the miners- we will not tolerate broken software; if something is broken I was not aware of it.

I'll run each of the miners on my windows machine first.

So far I have only tested nomp mining on my ryzen windows box and I found a couple problems.

The pool difficulty was not set correctly for pobh 2.0, and there was an issue where we complain too often about invalid shares.

These things have just been adjusted.  Its not 'perfect' yet but it appears to be working now (that is pool mining against nomp.biblepay.org).

If you have problems, try increasing the thread count with "-t40" for example in the command line string.
Then wait a while and look at the nomp leaderboard.

When time permits Ill try to hone in on lowering the reject rate to be more like 90% like we had in 1.0.

In the mean time Ill check out solo mining against the wallet using the external miner.

The internal miner seems to be fine (solo mining with setgenerate true 40 for example, gives me 225KHPS, and the nonce was tested in unit testing mode yesterday, so I know the internal miner is working).

Ill test the external miner in solo mode.

[Borgholio]

With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse?  Thanks!

So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp).  If they are in team bbp, we do not have a minimum rac.

There should be no minimum coin*age reqt either.  The only minimum I am aware of is if a person generates less than .005% of the GSC contract  - then due to rounding, our payment system leaves off the payment (because it considers it zero).  But in this case you should still see some RAC in the leaderboard.  The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row.

Exec rac shows I have 0.99 necessary coin age but my points on the leaderboard are still showing 0.  Thanks!

You can try to force out an 'exec sendgscc wcg' and see if it gives an error?  If you are still not in the leaderboard please send me the exec rac output.

It might be that you don't have enough coin age for .005% of the rac.

09:06:17

sendgscc wcg


09:06:17

{
  "Error!": "CreateGSCTransmission::Fail::(Create Transaction) Insufficient funds.",
  "Warning!": "WARNING!  PODC is using 0.99% of your coin age.  This means your RAC will be reduced, resulting in a lower PODC reward.  (Team BiblePay requires 62999 in coin-age, while Non-BiblePay teams require 806996.) "
}

[bible_pay]

With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse?  Thanks!

So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp).  If they are in team bbp, we do not have a minimum rac.

There should be no minimum coin*age reqt either.  The only minimum I am aware of is if a person generates less than .005% of the GSC contract  - then due to rounding, our payment system leaves off the payment (because it considers it zero).  But in this case you should still see some RAC in the leaderboard.  The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row.

Exec rac shows I have 0.99 necessary coin age but my points on the leaderboard are still showing 0.  Thanks!

Oh btw, be sure you have coins in your CPK address.  You can do that with 'exec bankroll qty denom'.  Then let them age.
You can see how much is in there in exec rac, and compare that balance to your total wallet balance, etc.

[bible_pay]

With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse?  Thanks!

So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp).  If they are in team bbp, we do not have a minimum rac.

There should be no minimum coin*age reqt either.  The only minimum I am aware of is if a person generates less than .005% of the GSC contract  - then due to rounding, our payment system leaves off the payment (because it considers it zero).  But in this case you should still see some RAC in the leaderboard.  The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row.

Exec rac shows I have 0.99 necessary coin age but my points on the leaderboard are still showing 0.  Thanks!

You can try to force out an 'exec sendgscc wcg' and see if it gives an error?  If you are still not in the leaderboard please send me the exec rac output.

It might be that you don't have enough coin age for .005% of the rac.

09:06:17

sendgscc wcg


09:06:17

{
  "Error!": "CreateGSCTransmission::Fail::(Create Transaction) Insufficient funds.",
  "Warning!": "WARNING!  PODC is using 0.99% of your coin age.  This means your RAC will be reduced, resulting in a lower PODC reward.  (Team BiblePay requires 62999 in coin-age, while Non-BiblePay teams require 806996.) "
}

Can you paste your exec rac so I can look at the internal wallet calcs and see if there is a limit?

[Borgholio]

With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse?  Thanks!

So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp).  If they are in team bbp, we do not have a minimum rac.

There should be no minimum coin*age reqt either.  The only minimum I am aware of is if a person generates less than .005% of the GSC contract  - then due to rounding, our payment system leaves off the payment (because it considers it zero).  But in this case you should still see some RAC in the leaderboard.  The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row.

Exec rac shows I have 0.99 necessary coin age but my points on the leaderboard are still showing 0.  Thanks!

You can try to force out an 'exec sendgscc wcg' and see if it gives an error?  If you are still not in the leaderboard please send me the exec rac output.

It might be that you don't have enough coin age for .005% of the rac.

09:06:17

sendgscc wcg


09:06:17

{
  "Error!": "CreateGSCTransmission::Fail::(Create Transaction) Insufficient funds.",
  "Warning!": "WARNING!  PODC is using 0.99% of your coin age.  This means your RAC will be reduced, resulting in a lower PODC reward.  (Team BiblePay requires 62999 in coin-age, while Non-BiblePay teams require 806996.) "
}

Can you paste your exec rac so I can look at the internal wallet calcs and see if there is a limit?

09:10:50

{
  "Command": "rac",
  "cpid": "54d2a30e96db342462808e0bed89228d",
  "CPK": "BEnG96E4bTH9JDXhnDUFMnZ6k1XCnMXq8o",
  "wcg_teamid": 30513,
  "next_podc_gsc_transmission": 171482,
  "team_name": "Gridcoin",
  "external_purse_total_coin_age": 32.52513888888889,
  "coin_age_percent_required": 0.99,
  "NOTE!": "Coins must have a maturity of at least 5 confirms for your coin*age to count.  (See current depth in coin control).",
  "WARNING!": "BiblePay requires staking collateral to be stored in your Christian-Public-Key (External Purse) to be available for GSC transmissions.  You currently do not have enough coin age in your external purse.  This means your PODC reward will be reduced to a commensurate amount of RAC.  Please read our PODC 2.0 guide about sending bankroll notes to yourself.  ",
  "coin_age_required": 806996.2736964496,
  "wcg_id": 122894,
  "rac": 4918.07
}




Thanks!

[sunk818]

Rob if you're busy, you can ignore this post - no offense taken.

https://github.com/biblepay/biblepay-evolution/blob/fb8279c0db82db2ff1d8777894b299e1ebd3cda0/src/rpcpog.cpp#L1066

Could explain how the nonce check works? Do I understand this correctly?

Nonce check passes because current time minus last block time is past 30 minutes?
Floor value for nonce is 512 unless nElapsed * 256 (nonce_factor) is greater?

So, I see this error in the debug.log:

2020-01-22 16:30:36 ERROR: CheckProofOfWork: ERROR: High Nonce, PrevTime 1579518261, Time 1579518587, Nonce 4047435024

(1579518587-1579518261)*256 = 83456 . Since the nonce was 4047435024 , the submit block was rejected? The nonce had to be less than 83456?

So as time passes, the submitted nonce value can be a greater? How does the nonce value translate to the "difficulty" sent to the pool?

Code:

bool CheckNonce(bool f9000, unsigned int nNonce, int nPrevHeight, int64_t nPrevBlockTime, int64_t nBlockTime, const Consensus::Params& params)
{
	if (!f9000 || nPrevHeight > params.EVOLUTION_CUTOVER_HEIGHT && nPrevHeight <= params.ANTI_GPU_HEIGHT) 
		return true;
	int64_t MAX_AGE = 30 * 60;
	int NONCE_FACTOR = 256;
	int MAX_NONCE = 512;
	int64_t nElapsed = nBlockTime - nPrevBlockTime;
	if (nElapsed > MAX_AGE) 
		return true;
	int64_t nMaxNonce = nElapsed * NONCE_FACTOR;
	if (nMaxNonce < MAX_NONCE) nMaxNonce = MAX_NONCE;
	return (nNonce > nMaxNonce) ? false : true;
}

[bible_pay]

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

"bunch of crap":
-> No, I'm afraid you don't know what you are talking about.  Could you provide one piece of evidence of a way to get around it with a gpu?  Or, you can surely win the 2 mil bounty if you care to?  Please explain.  

All I'm asking for is for you to explain your position in detail.  I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint).

For sure I'm complaining ! With the last release I can't anymore use my Ryzen 2600x !
You're trying to lock gpus, it's fine I'm correct with that.
But your modification is too restrictive, "high" cpu hashrate is locked too !
And there's a BIG difference between a Ryzen doing something like 190kHs and a GTX 1070 doing 7MHs no ?

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

"bunch of crap":
-> No, I'm afraid you don't know what you are talking about.  Could you provide one piece of evidence of a way to get around it with a gpu?  Or, you can surely win the 2 mil bounty if you care to?  Please explain.  

All I'm asking for is for you to explain your position in detail.  I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint).

@Rob: his problem is NOT a hypothetical ability to mine with GPU, but a now existing INability to mine with a high power CPU.

@whyme: why don't you redirect your ryzen against WCG and do some PODC instead of simple "heat mining"?

Just finding 1 solo block per day pays more than WCG. And it's winter here, so just doing heat is fine.

Just to clarify my position, I'm not against you complaining ... I was under the impression your position was that our GPU restricition was fake.  I just want to clarify that our GPU restriction has been tested from 2017-2018 and it works fine (the logic is sound).

So your talking more about the heat mining environment itself not working, OK, I will look at that now.

Sorry to ruffle your feathers.  Checking.

We are here to provide a quality environment for the miners- we will not tolerate broken software; if something is broken I was not aware of it.

I'll run each of the miners on my windows machine first.

So far I have only tested nomp mining on my ryzen windows box and I found a couple problems.

The pool difficulty was not set correctly for pobh 2.0, and there was an issue where we complain too often about invalid shares.

These things have just been adjusted.  Its not 'perfect' yet but it appears to be working now (that is pool mining against nomp.biblepay.org).

If you have problems, try increasing the thread count with "-t40" for example in the command line string.
Then wait a while and look at the nomp leaderboard.

When time permits Ill try to hone in on lowering the reject rate to be more like 90% like we had in 1.0.

In the mean time Ill check out solo mining against the wallet using the external miner.

The internal miner seems to be fine (solo mining with setgenerate true 40 for example, gives me 225KHPS, and the nonce was tested in unit testing mode yesterday, so I know the internal miner is working).

Ill test the external miner in solo mode.

Ok now Im testing my external miner on my ryzen windows box (bbpminer64.exe -o http://127.0.0.1:12000 -uusername -ppass -t40) and its working.  In task manager I see 99% cpu utilization.

Two days ago, I tested the external miner against testnet using pobh 2.0.  To address your concern about finding a share, and then seeing the other threads reject the same share, thats because in solo mode, if you find a block, the other threads have not joined the main thread yet and the other submissions are stale.  We do explicitly restart the work request (see the code) and let them join - so that is not a bug, its just a lagging display which gets cleared from the page in about 10 more seconds.

I don't see a problem.  I confirmed that this miner can solo mine against testnet and find blocks, and its running at full speed.
You might just need to add the parameter "-t40" to the end of your string.

Otherwise please tell us what problem you are having with heat mining.

[bible_pay]

Rob if you're busy, you can ignore this post - no offense taken.

https://github.com/biblepay/biblepay-evolution/blob/fb8279c0db82db2ff1d8777894b299e1ebd3cda0/src/rpcpog.cpp#L1066

Could explain how the nonce check works? Do I understand this correctly?

Nonce check passes because current time minus last block time is past 30 minutes?
Floor value for nonce is 512 unless nElapsed * 256 (nonce_factor) is greater?

So, I see this error in the debug.log:

2020-01-22 16:30:36 ERROR: CheckProofOfWork: ERROR: High Nonce, PrevTime 1579518261, Time 1579518587, Nonce 4047435024

(1579518587-1579518261)*256 = 83456 . Since the nonce was 4047435024 , the submit block was rejected? The nonce had to be less than 83456?

So as time passes, the submitted nonce value can be a greater? How does the nonce value translate to the "difficulty" sent to the pool?

Code:

bool CheckNonce(bool f9000, unsigned int nNonce, int nPrevHeight, int64_t nPrevBlockTime, int64_t nBlockTime, const Consensus::Params& params)
{
	if (!f9000 || nPrevHeight > params.EVOLUTION_CUTOVER_HEIGHT && nPrevHeight <= params.ANTI_GPU_HEIGHT) 
		return true;
	int64_t MAX_AGE = 30 * 60;
	int NONCE_FACTOR = 256;
	int MAX_NONCE = 512;
	int64_t nElapsed = nBlockTime - nPrevBlockTime;
	if (nElapsed > MAX_AGE) 
		return true;
	int64_t nMaxNonce = nElapsed * NONCE_FACTOR;
	if (nMaxNonce < MAX_NONCE) nMaxNonce = MAX_NONCE;
	return (nNonce > nMaxNonce) ? false : true;
}

First let me explain the logic.  Every block has an embedded timestamp that is hard (IE it cant be falsified).  The block time also is part of what gets hashed, so it affects the pobh hash.
We also must know the block time of the prior block.
We check the elapsed time by subtracting the previous block time from the *to be submitted hard block time*.
Then we allow up to 256 hashes per second, per distinct block.  A distinct block has a miners address and a distinct merkle root.
As time passes, we allow more and more total hashes.  So if you multiply 256 * 60 * 7, we allow up to 107,520 hashes for that created block in 7 minutes.
After 30 minutes (MAX_AGE), we allow any number of hashes (IE even GPUs could win that block).

So the idea is, between 1-7 mins, everyone has an equal chance of winning.   As the time draws longer, more and more chance is given to the ones with the most brute hashes done.

So yes, you could argue that a GPU would have an advantage after 20 mins or so, but this is pretty fair as it requires quite a bit of block recreation in the first 7 minutes.

As far as the pool, the pool is just enforcing what is in the core client.
If someone had a high nonce its probably because they are running the old miner.


The core client and the external miner automatically create new blocks when they run out of nonces.

[bible_pay]

With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse?  Thanks!

So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp).  If they are in team bbp, we do not have a minimum rac.

There should be no minimum coin*age reqt either.  The only minimum I am aware of is if a person generates less than .005% of the GSC contract  - then due to rounding, our payment system leaves off the payment (because it considers it zero).  But in this case you should still see some RAC in the leaderboard.  The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row.

Exec rac shows I have 0.99 necessary coin age but my points on the leaderboard are still showing 0.  Thanks!

You can try to force out an 'exec sendgscc wcg' and see if it gives an error?  If you are still not in the leaderboard please send me the exec rac output.

It might be that you don't have enough coin age for .005% of the rac.

09:06:17

sendgscc wcg


09:06:17

{
  "Error!": "CreateGSCTransmission::Fail::(Create Transaction) Insufficient funds.",
  "Warning!": "WARNING!  PODC is using 0.99% of your coin age.  This means your RAC will be reduced, resulting in a lower PODC reward.  (Team BiblePay requires 62999 in coin-age, while Non-BiblePay teams require 806996.) "
}

Can you paste your exec rac so I can look at the internal wallet calcs and see if there is a limit?

09:10:50

{
  "Command": "rac",
  "cpid": "54d2a30e96db342462808e0bed89228d",
  "CPK": "BEnG96E4bTH9JDXhnDUFMnZ6k1XCnMXq8o",
  "wcg_teamid": 30513,
  "next_podc_gsc_transmission": 171482,
  "team_name": "Gridcoin",
  "external_purse_total_coin_age": 32.52513888888889,
  "coin_age_percent_required": 0.99,
  "NOTE!": "Coins must have a maturity of at least 5 confirms for your coin*age to count.  (See current depth in coin control).",
  "WARNING!": "BiblePay requires staking collateral to be stored in your Christian-Public-Key (External Purse) to be available for GSC transmissions.  You currently do not have enough coin age in your external purse.  This means your PODC reward will be reduced to a commensurate amount of RAC.  Please read our PODC 2.0 guide about sending bankroll notes to yourself.  ",
  "coin_age_required": 806996.2736964496,
  "wcg_id": 122894,
  "rac": 4918.07
}


Thanks!

So basically what its saying is with 4918 RAC in team GRC, we require 806,996 coin age.  But in your purse you only have 32 total coin age.
You would need at least 4,030 coin_age (roughly) to earn more than 1 bbp in the leaderboard (IE .005% of the gsc contract) so you just need to increase your coin age.
If you send yourself a couple hundred K of BBP into your CPK that should fix the problem.  Then the .99 coin_age_percent required would drop to something like .50.

Then the sendgscc will work.

[WhyMe]

"256 hashes per second, per distinct block.  A distinct block has a miners address and a distinct merkle root."

Isn't it too low value ?

[sunk818]

I'll be sending out reimbursement payment in about 12 hours -- if you were affected, please review the audit sheet and make sure it looks correct.
https://docs.google.com/spreadsheets/d/1HBVVpNx93mvqLE5E_dLMWZ6W2NhERecOC6cRWsfRne8/edit?usp=sharing

[bible_pay]

"256 hashes per second, per distinct block.  A distinct block has a miners address and a distinct merkle root."

Isn't it too low value ?

No, because when you run out of nonces, your biblepaycore client will create a new block for you.

Or, you can run more threads.

[bible_pay]

I'll be sending out reimbursement payment in about 12 hours -- if you were affected, please review the audit sheet and make sure it looks correct.
https://docs.google.com/spreadsheets/d/1HBVVpNx93mvqLE5E_dLMWZ6W2NhERecOC6cRWsfRne8/edit?usp=sharing

I gave Capulo his missing payment out of my pocket the other day.