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 - Rob Andrews

Pages: 1 ... 135 136 137 138 139 140 141 [142] 143 144 145 146 147 148 149 ... 263
2116
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"
}

Great on adding another sanc!

Yes, I will make a list; but know that I have no intention of moving towards prod til after we fully believe testnet and chainlocks are tested in and out :).

There are so many things we need to test after Prod transitions to deterministic sancs in 0.14 against prod.  We definitely need a list, and it will make me feel better when we not only test chainlocks in testnet, but LLMQs against the deterministic sancs in prod.

We will see the GSC gov data and votes in testnet after prod upgrades to determistic.  LLMQ will also be enabled in .13 in prod, but won't be enforced like it is in testnet.


2117
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

Well actually POSE gets enabled in tandem with LLMQ (long living masternode quorums).  So technically, when the 4 good sancs start forming quorums, they will start d-dossing the other sancs.  This will cause the other sancs POSE scores to increase.  Once they move to 100%, they will be banned and wont get paid.

The reason you see 0 for every sancs pose score is the LLMQs havent been forming yet.
I did ensure both the Dip and the LLMQ height were activated in testnet; so next I need to do some deeper analysis; Ill look today.

Let me know if you need more info on LLMQ other than this; you can read this and this should give you most of the info:
https://blog.dash.org/mitigating-51-attacks-with-llmq-based-chainlocks-7266aa648ec9

This too:
https://github.com/dashpay/dips/blob/master/dip-0006.md

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



2119
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": ""
}


Ok, I see you in the leaderboard now.  (See pic).  Both of us look OK.

Yes, I see your exec analyze 168736.  The issue earlier was my machine was stopped on a bad llmq block before your block so it was actually me that was out.  (I just checked in a new patch that allows us to sync from zero with llmq activated).

Looks like we still need another sanc, I think MIP had one, MIP is yours down?


2120
Ok. I’ll upgrade and resync.

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

Oh cool, well you actually agree with me (so the hash I posted in the last post should be correct for you also).

So the issue is we just need to see where your sendgscc went;  after you do a new one please post your new analyze height and Ill ensure I can see it.

EDIT:
Btw, you wont need to resync then.


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

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.


2122
BiblePay
1.4.6.0 - Mandatory Upgrade for TestNet

- Update LLMQ settings to account for our network settings
- Add one totals row per project to 'exec analyze height nickname' report to show total prominence % per project per user per day
- Merge Prod -> develop ratelimiter changes to guarantee gobject replication
- Add key 'changequantity=n' allowing the user to adjust the change output quantity
- Increment mandatory protocol version upgrade to force a mandatory upgrade on Sancs in testnet
- Add dip8 and chainlocks active flag to getblockchaininfo

** Mac and Linux still building **

2123
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)?

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.   

 

2124
Dip0008 is now enabled in TestNet and Spork_17 (DKG's for LLMQs) are now enabled.

This means the 3 existing sancs will now start making hourly (and daily) quorums.  They should technically cause quorum info to be written in the coinbase transaction.

We will be able to see the effects of this by monitoring POSE scores per sanctuary.  Technically, the sancs who are offline should start receiving POSE bans.

We may be able to barely make a quorum with 3 nodes in testnet as testnet requires > 50% participation of 5 (so that means 2.5 = 50%) and that means the hourly quorums would succeed, but I would still like to see a couple more sancs online in testnet for LLMQs and Chainlocks for quality testing.

Now we just need to verify the quorum data is written, the non participating nodes are banned (for a few days) then we can enable chainlocks.


From the Dash TestNet thread, testing chainlocks:

https://www.dash.org/forum/threads/dash-core-v0-14-on-mainnet.45821/

EDIT:  After reading all that I must say I feel a breath of fresh air here in our community as we have less infighting :), I'm glad Camosoul hasn't been posting here in testnet!



2125
One thing that is very dissapointing in testnet, is I see exec health shows '3' votes.  (I have 3 sancs).

Do we have anyone testing other than me?

We need at least 4 to test LLMQs.


2127
Ok understood. Tell us if you need to check anything else in testnet.

Lets check:
1) Have you received a regular single cameroon payment per superblock cycle (not more than one payment per cycle), and at least 1 (as long as you send at least 1 gsc per cycle)?

2) Send me a new child ID and an amount you want to pay and lets ensure you can kick another one in?
3) Lets ensure you get kicked out when you fail to pay also.

EDIT:  After church Ill check into the LLMQ punchlist.



2128
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 assume it will drift off, but Im not sure at what point.  Probably at the point of the next superblock if I were to make a wild guess.

One thing that might work is running 1.4.5.9 in 'litemode=1', if you really want to, but I think its probably futile until we lock in dip 3 in prod.

Can you please check on cameroon 1 in testnet again also?


2129
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


Well, thanks for trying.  Yeah, lets hold off on testing 1.4.5.9 against mainnet for a little while.

I make the assumption that we are banning other nodes in prod.


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


Pages: 1 ... 135 136 137 138 139 140 141 [142] 143 144 145 146 147 148 149 ... 263