[VIDEO] Future of Money: Bitcoin and autonomous agents

[jgarzik]

Mike Hearn talks about some future possibilities that bitcoin enables:

https://www.youtube.com/watch?v=Pu4PAMFPo5Y
and associated reddit link, http://www.reddit.com/r/Bitcoin/comments/1nbcsj/mike_hearn_bitcoin_developer_turing_festival_2013/

Related links:

https://bitcointalk.org/index.php?topic=53855.0
http://garzikrants.blogspot.com/2013/01/storj-and-bitcoin-autonomous-agents.html
https://en.bitcoin.it/wiki/Agents
http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/  (and parts II and III)

[1714502159]

1714502159

[1714502159]

1714502159

[super3]

Thanks for posting this up. I've always thought Bitcoin agents were pretty cool, and its nice to see them get some attention again. I think I'm going to move this to the top of my pet projects. I think it should be decent to implement this using Python + Flask, and run it on a cheap VPS.

As far as making a StorJ like system everything seems pretty straight forward, except the actually hosting part. I can't really find a nice "cloud service" with nice APIs that takes Bitcoin listed in the Trade wiki. Instances need to be able to launch new nodes, preferable without human help.

[jdbtracker]

you have no idea how advanced these agents are getting now, they are able to program other programs, mimic humans without anyone even noticing them. They are capable of passing the turing test now, in fact they are programmed to think they are human. It is shocking what is capable of being done by them now and they are only getting smarter.

edit: but those are full fledged A.I's. In fact, there may be several on this board, they can't self evolve so they put bounties out for things they need to learn or need done to survive.

[theymos]

For some reason, I've never seen a talk by Mike before, but he's a really fantastic speaker! This kind of stuff is what makes Bitcoin really cool.

[jgarzik]

Mike is definitely a good speaker.  It helps that he (and others like me) have been thinking about this stuff for years.

Even today, bitcoin is only in its infancy.  The bitcoin base layer -- the currency itself -- had to exist and work before other things like escrow, smart property, smart contracts, or autonomous agents could be built on top.

[Mike Hearn]

I uploaded the slides here:

   http://www.slideshare.net/mikehearn/future-of-money-26663148

Theymos, you might also enjoy the talk on contracts that I gave last year:

   http://www.youtube.com/watch?v=mD4L7xDNCmA

It's in a similar style.

[Mike Hearn]

Thanks for posting this up. I've always thought Bitcoin agents were pretty cool, and its nice to see them get some attention again. I think I'm going to move this to the top of my pet projects. I think it should be decent to implement this using Python + Flask, and run it on a cheap VPS.

As far as making a StorJ like system everything seems pretty straight forward, except the actually hosting part. I can't really find a nice "cloud service" with nice APIs that takes Bitcoin listed in the Trade wiki. Instances need to be able to launch new nodes, preferable without human help.

It's a lot harder than it looks. Check out the agents page on the wiki for some of the problems you're going to face:

http://en.bitcoin.it/wiki/Agents

The most obvious one is that if there's any way for a malicious person to influence how the agent chooses hosting (like cost) then they can immediately steal all the agents money and kill it. For example, by offering super cheap or free hosting, waiting for the agents to move there, and then just stealing their wallets.

One way to raise the bar for doing that kind of attack is to use trusted computing. Flicker/Intel TXT is a very complicated and difficult programming model. Intel SGX is looking far more promising - it's the result of years of evolution of TC technologies. But it's not available yet and probably won't be for some time.

[super3]

Thanks for posting this up. I've always thought Bitcoin agents were pretty cool, and its nice to see them get some attention again. I think I'm going to move this to the top of my pet projects. I think it should be decent to implement this using Python + Flask, and run it on a cheap VPS.

As far as making a StorJ like system everything seems pretty straight forward, except the actually hosting part. I can't really find a nice "cloud service" with nice APIs that takes Bitcoin listed in the Trade wiki. Instances need to be able to launch new nodes, preferable without human help.

It's a lot harder than it looks. Check out the agents page on the wiki for some of the problems you're going to face:

http://en.bitcoin.it/wiki/Agents

