Skip to content
Home » Part 1: Taproot & Schnorr and its Impact on Mining

Part 1: Taproot & Schnorr and its Impact on Mining

This is the first part of a two part blog post. Part 1 provides an overview of Bitcoin’s current signature scheme, an overview of Schnorr and Taproot, and an analysis of these upgrades from a miner’s perspective. Part 2 is a breakdown from a technical perspective so a reader can understand what this actually looks like under the hood. Here is a link to Part 2.

Schnorr and Taproot are long awaited and generally non-controversial upgrades to the Bitcoin network introduced in BIP340¹, BIP341², and BIP342³. Schnorr signatures are an upgrade to Bitcoin’s ECDSA signature scheme. Taproot is an upgrade to Bitcoin’s transaction scripting. While the benefits may at first be incremental, Schnorr and Taproot are a powerful duo with the potential to provide major scalability, privacy, and fungibility improvements as adoption rises.

This set of upgrades brings improvements to privacy, scalability, and fungibility with minimal tradeoffs, a rarity in this space, but Schnorr and Taproot have the potential to do so.

Review of Bitcoin’s Cryptography

If you are familiar with ECDSA, ECC, and the SECP256K1 curve, this section can be skipped.

Digital signatures are used to guarantee integrity (the message with not changed) and authenticity (the message was by the author).

In its most broad definition, digital signatures are used to cryptographically prove that some message has not been altered in transit and that it has been authored by someone with specific credentials. Digital signatures are based on public key cryptography, also called asymmetric cryptography. There is a private key (also sometimes referred to as a secret key) used to encrypt some message and a public key used to decrypt the message. The key pair works together to form a digital signature over this message. With no knowledge of the private key, anyone with the public key and signature can verify that this message was indeed signed by the holder of the private key. Public key cryptography unbelievably powerful and is used in almost every networking and computer system. Common applications like text messaging, voice messaging, and file sharing all are possible because of public key cryptography.

Digital signatures are used in Bitcoin to prove ownership of bitcoin. From a private key, which in the case of Bitcoin is just a 256-bit number (which translates to a number with a maximum of 77 digits), a public key is generated. The public key allows for the receiving of bitcoin, and the private key and signature allows for spending. Using the message and the private key, a signature is generated over a message. In the case of Bitcoin, this message is a specific transaction.

Only some output formats require publishing the public key (P2PKH, P2WPKH), because the funds were previously locked to the hash of a public key. Other transactions do not publish the public key, because it’s already part of the locking script in the unspent transaction output (UTXO) that is being spent (P2PK, P2TR). The P2PKH and P2WPKH transaction inputs (the most commonly used input types in Bitcoin) contains both the public key and signature of the participant who controls the associate private key (and thereby owns this bitcoin). All nodes on the network can verify that the public key matches the hash in the locking script, and that the signature is valid for the given public key, meaning the transaction was indeed signed by the owner of the private key and they are allowed to spend the bitcoin. If this is not the case, then the transaction is invalid and rejected by the network.²

There are many different types digital signature algorithms, but Bitcoin currently uses the Elliptic Curve Digital Signature Algorithm (ECDSA) scheme. ECDSA is based on elliptic curve cryptography (ECC). The security of ECC, specifically the assumption that the Elliptic Curve Discrete Logarithm Problem is hard to solve, is why a bitcoin can only be spent by the holder of the private key and by no one else, allowing for the Bitcoin network to determine whether someone has ownership of some bitcoins and can spend them. ECC is what enables a participant to generate a private and public key pair to create a signature and sign a message. Again, by signing a message (a transaction), the participant is cryptographically committing to that message. After cryptographically committing, the message cannot be changed. If the message is changed, the signature is invalidated.

For a detailed technical analysis of ECDSA, ECC, and the SECP256K1 curve, check out part 2 of this post.

Schnorr and Taproot

