Bitcoin Blockchain Performance and Scalability

Bitcoin is a decentralized electronic cash system that makes peer-to-peer payment possible without going through an intermediary. The original Bitcoin software was developed by Satoshi Nakamoto, released under the MIT license in 2009, following the Bitcoin whitepaper, Bitcoin: A Peer-to-Peer Electronic Cash System. Bitcoin is the first successful implementation of a distributed cryptocurrency. Ten years after Bitcoin was born, as of December 2019, it has about 18 million Bitcoins in circulation and it has reached about a 132 billion market cap.

In Bitcoin, a transaction is a collection of inputs and outputs transferring the ownership of Bitcoins between payer and payee. Inputs instruct the network which coin or coins the payment will draw from. Those coins in the input have to be unspent, which means they have not been used to pay someone else.

Outputs provide the spendable amounts of Bitcoins that the payer agrees to pay to the payees. Once the transaction is made, the outputs become the unspent amounts to the payee; they remain unspent until the current payee pays someone else with the coin.

When, for example, Alice needs to pay Bob 10 BTC, Alice opens her Bitcoin wallet, and scans or copies Bob’s transaction address and creates a transaction with a 10 BTC payment to Bob. Once the transaction is digitally signed and submitted, it is sent to the Bitcoin blockchain network:

Once the transaction is broadcasted to the Bitcoin network, the bookkeeper node, usually a full node in a P2P network that receives the transactions, will validate it according to Bitcoin protocol rules. If the transaction is valid, the bookkeeper will add it to the transaction pool and relay the transaction to the peers in the network. In a Bitcoin network, every 10 minutes, a subset of network nodes, called “mining nodes” or miners, will collect all valid transactions from the transaction pool and create the candidate blocks. They also create a Coinbase transaction for themselves to get rewarded and collect transaction fees, in the event they win the mining race and add the block to the chain, all nodes will verify the new block and add it to their own copy of the blockchain. Magically, Bob will be able to see the payment from Alice and 10 BTC in his wallet.

One of the major concerns in the Bitcoin network, or in general for any PoW-based blockchain is scalability. By design, every transaction has to be verified by all nodes, and it takes about an average of 10 minutes to create a new block with the block size limited to 1 MB. Block size and frequency limitations further constrain the network’s throughput. As a result, a Bitcoin block is able to accommodate around 2700 transactions on average.

With today’s payment systems, VISA is able to handle on average around 2,000 transactions per second (tps), the daily peak rate is around 4,000 tps. Paypal handled an average of 115 tps in late 2014, around 10 million transactions per day.

Clearly, achieving Visa-like capacity on the Bitcoin network isn’t feasible today. To achieve the network’s higher performance and better scalability, it requires increasing the network’s transaction processing limit and making the software enhancements for the Bitcoin network.

There is the blockchain scalability trilemma regarding its capability to address scalability, decentralization, and security, without compromising any of them. The trilemma claims that it is almost impossible to achieve all three properties in a blockchain system.

The following diagram is an illustration of the scalability trilemma in the blockchain:

The key challenge of scalability is finding a way to achieve all three at the base layer. The design choices of Bitcoin favor decentralization and security, while making a sacrifice in scalability.

Bitcoin scaling solutions

There are many Bitcoin scalability solution proposals, it can further be divided into On-chain scaling and Off-chain scaling.

On-chain scaling

On-chain solutions, sometimes also called layer 1 solutions, are to look for solutions to address scalability and performance issues at the base layer of the Bitcoin blockchain network. With on-chain scaling, It refers to the solution of the latency of the network. It provides a way to be able to handle more transactions in the blockchain, Segwit is an example of that by processing more transactions in a block of 1MB. Or just simply by raising the blocksize, as Bitcoin Cash did.

Segwit

Segwit is a Bitcoin Improvement Proposal number BIP14, it is short for segregated witness, which means to separates the digital signature for the transaction. It was first introduced by Developer Pieter Wiulle at the Scaling Bitcoin conference in December 2015. The purpose of SegWit was to prevent nonintentional Bitcoin transaction malleability, allow optional data transmission, and to bypass certain protocol restrictions.

A Bitcoin transaction comprised of three things: a transaction input, a transaction output, and an amount with digital signatures.

The transaction input is the Bitcoin address from who sent it.

The transaction output is the Bitcoin address to who receives it.

The amount is the amount of Bitcoin that was sent with a digital signature that verifies the sender is eligible to send the coins.

