7

The Bitcoin Network and Payments

In this chapter, we'll present the Bitcoin network, relevant network protocols, and wallets. We will explore different types of wallets that are available for Bitcoin. Moreover, we will examine how the Bitcoin protocol works, as well as the types of messages that are exchanged between nodes during various node and network operations. Also, we will explore some advanced and modern Bitcoin protocols that have been developed to address limitations in the original Bitcoin. Finally, we'll give you an introduction to Bitcoin trading and investment.

We will start with a detailed introduction to the Bitcoin network.

The Bitcoin network

The Bitcoin network is a peer-to-peer (P2P) network where nodes perform transactions. They verify and propagate transactions and blocks. Nodes called miners also produce blocks. There are different types of nodes on the network. The two main types of nodes are full nodes and simple payment verification (SPV) nodes. Full nodes, as the name implies, are implementations of Bitcoin Core clients performing the wallet, miner, full blockchain storage, and network routing functions. However, it is not necessary for all nodes in a Bitcoin network to perform all these functions. SPV nodes or lightweight clients perform only wallet and network routing functionality.

Some nodes are full blockchain nodes with a complete blockchain as they are more secure and play a vital role in block propagation, while some nodes perform network routing functions only but do not perform mining or store private keys (the wallet function). Another type of node is solo miner nodes, which can perform mining, store full blockchains, and act as Bitcoin network routing nodes.

There are a few nonstandard but heavily used nodes. These are called pool protocol servers. These nodes make use of alternative protocols, such as the stratum protocol. These nodes are used in mining pools. Nodes that only compute hashes use the stratum protocol to submit their solutions to the mining pool. Some nodes perform only mining functions and are called mining nodes. It is possible to run SPV software that runs a wallet and network routing function without a blockchain. SPV clients only download the headers of the blocks while syncing with the network. When required, they can request transactions from full nodes. Verifying transactions is possible by using a Merkle root in the block header with a Merkle branch to prove that the transaction is present in a block in the blockchain.

There are also different protocols that have been developed to facilitate communication between Bitcoin nodes. One such protocol is called Stratum. It is a line-based protocol that makes use of plain TCP sockets and human-readable JSON-RPC to operate and communicate between nodes. Stratum is commonly used to connect to mining pools.

A Bitcoin network is identified by its magic value. Magic values are used to indicate the message's origin network.

A list of these values is shown in the following table:

Network	Magic value (in hex)
main	0xD9B4BEF9
testnet	0xDAB5BFFA
testnet3	0x0709110B

A full Bitcoin node performs four functions. These are wallet, miner, blockchain, and network routing. We discussed mining and blockchains in the previous chapter, Chapter 6, Introducing Bitcoin. We will focus on the Bitcoin network protocol and wallets in this chapter.

Before we examine how the Bitcoin discovery protocol and block synchronization work, we need to understand the different types of messages that the Bitcoin protocol uses. Also, note that the latest version of the Bitcoin protocol is 70015, which was introduced with Bitcoin Core client 0.19.0.1.

There are 27 types of protocol messages in total, but they're likely to increase over time as the protocol grows. The most commonly used protocol messages and an explanation of them are listed as follows:

• Version: This is the first message that a node sends out to the network, advertising its version and block count. The remote node then replies with the same information and the connection is then established.
• Verack: This is the response of the version message accepting the connection request.
• Inv: This is used by nodes to advertise their knowledge of blocks and transactions.
• Getdata: This is a response to inv, requesting a single block or transaction identified by its hash.
• Getblocks: This returns an inv packet containing the list of all blocks starting after the last known hash or 500 blocks.
• Getheaders: This is used to request block headers in a specified range.
• Tx: This is used to send a transaction as a response to the getdata protocol message.
• Block: This sends a block in response to the getdata protocol message.
• Headers: This packet returns up to 2,000 block headers as a reply to the getheaders request.
• Getaddr: This is sent as a request to get information about known peers.
• Addr: This provides information about nodes on the network. It contains the number of addresses and address list in the form of an IP address and port number.
• Ping: This message is used to confirm if the TCP/IP network connection is active.
• Pong: This message is the response to a ping message confirming that the network connection is live.

