IP-to-IP Bitcoin Machine Network

Lately there’s been a lot of chatter around “IP-to-IP Bitcoin transactions”.

While there have been several past attempts at IP-to-IP Bitcoin transactions by passing around raw transactions directly between peers before broadcasting (such as Fat URI and Bitpipe) the biggest challenge has always been the lack of adoption among wallets.

However with the rise of protocol standards such as BIP270 among other things like Miner ID, IP-to-IP transactions are fast becoming a usable, everyday reality. And many Bitcoin wallets are starting to adopt BIP270, and this is very exciting.

This article will serve two purposes:

1. A brief introduction to IP-to-IP Bitcoin interactions
2. A comprehensive guide to building Bitcoin state machines that incorporate IP-to-IP technologies

Table of Contents

1. How Bitcoin payments used to work
2. The IP-to-IP way
3. IP-to-IP Bitcoin Machines
4. Massively Multiplayer IP-to-IP-to-IP
5. Overpool use cases
6. Bitcoin Machine Networks
7. Conclusion

1. How Bitcoin payments used to work

The traditional way of sending Bitcoin transactions is similar to wire transfers.

In the picture above, the black vertical bar represents the blockchain.

Let’s say Alice wants to send 1 bitcoin to Bob. Here’s how it works:

1. Alice creates a new transaction directed to Bob with 1 bitcoin.
2. Alice signs and broadcasts it to the Bitcoin network.
3. Bob’s wallet is listening to the Bitcoin network, and confirms when it notices the relevant transaction in the mempool or in a block.

Using the wire transfer analogy, this is equivalent to Alice going to her bank and sending a wire transfer to Bob, and Bob waiting for his own bank account to update.

2. The IP-to-IP way

The same scenario, but done in BIP270 way (a.k.a. IP-to-IP approach, or “P2P approach”) is similar to writing a check.

The process is as follows:

1. Alice composes a new transaction directed to Bob with 1 bitcoin.
2. Alice signs and GIVES the signed raw transaction DIRECTLY to Bob.
3. Bob “deposits” (broadcasts) the “check” (transaction) to the Bitcoin network. (There may be further schemes to ensure safety, such as receipts, broadcasting directly to miners, etc. You can learn more about the full spec here)

If you look at it this way, Bitcoin in this mode works more like a “Peer to Peer Electronic Check” than “Peer to Peer Electronic Cash”.

Just like how Alice would write a check to Bob, sign it with her signature, and GIVE IT TO BOB (instead of wire transferring through her bank), the “IP to IP” approach of using Bitcoin lets Alice sign with her private key and give the raw transaction to Bob directly, peer (Alice) to peer (Bob), after which Bob “deposits” it to his bank account (broadcast to Bitcoin).

The only difference is that the signature is a million times more secure since it’s a cryptographic signature with a private key instead of a sloppy hand-written ones most people use when they write a check.

3. IP-to-IP Bitcoin Machines

A few weeks ago, I released a simple but powerful system called Overpool. It lets developers easily build P2P Bitcoin state machines.

Overpool

While many people got excited about the potential, I also realize Overpool might be a bit out there for most who haven’t even yet started to grasp how this “IP-to-IP” approach works, since Overpool takes the “IP-to-IP” concept and goes one dimension further.

Let me explain the basics first.

Overpool is essentially a ledger for locally storing and sharing pre-broadcast Bitcoin transactions. I said “pre-broadcast” but it’s not really strictly for pre-broadcast transactions, you may keep them all even after you broadcast them and they get confirmed. In fact it might be a good idea to store them to keep track of every event that happened on your app locally. This is why Overpool exists in the form of a ledger.

You can “WRITE” to Overpool in 2 ways:

1. API: Use the API directly to programmatically post to the ledger
2. HTTP: Make a POST request to the Overpool HTTP endpoint, with a BIP270 formatted raw transaction as payload.

Whenever you append to the ledger, an event is triggered, which you can also programmatically process.

