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 2 3 4 [5] 6 7 8 9 10 11 12 ... 137
61
Production Proposals / Compassion - July 2019
« on: July 26, 2019, 09:37:07 pm »
We sponsor 55 compassion children @$2090.00 per month.
Seeking 1 mil.


62
Production Proposals / Cameroon One Installment 4 2019
« on: July 26, 2019, 09:16:17 pm »
We have 11 children with cameroon one, we have donated approx $2393 in 2019, and our annual due is $4026.00.

Requesting 2 million.


63
Production Proposals / July payroll (March) 2019
« on: July 26, 2019, 09:05:51 pm »
Commits on Mar 31, 2019
1.4.0.7d-TestNet mandatory upgrade  …

@biblepay
biblepay committed on Mar 31
 
1.4.0.7c-Testnet Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 31
 
1.4.0.7b-Testnet mandatory upgrade  …

@biblepay
biblepay committed on Mar 31
 
1.4.0.7-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 31
 
Commits on Mar 30, 2019
Merge branch 'master' into develop  …
 
1.4.0.6b-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 30
 
1.4.0.6-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 30
 
Commits on Mar 29, 2019
1.4.0.5 - TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 29
 
Commits on Mar 28, 2019
1.4.0.4-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 28
 
Commits on Mar 27, 2019
1.4.0.3-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 27
 
Merge branch 'master' into develop  …

Commits on Mar 26, 2019
1.4.0.2-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Mar 26
 
Commits on Mar 25, 2019
1.4.0.1d-Testnet RC  …

@biblepay
biblepay committed on Mar 25


Commits on Mar 24, 2019
1.4.0.1c-TestNet RC  …

@biblepay
biblepay committed on Mar 24
 
1.4.0.1b-Testnet RC  …

@biblepay
biblepay committed on Mar 24
 
1.4.0.1-Testnet Release Candidate  …

@biblepay
biblepay committed on Mar 24
 
Commits on Mar 22, 2019
1.2.0.1o-Genesis  …

@biblepay
biblepay committed on Mar 22
 
Commits on Mar 20, 2019
1.2.0.1n-Genesis  …

@biblepay
biblepay committed on Mar 20
 
1.2.0.1m-Genesis  …

@biblepay
biblepay committed on Mar 20
 
Commits on Mar 18, 2019
1.2.0.1l-Genesis  …

@biblepay
biblepay committed on Mar 18
 
Commits on Mar 16, 2019
1.2.0.1k - Genesis  …

@biblepay
biblepay committed on Mar 16
 
Commits on Mar 12, 2019
1.2.0.1j-Genesis  …

@biblepay
biblepay committed on Mar 12
 
Commits on Mar 10, 2019
1.2.0.1i-Genesis  …

@biblepay
biblepay committed on Mar 10
 
Commits on Mar 6, 2019
1.2.0.1-Genesis  …

@biblepay
biblepay committed on Mar 6
 
Commits on Mar 5, 2019
1.2.0.1g-Genesis  …

@biblepay
biblepay committed on Mar 5
 
1.2.0.1f-Genesis  …

@biblepay
biblepay committed on Mar 5
 
1.2.0.1e-Genesis  …

@biblepay
biblepay committed on Mar 5
 
Commits on Mar 4, 2019
1.2.0.1d-Genesis  …

@biblepay
biblepay committed on Mar 4
 
1.2.0.1c-Genesis  …

@biblepay
biblepay committed on Mar 4
 1   
1.2.0.1b-Genesis  …

@biblepay
biblepay committed on Mar 4
 
1.2.0.1-Genesis  …

@biblepay
biblepay committed on Mar 4


120 hours = $4800 - capping at 3 mil.


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



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


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


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


68
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 **

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

 

70
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!



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


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



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


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


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