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. 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. 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. 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Alice or Bob MUST broadcast the final transaction when the microchannel nLockTime has expired or risk having a valid but old transaction broadcast.