Bitcoin developers currently have a significant challenge ahead of them, perhaps the biggest one they faced so far: improving the Core’s privacy and efficiency.
Most of their efforts seem to be focused on the Schnorr signatures technology, a key piece of code which further unlocks improvements like Taproot and the topic of today’s article, Graftroot. Before we dive into explaining what Graftroot is and how it benefits the Bitcoin network, lets revise other technological features that will serve as the base upon which Graftroot will be implemented.
From Schnorr to Taproot
Schnorr signatures actually predate Bitcoin’s current signature algorithm called Elliptic Curve Digital Signature Algorithm (ECDSA). Even though superior in most senses to ECDSA, Schnorr technology was under patent until February of 2008 so it wasn’t an option for Bitcoin developers.
Bitcoin’s technology is meant to be free and globally accessible, and having to pay for a patent doesn’t fit that bill. In fact, DSA was invented just because Schnorr signatures weren’t available for widespread use.
Schnorr signatures are equivalent to ECDSA in terms of security, having the same fundamental logarithm problem solving assumptions.
However, Schnorr comes with some interesting features, most important one being signature aggregation. What this basically means is that if you have a series of transactions, and you have a series of public keys that can be used to sign those transactions, instead of signing each transactions with each public key and having a series of signatures you can add all the public keys and all the transactions together, then sign the sum of transactions with the sum of keys in a single signature.
The other feature that Schnorr offers is aggregating signatures across signers. This is useful when we have a multi-sig transaction, where for example we have a condition that 5 out of 7 people need to sign off on said transaction for it to go through.
Schnorr signatures allow us to mask these multisig transactions and make them seem like normal, single signature transactions on the blockchain.
Naturally, the existence of conditions implies that some form of smart contract which enforces this condition exists; Schnorr also represents an important step towards building this smart contract layer on top of Bitcoin’s blockchain.
Having these conditions and smart contracts with Bitcoin is important to prevent potential problems and fight against adverse scenarios, as well as enable creation of complicated transactions that can be accessed and spent by multiple parties.
One recent example that comes to mind is the Quadriga exchange fiasco, where the owner died and took access to the exchange’s private keys to the grave with him. If these funds were protected with a timelock/multi-sig conditions, the funds would have been available and the exchange could have carried on operating.
Timelocks, multi-sig, Lightning network, confidential transactions, are all possible conditions that can come with one Bitcoin transaction; it’s important to create a way of introducing these conditions to the blockchain without suffering in terms of privacy and efficiency.
Schnorr is mentioned in the same breath as MAST, or so-called Merkelized Abstract Syntax Trees. This technology was proposed in 2016 and its main purpose is to obfuscate the conditions of one transaction.
If we have an advanced transaction, one that contains various possible conditions of which at least one needs to be met for the transaction to go through, MAST will hash each of these conditions into a Merkle Tree. You can then “pay to the root of the Merkle tree” and execute one of its branches (containing one of the conditions) without revealing the contents of other branches (other conditions that could have been used to verify the transaction but weren’t).
What we have in place today is different from what MAST offers. In multi-conditioned transactions, once the transaction is signed, every other condition that could have spent it is revealed.
For example in multisig transactions, once one key signs the transaction, all of the keys that could have spent it but didn’t are revealed. With Lightning Network payments, once you close a payment channel, the entire structure of the script is shown. This not only violates privacy, but also causes significant data bloat.
With Merkelized Abstract Syntax Trees we can represent one script with thousands of conditions as a tree with a couple of branches; this is both more data efficient and more private.
Taproot is a piece of technology created by Greg Maxwell, Pieter Wuille, Andrew Poelstra, and a few other Bitcoin developers. Taproot is a privacy enhancement that allows us to have a number of complex scripts appear as a single, normal transaction.
Taproot basically encompasses both Schnorr and MAST technologies and enables users to hide numerous scripting conditions within a single transaction without revealing the other scripting conditions when a specific one is met to spend the corresponding Bitcoins.
It does so by utilizing what are called “threshold public keys” and “threshold signatures”, where participants of a Bitcoin smart contract combine their keys and signatures into unique threshold ones. All of this improves the privacy of users that want to make advanced, smart contract-powered Bitcoin transactions.
Taproot, for all its good features, comes with one significant issue: a smart contract makes the transactions much more data-heavy than usual and Taproot doesn’t fix that. Greg Maxwell explains this best:
“Taproot suffers from a limitation that it only natively provides for one alternative. Trees or cascades of taproots can be done, but they have less privacy and efficiency than just a single level. E.g. a tree commitment has overhead that grows with the log of the number of alternatives.”
Graftroot is a way to achieve MAST with an even better average efficiency, which doesn’t really add capabilities, just makes them more efficient to use and allows the capabilities to be added retroactively to a transaction.
Graftroot allows us to add more ways (scripts containing spending conditions) to spend your coins at any time without communicating this to the blockchain. Only when spending, the chosen script is revealed and verified on the blockchain with the signature. We’ll turn to Maxwell for the explanation once again:
“With graftroot, the participants establish a threshold key, optionally with a taproot alternative, just as they do with taproot. At any time, they can delegate their ability to sign to a surrogate script by signing that script (and just the script) with their taproot key, and sharing that delegation with whomever they choose. Later, when it comes time to spend the coin, if the signers aren’t available and the script must be used, the redeeming party does whatever is required to satisfy the script (e.g. provides their own signature and a timelock, or whatnot) and presents that information along with the signer’s signature of the script.”
Reddit user RubenSomsen explained this to everyone like they were five:
- “Alice and Bob have money on the Graftroot Bank, which they can spend with their signature
- This particular bank also enables them to sign a document that allows someone to spend money on their behalf
- Alice and Bob worry that in the event of their death, their daughter Carol is left with nothing
- They decide to give Carol a signed document that states that she can spend the money if their bank account remains unused for a year
- It is private and convenient for Alice and Bob, since they don’t have to inform the bank whenever they sign a document like this
- The bank likes it too, because it requires no extra work unless one of these documents is actually used”
He also offered a more mature explanation later on:
“Schnorr enables multisig compressed into a single pubkey. With graftroot, the multisig participants can together sign the scripts they might like to use in their stead, which essentially creates a more space-efficient MAST (no tree needed, so blockchain usage does not grow with the number of scripts).”
In the example above, each participant signs alternative scripts and stores the threshold signature for each condition. The threshold signatures of the alternative conditions can be used later to prove that the scripts were agreed upon by the parties.
To not go into the technical details of the matter, Graftroot is an amalgamation of its Schnorr/Taproot/MAST roots which allows us to spend Bitcoin with the help of smart contracts with only a single current transaction’s worth of data (as opposed to two or perhaps even more that the currently existing system would require). Maxwell offers an explanation for this as well:
“The result is that instead of allowing only one alternative an unlimited number of alternatives can be provided. All are executed with equal efficiency to a single alternative, and the number of them is hidden without overhead. Alternatives can be provided for existing coins too, without requiring they get moved — movement is only required to destroy the ability to use alternatives by changing keys.”
Graftroot transaction’s main downside is the fact that it requires interaction between its participants; participants need to communicate about signing the alternative scripts before even spending the Bitcoins in the manner they arranged.
Additionally, all the scripts and threshold keys need to be stored somewhere which requires more complicated wallets that have these features enabled. Overall, it will likely make the already complicated process of making Bitcoin transactions even more complicated for the end user.
What Does The Future Hold?
The combination of Schnorr signatures, Taproot, Graftroot, and signature aggregation with multi-sig, will be implemented as a package of upgrades. Core developers are hoping to introduce these updates at the same time and Pieter Wuille explained the logic behind wanting to do so.
If implemented at the same time, network users will get maximum privacy benefits as these technologies complement eachother. If some features are left for a later time, an outside observer could differentiate addresses that use the new features and those that don’t; this somewhat defeats the purpose of wanting privacy as people will be able to tell you are after it, potentially putting a target on your Bitcoins.
Therefore, the goal is to implement all the features at once, to make sure that Schnorr/Taproot/Graftroot transactions are indistinguishable from the regular ones. It is expected that these features will be implemented via a soft fork, one that most likely won’t be voted on by miners but will instead be introduced as an opt-in change. Experts predict that this will go similarly to how SegWit was introduced: nodes will update to the latest Core version which contains these updates and turn the features on if they so desire.
The technology itself is almost ready to go, with BIP’s already written, specifications finalized and the first prototypes created and tested by Wuille and other developers.
As a matter of fact, Blockstream already released MuSig, which is their proposed test code for upgrading Bitcoin to Schnorr signatures. Most predictions see these features being rolled out sometime in the first six months of 2019. It seems likely that we’ll see Schnorr, MAST, and Taproot introduced initially, along with some other minor tweaks that will make future protocol upgrades easier.
Ultimately, there’s plenty of positive buzz surrounding the introduction of these features as they represent a significant step towards making Bitcoin ready for global distribution and commercial application.