Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - oncoapop

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12
106
Thats awesome.  I see .181 in my sanc list now also, with 0 POSE.
Just a guess, but maybe it was your masternodeblsprivkey on the old one, not matching?  In both of my cases it was using externalip=.  I found after I recreated without that, they stay up. 

Yes, good to know you were able to use the Dash method.  The pro for the dash method is you have more control over the operator and voting keys (which, we can expose in the future in our upgradesanc command, for more versatility).  The con is you have to remember to save those private keys in a file by yourself.  (In the case of a person who has a lot of sancs, the deterministic.conf might be convenient.  In my case, the deterministic was more useful for me to write a monitoring program to manage the sancs later - I need to loop through them and control them, etc.)

Great, we have 5 sancs now enabled!  We can start testing chainlocks pretty soon.
MIP, is yours up?

Have I forgotten to answer any questions about .14 other than making a test-list?

Btw, how did you lose your testnet controller wallet, was it a rabid animal, or a mad family member?

Hmm, my sanc has the external IP in the biblepay.conf:

Code: [Select]
addnode=testnet.biblepay.org
addnode=dns1.biblepay.org
addnode=dns2.biblepay.org
addnode=dns3.biblepay.org

rpcuser=XXX
rpcpassword=XXX
rpcallowip=127.0.0.1
rpcport=9998
daemon=1
listen=1
server=1
daemon=1
externalip=104.167.113.181
maxconnections=256
masternode=1
masternodeblsprivkey=XXXX

Not that exciting, I’m afraid. I thought each time in testnet we start from scratch so I didn’t pay much attention to the wallets. Anyway, I managed to resurrect the 239.200 as the VPS was still around.

107
Oh ok, yeah you can't spend the collateral then, so you cant free that node the easy way, right.

Well, anyway, the other way to do it is if you have the deterministic.conf file (this has the bls private and public key in it and the original pro-tx-txid), you could send a  ProUpServTx, (because sending a new pro-register-tx with the same IP results in bad-protx-dup-key error), but you could only do this if you had all the pieces saved from deterministic.conf (proTxHash, blsPrivKey) - see this section for future reference :  https://docs.dash.org/en/stable/masternodes/maintenance.html#updating-masternode-information


Well anyway I hope you have a Vultr Snapshot then you can rebuild without all that work.  Good luck.


PS: Can you please try the quick sync from zero when you rebuild so we can test that?

Set it up using the binaries from MIP and the quick sync script and it was fast and effortless! Used the Dash method from scratch (bit more complicated) and here it is...
 
Code: [Select]
"33ff087061fad94af7e4f1f73ff56af47f9b34e802cd845f5cf765b13944d453-1": {
   "proTxHash": "520ebc4e8fb36d335e89d3527c88e0096bb605983efbd339f78d17be12ce453e",
   "address": "104.167.113.181:40001",
   "payee": "yXhRHuA2YsV44K5VZJyQSxZurQ8s7diKbq",
   "status": "ENABLED",
   "posescore": 100,
   "posescoretries": 0,
   "posescoresuccesscount": 0,
   "lastpaidtime": 1564615177,
   "lastpaidblock": 182751,
   "owneraddress": "ygXsP7NRxDJtKKqRc2i1JXvxKZmXysYf76",
   "votingaddress": "ya5TqeZC7GRbibSzT8jbfHCLEQNTKT6LDL",
   "collateraladdress": "ydbZ7ppEEbq28Awyt2iQXTnM3JSn5fxKHF",
   "pubkeyoperator": "90856729abbe57866ec136e1505b59bf2fb5c399e04581df8264ba0ce49709cccd8c3e74c45ea1815e71572d602110c0"
 }

108
Hi Oncoa,

Nice hashes, so it looks like we are in agreement on that block hash (for your 3) plus mine.

As far as getting pose banned, you can get banned if:  Your masternodeblsprivkey does not match your deterministic.conf private key, or if you transmitted the same IP on more than one pro-tx, or if you are using the 'externalip=' setting in your wallet, or if your node is out of sync and acting strange in the quorums.  You would have to defer to the dash docs I pasted above for the rest of the reasons (as I am not familiar with the others yet).

