One tense November morning in 2018, two visions for Bitcoin permanently diverged, damaging an already-fragile community of miners, developers and crypto businesses. Millions were lost in the confusion as transactions jumped from one chain to the other—the network's final attempt to synchronize its state and remain whole even as it was being ripped in two. The world of cryptocurrencies—and especially the feuds that can arise between them—can be contentious and gut-wrenchingly stressful.

Of course, I'm describing the divergence of Bitcoin Cash (BCH) and Bitcoin SV (BSV). Both sides suffered greatly from this event—Bitcoin SV lost the support of Bitcoin ABC and was de-listed from most major cryptocurrency exchanges. Meanwhile, the BCH price fell from a high of around $441 on the day of the split to $80 just a month later. MoneyButton, Coingeek, nChain and others jumped ship from the BCH ecosystem. This loss has created bitterness and fostered a mentality of maximalism on both sides.

The chaos has been real—I've been on both sides of this controversial split and I understand both camps well. I'm addressing this post to the Bitcoin Cash community as a supporter of Bitcoin SV. I'm not here to criticize either project and I strongly believe that people have done some great things in Bitcoin Cash. I just think there are some aspects of BSV that most Bitcoin Cashers don't fully understand, so I want to create this resource especially for you and explain the important differences—I don't want to convert you into a mindless worshiper of Craig Wright (in fact, he's regularly called out by the BSV community), I simply want to educate and inform you about the differences in the technology and philosophy.

I believe that the biggest problem with Bitcoin SV right now is one of effective communication—In this post I'll be exploring a few key differences and expounding on ideas that most leaders in the BSV camp don't feel are worth taking their time to explain or justify. This has bread a culture of negativity and even hostility towards those who question the reasons why things are the way they are rather than to figure it out on their own. Similar in some ways to the LineageOS community, people don't generally take the time to explain their reasoning—it's much easier to just dismiss a genuinely curious new developer as a troll or an outsider.

I think one of the most visible examples Bitcoin Cashers are aware of is the debate over OP_CHECKDATASIG. I hope that by providing these explanations, I can show those BSV leaders that they should take the time to justify their ideas and welcome new developers so that talented people and useful projects understand why they should consider Bitcoin SV, the original Bitcoin.

CHECKDATASIG and Scripting Capabilities

One of the biggest reasons I hear from Bitcoin Cash supporters why they don't switch to BSV is that the scripting capabilities of BCH are far superior to that of BSV. In short, the idea is that there are things you can do on BCH that are simply not possible on the BSV network. Primarily, this is centered around BSV's lack of OP_CHECKDATASIG, which allows—among other things—for covenant contracts.

In BSV, this same functionality can be achieved by implementing ECDSA signature verification in Bitcoin script itself. Not only does this mean you can achieve the same result as OP_CHECKDATASIG, but you also get more flexibility over which algorithm you want to use in any given context. Eventually, one or more new pseudo-opcodes could be used to represent the various Script implementations. All of this is possible if implemented in Script, but adding a new opcode every time a new use-case is conceived would create a constant need for otherwise unnecessary network upgrades. Another way of thinking about it is that we wouldn't want to update the x86 CPU architecture whenever someone conceives of new functionality—Instead, we should implement the building blocks needed to define the new functionality with lower-level constructs.

While I wasn't able to find an example of someone having implemented signature verification, I did find this cool article on the OPPUSHTX pseudo-opcode where ECDSA signature creation in Bitcoin script is discussed. If you can create a signature, I can only surmise that you could also verify one in a relatively straightforward manner. These changes are possible in large part due to the Genesis upgrade, which removed a lot of the limits on script—More on that below.

Let's go back to that OPPUSHTX idea for a second—You can do a lot with it! In particular, one of the coolest uses for OPCHECKDATASIG, Bitcoin covenants, can be done with only OPCHECKSIG. This article by a Bitcoin Cash developer explains how it could even be done on BCH, but due to scripting limitations, things like multi-party transactions would need to be passed around among the signing parties many times in order to get a low enough Sighash value.

Without these Script limitations (which were removed by the BSV Genesis upgrade), this CHECKSIG-only strategy works exceedingly well and even saves one extra signature operation. In the next section, I'll cover some of the other things that changed in Genesis and what that means for the future of Bitcoin.

