A deep dive into Lopp’s ‘On BSV scalability’

This post was first published on Medium.

We investigate claims made by BTC evangelist Jameson Lopp in his recent article On BSV Scalability. We focus on technical and objective arguments, instead of philosophical differences such as users running a node and decentralization, which are subjective and more difficult to settle.

BSV transaction characteristics

He cherry-picks the 1GB block at #699154, containing only 10,136 transactions and 14,566 inputs, misleading readers into believing BSV can only handle large data storage blocks, where transaction validation is skipped.

He omits blocks that contain more than one million transactions and thus over one million inputs. For example, block #635141 has 1.3M transactions, ~200X that of BTC’s mere 7K. There is also block #634643 of 1.1M transactions, among others.

Parallelism

require over 600X as much resources to validate. That would mean a 1 GB block would take an expected 100 minutes for my machine to validate.

This is a rudimentary error. Even if we assume a block requires 600X resources to validate as claimed, it does NOT mean it necessarily takes 600X time to validate, because validation can be parallelized. In fact, parallel processing is at the core of on-chain scaling. If we look at block #635141, it should take about 100 * (370 MB / 1 GB) = 37 min to validate by his logic, while it only takes 13 min to mine in reality¹.

A “deep dive” on BSV scalability has managed to miss the most important part of its scalability: parallel tx/block validation.

Run

Run appears to be a smart contracting language that lets you create tokens, contracts, and other digital assets.

Run is based on Javascript, NOT a smart contracting language. Anyone visiting their homepage will find Javascript prominently displayed. Either he has not even visited their homepage or he does not recognize Javascript, which is surprising for a web developer turned BTC influencer.

Source: RUN

Maybe he mistakes Run for sCrypt, which is indeed a smart contracting language.

Coin Dance

One thing I noticed while researching BSV for this report was that coin.dance shows stats for the other major bitcoin forks but not for BSV.

If one actually clicks the link, Coin Dance DOES show stats for BSV, as comprehensive as other forks. The above statement is blatantly false. I figure I’m the first person to notice this because nobody bothers to read his article.

Source: Coin Dance

He resorts to an old picture from Wayback machine to mislead readers into believing Coin Dance gives up on BSV “Presumably because they simply can’t handle the data volume.”

Blockchair

I’m seeing similar issues on other services / block explorers such as blockchair.

He claims blockchair gives up supporting BSV due to high costs. He goes on to quote stats from blockchair in the next paragraph, immediately contradicting himself. You can find BSV at blockchair, along with many other blockchains.

Source: Blockchair

OP_RETURN

What is OP_RETURN? It’s is a script opcode used to mark a transaction output as invalid

OP_RETURN in BSV has been reverted to its original meaning: it terminates the script leaving the stack as-is and letting the result on top of the stack determine the success or failure of the script. Thus, if the top stack is non-zero, it is regarded as successful. It does not always fail as in BTC, which he still thinks.

While he is learning about the updated OP_RETURN, he may also be interested to learn many opcodes which have been re-enabled since the Genesis upgrade. It allows advanced smart contracts which are deemed impossible on Bitcoin without breaking changes, such as:

• Schnorr Signatures
• Merklized Alternative Script Trees(MAST)
• Pay to Script Hash (P2SH)
• Covenant
• Tree Signatures

Conclusion

We applaud Lopp’s empirical approach to study BSV scalability, by running a node and measuring its performance. We encourage him to continue exploring powerful BSV features, which are only going to grow. We would like to return the favor when BTC has any feature worth exploring.

***

NOTE:

[1] Timestamp 5:57–5:44 = 13 min, assuming block timestamp is more or less accurate at minute granularity.