What if a piece of code can replicate itself autonomously and earn you money, in the form of bitcoin, on autopilot?

You want the latest news about Crypto?
Then follow us on Google News!

During the development process of TENNET (the Tribler Exit Node Network), a decentralized autonomously operating agent, that is capable of generating money online via providing a Tribler exit node service, was created.

Tribler represents a decentralized open source torrent client, that promotes anonymous P2P communication by default. It is based on BitTorrent’s protocol and utilizes an overlay network to enable content searching, which allows the program to function independently of other websites and shields it against external manipulation e.g. government censorship.

A Tribler exit node is a special service utilized by Tribler in order to be compatible with torrents. TENNET will operate this exit node on a server. Then, it will sell (whatever comes down to) Tribler’s uploading capacity for bitcoin. The earned bitcoin will then be used to purchase a new Virtual Private Server (VPS) and then the exit node code will be installed onto it. As such, the cycle will continue on autonomously, which will yield a decentralized network of Tribler’s exit nodes.

During the process of development, multiple prototypes were constructed and several tests were conducted:

  • The first prototype: buying a VPS and then installing a brand new bitcoin wallet onto its server via a fully automatic process.
  • Long term exit node test: running a Tribler exit node on more than one server to monitor how they will perform on various servers.
  • The second prototype: via a genetic algorithm, the prototype buys a server from a selected group of VPS providers and then installs the agent along with a bitcoin wallet and the code of Tribler’s exit node, after which all these services will be started.
  • The Third prototype: this represents the finished product that is capable of autonomously replicating and making money online, and has all the functionalities of the second prototype.

An overview of the agent’s life cycle:

Due to the fact that the main goal of our agent is to create an autonomously functioning and replicating code, it is pivotal to consider how the agent’s life would be; how it is going to sustain itself and in what way it is going to thrive to allow it to replicate efficiently.

The below figure illustrates how the lifecycle would be. It will begin at the “Living out the server lifespan” box, at which the agent would know its amount of time left on the server, and would also know that to continue living for another cycle, it will need a certain amount of money, in the form of bitcoin, to pay for the upkeep of the server.

The client would set up a group of Tribler exit nodes that can build up a reasonable seed ratio that could be sold for bitcoins. Accordingly, as the agent has lived a portion of its lifespan, it can view the amount of money it has earned. Then, it can determine which server to buy afterwards, install itself onto it and thus, begin a new lifecycle. If the agent has a large amount of bitcoins in his/her wallet, he/she can choose to buy an additional VPS and install another child onto it.

More recently, Tribler added multichain to its code at production level. Multichain represents an effective decentralized bitcoin-like means for registering the upload/download ratio of clients across the network. Due to the fact that having a high upload/download ratio, could be linked to, in the future, being more favorable to upload to, this multichain could be possibly viewed as a new form of currency which can be utilized to indirectly sustain the agent, provided that it can be exchanged to a currency that permits purchase of new servers, such as bitcoin.

The developers of the client found out that using Docker can markedly improve the functionality of the system. Docker executes its programs within virtual environments which guarantees that whenever Docker is working successfully on a system, and the program is working successfully on Docker, it will then work on all other Docker systems. In the beginning, integrating Docker seemed unnecessary, yet when implementing more than a single VPS, it seemed that even though 2 VPSs can run the same version of an OS, they could still behave differently. Nevertheless, if Docker was integrated, the developers would have only had to focus on getting Docker to operate successfully. Due to the fact that the automation code would always work, since it is running via Docker, this would yield a more stable environment to experiment on.