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
61
sorry I sent the post prematurely. The CORRECT ratios are as follows:

TEAM           RAC       COINAGE REQD     RATIO
GRIDCOIN   6,023     1,116,115               185.3x
BIBLEPAY    9,569         149,679                15.6x

Output of exec rac
Code: [Select]
{
  "Command": "rac",
  "cpid": "xx003",
  "CPK": "xxb3d",
  "next_podc_gsc_transmission": 21217,
  "team_name": "Unknown",
  "external_purse_total_coin_age": 17926854.70136574,
  "coin_age_percent_required": 0.02855726425848298,
  "coin_age_required": 332673.380016672,
  "wcg_id": xxx83,
  "rac": 2826.58
}
{
  "Command": "rac",
  "cpid": "xxxaa5",
  "CPK": "xxxWPv",
  "wcg_teamid": 35006,
  "next_podc_gsc_transmission": 21217,
  "team_name": "Biblepay",
  "researcher_nickname": "oncoapop",
  "researcher_country": "CANADA",
  "total_wcg_boinc_credit": 4548281.74,
  "total_wcg_points": 31837972.18,
  "external_purse_total_coin_age": 20668208.12225695,
  "coin_age_percent_required": 0.0170824277899341,
  "coin_age_required": 146381.0915732143,
  "wcg_id": xxx773,
  "rac": 9406.974910000001
}

Team          Ratio
Gridcoin    117.69
Biblepay      15.56

Team info for team Gridcoin (and perhaps other team than Biblepay) not working.

62
BiblePay
1.4.8.4 - Mandatory Upgrade for TestNet

- Remove biblepaypool fields in getmininginfo
- Make PODC team configuration configurable by spork.  Allow any teams CPID to 'associate' or 'rac'.  Calculate the coin-age collateral req. exponent based on the config.
- Adjust DWS burn params for prod release.  Add DWS safety layer to double check rewards when the block exceeds the original base limit.  Require DWS rewards to be in the superblock if they exist.
- Enhance exec dwsquote 1 1 report to show a more consolidated report.
- Adjust Prod params to ready for mainnet release on Christmas

** All versions ready **

NOTE:  This version will also allow us to sync against mainnet, mine against mainnet, and verify the gsc passes in mainnet.  This version is theoretically the mainnet Christmas release candidate #1 (RC1).

Linux x64 testnet

>cli -version
BiblePay Core RPC client version 1.4.8.4

>cli getblockcount
21050
>cli getblockhash 21050
c050dc13103b96de932787ed502520654ea13ba013528ba10b39a97a63f67681

63
Yes, you are right, sorry, I just read what I wrote and corrected it to say "some".

Sorry, I apologize for coming across with that impression to you.

Actually to clarify, all of your support contributions have been very welcome and helpful in detecting, diagnosing, and solving the bugs we had over the entire duration of BiblePay.

Thank you for what you have already contributed.

Hopefully we will be working together in this endeavor.

I second what Rob said: your contributions are appreciated and acknowledged, Sunk And I am very happy that we will *all* be working together in bringing glory to our Lord and Saviour, Jesus Christ.





64
Very impressive!

Yes this looks like it matches what we would expect too!

Could you please keep us informed to tell us how well the Gridcoin CPID works out?  IE that its RAC gets reduced today but you still enter the leaderboard and then if you ultimately get paid?

Thanks!

EDIT:  Also, when you reboot your sancs on the new version, could you please tell me if they sync right up to the top block?

Let me post a hash:

getblockhash 19180
a1685482d58ba28526808dabe32b0794b8e5f72644b690bb35ff76bc6a48616b

Sorry, I had trouble with the re-syncing of two of those sancs following the recent upgrade. I had to delete the whole biblepay-evolution folder suggesting that there was some issue with the compilation which allowed me to start the wallet but somehow failed to sync after days... I have now just used the pre-compiled binaries and it is working fine as all of my testnet servers are at the top of the chain and can confirm your hash.