When a Bitcoin Core node starts up, first, it initiates the discovery of all peers. This is achieved by querying DNS seeds that are hardcoded into the Bitcoin Core client and are maintained by Bitcoin community members. This lookup returns a number of DNS A records. The Bitcoin protocol works on TCP port 8333 by default for the main network and TCP 18333 for testnet.

First, the client sends a protocol message, version, which contains various fields, such as version, services, timestamp, network address, nonce, and some other fields. The remote node responds with its own version message, followed by a verack message exchange between both nodes, indicating that the connection has been established.

After this, getaddr and addr messages are exchanged to find the peers that the client does not know. Meanwhile, either of the nodes can send a ping message to see whether the connection is still active. getaddr and addr are message types defined in the Bitcoin protocol.

This process is shown in the following diagram of the protocol:

Figure 7.1: Visualization of node discovery protocol

This network protocol sequence diagram shows communication between two Bitcoin nodes during initial connectivity. Node A is shown on the left-hand side and Node B on the right. First, Node A starts the connection by sending a version message that contains the version number and current time to the remote peer, Node B. Node B then responds with its own version message containing the version number and current time. Node A and Node B then exchange a verack message, indicating that the connection has been successfully established. After this connection is successful, the peers can exchange getaddr and addr messages to discover other peers on the network.

Now, the block download can begin. If the node already has all the blocks fully synchronized, then it listens for new blocks using the inv protocol message; otherwise, it first checks whether it has a response to inv messages and has inventories already. If it does, then it requests the blocks using the getdata protocol message; if not, then it requests inventories using the getblocks message. This method was used until version 0.9.3. This was a slower process known as the blocks-first approach and was replaced with the headers-first approach in 0.10.0.

The initial block download can use the blocks-first or headers-first method to synchronize blocks, depending on the version of the Bitcoin Core client. The blocks-first method is very slow and was discontinued on 16th February 2015 with the release of version 0.10.0.

Since version 0.10.0, the initial block download method named headers-first was introduced. This resulted in major performance improvement, and blockchain synchronization that used to take days to complete started taking only a few hours. The core idea is that the new node first asks peers for block headers and then validates them. Once this is completed, blocks are requested in parallel from all available peers. This happens because the blueprint of the complete chain is already downloaded in the form of the block header chain.

In this method, when the client starts up, it checks whether the blockchain is fully synchronized if the header chain is already synchronized; if not, which is the case the first time the client starts up, it requests headers from other peers using the getheaders message. If the blockchain is fully synchronized, it listens for new blocks via inv messages, and if it already has a fully synchronized header chain, then it requests blocks using getdata protocol messages. The node also checks whether the header chain has more headers than blocks, and then it requests blocks by issuing the getdata protocol message:

Figure 7.2: Bitcoin Core client >= 0.10.0 header and block synchronization

The preceding diagram shows the Bitcoin block synchronization process between two nodes on the Bitcoin network. Node A, shown on the left-hand side, is called an Initial Block Download (IBD) node, and Node B, shown on the right, is called a sync node.

IBD node means that this is the node that is requesting the blocks, while sync node means the node where the blocks are being requested from. The process starts by Node A first sending the getheaders message, which is met with a getheaders message response from the sync node. The payload of the getheaders message is one or more header hashes. If it's a new node, then there is only the first genesis block's header hash. Sync Node B replies by sending up to 2,000 block headers to IBD Node A. After this, the IBD node, Node A, starts to download more headers from Node B and blocks from multiple nodes in parallel; that is, it acts as the IBD and receives multiple blocks from multiple nodes, including Node B. If the sync node does not have more headers than 2,000 when the IBD node makes a getheaders request, the IBD node sends a getheaders message to other nodes. This process continues in parallel until the blockchain synchronization is complete.

The Getblockchaininfo and getpeerinfo Remote Procedure Calls (RPCs) were updated with a new functionality to cater for this change. An RPC known as getchaintips is used to list all known branches of the blockchain. This also includes headers-only blocks. Getblockchaininfo is used to provide information about the current state of the blockchain. getpeerinfo is used to list both the number of blocks and the headers that are common between peers.

Wireshark can also be used to visualize message exchange between peers and can serve as an invaluable tool to learn about the Bitcoin protocol. A sample of this is shown here. This is a basic example showing the version, verack, getaddr, ping, addr, and inv messages.