The Schnorr signature scheme offers the same cryptographic assumptions as ECDSA, Bitcoin’s current signature algorithm, but also has some more interesting properties. Specifically, Schnorr has a linearity property that allows for easy signature aggregation. This means that multiple signatures can be combined into one signature, which reduces the transaction size of more complex transactions. The ability to aggregate signatures also allows for an improved transaction scripting, especially when dealing with multisignature transactions in a new multisignature transaction scheme called MuSig.⁴

Currently, signature aggregation is only done in the context of an aggregated public key (e.g. by means of MuSig). Cross-input signature aggregation may eventually be added, where signatures of multiple inputs get aggregated. If this does get added in the future, transactions in a block that have been signed with Schnorr signatures can be combined into one, potentially allowing for more transactions in a block.

Taproot encompasses a myriad of features relating to Bitcoin’s transaction scripting. It defines an upgrade to the current SegWit v0 transaction type called SegWit v1, with two new output types that leverage the nice properties associated with Schnorr signatures, mainly the linearity property. These two new output types are key path spending and pay-to-taproot (P2TR). Taproot leverages Schnorr signatures in such a way that, from an on chain perspective, complicated transactions (like multisignature scripts and lightning channel closes) look no different than a simple single-script. It also introduces new OP codes that can be used to potentially make even more complex spending conditions.

The linearity property of Schnorr signatures improves network scalability: more transactions in the same block size. Furthermore, this potential increase in the number transactions in a block results in more total transaction fees per block, something that will become increasingly important to miners as the block subsidy diminishes over time.

The combination of Schnorr and Taproot improves the privacy of bitcoin because it is not possible to distinguish more complex transactions from a “regular” P2PKH transaction that simply sends some bitcoin from one address to another. This increase in privacy improves Bitcoin’s fungibility, making detailed insights more difficult to glean through chain analytics. Sometimes, chain analytics is performed to trace back the spend history of some bitcoin in an attempt to associate that bitcoin with nefarious activity.

The decision to upgrade the Bitcoin signature scheme and transaction format is not done lightly. Both of these are major network upgrades that require a lot of work to put into place. For this reason, the rationale to implement such a change must be a very good one. Schnorr signatures, however, provide so many benefits over ECDSA that the community, led by the developers, has decided to move forward with the proposal into the activation state.


The Schnorr signature scheme was patented up until February 2008. Because the wider cryptography community did not have access to Schnorr, consensus hadn’t built around its quality or features. In the time since the patent expired, significant work has been done on Schnorr and the cryptography community now general accepts that it is superior to ECDSA.

The choice of a cryptographic scheme is not done lightly. Choosing a scheme that is nascent or not well known can result in project-breaking security vulnerabilities. For this reason, it is inferred that ECDSA was initially chosen for Bitcoin because of its widespread use. It was one of the most popular and therefore reliable choices available at the time.

However, more time has passed since the release of Schnorr signatures into the public domain. With time, comes more development, trust, and widespread use, now making it a viable candidate over ECDSA.

The motivation behind BIP340 discusses how Schnorr is superior to the ECDSA signature scheme. The three main reason are:

1. Provable security: Schnorr signatures rely on weaker assumptions than ECDSA. Remember that in cryptography, assumptions relate to the hardness of the problem. The harder a problem is, the more difficult it is to crack. The weaker the assumptions, the harder the problem. In this case, it does not mean the ECDSA is insecure (easy to crack), it simply means that Schnorr is even harder to crack. It is an extra bonus Bitcoin gets with the adoption of Schnorr.

2. Non-malleability: ECDSA signatures are inherently malleable. This means that, without the private key, a third party can alter an existing valid signature for a given public key and message and create a new, still valid, signature. This does not reroute any funds, but it does change the transaction id in non-SegWit transactions, or the witness id in SegWit transactions.

