Press "Enter" to skip to content

How is the Current Bitcoin Protocol Different from the Original White Paper

The current Bitcoin protocol has varied from its structure in the original white paper. How exactly has Bitcoin evolved over the years? Here’s a deep dive.

Bitcoin, apart from being a currency, is a network subject to protocols. These protocols ensure an optimal functioning of the Bitcoin network – right from security, mining, transactions to its layout and structure. Over the past decade, these protocols have undergone major transitions to adapt to the rapid expanse of the Bitcoin consumer base and to offer a friendly and feasible cryptocurrency network. It is because of these exhaustive changes that even after a decade of its release, Bitcoin is still the leader in the crypto space. But if Bitcoin is decentralized technology, who has the authority to make these protocol changes? And if Bitcoin protocols have undergone changes, then how is the current network different from Satoshi’s model as described in the original white paper? Let’s find out the answers to these imperative questions. 

The Original Bitcoin White Paper

The era of cryptocurrencies started the day Satoshi Nakamoto, the pseudonymous person or persons who developed Bitcoin, released Bitcoin’s white paper. You can find Satoshi Nakamoto’s original white paper here.

Since that day, the Bitcoin network has undergone significant changes. But since Bitcoin is a decentralized network, who governs these changes? And if there is a governing body then does it not make Bitcoin a centralized Network? The answers to these questions lie in the next segment of our discussion. 

Bitcoin Improvement Proposals

A Bitcoin Improvement Proposal or a BIP is a detailed outline that proposes any kind of change in the Bitcoin Core application. Any member who is a part of the Bitcoin network can propose a BIP. The provision of a BIP was first established via BIP 1, the first BIP which detailed how a BIP format should look like. Over the years 342 BIP’s have been proposed so far, out of which only some have been implemented. For a BIP to get successfully accepted in the Bitcoin network it must be approved by the selected group of editors and must have a 95% support from the last 2,016 miners. This points in the direction that the Bitcoin community as a unit selects or rejects a BIP. 

After a BIP has been accepted, the developers initiate a soft fork after which the network participants need to upgrade their versions to access the latest changes. A BIP is of 3 types, with each BIP focusing on a vivid segment of the Bitcoin network. A Standard track BIP is our concern right now.

A standard track BIP concerns on making changes to the network protocol, block, or transaction validation method. It also aims to affect the interoperability of the two versions of BIPs or Bitcoin. Therefore the protocol changes witnessed in Bitcoin are a result of all the accepted standard track BIP’s. Let us look at some major standard track BIP’s which have carved the present Bitcoin network.

Prominent Standard Track BIPs 

#BIP 68

Proposed by Mark Friedenbach in May, 2015 BIP 68 aimed at using the sequence numbers of transactions as a time keeping parameter. It was thought that the miners will mine transactions in a block by choosing transactions from the mempool, where the valid transactions wait to be confirmed by the miners, based on the highest sequence number of the transaction. The system was based on a hope that miners will honestly mine the transactions with higher sequence numbers and not the lowest numbers despite the latter being more profitable to mine. 

Friedenbach proposed that such a system based on honesty is vulnerable to greed and instead devised code to use the sequence number as a time keeping character. The new system also aims in assisting in the success of bi-directional payment channels within the Bitcoin network. 

BIP 68 was implemented using consensus soft work by the community. You can study BIP 68 here.

#BIP 91

Proposed by James Hilliard in may 2017, BIP 91 became a stepping stone in successful deployment of the controversial Segregated Witness (SegWit). Hilliard noted that SegWit along with tackling the scalability issue in the Bitcoin network, fixed transactions malleability and made scripting easy along with offering other benefits to Bitcoin. BIP 141 aimed at deploying SegWit in the Bitcoin network.

But with many of the SegWit related features already in the network, it would have taken a lot of time and hashpower to first successfully eliminate the initial desired features, and then again redeploy those features with additional SegWit features. This would also leave no time for the tests. BIP 91 on the other hand provided a way for a simple majority of miners to coordinate activation of the existing segwit deployment using less than 95% hashpower. 

The successful implementation of BIP 91 paved the way for easy implementation of BIP 141. You can read more about the proposed BIP here

#BIP 112

BIP 112 was proposed in october 2015 and described a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin scripting system. BIP 112 was built in combination with BIP 68 and focused on the Bitcoin scripts, a key element missed by BIP 68. 

Since BIP 68 did not provide any method to control scripts, using which transaction output could become spendable and subsequently defeat the very task for which BIP 68 was implemented. BIP 112 described a new system that would compare against the sequence number, as a time parameter proposed in BIP 68, and after verification from both the ends allow a transaction to be mined on the block. You can read more about the proposed BIP here

#BIP 141

Proposed in 2015 by the trio of Eric Lombrozo, Johnson Lau and Pieter Wuille, BIP 141 is till date the greatest BIP implemented of all time. The BIP introduced Segregated Witness, a soft fork that would bypass protocol restrictions like the block size limit and increase the transaction speed. The issue of limited block size of 1 mb and low rate of transaction had been harrowing upon the Bitcoin community which itself was divided to increase the block size or not. BIP 141 or SegWit offered a back-door solution by splitting the transaction data into 2 segments with unlocking signature getting appended as a separate structure at the end. This reduced the transaction size and made place for more transactions to get mined in a single block. 

BIP 141 also prevents unintentional bitcoin transaction malleability, since the transaction hash does not contain signature data anymore. SegWit implementation further makes way for the adoption of Lightning network. You can read more about BIP 141 here.

#BIP 148

Seen popularly as a user promoted BIP in the community, BIP 148 proposed mandatory activation of the SegWit deployment. It urged the miners to activate SegWit early or else the BIP 148 would cause mandatory activation of the existing Segwit deployment at that time. 

BIP 148 is mostly remembered as a catalyst in promoting the hard fork that witnessed creation of Bitcoin Cash

These were some salient protocol changes that have significantly transformed the Bitcoin network over the years. Changes like introduction of Segwit though have increased the block size, yet they have not altered with the notable features of Bitcoin. Furthermore, awaited BIP implementations of proposals like Lightning network too might look like a 360 degree change in the existing system. But these changes do not interfere with the very idea that led to creation of Bitcoin. A decentralized electronic payment system based on cryptographic proof instead of trust, as elucidated by Satoshi in his white paper, still remains the crux of the Bitcoin network.

Be First to Comment

Leave a Reply

Your email address will not be published.

Latest Posts
Send this to a friend