In the details, valuable information such as the packet type, command name, and results of the protocol messages can be seen:

Figure 7.3: A sample block message in Wireshark

A protocol graph showing the flow of data between the two peers can be seen in the preceding screenshot. This can help you understand when a node starts up and what type of messages are used.

In the following example, the Bitcoin dissector is used to analyze the traffic and identify the Bitcoin protocol commands.

The exchange of messages such as version, getaddr, and getdata can be seen in the following example, along with the appropriate comment describing the message name.

This exercise can be very useful in order to learn about the Bitcoin protocol and it is recommended that the experiments be carried out on the Bitcoin testnet (https://en.bitcoin.it/wiki/Testnet), where various messages and transactions can be sent over the network and then be analyzed by Wireshark.

The analysis being performed here by Wireshark shows messages being exchanged between two nodes. If you look closely, you'll notice that the top three messages show the node discovery protocol that we introduced earlier:

Figure 7.4: Bitcoin node discovery protocol in Wireshark

Nodes run different Bitcoin client software. The most common are full and SPV clients. We introduced these briefly at the start of this chapter, but we'll have a deeper look at these clients and related concepts, such as bloom filters, in the next sections.

Full client and SPV client

Bitcoin network nodes can fundamentally operate in two modes: full client or lightweight SPV client. Full clients are thick clients or full nodes that download the entire blockchain; this is the most secure method of validating the blockchain as a client. SPV clients are used to verify payments without requiring the download of a full blockchain. SPV nodes only keep a copy of block headers of the current longest valid blockchain. Verification is performed by looking at the Merkle branch, which links the transactions to the original block the transaction was accepted in. This is not very practical and requires a more pragmatic approach, which was implemented with BIP37 (you can see this at https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki), where bloom filters were used to filter for relevant transactions only.

Bloom filters

A bloom filter is a data structure (a bit vector with indexes) that is used to test the membership of an element in a probabilistic manner. It provides probabilistic lookup with false positives but no false negatives. This means that this filter can produce an output where an element that is not a member of the set being tested is wrongly considered to be in the set. Still, it can never produce an output where an element does exist in the set, but it asserts that it does not. In other words, false positives are possible, but false negatives are not.

Elements are added to the bloom filter after hashing them several times and then setting the corresponding bits in the bit vector to 1 via the corresponding index. To check the presence of an element in the bloom filter, the same hash functions are applied and then compared with the bits in the bit vector to see whether the same bits are set to 1.

Note that not every hash function (such as SHA1) is suitable for bloom filters as they need to be fast, independent, and uniformly distributed. The most commonly used hash functions for bloom filters are fnv, murmur, and Jenkins.

These filters are mainly used by simple payment verification SPV clients to request transactions and the Merkle blocks that they are interested in. A Merkle block is a lightweight version of the block, which includes a block header, some hashes, a list of 1-bit flags, and a transaction count. This information can then be used to build a Merkle tree. This is achieved by creating a filter that matches only those transactions and blocks that have been requested by the SPV client. Once version messages have been exchanged and the connection is established between the peers, the nodes can set filters according to their requirements.

These probabilistic filters offer a varying degree of privacy or precision, depending on how accurately or loosely they have been set. A strict bloom filter will only filter transactions that have been requested by the node, but at the expense of the possibility of revealing the user addresses to adversaries who can correlate transactions with their IP addresses, thus compromising privacy.

On the other hand, a loosely set filter can result in retrieving more unrelated transactions but will offer more privacy. Also, for SPV clients, bloom filters allow them to use low bandwidth as opposed to downloading all transactions for verification.

BIP37 proposed the Bitcoin implementation of bloom filters and introduced three new messages to the Bitcoin protocol:

• filterload: This is used to set the bloom filter on the connection.
• filteradd: This adds a new data element to the current filter.
• filterclear: This deletes the currently loaded filter.

Now, we'll move to a different but relevant topic. So far, we've discussed that, on a Bitcoin network, there are full clients (nodes), which perform the function of storing a complete blockchain. If you cannot run a full node, then SPV clients can be used to verify that particular transactions are present in a block by only downloading the block headers instead of the entire blockchain. At times, even running an SPV node is not feasible (especially on low-resource devices such as mobile phones) and the requirement is only to be able to send and receive Bitcoin somehow. For this purpose, wallets (wallet software) are used that do not require downloading even the block headers. We'll introduce wallets and some different types next.

Wallets

The wallet software is used to generate and store cryptographic keys. It performs various useful functions, such as receiving and sending Bitcoin, backing up keys, and keeping track of the balance available. Bitcoin client software usually offers both functionalities: Bitcoin client and wallet. On disk, the Bitcoin Core client wallets are stored as a Berkeley DB file:

$ file wallet.dat
     wallet.dat: Berkeley DB (Btree, version 9, native byte-order)

Private keys are generated by randomly choosing a 256-bit number provided by the wallet software. The rules of generation are predefined and were discussed in Chapter 4, Public Key Cryptography. Private keys are used by wallets to sign the outgoing transactions. Wallets do not store any coins, and there is no concept of wallets storing balance or coins for a user. In fact, in the Bitcoin network, coins do not exist; instead, only transaction information is stored on the blockchain (more precisely, UTXO, unspent outputs), which are then used to calculate the number of bitcoins.

In Bitcoin, there are different types of wallets that can be used to store private keys. As software, they also provide some functions to the users to manage and carry out transactions on the Bitcoin network. Let's take a look at the common types of wallets.

Non-deterministic wallets

These wallets contain randomly generated private keys and are also called Just a Bunch of Key wallets. The Bitcoin Core client generates some keys when first started and also generates keys as and when required. Managing a large number of keys is very difficult and an error-prone process that can lead to the theft and loss of coins. Moreover, there is a need to create regular backups of the keys and protect them appropriately, for example, by encrypting them in order to prevent theft or loss.

Deterministic wallets

In this type of wallet, keys are derived from a seed value via hash functions. This seed number is generated randomly and is commonly represented by human-readable mnemonic code words. Mnemonic code words are defined in BIP39, a Bitcoin improvement proposal for Mnemonic code for generating deterministic keys. This BIP is available at https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki. These phrases can be used to recover all keys and make private key management comparatively easier.

Hierarchical deterministic wallets

Defined in BIP32 and BIP44, HD wallets store keys in a tree structure derived from a seed. The seed generates the parent key (master key), which is used to generate child keys and, subsequently, grandchild keys. Key generation in HD wallets does not generate keys directly; instead, it produces some information (private key generation information) that can be used to generate a sequence of private keys. The complete hierarchy of private keys in an HD wallet is easily recoverable if the master private key is known. It is because of this property that HD wallets are very easy to maintain and are highly portable. There are many free and commercially available HD wallets available, for example, Trezor (https://trezor.io), Jaxx (https://jaxx.io/), and Electrum (https://electrum.org/).

Brain wallets

The master private key can also be derived from the hashes of passwords that are memorized. The key idea is that this passphrase is used to derive the private key and if used in HD wallets, this can result in a full HD wallet that is derived from a single memorized password. This is known as a brain wallet. This method is prone to password guessing and brute-force attacks, but techniques such as key stretching can be used to slow down the progress made by the attacker.

Paper wallets

As the name implies, this is a paper-based wallet with the required key material printed on it. It requires physical security to be stored.

Hardware wallets

Another method is to use a tamper-resistant device to store keys. This tamper-resistant device can be custom-built. With the advent of NFC-enabled phones, this can also be a secure element (SE) in NFC phones. Trezor and Ledger wallets (various types) are the most commonly used Bitcoin hardware wallets:

Figure 7.5: A Trezor wallet

Online wallets

Online wallets, as the name implies, are stored entirely online and are provided as a service usually via the cloud. They provide a web interface to the users to manage their wallets and perform various functions, such as making and receiving payments. They are easy to use but imply that the user trusts the online wallet service provider. An example of an online wallet is GreenAddress, which is available at https://greenaddress.it/en/.

Mobile wallets

Mobile wallets, as the name suggests, are installed on mobile devices. They can provide us with various methods to make payments, most notably the ability to use smartphone cameras to scan QR codes quickly and make payments.

Mobile wallets are available for Android and iOS and include Blockchain Wallet, Breadwallet, Copay, and Jaxx:

Figure 7.6: Jaxx mobile wallet

The choice of Bitcoin wallet depends on several factors such as security, ease of use, and available features. Out of all these attributes, security, of course, comes first, and when deciding about which wallet to use, security should be of paramount importance. Hardware wallets tend to be more secure compared to web wallets because of their tamper-resistant design. Web wallets, by their very nature, are hosted on websites, which may not be as secure as a tamper-resistant hardware device.

Generally, mobile wallets for smart phone devices are quite popular due to a balanced combination of features and security. There are many companies offering these wallets on the iOS App Store and Google Play. It is, however, quite difficult to suggest which type of wallet should be used as it also depends on personal preferences and the features available in the wallet. Security should be kept in mind while making a decision on which wallet to choose.

Now that we've discussed the topic of Bitcoin wallets, let's see how Bitcoin payments can be adopted for business.

Bitcoin payments

Bitcoin can be accepted as payment using various techniques. Bitcoin is not recognized as a legal currency in many jurisdictions, but it is increasingly being accepted as a payment method by many online merchants and e-commerce websites. There are a number of ways in which buyers can pay a business that accepts Bitcoin. For example, on an online shop, Bitcoin merchant solutions can be used, whereas in traditional, physical shops, Point of Sale (POS) terminals and other specialized hardware can be used. Customers can simply scan the QR barcode with the seller's payment URI in it and pay using their mobile devices. Bitcoin URIs allow users to make payments by simply clicking on links or scanning QR codes. A Uniform Resource Identifier (URI) is basically a string that represents the transaction information. It is defined in BIP21. The QR code can be displayed near the point of the sale terminal. Nearly all Bitcoin wallets support this feature.

Businesses can use the following image to advertise that they can accept Bitcoin as payment from customers:

Figure 7.7: "Bitcoin accepted here" logo

Various payment solutions, such as XBT terminal and the 34 Bytes Bitcoin POS terminal, are available commercially.

Generally, these solutions work by following these steps:

1. The salesperson enters the amount of money to be charged in fiat currency; for example, US dollars.
2. Once the value is entered in the system, the terminal prints a receipt with a QR code on it and other relevant information, such as the amount to be paid.
3. The customer can then scan this QR code using their mobile Bitcoin wallet to send the payment to the Bitcoin address of the seller embedded within the QR code.
4. Once the payment is received at the designated Bitcoin address, a receipt is printed out as physical evidence of the sale.

A Bitcoin POS device from 34 Bytes is shown in the following image:

Figure 7.8: 34 Bytes POS solution

Bitcoin payment processors are offered by many online service providers. It allows integration with e-commerce websites to facilitate Bitcoin payments. These payment processors can be used to accept Bitcoin as payment. Some service providers also allow secure storage of Bitcoin, for example, BitPay (https://bitpay.com). Another example is the Bitcoin merchant solutions available at https://www.bitcoin.com/merchant-solutions.

Various BIPs have been proposed and finalized in order to introduce and standardize Bitcoin payments. Most notably, BIP70 (secure payment protocol) describes the protocol for secure communication between a merchant and customers. This protocol uses X.509 certificates for authentication and runs over HTTP and HTTPS. There are three messages in this protocol: PaymentRequest, Payment, and PaymentACK. The key features of this proposal are defense against man-in-the-middle attacks and secure proof of payment. Man-in-the-middle attacks can result in a scenario where the attacker is sitting between the merchant and the buyer, and it would seem to the buyer that they are talking to the merchant, but in fact, the man in the middle is interacting with the buyer instead of the merchant. This can result in manipulation of the merchant's Bitcoin address to defraud the buyer.

Several other BIPs, such as BIP71 (Payment Protocol MIME types) and BIP72 (URI extensions for Payment Protocol), have also been implemented to standardize payment scheme to support BIP70 (Payment Protocol).

Another innovative development is the Lightning Network. It is a solution for scalable off-chain instant payments. It was introduced in early 2016 and allows off-blockchain payments. This network makes use of payments channels that run off the blockchain, which allows greater speed and scalability of Bitcoin.

So far, we've covered a lot of concepts related to Bitcoin payments and pertinent concepts and techniques. We have completed our discussion regarding Bitcoin payments here and will now move on to the different but important topic of innovation. Bitcoin, and blockchain technology in general, are under continuous evolution, and we'll discuss some of the most relevant ideas next.

Innovation in Bitcoin

Bitcoin has undergone many changes and is still evolving into a more and more robust and better system by addressing various weaknesses in the system. Performance has been a topic of hot debate among Bitcoin experts and enthusiasts for many years. As such, various proposals have been made in the last few years to improve Bitcoin performance, resulting in greater transaction speed, increased security, payment standardization, and overall performance improvement at the protocol level.

These improvement proposals are usually made in the form of Bitcoin Improvement Proposals (BIPs) or fundamentally new versions of Bitcoin protocols, resulting in new networks altogether. Some of the changes proposed can be implemented via a soft fork, but a few need a hard fork and, as a result, give birth to a new currency.

In the following sections, we will look at the various BIPs that can be proposed for improvement in Bitcoin. Then, we will discuss some advanced protocols that have been proposed and implemented to address various weaknesses in Bitcoin.

Bitcoin Improvement Proposals

These documents, also referred to as BIPs, are used to propose improvements or inform the Bitcoin community about the improvements suggested, the design issues, or some aspects of the Bitcoin ecosystem. There are three types of BIPs:

• Standard BIP: Used to describe the major changes that have a major impact on the Bitcoin system; for example, block size changes, network protocol changes, or transaction verification changes.
• Process BIP: A major difference between standard and process BIPs is that standard BIPs cover protocol changes, whereas process BIPs usually deal with proposing a change in a process that is outside the core Bitcoin protocol. These are implemented only after a consensus among Bitcoin users.
• Informational BIP: These are usually used to just advise or record some information about the Bitcoin ecosystem, such as design issues.

Now that we've provided this brief discussion on Bitcoin improvement and evolution, let's look at some of the excellent ideas that have emerged from research and innovation efforts related to Bitcoin.

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:

1. 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>
   

2. 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.
3. 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>
   

4. 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.

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.

Bitcoin investment and buying and selling Bitcoin

There are many online exchanges where users can buy and sell Bitcoin. This is a big business on the internet now and it offers Bitcoin trading, CFDs, spread betting, margin trading, and various other choices. Traders can buy Bitcoin or trade by opening long or short positions to make a profit when the price of Bitcoin goes up or down. Several other features, such as exchanging Bitcoin for other virtual currencies, are also possible, and many online Bitcoin exchanges provide this function. Advanced market data, trading strategies, charts, and relevant data to support traders is also available. An example is shown from CEX (https://cex.io) here. Other exchanges offer similar types of services:

Figure 7.10: Example of the Bitcoin exchange on cex.io

The following screenshot shows the order book at the exchange, where all buy and sell orders are listed:

Figure 7.11: Example of a Bitcoin order book at the exchange of cex.io

The order book shown here displays sell and buy orders. Sell orders are also called ask orders, while buy orders are also called bid orders. This means that the ask price is what the seller is willing to sell the bitcoin at, whereas the bid price is what the buyer is willing to pay. If the bid and ask prices match, then a trade can occur. The most common order types are market orders and limit orders. Market orders mean that as soon as the prices match, the order will be fulfilled immediately. Limit orders allow for buying and selling a set number of bitcoins at a specified price or better. Also, a period of time can be set, during which the order can be left open. If it's not executed, then it will be canceled. We will introduce trading concepts in more detail in Chapter 18, Tokenization.

Summary

We started this chapter with an introduction to the Bitcoin network, followed by a discussion on Bitcoin node discovery and block synchronization protocols. Moreover, we presented different types of network messages. Then, we examined different types of Bitcoin wallets and discussed the various attributes and features of each type. Following this, we looked at Bitcoin payments and payment processors. In the last section, we discussed Bitcoin innovations, which included topics such as BIPs and advanced Bitcoin protocols. Finally, we presented a basic introduction to Bitcoin buying and selling.

In the next chapter, we will discuss Bitcoin clients, such as the Bitcoin Core client, which can be used to interact with the Bitcoin blockchain and also acts as a wallet. In addition, we will explore some of the APIs that are available for programming Bitcoin applications.