TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

I came back a couple of hours later and it said "Internal ABN: OK"
So maybe it was a matter of waiting a while for this to fix by itself.

Sorry for the headaches.

Now I am solo mining fine.

Can you try it all over again, and see what the total lag is?  Also could you check the log and see what the timestamp difference is and how long it took to recover?

This way we can modify the code to remove that situation.

Also, you didn't explain if it was a locked wallet; was it because the wallet was locked and then you unlocked it and the problem goes away after a certain amount of time?  (The error in the log would be telling).

I wonder if we should design the wallet to be able to mine without being unlocked.  Maybe this is a hurdle for newbies.

Again, is this 1.4.5.9 that is being tested (cause I think 1.2 in prod was a few months ago).

Getmininginfo dev 1.4.5.9 on mainnet

Code: [Select]

{
 "blocks": 132361,
 "currentblocksize": 1000,
 "currentblocktx": 0,
 "difficulty": 10360.99487125054,
 "errors": "",
 "pooledtx": 0,
 "chain": "main",
 "genproclimit": 1,
 "networkhashps": 619612.9706705563,
 "hashps": 7892.611994219653,
 "minerstarttime": "07-17-2019 20:13:41",
 "hashcounter": 2097288,
 "pooledtx": 0,
 "chain": "main",
 "biblepay-generate": true,
 "poolinfo1": "Pool mining with sam2_funded; ",
 "poolinfo2": "Submitting Solution 07-17-2019 20:17:23; ",
 "poolinfo3": "",
 "abninfo": "Mining with funded Valid ABN 36ad1fbdb62e2c7775e3000c29f4f87d59a4aa660277bef2271cdf94e96e4137; ",
 "poolinfo5": "Internal ABN: Invalid 1563394642; ",
 "gsc_errors": "",
 "poolmining": true,
 "pool_url": "https://pool.biblepay.org",
 "required_abn_weight": 125000
}
cli -version
BiblePay Core RPC client version 1.4.5.9

So just to confirm:

1) You tested solo mining, I tested solo mining, MIP tested solo mining and that worked with internal ABNs fine.

2) You tested both funded and non funded mining against pool.biblepay.org with pleaides, and a non-funded miner.

3) Can you please send a GSC and verify the Cameroon is no longer compounding?  For me they are no longer compounding.

4) We are waiting to turn on LLMQ's before checking the POSE banned states.

5) Did I miss anything?

So just to confirm:

1) You tested solo mining, I tested solo mining, MIP tested solo mining and that worked with internal ABNs fine.

It is a bit hard to capture all the scenarios, as on mainnet, i am limited by ABN. But it starts ok. Using a common wallet, i cannot confirm which machine and hence client solved the block.

2) You tested both funded and non funded mining against pool.biblepay.org with pleaides, and a non-funded miner.

It works initially and sometimes i get this error of a stale block. Don’t know if it specific to 1459. But the wallet is empty and not encrypted.

Code: [Select]

{
  "blocks": 132449,
  "currentblocksize": 24911,
  "currentblocktx": 38,
  "difficulty": 8470.190872573861,
  "errors": "",
  "pooledtx": 38,
  "chain": "main",
  "genproclimit": 3,
  "networkhashps": 558664.7160105165,
  "hashps": 20949.85006229456,
  "minerstarttime": "07-18-2019 05:04:56",
  "hashcounter": 126449943,
  "pooledtx": 38,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "Pool mining with proteus_funded; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; ",
  "poolinfo2": "RM_07-18-2019 16:51:35; RM_07-18-2019 16:51:44; RM_07-18-2019 16:51:50; ",
  "poolinfo3": "",
  "abninfo": "Received a stale block from the pool... Please wait... ; Received a stale block from the pool... Please wait... ; Received a stale block from the pool... Please wait... ; ",
  "poolinfo5": "Internal ABN: Invalid 1563468695; ",
  "gsc_errors": "",
  "poolmining": true,
  "pool_url": "https://pool.biblepay.org",
  "required_abn_weight": 125000
}
cli -version
BiblePay Core RPC client version 1.4.5.9



3) Can you please send a GSC and verify the Cameroon is no longer compounding?  For me they are no longer compounding.

I cannot see any sancs? Is GSC testing DIP3 sanc dependent?

4) We are waiting to turn on LLMQ's before checking the POSE banned states.

5) Did I miss anything?

1.It is a bit hard to capture all the scenarios, as on mainnet, i am limited by ABN. But it starts ok. Using a common wallet, i cannot confirm which machine and hence
  client solved the block.
   It works initially and sometimes i get this error of a stale block. Don’t know if it specific to 1459. But the wallet is empty and not encrypted.

