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:

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) 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. 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. 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.