Towards Massive On-Chain Scaling: Block Propagation Results With Xthin

Part 5 of 5: Massive on-chain scaling begins with block sizes up to 20MB

7 min readJun 13, 2016

By Andrew Clifford, Peter R. Rizun, Andrea Suisani (@sickpig), Andrew Stone and Peter Tschipper. With special thanks to Jihan Wu from AntPool for the block source and to @cypherdoc and our other generous donors for the funds to pay for our nodes in Mainland China.

In this post, we conclude our 5-part series with a discussion of why we believe Xthin can be leveraged today to facilitate up to 60 on-chain transactions per second (tps) and 20 MB blocks. This would provide significant relief for the currently-congested network (limited to 3 tps) and breathing room for off-chain scaling solutions to mature. We end with a peek at what’s coming next from Bitcoin Unlimited.

60 transactions/sec, 20 MB blocks

“With Xthin, efficient block relay is now a reality.”

What an interesting journey this article series has been! In Part 1, we described how Xthin fixed a long-standing inefficiency in Bitcoin Core where transactions were often received twice by each node: once when the transaction was first broadcast by a user, and then again when the node later downloaded the solved block containing that transaction. This inefficiency resulted in blocks that propagated slowly and consumed a lot of bandwidth. By compiling statistics for over 9,000 blocks transmitted across the real Bitcoin network, we proved that Xthin blocks were faster (Part 2), less affected by the Great Firewall of China (Part 3), and smaller (Part 4) than standard blocks. (We even took a detour last week to debunk an alleged attack vector.) With Xthin, efficient block relay is now a reality.

Fig. 1. Based on statistics from over 9,000 blocks transmitted across the real bitcoin network. Xthin blocks are faster, less affected by the Great Firewall of China, and smaller than standard blocks.

These properties of Xthin precisely address the bottlenecks to on-chain scaling identified by the only data-driven studies our group is aware of: the position paper on scaling by Cornell and the “Block Size Olympics” study by Jonathan Toomim.

The Cornell Position Paper

The Cornell paper identified block propagation to nodes as the dominant bottleneck. They argued that for a given block size, a portion of nodes would be unable to download blocks within the 10 minute block-time target and thus continually fall further and further behind. Based on real measurements of block propagation across the Bitcoin network, the authors calculated that at an average block size of 4.1 MB, 10% of the network nodes would be unable to keep up, while at an average block size of 37 MB, half of the network nodes would be left behind. They suggested that the size of blocks should not exceed 4 MB.

“Block propagation to nodes was the bottleneck. Xthin fixes that.”

Jonathan Toomim’s Block Size Olympics

Prior to the Cornell paper, Jonathan Toomim had spearheaded a study referred to as the “Block Size Olympics” where he also concluded that the network in its present form could safely support 4 MB blocks. Toomim measured the propagation time for hundreds of Testnet blocks up to 10 MB in size using twenty different nodes, three of which lay on the Mainland-China side of the GFC. Like the Cornell paper, what drove Toomim’s suggestion for a 4 MB limit was inefficient block propagation to nodes — particularly those separated by the GFC.

Xthin Fixes the Bottleneck

Block propagation to nodes was the bottleneck. Xthin fixes that. If 4 MB blocks were safe using standard block propagation, then significantly more than 4 MB should be safe if Xthin were widely deployed.

Fig.2. Both the Cornell position paper and the Toomim “Block Size Olympics” study suggested that blocks should not be greater than 4 MB (12 transactions per second). The bottleneck according to both studies was block propagation to nodes. Xthin fixes this bottleneck, in our opinion safely permitting blocks up to 20 MB in size (60 transactions per second) when used together with Xval. This amount of on-chain scaling provides ample breathing room for off-chain solutions to mature.

Xthin improved block propagation times to nodes by a factor of 5.6 (normal P2p) and by a factor of 9.7 through the GFC. It also reduced bandwidth requirements during block propagation by a factor of 24. Simple ratio-based estimates would point to a new limit of 22 MB using the 5.6X number, 39 MB using the 9.7X number, and 96 MB using the 24X number. (The Cornell paper suggests that the transaction-verification and disk-I/O bottlenecks are significantly beyond 4 MB so we expect the bottleneck to remain bandwidth related).