If your not sure after reading this, I have found it is very easy to do this to recover:

Spent your collateral Tx in the controller wallet
Create a new public key for a new sanc
Create a new legacy sanc using the new address
Perform the upgradesanc command on it

I did that and Im chugging fine.

You can use the same address as long as you spend the old sanc funds first.  (Unlock them to spend them, spend them, then spend a new amount for the new sanc).

This would only happen in testnet but i lost / destroyed my controller wallet with my VPS and hence the collateral is locked and hence I cannot recreate the sancs using the same IP as you mentioned without spending the collateral which is not possible without the wallet!

I’ll have to destroy the VPS and recreate it with new A fresh IP and start from scratch. This might take awhile... sorry.


109
So can we get a little update from everyone on testnet, do you all agree:


getblockhash 180650
28383ec96296dbee95f45a0240cae97ef8ef06ff8fd3fe4e90552eb2cbe72d6e

Id like to see all 5 of our sancs in agreement before we talk about testing chainlocks.
I see my 3 non-pose banned sancs are in agreement.

MIP, Oncoapop we could use feedback - and anyone else that wants to test chainlocks.
Dear Rob,

I just have three VPS running in TESTNET. I did have one sanc but it is now banned, I have no idea how to get it unbanned. I restarted it to no avail. How does one get banned, other than not running bbp daemon?

Code: [Select]
{
 "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
 "service": "45.62.239.200:40001",
 "state": "POSE_BANNED",
 "status": "Masternode was PoSe banned"
}

The VPS is up and running and port appears to be open
Code: [Select]
telnet 45.62.239.200 40001
Trying 45.62.239.200...
Connected to sanc2.myseqtools.com<http://sanc2.myseqtools.com>.

mnsync status
{
 "AssetID": 999,
 "AssetName": "MASTERNODE_SYNC_FINISHED",
 "AssetStartTime": 1564531134,
 "Attempt": 0,
 "IsBlockchainSynced": true,
 "IsSynced": true,
 "IsFailed": false
}

If you want to check my machines, you can see the automatically polled hashes of my three machines at any time on:
http://oncoapop.sdf.org/biblepaytest/testnet_chainstate.shtml

They are pretty puny VPS  so one or more may be offline syncing or updating…

Cheers,
Oncoapop



110
Dear Rob,

Given your stressing the importance in testnet of the sancs testing of LLMQ (kindly remind me what this is again?), I have (surprisingly) resurrected one of my initial DIP3 sancs (just using old biblepay.conf and masternode.conf files left on the server WITHOUT the controlling wallet which I may have destroyed....), so I am hoping that it will be okay.

Let's test this to ensure, as far as we are able with a fraction of the network in testnet, we roll out a stable product in mainnet. Could you kindly help us to assist you in this by providing a checklist  (in simple layman's terms, please. Thanks  :) )  so that we can test specific aspects and report on.

Blessings,
oncoapop


Code: [Select]
{
  "outpoint": "51a7d0cdb93fb3377d274f1b448af3c260618eb23c145a52c6c2fc081192b4dc-1",
  "service": "45.62.239.200:40001",
  "proTxHash": "3fdfa35533185427856e07d7a966714d118c7434994b5d6a349c11558e79e290",
  "collateralHash": "51a7d0cdb93fb3377d274f1b448af3c260618eb23c145a52c6c2fc081192b4dc",
  "collateralIndex": 1,
  "dmnState": {
    "service": "45.62.239.200:40001",
    "registeredHeight": 65387,
    "lastPaidHeight": 171297,
    "PoSePenalty": 0,
    "PoSeRevivedHeight": -1,
    "PoSeBanHeight": -1,
    "revocationReason": 0,
    "ownerAddress": "yhDJCUZq19CVLiuDa4wEoY4PxWg17bZuTx",
    "votingAddress": "yhDJCUZq19CVLiuDa4wEoY4PxWg17bZuTx",
    "payoutAddress": "yRKdex8fFcDyjqx618Cz4hsQcQFjp55jRg",
    "pubKeyOperator": "05f58c1b79e898cf31a0375ded7a8e5bb6b0e5aacb48dc79f7c87e38eb0533bdf85c610cee5cf94b79c425c20f423cc4"
  },
  "state": "READY",
  "status": "Ready"
}