The transaction identifier changes if the digital signature changes. It turns out that Bitcoin’s code allows digital signatures to be altered when a transaction is still unconfirmed. Once a transaction is added to the network, the transaction, including the signature, becomes immutable. The signature alteration is done in a way that if you run a mathematical check on it, it is still valid by the network. However, when you run a hashing algorithm on it, it gives a different result.

Let’s take a look at an example,

Input:

Previous tx: p9k5ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6

Index: 0

scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10

90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:

Value: 2000000000

scriptPubKey: OP_DUP OP_HASH160 201371705fa9bd789a2fcd52d2c580b65d35549d

OP_EQUALVERIFY OP_CHECKSIG

The input in this transaction imports 20 BTC from output #0 in transaction p9k5e… Then the output sends 20 BTC to a Bitcoin address (expressed here in hexadecimal 2013… instead of the normal base58). When the recipient wants to spend this money, he will reference output #0 of this transaction in an input of his own transaction.

• Previous tx — an identifier of the previous transaction to the address A;

• Index — input number (here we have only one input number 0);

• scriptSig — first part of the validation script (contains a transaction signature);

• Value — the number of Bitcoins to send in satoshi (one bitcoin = 100 millions satoshi) — 20 bitcoins in the example;

• scriptPubKey — second part of the validation script, which also contains the receiver address B.

To verify that one can spend the amount of the previous transaction, it needs to check combine the scriptSig of a new transaction with the scriptPubKey of the previous transaction, to make sure the result is true and valid.  scriptPubKey simply checks the equality of the public key and the validity of the signature – OP_CHECKSIG

In a Bitcoin transaction, txid is a sha256d hash of all the fields of the transaction data. The value of txid depends on scriptSig.

During a mining node process transaction, the node can mutate scriptSig that the signature will stay valid, the transaction will have the same effect, but txid will change.

For example, one can add a OP_NOP operation (that does nothing). Or for some sophistication, one can add two operations: OP_DUP OP_DROP (the first one is duplicating the signature on the stack, and the second one removes it again). The signature is still valid, but txid changes.

Another example like signature value was “3”, but we can change it to “03” or “3+7-7”. Mathematically, it’s still the transaction value with a valid signature, but there are different hash results since hashing depends on how you write the value and not the value itself.

Mutable transaction id for an existing transaction can be problematic for a number of reasons:

If you want to build second layer solutions on top of the Bitcoin network, like the network, you need to make sure no one can alter the first layer since it relays on it.

Modifying txid can cause issues if you’re spending or accepting unconfirmed funds.

How SegWit solves the problem:

In SegWit, all the malleable information is separate from the transaction into a separate “witness data”. When computing txid, it will not include this malleable information, in this case, the identifier will never be able to change, the problems will be fixed. Here is an Segwit transaction output example:

Index 0

Details

Output

Address

35SegwitPieWKVHieXd97mnurNi8o6CM73

Value

1.00200000 BTC

Pkscript

OP_HASH160

2928f43af18d2d60e8a843540d8086b305341339

OP_EQUAL

Sigscript

0014a4b4ca48de0b3fffc15404a1acdc8dbaae226955

Witness

30450221008604ef8f6d8afa892dee0f31259b6ce02dd70c545cfcfed8148179971876c54a022076d771d6e91bed212783c9b06e0de600fab2d518fad6f15a2b191d7fbd262a3e01

039d25ab79f41f75ceaf882411fd41fa670a4c672c23ffaf0e361a969cde0692e8

We can see that there is witness information, the data include all the malleable information. Sigscript have much less hash information compared to the previous example without the Segwit transaction. This also means it reduces a Bitcoin transaction size and improves transaction speeds by removing the witness data from the original portion and appending it as a separate structure at the end.

Here is some benefit with Segwit:

Node performance – The transaction size is reduced, the Bitcoin network is less congested so that nodes can verify blocks, or transactions, quicker.

Transaction malleability – As we discussed, with Segwit,  the signature moved from the transaction data to a witness data block. Transaction id (txid) is immutable and protects transaction data from being hacked.

Linear scaling of signature hashing operations – By reducing transaction size, we can add more transaction data for a certain transaction as a batch. Segwit separates transaction signatures out from transaction data so that each byte of a transaction only needs to be hashed no more than twice.

Increased security for multi-signature transactions – SegWit provides two different scripts; one to a public key and another directs payments to a script hash. With combine these scripts, Segwit boosts security by enabling a multi-signature transaction.