“We are comfortable setting our nodes to accept up to 20 MB blocks today.”

Bitcoin Unlimited rejects the the notion that a protocol-enforced block size limit is required. Instead, it provides tools to facilitate the emergence of an “effective limit” that changes when needed, as each node operator adjusts his or her max block size setting using the best information he or she has on hand. With Xthin and the other improvements made to Bitcoin Unlimited (including Xval), and with the information we have gained by conducting these experiments, we are comfortable setting our nodes to accept up to 20 MB blocks today.

Everybody Loves Xthin

“Developers from all implementations including Classic, Core and XT not only agree that it was a great idea, they also want to implement it (or something very similar to it) in their implementations too.”

Six months ago, efficient block relay to nodes was only an idea. The debate at that time was whether or not it was even a good idea.

Thanks to the tremendous efforts by Peter Tschipper, @sickpig and Andrew Stone, efficient block relay is now a reality. Developers from all implementations including Classic, Core and XT not only agree that it was a great idea, they also want to implement it (or something very similar to it) in their implementations too.

Fig. 3. With only minor code modifications, developers can add and remove features from Xthin to meet the needs of their customers.

The development community is now debating the details.

For example, some developers are interested in trimming bytes by removing the Bloom filters (at the expense of longer propagation times and more rounds trips) and some want to add salting to the hashes as an extra safety precaution (at the expense of additional CPU cycles and code complexity).

“Let the free market bike-shed over the details.”

A central tenet of Bitcoin Unlimited is that the network should evolve based on the code people freely choose to run. In line with this philosophy, we believe that all flavors of Xthin should be deployed for which there is both demand from users and interest by developers. Let the free market bike-shed over the details.

A Peek Inside the Bitcoin Unlimited Laboratory

Below are four projects currently in the works. Anyone is welcome to join Bitcoin Unlimited and help contribute to these ideas (or bring your own idea)!

Optimistic Mining

Optimistic Mining refers to the act of mining off the block headers after the proof-of-work has been checked but before the entire block has been downloaded and verified. Miners that use optimistic mining have a small profitability advantage over miners that do not. The technique also breaks all alleged ‘attacks’ that rely on slowing down the blocks of a miner’s competitors. Optimistic Mining — a term coined by Thomas Zander — is based off the “headers-first” mining technique pioneered by Gavin Andresen.

eXpedited Block Relay

eXpedited Block Relay is aimed towards latency-conscious mining- and relay-nodes. Rather than using Bitcoin’s inv/getdata method like Xthin, a Bitcoin Unlimited node sends thin-blocks to peers who subscribed to eXpedited service without first inquiring if the peers wanted them. This results in block transfers in as few as 0.5 round trips at the expense of increased bandwidth consumption.

“Long Tail” Block Propagation Times

During our empirical studies of block propagation, we saw a small number of blocks that took an inordinately long time to propagate. This problem may stem from multiple disparate causes ranging from connectivity issues with global networks, GFC traversal, and bugs in the software. In many physical engineering disciplines it is standard practice to feed empirical results back into the design, creating an iterative design process. While the Bitcoin client is simply a computer program, Bitcoin as a whole is a complex system implemented on an internet that consists of physical optical and copper networks connecting data centers and homes worldwide. We believe that an empirical, redesign feedback loop will be very effective in optimizing Bitcoin-as-a-whole and are beginning our iterative redesign by investigating these “long tail” block propagation times.

Subchains

Subchains are an application of weak blocks that reduce orphaning risk and improve zero-confirmation security. Subchains could work together with Xthin to facilitate on-chain scaling to 100 MB blocks and beyond.

“Anyone is welcome to join Bitcoin Unlimited”

The End

Lastly we wish to thank our readers and the Bitcoin community. It is your dedication to seeing this grand experiment change the world that keeps the whole thing moving along.

Donations

For advancing On-Chain Scaling projects at Bitcoin Unlimited, please consider making a donation to 36XTMVtgJqqNYymsSvRonpUsbZRGkm1jvX to help us keep our VPS network running, including our nodes in Shanghai and Shenzhen. Donors who contribute 1 BTC or more will be personally thanked in a future article.