The Genesis Upgrade

In addition to removing the maximum block size (more on this later), the Bitcoin SV Genesis Upgrade also changed how Script evaluation is metered, re-enabled a few opcodes and provided various other improvements. But out of all the changes, by far my favorite is the restoration of nLockTime and nSequence to their original functionality. This change allows for payment channels, micropayment streaming and other goodies, all without diverging from the original Satoshi protocol.

As I talked about in the previous section, the upgrade also removed the limits on Bitcoin script that have long prevented its widespread use. For example, in BTC and BCH, there is a limit of 201 opcodes per script. This makes certain use cases—such as the 21e8 and BoostPOW family of protocols—impossible.

Things like the Bitcoin Cash OP_RETURN limit have also been removed, meaning that people can put data larger than ~220 bytes on the blockchain. It's fairly common to see pictures, whitepapers and various other files uploaded to the blockchain and stored in the ledger.

A common objection to storing large amounts of data like this in the blockchain is that it "makes money a second-class citizen," but OP_RETURN data is provably unspendable and therefore prunable. This means that it won't bloat the size of the UTXO database.

Miners have an incentive to mine transactions that pay them the most fees, regardless of whether those transactions transfer money, store data or do anything else. BSV believes that it is the role of the market—not protocol developers—to determine which transactions are "second-class," based on their usefulness to the parties involved. In any case, if the creator of a transaction wants it to be mined, he will need give it a high enough fee for it to be scooped up by miners.

If you'd like to learn more about the Genesis upgrade and see what opcodes have been re-enabled, you should check out the specification for a complete list. In general, all limits on script size, transaction size, block size, SogOps per MB of block space and many other restrictions were removed. People argue that making these changes was pre-mature, but in the next section we'll explore the incentives at play and why this isn't the case.

Block Size Limit and Orphaning

As I alluded to earlier, the Genesis update also removed the block size cap by forcing miners to choose a limit they find acceptable. Another common criticism of BSV is that because there is no restriction on block size, the network will experience instability due to orphan blocks. Transactions won't get confirmed causing a complete network shutdown. The BSV network has been operating under the Genesis rules for over 3 months as of this writing, but for those who aren't convinced this will work, let's explore the incentives that prevent this theoretical mass-chaos.

The misconception here is that just because a miner can do something doesn't mean they will do it. If I am a BSV miner with a choice between mining a large block that has a high probability of being orphaned or a slightly smaller block with much lower orphan risk, I'll surely choose the smaller block. Why? Because I would lose money if my larger block got rejected. Each miner independently decides to mine blocks of a size that will earn them the most profit—while keeping in mind that higher orphan risk could mean they get none at all.

This essentially creates a self-regulating market since miners need to produce blocks other miners can easily process. This same rule applies to transactions and the scripts within them. As a miner, I will independently decide on an acceptable script size and transaction size. If my limits are too low, I miss out on revenue from fees. If I set them too high, other miners are more likely to reject my blocks. Additionally, they will only choose to include transactions that other miners will find acceptable and legal.

Laws and Regulations

Another aspect of BSV that Bitcoin Cashers might not find attractive is its comparative friendliness with laws and governmental regulation. In the words of one of my BCH supporter friends, "Bitcoin SV is a bank." There's a general idea that since Bitcoin SV is regulation-friendly, its backers are pursuing the agenda of central bankers. While Bitcoin SV accepts regulatory oversight, the nature of the blockchain means that this can only lead to greater transparency—In fact, Bitcoin SV is no more susceptible to regulatory influence than Bitcoin Cash.

To illustrate, let's focus on the miners. As the network grows and the mining difficulty increases, mining power consolidates into a few small, easily-regulated mining pools. If a regulator—let's take the Chinese government for example—ordered that all miners in China must (a) refuse to mine certain transactions and (b) refuse to accept blocks from other miners who do, all miners who fall under their jurisdiction would be forced to comply with this order or face prosecution.

From here, one of two things might happen: Either the compliant Chinese miners have 51% of the hashing power—in which case the network will follow the order—or the miners in China fork themselves off the network. That being said, if we assume Bitcoin is used around the globe as an international reserve currency, if all of China's miners split away from the global network, China will have effectively cut itself off from the global economy.