Here’s an example:

const Overpool = require('overpool')
const pool = new Overpool()
pool.create({ path: "mypool", port: 3000 })
pool.on("tx", async (e) => {
  console.log("new payment event", e)
  await db.collection("transaction").insertOne(e.parsed)
})

When you run this app:

1. An overpool ledger is created at path mypool.
2. A Microservice endpoint starts listening to HTTP requests at port 3000.
3. Whenever there’s a POST request which follows BIP270 format, it gets appended to the mypool overpool ledger.
4. Whenever there’s a new item appended to the mypool ledger, the pool.on("tx") event is triggered, and you can do whatever you want inside this event handler.

When I say “whatever you want”, I mean really anything. Some basic operations we can think of are:

1. Update a database
2. Loop back into overpool
3. Broadcast to Bitcoin

a. Update a database

This works the same way as the onmempool event handler of Neon Planaria. You can simply parse the overpool event to insert into a database, write to a file, or do whatever you want to maintain state.

For example you can see in the above code it’s writing to the database:

await db.collection("transaction").insertOne(e.parsed)

But the “database” is just an example use case. You can trigger anything with the event. Using the same principle we can easily imagine creating or updating a file, or triggering a 3rd party API which exists outside of Overpool, etc.

b. Loop back into overpool

You can modify an incoming transaction and loop it back into Overpool. This means we can build Turing complete systems with Bitcoin by constantly updating a transaction and re-posting to Overpool until certain condition is met. (For example signing multiple times iteratively)

Here’s an example of an infinite loop (Don’t try this at home):

const Overpool = require('overpool')
const pool = new Overpool()
pool.create({ path: "mypool", port: 3000 })
pool.on("tx", async (e) => {
  console.log("new payment event", e)
  await pool.post({
    path: "mypool",
    payment: e.payment
  })
})

c. Commit by broadcasting to Bitcoin

You can keep reposting modified transactions back to Overpool and handle the corresponding event until it meets certain criteria. Then you could either halt, or broadcast the final transaction set to the Bitcoin network.

Below is just a dumb example of immediately broadcasting a transaction which is submitted to overpool:

const Overpool = require('overpool')
const datapay = require('datapay')
const pool = new Overpool()
pool.create({ path: "mypool", port: 3000 })
pool.on("tx", (e) => {
  console.log("new payment event", e)
  datapay.send({
    tx: e.payment.transaction
  })
})

You can imagine how this can be combined with the looping approach to create a conditional broadcast. Also you can combine this with database updates to create a separate local state machine.

With looping and conditionals like this, we can build Turing complete machines out of Bitcoin.

But we can go deeper.

4. Massively Multiplayer IP-to-IP-to-IP

I heard you like P2P, so I put P2P in P2P so you can P2P while you P2P.

So far we’ve discussed the term “P2P” (or, “IP-to-IP”) within the context of a peer (Alice) sending transactions directly to another peer (Bob).

Overpool takes this notion of “P2P” to a whole new level.

If the P2P transaction approach we’ve seen so far was just a game between Alice and Bob, Overpool turns this into a massively multiplayer P2P game.

This is achieved by creating a P2P overlay network made up of Overpools, using a P2P protocol called DAT.

Unlike the Bitcoin blockchain ledger where anyone can write to the single global ledger and the “truth” is determined by proof of work, each DAT archive only allows its owner to write to them.

For example, in above diagram only Alice can write to Pool A, and only Bob can write to Pool B, etc. To explain simply, you can think of each DAT archive (in this case Overpool) as a decentralized Twitter feed. You can globally publish an overpool by simply running the "pub" command:

let key = await pool.pub({ path: "mypool" })

The command returns a discovery key for the Overpool which you can share with other peers.

Assuming the key returned was d7fcc2cc5e60154e299c54…8390, another peer may subscribe to your feed with:

await pool.sub({ path: "d7fcc2cc5e60154e299c54...8390" })

