The Bitcoin HTTP Header
Per Request Micropayments for Web Services
Wouldn’t it be cool if we could just pay for each HTTP request we make to our favorite web services by adding the following HTTP header…
…where BTC is some sort of micro-money that the web service could cash out from the blockchain?
This is an experimental idea that I’ve been thinking about over the past few days. I want a reliable way for my users to anonymously pay for my APIs and web services on a request by request basis; without the need to create accounts, add credit cards, or even maintain bitcoin wallets for each of my users.
I want it to be so simple that you just attach couple of Satoshis with your HTTP request, so that I’d give you the response you need. This approach is infinity scalable, and it captures the true nature of micropayments with bitcoin. The way I see it, this would revolutionize the “Internet of Things” industry in particularly, and shape the virtual ecosystem between devices that we’ve been talking about for years.
So, How Are We Gonna Do That?
This is all great theoratically, but I’m still not sure about how we can accomplish that practically. I came up with a design that maybe could take us there, but it’s still not perfect.
First off, what does this BTC header represent exactly? Could it be a bitcoin address/private key pair that contains a very tiny number of Satoshis that represent the value of that HTTP request? It would work the same way a check works in the real world. You send the API provider a bitcoin check that they can cash out from the blockchain.
This approach is very similar to what bitcoin payment gateways like BitPay use to create invoices for their users to cash out later on from the blockchain. The difference however is that we do it in a very micro scale, and we need to do it fast, in milliseconds. That’s not as easy as it seems.
We can’t create these checks/bitcoin addresses, and fill them with Satoshis in realtime on demand. This would take couple of seconds to broadcast up the blockchain (not to mention tx confirmation if we need it), and since we’re working with APIs, that’s an issue. Maybe it is not in certain applications, but for the most part, it’s not even an option.
To solve the previous issue, we could pre-create those address, and fill them up. We just create a “checkbook” of a certain value (Say 1 BTC), which is just a collection of tiny checks, each of which is valued at the current price of that HTTP request we’re trying to consume. The problem is, we’re gonna need a big fat database to keep track of all those checks!
Assuming that we’re ok with maintaining a database of checks, we’ll be able to successfully make the request. Now let’s take it from the web service side. The API provider will have to verify, or better yet immidietly cash out each check it receives with each request. To accomplish this as fast as possible, the web service provider will need direct access to the blockchain on the file system level. Which means it’ll need to host it’s own bitcoin node, and not use external Blockchain HTTP APIs. Otherwise, the response will be ridiculously slow. There’s a big cost and maintenance compromise here.
If we’re still okay with that design, we’ll have to keep in mind that the API provider will have to serve on a secure HTTPS connection, since we’re sending the address private key along with the request. Even though that address contains very tiny number of Satoshis, it’s still sensitive information.
The biggest challenge that I could think of is that there’s a minimum limit for sending bitcoin. It’s about 0.1 cents. And since we’ll be paying on a request by request basis, paying 0.1 cents for each request is just non sense. Maybe we can go around that by paying per 1k requests or something, but that wouldn’t be ideal.
This design looks more of an open protocol, kind of similar to oAuth. And despite these challenges, and maybe others that I haven’t thought of yet, I’m still excited to try this out! I’m particularly worried about having to maintain a database of checks, and I’m hopping to find a better solution.
Remember, the goal here is to anonymously pay for each request in realtime without maintaining user accounts, balances, API rate limits…etc. If you could think of a better design that would accomplish this goal, please get in touch with me and we can work together on making this happen! Meanwhile, I’ll be experimenting with this design and see how it goes.