ReddCoin Core 4.22 Beta — What Is Taproot?

What is Taproot and how does it work?

P2SH

All RDD are essentially “locked up” in scripts: a couple lines of code embedded in a transaction included in the blockchain, that define how the coins can be spent in the next transaction. Spending conditions usually involve providing a signature to prove ownership of the coins. But other, well-known conditions for example include timelocks (coins can only be spent after a specific block height or date) or multisig (coins can only be spent if some number of private keys out of a set of private keys provide signatures).

Different conditions can be mixed and matched, to create complex types of smart contracts. An example of such a contract could be that coins can be spent if both Alice and Bob sign, or if Alice alone signs after a week has passed, or if Bob alone signs while also providing a secret number. Whichever of these three conditions is met first, is how the coins are spent.

Since 2012, scripts (the conditions) are often not publicly visible at first; only the new owner of the coins knows how they can be spent. This is done with a trick called P2SH (pay to script hash), where initially only a hash of the script is included in the blockchain. This seemingly randomly scrambled number holds the coins. When the owner spends the coins, he reveals the whole script as well as the “solution” to the script at the same time. Anyone can then use the initial hash to check that the supplied script was indeed the original script locking up the coins and can immediately conclude that the requirements of the script were met.

Still, when the coins are spent, it’s currently necessary to reveal all the possible conditions that could have been met — including the conditions that weren’t met. This has two main downsides. One, it’s data heavy, especially if there are many conditions. And two, it’s bad for privacy. Everyone learns all the different ways in which funds could have been spent, which can, for example, reveal what kind of wallet was used and perhaps even more.

MAST

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.

SCHNORR

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

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.

IMPROVING THE BITCOIN (AND REDDCOIN) TRANSACTION MODEL

The history of paying in bitcoin has changed a lot since the early days of the network. Overall, the UTXO model described above relies on scripts or contracts created using the Bitcoin Script “programming” language. This author has put “programming” in quotation marks because Bitcoin’s scripting language can more accurately be seen as a verification language than one that provides computation directives. In essence, Bitcoin scripting is a way to specify conditions for spending a UTXO.

There are three major constraints when considering Bitcoin Script and how its improvements are made: privacy, space efficiency, and computational efficiency — usually, improving one of these cascades into strengthening the other two. For instance, seeking to reveal less about a transaction and thereby improving privacy would entail submitting a smaller amount of data, reducing space needs for the transaction, and making it easier to be verified — it’s less computationally intensive.

We have been improving how ReddCoin transactions work by gradually introducing new script, or address, types. Ultimately, these changes have sought to enhance transactional privacy, make the transfer of funds more lightweight, and speed up the process of validating transactions. As a result, users have greater flexibility for creating scripts that increase the resilience of their savings, move funds around more efficiently and privately, and help unleash financial sovereignty. Albeit complicated for the end-user, technical tools have emerged to adopt these practices and abstract low-level technicalities, ensuring greater adoption of current best practices.

One clear example of this is multisignature addresses, which once had to be done manually with Bitcoin Script but can now be effortlessly created with a smartphone or a laptop.

Taproot, the latest upgrade to the Bitcoin protocol and arguably the most important one to date, is a natural evolution of the way Bitcoin transactions, and hence scripts, work. Enabled by Schnorr signatures, MAST and Tapscript, Taproot seeks to increase flexibility and privacy without compromising security.

WHAT TAPROOT COULD ULTIMATELY ENABLE FOR AVERAGE REDDCOIN USERS

By making transactions cheaper, more efficient, and more private, the adoption of Taproot will set the stage for extra functionality to land on the ReddCoin network. As nodes upgrade and people start using Taproot addresses primarily, it will become more difficult for blockchain observers to spot and discriminate between senders and receivers, UTXOs will be treated more equally, and the broader ReddCoin network will be a more robust settlement network that enables complex functionality to be built on top.

Layer 2 protocols and sidechains will be empowered to step up and leverage even more sophisticated smart contracts for coordinating funds on the base layer. The end-user might not construct these themselves, but they will benefit from more special offerings in the broader ReddCoin ecosystem with stronger assurances. Although some decentralized finance applications and use cases are already being implemented on ReddCoin’s network, the greater smart contract flexibility and capabilities brought by the Taproot upgrade can ultimately allow even more use cases to be implemented and more complex functionality to be deployed while leveraging the strong security assurances of the new code.

As RDD is actual money, long-term applications of decentralized finance can naturally only be built on top of it. Networks such as Ethereum lack the monetary properties of the Bitcoin base layer and its security and robustness — part of the reason why most applications built on them have fallen short of accomplishing their value proposition over the long run. By patiently building up the foundations for a distributed, uncensorable, antifragile, and sovereign monetary network throughout its lifetime, ReddCoin is set to enjoy actual long term functionality and growth through a layered approach.

CONCLUSION

In short, complex concepts come together to provide smaller more efficient transactions, more privacy, more user protection, and smart cotnract functionality allowing for complex operations on what would otherwise be a firaly simple blockchain. The features have been activated on the bitcoin blockchain, and ReddCoin is proud to incorporate much of the BTC developers work with some little additions of our own.

Endless credit to Barrystyle, CryptoGnasher and others for endless, dedicated work to incorporate new code into the latest versions of ReddCoin Core, solve new and intractable problems, and in general, bashing their heads on the monitors and keyboards for the benefit of the ReddCoin ecosystem. Thank a ReddCoin dev today! :)

About Redd

Redd is a global social movement that allows anyone, anywhere, the power to tip, support, donate and fund social causes, independent content creators, and humanitarian programs. The platform utilizes ReddCoin (RDD), a reliable and versatile decentralized cryptocurrency launched in 2014 that allows for seamless payments across borders and social networks. All Redd Partners are expected to adhere to the project’s high standards of openness, accountability, and user experience as we strive to be an example of not only the stated ideals of love, support and inclusion, but also integrity, transparency, and honor.

Feel free to visit us at Redd.Love, Reddcoin.com or email info@reddcoin.com. You can also follow us on YouTube, Twitter and Telegram Love to all of our Reddheads, new and old, and welcome!