In legacy transactions (non-SegWit), the attack is that upon submission to the network for confirmation, a nefarious recipient of the bitcoin can modify the signature which creates a new transaction id. The transaction id is how participants look up transactions. The sender has no knowledge of the modified transaction or modified transaction id. The nefarious recipient has received the coins via the modified transaction, but the sender is unaware of this. The nefarious recipient can then contact the sender and claim they never received their coins. The sender checks their original transaction id, and does not see it confirmed on the network. Believing it to be dropped, the sender will likely resend the nefarious recipient the funds in a new transaction, effectively paying them twice.

SegWit addressed this transaction malleability by separating the signature from the transaction and placing them in a witness structure that is committed to blocks separate from the transaction Merkle tree.⁵ In this way, the modifying the signature does not modify the transaction id. However, the witness transaction id is still open to malleability and this may reduce the efficiency of compact block relay.⁶

Since Schnorr signatures are not susceptible to malleability, these kinds of attacks are mitigated.

3. Linearity: Schnorr signatures are linear, meaning that multiple Schnorr signatures can be simply and efficiently combined into a single signature. This primitive is leveraged to improve privacy and security for more complex transaction types like multisignatures.

The linearity property of Schnorr signatures provides a big win for network scalability and privacy. This property allows for a potential of 2.5x faster block validation times as well as a size reduction in complex scripting transaction via the ability to express multiple signatures as a single signature and single public key. These features directly correlate to an increase in network scalability.

The linearity property (in conjunction with Taproot) allows for collaborating parties to aggregate (combine) multiple public keys and produce a single public key and a single signature over the transaction. Making complex transactions indistinguishable from single-script transactions is inherently more private from an on-chain analysis perspective. This is because it is more difficult for outside actors to distinguish how a bitcoin is being spent and by whom. This privacy increase lends itself to an increase in fungibility since the spending history of some bitcoin is harder to tie back to a specific participant, making more difficult to categorize specific outputs in an attempt to devalue them.

One downside to Schnorr, stemming from its previous patent, has been is its lack of standardization. However, in BIP340¹, the Bitcoin developers have defined the following standard:

1. Signature encoding: Uses a 64-byte format instead of the variable sized (up to 72 bytes) DER encoding currently used in Bitcoin signatures.

2. Public key encoding: Public keys are encoded in 32 bytes instead of the compressed 33-byte encodings of elliptic curve points.

3. Batch verification: Schnorr’s linearity property means the ability to batch signatures, as opposed to ECDSA which must verify each signature.

4. Completely specified: The developers have completely specified Schnorr’s signature algorithm at the byte level. A lack of standardization can cause compatibility issues between verifiers. This was an issue with the DER encoding of ECDSA signatures in Bitcoin in the past and required another BIP (BIP66⁷) to address it.

One concern when changing signature schemes is the preservation of key derivation algorithms currently used in Bitcoin. For example, if a signature upgrade invalidated things like hierarchical deterministic (HD) wallets used extensively in applications built on top of bitcoin including all major wallets, then this change would likely be a very contentious one that would not make it to the activation stage.⁸ Fortunately, the underlying SECP256K1 elliptic curve used in the ECDSA signature scheme is still used in this Schnorr signature scheme. This means that the generation of key pairs and the use of use of common methods like HD wallet derivations are still completely valid.


The motivation behind taproot according to BIP0341 is to “improve privacy, efficiency, and flexibility of Bitcoin’s scripting capabilities without adding new security assumptions. Specifically, it seeks to minimize how much information about the spendability conditions of a transaction output is revealed on chain at creation or spending time and to add a number of upgrade mechanisms, while fixing a few minor but long-standing issues.”²

Taproot transactions are spent using a new transaction type, SegWit v1. SegWit v1 outputs are called pay-to-taproot (P2TR) outputs and can be spent in two ways, key path spending or script path spending.

Key path spending is the default spending path used in “regular” transactions (akin to P2PKH) and MuSig. In key path spending, the witness program is the x coordinate of the public key. The locking script takes the form OP_1 <witness program>.To unlock this type of output, a signature from that public key is required. The MuSig protocol is can be used to make a k-of-m output indistinguishable from a single-key output.⁹

