autonomous self-replicating code

[synctext]

Goal: creating healthy exit-node network through cybercurrency.

Previously a TUDelft thesis project created an initial implementation of the autonomous self-replicating code concept.

next step: go live

Key features:

• earn cybercurrency using the Tribler blockchain
• provide Tor-like exit node services
• unpermissioned open compute API in Python (Scrapy, urllib2,BeautifulSoup,lxml,..)
• post births and life events on Twitter
• sell Tribler credits for Bitcoin on open market
• auto-buy-bot
  • provide initial market liquidity
  • automagically buying Tribler credits
  • create healthy exit-node network of 25+ servers

Planning:

• 2 week sprints
• 1 chapter of documentation per sprint
• Week 1-2 focus: initial experiment: Selenium, Singapore server, Dispersy community
• Week 3-4 focus: open compute API? (light-weight, fast, robust, high-volume support)
• Week 5-6: earn, sell, and buy?
• Week 7-8:

Include in the report a detailed analysis of why the previous code could not be re-used and why clean-slate implementation was started.

[thijmensjf]

As our cycle in the project is ending, we will provide a final status update regarding the project.

First of all there is a final version of the report, which can be found here

The slides of our final presentation can be found here

All in all it can be concluded that PlebNet is working end-to-end now, which is demonstrated in the following videos.

stage 1 - initialization of a agent stage 2 - create an offer on the market stage 3 - buying a new VPS via cloudomate stage 4 - replicating on a new instance monitoring via the IRC

[synctext]

Official TUDelft repo of thesis (has link to .pdf)

[synctext]

Related work: "Mitogen is a Python library for writing distributed self-replicating programs."

[devos50]

This ticket will be used for the upcoming software project, starting this Monday. Project description (locked in ProjectForum):

The goal of this Bachelor end project is to create a Bitcoin-based entity which can earn money, mutate, multiply, and dies. We provide a crude starting project which needs decades of further work in order to be considered 'really' living. This project builds upon existing code that creates autonomous life. Two previous groups have worked on this system and their documentation can be found in the TU Delft repository (see here and here). Recently, two groups of master students have expanded the project.

You will create an Internet-deployed system which can earn money, replicate itself, and which has no human control. In the past, humanity has created chess programs that it can no longer beat. The distant future of an omniscient computer system that on day chooses to exterminate humanity in the Terminator films is not the focus of your project. You will create software that is beyond human control and includes features such as earning money (Bitcoin) and self-replicating code (the software buys a server and spawn a clone). Earning money consists of helping others become anonymous using the Tor-like protocols developed at TUDelft and our own bandwidth token designed for this purpose, called Tribler tokens. A cardinal unanswered question is how to securely pass the wallets with Tribler tokens and Bitcoin to the offspring servers. You Python software is able to accomplish some parts of the following functionality: • Earn income in a form of a bandwidth token (existing code). • Sell these earned tokens on a decentralized market for Bitcoin or other currencies. • Buy a server with Bitcoin or Ethereum without human intervention (see our existing PyPi scripts). • Login to this Linux server and install itself with code from the Github repository. • Automatically buy and install VPN protection to hide the outgoing traffic from the servers.

The software should be able to have a simplistic form of genetic evolution. Key parameters will be inherited to offspring servers and altered with a mutation probability. For instance, what software version of yourself to use (latest release?), what type of server to prefer buying (quad core, 4GB mem, etc), and whether you offer Tor exit node services for income or not. Bitcoins owned by TUDelft will be used to bootstrap your research.

[synctext]

@devos50 This will be used instead of Gitlab, feel free to give a 1-line pointer to this repo of TUDelft rules require you to leave notes there. All weekly meeting notes will be posted here (unless you GDPR-protest...)

Sprint staring point suggestion:

• 2-3 weeks of partial reading time what others did since 2017
• Focus on getting this operational by Week 3: https://github.com/Tribler/cloudomate/issues/79

[devos50]

@synctext I'm also using our other tickets on the Tribler repo for meeting notes so I'm totally fine with that.

[daangoossens22]

Getting the qtables through the IRC chat has been implemented, by calling !qtables{nick} you can get the qtable of the node that has that specific nick.

[daangoossens22]

I made the pull request both for Dollynator and cloudomate. Sorry for the delay.

most important changes made in Dollynator:

• gossiping implemented
• qd-learning implemented
• port the code to python 3.6
• a new market strategy implemented (namely crossover moving average)

Changes made in cloudomate:

• fixed the wallet code, so that it doesn't give an error mid purchase (with the latest electrum)
• fixed the providers linevast and qhoster
• linevast deletes accounts after purchasing and I have no idea why. From what I read and what I experienced this provider seems like a scam, and I don't recommend using it anymore.
• qhoster works, but it doesn't integrate with dollynator, not because of ubuntu 16.04 (because dollynator can work both on 16.04 and 18.04), but because the kernel version is too low to support some modules of tribler, so it cannot run tribler.

For a short summary of the gossiping and qd-learning, I will point to the readme in the dollynator repo. The best explaination of the specific parts, I will point to the related sections in our final report (which I linked in this message) Dollynator - Final Report.pdf.

Another future recommendation that I forgot to say during the presentation Q&A, is if you want to run dollynator reliable for long periods of time, probably some dynamic adding of vps providers should be added or changing the vps providers code while it is still running (so while it replicated it get the latest code for cloudomate, which is probably already done, but should be checked). This is because the vps providers sites change a lot, which makes them not work anymore for dollynator/cloudomate, but if you want the botnet to run for a long time this should be accounted for. This is probably a hard problem, but maybe a good problem for a next group to solve.

Another tip while fixing cloudomate is to first buy an instance of the vps provider manually and check if that provider works for dollynator and then fix the code for it. Don't make the same mistake that I made to first fix the code and then later find out that it doesn't work with dollynator anymore, because of a kernel version (or something else).

[qstokkink]

It seems like this project has been completed years ago. I'll close this issue now.