2) Can you please send a GSC and verify the Cameroon is no longer compounding?  For me they are no longer compounding.

I cannot see any sancs? Is GSC testing DIP3 sanc dependent?

So on #1, I do know about the stale block error; that is expected; its the pool sometimes has trouble finding an ABN to give to you (but it usually finds one within 15 secs, so thats OK) it just keeps trying and eventually gets one.

On the sancs, my machine is tied up, but I have not had that problem.  We dont have to wait til LLMQ is turned on in 1.4.5.9 - sancs should already be up and running and in deterministics mode now-  we have about 6 sancs running.

It might be your data is corrupted;  When you boot, ensure litemode is Off (litemode=0 or not in the config).
Then ensure your mnsync 'mnsync status' has reached 999.
You should see 6 sancs in the Sancs list then.

If not, try deleting your mncache*, mnp*, and gov*.dat, and retry again with a cold boot (you might have a bad sanc cache).

Then let me know if 'exec health' shows votes > 4, etc.

Then we can test cameroon again.

1. cli -version
BiblePay Core RPC client version 1.4.5.9 (downloaded binaries)

2. both wallets are fresh unencrypted and empty wallets (deleted whole .biblepayevolution dir)

3. both wallets sync to the top - block height 132570
449c1b5de627362f8369836ab8497720ff36aab9ba45e3bc93d3f65a9c654566

4. They appear to mine on the pool (mainnet) as
a. proteus_funded (Ubuntu 16.04 kernel 4.4.0-154-generic)
b. sam2_funded (Ubuntu 18.04 kernel 4.15.0-54-generic)

5. sanc list of both miners are empty
{
}

6. cli exec health

Code: [Select]

{
 "Command": "health",
 "pam_hash": "0000000000000000000000000000000000000000000000000000000000000000",
 "pam_hash_internal": "00000000000000000000000000000000c52798b5da1155a10e047b781f1a45ba",
 "WARNING": "Our internal PAM hash disagrees with the network. ",
 "govobjhash": "0000000000000000000000000000000000000000000000000000000000000000",
 "Amounts": "",
 "Addresses": "",
 "votes": 0,
 "required_votes": 10,
 "last_superblock": 132450,
 "next_superblock": 132655,
 "next_superblock_triggered": false,
 "Healthy": false,
 "GSC_Voted_In": false
}

Can you kindly provide me a list of DIP3 sancs so that I can just add them into my conf file, please?

Thank you.

Can you try it all over again, and see what the total lag is?  Also could you check the log and see what the timestamp difference is and how long it took to recover?

This way we can modify the code to remove that situation.

Also, you didn't explain if it was a locked wallet; was it because the wallet was locked and then you unlocked it and the problem goes away after a certain amount of time?  (The error in the log would be telling).

I wonder if we should design the wallet to be able to mine without being unlocked.  Maybe this is a hurdle for newbies.

Again, is this 1.4.5.9 that is being tested (cause I think 1.2 in prod was a few months ago).

I am on 1.4.5.9 against mainnet
The wallet was locked but I unlocked and this message was there for several hours after unlocking.
However I repeated the same steps now and I can't reproduce the same message, it behaves as normal.

So maybe it was a glitch on my end.

About unlocking the wallet, I think it would be user friendly to detect that user has setgenerate=true and then, if wallet is locked, show some red message on the Overview screen to unlock it.

1. cli -version
BiblePay Core RPC client version 1.4.5.9 (downloaded binaries)

2. both wallets are fresh unencrypted and empty wallets (deleted whole .biblepayevolution dir)

3. both wallets sync to the top - block height 132570
449c1b5de627362f8369836ab8497720ff36aab9ba45e3bc93d3f65a9c654566

4. They appear to mine on the pool (mainnet) as
a. proteus_funded (Ubuntu 16.04 kernel 4.4.0-154-generic)
b. sam2_funded (Ubuntu 18.04 kernel 4.15.0-54-generic)

5. sanc list of both miners are empty
{
}

6. cli exec health

Code: [Select]

{
 "
 "votes": 0,
 "required_votes": 10,
 "last_superblock": 132450,
 "next_superblock": 132655,
 "next_superblock_triggered": false,
 "Healthy": false,
 "GSC_Voted_In": false
}

Can you kindly provide me a list of DIP3 sancs so that I can just add them into my conf file, please?

Thank you.