In script path spending, the output is spent with a pre-committed script using TaprootTrees, something that is not discussed in detail in this post.

The Schnorr and Taproot upgrades include many changes. This blog post is already long enough, so some features are omitted including a detailed discussion of TapTrees and TapScript.

Activation of Schnorr + Taproot

As with any major network upgrades, there must be a well defined path towards activation. Activation methods are required in order to let the network participants (including devs, miners, and nodes) the opportunity to show support or disagreement for an upgrade. An upgrade cannot just be pushed through because participants, namely miners, need time to upgrade their Bitcoin nodes to the latest version that includes the upgrade. Miners show their readiness for an update in accordance with the rules of activation method being used. “Readiness” simply means that the miner has updated their Bitcoin nodes to the support the latest and greatest version with the new updates.

While it seems simple on the surface, choosing an ineffective activation method can lead to a multitude of unforeseen problems.¹⁰ A well-known example of activation gone wrong is that of SegWit. SegWit was a very contentious network upgrade because it eliminated gains realized through covert ASIC boost. Given the highly competitive nature of mining, miners did not want to give up the edge gained through covert ASIC boost, but did not want to publicly admit to their competitors that they were using covert ASIC boost.¹¹

SegWit used the BIP9 activation method, which is described in detail in a previous post. In short, BIP9 defines a certain amount of time (typically set to 1 year) in which miners can signal their readiness for the upgrade. A miner signals readiness by flipping a predefined bit in the version field that is associated with the upgrade in question. If 95% of the network signals readiness within the timeout period, then the activation has successfully completed. If 95% is not achieved within this timeout period, the the activation fails.

Ultimately SegWit did activate, but not without creating an untold amount of strife in the community, specifically causing a rift between developers and miners. Even though SegWit was a distinct upgrade from 2x, it also occurred during the big block debate. Attempts by some parties to tie SegWit activation to a block-size increase also angered developers and users, who revolted to force a SegWit-only activation.

No one, not developers nor miners, wants a repeat of the SegWit drama. Developers do not want to be seen as forcing an unwanted change on everyone (especially if that change results in unforeseen negative consequences to the network), while at the same time, do not want to be beholden to stubborn miners acting in their own interests rather than in the interests of the health of the network as a whole. Miners don’t want any more bad press.

For this reason, the activation method of BIP340, BIP341, and BIP342 is a hot topic that all parities are putting a lot of effort into planning. Fortunately, these upgrades are palatable to all parties for the most part. Developers and users are in support of the increase privacy and scalability that Schnorr and Taproot can theoretically achieve. Miners are relatively unaffected by the change, and if anything recognize that the reduction in size of transactions that include more complex scripting will result in more transaction in a block and thus more transaction fees. It is also likely that miners are eager to show support for something that developers want that does not inherently impact their bottom line, in an attempt maintain the peace.

Currently there are four various methods being discussed towards activating BIP340, BIP341, and BIP342: (1) BIP8 fail at timeout, (2) BIP8 activate at timeout, (3) Modern Activated Soft Fork (MASF), and (4) Townes’ proposal.¹²

BIP8 is very similar to BIP9, with a couple changes. The first being that BIP8 measures the timeout period in blocks, whereas BIP9 uses time. There are also two possible outcomes at the end of a timeout with BIP8: the upgrade fails (BIP9 behavior), or the upgrade automatically succeeds regardless of the percent of the network that signaled readiness.

Again, since developers do not want to be seen as having an over representation in the network, the community appears to be leaning towards the BIP8 fail at timeout activation method. There are a couple more methods worth discussing, however.

MSFA, proposed by Matt Corallo, can be seen as an extension of BIP8. Initially, BIP8 fail at timeout is used, with a timeout of 52,560 blocks (~1 year). If a failure occurs, there will be a 6 month review period for community reflection and review, followed by another instantiation of BIP8 activate at timeout. This timeout is set to 105,100 blocks (~2 years), in which the upgrade will activate independent of the percentage of the network that has signaled readiness.

How These Upgrades Relate to Mining

