Grid Computing with Bitcoin Micropayment Channels

Posted by Balaji Srinivasan, David Harding

Grid Computing with Bitcoin Micropayment Channels


In this tutorial, we'll show you how to use 21 to create a grid computer which allows other machines to use its filesystem in exchange for bitcoin micropayments. This means you can turn spare compute resources into money. Specifically, here are the steps you'll follow:

  • First, set up a server that gives remote filesystem access in exchange for micropayments
  • Then, on the client, set up a persistent micropayment channel to the server
  • Next, in a separate window on the client, start executing commands on the remote server
  • You will see that each command that hits the remote filesystem will cost the client a small amount of bitcoin
  • At the end, when the client is done using the remote server, it closes the micropayment channel and settles out

Crucially, through the use of micropayment channels you can do an essentially unlimited number of filesystem actions, billed in sub-Satoshi increments, yet only have two transactions posted to the public Blockchain.


Install 21

You will need the following items:

  • Either a 21 Bitcoin Computer or 21
  • The latest version of the 21 software, obtained by running 21 update

Step 1: Set up the merchant server to sell grid computing

Open up a new terminal window. If you use a 21 Bitcoin Computer, ssh into it:

## Only necessary if you use a 21 Bitcoin Computer
ssh twenty@IP_ADDRESS

We'll call this session the merchant for the rest of this tutorial:

Install FUSE, the "Filesystem In Usespace", and the python library required to use it.

## If you use Linux
sudo apt-get -y install fuse
## If you use Mac OS X
sudo brew install osxfuse
## For both Linux and Mac
sudo pip3 install fusepy flask

Create a folder to store the files, download the server code, and run it:

mkdir serve
python3 serve/

Leave this session running; we will call it the first window (merchant server).

Step 2: Set up a micropayments channel to buy grid computing

Open a second terminal window. If you use a 21 Bitcoin Computer, ssh into it:

## Only necessary if you use a 21 Bitcoin Computer
ssh twenty@IP_ADDRESS

We'll call this session the customer for the rest of this tutorial:

Make sure you have bitcoins in your on-chain account. The minimum necessary to establish a micropayment channel is 163,000 satoshis. If you don't have enough in your on-chain wallet, you can flush the necessary amount from your buffer to your wallet using the following commands:

21 flush 163000
21 status

Periodically re-run the 21 status command until it says that your flushed satoshis have moved to your on-chain account. This may take 20 minutes or longer. Create a directory that will act as a virtual directory for the files stored by the customer and then download and run the merchant-side code.

mkdir storage
python3 'http://[::]:9123/files' storage

Also leave this session running. By watching the traffic in this session you can see the micropayments occurring in realtime.

Step 3: Start using remote grid computing resources and track the bitcoin micropayments

Open a third terminal window. If you use a 21 Bitcoin Computer, ssh into it:

## Only necessary if you use a 21 Bitcoin Computer
ssh twenty@IP_ADDRESS

We'll call this the action window.

Enter the storage directory:

cd storage

You don't have files in the directory, so copy the BSD software license file into this directory:

cp /usr/share/common-licenses/BSD BSD

If you get a "bad address" error, that's because your payment channel hasn't finished opening yet. (For security, the transaction that opens the channel must receive at least one confirmation before the channel fully opens.) You can wait five minutes and then try the command above again (and keep retrying it every five minutes as confirmation can sometimes take an hour or longer).

View channel status and the deposit transaction

Log into the client on a fourth window (tracking window):

ssh twenty@IP_ADDRESS

View a summary of the micropayments channel by doing channels list:

Bitfs channel open

The last of these is the current live open payments channel between the client and the server. The example above shows the deposit transaction that is live in the blockchain. You can view that transaction here. This channel is what will be paying for the actions we take in window 3.

The url in blue displayed after the command can be used to track the micropayments transaction by running channels status followed by the url. This will be referred to as the txid url.

