Bitcoin smart contracts enable you to have complicated transactional conditions in it through its scripting language called Script. And in these conditions or scripts, actual bitcoins are locked which get unlocked after satisfying the relevant requirements.
For example, when you have 3 of 3 multisig, all 3 need to sign to unlock the coins. But what if one of the persons dies after a year?
For that, we have 2 of 3 multisig also, where only 2 of the 3 can sign and unlock the bitcoins.
We can also have 1 of 3 multisig, but we don’t want to reveal all the conditions while executing a transaction even when only one is being used.
For that, we use Merklized Abstract Syntax Trees (MAST) that help us execute the transaction by including only the script that is being used. Other scripts (or conditions) can remain hidden.
So far so good !!
But these multisig transactions enabled through MAST has a limitation that they look different than other normal transactions happening over the blockchain.
That’s where Bitcoin Taproot comes to the picture.
Bitcoin Taproot is a form of MAST used in a particular manner to hide that a particular transaction is a multisig transaction. This magic is done by Schnorr signature aggregation where threshold signatures and threshold public keys are generated.
Using Bitcoin Taproot then multisig transactions start looking like normal single party transactions.
So let’s assume we have 2 of 3 multisig which we will be able to execute when atleast 2 of the 3 agree. While in the base case all 3 could also agree.
Let’s call all 3 signing in as the base case and 2 of them signing as the alternative condition.
When all 3 are signing there is no problem but when one of the parties is not in consense that time the alternative 2 of 3 alternative conditions will come into play.
In execution of such alternative conditions, we don’t want to reveal that participants involved are not in consensus and thus are executing the alternative way.
This is what Taproot enables by making the execution of the base case as well as the alternative condition indistinguishable from the normal single party transaction.
But Gregory Maxwell says:
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.
Which means Taproot natively supports only one alternative condition to be executed with privacy.
Taproot works well when you have the sort of base case in multisig for example even in 2-of-3 multisig if all 3 signs, the bitcoins will be released. (base case)
Similarly, when 2-of-3 signs the bitcoins will be released, and the transaction can be made indistinguishable from the normal ones. (alternative case)
But what if 2-of-3 are not agreeing and you have other alternative scenarios coming into play !!
- Can we ensure privacy and indistinguishability in such case with Taproot?
Well, we can, but it will become data-heavy as well as complicated thus capping its ability of inclusion for more complicated conditions where alternatives other than the base case are likely to come into play.
This becomes data heavy because then you need to have a cascading tree of Taproot with various conditions. This way you will have a decreasing number of public keys/private keys that will sign the transaction, but under that also you need to specify relevant alternative conditions such as disaster preventing conditions atleast.
For example, let say you have a 6 of 7 multisig.
The base case being the 7 of 7 signing and another alternative (6 of 7). Both these you can execute privately as well as efficiently with Taproot.
But if you need to be prepared for a case when less than 6 parties are willing to come to a consensus and in that case, you can use a cascading Taproot like:
- Under 6 of 7 alternative, if 6 of 7 agreement is not happening, the alternative is 5 of 7 with one more ‘X’- disaster prevention condition.
- If 5 of 7 is also not happening, then you have 4 of 7 with ‘Y’ as one more condition and so no…
This will make the Taproot cascade very long, complex, and inefficient.
For such scenarios, Gregory Maxwell has come up with another technique which will provide the ability to have an arbitrary number of alternative conditions without being data-heavy and it is called Bitcoin Graftroot.
What Is Bitcoin Graftroot?
Just like Taproot, Graftroot also uses signature aggregation as described by the Schnorr signatures trick, but the signatures are used to sign individual scripts (or conditions) instead of the whole set of conditions.
Well consider this example:
Alice, Bob, and Harry form a 3 of 3 multisig for locking some bitcoins that can be unlocked when all three of them agree. This is a sort of base case.
But in case the base case doesn’t work out due to some or the other reason, such as non-cooperation of one person or due to the death of one person. For that you have these alternative conditions:
- Coins can be spent when 2 of the 3 signs
- Bob can spend coins after a year has passed with his signature.
- Alice can spend coins after 6 months if she signs and produces a password.
So these are the three alternative conditions or scripts that can be signed by each of these 3 participants using their threshold signature.
And when the times come to spend, either the coins will be spent by the base case where all three agree or by one of these scripts produced by one of the participants.
The produced alternative script will be executed successfully because the participants have already agreed and signed off their ability to sign the scripts.
This way the participants can agree to any outsized number of conditions and keep the agreement on those by using their signing ability.
You don’t have to define all these possible conditions ahead of time, and this is the beauty of Graftroot.
Another thing nice thing that Garftroot enables is the delegating of keys to a script.
For example in a case of 7-of-7, one participant can say that I am responsible for my key only for a year and hence I am delegating my keys or signing ability to another script which this other person can unlock after a year.
The delegation of signatures in case of 7 of 7 is an interesting one because all 7 participants can delegate their keys to some group or other people.
Another cool thing is that the number of such delegated scripts (or conditions) can be as many as the participants want that too without any overhead or privacy loophole.
With Graftroot, in our previous example of Alice, Bob, Harry. Alice can say that instead of my signature you can use this particular script where I have delegated my keys for signing.
This delegation can exist even after Alice is not around and the new scripts are available for fallback in case Alice is not around or not able to corporate. This is also known as Surrogate script.
This way each holder of the key can create their own conditions for what allows it to get signed.
Another classic example of Graftroot could be in a Will.
Where the person who has formed the will can delegate his keys to three of his sons upon his death certificate is produced over the blockchain.
In this case, also the funds will be released when all the three sons are cooperating.
Gregory Maxwell, the initiator of Taproot concept, presented the idea of Graftroot after a month of unveiling Taproot in February 2018.
Graftroot could have helped in the case of QuadrigaCX where the exchange has lost $21 million in crypto due to the sudden death of its CEO. The exchange claims that because of the CEO’s death they are unable to recover the funds from the cold storage and in this case alternative conditions such as CSV time locks or delegation of keys must have prevented this.
So that’s how powerful Graftroot and Taproot are !!
But these two pieces of technologies are not going live anytime soon because they are dependent upon Schnorr signatures which is a major Bitcoin upgrade since Segwit.
It is also believed that Schnorr signatures, MAST, & Taproot will all go live together in one package because it makes sense in doing so, followed by Graftroot.
Lastly, I am very excited about developments happening over Bitcoin because these changes open up a whole new range of possibilities for Bitcoin users.
Hope you liked this article? If you did, do share this with your friends and family who wish to know about Bitcoin Taproot & Graftroot !!
Further Suggested Readings…