Transaction Fees

In Part 2 of this post, two transaction types are explored for both Segwit V0 (current type) and SegWit V1 (Schnorr + Taproot type) transactions. It is shown that in a single script transaction, there is a reduction in transaction weight of ~10%, and in the 2-of-2 multisignature transaction, there is a reduction in transaction weight of nearly ~28%. Also notice that in SegWit V1, both transactions have the same weight since the two transaction types are indistinguishable from one another from an on-chain perspective.

SegWit V0 SegWit V1 % Reduction
Single 437 396 ~10%
2-of-2 549 396 ~28%

As block subsidies diminish with time, transaction fees become increasingly important for miners. To maximize fees, miners try to find a balance between fee amount and transaction weight (this is akin to the knapsack problem).¹³

Transaction weight is measured in vbytes, a developer defined unit designed to quickly assess how heavy (aka expensive to include in a block) a transaction is. One vbyte is equal to four weight units, another developer defined unit of transaction weight measurement for legacy (pre-SegWit) transactions. The block limit is 4M or 1M vbytes.¹⁴

A reduction in transaction size does come at a reduction in fees (less vbytes, less fees). Theoretically, fitting more transactions in a block does not change the total vbytes in the block, resulting in unchanged total fees. One vbyte is still one vbyte. In practice however, a Schnorr and Taproot activation will likely cause an increase in fees per block. This is because demand for blockspace today grossly exceeds availability, so incrementally increasing blockspace will add transactions without meaningfully reducing the demand.

Before a transaction can get confirmed, it needs to be accepted by a node and placed in its mempool. The number of transactions a mempool can accept is capped, however. In the node’s configuration file, the maximum mempool size is set by default to be 300MB (which most nodes never change). This means that once a node’s mempool hits its defined limit, it does not accept any more incoming unconfirmed transactions (or it drops transactions in favor of transactions coming in with a higher per vbyte fee).

As it stands, the Bitcoin network has enough transactions to saturate a node’s mempool at the default setting, creating competition between network participants to include a higher per vbyte fee in order to get their transaction confirmed. This competition for block space is why fitting more transactions into a block will likely increase block fees: participants pay per vbyte, but there is an up-charge due to block space competition, making the price per vbyte non-linear. Therefore, since a Schnorr + Taproot activation ultimately results in smaller transactions sizes (by at least 10%), miners’ fees per block will likely increase, something miners should be cheering for.


For the same reasons Schnorr and Taproot increase privacy, they also increase fungibility, an important feature of any currency. The fungibility of bitcoins is imperative to the success of the network as it pertains to all users. One bitcoin must equal to one bitcoin now and forever.

In keeping track of the industry, something that miner’s shouldn’t be cheering for are these two concepts that have come up in relation to fungibility: clean coins and green coins.

Clean Coin

A myth in the mining is the idea of virgin or clean bitcoins— bitcoins that come specifically from the block subsidy that could potentially hold higher value than other Bitcoins on the network, because they possess no prior transaction history that could taint them.

Green Coins

As bitcoin has become more widely adopted, Environmental, Social, and Governance (ESG) groups exploring bitcoin who are critical of the network’s energy usage have argued that some coins should be worth more or less depending on the green energy profile of miners who produced them. The idea is to incentivize miners to use renewable energy sources and encourage people to use green bitcoins as they would have a higher value attributed to it than non-green coins. This higher attributed value would come from pressure applied by the energy sector onto institutions and vendors to favor green coins.

The Problem with the Clean & Green Coins

These concepts are flawed for a couple reasons:

