<p>Taproot would improve the privacy and fungibility of Bitcoin transactions. It seems Smart contract payments, Lightning payments, and sophisticated multi-signature smart contract payments all look the same after Taproot. When Taproot does eventually roll out, it is likely to be followed by more incremental protocol upgrades. <em>Graftroot</em>, which delegates signatures to allow for additional multi-sig functionality.</p>
<p>Please let me describe the building blocks of Taproot for better context.</p>
<p>The aim of Taproot is to ensure that Pay to Script Hash (P2SH) transactions appears indistinguishable from other transaction types therefore improving privacy and scalability. There is a proposal within Taproot to replace EDCSA with Schnorr signatures and therefore allow signers to jointly produce a signature, rather than needing to compute independently and add to the transaction.</p>
<p>Taproot also introduces Merklized Abstract Syntax Trees (MAST). MAST looks to provide additional privacy for complex redeem conditions by hashing the various potential routes. Taproot aims to use MAST in order to hide all conditions for spending and reduce the size of this information. Taproot uses MAST to include the merklized hash as the public key, thereby then includes making a complex script transaction indistinguishable from a standard P2PKH transaction.</p>
<p>The introduction of MAST within Taproot improves both the scalability for complex redemption conditions as well as transaction privacy by obscuring the existence of alternative routes. Please find an interesting write up on Taproot, MAST and Schnorr Signature here.</p>
<ul>
<li><a href="https://bitcoinmagazine.com/articles/taproot-coming-what-it-and-how-it-will-benefit-bitcoin" rel="nofollow noreferrer">Taproot Is Coming - Bitcoin Magazine</a></li>
<li><a href="https://medium.com/@tara.annison/what-are-taproot-mast-and-schnorr-signatures-b737dae20681" rel="nofollow noreferrer">What is Taproot - Tara Annison</a></li>
</ul>

CC BY-SA 4.0
2020-06-19T12:57:49.173Z
2020-06-19T12:57:49.173Z
Gokul Alex
<p>Tapscript proposes to make disabled opcodes OP_SUCCESSx meaning that new opcodes could potentially be introduced in a future soft fork (hopefully in SegWit v2.0).</p>
<p>Here's a list of potential opcodes I'm most excited;</p>
<ol>
<li><code>OP_CHECKSIGFROMSTACK</code> for arbitrary signature verification from stack.</li>
<li><code>OP_SUBSTR</code> for data manipulation from stack.</li>
<li><code>OP_AND</code> <code>OP_OR</code> for bitwise logic.</li>
<li>Arithmetic operations with bigger than 32-bit integers.</li>
<li>Some opcodes for writing to stack.</li>
</ol>

CC BY-SA 4.0
2020-11-16T16:21:25.007Z
2020-11-16T16:32:58.053Z
2020-11-16T16:32:58.053Z
Brqoo
<p>I think it's important to note first that BIP341-BIP342 are improvements to the Bitcoin script &quot;framework&quot; more than they are improvements to the smart contracting &quot;functionality&quot;.</p>
<p>All Bitcoin scripts can do in practice is enforce combinations of conditions on signatures by certain (sub)sets of <strong>signers</strong>, <strong>timelocks</strong>, and revealing <strong>hashes</strong>. At a conceptual level, this does not change with Taproot - everything that can be implemented using it can be implemented without Taproot too.</p>
<p>What it does do is:</p>
<ul>
<li>Make certain things smaller/cheaper (but sometimes at the cost of higher signer complexity).</li>
<li>Make certain things more private.</li>
<li>Make certain things easier to do.</li>
<li>Add mechanisms through which actual new conditions/features can be added later.</li>
</ul>
<p>In some cases, these advantages can be very substantial though - making the difference between feasible and infeasible in practice, or between actually incentivizing more private constructions or not.</p>
<p>It's hard to give a comprehensive answer what that entails, as it's akin to a new programming language, and there are presumably many things it enables that haven't been discovered yet. I can give a few examples though:</p>
<ul>
<li>The &quot;Taproot&quot; function itself means that any output, regardless of how complex its script is, can be spent using a single signature on-chain if all signers agree with spending (which also reduces their costs, but it may complicate the signing procedure). This applies to escrows, cooperative Lightning closes and various other things.</li>
<li>Various kinds of multisig become cheaper even when the &quot;optimistic&quot; taproot single-key spend can't be used, either through key aggregation (one key representing multiple people), or MAST (just revealing a script that embodies the exact condtions that were satisfied, rather than revealing all possible conditions). The advantages of key aggregation are in theory already possible using multiparty ECDSA, but that is significantly more complex than what is possible with the Schnorr signatures introduced by BIP340, and not used by anything in practice (as far as I know).</li>
<li>Atomic swaps, which can be used as a new privacy tool, are also in theory possible using multiparty ECDSA, but become a lot simpler using Schnorr based adaptor signatures.</li>
</ul>

CC BY-SA 4.0
2020-11-16T19:14:31.497Z
2020-11-16T19:14:31.497Z
Pieter Wuille
<p>From a strictly technical perspective, MAST makes a lot of sense. However, <em>understanding it</em> in the context of Taproot/Tapscript does require prior knowledge in Merkle Trees and hash functions. </p>