1) I just wanted to test mining on mainnet, just to ensure syncing and mining worked, but I wanted us to revert back to Testnet for testing cameroon one and GSCs.  Sorry for the confusion. 
  1b) So, yes, This 1.4.5.9 Testnet branch is called our 0.14 develop branch, and its protocol version is not at all compatible with non deterministic sancs.  Prod (mainnet) is running in non-deterministic (IE non dip 3 mode).  So correct, you will not be able to see any prod sancs in Prod mode on 1.4.5.9.  However, when Prod starts upgrading to dip3 (deterministic), you Will start seeing them on this version.  As a matter of fact, that is something of dire importance we need to test in about a week, once we start pushing that in prod (we are waiting in prod for a Bit to flip over called Dip3-Active, I believe it will flip in about 7 days).
1c)  You can not manually add sancs to the config, (except your own), but in dip3 mode (IE 0.14 branch mode) you cannot manually add any - they all must be sent with ProReg Tx's.  So for all intents and purposes, you cant add them.
2) In Testnet mode however, you should see about 6 sancs right now.  I just booted up in testnet mode and I do see the 6 sancs.  I see exec health has 3 votes.  Does yours agree with the votes count?
3) The other info you posted looks good, on the mining info.
4) Now it would be cool for us to test cameroon again in Testnet mode - just to verify you are no longer seeing the compounded rewards?

Dear Rob,

There appears to be unexplained behaviour when funded and unfunded miner are in one account on the pool.

Pollux     unfunded 135,484 hps 1443
Sam2_funded              7,571 hps 1459
Proteus_funded        32,864 hps 1459

Leaderboard
 oncoapop            17,916.11 hps

Thanks

I am on 1.4.5.9 against mainnet
The wallet was locked but I unlocked and this message was there for several hours after unlocking.
However I repeated the same steps now and I can't reproduce the same message, it behaves as normal.

So maybe it was a glitch on my end.

About unlocking the wallet, I think it would be user friendly to detect that user has setgenerate=true and then, if wallet is locked, show some red message on the Overview screen to unlock it.

Ok great, glad it could not be reproduced again; as I have an encrypted mainnet wallet also, and I am aware of it going to Low ABN weight 0 when it switches, and then the miner being stuck until the ABN expires; but just for ease of use sake, I went ahead and added a line of code to handle this-   so in the next version, when the wallet is locked then unlocked and the miner is in the "0 abn state", it will recover within 15 secs.  That should help cut down the complaints too.

Great idea on the setgenerate=true and the locked wallet.  Ill check this:
If miner is Not funded, and locked, and generating, then we will make a warning appear on the overview page And in the getmininginfo.  Ill do that right now, thanks for the advice!

On a side note, the next wallet version is going to have a new procotol that will allow faster transition and more accurate and quicker comm, but for now, I believe the pool will take this into account after a 1-7 minute lag.

Can you confirm if the HPS settles down properly after 5 mins?

If not, what discrepency remains?

Whoops, Im not giving enough info.

The pool can only handle One miner funding type per USER at a time for the time being (Funded or non funded).
It does allow switching however, but not a conflict per miner (all must be either non funded or funded at the same time).
You can accomplish this by copying the same wallet.dat out to the miners.

This limitation will be removed after people upgrade to the new protocol version - but its not released yet.

I am trying to test pool mining, but after 15 minutes the Core client is stuck in “Connecting to peers” and it does not sync. I just set up:

pool=https://pool.biblepay.org
workerid=MIP
minersleep=0
generate=1

There are 20 banned peers and around 10 working ones too.
I will wait a few more minutes to see if it fixes

PS: I see this in debug.log

Code: [Select]