>cli getblockhash 19180
a1685482d58ba28526808dabe32b0794b8e5f72644b690bb35ff76bc6a48616b

Since one of those wallets that would not sync was my controlling wallet, I could not perform an update_service to the POSE_BANNED sancs which I have now done and as far as I can see all 7 sancs on testnet are ENABLED.

>list status
{
  "a46074dac98333269341fee5b712f795fdeaa615b276fee12175e1c537ce8a43-1": "ENABLED",
  "efbe80743321967f9d94b124b6670e3d87492e711f34acbe6fdada608007e055-0": "ENABLED",
  "24ba631e105c9f1d1923fe32d9c534e51556cddb15f625a5c42d5c902c868583-1": "ENABLED",
  "7570652f63502f29b610c4bf134f3d1d589c970c383b20a88545cd683c802130-1": "ENABLED",
  "7c30c4cf73a81ce8ebb90b3cd6bcda3c279d86fb044605b3f95f75a1657cd19e-1": "ENABLED",
  "c49f6f1e8fc8829b048abc37e790f4d6fc6364e05b9c433b77838ba575c15477-0": "ENABLED",
  "05a42edd711c8225b6febc0a422a0c8308dbd700d5ebd3b8af00571c7c5870d3-1": "ENABLED"
}

Finally, the Gridcoin RAC has been accumulating similarly to Biblepay RAC since the start of testnet PODCv2. I just noticed the higher coinage requirement and lower points on the leaderboard with the recent spork to add a higher requirement to gridcoin team members.

 






65
Code: [Select]
{
  "Command": "rac",
  "cpid": "xxx",
  "CPK": "xxx",
  "wcg_teamid": 30513,
  "next_podc_gsc_transmission": 19167,
  "team_name": "Gridcoin",
  "researcher_nickname": "xxx",
  "researcher_country": "CANADA",
  "total_wcg_boinc_credit": 509461.35,
  "total_wcg_points": 3566229.45,
  "external_purse_total_coin_age": 6501.996296296297,
  "coin_age_percent_required": 0.99,
  "NOTE!": "Coins must have a maturity of at least 5 confirms for your coin*age to count.  (See current depth in coin control).",
  "coin_age_required": 1116115.243997492,
  "wcg_id": xxx,
  "rac": 6023.073319
}

{
  "Command": "rac",
  "cpid": "xxx",
  "CPK": "xxx",
  "wcg_teamid": 35006,
  "next_podc_gsc_transmission": 19167,
  "team_name": "Biblepay",
  "researcher_nickname": "xxx",
  "researcher_country": "CANADA",
  "total_wcg_boinc_credit": 4457712.47,
  "total_wcg_points": 31203987.29,
  "external_purse_total_coin_age": 5410402.656666667,
  "coin_age_percent_required": 0.03766507675813258,
  "coin_age_required": 149679.2047890878,
  "wcg_id": xxx,
  "rac": 9569.592315
}

TEAM           RAC       COINAGE REQD     RATIO
GRIDCOIN   6,023     1,116,115               19.2x
BIBLEPAY    9,569         149,679               15.6x

sorry I sent the post prematurely. The CORRECT ratios are as follows:

TEAM           RAC       COINAGE REQD     RATIO
GRIDCOIN   6,023     1,116,115               185.3x
BIBLEPAY    9,569         149,679                15.6x

66
Code: [Select]
{
  "Command": "rac",
  "cpid": "xxx",
  "CPK": "xxx",
  "wcg_teamid": 30513,
  "next_podc_gsc_transmission": 19167,
  "team_name": "Gridcoin",
  "researcher_nickname": "xxx",
  "researcher_country": "CANADA",
  "total_wcg_boinc_credit": 509461.35,
  "total_wcg_points": 3566229.45,
  "external_purse_total_coin_age": 6501.996296296297,
  "coin_age_percent_required": 0.99,
  "NOTE!": "Coins must have a maturity of at least 5 confirms for your coin*age to count.  (See current depth in coin control).",
  "coin_age_required": 1116115.243997492,
  "wcg_id": xxx,
  "rac": 6023.073319
}

