• Complete list of dependencies (python packages and other)
• Ideally on both linux (Ubuntu?) and windows
• Maybe move from Readme.md to wiki

The version of a code from a nanopayment whitepaper should be put into the repository and subaccounts contract should be written. All contracts must be tested in a Golem Private Network as soon as it will start to work again.
After that updated support for new contracts should be implemented in Golem.

• Implement SubAccounts contract.
• Create genesis block for test network
• Create mining/bootstrap node (aka server).
• Deploy SubAccounts contract.
• Implement direct payments.
• Implement subaccount payments.

setup.py has only "golem" package specified manually. It will not install subpackages like "golem.network", etc.

You can use setuptools.find_packages()
http://setuptools.readthedocs.org/en/latest/setuptools.html#using-find-packages

Describe what exactly should happen after timeout for task / subtask has been reached. Description should include both provider and requester scenarios.

Current code is in a Python 2.7.

Rendering tasks create sometimes temporary files, for example Blender task is creating "crop file" that describes a rendering window for a subtask. However there is still a problem with creating and naming a file that is platform independant - right now creating a temp file on Ubuntu generates a file named "" instead of random name.

Add support for UPnP to Golem.

Adding this option will eliminate the need to forward ports by hand for some users. Port forwarding is very uncomfortable process or sometimes not even possible for some users. Having it partially automated will significantly improve UX.

User should be able to choose if she/he wants this option or not. There should be additional flag in config file that would turn on/off this functionality.

We should check if there are any python libraries that support that. The most popular one in C (and used in all p2p application) is miniupnp.

Assumptions:

1. Resources that will be used in Golem Worldwide Renderer stands only for files and directories (with right hierarchy).
2. Resources for different subtask of the same task will often be the same, so the network should be prepared to send same set of resources to all computing nodes.

Extend and improve GNR interfaces:

• Python interface - a facade class.
• CLI interface - simple like python gnr-node.py. It should not import any Qt packages.
• Merge and clean up startup scripts: admmain.py, grandmmain.py, main.py.

Describe which functionalities should be available to users and which one are only for developers and testers.

Add new Golem task type with no external dependencies, to be used for testing. Should be customizable to allow different size of input data, output data and level of computational difficulty.

If this information is accessible user should be able to see from gui, why specific subtask failed. Was there problem with verification, timeout or user send error message? Right now we have to look for this information on golem console, log or by checking received files.

For tasks there should be a added subtask_id and delay_time as an argument. The name should be also changed from "accept" to "set down" or something similar. The result of this method is a delay value, not a boolean as a name is suggesting.

It's quite obvious that user should be allowed to cancel computation, ie. paid for previously computed subtasks, but don't accept any other providers issue.
What is not clear is that if there should be special broadcast method indicating that requester doesn't want to compute this task anymore and information about it shouldn't been kept and broadcast further. It may be useful for very long-standing task but generates some additional complexity.

Additional note: we should be sure that when requester decides to cancel task it pays for all remaining computation, ie. results for the subtasks that has already started being computed. Additional question: what should happened when we added redundant computation and some subtasks has been computed by some nodes but not enough to verify them.

Golem version of something like: https://stats.ethdev.com/

There used to be some manager applications but they are very old and probably aren't working any more with newer code.

Task_id is unnecessary because task knows it's own id. It should be replaced with subtask_id or list of subtasks_id which will give possibility to send different resources for different subtasks.

On wiki

Both Luxrender and Cycle allow GPU rendering:

• http://www.luxrender.net/wiki/GPU
• https://www.blender.org/manual/render/cycles/gpu_rendering.html.

Chosen virtualization platform should support OpenCL, is it possible for Virtual Box (or Virtual Box Guest additions)?

Right now there are no implemented methods for advance verificaiton on LuxRender. We canno use "part of a subtask" method from other task types. We probably should check luxcompare software that should does exactly what we require (PSNR check of flm files).

on wiki

on wiki

There should be possibility to run Kademlia's find node function to find a node address using only his id, so adding address may be redundant. On the other hand adding address may be quicker and reduce network traffic.

Read blog post and list of resources from Jeff Coleman. Write a short description and evaluate how useful those methods may be in Golem.

Describe what should exactly happen when we close Golem node and what should happend when we kill it. Should we write some data to database, kill computation on Virtual Machine, write some states, inform other nodes? Check which elements are implemented and add missing ones.

• First version
  Requestor broadcast his task with maximum price. All providers who can compute task for price lower than defined will be accepted. Final price equals to price offered by provider multiplied by computation time.