and that remote machine will automatically start synchronizing to your local “mypool”.

This way Alice can subscribe to Bob, Carol, and Dave, and vice versa. When Alice writes to her ledger, everyone who’s “following” Pool A will get updates and they can take appropriate actions, such as updating their own database, creating a new transaction and submitting to their own overpool, modifying the transaction and appending it to their own overpool, or broadcasting to the Bitcoin network. Really, imagination is your limit.

5. Overpool use cases

Overpool is just a tool. Anyone can use it for whatever purpose they want, including application developers, miners, or even consumers.

And thanks to its simplicity a lot of people have been coming up with lots of creative use case scenarios already, so I will share some of them here:

6. Bitcoin Machine Network

Let’s define “Bitcoin Machine Network” as a network of Bitcoin-powered state machines which may or may not interoperate with one another, and with Bitcoin directly.

The introduction of the “IP-to-IP” approach gives us multiple different combinations of such Bitcoin Machine network topology. Let’s take a look at the most obvious 3 which can be implemented easily today:

1. Single Player IP-to-IP Network: One application serves multiple users. But no interaction with other apps. For example we could think of a coffee vendor who accepts Bitcoin transactions. Multiple coffee vendors may not need to interact with a greater community of other coffee vendors (Or maybe they will :D)
2. Multiplayer IP-to-IP-to-IP Swarm Network: IP-to-IP, but publish-able and subscribe-able, creating a swarm of IP-to-IP-to-IP machines. Imagine the coffee vendors, but each being able to band together to form a group. It would be like a grassroots approach competition to Starbucks.
3. Bitcoin Central Grid Network: A network of authoritative Bitcoin global state, directly derived from the global state of Bitcoin. At the end of the day, the only thing that matters is what’s stored on the blockchain.
4. Central Grid + IP-to-IP Hybrid Network: Mix and match both IP-to-IP and the Central grid approach to take advantage of the best parts

Let’s go through each.

a. Single Player IP-to-IP Machine Network

The IP-to-IP approach can be very powerful and efficient. It lets you store transactions locally before broadcasting therefore you don’t need to wait for confirmations. Here’s what the topology looks like:

You can build these machines with Overpool, since Overpool in its most basic form is a mini-blockchain which lets you store any Bitcoin transaction (both signed and unsigned) and process them before broadcasting:

b. Multiplayer IP-to-IP-to-IP Machine Network

But the real power of Overpool lies not just in IP-to-IP, but in a massively multiplayer IP-to-IP-to-IP swarm network.

This is the part that may be too out there for many people since it goes one step further than the IP-to-IP approach which itself is new and not many people understand fully yet. But make no mistake, this multiplayer approach is already possible, the tool (Overpool) is already here for you to build with.

Let’s take the single player IP-to-IP machine from the previous section, and imagine what it would be like if these machines could communicate and interoperate, forming a distributed swarm of Bitcoin machines which collaborate to create sophisticated transactions and finally broadcast to the miners.

The IP-to-IP part works exactly the same, but now each Overpool can publish and subscribe to one another. What makes this powerful is you can subscribe to a peer and create a multiplayer loop which hops back and forth among multiple Overpool nodes. Yes, read it again: “Multplayer loops”. Instead of one machine running a loop, you can distribute the loop across multiple parties, each of which becomes a part of the greater looping program by passing around transactions among one another.

We could even imagine each Overpool node acting as an autonomous agent.

This sounds like a sci-fi scenario but is actually already possible with Overpool today. You can use pub api to publish and sub api to subscribe to other pools over DAT and Distributed Hash Table.

To summarize, this takes the notion of “IP-to-IP” to a new dimension. It’s an overlay network of IP-to-IP machines. Note that each Overpool can be run by anyone, which includes miners, businesses, application developers, and even a consortium of multiple private organizations looking to implement private communication channels.

c. Central Grid Network

