Hi, I just wanted to take a moment to give an update for grcpool.com. There have been quite a few things going on, and of course much to keep working on.
V8 Staking
The big news with Gridcoin is the V8 Staking has been implemented since block 1,010,001. A component of the upgrade was to remove magnitude from the equation in regards to staking ability. In other words, wallets that have a big magnitude, such as the pool, have to rely only on balance to stake rather than a combination of balance and magnitude. Therefore, this change could impact the pool by reducing its ability to stake as often as it previously was. After V8 went into place, pool 3 did not stake for about 3 days, while pool 1 and 2 started staking somewhat normally.
I decided to take this opportunity to change the way Gridcoin clients work with the pool in order to achieve more flexibility and security. Before the change, there was a single wallet on the server which held a base amount of coins, any staked coins, and also handled the payouts. Now there is a hot wallet which resides on the server and only holds the coins which are owed to the pool members, fees, and donations. The staking wallet is maintained on a different server and contains the seed coins and recent coins received from staking. When coins are received from staking in the staking wallet, the balance above the seed amount are moved to the pool’s hot wallets and owed amounts are re-calculated. I have doubled the amount of Gridcoin in the staking wallets to 200,000 GRC for each pool in order to increase their chances of staking. I’ll be keeping an eye on the staking timing and making adjustments as needed as I would like to keep daily payouts going.
Open Sourcing
Open sourcing the pool is a continued work in progress. There are now two official GitHub repositories for the pool. One of them is my personal GitHub and the other is the Gridcoin Community Github. Each repository serves a different set of code. I felt as though grcpool.com will continue to grow and become more complex in ways that a person solely interested in running a GRC pool might be inhibited by its functionality. So the Gridcoin Community GitHub will contain some basic core code to get a pool running, while my personal GitHub repository will reflect what is on the grcpool.com site. Therefore, the Community repository should be the focus for anybody that really wants to contribute to the core code for collaboration.
Pool Growth
Pool growth is still continuing to climb with new memberships and active members. With three pools now, there has been no issues regarding the magnitude cap so far. My current plan is to try and balance the pool’s so their magnitude is the same between them. There is still a proposal to have the cap raised to 32k in the future.
SPARC
I have received many inquiries regarding SPARC, Science Power and Research Coin. If you are in the pool, you are currently dual mining Gridcoin and SPARC, depending on the project. SPARC is being distributed about every 1-2 weeks. After the token is available from the SPARC network, I have been moving the SPARC to an Ethereum address for each pool with a wallet located off site.
Pool 1: 0xbe7191f56918c3d8c6df199663b74b0ff9e7b1b9
Pool 2: 0x897dddb94e33956ff159f4a501df460a91a157c5
Pool 3: 0x09dfc7deb08fd86a4d59b65fc6cf562ee10da529
Then there is a manual process of entering the SPARC generated for each project into the pool database. An automated process picks up the new amounts and generates amounts owed based on the RACs within each project separately.
I discovered in a recent audit of SPARC there were some misallocations in the amount owed. SPARC is not tied to the Gridcoin whitelist, and when the first amounts owed were calculated, the Gridcoin network whitelist and owed calculation was reused for my ease in distributing a single sum for the week, much like when a POR is received. Making this correction means manually entering in the individual SPARC amounts for each weekly payout (20+ projects x 3 pools) until SPARC can provide an API.
I would expect all members to see a change within their SPARC owed when the redistribution occurs as the amount owed will be generated specifically based on individual project data and the SPARC whitelist. Crunchers on projects STZAKI, Yafu, and Enigma will be heavily impacted due to the whitelist mismatch. Even though STZAKI is not in the Gridcoin whitelist, there appears to be many pool members still crunching on the project. Therefore they should receive their SPARC but of course cannot receive any Gridcoin. Then on the other hand, crunchers of YAFU and Enigma should receive Gridcoin but not any SPARC since those projects were not in the SPARC network. The projects status page has been updated to indicate SPARC enabled projects to clarify this confusion. If you want to have items added to the SPARC whitelist, you should contact the SPARC team.
“This project may not be attached correctly or needs to be synchronized from your client.”
Every pool member will receive this warning message at one time or another. Usually this message occurs when a new project is added to the pool as it waits for the BOINC client to contact the pool. It takes two successful synchronizations with the pool for this warning message to be eliminated. This is because during the 2nd synchronization with the pool, the needed data from the BOINC project site is passed into the pool so it can match up the hosts credit with the owner. Therefore, this message should not be taken lightly if you expect to be earning Gridcoin on a specific project where the message is occurring.
Recently, a new scenario has emerged where you could see this warning message as it relates to the need for the pool to blacklist certain hosts. As the pool membership has grown, there has been an occasional collision of network MAC addresses which cause the BOINC projects to issue the same internal ids to different computers. When the hosts connect to the pool, they appear to be the same host since they carry the same BOINC id. When this happens, the pool refuses the 2nd host since it appears to be a duplicate. Therefore the 2nd host will be unable to resolve the warning message and will not be able to receive any Gridcoin. This process so far has been working, as pool members in this scenario have been able to resolve the situation by obtaining a new MAC address and synchronizing with the pool, usually after contacting me.
A pool member recently contacted me with an issue where the amount owed to him was reduced without receiving a payment. Upon further investigation, it was discovered his credit was given to another pool member and paid out. What had happened is the BOINC project which had the conflict (after about 6 weeks) issued a new id to the original host. Then when the 1st host contacted the pool, the pool saw it as a new host and created new records to match the BOINC feed. At a later time when the 2nd host contacted the pool, it was able to assume the credits of the 1st host as it now appeared there was no duplicate. This is not limited to the pool, as now in the BOINC network, the 2nd host has assumed the 1st hosts credits and identity. To resolve this scenario within the pool, the pool now detects when the id of a host changes in this manner and will blacklist the host past BOINC id making it unavailable for a 2nd host to assume it. This does mean any existing credit by the 1st host will be reduced in the pool while the 2nd host will be generating credit within the pool on the 1st host's BOINC id still. However, since the host id is blacklisted, the warning message will persist for the 2nd host, and no amount owed will be generated. Currently, manual intervention will be needed to resolve this rare issue. I paid the pool member the Gridcoin that he was missing from this BOINC issue. Again don’t disregard the warning message if you are planning on getting Gridcoin for a project which it appears.
...
I appreciate all of the communication from the Gridcoin community. As always, please feel free to reach out to me via email or slack teamgridcoin.slack.com 