Again I notice that all the sancs appear to be "valid" although I know that only one of my sancs (45.62.239.200) is online and the other (64.180.194.238) is  not (see below). Would this affect the quorum if we have zombie sancs?

Code: [Select]
telnet 45.62.239.200 40001
Trying 45.62.239.200...
Connected to 45.62.239.200.

telnet 64.180.194.238 40001
Trying 64.180.194.238...
telnet: Unable to connect to remote host: Connection refused

111
As a side tip for anyone who is upgrading, remember you can do the 'exec reassesschains' if you end up at a lower height than us (it worked for me) due to LLMQ errors.

In the latest version I increased the LLMQ start height to 170,000.

Starting up LLMQ is much trickier (and dangerous) than I expected.

Since LLMQ drives chainlocks, the wallet is going to throw a bad block error, mark the block as dirty and put the wallet in a non recoverable state if it finds any block greater than 170,000 that is not in a quorum.

What this means is either the network has a lot of sancs, and a healthy quorum environment, or absolutely fails with a nightmare scenario.

This is obviously a decision Dash made to ensure there are no exceptions to the quorums once they are up and running. 

So in the current state of testnet, we would need to try to bring one more sanc on before 170,000 and see if a quorum forms, otherwise we need to keep increasing the LLMQ height.

What frightens me is if we start the quorums and then take down 70% of the nodes.  I think that means, we will need to regroup and bring the sancs back online. 

But from what I see, if lets say we lose those sancs VMs, and recreate them all, then the sigs will be new and the old quorums will be invalid (and I think that means a chain rollback).  We will cross that bridge when we come to it as our prod environment should be OK, as its always going to have for the most part more than 100 reliable sancs, so theoretically the quorums will never fail.

Dear Rob,

Given your stressing the importance in testnet of the sancs testing of LLMQ (kindly remind me what this is again?), I have (surprisingly) resurrected one of my initial DIP3 sancs (just using old biblepay.conf and masternode.conf files left on the server WITHOUT the controlling wallet which I may have destroyed....), so I am hoping that it will be okay.

Let's test this to ensure, as far as we are able with a fraction of the network in testnet, we roll out a stable product in mainnet. Could you kindly help us to assist you in this by providing a checklist  (in simple layman's terms, please. Thanks  :) )  so that we can test specific aspects and report on.

Blessings,
oncoapop


Code: [Select]
{
  "outpoint": "51a7d0cdb93fb3377d274f1b448af3c260618eb23c145a52c6c2fc081192b4dc-1",
  "service": "45.62.239.200:40001",
  "proTxHash": "3fdfa35533185427856e07d7a966714d118c7434994b5d6a349c11558e79e290",
  "collateralHash": "51a7d0cdb93fb3377d274f1b448af3c260618eb23c145a52c6c2fc081192b4dc",
  "collateralIndex": 1,
  "dmnState": {
    "service": "45.62.239.200:40001",
    "registeredHeight": 65387,
    "lastPaidHeight": 171297,
    "PoSePenalty": 0,
    "PoSeRevivedHeight": -1,
    "PoSeBanHeight": -1,
    "revocationReason": 0,
    "ownerAddress": "yhDJCUZq19CVLiuDa4wEoY4PxWg17bZuTx",
    "votingAddress": "yhDJCUZq19CVLiuDa4wEoY4PxWg17bZuTx",
    "payoutAddress": "yRKdex8fFcDyjqx618Cz4hsQcQFjp55jRg",
    "pubKeyOperator": "05f58c1b79e898cf31a0375ded7a8e5bb6b0e5aacb48dc79f7c87e38eb0533bdf85c610cee5cf94b79c425c20f423cc4"
  },
  "state": "READY",
  "status": "Ready"
}


112
cli -version
BiblePay Core RPC client version 1.4.6.0

