Bitcoin is both a currency and a technology. On the currency side, Bitcoin has been engineered so that transactions, once validated, are immutable and live forever on the blockchain. But that doesn’t mean that the technology is static. Bitcoin’s protocol has been steadily improved year after year, thanks to a vibrant developer ecosystem.

Bitcoin’s decentralized nature creates a unique challenge to the process of improving the underlying technology powering the protocol. To avoid anarchy, Bitcoin’s core developers have adopted a specific process for code revisions. Because there’s no central authority to say which updates should and shouldn’t be completed, changes depend on proposals gaining support from the developer community. Once proposals have been implemented into code, nodes on the network have to accept the new changes by upgrading their client software.

Investors should be aware of significant update proposals because a major change to Bitcoin could potentially impact the price of BTC. Contentious proposals could even lead to hard forks, causing the smaller group to split off and form a new version of the blockchain (as the SegWit2 proposal inspired the creation of Bitcoin Cash).

Bitcoin Improvement Proposals

Bitcoin improvements are typically submitted to the GitHub repository in the form of Bitcoin Improvement Proposals (BIPs). A BIP is a design document that presents an idea for a new Bitcoin feature or a revision of an existing feature. Only significant changes are given their own BIP. The document’s author will typically poll the Bitcoin community to confirm if there’s a good chance of acceptance before submitting the BIP for the official approval process.

If the community is largely supportive, the BIP author will then submit the document to the Bitcoin development mailing list for review. BIPs pass through several stages:

• Draft — the BIP has been submitted
• Proposed — the BIP has a working implementation and the author has a clear plan to take it live
• Final / Active — the BIP proposal is ready to go live or has been applied
• Rejected / Withdrawn — the BIP has been rejected by the development community or the author has withdrawn it from consideration
• Replaced / Obsolete — a new version of the feature proposed by the BIP has replaced it

Here’s are the up-and-coming BIPs that could have significant effects on Bitcoin users and investors in 2019. We’ll dive into the details of each of these below.

Standardizing multisig transactions: Partially Signed Bitcoin Transactions (PSBTs)

Let’s say that you and two partners are running an investment fund, where your funds are denominated in Bitcoin. You want to make sure that at least two of you need to agree in order to make any investment and draw on your capital. Thanks to multisignature addresses, you can guarantee this through cryptography. On Bitcoin, you can create a 2-of-3 multisignature address to hold your funds, where you need the private keys of two partners to authorize any transaction.

The current problem with multisignature transactions is that there isn’t a standard format for them in Bitcoin. For example, if you and your partners are using different Bitcoin wallets, those wallets might not support each other’s signature formats, which would prevent the transaction.

Andrew Chow’s proposal for partially signed Bitcoin transactions (PSBTs) could resolve this problem. The proposal creates a transaction format that would standardize partially signed transactions across different wallet clients. This standard transaction format is like a piece of a jigsaw puzzle. To create a multisignature transaction, you need different pieces from each participant — only now, with PSBTs, the pieces of the puzzle actually fit together. The new format would also allow groups to conduct transactions even if not all the users have access to the complete UXTO (unspent transaction output) record.

Efficient, private transactions: Schnorr signatures

Schnorr signatures are a way to consolidate private key, public key, and transaction signature(s) into a single hash. This increases the efficiency and privacy of transactions, especially for multisig transactions (since it’s no longer apparent whether there are multiple signers on the transaction).

Currently, Bitcoin uses ECDSA signatures, which are between 71 to 75 bytes. Schnorr signatures are 64 bytes, which is already an improvement. But that’s only the tip of the iceberg. Most Bitcoin transactions are actually comprised of several smaller inputs, following Bitcoin’s Unspent Transaction Output (UTXO) model. Currently, each input needs its own signature, and all the signatures need to be included in a transaction — which takes up space, and leads to higher transaction fees.

Schnorr signatures will allow one combined signature to represent all the signatures required by the transaction, which leads to an estimated 17% gain in block capacity and faster validation for transactions. These gains also apply to multisignature transactions, where multiple signatures are currently required to access a transaction input.

Pieter Wuille’s proposal to add Schnorr signatures to Bitcoin would include all of the above advantages and also incorporate two secondary advantages:

1. a fixed, 64-byte signature-encoding format
2. the potential for batch verification, thanks to the standardized nature of the proposed signature format

Greater anonymity: Dandelion

Privacy was one of Satoshi Nakamoto’s stated goals in creating Bitcoin, but the currency is pseudonymous rather than anonymous. What this means is that you can think of your wallet address as a kind of pseudonym: Anyone on the network can see all transactions associated with your address, so, if they can associate your real-world identity to your address, your privacy is eliminated.

There are a number of ways that this kind of real-world identification is possible today. Currently on the Bitcoin network, when a transaction is sent to a node, it is then broadcast to other nodes on the network. That makes it possible to do network analysis and trace the transaction back to the originating node. From there, it’s relatively simple to trace the transaction back to the IP address that it came from, effectively identifying users.

