Introduction to Micropayment Channels

Introduction

Transactions on Bitcoin rely exclusively on being able to get into a block to be final and settled. Unfortunately, in the current climate there might be more transactions that can fit into a 1MB block. Furthermore, while blocks occur on an average of 10 minutes, in some instances the next block may take more than an hour. This means that users transactions may not be processed and settled in a timely manner, and this exposes issues with scaling Bitcoin to many more users.

What is needed is a layer two solution that allows users to transact without having to rely directly on the next block for a complete transaction. We propose using micropayment channels to allow users to transact as much as they would like in a given time period. Using current methods, this would require a Bitcoin transaction to start, and a Bitcoin transaction at the end, but allow many transactions in between with no additional fees. Using current methods, once a channel is established, a user can transact without having to worry about the next block being full or happening in a timely manner.

One Way Micropayment Channel

Let's say Bob wants an important 10GB file from Alice, and is willing to pay Alice for her bandwidth. Now Bob doesn’t necessarily trust Alice so he doesn’t want to give up all his money at once and have Alice run away. If the data costs 1 mBTC per GB, Bob would pay more in Bitcoin transaction fees if he splits the payment into more than 10 pieces, and he may have to wait hours before all these transactions are confirmed in the blockchain.

Figure 1

Figure 1. Traditional solutions can lead to fraud and exorbitant transaction fees

Instead we would like to establish a one way micropayment channel between Bob and Alice. Bob can use this channel whenever he wants to pay Alice for a good or service as long as the channel is open. Bob intends to pay around 10 mBTC (around $0.50) to Alice. Bob sends 15 mBTC to a 2-of-2 multisig wallet controlled by both Alice and Bob. A 2-of-2 wallet means that both Alice and Bob must agree to all transactions that leave the wallet. Before Bob deposits the funds, Alice signs a transaction with Bob, returning all the funds sent to the 2-of-2 wallet to Bob, with an nLockTime of 100 blocks in the future. nLockTime allows us to craft a valid transaction that can only be spent in the future. Think of an nLockTime transaction like a post dated check. It's still a valid transaction/check just can't be spent until the n blocks in the future. This means that Alice can’t hold any of the funds hostage after they are deposited, and Bob can recover his funds after 100 blocks in the refund transaction. The core of how micropayment channels work is that if Bob and Alice agree, they can make many changes to the refund transaction until the channel expires, Bob/Alice cease to agree, or one goes offline.

Figure 2

Figure 2. State of the refund transaction on a one way micropayment channel

Bob paid 1 mBTC as a transaction fee, and waited 10 minutes for the transaction to be included in a block. He can now start transacting with Alice. Bob instructs Alice to send the file in 1GB increments. After each increment Bob and Alice can mutually agree to adjust the transaction refund to a new state. The new unsent transaction has an nLockTime of 99 blocks, sends 1mBTC to Alice and 13 mBTC back to Bob. Note that there is 1 mBTC transaction fee when the final transaction is broadcast. This continues until the last unsent transaction with a nLockTime of 90 blocks, which gives Alice 0.0010 BTC and returns 0.004 BTC to Bob, after the 0.0001 BTC transaction fee. After 90 blocks pass this transaction can be broadcasted to the network and Alice and Bob can receive the final version of their payment.

If at any point Alice failed to deliver the next piece of the file to Bob, Bob would get the remaining funds returned to him that had not been assigned to Alice. Because both Bob and Alice have to sign transactions out of this wallet neither of them have to worry about double spends.

Bidirectional Micropayment Channel

Let's say that Bob and Alice would both like to pay each other to exchange data. Bob has some data that Alice wants, and Alice has some more data that Bob wants. In this case, we would setup the a one way micropayment channel in both directions allowing Bob and Alice to transfer funds between them on the active micropayment channels.

Figure 3

Figure 3. Bidirectional micropayment channel is just two one way microchannels

Shortcomings of Bidirectional Micropayment Channels

While micropayment channels would allow you scale to many use cases between two parties, it has some shortcomings.

  1. With current Bitcoin prices and transaction fees, it costs about 4 mBTC($0.20) to set up and close: Two transactions to setup, and two transactions to end. For this to make sense, the total value transfer should probably be larger than $1.
  2. What we have described only allows us to conduct transactions between two parties. If we wanted to add Carol and Dan to our incentivized file sharing network, that would increase the cost by 2x to setup the micropayment channels.
  3. There is a limit to the amount of transactions we can make with a microchannel. We must lessen the nLockTime of the the latest transaction, so the most recent agreed upon state of the microchannel can be broadcast and settled first. If we set an nLockTime of 100, we can make 100 changes before the refund transaction should be executed.
  4. Funds to be spent in a microchannel must be put in up front. So from our first example, if Bob wants another file from Alice and he runs out of money to reward her, he will have to establish another microchannel and incur fees doing so.
  5. In our first example, Bob loses access to spend his funds on other things while he is waiting for the transaction to complete. Unless Alice agrees to end the transaction early by signing an early refund request, then Bob will have to wait quite a while to receive the change from the microchannel.
  6. Alice or Bob MUST broadcast the final transaction when the microchannel nLockTime has expired or risk having a valid but old transaction broadcast.

Welcome to 'Super3.org'

It's a new year, so out with the old and in with the new. The old static website is gone, and has been replaced with this blog which I'll post my ideas and projects from time to time.

What I Do

In 2015 I started a company called Storj Labs, where I am currently the CEO/CTO. Our mission is to create a peer-to-peer cloud storage network powered by users. We aim to be the fastest, most secure, most private, and cheapest cloud storage provider.

Education

I graduated Morehouse College with a BS in Computer Science in 2014. I'm currently pursuing a Masters in Computer Science in the OMSCS program at Georgia Tech. I've conducted research at University of Washington and Aberdeen Proving Grounds.

Previous Work

Some of the stuff I've worked on in the past.

Bitcoin

Got involved with Bitcoin in 2012 and it changed my life. Bitcoin is an innovative payment network and a new kind of money. It is one of the first highly successful examples of an incentive driven decentralized network.I started out at a Bitcoin miner, but really fell in love with the technology and what it could do. I made small contributions to Bitcoin Core, got involved with projects such as Peercoin, Primecoin, and BitShares.

After that I focused on my own project, Storj to harness some of that of that technology into a peer-to-peer cloud storage network. After raising $500k to fund the open-source project in 2014, I founded a company called Storj Labs to further the concept and the technology.

Blender

In my early years I built a tutorial series teaching people how to use the 3D animation and graphics program Blender. The series has about 3.6 million views to date. I no longer do this, but it was great fun and I learned a ton about building communities and teaching.

Small Code Projects

  • PyTrack - A computer vision object and motion tracking tool. Currently allows you to track and report the location of a single object in a video. Developed at the University of Washington as part of a REU program at the Center for Sensorimotor Neural Engineering.
  • Zombie Factory - A zombie shooting game made with Python. Part of my experiments with PyGame, a cross-platform set of Python modules designed for writing video games.
  • Sketch and Shake - An etch-a-sketch app, designed during Experience Microsoft 2012, for Windows Phone 7. You can draw with your finger and shake your phone to erase. Written in C#. This app has been recommended and featured by AppDeals. Best of all it is free to download.
  • PHP IRC Bot - A simple, object oriented, and PHP based IRC Bot for games, channel logging and management. No special software needed, simply run it on any webserver or LAMP stack. You can easily extend it with your own modules in PHP, rather than some custom scripting language.