cli getblockhash 168736
c317c3de030df7c215f39b8568e9065b71a9e8e16af8d1fff5a09809e1ad18cd

leaderboard
Code: [Select]
{
 "Prominence": "Details",
 "CAMEROON-ONE: yUNSEjjtC9pdeHp4spswdFWh1npfV5Jvqe [N/A], Pts: 0.00": "0.00%",
 "CAMEROON-ONE: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt [oncoapop1], Pts: 2667.00": "0.67%",
 "HEALING: yUNSEjjtC9pdeHp4spswdFWh1npfV5Jvqe [N/A], Pts: 0.00": "0.00%",
 "HEALING: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt [oncoapop1], Pts: 111670149.00": "0.00%",
 "POG: yUNSEjjtC9pdeHp4spswdFWh1npfV5Jvqe [N/A], Pts: 596289318.00": "65.00%",
 "POG: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt [oncoapop1], Pts: 0.00": "0.00%",
 "Healing": "Diary Entries",
 "oncoapop1": "Prayed for the salvation of the saints.",
 "Prominence": "Totals",
 "ALL: yUNSEjjtC9pdeHp4spswdFWh1npfV5Jvqe [N/A], Pts: 596289318.00, Reward: 537521.670": "65.000%",
 "ALL: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt [oncoapop1], Pts: 111672816.00, Reward: 5553.030": "0.670%"
}

(my VPS is too small for GUI, so have to reply on cli, sorry)
cli exec analyze 168736 oncoapop1
Code: [Select]
{
 "Command": "analyze",
 "Campaign": "Totals",
 "0": "CAMEROON-ONE|yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt|2667|0.00671502|oncoapop1|2668",
 "1": "HEALING|yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt|111670149|0.00000000|oncoapop1|111670150",
 "2": "POG|yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt|0|0.00000000|oncoapop1|596289319",
 "3": "",
 "Campaign": "Points",
 "0": "User: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt, Diary: , Height: 168733.00, TXID: fba1f5a89c130c8a1b20b822261c3bca93c732ced1b96c1e2d692c9f99bdec09, NickName: oncoapop1, Points: 2666.67, Campaign: CAMEROON-ONE, CoinAge: 56159643.2778, Donation: 0.0000, UserTotal: 2666.67",
 "1": "User: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt, Diary: Prayed for the salvation of the saints., Height: 168733.00, TXID: 82758735ba9c7f2b63a477f15f1bdb98b245ae1e61e20ca1fef8b982e572af91, NickName: oncoapop1, Points: 111670149.47, Campaign: HEALING, CoinAge: 111670149.4654, Donation: 0.0000, UserTotal: 111672816.13",
 "2": ""
}







113
On #1, yes, thats what I thought you meant.

Well on my end, I did see 7 sancs, but I was under the impression only 3 were really online (due to the exec health vote level), and Ive been synchronized with the 3 I hosted - as compared to my local node.

Lets try this, could you please upgrade and see if you agree with this hash:
getblockhash 166762
630a5075****  ?


If not we will have to figure out where the bridge is broken.
Since we know we had gobject propagation problems in prior versions, the bridge should mend after everyone deletes the banlist.dat.

I could see MIPs children when he did his exec sendgscc, so Im still thinking you were on a fork.

As far as more sancs, as long as we have 1 more join in we will be fine - lets hope when everyone upgrades we see 4.

Ok. I’ll upgrade and resync.

Before upgrade :
Block=168323
sa1-onc1.106.010=54875194410ba41d69b380a9537d9a77f22f0887ef2c1a807589ff412f87ac7f
sa2-onc1.239.200=54875194410ba41d69b380a9537d9a77f22f0887ef2c1a807589ff412f87ac7f

114
Please dont hesitate to ask if I missed something.
1) It appears you are out of sync (and that is understandable considering our last releases issue), but know that we have a mandatory upgrade now anyway (addressing LLMQ changes and prod->testnet changes, and a liesure feature), so dont worry about it.

2) Very excellent calculations!  I believe you are spot on the POG and Cameroon!  And that makes me feel good about our regression testing, that we did not break pog by adding cameroon.

