Advanced protocols
In this section, we'll introduce various advanced protocols that have been suggested or implemented for improving the Bitcoin protocol.
For example, transaction throughput is one of the critical issues that need a solution. The Bitcoin network can only process approximately three to seven transactions per second, which is a tiny number compared to other financial networks. For example, the Visa network can process approximately, on average, 24,000 transactions per second. PayPal can process approximately 200 transactions per second, whereas Ethereum can process up to, on average, 20. As the Bitcoin network has grown exponentially over the last few years, these issues have started to grow even further. The difference in processing speed is also shown in the following graph, which shows the scale of difference between Bitcoin and other networks' transaction speeds. The graph uses a logarithmic scale, which demonstrates the vast difference between the networks' transaction speeds:
Figure 7.9: Bitcoin transaction speed compared to other networks (on a logarithmic scale)
Also, security issues such as transaction malleability are of real concern and can result in denial of service. Various proposals have been made to improve the Bitcoin proposal to address various weaknesses. A selection of these proposals will be presented here.
Segregated Witness
The SegWit or Segregated Witness is a soft fork-based upgrade of the Bitcoin protocol that addresses weaknesses such as throughput and security in the Bitcoin protocol. SegWit offers a number of improvements, as listed here:
- Fix for transaction malleability due to the separation of signature data from transactional data. In this case, it is no longer possible to modify the transaction ID because it is no longer calculated based on the signature data present within the transaction.
- By segregating the signature data and transaction data, lightweight clients do not need to download the transactions with all signatures unnecessarily. The transactions can be verified without the useless signatures, which allows for increased bandwidth efficiency.
- Reduction in transaction signing and verification times, which results in faster transactions. A new transaction hashing algorithm for signature verification has been introduced and is detailed in BIP0143 (https://en.bitcoin.it/wiki/BIP_0143). Due to this change, the verification time grows linearly with the number of inputs instead of in a quadratic manner, resulting in quicker verification time.
- Script versioning capability, which allows for easier script language upgrades. The version number is prefixed to the locking scripts to depict the version. This change allows upgrades and improvements to be made to the scripting language, without requiring a hard fork, by just increasing the version number of the script.
- Increased block size by introducing a weight limit instead of a size limit on the block and the removal of signature data. This concept will be explained in more detail shortly.
- An improved address format, also called a "bc1 address," which is encoded using the Bech32 mechanism instead of base58. This improvement allows for better error detection and correction. Also, all characters are lowercase, which helps with readability. Moreover, this helps with distinguishing between legacy transactions and SegWit transactions. More information is available at this link: https://en.bitcoin.it/wiki/Bech32.
SegWit was proposed in BIP 141, BIP 143, BIP 144, and BIP 145. It was activated on Bitcoin's main network on August 24, 2017 at block number 481824. The key idea behind SegWit is the separation of signature data from transaction data (that is, a transaction Merkle tree), which results in the size of the transaction being reduced. This change allows the block size to increase up to 4 MB in size. However, the practical limit is between 1.6 MB and 2 MB. Instead of a hard size limit of 1 MB blocks, SegWit introduced a new concept of a block weight limit.
Block weight is a new restriction mechanism where each transaction has a weight associated with it. This weight is calculated on a per-transaction basis. The formula used to calculate it is:
Weight = (Transaction size without witness data) X 3 + (Transaction size)
Blocks can have a maximum of four million weight units. As a comparison, a byte in a legacy 1 MB block is equivalent to 4 weight units, but a byte in a SegWit block weighs only 1 weight unit. This modification immediately results in increased block capacity.
To spend an unspent transaction output (UTXO) in Bitcoin, a valid signature needs to be provided. In the pre-SegWit scenario, this signature is provided within the locking script, whereas in SegWit this signature is not part of the transaction and is provided separately.
There are four types of transactions introduced by SegWit. These types are:
- Pay to Witness Public Key Hash (P2WPKH): This type of script is similar to the usual P2PKH, but the crucial difference is that the transaction signature used as a proof of ownership in ScriptSig is moved to a separate structure known as the "witness" of the input. The signature is the same as P2PKH but is no longer part of ScriptSig; it is simply empty. The PubKey is also moved to the witness field. This script is identified by a 20-byte hash. The ScriptPubKey is modified to a simpler format, as shown here:
- P2PKH ScriptPubKey:
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG- P2WPKH ScriptPubKey:
OP_0 <pubKeyHash> - Pay to Script Hash - Pay to Witness PubKey Hash (P2SH-P2WPKH): This is a mechanism introduced to make SegWit transactions backward-compatible. This is made possible by nesting the P2WPKH inside the usual P2SH.
- Pay to Witness Script Hash (P2WSH): This script is similar to legacy P2SH but the signature and redeem script are moved to the separate witness field. This means that ScriptSig is simply empty. This script is identified by a 32-byte SHA-256 hash. P2WSH is a simpler script compared to P2SH and has just two fields. The ScriptPubKey is modified as follows:
- P2SH ScriptPubKey:
OP_HASH160 <pubKeyHash> OP_EQUAL- P2WSH ScriptPubKey:
OP_0 <pubKeyHash> - Pay to Script Hash - Pay to Witness Script Hash (P2SH-P2WSH): Similar to P2SH-P2WPKH, this is a mechanism that allows backward-compatibility with legacy Bitcoin nodes.
SegWit adoption is still in progress as not all users of the network agree or have started to use SegWit.
Next, we'll introduce some other innovative ideas in the Bitcoin space. Not only has the original Bitcoin evolved quite significantly since its introduction, but there are also new blockchains that are either forks of Bitcoin or novel implementations of the Bitcoin protocol with advanced features.
Bitcoin Cash
Bitcoin Cash (BCH) increases the block limit to 8 MB. This change immediately increases the number of transactions that can be processed in one block to a much larger number compared to the 1 MB limit in the original Bitcoin protocol. It uses Proof of Work (PoW) as a consensus algorithm, and mining hardware is still ASIC-based. The block interval is changed from 10 minutes to 10 seconds and up to 2 hours. It also provides replay protection and wipe-out protection, which means that because BCH uses a different hashing algorithm, it prevents it being replayed on the Bitcoin blockchain. It also has a different type of signature compared to Bitcoin to differentiate between two blockchains.
The BCH wallet and relevant information is available on their website: https://www.bitcoincash.org.
Bitcoin Unlimited
Bitcoin Unlimited increases the size of the block without setting a hard limit. Instead, miners come to a consensus on the block size cap over a period of time. Other concepts such as extremely thin blocks and parallel validation have also been proposed in Bitcoin Unlimited.
Its client is available for download at https://www.bitcoinunlimited.info.
Extremely thin blocks allow for faster block propagation between Bitcoin nodes. In this scheme, the node requesting blocks sends a getdata request, along with a bloom filter, to another node. The purpose of this bloom filter is to filter out the transactions that already exist in the memory pool (mempool) of the requesting node. The node then sends back a thin block only containing the missing transactions. This fixes an inefficiency in Bitcoin whereby transactions are regularly received twice – once at the time of broadcast by the sender and then again when a mined block is broadcasted with the confirmed transaction.
Parallel validation allows nodes to validate more than one block, along with new incoming transactions, in parallel. This mechanism is in contrast to Bitcoin, where a node, during its validation period after receiving a new block, cannot relay new transactions or validate any blocks until it has accepted or rejected the block.
Bitcoin Gold
This proposal has been implemented as a hard fork since block 491407 of the original Bitcoin blockchain. Being a hard fork, it resulted in a new blockchain, named Bitcoin Gold. The core idea behind this concept is to address the issue of mining centralization, which has hurt the original Bitcoin idea of decentralized digital cash, whereby more hash power has resulted in a power shift toward miners with more hashing power. Bitcoin Gold uses the Equihash algorithm as its mining algorithm instead of PoW; hence, it is inherently ASIC resistant and uses GPUs for mining.
Bitcoin Gold and relevant information is available at https://bitcoingold.org.
There are other proposals like Bitcoin Next Generation, Solidus, Spectre, and Segwit2x, which will be discussed later in this book in Chapter 21, Scalability and Other Challenges, in the context of performance improvement in blockchain networks.
Now that we have covered some new blockchains and implementations of the Bitcoin protocol, let's introduce some basic concepts around Bitcoin investment and how to sell and buy Bitcoin.