Often you will need an instant global view of the blockchain. Without an efficient global access to the blockchain it is impossible to build various useful applications like bitcoinblocks.live, oyo.cash, trends.cash, bitgraph.network, etc. Also, as more businesses start using Bitcoin, we will see more need for interoperability in the future and a global access to the blockchain will become increasingly important.

Also let’s not forget that even when we use the IP-to-IP approach, we will still need ways to reliably and efficiently sync the entire app state straight from the blockchain state.

The following tweet makes a great point. The power of Bitcoin is that YOU THE USER own your data, not the application providers.

The important part here is:

“You would simply move your account to a different interface”

“move your account” means being able to re-synchronize the global app state, also known as “exit” according to Albert Hirschman.

According to Hirschman, every society is shaped by how costly it is for their members to “Exit” or “Show voice”.

Without an easy way to “Exit” from an application, the users may end up being practically locked into each application silo. It’s not a matter of whether something is possible or not. It is all about economics and everything exists on a spectrum.

Even if it is theoretically possible to “exit”, if the cost is too high it may be as good as impossible. For example, it is theoretically possible to migrate to another country, but many people who live in a corrupt country cannot afford to “exit”, therefore to them, this theoretical possibility is meaningless.

Coming back to the Bitcoin context, without an affordable way to access the global state, certain businesses may take advantage of this inefficiency in global data retrieval and synchronization to effectively lock their users into their services and take advantage of their users, the same way many of the current era web companies do.

This is why the “central grid” approach taken by Neon Planaria and Bitbus is important.

Last but not least, the “IP-to-IP” approach may not even be relevant for certain applications. These apps include:

• agent-type apps which monitor other applications globally and react.
• apps that provide value by connecting the global dots: oyo.cash, bitcoinblocks.live, bitgraph.network, trends.cash, etc.
• apps that require flexible interoperability
• more

d. Central Grid + IP-to-IP Hybrid Network

Lastly, you may use a hybrid of IP-to-IP and central grid approach.

For example, you may run both Neon Planaria and Overpool concurrently and write to a shared database to update the app state. Here’s what it would look like:

You may use Overpool to update your app database immediately in order to provide instant user experience, but then also use Neon Planaria/Bitbus to get a more global contextual view which will help you integrate data from other applications into your app (Which would otherwise be impossible since you only have access to your own local state in a pure IP-to-IP approach), as well as allowing anyone to easily synchronize the global app state. Here’s an example workflow:

One of the future plans is to integrate Overpool with Neon Planaria so that you can run the above architecture as a single self-contained code base instead of having to run them as separate processes.

That way you can take advantage of the instant UX that comes from the IP-to-IP approach, while also taking advantage of efficient access to the global state of Bitcoin.

7. Conclusion

The combination of the traditional transaction method and the new “IP-to-IP” method will enable various modes of Bitcoin machine communication networks as depicted in below diagram (“wire transfer approach”, “ip-to-ip approach”, “ip-to-ip triggered wire transfer”, “wire transfer triggered ip-to-ip”, “ip-to-ip swarm”, “ip-to-ip swarm triggered wire transfer”, “wire transfer triggered ip-to-ip swarm”, etc.):

Also, you should realize that this is just the beginning. It’s not like we will have just these two methods (“Wire transfer model” + “Check model”) and be done with it forever.

Just like how wire transfers and checks are just two of many ways to move money (There’s also cashier’s check, credit card, debit card, treasure chest, and many more, each with its own pros and cons), developers will come up with various creative ways of passing around Bitcoin transactions. Bitcoin is “programmable money” after all.

Also as we move towards the future where various Bitcoin machines and intelligent agents need to interact with one another autonomously without having to ask for permission, there definitely will be many other approaches to pass around transactions and interact with the blockchain.

And this is why Overpool exists as the most minimal and generic form, supporting not only the BIP270 model but also any other type of raw transactions including unsigned ones.

The key is to not trap oneself in a box, thinking there’s only one way to do things. Instead we need to think holistically about the problem, be open-minded, and adapt.