The talk ‘20 Million Txs Per Day: Writing Data to the World’s Largest PoW Blockchain’ was the first of two presentations representing Bitcoin SV at the WeAreDevelopers Congress in Berlin on the 14th of June. Connor Murray, Founder of Britevue and Bitcoin SV Academy Course Content Creator, Kurt Wuckert Jr, Founder of Gorilla Pool and Chief Bitcoin Historian for CoinGeek and Jad Wahab, Director of Engineering at Bitcoin Association, held the presentation and answered questions from the audience.

Since the hash war that separated Bitcoin Cash and Bitcoin SV, the goal was to provide the world with a scalable blockchain that can be adopted on a global scale. Bitcoin SV has reached a state where it is regarded as an ‘enterprise-grade ready blockchain’ (Patryk Walaszczyk, Blockchain Solutions Expert at IBM Consulting). The most recent efforts were targeted at making Bitcoin SV more easily accessible regarding adoption, development and usability. Very recent examples of that are the Solidity Transpiler and the LiteClient Toolbox.

At the WeAreDevelopers Congress, the Bitcoin Association for BSV promoted the unmatched scalability and utility of Bitcoin SV. The first stage session illustrated this by choosing the subject ‘20 Million Txs Per Day: Writing Data to the World’s Largest PoW Blockchain’.

Bitcoin SV: a record-breaking Proof-of-Work blockchain 

Connor Murray

Connor Murray was the first to take the stage, giving a general introduction to Bitcoin SV. He briefly summarised the history of Bitcoin and stressed the utility aspect of Bitcoin SV, which no other blockchains provide at scale. On top of that, Bitcoin SV’s protocol is set in stone like TCP/IP. It is an important aspect of Bitcoin SV, as this allows to build applications and businesses on top of Bitcoin SV without fear that the protocol will change in the future.

Murray then talked about the scalability of Bitcoin SV in more detail, he explained the title of the talk: 

‘Bitcoin SV has set numerous records as far as transaction throughput. That’s why the title of the presentation is 20 million transactions a day. That has happened on Bitcoin SV already. And we believe that we can scale unboundedly into the future.’

Murray went on to talk about how these 20 million transactions per day are only enabled by the unlimited block-size of Bitcoin SV’s blockchain. That proof-of-work is wasteful, because of its high energy-consumption, is a misconception. As data from coincarboncap.com suggests, Bitcoin SV is not only the largest proof-of-work blockchain, but also the most energy-efficient. As the ecosystem continues to grow, so will BSV’s efficiency continue to improve.

Sysadmin or developer? – Cooperation between miners and developers on Bitcoin SV 

Kurt Wuckert Jr.

Kurt Wuckert Jr., Founder and CEO of Gorillapool, introduced his talk by asking the audience whether they would like to become sysadmins in order to be able to develop:

‘Who here would be interested in building on a blockchain as a developer? Curious, right? Now, what if you had to be an infrastructure partner in order to even begin to develop? Do you want to learn about and then deploy infrastructure on a blockchain network like you’re managing the stack? You have to be a sysadmin, you have to keep yourself in consensus. You have to do all these other things. Do you want to be a sysadmin or do you want to be a developer? You want to be a developer, right?’

Here, Wuckert alluded to how other blockchains are organised – requiring developers who build on these blockchains to participate in their consensus model, e.g. by running a node and processing transactions. Therefore, in addition to their original profession as developers, they also have to invest time into other skills that are required when you process transactions and maintain a blockchain. If you want to scale on a global level, average developers will likely run into problems when you need to process terabytes of transactions. The argument that proof-of-work does not scale is only valid if you imagine average users or developers in this case to be infrastructure participants.

As the CEO of Gorillapool, one of several mining pools in the Bitcoin SV network, Kurt Wuckert stressed how the easiest solution to that problem is to allow others to maintain the infrastructure. He went on to explain what mining is about and what it is capable of on Bitcoin SV. The largest blocks in the history of Bitcoin were mined on Bitcoin SV with more than 2.5 million transactions in one single block. It is exponentially more than what BTC and BCH are capable of. By scaling on-chain Bitcoin SV can already manage a transaction throughput of about 10 – 20,000 transactions per second. In the future, much higher figures will be possible.

Wuckert then ventured into the prejudice that proof-of-stake is a faster consensus model than proof-of-work. He went on to say that network speed is not determined by the consensus mechanism per se, but by node connectivity. This quality is tainted on Ethereum as its system requires you to run a node for the sake of decentralisation if you want to build on Ethereum.