{
  "Command": "rac",
  "cpid": "xxx",
  "CPK": "xxx",
  "wcg_teamid": 35006,
  "next_podc_gsc_transmission": 19167,
  "team_name": "Biblepay",
  "researcher_nickname": "xxx",
  "researcher_country": "CANADA",
  "total_wcg_boinc_credit": 4457712.47,
  "total_wcg_points": 31203987.29,
  "external_purse_total_coin_age": 5410402.656666667,
  "coin_age_percent_required": 0.03766507675813258,
  "coin_age_required": 149679.2047890878,
  "wcg_id": xxx,
  "rac": 9569.592315
}

TEAM           RAC       COINAGE REQD     RATIO
GRIDCOIN   6,023     1,116,115               19.2x
BIBLEPAY    9,569         149,679               15.6x

67
Unfortunately, Dash took out the masternode version in the deterministic branch, so now we have no way to tell what version they are running.

I tried to put it back in 'masternodelist all', but it is actually missing everywhere in the code.

10-4 on the upgrade speed; Im pretty much in the same boat with my QT sancs, because I self compile and it puts a strain on this small hosting companies server.

One cannot tell the version of sanc other than if you are in control of the server running the sanc? I thought DIP3 the owner and operator could be separate parties. Surely one should be able to verify that information?

Also in the classic, when a sanc was on a different chain or offline, watchman would cause it to appear in a state other than ENABLED.

I still do not know how PoSE works on DIP3 sancs? Previously they were reported enabled when the servers were off. Then they began to be PoSE banned even though as far as i could tell they were on the same chain. Now even though the 2 sancs were clearly on a different chain, they appeared ENABLED when checked from the sanc on the main testchain.

68
I was not awake at that particular height, but looking at my 4 wallets (I have 3 sancs) they all agree with your getblockhash 18514.
So the height you mentioned - 18475 - thats right after the last GSC.

Was it just one of your 3 sancs that went out and required manual intervention, and after that, did all 3 stay in sync?

Yes, we really need to get to the root of this and prevent this entirely, it might require me adding a checkpoint and all of us doing some testing from a certain height forward.

2/3 sancs went on a parallel chain diverging at the block 18475, in fact both these appeared to be stuck on the previous block for some time after the two (1 sanc and 1 wallet) already accepted the block.

I left them till block 18514 to see if they will correct themselves but they did not and hence manually intervened to reassesschains.

All 3/3 sancs and the controller wallet have been in sync since block 18514.

69
Hmm, blockhashes appear to diverge from block 18475 on testchain. No intervention on my part.

at Block 18514,
exec reassesschains
wait for mnsync status to finish

>cli getblockhash 18514
1f280bd0f1bb8796980493b54ed71c7fb5f35d16400ad0e3f0bca7d774f5e93d

So all wallets are back in sync again.

70
Yeah, the issue is -erasechain=1 does not erase instantsend.dat.
So I added that into the next version.

Cool that you are synced now.

I suppose we need to find reliability in testnet before we consider this version to be stable.

Hmm, blockhashes appear to diverge from block 18475 on testchain. No intervention on my part.

71
Yeah, Im looking through the heights on my node that has 21 connections and everyone is at a different height, so its not the GSC block at all, it points to LLMQ and IX locks.

Unfortunately what it looks like is something like this:
Half of the sancs were forming their own version of the LLMQ quorum, so they have a different cache of IX locks.
The other half, has a different quorum.
The reason I can tell, is I found I can end up on a different height after erasing the chain twice, and, I can see what height some of the sancs are at by looking them up by IP.

This is interesting because it appears that the chain you end up on depends on which governance data you synced from.

So let me look deeper into the issue.  The answer is probably going to be marking a checkpoint block, and then ensuring our LLMQ all adheres to one chain after we upgrade.

This is much more complicated than plain old POW in bitcoin.