The Dandelion project hopes to solve this and make Bitcoin more private. Instead of broadcasting a transaction to the rest of the network from the original node, Dandelion begins with an “anonymity phase.” In this phase, the transaction hops to a random peer, which transmits it to another random peer, which continues until the “spreading” or “fluff” phase. Each time the transaction hops from one node to another, there’s a 90% chance that the transaction stays anonymous and hops to another single node and a 10% chance that the transaction enters the “spreading” phase where it is broadcast to nodes on the network.

Dandelion uses probability to randomize the path a transaction takes before being broadcast to the rest of the network, which gives the network a much higher degree of privacy by making it impossible to trace a transaction back to the originating node.

Brad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, and Pramod Viswanath jointly submitted the Dandelion proposal and have built a prototype version on a small version of the Bitcoin network for testing. Thus far, the team reports that it has found no software conflicts.

Greater scalability: Merkelized Abstract Syntax Tree (MAST)

Blockchains use hashing algorithms to encode and verify transactions, generating a new hash each time a coin is moved from one place to another. Every new hash includes a code that points back to the previous hash, which means that information from a series of hashes can be stored in one single hash, greatly reducing the amount of processing time and power needed to handle a series of transactions. This method of chaining together hashes is known as a Merkle tree.

The Merkelized Abstract Syntax Tree (MAST) takes Merkle trees a step further by combining them with abstract syntax trees, a way of describing code by splitting it into individual components and mapping it to its dependencies. Combined with Merkle trees, these individual components can be used to verify that the individual components belong to the complete set. On Bitcoin, MAST will help reduce the size of transaction data by removing the need to include unused parts of a script on the Bitcoin blockchain, and allowing for more complex uses of Bitcoin’s scripting language that are currently limited by space constraints.

Bitcoin’s blockchain size has doubled over the past two years, from roughly 100 GB to 200 GB, making it harder and more difficult for people to run a full node. MAST would help slow down the rate at which the blockchain grows.

Bitcoin developers have proposed two different approaches to adding MAST to the cryptocurrency. Johnson Lau’s proposal, BIP 114, proposes activating MAST by using script versioning from BIP 141. Mark Friedenbach, Kalle Alm, and BtcDrak’s proposals, BIP 116 and 117, would incorporate MAST without script versioning — requiring fewer consensus changes — potentially making it simpler to implement.

Sidechain implementation: Hashed time-locked contracts

2018 saw significant progress in Layer-2 developments such as sidechains, a mechanism for shifting tokens from one blockchain to a different, secondary blockchain and back again. Sidechain nodes are designed to do most of the actual transaction processing, thereby taking much of the load off the primary Bitcoin nodes. The theory is that this will facilitate scalability by makes a much larger number of transactions possible without impinging on the primary blockchain. The Lightning Network is the best-known of the Layer-2 programs, but it’s not the only one in development.

Hashed time-locked contracts (HTLCs) are a way of creating conditional payments in Bitcoin that make sidechain transactions more feasible. They’re a core component of the Lightning Network.

Using a Layer-2 solution like Lightning, Alice may have an open payment channel with Bob, and Bob might have an open payment channel with Charlie. A HTLC basically allows Alice to send money to Charlie through Bob, without having to trust Bob or Charlie.

Here’s an example of how a HTLC would work in a payment channel system:

1. Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
2. Alice wants to buy something from Charlie for 1000 satoshis.
3. Charlie generates a random number and generates its SHA256 hash. Charlie gives that 
hash to Alice.4. Alice uses her payment channel to Bob to pay him 1,000 satoshis, but 
she adds the hash Charlie gave her to the payment along with an extra condition: in order
for Bob to claim the payment, he has to provide the data that was used to produce that 
hash.
5. Bob uses his payment channel to Charlie to pay Charlie 1,000 satoshis, and Bob adds 
a copy of the same condition that Alice put on the payment she gave Bob.
6. Charlie has the original data that was used to produce the hash (called a pre-image), 
so Charlie can use it to finalize his payment and fully receive the payment from Bob. By 
doing so, Charlie necessarily makes the pre-image available to Bob.
7. Bob uses the pre-image to finalize his payment from Alice. Source: Bitcoin Wikipedia

Sean Bowe and Daira Hopwood’s proposal for hashed time-locked contracts includes a script that makes it possible for either party in a transaction to recover funds if the other party does not cooperate. It sets a time limit on transactions: If the buyer doesn’t spend the funds by the time this limit expires, the seller can recover the coins.

Reliably Upgrading a Decentralized Network

The various improvement proposals we’ve discussed are in various stages of development, and it will be exciting to see which ones are adopted over the next year. While the BIPs themselves propose incremental improvements rather than radical change, proposed upgrades promise to make Bitcoin more efficient and private, while making the protocol more compatible with Layer-2 solutions such as Lightning.