Building on top – SegWit is great for the Bitcoin development of second layer protocols, like its lightning network. SegWit activation also boosted development work on other features such as MAST (which enables more complex Bitcoin smart contracts), Schnorr signatures (which would enable another transaction capacity boost) and TumbleBit (an anonymous top-layer network).

Protects Lightning Network – Lightning Network Micropayment channels rely on double-signed transactions to lock the initial deposits. To start a Lightning Network payment, the funds from both parties are sent to one double-signed address. To prevent cheating, the transaction should be double-signed before any funds are actually sent there. Both parties need to synced to collect the outputs of transactions from to the main blockchain. This required transaction id is immutable, that is where SegWit comes to the rescue.

SegWit, in theory, can double Bitcoin’s throughput to approximately six TPS. While it is very important for Bitcoin network improvement, but this theoretical doubling of transaction throughput still remains too low for mainstream use of Bitcoin as a payment system.

Block size

Another proposal to improve Bitcoin’s scalability on-chain is to increase the block size. The idea is superficially simple: increasing the block size from today’s 1 MB to, for example, 8 MB would increase transaction throughput eight-fold. Some of the altcoins, like Bitcoin Cash. The BCH blocks were initially 8MB, currently a BCH block is at 32MB. This is similar to the vertical scaling approach to add more transactions in one block. However, Increasing the block size means blockchain can be many times larger and that would require better computing capacity in order to process large-sized blocks. At the same time, this would decrease the security of the network to some extent due to the decrease of effective honest hash power. This may also lead to a scenario where a network is concentrated into a few rich hands and, thus, may ultimately compromise decentralization and security, the main tenets of the blockchain.

One is security concerns. It is a common belief that the network is more secure if more network nodes participate in transaction processing in the blockchain. With the wider distribution of altcoin chains, fewer nodes will operate on any given blockchain. This may make the blockchain less secure, since a smaller altcoin network may be more vulnerable to network attacks. Let us say, we have about 10,000 nodes on the larger network, it will require at least 5,001 nodes (or called 51%) to be compromised to launch an attack on the network. If we slice 10,000 nodes into 50 smaller chains, each chain comprises 200 nodes, and it only requires 101 nodes to take down any smaller chain, which is what we call a 1% attack problem. Another issue is cross-chain integration. Although there are some solutions for handling cross-blockchain integration, the overall complexity of integrating smaller chains and altcoins will increase drastically.

Segwit2x was a proposed compromise to the block size debate back in 2017. It suggested that Segwit will be activated as a first step, and after that, the block size will be increased to 2mb. This proposal was not accepted by the majority of the Bitcoin network.

Off-chain solutions

Similar to the rationales for an on-chain solution, the Bitcoin community is also actively looking for off-chain solutions, sometimes called layer 2 solutions. In off-chain scaling, the solution is to build extra layers on top of the Bitcoin blockchain and to do process all kinds of transactions with two participants. These transactions could then be batched and sent as one transaction on the blockchain. One of these off-chain solutions is called the Lighting network.

Lighting network

In Jan 2016, a white paper- The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments was submitted by Joseph Poon and Thaddeus Dryja. Here the contours of the Lightning Network were described.

Lightning is a decentralized network using smart contract functionality in the blockchain to enable instant payments across a network of participants.

The Lightning Network is a “Layer 2” payment solution that scales blockchains and enables trustless instant payments by keeping most transactions off-chain.  It builds a network of so-called payment channels, in which two parties commit a transaction and pay each other only. The process is instant, and the transaction does not need to be validated, relayed, and stored by every node of the Bitcoin network, but only between two participants.  

By moving payments off-chain, the cost of maintaining channels is reduced over the volume of payments in that channel, enabling micropayments and small-value transactions for which the on-chain transaction fees would otherwise be too expensive to justify. Furthermore, the Lightning Network scales the off-chain transaction throughput with modern data processing and latency limits – payments can process very fast.

Let’s take a look at how the Lightning Network works.

Initially, Alice holds the A1 commitment transaction, and Bob holds the B1 commitment transaction.

The revocation key for A1, K A1, is owned only by Alice;

The revocation key for B1, K B1, is owned only by Bob.

Suppose Alice and Bob, each owns 10 BTC in their account. Alice wants to send 2 BTC to Bob.

Alice and Bob both deposit equal amounts of money, in our case, 10 BTC and each put a lock on it.  This action of depositing equal amounts of money in a common box is recorded on the Blockchain in the form of a ‘payment channel’ and thereafter a payment channel is open between those two people.

