Bitcoin's headroom

How batching transactions gives BTC room to grow without Segwit2x

Evan Rose & Brandon Rose
November, 2017

Overview

The highly contentious Segwit2x fork, planned for a November 15 release, increases block size from 1MB to 2MB. This risks creating another blockchain, undermining Bitcoin's security by stealing its hashrate and user base, and confusing the public as to the long-term viability of Bitcoin. Is this really necessary?

The short answer is a resounding no. We can demonstrate that both transaction fees and pressure on the 1MB block size limit can be managed through intelligent batching of transactions. Despite a spike in transaction fees in August, 2017, major players in Bitcoin did not take advantage of the fundamental ability to include multiple outputs for a given transaction. If the majors in the Bitcoin ecosystem focus on optimizing their software instead of breaking Bitcoin they could reduce overall transaction fees and ease pressure on the block size limit.

The rise in transaction fees

Since the start of 2017 Bitcoin (BTC) has witnessed an unprecendented and volatile rise in transaction (tx) fees. This is primarily driven by increased competition for transaction inclusion into a block. Given the 1MB block size limit, miners select those transactions with the highest fees to include in the blocks they attempt to mine.

Theoretically, transaction fees should be purely supply and demand driven. In this case supply is constrained (the number of blocks mined per day) and demand potentially unlimited (the number of transactions broadcast across the network per day).

Based on the average total transaction fees per block, by the end of August a miner earned over 4 BTC in transaction fees per block. Given a block reward of 12.5 BTC per block, this means that 25% of the value of mining the block was derived from transaction fees--a nontrivial amount.

Transactions hold strong

Since August, transaction fees have returned to baseline. But what happened with the volume of transactions during this period? We can see that the transaction fee cost hike was largely driven by an increase in the total number of transactions.

Despite the hike in fees, the volume of transactions did not correct. The implication is that the transactions broadcast to the network were of sufficiently high value to justify the expense incurred in conducting the transaction (through transaction fees). The utility of actually transacting outweighed the rising costs to transact.

The implication is that the transactions broadcast to the network were of sufficiently high value to justify the expense incurred in conducting the transaction. The utility of actually transacting outweighed the rising costs to transact.

This suggests two things:

  1. Activity on the Bitcoin blockchain may be increasingly driven by high-value, real (i.e. non-speculative) transactions
  2. Increased demand by users to have transactions included in blocks will cause demand pressure due to block size limit

Cost savings through batching

One critical and often overlooked component of Bitcoin's transaction functionality is that it enables a single transaction to have multiple inputs and multiple outputs. This is important because it allows a user to "batch" transactions together. Consider the scenario where Sally needs to pay 0.5 BTC to both Jim and Susan. She could send two transactions, each worth 0.5 BTC. But, she'd have to pay two transaction fees at the network clearing rate. Alternatively, Sally could batch the two transactions into one transaction with 1.0 BTC as its input and two 0.5 BTC outputs. She'd then only need to pay one transaction fee. Logically, we would expect that as transaction fees rise, users would increasingly batch transactions together into single transactions with multiple outputs in order to reduce transaction costs.

Yet, the number of outputs per transactions trended only marginally higher. When we look at the ratio of outputs per transaction (see chart below) we can determine that few users chose to implement this cost saving measure.

When shown together it becomes even more apparent that number of outputs per transaction scaled with the number of transactions per block. Given the increased transaction fees we would expect to see the number of outputs per transaction diverge from transactions per block as batching adoption increased.

Space savings through batching

Putting aside cost savings to our user Sally, let's consider the impact on block size of sending two transactions versus one transaction with two outputs. A basic transaction requires 226 bytes. Of this, 34 bytes are required for the first output. Adding a second output to a transaction increases its size from 226 bytes to 260 bytes. Each additional output added to the transaction only adds 34 incremental bytes to the transaction size.

Conversely, creating a second transaction requires doubling the original transaction size (226 x 2) or 452 bytes. See the problem? For each output that could be batched but isn't, unnecessary pressure is applied to the block size limit and transaction fees are needlessly inflated. By incorporating batching more can be done with each Bitcoin block because the overall ratio of outputs per transaction will increase and the relative byte size of each output will decrease.

Interestingly, the spike in transactions in August could have been driven in part by the low transaction fees at the beginning of the month. Low fees may have led to the increase in transactions; if some of these transactions were contractual obligations then users who were lulled into committing to transact later in the month by low fees early in the month could not escape these costs unless they incorporated batching.

Verifying our results

To verify that major Bitcoin platforms have not implemented batching we tried sending a small amount of Bitcoin from a Coinbase wallet to another wallet. We sent 0.00134 BTC ($10 at the time of writing). Coinbase automatically added a 0.00065960 BTC transaction fee ($4.93). In this case the cost of the transaction fee is nearly 50% of the value of the transaction.

0.00134 BTC sent from Coinbase to another wallet

Next, we inspected the transaction on BlockCypher to determine whether our transaction was batched with others.

BlockCypher transaction analysis

This transaction was clearly not batched. A 0.00134 BTC output was sent to our wallet and 0.00000929 BTC was returned to Coinbase as change. This is extremely inefficient for three primary reasons:

  1. Had this transaction been batched with others we would not have had to pay such an exorbitant transaction fee
  2. Had this transaction been batched with others more outputs could have been included in the block
  3. Perhaps worst of all, the change amount (0.00000929 BTC) is smaller than the minimum amount that can be sent on the blockchain (0.00005460 BTC). This is, simply put, bad business since the change amount is unusable Bitcoin.

Conclusion

Major players in Bitcoin, such as Coinbase, have simply not developed batching technology. This drives up transaction fees for everyone using the Bitcoin network and puts pressure on the block size limit. Bitcoin has plenty of head room if key players manage transactions, outputs, and fees intelligently. Let's see that happen.