Run this command in the client terminal window (the action window) and you will see that this action triggered a bitcoin micropayment over the payment channel established in step 2!

Pay bitcoin to copy a file on a grid computer

The exact amount is circled above. As you can see from the source, writing data costs 0.02 satoshis per byte by default and that file has 1,499 bytes, so 29 satoshis are sent using the micropayment channel from the customer to the merchant. Since this is the first micropayment, the amount is rounded up to 3,000 satoshis; this is done because most Bitcoin miners require micropayments exceed a minimum size, called the dust limit, so the customer must pay the merchant at least 3,000 satoshis to ensure the final micropayment transaction can confirm.

In addition, the customer balance is not allowed to drop below 3,000 satoshis for the same reason.

Now let's do another action and list the file's metadata:

stat BSD

Getting metadata is free by default, so there is no charge. Run channels status followed by the txid url and notice that your balance has not changed.

Pay no bitcoin to view metadata

Now read the file by printing it to your screen:

cat BSD

Pay bitcoin to print file to screen

Reading data also costs 0.02 satoshis by default and the file is still 1,499 bytes, so you should pay about 29 satoshis in fees. However, the cat command and most other commands read files in 4,096-byte filesystem blocks, so the customer ends up paying 81 satoshis to read the file.

Step 4: Close out the micropayments channel