3)  Yes, $1.33 per day for one child, always equals 2,666 points for two kids because Cameroon points are denominated in USD cents (thats just a feature to make it easier for us to quickly see how many children a participant is sponsoring when we see the future leaderboard).  Not sure if you know this but if you go to the UI, and click Summary, you can see just Cameroon totals. 

4) To see the governance superblock daily limit , type 'exec getgovlimit height' where height must be a correct %205 height (you can find a height from exec health).  For this example im doing a getgovlimit 166685, and seeing the daily emission is 872356.  The daily emission Is affected by QT, but note that in TestNet we temporarily have QT turned Off so it is 0% - However, note in testnet, since its deflation is far ahead of Prod (we have a 19.5% annual deflation), its daily emission is down to 872356 *without* QT while prod is something like 930K or so.

5)  You can actually calculate the owed amounts by multiplying the prominence % Owed * the Superblock gov limit, but note that in the version you were running, its very hard to see that prominence level without going to the leaderboard UI.  I fixed this in the next release.  In the next release when you type 'exec analyze
 height nickname' you will see a Totals section with prominence % per row.  In your case above, your cameroon was .0069% - so you got 872356*.0069 = 6019 reward.  You got 872356 * .64515 for POG = 562800  (Note that I might be off a little from your leaderboard figure above because I used a different payment limit height) but  - thats Not a problem because the numbers you posted above - the prominence totals do add up to 65% (why 65%) its because 30% is set up for Cameroon in testnet (50% in prod), 5% for healing, and the remaining 65% for POG.  The reason you capped out at 65% is because of our Cameroon Cap.  And you were the only participant on the fork so that means we know for certain you added up to the entire contract (because .64515 + cameroons .0069) added up to the pog cap + capped child amount.

6) The child emission rate of 6019 or 3010 per child is good - its a reverse engineered exec price to arrive at the BBP * satoshi midpoint to recoup $1.33 per day.

7) Yes, on your question, the #6, should 1 = 2 * 2, Yes, but only if we know the actual daily emission rate for that height; From your figs I think you got it - being off only by 100 bbp, but to make sure, in the next version lets do another one and all you have to really do to see that is click in "Details" in the leaderboard UI (if you run QT?) and just ensure you have 6020 bbp for the kids and the remaining amount in POG rewards.   

Thank you, Rob, for the detailed explanation which is greatly appreciated.

As for #1 - I meant : the command supplied was leaderboard true which just showed that I stopped all POG/gsc (and hence did not appear on the leaderboard) to ensure a clean slate for the testing...
 
A fork? Hmm, I waited to get both wallets to sync for a week and I checked to see that this chain had all 7 DIP3 sancs. I was pretty sure this was the main testnet chain. Anyway, the reason I have not been able to contribute any sancs is that my old DIP3 sancs could never sync on the same chain as the other sancs or my wallets so I gave up trying...

If desperately needed, I will have to set one up from scratch after you have determined the current issues have been addressed and it is time to test again.

115
cli -version
BiblePay Core RPC client version 1.4.5.9

1.   Begin experiment: Not in leaderboard
Code: [Select]
{
  "Prominence": "Details",
  "Healing": "Diary Entries",
  "Prominence": "Totals"
}
2.   Tithe normally
Code: [Select]

{
  "Command": "sendgscc"
}
3.   Leaderboard true
Code: [Select]
{
  "Prominence": "Details",
  "CAMEROON-ONE: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt [oncoapop1], Pts: 2667.00": "0.70%",
  "POG: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt [oncoapop1], Pts: 458746647.00": "64.03%",
  "Healing": "Diary Entries",
  "Prominence": "Totals",
  "ALL: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt [oncoapop1], Pts: 458749314.00, Reward: 535266.400": "64.730%"
}

