Senior Project

View project on GitHub

To see the original version of this click here.


A generalized, peer-to-peer platform for programs like Folding at Home, which rewards users with micropayments for solving NP problems.


With the rise of distributed computing projects, from Folding at Home, SETI, etc., there is a distinct lack of standardization in their distribution methods. Because of this, anyone who wants to tap into this trove of information must design their own platform and market this to the world. It’s not surprising that it’s been slow to diversify.

Another problem is that clients have no incentive to run these programs, save for charitable inclinations. Until recently, it would have been next to impossible to provide an incentive. However, with the onset of cryptocurrencies, there is now an easy solution. If people are provided a reward for problems, they can gain a passive income for their idle resources. This becomes their incentive.

Design Goals

Because this platform will involve a great number of moving parts, and because it will be dealing with people's money, it is important that there is no central point of failure. While this may complicate things, it is very important to me that I make this platform as robust as I can before it is opened for public development. That means that it must be decentralized, flexible, and secure.

There are five attacks that I currently anticipate on this platform. Each of them must be addressed in its design, and throughout this proposal I will point out when they are.

  1. Mallicious user
    • This is a Denial of Service attack on the servers. By spoofing an active user (not solving the problems it is sent), an attacker could waste the money and processing time of the server.
  2. Mallicious server
    • This is a Denial of Service attack on the user and charity servers (one which does not pay). By spoofing a charity server, an attacker could send useless programs, which, for instance, add random sums forever. Such an attack would go against the wishes of the user (not contributing towards general research), and force real charity servers to provide payment which they may not be able to afford.
  3. Dishonest server
    • This is a Denial of Service attack on the user and platform. By broadcasting a bounty with a substantial reward, an attacker could trick nodes into wasting their computational time. This would drive up the general price of the platform, and possibly force it to a halt.
  4. Outside actors
    • It is very possible that an outside bad actor could misuse the platform. One such misuse could be hiring out a botnet.
  5. Bounty spammers
    • This is an attempt to overwhelm the user end of the network. If they spend all their time verifying incoming bounties, the network cannot function properly. This does not yet have a proposed solution, but is partly mitigated by actively requesting information and having a dedicated listener thread.


Because a client is allowing other people to run unknown code on their computer, there needs to be a way to keep things secure. This is possible by the use of a sandbox, making Java an ideal language for this platform. While this is less efficient than other languages, it builds a security solution into the network and client itself. This is a solution for the Outside Actor problem.

There will also be cases where one will want to run it in a bigger sandbox. Support for this type of operation is critical for companies like Intel, AMD, NVidia, and Samsung, which may want to test edge cases of their products in the wild. If everything is completely sandboxed, there’s no way for them to easily guarantee that they are getting to the correct devices. These use cases will be investigated, as they could make up most of the demand for this network. If they are feasible, a permissioning system will be used to select different security policies for each program.


A bounty is the mechanism by which one notifies the network of a new problem to solve. It is sent as an object with all the data a user needs to verify, prioritize, connect to the sending server, and select the proper security policy.

There are two tools used to validate a bounty. It comes with an object method to validate itself to the minimum definition, and there is also an external method which the user can change as needed. This allows a user to filter out the IPs of known attackers, or permissions that it cannot use.

The object verification method checks four things. First it checks if the IP address is in the valid IPv4 range. Second, it checks if the Bitcoin address is in the proper namespace (but does not check if it has enough funds until later). Next, it checks if the reward is in the valid range. Finally, it checks the timeout value. If all of these are valid, it propagates the bounty to its peers. This shallow check takes ~239μs to complete.


The Mallicious Server problem and Man-in-the-Middle attack forces an extra step for non-paying servers and relayed bounties (read: ones that were not sent directly by the issuer). In order to distinguish between attackers and genuine bounties, they must be vetted by a third party. This can be done by making a certificate authority. If a user encounters an unpaid bounty, the user will verify its certificate. It does this as follows:

In the worse case scenario (the bounty contains a certificate and signature, and is valid), this verification takes an additional 2.243ms. While this is by no means ideal, it is (as of yet) the best available solution. The certificate authority will be spun off to the overall Bitcoin community in order to keep some element of decentralization.

To request a certificate, click here.


Tests are a vital part of the network. Like there are ways for clients to exclude invalid requests, there must also be a way for servers to exclude inappropriate clients. They can do this with permissions, requirements, and small bits of test code.

Before the user follows through on a bounty, it checks the data['reqs'] and data['perms'] fields. If the user does not fit the desired client, or the server is requesting too large a sandbox, the user will not follow through.

This connection is made by sending a specified header, an instance of the Bounty object, and a dict of the client's system info. This allows the server to determine which test/query combination to use. After parsing this request, the server will send the test code.

The client sends the server the output of this code, and if it is correct, is sent the query.


After all of this, the query is finally sent to the client. Simultaneously, a payment channel is opened.

payment channel

This channel will be updated once per minute as long as there is an active connection between the server and user, and will grow at a linear rate until a result is achieved, but will never reach the full bounty until a result is submitted. This is to protect from fraud on both the server and user end. The server is protected in that the user has an incentive to stay online, and the user is protected in that the connection will expire if a predetermined time goes by without a result. This is a solution to the Dishonest Server problem.

In addition to this, the server can implement a flagging system. By making their program print a predetermined flag, they can request the user to send the following line to the server. This gives the server both an indication that the user is still working, and an estimation of their speed. This is a solution to the Mallicious User problem.

Upon closing the connection, the reward is distributed between the two parties in the way agreed upon in the last transaction broadcast. If a result is given, the full bounty will be delivered. The transactions are always broadcast with a lock-time of 24 hours.

Proposed Grading Scale

The project would be graded according to the following scale, where 1 point is 1%, and all points above 100 are discounted.

Goal Points Current
Network Communications 20 20
Port Forwarding (Linux, OSX) 5 5
Port Forwarding (Windows) 15
Peer Discovery 10 10
Execution of Bounties 15
Flagging System for Bounties 7
Working Paid Example Server 3
Working Charity Example Server 2
Coin Control 25
Certificate Authority 15 15
Rough GUI 5
Show Bounty Queue 5
Hide to Tray 2
Notifications 1
Additional Wallet Utilities 5
BIP32+39 Support (Hierarchical Deterministic Wallet + Pneumonic Backup) 10
Unit Testing 10 3
Max Earnable 100
Total 145 53



  • Java
  • pycoin
  • rsa
    • pyasn1


  • MiniUPNPc


Current Compatability issue tracking

Python 2.6 Python 2.7 Python 3.3 Python 3.4 Python 3.5 Pypy 2 Pypy 3

So Far

  • Basic networking capabilities
    • Send messages
    • Listen and respond (concurrently)
    • On a custom port, if desired
  • Encrypted communications (RSA)
  • Transparent settings storage
  • UPnP forwarding (Linux, OSX)

Working on it

  • Dedicated server mode
  • More complete bounty definition
  • More complete settings controls
  • Windows dependency fixes
    • MiniUPNPc (compile-time error)


  • Coin control
    • Payment channel
    • Secure wallet generation
    • Secure wallet storage
  • Sandboxed Execution
  • Seedless(?) network discovery

Open Issues

Submit an issue here if you do not have a GitHub account, or here if you do.