Bitcom is an open ended OP_RETURN protocol for creating a universal virtual computer on top of Bitcoin.

Bitcom borrows from the UNIX filesystem metaphor to represent a global directory of Bitcoin application protocols, where:

• Each "account" is represented as a root folder with a Bitcoin address as the name
• Each "account" is an application protocol controlled by the private key holder of the address.

Thanks to the simplicity of the protocol, you can generate these transactions yourself easily.

But to make it even easier, it ships with a utility NPM package that manages keys and broadcasts to Bitcoin through a terminal interface.

NOTE: Nobody owns Bitcom. It's just an open convention you can use to build your application protocols. And comes with the benefit of NEVER having to worry about namespace problems.

Background

1. Protocol Prefix

In the past, Bitcoin application developers building OP_RETURN based application protocols had to come up with an arbitrary "prefix" to distinguish one protocol from another.

Here's an example for Memo.cash:

OP_RETURN 6d01 6d656d6f

Here, the 6d01 is the so-called "Prefix", but it's actually just the second pushdata (The first being OP_RETURN).

2. Namespace Collision

The problem with this prefix approach is that ANYONE can come up with their own protocol prefix as pushdata. And there will be collisions.

In the past, people tried to fix this problem by creating a registry to keep track of protocol prefixes in a centralized website.

For example, you can see this central directory in action at the Bitcoin Cash Protocol Repository, where you are required to submit an 4 byte prefix to the directory, stored on GitHub:

3. Problems

There are several problems with this approach.

1. High Barrier: There's too high of a barrier to create a new protocol. You have to first come up with a hex prefix, go to this website and check if there's any collision, and if there is, come up with another. And as every programmer knows, "There are only two hard things in Computer Science: cache invalidation and naming things.". Ideally, creating a new protocol should be so easy that a grandma can create a protocol over a cup of tea.
2. Manual: You can only create protocols manually. Let's use our imagination. We could create protocols that create more protocols. And to automate this, this prefix scheme should NOT rely on human factor.
3. Centralized: You must know the existence of this central directory, and check before you name your protocol. And this won't scale as more people start creating their own protocols. There will be politics since it's run by a central party.
4. Not a Fundamental Solution: This solution does NOT solve the namespace collision problem fundamentally. Let's say I created a protocol and listed it on that directory. What happens if someone else had already been using it before, but just didn't realize the directory existed so it's not listed there? Who gets the prefix? Also, people could knowingly just use whatever prefix they want even if it overlaps with others.

What

Bitcom solves this problem by looking at this problem from a computer operating system point of view.

If Bitcoin was a single Unix computer, and if there was a way to guarantee that no namespace collision occurs, we could create a decentralized directory of "Bitcoin applications", each of which is represented as an account represented by a Bitcoin address.

Highlights:

1. Bitcoin Address as Prefix

There is no arbitrary hex code you have to come up with. Creating a protocol is as simple as generating a Bitcoin Keypair.

Instead of the traditional approach of manually coming up with a prefix (example: memo.cash)

OP_RETURN 0x6d02 Hello

The "prefix" is automatically generated, as a Bitcoin Address.

OP_RETURN 17yyXL4raLZFU95ixkRESa2ZBPSSYxSsS5 [App pushdata1] [App pushdata2] [App pushdata3] ...

And you can bet that randomly generated Bitcooin adddress won't suffer from namespace collision issues. This means you can feel free to make as many protocols as you want, because it's as easy as generating a Bitcoin address.

2. No Central Directory

There is no central directory to list. You can load the directory directly from Bitcoin through Bitquery

3. Decentralized Listing

There is no such thing as "listing". There is no Github to list to, there is no one to ask for permission. You simply generate a Bitcoin address, and prove that it's you by making the initial transaction from that address, and then you effectively OWN that namespace.

4. Provable Ownership

You can prove your ownership of the protocol namespace by signing it with your private key.

These are the basics. Of course, this can be extended in the future to make it more powerful, but for now this should be good enough to make developers' lives much easier and get away from centralization and politics.

Why

Why does Bitcom suddenly make sense now? Why hasn't anyone done this before?

Before Bitcoin SV's Block 566476, OP_RETURN transactions have been defacto limited to around 220bytes. This meant people had to try really hard to pack whatever data they want into a SINGLE Transaction, otherwise they had to come up with all kinds of hacks to chain transactions together to create a large whole.

This is why the past approaches used things like a 4 byte hex pushdata prefix scheme.

But with this scheme, the "prefix" is much larger. What a waste!!!

Or is it?

Let's step back and thinking about this. With the limits gone since Block 566476, people have started putting all kinds of things on the blockchain, from text to image to a website to audio.

When the type of data we are storing is now in kilobytes, does "4 bytes vs 25 bytes" really matter that much?

Especially when the benefit outweighs the cost? (Permissionless, Decentralized, Collision free, Ownerless, and powered by Bitcoin itself)