3. exec analyze 167447 oncoapop1
[code]
{
  "Command": "analyze",
  "Totals": "CAMEROON-ONE|yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt|2667|0.00698158|oncoapop1|2668\nPOG|yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt|458746647|0.64029122|oncoapop1|465702655\n",
  "0": "User: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt, Diary: , Height: 167444.00, TXID: 6f6a7d7a447e8788ccce7b5fea3a1bc0dfcb844698afdc2f9b3a1d7c38f4049d, NickName: oncoapop1, Points: 2666.67, Campaign: CAMEROON-ONE, CoinAge: 130279453.0504, Donation: 0.0000, UserTotal: 2666.67",
  "1": "User: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt, Diary: , Height: 167445.00, TXID: 58e8fc4456674bb74ac30f7854fb6d73cf84ad7a74786e55cb499560ef16699e, NickName: oncoapop1, Points: 458746647.36, Campaign: POG, CoinAge: 239813460.8751, Donation: 7.0000, UserTotal: 458749314.02",
  "2": ""
}

4. POG + Cameroon1 calculation

CoinAge x (tithe)^1/3
239813460.8751 x (7)^1/3 = 239813460.8751 x 1.91293118= 458,746,646.6916889
Cameroon-one = 2666.67
Total = 458,749,314.02 (from leaderboard)
Total =458,749,313.36(calculated manually)

5.   cli exec sendgscc
Code: [Select]
{
 "Command": "sendgscc"
}
cli exec analyze 167474 oncoapop1
Code: [Select]
{
  "Command": "analyze",
  "Totals": "CAMEROON-ONE|yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt|2667|0.00698158|oncoapop1|2668\nPOG|yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt|476191731|0.64515645|oncoapop1|479766771\n",
  "0": "User: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt, Diary: , Height: 167444.00, TXID: 6f6a7d7a447e8788ccce7b5fea3a1bc0dfcb844698afdc2f9b3a1d7c38f4049d, NickName: oncoapop1, Points: 2666.67, Campaign: CAMEROON-ONE, CoinAge: 130279453.0504, Donation: 0.0000, UserTotal: 2666.67",
  "1": "User: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt, Diary: , Height: 167445.00, TXID: 58e8fc4456674bb74ac30f7854fb6d73cf84ad7a74786e55cb499560ef16699e, NickName: oncoapop1, Points: 458746647.36, Campaign: POG, CoinAge: 239813460.8751, Donation: 7.0000, UserTotal: 458749314.02",
  "2": "User: yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt, Diary: , Height: 167474.00, TXID: 88d8da4b97b2d11feb482dc5a026b619c4bde8c14a0379cbc9f662c9e557442c, NickName: oncoapop1, Points: 17445083.35, Campaign: POG, CoinAge: 9119556.1576, Donation: 7.0000, UserTotal: 476194397.37",
  "3": ""
}

6.   It appears that Cameroon-one tithe exhibits intended behaviour of not accumulating whereas POG does


7.   Fiat calculations (two commands instead of one previously)
Code: [Select]
cli exec dailysponsorshipcap
{
  "Command": "dailysponsorshipcap",
  "cap": 0.003489919543713683
}
cli exec price
{
  "Command": "price",
  "consensus_price": 0.000452465678,
  "qt_phase": 0,
  "qt_prior_phase": 0,
  "qt_future_phase": 0,
  "qt_enabled": true,
  "cur_price": "0.000437166531",
  "BBP/BTC": "0.000000045000",
  "BTC/USD": 9714.811799999999
}
1. $1.33 per child per day = $2.66 for two children =  2.66 / 0.000437 = 6,084 BBP
2. 950,000 (assumed daily superblock GSC contract value ) * 0.00349 (sponsorship cap) = 3,315 BBP per child (should be a bit less as I don’t know how QT affects the daily superblock – where can one find this out easily).
4.   POG calculations
a.   Total emission (from exec roi) = 537521.64
b.   My points = 476,191,731/479,766,770 = ‬0.99254 of POG
c.   0.99254 x 537521.64 = 533,516.2337349017
5.   My reward from leaderboard = 539289.730
6.   Therefore reward from Cameroon-One = 539289.730 - 533,516.2337349017 = 5,773 BBP

Sorry but it is still a bit off. I don’t know what I missed. Shouldn’t (6) =(1) = 2 * (2)?

116
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


117
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

118
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


119
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.






120
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?

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12