Alice creates a new Bob’s transaction, B2, which allocates 8BTC to Alice and 12 BTC to Bob.

Alice signs B2 and sends to Bob.

Bob receives B2, signs it, and keeps it.

Bob creates a new Alice’s transaction, A2, which allocates 8 BTC to Alice and 12 BTC to Bob.

Bob signs A2 and sends to Alice.

Alice receives A2, signs it, and keeps it.

Alice provides K A1, invalidating A1, she can then delete A1.

Bob provides K B1, invalidating B1; he can then delete B1.

To sum it up, the payment channel is creating a combination of money pooling together for both parties and then transferring the promise of ownership of the pooled-in money in the agreed-upon manner.

When either of Alice or Bob wants to close the channel, they can. Closing a channel would simply mean both sides take their own money back. This opening of the box happens on the Blockchain and the who owns how much from the box is recorded forever.

Lighting network use Hash Time-Locked Contracts (HTLCs) is a class of payments that use hashlocks and timelocks to require that the receiver of a payment either acknowledges receiving the payment prior to a deadline by generating cryptographic proof of payment or forfeit the ability to claim the payment, returning it to the payer.

It allows transactions to be sent between parties who do not have a direct channel by routing it through multiple hops, so anyone connected to the Lightning Network is part of a single, interconnected global financial system.

Let’s take a look at an example:

Alice wants to send payment to Tim, but she doesn’t have a payment channel with Tim.  Alice has a payment channel with Bob, who has a payment channel with Tim, how can Alice pay Tim?

In order to do so, Tim must create a cryptographic secret string (Key), then hashes it using a hash function such as SHA-256 and then send to Alice.  Tim also shares that Hash with everyone: Bob. To simplify this written illustration, we’ll represent value as V.

HTLC

This Hash V is the lock, the Key is the code to unlock the HTLC’s.

Alice creates a Hash Time-Locked Contract (HTLC) with Bob and tells Bob that I will pay you if you can produce the preimage of V within 3 days. Alice signs a transaction with a lock time of 3 days after it is broadcast. Bob can redeem it with knowledge of V, and afterwards it is redeemable only by Alice. HTLC allows Alice to make a conditional promise to Bob while ensuring that her funds will not be accidentally burned if Bob never knows what V is.

Bob does the same, making an HTLC that will pay Tim if Tim can produce V within 2 days. However, Tim does, in fact, know V. Because Tim is able to pull the desired amount from Bob by using his key, Tim can consider the payment from Alice completed. Now, he has no problem telling V to Bob so that they are able to collect their funds as well.

Tim discloses Key to Bob, within 2 days, and Tim gets paid by Bob.

Bob discloses Key to Alice, within 3 day, and Bob gets paid by Alice.

After everyone cooperates, all of these transactions occur inside of lighting network. Everyone gets paid in a mechanical manner. The Lightning Network is almost atomic in nature and bidirectional, meaning that either everyone gets paid, or nobody gets paid.

In the lighting network, when the payment transaction is broadcasted, all the individual transactions will be verified first, and they must to match with the transaction history to avoid broadcasting fake or incorrect transactions. There is also a penalty imposed on fraudulent transactions where if the lighting network detects a bad actor in the system, they are immediately charged with a penalty. This way, the entire network ensures credibility and consistency while discouraging bad behavior.

There are several benefits to using the Lightning Network compared to on-chain transactions:

Quick and instant transactions: Settlement time for lightning network transactions is under a minute and can occur in milliseconds.

Micro-payments: It allows large amount micro-transactions.

Transaction Throughput: There are no fundamental limits to the number of payments per second that can occur under the protocol. The number of transactions are only limited by the capacity and speed of each node.

Privacy: No blockchain records. The details of individual lightning network payment transactions are not publicly recorded on the blockchain directly. Payments may be routed through many sequential channels where each node operator will be able to see payments across their channels, but they will not be able to see the source nor destination of those funds if they are non-adjacent.

Less on-chain network congestion:

Extremely low transaction fees: Transaction fees in lighting network paid to intermediary nodes are frequently very small amounts, typically in millisatoshis.

Limitations

The Lightning Network is made up of bidirectional payment channels between two nodes which combined create smart contracts. If at any time either party drops the channel, the channel will close and be settled on the blockchain.

Due to the nature of the Lightning Network’s dispute mechanism, which requires all participants to needs to always monitor their channel and track the state of offline ledger being broadcasted to the network. The concept of a “watchtower” has been developed to solve this problem.