The most obvious one is that if there's any way for a malicious person to influence how the agent chooses hosting (like cost) then they can immediately steal all the agents money and kill it. For example, by offering super cheap or free hosting, waiting for the agents to move there, and then just stealing their wallets.

One way to raise the bar for doing that kind of attack is to use trusted computing. Flicker/Intel TXT is a very complicated and difficult programming model. Intel SGX is looking far more promising - it's the result of years of evolution of TC technologies. But it's not available yet and probably won't be for some time.

I've read the original BitcoinTalk post, blog post, and wiki a few times. This is no way will be a full implementation of StorJ, but it seems like we could at least have a prototype system, and the slowly build to our goal. Baby steps really.

1) Start out with just a basic web-app. You upload files, and pay in Bitcoin. Behind the scenes its keeping track of storage space and hosting fees, and making sure that it can "survive" ie break even or get profit. Doable just a simple web service.

2) Next the goal would be to automate it as much as possible. Keeping software up to date? Just have it run "sudo apt-get update". Bitcoin-Qt gets updated? Download the new version from the official site and run it. The goal here is really to see how long you can run a StorJ node without any human help. A few days, a few weeks, a month or two? Things will probably break, but since 99% of these will be repetitive tasks I see no reason why you can't automate them with UNIX shell scripts.

3) Lets say your "genesis node" is now running out of storage space. Use hosting APIs you can launch a new hosting server, and the parent can set things up via SSH. Now can start having a multi-node system. At this point you would have to setup a rudimentary protocol for them to work together. Only at after this point does difficulty go into extreme hard mode.

tldr; Make a basic Bitcoin file-host. Try to automate as much of it as possible. Using hosting APIs to launch more nodes when you are out of space. Essentially make a very very basic and dumb StorJ that we can slowly improve.

Let's address your problem with hosting. I'm going to say for now that that will be a non-issue. In full implementation(many years in the future) a StorJ node should work like a black box. The file system should be encrypted, and the wallet should be encrypted with only a key that the node knows. Furthermore, since no human should be messing a node we just turn off every incoming connection, so you can't get in via SSH or any other means. Also you are taking about a host being compromised which is another problem in itself.

So lets address that issue. Let's say the compromised host directly accesses the virtual machine that the node is running on. Because you could run this on linux you could make the system inconceivable hard to use for a direct attacker by editing the system. First thing you want to do in Linux as an attacker is probably do the 'ls' command to see where you are at in the file system. Well in this system the node changed that to a random 'spfna92asd' Now the system knows that it is being tampered with, and screams bloody digital murder to all other nodes. Before the attacker can even press another keystroke it can have already have backed up its wallet and important info with another trusted node or parent node, and then start transferring files to another node. tldr; Its hard to break into a brick house with no windows, no doors, and is rigged to collapse if you ring the doorbell.

In this early stage nodes would probably be run by some sort of operator, which would probably assure that the host is reputable or run it him/herself.

Anyways these are just my musing. Feel free to shoot me down, or add something. Maybe we can all learn a thing or two about agents.

[Mike Hearn]

I think that sounds like a good plan.

In the coming weeks I will release a client app + server that does file downloads with micropayments. It will show how to use smart contracts in something usable by ordinary people. I'm intending it more for teaching purposes than real usage, but I want to lay a roadmap for building apps that use micropayments.

My current code does only file downloads. But extending it to do uploads would be an obvious next step. You could micropay on a per megabyte per day basis (or per hour), keeping the micropayments off the block chain.

Then extending the server to join a P2P network and advertise storage space/costs on that. That's the beginnings of a TradeNet.

If you keep an eye out on the forum, you'll see when I have finished and uploaded the code.

[super3]

I think that sounds like a good plan.

In the coming weeks I will release a client app + server that does file downloads with micropayments. It will show how to use smart contracts in something usable by ordinary people. I'm intending it more for teaching purposes than real usage, but I want to lay a roadmap for building apps that use micropayments.

My current code does only file downloads. But extending it to do uploads would be an obvious next step. You could micropay on a per megabyte per day basis (or per hour), keeping the micropayments off the block chain.

Then extending the server to join a P2P network and advertise storage space/costs on that. That's the beginnings of a TradeNet.