This means that the only effective regulatory policy for Bitcoin is global. In other words, more than half of the world's hashing power would need to fall under the jurisdiction of a given regulatory authority in order for transaction reversal to occur. At this stage, nation states will begin to sponsor mining operations to protect their national security interests, but all of this will happen much later—after the widespread adoption phase. For now, I don't personally think any of us need to worry about regulatory intervention.

This applies equally to Bitcoin Core, Bitcoin Cash and Bitcoin SV. People who think cryptocurrency will be able to evade the law and governmental oversight are unfortunately misguided. However, this doesn't mean there will be tyranny in Bitcoin, because a government would need to serve an order on more than 51% of global hash power for it to be effective. Since an order that, for example, tripled the amount of coins in circulation isn't likely to reach this threshold, we're safe on that front too.

Even if we accept that world governments are able to order changes to the ledger (if they can get more than 51% of hashing power), we should recognize that generally, users want this type of regulation in a financial system. If a thief can steal your coins and get away with it, the value proposition for your digital currency project goes down. Fundamentally, people want a fair government to have their backs whether they admit it or not. If this wasn't the case, the U.S. Constitution wouldn't have been ratified and there would be global anarchy.

Of course, this gets political and not everyone in the community will think about things in the same way. But in general, the belief among most Bitcoin Cashers is that governmental oversight for Bitcoin is both tyrannical and impossible. But those who believe code should be law must also endorse the morality and fair-mindedness of the thief who stole $50 million from the DAO in 2016. Code can have bugs and most humans on Earth don't want a political system in which those bugs should rightly destroy people's lives.

What I want people to take away from this section is simply that most humans on Earth would want regulation for Bitcoin. This doesn't mean the government can or should control the money supply, it just means that courts are able to intervene when property is wrongfully stolen. Also, keep in mind that since the blockchain is a public ledger, these governmental actions and orders are completely transparent. Everyone can know what happened and what was done to remedy the situation. This forces courts to make publicly accountable rulings.

Craig Wright

I'll keep the Craig section as brief as possible. The only reason I decided to include it at all is because there are many people in Bitcoin Cash who write off the entire BSV ecosystem because they think Craig Wright represents everyone involved. In reality, many BSV supporters are critical of the things they hear from Craig. The vast majority—myself included—just want a coin with a bedrock-solid protocol where we can build technologies and businesses without limits.

It's extremely easy to write off a cryptocurrency just because of one of its controversial public figures—But that can't begin to paint a complete picture of the many projects and businesses working to build Bitcoin SV. I'm not here for the drama, I'm here because I believe in the power of a self-governing protocol without limitations. If we truly want world money, we'll need to accept that not everyone involved will agree with our own views—So let's get some practice! Whatever you think of Craig, I only ask for you to realize that Craig Wright does not speak for the entire Bitcoin SV ecosystem—He sure doesn't speak for me!

Developers and Power

Before I wrap things up by showcasing some of the ways you can get involved—one final point on protocol developers and power. In Bitcoin SV, we believe that they should have none. Since the project is governed by the original Satoshi rules, it will be much harder to subvert the system by adding anything new. The only remaining changes will re-enable the last few opcodes and eventually revert the mining difficulty algorithm back to its original implementation.

As long as people can agree on this basic premise—embedded in the name and ticker symbol for the project—any attempts to capture the system (such as by introducing a dev tax, which thankfully doesn't look like it'll be happening after all) ought to get outright rejected by all ecosystem participants. While certainly not a perfect remedy, this provides a strong defense for the protocol and some level of assurance that people will be free to leverage the system as it was originally designed.

Cool BSV Projects: How to Get Started

Alright—That's great and all, but just one problem: there are no projects or devs in BSV! No one uses it! Of course, there will always be people who criticize a project for its lack of widespread use, but there are many great projects and developers working to make Bitcoin SV an open and inviting place for crypto- and non-crypto users alike. The fact is, BSV now has more transactions and a larger average block size than Bitcoin Core. This is a non-exhaustive list, so if I miss your project, shoot me a message through this site or drop a comment and I'll be sure and get it added.

MoneyButton

