Update 11 Jan 2020 – PODC 2.0 Bad transmission amounts – missing payments
** PODC 2.0 Bad transmission amounts – missing payments **
So the lion’s share of the problem has been corrected related to bad gsc transmission stake amounts and missing payments (for all those who have enough collateral in the wallet).Please restart your baseline from today if you missed a payment or had an invalid transmission.
The only issue we have left with PODC 2.0 is for those who don’t have enough collateral; the wallet does not reward the correct amount of RAC in that case in the leaderboard. The problem has been corrected in the current version, but we have not required a mandatory sanctuary upgrade yet (hence the code is not running in prod yet). I believe we will roll this out towards the end of the month.
Points issue
Some users that are currently crunching science tasks are reporting that their RAC (recent average credit) that should show up in the Leaderboard under the points column are showing with reduced points.(( Point is the same as RAC. Some users such as barton26 and bbpminer4 have reported dropping off the leaderboard entirely. I’ve verified that in some versions of wcg.rac their CPID is missing from the file.)) Some have said this happens when your BBP required stake is less than what is required. The formula for a BBP team member is ^1.3 BBP required per RAC.
For team BiblePay the stake requirement is ^1.3 per RAC
For non-team BiblePay The stake requirement is ^1.6 per RAC. The only two PoDC 2.0 members currently on non-BBP team is pollux (GridCoin) and barton26 (GridCoin).
| RAC | Exponent | BBP Stake Required |
| 1,000 | ^1.3 | 7,943 |
| 10,000 | ^1.3 | 158,489 |
| 1,000 | ^1.6 | 63,095 |
| 10,000 | ^1.6 | 2,511,886 |
Boring geeky analysis
Corrupt SAN\wcg.rac file
There’s bad data in the wcg.rac
There’s repeated string values 1000 in the file which may be causing parsing errors.
Based on my observation, I think when user.xml is being processed, it lands in our biblepay san/wcg.rac as a corrupt file.
For example:
oncoapop3 showed a RAC of 171000446.350588 on 7 Jan 2020.
It should have been 17446.
and the wcg.rac file was encoded partly as having line endings with CR only (macOS) as line ending.
He worked around the issue by restarting the server. I think quitting biblepay, erasing wcg.rac in san folder, and restarting biblepay will also work
Screenshot of wcg.rac area that shows problem 1000 string
<user> <id>1072773</id> <name>oncoapop</name> <country>CANADA</country> <create_time>1533274493</create_time> <total_credit>4958657.778454</total_credit> <expavg_credit>17 1000 446.350588</expavg_credit> <expavg_time>1578311975.659187</expavg_time> <cpid>168c62b82fb40fa3db0d34605439daa5</cpid> <teamid>35006</teamid> </user>
As the contents of wcg.rac changes (users added), where the string of 1000 falls changes
In performing my analysis, I took the output from leaderboard from the debug console:
I ended up creating a CSV file and importing it into Microsoft Access:
From there, I downloaded the BOINC statistics files from World Community Grid:
https://download.worldcommunitygrid.org/boinc/stats/
I downloaded user.gz and team.gz to join the various fields.
I joined the data to show the leaderboard with their respective user and team stats.
For the most part, most of the users “points” lined up with “expavg_credit” (RAC) as they shoud.
Some though — about five users — showed less points then they are supposed.
Some have tried to explain this away by saying they did not have enough stake.
So, even that I compared and only included those that had enough stake and where the leadership points and BOINC RAC had a variance greater than 10%.
That only led to about five users that fit all the criteria set forth.
| cpid | bbp | cpk | points | prominence | expavg_credit | teamid | name | create_time | user_joined_wcg | CPK_balance | StakeRequired | HasEnoughStake? | StakePercent | PointsVsRACVariance | CheckCPK |
| c3939b61e69c6bde1eddb06708e0f96e | BLENRYgVPwzfsrJoJNbvC537qMHsCVyeFU | Sunk | 5714 | 0.49 | 74799 | 35006 | BiblePay | 1525970298 | 5/10/2018 16:38:18 | 2,420,813.4 | 2,168,026.2 | yes | 111.66% | -1209.05% | CheckCPK |
| 70e573f0fa03b83de2c55dd0e407176b | BNqyKkxVcx4njCqUZ7f9yq8ranXq8zV8sx | w2m_15 | 141 | 0.01 | 621 | 35006 | BiblePay | 1577817542 | 12/31/2019 18:39:02 | 5,978.3 | 4,275.8 | yes | 139.82% | -340.43% | CheckCPK |
| 4bda4ec72734ca376ac70b71cd656de9 | BLEiLrEnHkjjPyjYJGW4LCHke8gEobmfDM | xxburg | 80 | 0.01 | 300 | 35006 | BiblePay | 1578264357 | 1/5/2020 22:45:57 | 4,108.7 | 1,660.6 | yes | 247.43% | -275.00% | CheckCPK |
| 9f184b91bc1fca221f3365297396179d | B6BCPhgqbmt5FpmsKMTMePtBSxFaMZy4XF | BBP_NICKNA | 76 | 0.01 | 274 | 35006 | BiblePay | 1577680226 | 12/30/2019 4:30:26 | 1,699.1 | 1,476.0 | yes | 115.12% | -260.53% | CheckCPK |
| c3ded44e062bd53de3fef22be5302fab | BCtEy4v3orgsXTVbjYPe66pWAxsgjhMqpY | sf7kkn99 | 1538 | 0.13 | 1718 | 35006 | BiblePay | 1577576474 | 12/28/2019 23:41:14 | 18,791.6 | 16,052.0 | yes | 117.07% | -11.70% | CheckCPK |
Transfer-Encoding: chunked
The hex value of 1000 in decimal is 4096. That is exactly how much bytes the chunks are in. This appears to be why the 1000 string is in the wcg.rac file.
It seems the wcg.rac is the raw output from the web server. The beginning of the wcg.rac file has the HTTP header.
Kestrel is web server implementation in ASP.NET Core.
| HTTP/1.1 200 OK
Date: Fri, 10 Jan 2020 14:02:45 GMT Server: Kestrel Transfer-Encoding: chunked Expires: Fri, 10 Jan 2020 14:32:45 GMT |
From: https://ec.haxx.se/http/http-response
When sending a chunked response, there’s no Content-Length: for the response to indicate its size. Instead, there’s a Transfer-Encoding: chunked header that tells curl there’s chunked data coming and then in the response body, the data comes in a series of “chunks”. Every individual chunk starts with the size of that particular chunk (in hexadecimal), then a newline and then the contents of the chunk. This is repeated over and over until the end of the response, which is signalled with a zero sized chunk. The point of this sort of response is for the client to be able to figure out when the responses has ended even though the server did not know the full size before it started to send it. This is usually the case when the response is dynamic and generated at the point when the request comes.