Some BiblePay PoDC 2.0 miners are not receiving full payment.

Update 11 Jan 2020 – PODC 2.0 Bad transmission amounts – missing payments

Rob said

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

image

<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:

wcg-leaderboard.csv

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

https://docs.google.com/spreadsheets/d/e/2PACX-1vR2jzcVvyuQWbQ095L3McdKt54R-BPkYFggMGvY4WL19AfKcYj2H7Al5T1fg7osybuSWFK64kjXzqi3/pubhtml?gid=0&single=true

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.