You've probably heard about MoneyButton. It's old enough to have been around before the BSV split, and Ryan X. Charles, it's creator, used to be a fairly prominent and respectable member of the Bitcoin Cash community. Not unlike yours truly, he decided to move his projects and infrastructure onto BSV escape from the controversy, trolling, protocol instability and scripting limitations of Bitcoin Cash. If you haven't already, you can sign up for MoneyButton and begin using it across the web. Most of the other projects on this list use MoneyButton for login and transactions, so signing up is a great way to get a foothold in the BSV ecosystem.

Twetch

Twetch is a new take on social media. It's currently in a "community beta" of sorts, but I was able to register just by giving my email and logging in with MoneyButton. It's a Twitter-like format where you can earn money for the things you post. Liking and sharing content costs money, which is paid back to the content creator. You can set a price for somebody to follow you, and add a "trolltoll" to your posts so that specific users need to pay you in order to post comments. It's a new and interesting platform which you can check out here.

Paymail

Paymail is a specification for letting users tie addresses and public keys to their email addresses. A Paymail address is formatted just like an email address, and it's possible to support both at the same address. You can read the specification here, but if you'd just like to get started, you can pay $1 for a username from MoneyButton, or just host your own like I do. You can also use something like Baemail, which also has some other cool features.

B:// Protocol and BitcoinFiles

This section is all about reading and writing large files to the blockchain. The B:// protocol is a specification for putting files on chain and specifying their MIME types, among other information. To check out the latest file uploads, BitFS can show you the list filtered by file type. If you'd like to immutably upload a file, try BitcoinFiles or BitPaste. For uploading bigger things, Bico.media works great.

Bitbus & Bitsocket

If you're building Bitcoin SV apps, Bitbus and Bitsocket provide scalable, filterable views of the blockchain and its transactional data. They both use Bitquery, a blockchain query language that's actually been around since the BCH days. Bitbus is the successor to Bitdb with significant scalability improvements. If your OP_RETURN protocol uses Bitcom, this makes it easy to filter out only the transactions in your namespace. These are the tools I recommend for getting started learning and building on Bitcoin SV for developers.

21e8 & BoostPOW

The BoostPOW White Paper introduces the idea that as more information becomes available online, we will need a good and provable way to sort through all of it. The paper describes the process of "boosting" information by using proof-of-work to increase its exposure to others. It proves that looking at information with more proof-of-work behind it will increase the quality of information you view, because people needed to spend energy in order to bring it to the top of your list. The 21e8 project is an earlier rendition of this same idea, while pow.market allows people to "buy magic numbers" from people who mine them with 21e8miner.

Computing with Integrity (my project)

Yep—I'll admit it. This, right here, is a big hunk of shameless self-promotion. Computing with integrity is (will be) a decentralized computing platform where all your social accounts, documents, contacts, wallpapers and apps are seamlessly accessible across all your devices. Eventually, the idea is to also allow running apps to move between systems without being interrupted. Originally I wanted to use BCH for this, but since storing entire filesystems on-chain (except for the large files) creates insane numbers of transactions, a coin with a larger OP_RETURN size and 0.5 sat/b transactions simply made more sense for the project. You can read the paper here.

Developers' Chatroom

I've heard from many in Bitcoin Cash the argument that "BSV has no devs!" But then when I check the place where all the BSV devs hang out, I don't see any of those people in the chat rooms! If you read some of the docs (Bitbus, Planaria etc), you'll easily be able to find the BSV dev hangout spot. I won't link to it here, but there are plenty of active projects (beyond the ones I link to above) where cool new things are being built with BSV every day.

Conclusion

Bitcoin Cash and Bitcoin SV have both come a long way over the past 2 years. I hope that by giving you more information and attempting to "pull back the iron curtain" so to speak, I can encourage developers to do more research and evaluate the merits of both projects. If you want a stable, unchanging protocol without limits, you should consider Bitcoin SV for your next project—especially if you want to put insane amounts of data on the blockchain like me.

I hope this guide has been informative—If you've got unanswered questions, get to the asking! On the other hand, if you've got unquestioned answers—well—I hope you start to question the things around you so that you can find the right path. This world of consensus controversies, blockchain battles and Satoshi scandals is sure unlike anything I've ever experienced. Wherever you stand, whichever project you support, I wish you success and prosperity.