Published using Google Docs
FoldingCoin Off-Chain Distribution System
Updated automatically every 5 minutes

FoldingCoin Off-Chain Distribution System

Need

The FoldingCoin (FLDC) development team anticipate an increased folder participation rate due to our recent aggressive outreach. This has the potential to make our system of daily Counterparty payouts to individual folders too expensive in terms of BTC transaction fees. These fees are required for each transaction in order to get on the blockchain.

We need a system where we could calculate a folder’s FLDC earned in an “FLDC earning period” and credit these to a secure account on our FoldingCoin system. Then we would offer a system where the folder could do a withdrawal of their FLDC balance to their own Counterparty wallet any time they desire.

A bonus would be if the folder was responsible for their own BTC fee amount upon making the withdrawal. The fee for an individual transaction is small, but it is the aggregation of all these fees on the FLDC development team to self-fund that becomes prohibitive.

Available Technology

The FoldingCoin website is hosted on NameCheap shared hosting, running on a Linux-Apache-MySQL-PHP (LAMP) platform. We have developed our current payout calculator system on this platform and it has met our needs so far. We have 23GB of file space and 96 MySQL databases still available on the system for future uses.

cPanel Version        11.40.1 (build 20)

Apache version        2.2.27

PHP version        5.3.28

MySQL version        5.5.32-cll-lve

Architecture        x86_64

Operating system        linux

Perl version        5.10.1

Kernel version        2.6.32-531.11.2.lve1.2.55.el6.x86_64

Requirements

  1. Implement a secure account storage and password authentication system
  1. We favour integrating with a proven system. OpenID is one potential system that the FLDC team has looked at. Further research is needed.
  2. Two-Factor authentication (Google Authenticator) is a strong “nice to have”.
  3. “Forgot password” system for securely setting a new password (may come from the the chosen auth system)
  4. Store the following in the account database:
  1. FLDC Account Username/Identifier
  2. Salted password hash (according to the chosen auth system)
  3. Two-Factor authentication hash
  4. Real Name/Display Name
  5. Email address, for sending account updates, withdrawal statements and the like (may also be used for “forgot password”)
  6. Folding@home folder username, and whether this has been securely associated to their folding account (see below)
  7. FLDC balance.
  1. This requires research. Should it be a static number in an account? Or a ledger system where the balance is calculated dynamically based on debit and credit transaction logs? Each awarding period they get the earned FLDC amount credited to the account, and a FLDC debit upon withdrawal?
  1. Securely associate any Folding@home (FAH) folder username from any folding team on the Stanford network with a unique account identifier on the FoldingCoin system.
  1. This would be an improvement over the current system, where the folder has to be on a specific FAH team and use the Counterparty wallet address as their username.
  2. This would likely require cooperation and/or integration with FAH. At this time we do not have any inside knowledge of their system. Discussions are at a very early stage of determining what benefits our team could provide to the FAH team at Stanford University.
  3. There is a Plan B in case integration with FAH is not possible. We could implement a verification system where a folder would idle their systems for a specific time period after presenting their FAH user name. This would be a way for a folding user to prove to FoldingCoin that they control that folding account. Once “proof of idle” is attained, we would securely associate that folder name to a FoldingCoin Account.
  4. The thing we want to stop is any malicious member of the public going to Stanford’s public stats page, picking a folder with lots of computer power, and “stealing” that folder’s folding credits to get FLDC awards they are not entitled to. We need a way to know for certain that if you give a folder name, you are really that folder on the Stanford FAH network.
  5. The driver behind this requirement is that some of the prolific folders on Stanford’s network would love to earn FLDC, but do not want to give up their credits earned on their own well-loved username, and they have camaraderie with their existing team.
  1. Take a “Snapshot” of the Folding@home credits and record the current credits of all registered folders.
  1. FAH produces publicly accessible updates of folding at http://fah-web.stanford.edu/daily_user_summary.txt.bz2
  2. This is a text file with BZIP compression. It is a comma separated list of every folder that has ever folded, and all the credits they had ever earned up to the moment the file was outputted. The file is flat text in comma-separated format.
  3. Since it is a cumulative total, we must store our own day-to-day history, in order to know how many credits a particular folder folded in an FLDC earning period. We call this a “Snapshot”.
  4. To see our current snapshot code, you can view our Github: https://github.com/FoldingCoinNet/Calculator
  1. Calculate the total number of FAH folding credits folded by all registered folders in the FLDC earning period.
  1. This will determine how many FLDC to award per folding credit. A fixed amount of 500,000 FLDC are distributed per day.
  2. Divide 500,000 by the total folding credits to determine “FLDC per folding credit”.
  1. For each folder, determine how many FLDC they earned in this FLDC earning period.
  1. Retrieve how many folding credits they had in the current FLDC earning period.
  2. Multiply by the previously computed “FLDC per folding credit”.
  3. Record this FLDC award to the ledger.
  4. Move on to the next folder.
  1. There need to be strong measures to secure the database and FLDC balances against attack. This requires further research.
  1. Right now, we have not had onerous security requirements. We are not really “storing” anything of value. We just pay out the FLDC every day to public Counterparty wallet addresses, so there’s no storage of any confidential info.
  2. If we begin storing FLDC balances on our system, security requirements go WAY up. This is beyond the expertise of the current development team and outside help will be required.
  3. Need to protect against FLDC balance forgery, or withdrawal to an unauthorized Counterparty wallet. There may be other security requirements we have not thought of yet. This requires further research.
  1. Integrate an instance of counterpartyd with FoldingCoin’s system.
  1. This will be required to send the FLDC withdrawals to the folder’s Counterparty wallet when the folder requests it.
  1. Provide a GUI form to request FLDC withdrawal.
  1. It is at this point where the folder would present their desired Counterparty wallet address. It is debateable if we even need to store the Counterparty address along with their account, or if the folder would enter it for each withdrawal.
  1. Implement a logging system for folding credits, FLDC awards, and FLDC withdrawals.
  1. Allow the folder to view all folding credits in a particular FLDC earning period, and the associated FLDC award amounts and date/time.
  2. Allow the folder to view all FLDC withdrawal amounts and date/time that were done, and what Counterparty wallet address they were sent to.