There is no distinction between the newly issued coins in a block and transaction fees in a block, which means that newly minted bitcoins are mixed with the coins paid by transactors in a block, which themselves may not be “clean”.Pools currently assemble blocks, and the coin flow starts at the pools’ addresses. Depending on the pool, miners can see multiple hops of coin movement prior to the coins landing in their wallets — usually attributed to change addresses.It also does not take into account the transaction fees, something that become increasingly significant as the block subsidy diminishes over time. When a block is found by a pool, that block subsidy and all its transactions fees are paid to the pool’s address, not to the miner who found the valid block. The miner is then paid from the pool’s address and, even if they were lucky enough to find a block, is in no way guaranteed payment of the exact bitcoin that was minted in that specific block. So the bitcoin that is paid out to all miners includes block subsidies and transaction fees with a multitude of addresses with very different histories, all from different blocks.

If some coins are valued over others, a tiered system emerges where some coins are less valuable than others. A tiered bitcoin system in many ways would be very, very bad for fungibility, miners, and the Bitcoin network as a whole. Because the Schnorr and Taproot upgrades obfuscate some of the details of the script execution, it makes it more difficult to label one bitcoin as being worth less than another bitcoin because it is more difficult to obtain an accurate understanding of a bitcoin’s spend history, thereby increasing network fungibility. For this reason, miners, developers, and the community as a whole seem to be in general agreement for activation. Several miners have already signaled their support in their block headers even though activation has not been started or the method even completely determined.

Understanding how Schnorr and Taproot work together to provide these privacy, scalability, and fungibility improvements is of upmost importance in order to properly leverage them for both institutional and individual use.

Further Exploration

The Bitcoin Optech Schnorr/Taproot workshop is a great resource for learning more and playing around with the signatures and transactions. The most up to date branch is the 32-bytes-keys branch. Clone it locally along with the bitcoin branch Taproot_V0.1.5-proposed. Build on that branch and make sure the wallet is enabled.Bitcoin Optech: TaprootMurch’s 2-of-3 inputs using Pay-to-TaprootBitcoin Technology Development Talks: Schnorr signatures

Special thanks to Valentine Wallace, Mark Erhardt, Carl Dong, and Harry Sudock for all their feedback.


[1]: Pieter Wuille, Jonas Nick, Tim Ruffing. (January 19, 2020). Schnorr Signatures for secp256k1.

[2]: Pieter Wuille, Jonas Nick, Anthony Towns. (January 19, 2020).Taproot: SegWit version 1 spending rules.

[3]: Pieter Wuille, Jonas Nick, Anthony Towns. (January 19, 2020). Validation of Taproot Scripts.

[4]: Gregory Maxwell, Andrew Poelstra, Yannick Seurin , Pieter Wuille. (May 20, 2018). Simple Schnorr Multi-Signatures with Applications to Bitcoin.

[5]: Eric Lombrozo, Johnson Lau, Pieter Wuille. (December 21, 2015). Segregated Witness (Consensus layer).

[6]: Johnson Lau, Pieter Wuille. (August 16, 2016). Dealing with signature encoding malleability.

[7]: Pieter Wuille. (January 10, 2015). Strict DER signatures.

[8]: Pieter Wuille. (February 11, 2012). Hierarchical Deterministic Wallets.

[9]: Murch. (August 18, 2020). 2-of-3 inputs using Pay-to-Taproot.

[10]: Reddit u/almkglor. (July 14, 2020). Technical: The Path to Taproot Activation.

[11]. Dr. Timo Hanke. (March 31, 2016). AsicBoost ­A Speedup for Bitcoin Mining.

[12]: Coin Harper. (January 13, 2021). Bitcoin Miners, Developers Narrow Down How Taproot Will Be Activated.

[13]: Wikipedia. (February 3, 2021). Knapsack problem.

[14]: Bitcoin Wiki. (January 17, 2018). Weight units.

Legal Disclosure: This blog, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any banking services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this blog are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital own investments in some of the digital assets and protocols discussed in this blog. Except where otherwise indicated, the information in this blog is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. For all inquiries, please email ©Copyright Galaxy Digital Holdings LP 2021. All rights reserved.

Part 1: Taproot & Schnorr and its Impact on Mining was originally published in Galaxy Digital Mining on Medium, where people are continuing the conversation by highlighting and responding to this story.

Leave a Reply

Generated by Feedzy