About Bitcoin Taproot Softfork
Taproot is a softfork to the Bitcoin network that will improve the scripting capabilities and privacy. It enables something called MAST, which can help make smart contracts more efficient and private by only revealing the relevant parts of the contract when spending. It can also improve privacy of the Lightning Network by making channels look like regular bitcoin transactions, if the Lightning implementations choose to adopt Taproot.
MAST (Merkelized Abstract Syntax Tree) is a proposed solution that uses Merkle trees (a decades-old, compact data structure invented by cryptographer Ralph Merkle) to work around these two downsides. In short, all the different conditions under which the funds can be spent are individually hashed (as opposed to combined into a single hash) and included in a Merkle tree, which ultimately produces a single hash: the Merkle root. This Merkle root “locks up” the coins.
The unique benefit is that if any of the data in the Merkle tree is revealed, the Merkle root and some additional data (called the Merkle path) can be used to verify that that specific data was included in the Merkle tree. The rest of the Merkle tree remains hashed and hidden.
With MAST, this means that only the condition that is met needs to be revealed. If, in the initial example above, Alice alone spends the funds after a week, she just reveals that condition (and the Merkle path). No one learns that the money could have also been spent by Alice and Bob together, or by Bob alone if he’d added a secret number. This makes MAST more data efficient than complex P2SH smart contracts and adds privacy to boot.
Yet with Schnorr, Taproot can do even better: a transaction can hide that a MAST-structure existed at all.
The Schnorr signature scheme has long been on the wishlist of many Bitcoin developers and is currently in development to be deployed as a soft fork protocol upgrade. Many cryptographers consider the Schnorr signature scheme to be the best in the field, as its mathematical properties offer a strong level of correctness, it doesn’t suffer from malleability and is relatively fast to verify.
As its best-known benefit in the context of Bitcoin, Schnorr’s “linear math” allows for signature aggregation: several signatures in the same transaction can be combined into one. A similar trick could be applied to multisig transactions. Combining both public keys and signatures into “threshold public keys” and “threshold signatures,” a multisig transaction can be made indistinguishable from any regular transaction.
And the signature scheme can be used in even more interesting ways. For example, it’s possible to use data to “tweak” both a private key and a public key. As a simplified example, a private key and its corresponding public key could be tweaked by multiplying both by two. The “private key x 2” and the “public key x 2” would still correspond, and the “private key x 2” could still sign messages that could be verified with the “public key x 2.” Anyone unaware that the original key pair was tweaked wouldn’t even see any difference; the tweaked keys look like any other key pair.
This is what enables Taproot.
Taproot is based on an interesting realization: no matter how complex, almost any MAST-construction could (or should) include a condition that allows all participants to agree on the outcome and simply sign off on a settlement transaction together. In the earlier example, if Bob knows Alice can, by herself, claim all the funds next week, he might as well cooperate with her now to sign off together. (In many typical smart contract setups he would even be penalized if he doesn’t. The complexity really just serves to keep everyone honest.)
Taproot resembles MAST and always includes a condition where all participants can cooperate to spend the funds: the “cooperative close.”
By utilizing Schnorr signatures, this is where it gets interesting.
First off, the cooperative close would utilize Schnorr’s threshold trick to make it look like a regular transaction, from one person to another. So, the public keys of all participants are added together, resulting in the “threshold public key.” Corresponding with this threshold public key, the combination of all participants’ signatures — their “threshold signature” — allows them to spend the funds.
So far so good, but spending the funds as if it were a normal transaction is the only thing they can do — no MAST-like structures yet. That’s where the other Schnorr trick comes in.
All the alternative ways in which the funds can be spent — the non-cooperative outcomes — are this time combined into a different script. This script, then, is hashed and used to tweak the threshold public key. Rather than “public key x 2,” as used in the example earlier, this results in a “threshold public key x script.” (We’re still simplifying.) This “threshold public key x script” corresponds, of course, to a “threshold signature x script.”
Now, if the money is spent cooperatively, all participants combine their signatures into the “threshold signature” and tweak it with the script. The resulting “threshold signature x script” allows them to spend the funds. Yet, and importantly, to the outside world, all this would still just look like a regular public key and a regular signature — a regular transaction.
Only if a cooperative close proves impossible, the threshold public key can be shown for what it really is: tweaked.
In this case, both the original threshold public key and the script are revealed. This proves that the “threshold public key x script” was tweaked with this specific script. So, like the hash in P2SH, the tweak proves to the world that the funds should be spendable if the alternative conditions, as specified in this script, are met. (And, like with P2SH, these conditions are of course immediately met to spend the funds.)
Alternatively, instead of tweaking the threshold public key with script, the threshold public key can be tweaked with a Merkle root of a Merkle tree that includes all the different conditions under which the funds can be spent: a MAST structure. To spend the funds, then, only the spending condition that’s been met needs to be revealed.
As such, Taproot offers all the benefits of MAST, while under normal circumstances no one will ever know that a regular transaction was hiding such a complex smart contract as a fallback.
BitHash exchange BitcoinCore node has been upgraded to version 22.0, supporting the softfork:
BitHash Cryptocurrency Exchange was established in 2016 in Singapore with more than 100 pairs available for trading cryptocurrency — Bitcoin (BTC), Ethereum (ETH), Litecoin (LTC), Bitcoin Cash (BCH), Ethereum Classic (ETC), Dash (DASH), EOS (EOS), Monero (XMR), Ripple (XRP), Zcash (ZEC).
BitHash Exchange is operated by PHOENIX TRADING SOLUTIONS LTD, a company incorporated under the International Business Companies Act of 2016 of the Republic of Seychelles with company number 214028.
Global Gateway 8, Rue de la Perle, Providence, Mahé, Seychelles
PHOENIX TRADING SOLUTIONS LTD
IBC NO 214028