• Second version
  Requestor broadcast his task with maximum price. For some time offers from providers are collected. Finally the set of best providers is chosen. Function for provider validation should be take price, performance and reputation as parameters.
• Third version:
  Providers may try to cheat and declare too high performance and too high computation time. Therefore requester will try to predict computation time. Benchmark will be run on requester's computer to compute his performance and expected time. Based on this result requester will to predict computation time for each provider based on their performance. Provider will have to accept this time multiplied by declared price as a fixed remuneration for computation. For each subtasks there is defined timeout so there's no risk of computing a subtask forever.

We should control and fix timeout that are used in tasks. Mainly task timeouts and subtask timeouts, but also some other timeouts that may occur in code (eg. in task computer or task keeper for removing old tasks).

There are some additional important problems with that, ie differences with timestamps in different timezone.

How can we test network scenarios (at least simulate many nodes with different IP's)?

We have tried and made some test with imunes, but this topic is still open.

How to inform users about subtask progress? How to measure progress?
For Blender i Luxrender task we should probably monitor logs and find specific strings in logs.

When user is testing task and it takes a lot of time, he may close test window and try to test another task or test task again. He's not able to this, because test task directory is locked with another thread. Any solution for this problem will be appreciated.

TaskHeader should have additional field for signature. Otherwise there is a risk that malicious node may produce false task header directed to other node as a requester.

Integration with Ethereum protocols seems to be troublesome for now, but we may return to this topic later when p2p protocols will be improved.

Previously clients were identified by uuid called client_id. Then we have added identification by public key (called key_id). Task manager and tasks instances still uses client_id (for example to identify if a client has counted a subtask in that task already). This should be replace with a new method.

Interface that should allow user to see past and future payments.

What other methods should this interface make available? Should it allow to make payments before expected time? Should it allow to make see Ethereum account balance? Should it allow to send additional money to Eth account?

Allow user to send .flm files to Golem network and make other Golems to resume computation rather than start them from scratch.

How to propage tasks in Golem network.

Implement redundant verification from: https://github.com/golemfactory/golem-rd/wiki/Verification

First approach (abandoned branch) was here: https://github.com/golemfactory/golem/tree/redundant_computation

One potential approach is described below, but any other rational algorithm will be fine.

Algorithm proposal:
We define replication level x and consensus level c > x/2 and max tries m. Tasks send up to x copies of subtasks to different nodes and wait for the results. If c same answers is received the subtask is verified and all answers that are consistent with the consensus are accepted. If consensus is not reached within x subtasks, than additional m - x tasks may be send. If consensus is not reached subtask is marked as failed.
If consensus is reached before all x subtasks are send, then subtask is accepted.

Necessary changes:

• subtask verification may be delayed
• task should have num_subtask parameter
• total_tasks = m * num_subtasks
• task may be computed before total task number is reached

Add support for storing node/application data in user defined folder. E.g. --datadir=/tmp/test-node1.

By default it should be standard OS-specific "add data" folder. It can be queried using appdirs package.

• We have both computation_finished() and finished_computation() methods
• query_extra_data() should probably be changed to a better name
• Is there a difference between needs_computation() and get_tasks_left() != 0?

https://github.com/imapp-pl/golem/wiki/Verification

There are two issues for advance singular verification:

1. Is it always the random test rectangle draw in a proper way? Is it possible that it is too close to the border? What happens if chosen test rectangle size is bigger than a subtask area?
2. Some renderers settings may produce anomalies on the picture edges, for example one pixel on the edge of the rendered area may be much brighter that it should be. Identifie renderers and settings that produce such anomalies and propose better solutions for those.

Current performance test task was chosen for PBRT renderer (minilight). Maybe we should be choose different task, somehow connected with Blender?
Additionally test task should be connected with environment, not with global config?

Databases, internal lists, etc.

Implement resource transfer over IPFS, as a replacement for the current methods or as an additional method.

Build servers:

• Travis CI: easy config, old Python packages causes some build failures. DISABLED
• CircleCI: super easy config, works for free 👍
• AppVeyor: price from $29/m, Windows!

Code Coverage / Analysis:

• https://coveralls.io/
• https://codeclimate.com/pricing
• https://codecov.io 👍

Right now tasks output during computation is written to the console. It should be redirected and written to log files. Those log files may also be send back to the requester and be part of verification process.

Create docker image containing GNR compute node.

Docker image containing Blender might be a good starting point: https://hub.docker.com/r/ikester/blender/