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

[bible_pay]

i'm not able to rejoin pog...

}
capo@xeon4:~$ biblepay-cli exec cpk capulinko true
{
  "Command": "cpk",
  "Results": false,
  "Error": "ALREADY_IN_CHAIN"
}
capo@xeon4:~$ biblepay-cli exec join pog true
{
  "Command": "join",
  "Results": false,
  "Error": "ALREADY_IN_CHAIN"

how to fix this, seems force is not working for me

Although capulinko, is probably in there already as far as a nickname being linked to an old address, try this:
exec cpk your-nickname your-emailaddress user true
The your-emailaddress and "user" must come before the "force=true"

Then try a sendgscc after 5 confirms after you are in the chain, then wait for the leaderboard.

cpk command works, but join or sendgscc still not:

09:28:50
?
exec join pog


09:28:50
?
{
  "Command": "join",
  "Results": false,
  "Error": "ALREADY_IN_CHAIN"
}


09:29:07
?
sendgscc pog 2000


09:29:07
?
{
}



how to force join? i'm sure i did several unjoin so i should not be joined yet

Well if you did an 'unjoin pog' and waited 5 blocks then did a 'join pog' that should have done it; but anyway, please send me the output of 'exec sentgsc'.
If you sent a gsc with 'sendgscc pog 2000', then received an empty response (that means success), then we should see the txid of the sent GSC and be able to track it.

00:21:51
?
exec sentgsc


00:22:18
?
{
  "d0cd2754a6a7a31221654fc7d959e857703f07b81e169909e135f0a418e5e62f": "ABN Weight: 139803.05, Height: 152935, Date: 10-22-2019 19:14:56",
  "3dd8d1628023ab1c6224c310265b8d136a361b52859322ec8537d841a47cb816": "ABN Weight: 153835.87, Height: 152961, Date: 10-22-2019 22:12:49",
  "38f4e25569f2fa10eba78ff976b15adb72f651d21169fc1119fb4843e661c729": "ABN Weight: 184727.69, Height: 152993, Date: 10-23-2019 02:30:25",
  "45baef568915d4906e9f7ccbd80a15565849644dd4a30accf60169dbe0d88b2c": "ABN Weight: 157957.37, Height: 153011, Date: 10-23-2019 04:51:29",
  "c919a70f25fe6722c7167ffe7165fdab60c3339fea2014249312414ed4079591": "ABN Weight: 173817.82, Height: 153013, Date: 10-23-2019 04:58:06",
  "97a5b5f76bc2d2fddf4da202a85b6d6dd34a94b8ba064ef0da831419fe0134e2": "ABN Weight: 173303.38, Height: 153022, Date: 10-23-2019 06:36:36",
  "7615677539a26386175bc214a0640492722ff3d6d30071a10a6b4ef5bc76f95b": "ABN Weight: 290760.76, Height: 153026, Date: 10-23-2019 06:51:04",
  "cba2d09d12399383517eb07ae45beca4b97e4ecbd6c28fb72a3a0f9a24fd059e": "ABN Weight: 135836.00, Height: 153052, Date: 10-23-2019 09:54:18",
  "f3c988ec9736136bedf6613eeb74678b86d1e2132a0c529fe1a78428452121c2": "ABN Weight: 142925.78, Height: 153063, Date: 10-23-2019 11:32:23",
  "98ae8ab05b57e9ee8e769dea6714aa8c7ea0fa1b54a011f6728a5fd0af070bcf": "ABN Weight: 312574.22, Height: 153071, Date: 10-23-2019 12:25:08",
  "fadd02488429c55c8508ca28a7569abe031b3823e7235267c1fc6206d48fe0f6": "ABN Weight: 329749.16, Height: 153073, Date: 10-23-2019 12:46:24",
  "2567b8ad071be7647ffd32c4a649ef0d8500244836b5f322cbfae3b854465de1": "ABN Weight: 331969.89, Height: 153076, Date: 10-23-2019 13:01:59",
  "Total": 0
}

sendgscc returns empy, but nothing is sent, i think i need somehow rejoin pog but dont know how

So Im double checking our code, and it appears a person could get out and in like this (for future reference) - say we joined with nickname 'cap' - if you did : exec cpk cap, then exec join pog, then we have "cap" being used.  If you did a new force on the cpk without unjoining pog: exec cpk cap2 email user true, then exec unjoin pog, then exec join pog, you would be fine (as far as I can see).  But just ignore this part for now lets move on to your two accounts.

As far as 'capulinko2' I dont see a config issue:  I see BHKIV* being used for the CPK - and it looks fine, it has your sig, then we have the exec join pog being successful also for the BHIV* (capulinko2).  (On a side note I also see a successful BLUL capulo and BLUL pog capulo).  But moving back to capulinko2, I dont see anything stopping your pog.

Could you please do this - try erasing debug.log, and after a restart, unlock the wallet and try the 'sendgscc pog 2000' again and look in the log and see if there is a specific error message?  It could just be at the time you had < 5 in depth.  And maybe that error was only in the log.

If that does not work, tonight while we are sleeping you can try:  exec unjoin pog, wait 5 blocks, then exec join pog and re-report.  (But I dont see that helping the situation).

only this is in log  after trying to tithe
2019-10-30 21:39:52
Tithing 2000.000000 BBP into the Orphan Foundation for POG, because expected ROI is 2394.548592 percent.Misbehaving: 107.172.188.132:40000 peer=20 (0 -> 1)
2019-10-30 21:40:08 Misbehaving: 107.172.188.132:40000 peer=20 (1 -> 2)

and when i try unjoin and then join i get error; already in chain...
i still think i'm not joined, how to force join cmd?

I'm sooo surprised that unjoin join did not work.  Well at least we know your CPK is in.
I'm also surprised you don't receive an error or anything after the confirmation that it will tithe.

Let me add an RPC option for you to force a 'join' and Ill report back in a bit.

[bible_pay]

i'm not able to rejoin pog...

}
capo@xeon4:~$ biblepay-cli exec cpk capulinko true
{
  "Command": "cpk",
  "Results": false,
  "Error": "ALREADY_IN_CHAIN"
}
capo@xeon4:~$ biblepay-cli exec join pog true
{
  "Command": "join",
  "Results": false,
  "Error": "ALREADY_IN_CHAIN"

how to fix this, seems force is not working for me

cpk command works, but join or sendgscc still not:

09:28:50
?
exec join pog



09:29:07
?
sendgscc pog 2000




how to force join? i'm sure i did several unjoin so i should not be joined yet

Well if you did an 'unjoin pog' and waited 5 blocks then did a 'join pog' that should have done it; but anyway, please send me the output of 'exec sentgsc'.
If you sent a gsc with 'sendgscc pog 2000', then received an empty response (that means success), then we should see the txid of the sent GSC and be able to track it.

00:21:51
?
exec sentgsc


sendgscc returns empy, but nothing is sent, i think i need somehow rejoin pog but dont know how

So Im double checking our code, and it appears a person could get out and in like this (for future reference) - say we joined with nickname 'cap' - if you did : exec cpk cap, then exec join pog, then we have "cap" being used.  If you did a new force on the cpk without unjoining pog: exec cpk cap2 email user true, then exec unjoin pog, then exec join pog, you would be fine (as far as I can see).  But just ignore this part for now lets move on to your two accounts.

As far as 'capulinko2' I dont see a config issue:  I see BHKIV* being used for the CPK - and it looks fine, it has your sig, then we have the exec join pog being successful also for the BHIV* (capulinko2).  (On a side note I also see a successful BLUL capulo and BLUL pog capulo).  But moving back to capulinko2, I dont see anything stopping your pog.

Could you please do this - try erasing debug.log, and after a restart, unlock the wallet and try the 'sendgscc pog 2000' again and look in the log and see if there is a specific error message?  It could just be at the time you had < 5 in depth.  And maybe that error was only in the log.

If that does not work, tonight while we are sleeping you can try:  exec unjoin pog, wait 5 blocks, then exec join pog and re-report.  (But I dont see that helping the situation).

only this is in log  after trying to tithe
2019-10-30 21:39:52
Tithing 2000.000000 BBP into the Orphan Foundation for POG, because expected ROI is 2394.548592 percent.Misbehaving: 107.172.188.132:40000 peer=20 (0 -> 1)
2019-10-30 21:40:08 Misbehaving: 107.172.188.132:40000 peer=20 (1 -> 2)

and when i try unjoin and then join i get error; already in chain...
i still think i'm not joined, how to force join cmd?

I'm sooo surprised that unjoin join did not work.  Well at least we know your CPK is in.
I'm also surprised you don't receive an error or anything after the confirmation that it will tithe.

Let me add an RPC option for you to force a 'join' and Ill report back in a bit.

Capulo,

I released this just now for windows:
https://github.com/biblepay/biblepay-evolution/commit/a63bab6a14717dbaf4bcb8e634ae9c3a58d522a7

Hopefully this will solve your problem.

MIP is building the Linux version, but I'm not sure yet of the eta.

To use the command please type:
exec join pog nickname true



Good luck.

[sunk818]

Rob, how do we set up stratum send work restart request more often?

I was looking at pool.js - with vardiff. The comments made me hopeful that perhaps if the difficulty is adjusted often, this would be a way to workaround the duplicate share issue I've been facing in the pool I've been setting up?

Code:

    this.setVarDiff = function (port, varDiffConfig) {
        if (typeof (_this.varDiff[port]) != 'undefined') {
            _this.varDiff[port].removeAllListeners();
        }
        var varDiffInstance = new varDiff(port, varDiffConfig);
        _this.varDiff[port] = varDiffInstance;
        _this.varDiff[port].on('newDifficulty', function (client, newDiff) {

            /* We request to set the newDiff @ the next difficulty retarget
            (which should happen when a new job comes in - AKA BLOCK) */
            client.enqueueNextDifficulty(newDiff);

            /*if (options.varDiff.mode === 'fast'){
            //Send new difficulty, then force miner to use new diff by resending the
            //current job parameters but with the "clean jobs" flag set to false
            //so the miner doesn't restart work and submit duplicate shares
            client.sendDifficulty(newDiff);
            var job = _this.jobManager.currentJob.getJobParams();
            job[8] = false;
            client.sendMiningJob(job);
            }*/

Update:

Oh well.. so much for that idea to uncomment it.

Code:

/pool/nomp/node_modules/stratum-pool/lib/pool.js:877
            if (options.varDiff.mode === 'fast'){
                                ^

TypeError: Cannot read property 'mode' of undefined
    at varDiff.<anonymous> (/home/pool/nomp/node_modules/stratum-pool/lib/pool.js:877:33)
    at emitTwo (events.js:126:13)
    at varDiff.emit (events.js:214:7)
    at StratumClient.<anonymous> (/home/pool/nomp/node_modules/stratum-pool/lib/varDiff.js:122:19)
    at emitTwo (events.js:131:20)
    at StratumClient.emit (events.js:214:7)
    at handleSubmit (/home/pool/nomp/node_modules/stratum-pool/lib/stratum.js:159:15)
    at handleMessage (/home/pool/nomp/node_modules/stratum-pool/lib/stratum.js:72:17)
    at /home/pool/nomp/node_modules/stratum-pool/lib/stratum.js:233:25
    at Array.forEach (<anonymous>)

[sunk818]

Rob, can OP_RETURN be used as a way to store GSC data (e.g. exec join) for PoDC, PoG, Healing? I don't understand OP_RETURN either, but thought you might know more.

https://en.bitcoin.it/wiki/OP_RETURN
https://dash-docs.github.io/en/glossary/null-data-transaction
https://github.com/bitcoin/bitcoin/pull/2738

[MIP]

Rob, can OP_RETURN be used as a way to store GSC data (e.g. exec join) for PoDC, PoG, Healing? I don't understand OP_RETURN either, but thought you might know more.

https://en.bitcoin.it/wiki/OP_RETURN
https://dash-docs.github.io/en/glossary/null-data-transaction
https://github.com/bitcoin/bitcoin/pull/2738

OP_RETURN allows you to store a limited amount of bytes.
Also in Biblepay we have an extra "message" string field to add information into a transaction.

[MIP]

While we are currently in block 154642, for the second day in a row I got my sancs stall behind at block 154590. Now I see, one of them even crashed

I moved those sancs from several $5 Vultr VPS to a bigger hardware a couple of days ago and host all in the same machine with different ports same IP, and they are all now behaving the same, they stall during the night, I restart in the morning, they work for about 15h, then stall again.

Yesterday running reassesschains worked for me, but today is inneffective.

Rob I will send you the log of the crashing MN by email, you will probably find some interesting information there.

[sunk818]

in the nomp pool, I see shares rejected with this error message:

Code:

ntime out of range nTime 1572528879, rpctime 1572528877

what does this mean and why does it happen?

[sunk818]

Rob, can OP_RETURN be used as a way to store GSC data (e.g. exec join) for PoDC, PoG, Healing? I don't understand OP_RETURN either, but thought you might know more.

https://en.bitcoin.it/wiki/OP_RETURN
https://dash-docs.github.io/en/glossary/null-data-transaction
https://github.com/bitcoin/bitcoin/pull/2738

OP_RETURN allows you to store a limited amount of bytes.
Also in Biblepay we have an extra "message" string field to add information into a transaction.

I wanted to see if there is a way to send data when the block is generated with no BBP involved (0 tx fee and no BBP sent to anyone). Was hoping new participants with 0 BBP in wallet could register with GSC.

[bible_pay]

Rob, can OP_RETURN be used as a way to store GSC data (e.g. exec join) for PoDC, PoG, Healing? I don't understand OP_RETURN either, but thought you might know more.

https://en.bitcoin.it/wiki/OP_RETURN
https://dash-docs.github.io/en/glossary/null-data-transaction
https://github.com/bitcoin/bitcoin/pull/2738

OP_RETURN allows you to store a limited amount of bytes.
Also in Biblepay we have an extra "message" string field to add information into a transaction.

I wanted to see if there is a way to send data when the block is generated with no BBP involved (0 tx fee and no BBP sent to anyone). Was hoping new participants with 0 BBP in wallet could register with GSC.

It wouldn't make sense to design 0 bbp requirement when 100% of our use cases require bbp now.  Cameroon requires bbp to pay the bill, podc requires a daily stake, and POG requires a tithe, etc.

Dash has already expirimented with 0 cost transactions and its not being embraced because it can be an attack vector.  We already do support 0 fee transactions - that store data in two ways - but they are 'use at your own risk'.  Basically, they have a 99% chance of being delivered, but a miner could theoretically modify the client and filter those.  Although we do have a more decentralized network than bitcoin and dash, so it probably wouldnt happen (I say this from the perspective that we have distinct CPUs mining, not asics).

Regarding data storage we already have two types of storage:  We use op_return in our non financial tx's and we can store a lot of data, but you pay by the byte.  We also store data in our proprietary transaction format at the end of each vout.  This is where prayers are stored. 

So there is no lack in creation or transmission of PODC messages in biblepay.  However we do charge the transaction fee for the message to avoid the attack vector.

[bible_pay]

in the nomp pool, I see shares rejected with this error message:

Code:

ntime out of range nTime 1572528879, rpctime 1572528877

what does this mean and why does it happen?

That means the share was rejected due to being out of range - we have a window of -320 seconds and +7200 (IE the standard for asic).  Please check the server and ensure the timezone is correct and the time is correct?

Is it only happening on your mining against your own server, or ....

[bible_pay]

While we are currently in block 154642, for the second day in a row I got my sancs stall behind at block 154590. Now I see, one of them even crashed

I moved those sancs from several $5 Vultr VPS to a bigger hardware a couple of days ago and host all in the same machine with different ports same IP, and they are all now behaving the same, they stall during the night, I restart in the morning, they work for about 15h, then stall again.

Yesterday running reassesschains worked for me, but today is inneffective.

Rob I will send you the log of the crashing MN by email, you will probably find some interesting information there.

Do you have swap space on this machine btw?
And when you install bbp, do you let it sync from zero?

It seems like your nodes do have multiple recurring consecutive issues - but I usually see 90 days of uptime per run.
When I have problems I see it is confined down to the same few problem nodes though - somethign to do with region.

Something is going on with your nodes being able to gather votes from the network.
Is your firewall set up in a way to block our gobjects propagation somehow?

Please check exec health and make sure it matches the exec health in the pool.biblepay.org | reports | Sanc health report?

I see the same 10 nodes appear over and over ; could be a Country issue - where nodes aren't reaching out to propagate the votes; but first we need to ensure your votes are falling behind and creating a discrepency with the network?

[bible_pay]

Rob, how do we set up stratum send work restart request more often?

I was looking at pool.js - with vardiff. The comments made me hopeful that perhaps if the difficulty is adjusted often, this would be a way to workaround the duplicate share issue I've been facing in the pool I've been setting up?

Code:

    this.setVarDiff = function (port, varDiffConfig) {
        if (typeof (_this.varDiff[port]) != 'undefined') {
            _this.varDiff[port].removeAllListeners();
        }
        var varDiffInstance = new varDiff(port, varDiffConfig);
        _this.varDiff[port] = varDiffInstance;
        _this.varDiff[port].on('newDifficulty', function (client, newDiff) {

            /* We request to set the newDiff @ the next difficulty retarget
            (which should happen when a new job comes in - AKA BLOCK) */
            client.enqueueNextDifficulty(newDiff);

            /*if (options.varDiff.mode === 'fast'){
            //Send new difficulty, then force miner to use new diff by resending the
            //current job parameters but with the "clean jobs" flag set to false
            //so the miner doesn't restart work and submit duplicate shares
            client.sendDifficulty(newDiff);
            var job = _this.jobManager.currentJob.getJobParams();
            job[8] = false;
            client.sendMiningJob(job);
            }*/

Update:

Oh well.. so much for that idea to uncomment it.

Code:

/pool/nomp/node_modules/stratum-pool/lib/pool.js:877
            if (options.varDiff.mode === 'fast'){
                                ^

TypeError: Cannot read property 'mode' of undefined
    at varDiff.<anonymous> (/home/pool/nomp/node_modules/stratum-pool/lib/pool.js:877:33)
    at emitTwo (events.js:126:13)
    at varDiff.emit (events.js:214:7)
    at StratumClient.<anonymous> (/home/pool/nomp/node_modules/stratum-pool/lib/varDiff.js:122:19)
    at emitTwo (events.js:131:20)
    at StratumClient.emit (events.js:214:7)
    at handleSubmit (/home/pool/nomp/node_modules/stratum-pool/lib/stratum.js:159:15)
    at handleMessage (/home/pool/nomp/node_modules/stratum-pool/lib/stratum.js:72:17)
    at /home/pool/nomp/node_modules/stratum-pool/lib/stratum.js:233:25
    at Array.forEach (<anonymous>)

Please dont uncomment that; thats only for bitcoin-lightning.  Or coins who have difficulty that changes during the same block.

Lets look at our screens and see what the reasoning is for dupes first - I had it down to less than 10% then something appears to have changed recently, sliding back up to 20%?

[bible_pay]

i'm not able to rejoin pog...

}
capo@xeon4:~$ biblepay-cli exec cpk capulinko true
{
  "Command": "cpk",
  "Results": false,
  "Error": "ALREADY_IN_CHAIN"
}
capo@xeon4:~$ biblepay-cli exec join pog true
{
  "Command": "join",
  "Results": false,
  "Error": "ALREADY_IN_CHAIN"

how to fix this, seems force is not working for me

cpk command works, but join or sendgscc still not:

09:28:50
?
exec join pog



09:29:07
?
sendgscc pog 2000




how to force join? i'm sure i did several unjoin so i should not be joined yet

Well if you did an 'unjoin pog' and waited 5 blocks then did a 'join pog' that should have done it; but anyway, please send me the output of 'exec sentgsc'.
If you sent a gsc with 'sendgscc pog 2000', then received an empty response (that means success), then we should see the txid of the sent GSC and be able to track it.

00:21:51
?
exec sentgsc


sendgscc returns empy, but nothing is sent, i think i need somehow rejoin pog but dont know how

So Im double checking our code, and it appears a person could get out and in like this (for future reference) - say we joined with nickname 'cap' - if you did : exec cpk cap, then exec join pog, then we have "cap" being used.  If you did a new force on the cpk without unjoining pog: exec cpk cap2 email user true, then exec unjoin pog, then exec join pog, you would be fine (as far as I can see).  But just ignore this part for now lets move on to your two accounts.

As far as 'capulinko2' I dont see a config issue:  I see BHKIV* being used for the CPK - and it looks fine, it has your sig, then we have the exec join pog being successful also for the BHIV* (capulinko2).  (On a side note I also see a successful BLUL capulo and BLUL pog capulo).  But moving back to capulinko2, I dont see anything stopping your pog.

Could you please do this - try erasing debug.log, and after a restart, unlock the wallet and try the 'sendgscc pog 2000' again and look in the log and see if there is a specific error message?  It could just be at the time you had < 5 in depth.  And maybe that error was only in the log.

If that does not work, tonight while we are sleeping you can try:  exec unjoin pog, wait 5 blocks, then exec join pog and re-report.  (But I dont see that helping the situation).

only this is in log  after trying to tithe
2019-10-30 21:39:52
Tithing 2000.000000 BBP into the Orphan Foundation for POG, because expected ROI is 2394.548592 percent.Misbehaving: 107.172.188.132:40000 peer=20 (0 -> 1)
2019-10-30 21:40:08 Misbehaving: 107.172.188.132:40000 peer=20 (1 -> 2)

and when i try unjoin and then join i get error; already in chain...
i still think i'm not joined, how to force join cmd?

I'm sooo surprised that unjoin join did not work.  Well at least we know your CPK is in.
I'm also surprised you don't receive an error or anything after the confirmation that it will tithe.

Let me add an RPC option for you to force a 'join' and Ill report back in a bit.

Capulo,

I released this just now for windows:
https://github.com/biblepay/biblepay-evolution/commit/a63bab6a14717dbaf4bcb8e634ae9c3a58d522a7

Hopefully this will solve your problem.

MIP is building the Linux version, but I'm not sure yet of the eta.

To use the command please type:
exec join pog nickname true



Good luck.

MIP notified me this version is ready.

Btw, you can type 'exec join' to see 'v1.1' to know you have upgraded.

[bible_pay]

Rob, how do we set up stratum send work restart request more often?

I was looking at pool.js - with vardiff. The comments made me hopeful that perhaps if the difficulty is adjusted often, this would be a way to workaround the duplicate share issue I've been facing in the pool I've been setting up?

Code:

    this.setVarDiff = function (port, varDiffConfig) {
        if (typeof (_this.varDiff[port]) != 'undefined') {
            _this.varDiff[port].removeAllListeners();
        }
        var varDiffInstance = new varDiff(port, varDiffConfig);
        _this.varDiff[port] = varDiffInstance;
        _this.varDiff[port].on('newDifficulty', function (client, newDiff) {

            /* We request to set the newDiff @ the next difficulty retarget
            (which should happen when a new job comes in - AKA BLOCK) */
            client.enqueueNextDifficulty(newDiff);

            /*if (options.varDiff.mode === 'fast'){
            //Send new difficulty, then force miner to use new diff by resending the
            //current job parameters but with the "clean jobs" flag set to false
            //so the miner doesn't restart work and submit duplicate shares
            client.sendDifficulty(newDiff);
            var job = _this.jobManager.currentJob.getJobParams();
            job[8] = false;
            client.sendMiningJob(job);
            }*/

Update:

Oh well.. so much for that idea to uncomment it.

Code:

/pool/nomp/node_modules/stratum-pool/lib/pool.js:877
            if (options.varDiff.mode === 'fast'){
                                ^

TypeError: Cannot read property 'mode' of undefined
    at varDiff.<anonymous> (/home/pool/nomp/node_modules/stratum-pool/lib/pool.js:877:33)
    at emitTwo (events.js:126:13)
    at varDiff.emit (events.js:214:7)
    at StratumClient.<anonymous> (/home/pool/nomp/node_modules/stratum-pool/lib/varDiff.js:122:19)
    at emitTwo (events.js:131:20)
    at StratumClient.emit (events.js:214:7)
    at handleSubmit (/home/pool/nomp/node_modules/stratum-pool/lib/stratum.js:159:15)
    at handleMessage (/home/pool/nomp/node_modules/stratum-pool/lib/stratum.js:72:17)
    at /home/pool/nomp/node_modules/stratum-pool/lib/stratum.js:233:25
    at Array.forEach (<anonymous>)

Please dont uncomment that; thats only for bitcoin-lightning.  Or coins who have difficulty that changes during the same block.

Lets look at our screens and see what the reasoning is for dupes first - I had it down to less than 10% then something appears to have changed recently, sliding back up to 20%?

Sun-

I see our rejects have crept up to 20% or so, let me take a look at the core problem.

[sunk818]

It wouldn't make sense to design 0 bbp requirement when 100% of our use cases require bbp now.  Cameroon requires bbp to pay the bill, podc requires a daily stake, and POG requires a tithe, etc.

If you're going to make PoDC the main GSC contract, I would consider not starting the exponential stake until after you go past a certain RAC like 5k RAC. So, from 1 RAC to 5,000 RAC no stake is required. Why do this? If you create zero barrier to entry, you will get more BBP members. That's also where zero (0) fee registration comes in. You should be able to participate in PoDC 2.0 with 0 BBP in your wallet.

Otherwise, you will need to do airdrop or faucet like last time to get people to BBP. That created a lot of support work and we're just repeating the same scenarios from PoDC 1.0 all over again. Let's learn from the previous pain points.

in the nomp pool, I see shares rejected with this error message:

Code:

ntime out of range nTime 1572528879, rpctime 1572528877

That means the share was rejected due to being out of range - we have a window of -320 seconds and +7200 (IE the standard for asic).  Please check the server and ensure the timezone is correct and the time is correct?

Is it only happening on your mining against your own server, or ....

I've seen it happen on nomp.biblepay.org before. You can see the console error when you run with the -P (protocol) parameter.

I see it on my test pool too but takes some time (10 minutes?) before it shows up. The rejected shares are primarily duplicate, but this out of range shows up less frequently.

[bible_pay]

It wouldn't make sense to design 0 bbp requirement when 100% of our use cases require bbp now.  Cameroon requires bbp to pay the bill, podc requires a daily stake, and POG requires a tithe, etc.

If you're going to make PoDC the main GSC contract, I would consider not starting the exponential stake until after you go past a certain RAC like 5k RAC. So, from 1 RAC to 5,000 RAC no stake is required. Why do this? If you create zero barrier to entry, you will get more BBP members. That's also where zero (0) fee registration comes in. You should be able to participate in PoDC 2.0 with 0 BBP in your wallet.

Otherwise, you will need to do airdrop or faucet like last time to get people to BBP. That created a lot of support work and we're just repeating the same scenarios from PoDC 1.0 all over again. Let's learn from the previous pain points.

in the nomp pool, I see shares rejected with this error message:

Code:

ntime out of range nTime 1572528879, rpctime 1572528877

That means the share was rejected due to being out of range - we have a window of -320 seconds and +7200 (IE the standard for asic).  Please check the server and ensure the timezone is correct and the time is correct?

Is it only happening on your mining against your own server, or ....

I've seen it happen on nomp.biblepay.org before. You can see the console error when you run with the -P (protocol) parameter.

I see it on my test pool too but takes some time (10 minutes?) before it shows up. The rejected shares are primarily duplicate, but this out of range shows up less frequently.

Oh ok, I see what you mean, thats a good idea.  You basically mean we need to also allow a lower barrier of entry for say, cpids who have < 500 RAC.  MIP and I were discussing unbanked last night (maybe leaving a zero stake requirement for mobiles who are unbanked with < 100 RAC, and giving them a way to associate the CPID on the biblepay-mobile wallet).

Yeah, we could actually create a method that would allow association for unbanked with 0 bbp.  Im not sure if this will be ready in testnet first release; but the first baby step is:

- Allow zero staking requirements for cpids with < 100 RAC - so we find these unbanked cpids, as long as they are in team BBP or GRC, they pass and get included
- MIP looks at making the associate message on the mobile
- I look into making this a zero fee tx (since these are going to be relatively rare, I think they will be included in blocks).

I've already got the external purse working; Ill look into implementing these things as I think this helps bring the barriers down.

As far as the nomp, I tweaked a few things just now and it appears to be working; Ive reset the servers shares found counters - if we can get below 10% rejects, I believe its fixed.
You cant get much below 5% as there are a lot of chatty unexpected breaks in the protocol. 
Besides, a rejected share is not necessarily meaning the hashes were wasted; a lot of these mean the stratum job was changed on the server side before the miner submitted the solution for work that was 15 secs old; IE sometimes, the server finds a new merkleroot  - changes the job for its 50 clients - while at the same time the client is sending a solution for work that is 20 secs old - so those are not actually hurting the team as far as finding a block.
But I agree, efficiency rejections should be fixed.  So if we get below 10% again Ill share the params.

[MIP]

Do you have swap space on this machine btw?
And when you install bbp, do you let it sync from zero?

It seems like your nodes do have multiple recurring consecutive issues - but I usually see 90 days of uptime per run.
When I have problems I see it is confined down to the same few problem nodes though - somethign to do with region.

Something is going on with your nodes being able to gather votes from the network.
Is your firewall set up in a way to block our gobjects propagation somehow?

Please check exec health and make sure it matches the exec health in the pool.biblepay.org | reports | Sanc health report?

I see the same 10 nodes appear over and over ; could be a Country issue - where nodes aren't reaching out to propagate the votes; but first we need to ensure your votes are falling behind and creating a discrepency with the network?

I have enough resources. Server is placed in Germany.

I set up firewall allow rules for each of the sanc ports (I guess that if they were closed I would not have been able to start them in first place).
Also, that would not explain why they are seen by pool and masternodes,online for 16 hours then suddenly stall...

Let's see what happens in the next hours, thank you!

[bible_pay]

Do you have swap space on this machine btw?
And when you install bbp, do you let it sync from zero?

It seems like your nodes do have multiple recurring consecutive issues - but I usually see 90 days of uptime per run.
When I have problems I see it is confined down to the same few problem nodes though - somethign to do with region.

Something is going on with your nodes being able to gather votes from the network.
Is your firewall set up in a way to block our gobjects propagation somehow?

Please check exec health and make sure it matches the exec health in the pool.biblepay.org | reports | Sanc health report?

I see the same 10 nodes appear over and over ; could be a Country issue - where nodes aren't reaching out to propagate the votes; but first we need to ensure your votes are falling behind and creating a discrepency with the network?

I have enough resources. Server is placed in Germany.

I set up firewall allow rules for each of the sanc ports (I guess that if they were closed I would not have been able to start them in first place).
Also, that would not explain why they are seen by pool and masternodes,online for 16 hours then suddenly stall...

Let's see what happens in the next hours, thank you!

I would say to hone in on the most suspicious part - each day, we have our GSC superblock spaced 205 apart; typing exec health reveals the next one is at 154795 - thats in 85 blocks - to reveal the most suspicious cause - take a look at the exec health vote level about 20 blocks before and see if it sways from the supermajority on the pool. 

If it does, then you have definitely discovered the problem is gobject propagation receive issues in Germany.

Also, I didn't hear feedback on if you sync from zero when these breakdowns occur; but I do recommend restarting all the governance files from empty - at least once - when these are installed.  This will ensure all the old gobjects are in the cache.

[sunk818]

Oh ok, I see what you mean, thats a good idea.  ... we need to also allow a lower barrier of entry for say, cpids who have < 500 RAC.

Not just for unbanked, but for all signups. Android miners have Linux/Windows/mac QT desktop wallets already. I seriously doubt there were any unbanked in PoDC 1.0 that only had Android. BBP has been perceived as hard to join, so whatever we can do to make not seem like an exclusive walled off garden is good right?

- MIP looks at making the associate message on the mobile

- I look into making this a zero fee tx (since these are going to be relatively rare, I think they will be included in blocks).

Ill look into implementing these things as I think this helps bring the barriers down.

Awesome, thank you!

[MIP]

Also, I didn't hear feedback on if you sync from zero when these breakdowns occur; but I do recommend restarting all the governance files from empty - at least once - when these are installed.  This will ensure all the old gobjects are in the cache.

When I set those sancs up, I initially replaced block database from a bootstrap copy that is like 4 weeks old, as well as peers.dat.
But all the other .DAT files including governance files are recreated from empty.

I will try to be awake by the time you say, however it will be around 1-2 am European time, I hope to make it.