How do you reliably calculate backpay for PoDC 2.0 when points on leaderboard is inaccurate?

How does one calculate backpay for PoDC 2.0 missing backpay?

If Points (RAC) on leaderboard for BBP is inaccurate, how could one accurately create the correct amount of BBP each miner is supposed to receive per day?

  • BOINC stats – look up RAC per day (snapshot) for WCG project only
    • – copy RAC per day
    • Is the data accurate? We can spot check
    • Does it really matter because what other reliable source of data do we have?
    • compare with free-dc at least to most recent to see numbers match up
    • compare with user.gz and team.gz from wcg stats directory to validate
  • Did the miner submit a sendgscc wcg transaction scheduled by BBP?
    • Look for BBP address on specific blocks (e.g. in exec rac look at “next_podc_gsc_transmission”: 169022)
      • Can we assume if auto was sent on block that it submitted enough coin age? yes
      • Do you count manually submitted sendgscc wcg? (Assume no in this exercise, out of scope).
    • Did the miner’s balance in the CPK have enough stake for the RAC they generated?
      • What team was the miner on?
        • team BiblePay = stake requirement ^1.3
        • non-BBP team (e.g. GridCoin) = stake requirement ^1.6
  • What was the payout per address on the smart contract reward block?
    • did CPK also participate in other GSC campaigns?
      • sakic – healing
      • oncoapop3 – healing
      • randrews – poom, healing
      • akkin4 – healing
      • porpoise – healing
    • WCG only? or can we count CPK to see if their name appears in others campaigns.
    • can we subtract prominence of other gsc campaigns to arrive at correct RAC payment target?
    • is a good estimate to take ratio of top WCG only earner like rubicon, capulo, talisman – then apply same ratio to other RAC only miners?
      • So, if the ratio is 100 RAC : 80 BBP, then apply same ratio to other RAC only
      • Track ratio per day and use that ratio to compare whether the payment of BBP to RAC matches
        • outliers would be multi gsc participants, but hopefully will be easy way to confirm 80% with 20% work

Good starting point is from 166070 (Christmas Dec 25) and as PoG ended and PoDC 2.0 definitely started.


1/12/2020 update

Import into Microsoft Access

CSV of WCG leaderboard

Make query grouping just cpk, bbp name, and cpk name


Next import all the payouts for the daily gsc reward.

ImportJSON of the specific txid for the daily gsc reward

block height gsc_tx
165660 bbaabbe708e6feb6d3bbd17a3e027ed4d4fb58e3b5bdb1ba676c060a7cf1e85a
165865 c2ff9bded809786c6b3a22e8eaaf663373854bd325cad2e73abca2039270be28
166070 578dd70f9a0aef1aa6e5380fdac91e9e4dae38a9f3f906298ed8e2a0efa5f005
166275 24e3d644dc66ca78479cff11b298779fb69959bb45d1d28b6fae0a2b6db65f92
166480 0088f9b2e0f70431cbcf4545371bfd7d7a154e0744218d39d925fee4f7722c4d
166685 54f77074e117f8718fbca0aa985a5b4ff7287a9226aadde892710631718f19c7
166890 af0186e1586e9272f059029bc29f353588d07878654882339ca3919239da284d
167095 51612ea49369218c924b7155d7fb6ba1cb984381bf396d7ac4437b17b38eaeb3
167300 cb0edc668a02028223de8356bc5d2a0ba608b6603b3fecbf062bb639969bc1e0
167505 fe53c67c62f28ae363d23c5bd0c5c1f639418e579e72c5b9fc92c0b9ebe2c197
167710 b8f2588d4eaea8572ba8bfdb549c3223518ac57d4111f1e73cf344d0265332ad
167915 31287ca380e76cbf4378b5fb55148a5bf7d899b57c1cd0a4df792cddbadc79ea
168120 65f008c815737e36c16e27874f81e2099e6aad861917cee2b6cd226ee2c602a2
168325 fd3fdb41af302bafc4ed230ddef9ca611b9e653751c59bc824cc6e74e24e6c9f
168530 797429ee1b2aea3b6da04052a2b2063671e9c852d5f807937905b7f7c306eea6
168735 315cb0f20da4d854fb4140bb80abca0cc57aac702ce3d1064714d6179c2c3014
168940 c595235089245b33ebf541e0e29e7e83a391db28b0a9b2eae7a573ea08635325
169145 7c9c13eb0a7ae68ad91b6cd56c4705d2b5489f3e579ef518166ba85855d18d39
169350 6bee9253f9f5a91c676c8aaa98a2a01ff87a3bd738627fadef25743c98a5df6e

import the json data into microsoft access


import user.xml per day into access (user0104.xml to user0111.xml)

still need run a query that retrieves only the relevant cpid from christmas to present (01/11 should be okay).

make a table called user from the filtered list, this is what will be used for the analysis. linked tables is convenient but will slow down performance.

get the gsc daily payment and figure out an offset that works with the data

there’s no median function that I can really use. I may have to just code it in based on the bbp to rac ratio that is calculated in general. must exclude the high ones (randrews, sakic, sunk (some days) because of multi gsc). need to see the tx for specific blocks how many gsc they sent to.

for each day, figure out the ratio:

1/4 0.8
1/5 0.8
1/6 0.67
1/7 0.65
1/8 0.7
1/9 0.66
1/10 0.72
1/13 0.62

4 Jan 2020 = 0.8

5 Jan =


Get stats from boincstats

it doesn’t go back far enough for grc feed or getting from wcg boinc stats download now

get chart.json from boincstats for each cpid

assume that each cpid sent enough stake per day

barton26 didn’t send on 1/12 but his name wasn’t on the leaderboard, so you can’t even rely on tx being sent on a specific block to be correct

you can only use who was paid, how much, and who should have been paid instead and re-do the payment for each day.


wcg.rac is

Thu, 16 Jan 2020 22:19:09 GMT

RAC 1/16/2020 – 2PM Los Angeles

PAYOUT 1/17/2020 – 9PM

offset is 1 day and 7hours? 1.5 days?


updated qryRACpts5

added staticratio and calcratio (bbp_amount / rac).

created bbp_rac_ratio static table. took the dynamic range and decided on a static ratio.

any out of the staticratio range are likely multi campaign (randrews, sakic). not sure how to split them out. i don’t think they need to get adjusted payment.

still issue with people who did not submit gsc tx on a specific day. there is no pay day entry, but should be there…