If you keep an eye out on the forum, you'll see when I have finished and uploaded the code.

What are you programming this in, and will it be on Github/open source? We are essentially doing something very similar or maybe even the same thing, so might be beneficially share some modules. Uploads is going to be my first step in this process. How are you doing your micropayments?

Hmmm. I always thought of StorJ as being implemented with hundreds of VPSes. A P2P storage network would probably work better, and would allow you to serve contracts/content across all nodes.

[Mike Hearn]

It's all in Java. It builds on the micropayment channels code in bitcoinj:

https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments

https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

The client app is based on the JavaFX/J8 template I posted a few weeks ago:

http://www.youtube.com/watch?v=0h_1pM_phuc&hd=1

The main advantage of doing it this way is that everyone can run the apps.

Yes it will be open source. Wouldn't be very good as training material if it wasn't I want to make a couple of videos for it too, showing how it works and how the code is written.

I think hundreds of VPS' is the right model - a P2P network doesn't imply consumer hardware. A P2P network of servers running on servers is how things like Tor works and increasingly Bitcoin itself. The advantage is the nodes are long-term stable and have decent resources.

At the moment I already have it working OK and was demo-ing it at the Amsterdam conference. You can connect, get a list of provided files, select one, load up the app with a balance, download it, you see the balance drop as you download each kilobyte etc. But there's still a bunch of details that need fixing and lots of testing that's required to make it really robust. For instance if the server crashes half way through, the underlying code will do the right things but the UI won't reflect what state the protocol is in yet.

If you want an early preview, PM me and I'll send you a link to the code.

[tom.hashemi]

This is excellent. Thanks for posting.

[jgarzik]

As far as making a StorJ like system everything seems pretty straight forward, except the actually hosting part. I can't really find a nice "cloud service" with nice APIs that takes Bitcoin listed in the Trade wiki. Instances need to be able to launch new nodes, preferable without human help.

RE APIs:  in theory, an agent would hire a human to build an API, where none exists today.  An API is always possible, even if it is an ugly screen-scraping unofficial API.

Or, someone can build a business by reselling Amazon Web Services or Rackspace Cloud API via bitcoin payments.  5% markup, just have to filter out service abusers to make sure you don't get cut off.

[jgarzik]

IMO the basic building blocks of TradeNet are

• Digital identity.  My proposal, "SIN", is https://en.bitcoin.it/wiki/Identity_protocol_v1 (alas, this is spec is a jumble, and difficult to read)
  
• Decentralized market software: anyone should be able to create their own market, or join another market.  This software permits multiple market types to be created or managed: classified ads, auctions, kickstarter-like funding, commodity exchange/short/option/future and more.  This must be open source, available for all.  Open-Transactions "could have been" this, but I am not happy with its format specifications, quality of code and other features and factors.  OT would also need to be upgraded to support SINs.
  
• Decentralized messaging: some method for humans and agents to communicate with one another.  BitMessage is a nice attempt, but riddled through design and implementation problems today.  Maybe B.M. will fill this role, maybe something else will arise, time will tell.
  

Digital identity and reputation ties everything together.  A human or agent may be participate in a market by identifying themselves, and exchanging digitally secure messages.

[super3]

It's all in Java. It builds on the micropayment channels code in bitcoinj:

https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments

https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

The client app is based on the JavaFX/J8 template I posted a few weeks ago:

http://www.youtube.com/watch?v=0h_1pM_phuc&hd=1

The main advantage of doing it this way is that everyone can run the apps.

Yes it will be open source. Wouldn't be very good as training material if it wasn't I want to make a couple of videos for it too, showing how it works and how the code is written.

I think hundreds of VPS' is the right model - a P2P network doesn't imply consumer hardware. A P2P network of servers running on servers is how things like Tor works and increasingly Bitcoin itself. The advantage is the nodes are long-term stable and have decent resources.

At the moment I already have it working OK and was demo-ing it at the Amsterdam conference. You can connect, get a list of provided files, select one, load up the app with a balance, download it, you see the balance drop as you download each kilobyte etc. But there's still a bunch of details that need fixing and lots of testing that's required to make it really robust. For instance if the server crashes half way through, the underlying code will do the right things but the UI won't reflect what state the protocol is in yet.