Wuckert explained how decentralisation is only a desirable quality in a blockchain as long as it adds to security. However, above a certain limit it is arbitrary to push for further decentralisation and even decreases utility. He concludes that proof-of-work is inefficient when you are forced to run a node or when you are required to have the blockchain on your own computer, although your primary goal is to build on a blockchain or to run a service on it.

Furthermore, proof-of-work is often seen as a wasteful and unnecessarily competitive consensus mechanism. Kurt Wuckert highlighted a different aspect in the discussion; Conceived in the right way, proof-of-work incentivises cooperation. Miners want to become reputational within the ecosystem and are eager to work with their clients as partners.

Wuckert concluded that requiring developers to become nodes is a major roadblock in the scalability of blockchains. This roadblock is easily removed by letting professional miners take care of that side of the business. The question is now: How do you interface with the blockchain?

Simplified payment verification for users

Jad Wahab

Jad Wahab started his talk by referring to Bitcoin’s white paper and that simplified payment verification (SPV) is mentioned in its own separate paragraph as a future possibility. This paragraph has largely been ignored on all other blockchains, but with LiteClient Toolbox, Bitcoin SV provides users with a solid and standardised solution for this. One important reason for this, is that other blockchains lack scale in the first place.

To illustrate SPV and the underlying issue it addresses, Jad Wahab compares the blockchain to other technologies. One of which is the example of email: 

‘So that design from the start supported users, just being users. Nodes, on the other hand, were always tending towards becoming like server farms. So this is a bit similar to if you use email or anything like that; you don’t need to run your own mail server for just to get started with an application. You don’t need to download the entire world’s emails, if you just want to use email yourself.’

SPV in the form of the LiteClient toolbox allows you to become a user of the blockchain. Being a user of the blockchain means to simply send and receive payments and to write or read data to/from the blockchain. Running a node, on the other hand, would resemble someone using a helicopter to cross the road.

To facilitate simplified payment verification, proof-of-work is required. The reason is simply that it is scalable, and SPV is a display of that scalability. In order to explain this, Wahab explained the blockchain in a very fundamental way. You can see it as a global timeline of events as every single piece of data is time stamped and a new block is created every ten minutes.

Simplified Payment Verification (SPV) relies on the block headers that every block has. They have an anchored root of all transactions with a data size of 80 bytes. To verify them, you simply have to put them through a hash function, if the header hash is below a certain target, it is valid.

The same principle would be hard to replicate on proof-of-stake, as Wahab outlined:

‘There hasn’t been any code written for lite clients, SPV clients on proof-of-stake and the reason why is that it’s really difficult to do. You have to basically track at every block who the miners are that staked the coins. You need to validate their signatures. They change over different blocks. So it just gets really tough to do. And if you want to scale, basically the message is if you want to scale to users, to global adoption, you need something like proof of work.’

The bottom line is that proof-of-stake is more complex than proof-of-work. Therefore, something like SPV/LiteClient is not only hard to realise, but the network as a whole also becomes more complex. In general, complexity creates attack vectors making the network more insecure. Therefore, proof-of-work is required to scale for global adoption as a simple and elegant solution to verify transactions.

This also provides further incremental value if we see the blockchain as a global source of truth that timestamps any kind of data and verifies it. Thus, even in 100 years of time people that have the block headers can ensure they have the same verified data on the blockchain. While not having data on the blockchain, possibly means that it will fade away in data silos.

PoS, on the other hand, allows the blockchain to get corrupted more easily, it corrupts the blockchain as a whole as a source of truth. 

So at this point in time at which we have a scalable blockchain, the missing link was SPV. Something that makes the blockchain easy to use and that allows users (as payers and receivers) to make transactions and send them to the blockchain via LiteClient. The LiteClient Toolbox consists of four different components:

• Wallet – enables key and UTXO (Unspent Transaction Output) management.
• Block Headers Client – collects and maintains an up-to-date copy of the longest chain of block headers, which can be used to validate transactions.
• Direct Payment Protocol (DPP) – defines a standard language (via API) for senders and receivers of payments to communicate with each other and the Bitcoin network. This includes creating connections to Bitcoin nodes through a node/miner interface and extensions such as the Paymail Server and Peer Channels.
• Direct Payment Protocol Proxy (DP3)

The Toolbox also tackles interoperability – NFTs on specific wallets, multi signatures, different protocols and standards. It is another way to use Bitcoin SV as a global source of truth, a backend so to speak that connects to innumerable frontends that interact very differently with the blockchain.

Michael Sprick
Sprick