5

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?

Improve this question

3 Answers 3

Reset to default
6

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.
Improve this answer
3

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.

Improve this answer
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.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.