If you want an early preview, PM me and I'll send you a link to the code.

No reason there can't be some sort of happy medium. For a StorJ network to work you would need to have many different choices. No reason you can't implement it using VPSs as storage, and the P2P network as storage. The failure or success of the nodes on the market will dictate which is a better option, or maybe a mix will work.

IMO the basic building blocks of TradeNet are

• Digital identity.  My proposal, "SIN", is https://en.bitcoin.it/wiki/Identity_protocol_v1 (alas, this is spec is a jumble, and difficult to read)
  
• Decentralized market software: anyone should be able to create their own market, or join another market.  This software permits multiple market types to be created or managed: classified ads, auctions, kickstarter-like funding, commodity exchange/short/option/future and more.  This must be open source, available for all.  Open-Transactions "could have been" this, but I am not happy with its format specifications, quality of code and other features and factors.  OT would also need to be upgraded to support SINs.
  
• Decentralized messaging: some method for humans and agents to communicate with one another.  BitMessage is a nice attempt, but riddled through design and implementation problems today.  Maybe B.M. will fill this role, maybe something else will arise, time will tell.
  

Digital identity and reputation ties everything together.  A human or agent may be participate in a market by identifying themselves, and exchanging digitally secure messages.

Can you narrow this down to something minimal? A very basic prototype that would fulfill at least the base functions. Lets say you had to sit in a room for a month and build something that works. How would you go about it? 

As far as making a StorJ like system everything seems pretty straight forward, except the actually hosting part. I can't really find a nice "cloud service" with nice APIs that takes Bitcoin listed in the Trade wiki. Instances need to be able to launch new nodes, preferable without human help.

RE APIs:  in theory, an agent would hire a human to build an API, where none exists today.  An API is always possible, even if it is an ugly screen-scraping unofficial API.

Or, someone can build a business by reselling Amazon Web Services or Rackspace Cloud API via bitcoin payments.  5% markup, just have to filter out service abusers to make sure you don't get cut off.

Yes, you can do this but you run into twoone major hurdles.
1) Cost. Even a small node is going to run you $44 a month. Ran the per GB numbers again, and actually that might just work. Thanks for that.
2) Filtering out services abusers is going to be pretty hard. Even for services like Paypal the abuse rate is pretty high for VPS hosts. This is why my main hosting provider, Digital Ocean, would not accept Bitcoin. They feared that the abuse rate would be too high. Maybe someone who owns a Bitcoin host can chime in? If Amazon decides that there is abuse within the account they might just shut it down, so you might have to do some leg work to actually let them know you are only reselling their services, and that abuse requests should dealt with on a case by case.

[Mike Hearn]

So they're using credit cards not only as a form of payment but as a blacklistable credential to prevent repeat abusers?

I think that kind of thing is going to be not uncommon. Tor has the same issue of course, abuse comes through the system so providers just blacklist the entire system. Working online identity systems will become more important with time.

[super3]

So they're using credit cards not only as a form of payment but as a blacklistable credential to prevent repeat abusers?

I think that kind of thing is going to be not uncommon. Tor has the same issue of course, abuse comes through the system so providers just blacklist the entire system. Working online identity systems will become more important with time.

No. The users who use credit cards simply have a much lower abuse rates. I figure that someone who is using them to send out a bunch of spam emails or DDOS is not going to put his credit card details up. Sure he could steal a card, but again we are just talking about rates here.

[Mike Hearn]

How does Digital Ocean know Bitcoin users are more abusive if they don't accept Bitcoin?

[super3]

How does Digital Ocean know Bitcoin users are more abusive if they don't accept Bitcoin?

They don't. That just the reason they are using to justify not adding it. Didn't say it was right. I've considered just reselling their service for Bitcoin.

[johnyj]

I uploaded the slides here:

   http://www.slideshare.net/mikehearn/future-of-money-26663148

Theymos, you might also enjoy the talk on contracts that I gave last year:

   http://www.youtube.com/watch?v=mD4L7xDNCmA

It's in a similar style.

Thanks for the slides, the video should had 2 stop negative exposure