To recap, we have four terminal windows open:

  • The server you opened in Step 1 (
  • The client you opened in Step 2 (
  • The SSH window you opened in Step 3
  • The window used to monitor the micropayments

As you did actions in the third window, you saw the resulting micropayments reflected in the server and client traffic, reflected in the first (merchant server) and second (customer) windows respectively.

Do another transaction

Now go to window 3 (action window) and execute this command again:

cat BSD

You should see server and client traffic in windows 1 and 2 respectively, as shown:

cat BSD

Upon going to window 4 (tracking window), you can also see that 81 satoshis were debited from your channel by running channels status:

channel debit

In other words, you can see exactly how much bitcoin you are spending to execute actions on the remote machine.

Close the channel and see the refund transaction

Let's now return to the second terminal window (the customer client opened in Step 2) and kill the running bitfs client by pressing Ctrl-C.

This won't affect the associated payment channel. If you restart the client in the second window and then re-enter its directory in the third window, you can display the file again for a cost of another 81 satoshis debited against the existing channel.

Only a merchant can close a channel in the normal way. However, the client can signal to the merchant that they want the channel to close. Do this by running channels close followed by your txid url in window 3 (action window), and then run channels list followed by the url to see a summary of the transaction.

Channels close and list image

Note the last entry. This was the payment channel that was paying for the client/server traffic. It's now closed and the refund transaction has been broadcast to the bitcoin network for mining. You can see that transaction here.


Just stop to recap for a second - this is pretty awesome. In just a few seconds, you set up a grid computer (Step 1), opened up a micropayments channel to that grid computer (Step 2), and started renting out resources simply by making filesystem accesses on that remote machine (Step 3). You viewed the status of that micropayment channel in Step 4, and were able to execute actions and see those reflected live in the channel status. Finally, you could close out that channel and see the deposit and refund transactions live in the Blockchain. All bitcoin micropayments were taken care of in the background until the channel was closed out.

Step 5: Start using grid computing programmatically (optional)

In Steps 1-4 above, you used the remote grid computer manually by setting up a server, opening a channel to that server on the client, and then reading/writing files.

If you would like to extend this example, the server provides a simple REST API:

access(path) -> HEAD /files/<path>
    404     Not Found

getattr(path) -> GET /files/<path>?op=getattr
    200     {"st_mode": <mode int>, "st_size": <size int>}
    404     Not Found

readdir(path) -> GET /files/<path>?op=readdir
    200     {"files": ["<file str>", ... ]}
    404     Not Found

read(path, size, offset) -> GET /files/<path>?op=read&size=<size>&offset=<offset>
    200     "<base64 str>"
    404     Not Found

create(path) -> POST /files/<path>?op=create

mkdir(path) -> POST /files/<path>?op=mkdir
    400     Directory exists.

write(path, data, offset) -> PUT /files/<path>
    {"data": "<base64 str>", "offset": <offset int>}

    200     <bytes written int>
    404     File not found.

unlink(path) -> DELETE /files/<path>?op=unlink

rmdir(path) -> DELETE /files/<path>?op=rmdir

And the client provides a FUSE API backed by the REST API above that implements the following filesystem system calls:

  • access()
  • getattr()
  • readdir()
  • read()
  • create()
  • mkdir()
  • write()
  • unlink()
  • rmdir()
  • truncate()

Next Steps

The Return of Grid Computing?

This example may also be of broader significance for grid computing. In the late 90s and early 2000s, there was much excitement around the idea of renting out spare compute capacity at home (so-called "grid computing"). However, this enthusiasm dimmed over the course of the 2000s. The reason is that cloud computing (homogenous servers run by a single entity like AWS) could be fairly said to have dominated grid computing (heterogeneous compute resources in homes and offices coordinated over the internet) for most tasks.

The applications of grid computing that did exist were smaller by comparison, with the biggest successes being academic projects like SETI@HOME and Folding@Home. These projects used status (in the form of leaderboards) rather than money to compensate the individual nodes in the grid performing distributed computations. And part of the reason they did that is that tiny amounts of money were hard to send over the internet.

Bitcoin mining as grid computing

Bitcoin mining began to change that. The global Bitcoin mining network can be conceptualized as a massive, heterogeneous, loosely coordinated grid computing network. The sellers are the miners, the direct clients are the bitcoin wallets that are paying transaction fees to these miners, and (arguably) the indirect clients are those who are valuing the block reward of the miners by buying bitcoin at market price.

While the block reward aspect of Bitcoin mining differs from traditional grid computing, it is similar in other respects. The unit of work for this network is the hash-per-second, which has an expected value that can be calculated from the current hashrate and price. The nodes in the network run the computation because they are being compensated by the clients via fees and (of course) via the block reward. So in this fashion money, rather than status, has been successfully used to coordinate a heterogenous network of devices.

Bitcoin micropayments and a new age of grid computing

The scale of the Bitcoin mining buildout indicates that grid computing may indeed be feasible after all given the appropriate compensation, and potentially better than or competitive with cloud computing for some applications.

Now that we have a quick way to set up a fine-grained bitcoin micropayments channel between any two machines, an obvious next step is to start generalizing this to the renting out of other compute resources beyond just storage. The primary limitation right now is that the value of the transaction has to be a significant multiple of the cost to set up and tear down a channel (23000 Satoshis). However, any device-to-device transaction in the range of a dollar or so would clear that bar today, and we can likely bring that setup cost down 100-1000X over the next few years.

How to send your Bitcoin to the Blockchain

Just as a reminder, you can send bitcoin mined or earned in your balance to the blockchain at any time by running 21 flush . A transaction will be created within 10 minutes, and you can view the transaction id with 21 log. Once the transaction has been confirmed, you can check the balance in your bitcoin wallet from the command line with wallet balance, and you can send bitcoin from your wallet to another address with wallet sendto $BITCOIN_ADDRESS --satoshis $SATOSHI_AMOUNT --use-unconfirmed. The --satoshis flag allows you to specify the amount in satoshis; without it the sendto amount is in BTC, but this behavior is deprecated and will be removed soon. The --use-unconfirmed flag ensures that you can send even if you have unconfirmed transactions in your wallet.

Ready to sell your endpoint? Go to

Ready to try out your bitcoin-payable server in the wild? Or simply want to browse and purchase from other bitcoin-enabled servers? Head over to the 21 Developer Community at to join the bitcoin machine-payable marketplace hosted on the 21 peer-to-peer network.