Thank you, Rob.

Whatever you did appeared to bring some stability to the network as sampled by my VPSs on the testnet chain, after deletion of instantsend.dat, exec reassesschains and waiting for mnsync status to finish.

currently, all my clients and sancs appear to be on the same chain

https://oncoapop.sdf.org/biblepaytest/testnet_chainstate.shtml






72
After deleting instandsend.dat, and restarting I can only get to height 18380 even after reassesschains.

I realized that I reported too soon... reassess got me to a higher height.

Code: [Select]
getblockcount
18380
cli getblockhash 18433
error code: -8
error message:
Block height out of range

cli exec reassesschains
{
 "Command": "reassesschains",
 "progress": 65
}
cli mnsync status
{
 "AssetID": 0,
 "AssetName": "MASTERNODE_SYNC_INITIAL",
 "AssetStartTime": 1574804204,
 "Attempt": 0,
 "IsBlockchainSynced": false,
 "IsSynced": false,
 "IsFailed": false
}

wait for sync to complete.

Code: [Select]
cli mnsync status
{
 "AssetID": 999,
 "AssetName": "MASTERNODE_SYNC_FINISHED",
 "AssetStartTime": 1574807022,
 "Attempt": 0,
 "IsBlockchainSynced": true,
 "IsSynced": true,
 "IsFailed": false
}
cli getblockhash 18433
5e76b6e223aafa7ceb64e7bf187454425ba7856828974f05d104ed41d07c4f9d
Getblockcount
18448


73
After deleting instandsend.dat, and restarting I can only get to height 18380 even after reassesschains.

Sorry i meant instantsend.

74
I find it very odd that we have 21 testnet nodes, all on the newest version I see.

This last release does not feel right.  After deleting instantsend Im getting different heights now on my sancs.

I'm dissapointed in the latest stable branch.  Right now we are running what Dash prod is running.
Looks like we need to dig deeper into the problem.

After deleting instandsend.dat, and restarting I can only get to height 18380 even after reassesschains.


75
Well although we lost some of the fields, I do think there will be alternatives to the same info for example we have to consider these LLMQ quorums are only supposed to work within the quorum group themself who are creating the quorum from the currently allowed protoversion (another words, after a mandatory, when I increase the minimum govnance version, only those sancs can participate in the LLMQ, so theoretically, the lower sancs would fall out of the quorum and get POSE banned).

But first could we check those two as guinea pigs that have the wrong hashes?  Id really like to get to the root of the problem so we can always blame it on one specific thing.  Up til today, I blamed a chain fork on failure to pass the last gsc height.  It was not til this version where I saw all these instantsend autolock failures.

Could you please try this:
On one, try 'exec reassesschains' and on the other, delete the instantsend.dat, then try exec reassesschains?  Lets see what fixes each one?

Don’t know how long I have to wait after reassesschains.

VPS1

Code: [Select]
cligetblockcount
18431
cli getblockhash 18431
7a28fc55fb6ac41d1987c2b93d093d8302526b63ef4a26ea67547aaeb895e14b
cli exec reassesschains
{
 "Command": "reassesschains",
 "progress": 11
}
cli getblockcount
18433
cli getblockhash 18433
5e76b6e223aafa7ceb64e7bf187454425ba7856828974f05d104ed41d07c4f9d

VPS2

Code: [Select]
cli getblockcount
18446
cli getblockhash 18431
3ee3f6e9dae4761c0f4f90707dd928bb5b336a470f9ca430f983bb54e48290f2
rm ~/.biblepayevolution/instantsend.dat

cli exec reassesschains
{
 "Command": "reassesschains",
 "progress": 69
}
cli getblockcount
18447
cli getblockhash 18431
3ee3f6e9dae4761c0f4f90707dd928bb5b336a470f9ca430f983bb54e48290f2
cli getblockhash 18433
b8b7e44b896afceda97a4bfa20c187db4ec582b61be6942028d096855ae0399f




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