Bitcoin’s struggles with privacy and efficiency have been described numerous times in the past, but we’ll do it once again before moving onto the topic of today’s article. The language Bitcoin was originally scripted in allowed its developers to define the terms of spending transaction outputs.
These terms needed to be defined in such a way that transactions remain private, as well as low enough on data requirements to not tax Bitcoin nodes’ space and computational capabilities too much. However, writing in the required privacy features would definitely introduce these inefficiencies for the Bitcoin blockchain.
The burdening effects that introducing something more complicated like smart contracts onto the chain would have been a topic of discussion for quite some time now.
Namely, the amount of code that would need to be added to a block with each transaction would grow significantly. This would slow down the network, as more data would end up being processed with each new transaction. Additionally, more data requires more storage space, which would cause the blockchain to become even more bloated.
This would hamper full blockchain nodes that are tasked with validating the network transactions, as they would need stronger processors and much more storage data to handle the already significant demands of the Bitcoin blockchain.
Therefore staying space efficient and anonymous is important for Bitcoin developers. Solutions that would enable this have been suggested and even entered development in the past, with such technologies as CoinJoin or Dandelion++ being mentioned the most. One new idea has been making the rounds among developers and cryptographers, and its name is Taproot.
Requirements For Introducing Taproot
The solution was originally introduced by Greg Maxwell, Bitcoin Core developer and cryptographer, who wanted to create something that would preserve on-chain anonymity sets for fixed party smart contracts (by making them look like ordinary payments).
What this means is that Taproot basically expands the smart contract capabilities of the Bitcoin network (while preserving privacy) by making all the on-chain transactions (both simple and more advanced ones) look the same to an outside observer.
The solution depends on three pieces of technology that are currently implemented or are being implemented in Bitcoin: P2SH, MAST and SCHNOOR. Let’s quickly take a look at what each of these is.
P2SH or “pay to script hash” is an underlying piece of technology that currently takes part in “powering” the transactions on the network. Introduced with BIP 16, P2SH locks your Bitcoins behind a script which requires specific conditions to be met before the Bitcoins are made available.
Earn passive income with Quadency trading bot. Connect Binance account and use Quadency bot for 6 months completely free. Hurry up, this deal is not around for long!
With standard transactions this means that a private key will be used to verify that the coins can be spent. With advanced transactions, this can mean that more private keys will need to be presented before the script releases the Bitcoins. The conditions don’t have to be just the private keys; alternatively a password, time lock or some other unique requirement (or more of them at the same time) can be used.
P2SH script (containing the release conditions) is stored as a hash on the blockchain. To spend Bitcoins sent via P2SH, the recipient must provide a script matching the script hash and data which makes the script evaluate to true. Once the coins are spent, these conditions are revealed to the network.
The issue is that when the conditions are revealed, all of them are revealed; if you set up a multi-sig protection condition and also had the password one in your P2SH, both are revealed after the coins are spent. This represents a problem as outside observers can deduce what kind of wallet the Bitcoin was sent from/validated by.
Some wallets don’t offer advanced features like time locks or multi-sig, which narrows down the pool of wallets to guess from. Additionally with more conditions comes more code, and we already explained why this is bad for the network.
MAST or Merkelized Abstract Syntax Trees was proposed in early 2016 by Johnson Lau and is a piece of technology which reduces the size of data necessary for writing a Bitcoin script.
This reduces demand on block space and improves privacy, as you only reveal a small part of the smart contract to the public blockchain, so it’s more difficult to analyze. Thanks to MAST, those complicated redemption conditions we mentioned above suddenly become a viable option for the Bitcoin blockchain.
MAST obscures the script conditions of a transaction and only reveals the first condition that was met — the one which was responsible for the spending of the coins.
It does so by hashing each individual condition through implementation of the Merkle Tree technology. If, for example, P2SH contained a time lock and a multi-sig requirement and the transaction was signed with the latter, then no one will know that the former was even a part of the initial script.
The final piece of the puzzle is the Schnorr technology. Schnorr is an upgrade from the current Bitcoin signature scheme, allowing for a single transaction to encrypt multiple keys in one (basically incorporating several transactions into a single one).
Schnorr technology has been in development for years and is expected to be the next major addition to the Bitcoin code base. With Schnorr, the network is expected to see significant improvements in transaction data sizes and become much more scalable than before.
Signature aggregation, the main feature of this technology, can be applied to multi-sig transactions; public keys and signatures can be combined into “threshold” keys and signatures, making a single multi-sig transaction blend in with the unconditional ones. The scheme is linear in nature, which means that you can take multiple signatures by different keys on the same message, add them together, and create a valid signature for the sum of those keys.
Additionally, it allows for “tweaking” of public and private keys, which can also help make multi-sig transactions appear normal. Schnoorr signatures scheme was always superior to what Bitcoin had in place but it was patented until 2008, which prevented Bitcoin developers from implementing it on a major scale.
All of this potentially opens the door for the implementation of Taproot. It is a concept similar to MAST; MAST scripts always require that a condition is inserted in a hash which allows the participants to agree to sign off on a transaction together.
If two members of a multi-sig transaction know that the funds will become available to one of them in a couple of weeks, they can agree to sign off on the transaction immediately. This feature is always included in Taproot and is called the cooperative close, improving the security and honesty of Bitcoin smart contracts.
Introducing Schnorr into the equation allows us to have elements of privacy in the mix. Schnorr lets users create threshold public keys and threshold signatures; if a matching threshold signature is provided to a certain threshold public key, the funds are released to be spent. Schnorr also allows us to combine the non-cooperative outcomes into a script which can be used to tweak the threshold public key and create a unique hash.
This script is the used to tweak the threshold signature; the threshold signature+script hash will ultimately allow individuals involved to spend the Bitcoin. As long as all participants agree on the “cooperative close” of a contract, the combination of Schnorr and MAST offers both data efficiency and privacy.
Bitcoin Core developer Anthony Towns proposed in July 2018 to introduce ‘generalized taproot,’ which would reduce the amount of data required for the initial Taproot proposal. Complex Taproot contracts would still be data-heavy and a solution named “Graftroot” was engineered to fix this problem.
Graftroot would allow the smart contracts to be as complex as their creators want them to be, potentially including hundreds of scripts and conditions. Towns does note that “there’s no great urgency for generalized taproot”, which means that the Core will initially implement the Schnorr/Taproot/MAST and then look to introduce Graftroot later. This article explains the feature in much better detail.
The timeline to introduce these features remains unclear, but the community feels that we might see some movement on that field in 2019. In essence, Taproot and the corresponding technologies allow for complicated transactions to appear indistinguishable from the simple ones in the public eye.
Complex smart contracts that protect and condition the spending of Bitcoin can be hidden away thanks to Taproot’s MAST, P2SH and Schnorr-like features. This represents a significant win for the privacy of Bitcoin users and is something that many Core supporters are looking forward to seeing implemented.
Pieter Wuille, Bitcoin Core developer and Blockstream co-founder, spoke recently about the upcoming Taproot and Schnorr improvements, explaining how these improvements might benefit the Bitcoin network. Check his presentation out if you are interested in learning more about the technological minutia of these upcoming features.
CaptainAltcoin's writers and guest post authors may or may not have a vested interest in any of the mentioned projects and businesses. None of the content on CaptainAltcoin is investment advice nor is it a replacement for advice from a certified financial planner. The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of CaptainAltcoin.com