<p>What are some toy use cases that could be used to highlight Taproot's value proposition? From what I've seen, 2FA-like applications are often used as example, but what are other fun applications this technology could serve?</p>

<smartcontracts><schnorr-signatures><taproot>
What are some interesting applications of Taproot "smart contracts"?
metahash
# What are some interesting applications of Taproot "smart contracts"?

(Asked by: username_0 on 2020-05-19)

From a strictly technical perspective, MAST makes a lot of sense. However, *understanding it* in the context of Taproot/Tapscript does require prior knowledge in Merkle Trees and hash functions.

What are some toy use cases that could be used to highlight Taproot's value proposition? From what I've seen, 2FA-like applications are often used as example, but what are other fun applications this technology could serve?

**Tags:** smartcontracts, schnorr-signatures, taproot


---

## 3 answers

### Answer by username_3 on 2020-11-16. Score: 6 | Accepted answer

I think it's important to note first that BIP341-BIP342 are improvements to the Bitcoin script "framework" more than they are improvements to the smart contracting "functionality".

All Bitcoin scripts can do in practice is enforce combinations of conditions on signatures by certain (sub)sets of **signers**, **timelocks**, and revealing **hashes**. At a conceptual level, this does not change with Taproot - everything that can be implemented using it can be implemented without Taproot too.

What it does do is:

* Make certain things smaller/cheaper (but sometimes at the cost of higher signer complexity).
* Make certain things more private.
* Make certain things easier to do.
* Add mechanisms through which actual new conditions/features can be added later.

In some cases, these advantages can be very substantial though - making the difference between feasible and infeasible in practice, or between actually incentivizing more private constructions or not.

It's hard to give a comprehensive answer what that entails, as it's akin to a new programming language, and there are presumably many things it enables that haven't been discovered yet. I can give a few examples though:

* The "Taproot" function itself means that any output, regardless of how complex its script is, can be spent using a single signature on-chain if all signers agree with spending (which also reduces their costs, but it may complicate the signing procedure). This applies to escrows, cooperative Lightning closes and various other things.
* Various kinds of multisig become cheaper even when the "optimistic" taproot single-key spend can't be used, either through key aggregation (one key representing multiple people), or MAST (just revealing a script that embodies the exact condtions that were satisfied, rather than revealing all possible conditions). The advantages of key aggregation are in theory already possible using multiparty ECDSA, but that is significantly more complex than what is possible with the Schnorr signatures introduced by BIP340, and not used by anything in practice (as far as I know).
* Atomic swaps, which can be used as a new privacy tool, are also in theory possible using multiparty ECDSA, but become a lot simpler using Schnorr based adaptor signatures.


---

### Answer by username_1 on 2020-06-19. Score: 2

Taproot would improve the privacy and fungibility of Bitcoin transactions. It seems Smart contract payments, Lightning payments, and sophisticated multi-signature smart contract payments all look the same after Taproot. When Taproot does eventually roll out, it is likely to be followed by more incremental protocol upgrades. *Graftroot*, which delegates signatures to allow for additional multi-sig functionality.

Please let me describe the building blocks of Taproot for better context.

The aim of Taproot is to ensure that Pay to Script Hash (P2SH) transactions appears indistinguishable from other transaction types therefore improving privacy and scalability. There is a proposal within Taproot to replace EDCSA with Schnorr signatures and therefore allow signers to jointly produce a signature, rather than needing to compute independently and add to the transaction.

Taproot also introduces Merklized Abstract Syntax Trees (MAST). MAST looks to provide additional privacy for complex redeem conditions by hashing the various potential routes. Taproot aims to use MAST in order to hide all conditions for spending and reduce the size of this information. Taproot uses MAST to include the merklized hash as the public key, thereby then includes making a complex script transaction indistinguishable from a standard P2PKH transaction.

The introduction of MAST within Taproot improves both the scalability for complex redemption conditions as well as transaction privacy by obscuring the existence of alternative routes. Please find an interesting write up on Taproot, MAST and Schnorr Signature here.

* [Taproot Is Coming - Bitcoin Magazine](https://bitcoinmagazine.com/articles/taproot-coming-what-it-and-how-it-will-benefit-bitcoin)
* [What is Taproot - Tara Annison](https://medium.com/@tara.annison/what-are-taproot-mast-and-schnorr-signatures-b737dae20681)


---

### Answer by username_2 on 2020-11-16. Score: 1

Tapscript proposes to make disabled opcodes OP\_SUCCESSx meaning that new opcodes could potentially be introduced in a future soft fork (hopefully in SegWit v2.0).

Here's a list of potential opcodes I'm most excited;

1. `OP_CHECKSIGFROMSTACK` for arbitrary signature verification from stack.
2. `OP_SUBSTR` for data manipulation from stack.
3. `OP_AND` `OP_OR` for bitwise logic.
4. Arithmetic operations with bigger than 32-bit integers.
5. Some opcodes for writing to stack.


---