2019-07-19 19:07:26 ERROR: AcceptBlockHeader: block 6e6f1676585e16959bb1dc81fcc79a60932ee29cd8681504f4295a97547fd92b is marked invalid
2019-07-19 19:07:26 ERROR: invalid header received
2019-07-19 19:07:26 ProcessMessages(headers, 26409 bytes) FAILED peer=0
2019-07-19 19:07:32 ERROR: AcceptBlockHeader: block 6e6f1676585e16959bb1dc81fcc79a60932ee29cd8681504f4295a97547fd92b is marked invalid
2019-07-19 19:07:32 ERROR: invalid header received
2019-07-19 19:07:32 ProcessMessages(headers, 26409 bytes) FAILED peer=1
2019-07-19 19:07:35 Loading addresses from DNS seeds (could take a while)
2019-07-19 19:07:35 1 addresses found from DNS seeds
2019-07-19 19:07:35 dnsseed thread exit
2019-07-19 19:10:13 ERROR: AcceptBlockHeader: block 6e6f1676585e16959bb1dc81fcc79a60932ee29cd8681504f4295a97547fd92b is marked invalid
2019-07-19 19:10:13 ERROR: invalid header received
2019-07-19 19:10:13 ProcessMessages(headers, 26409 bytes) FAILED peer=1
2019-07-19 19:18:02 ERROR: AcceptBlockHeader: block 6e6f1676585e16959bb1dc81fcc79a60932ee29cd8681504f4295a97547fd92b is marked invalid
2019-07-19 19:18:02 ERROR: invalid header received
2019-07-19 19:18:02 ProcessMessages(headers, 26490 bytes) FAILED peer=1
2019-07-19 19:22:32 Timeout downloading headers from peer=1, disconnecting
2019-07-19 19:22:33 ERROR: AcceptBlockHeader: block 6e6f1676585e16959bb1dc81fcc79a60932ee29cd8681504f4295a97547fd92b is marked invalid
2019-07-19 19:22:33 ERROR: invalid header received
2019-07-19 19:22:33 ProcessMessages(headers, 26571 bytes) FAILED peer=2

The only thing I've been doing in this Mac lately is solo mining.

Dear Rob,

Please be aware that both my 1.4.5.9 miners appear to constantly drift off by themselves.

The following machines are running 1.4.5.9 on mainnet

XXX.XXX.098.201
XXX.XXX.108.063

cli -version
BiblePay Core RPC client version 1.4.5.9
block
132761
hash
20d6e3054e7b0c6d957e0884e02141e9e70d8c54758c02b95fc87e2b289a7238


All my other machines are on

BiblePay Core RPC client version 1.4.4.3
getblockhash 132761
960755cefc3ded480ac454ea03a264c8279c9f68b8fada228cd8147046e3f1b5

This can be verified in real time from my monitoring web page
https://oncoapop.sdf.org/biblepaymain/biblepay_chainstate.shtml

getblockhash 132778
02e667e874569ed6000160a6e05bafe7f3a09379da6d529c2d403a1cd32bf6af

I reindexed and everything seems fine. I am with funded mining. I will leave it for a while then try unfunded (unless you instruct me otherwise)

Dear Rob,

Please be aware that both my 1.4.5.9 miners appear to constantly drift off by themselves.

The following machines are running 1.4.5.9 on mainnet

XXX.XXX.098.201
XXX.XXX.108.063

cli -version
BiblePay Core RPC client version 1.4.5.9
block
132761
hash
20d6e3054e7b0c6d957e0884e02141e9e70d8c54758c02b95fc87e2b289a7238


All my other machines are on

BiblePay Core RPC client version 1.4.4.3
getblockhash 132761
960755cefc3ded480ac454ea03a264c8279c9f68b8fada228cd8147046e3f1b5

This can be verified in real time from my monitoring web page
https://oncoapop.sdf.org/biblepaymain/biblepay_chainstate.shtml

getblockhash 132778
02e667e874569ed6000160a6e05bafe7f3a09379da6d529c2d403a1cd32bf6af

These two 1.4.5.9 miners:

1. Tried exec reassesschains 5 times to no avail.

2. Re-Started wallet with -erasechain=1

3. Currently on main chain at height of other machines running 1.4.4.3

4. Will put them on the pool using workerids “sam2” and “proteus” with “_funded” for funded workerids respectively. They have the same wallet as other miners running 1.4.4.3

I reindexed and everything seems fine. I am with funded mining. I will leave it for a while then try unfunded (unless you instruct me otherwise)

Ok, I just realized something.
First let me clarify - so in TESTNET against Develop branch (1.4.5.9), I just checked my 3 sancs and my dev node and they are all in sync.  So I think we can all agree, we didnt go off the rails in TESTNET.

I asked MIP and Oncoapop to test POOL mining in PROD (Mainnet) against 1.4.5.9.  So MIP uses an existing blockchain, and goes off the rails, and so does Oncoapop.

So, heres what I think we need to do.  I think we need to wait on testing Mainnet until Mainnet enables dip3.  Because there are 2 places in the code in 1.4.5.9 that make deterministic calls, assuming DIP3 is always on - for example, if it sees a non-fin-tx, it will handle that differently than mainnet currently does.

So lets go back to Testnet for a while, and once we enable the dip3 sancs in mainnet, Ill jump in testnet and try to mine for a day or two and join you guys and see if we stay on track.

As you both might know, 1.4.5.9 has no sancs to load gov data from either (from mainnet), so its probably banning sancs too.