<p>From what I've read and heard about MAST, it's an alternate version of pay-to-script-hash that uses a Merkle root instead of a regular hash digest.  It combines this idea with that of an <a href="https://en.wikipedia.org/wiki/Abstract_syntax_tree" rel="nofollow noreferrer">abstract syntax tree</a>, which is a data structure that compilers use to parse source code.  By "Merkelizing" a syntax tree, it allows redeemers to only expose the parts of the script being used for redemption.</p>

<p>This means that you can have more complicated scripts than are currently allowed by the 10,000 byte or 201 OP code limit.  Let's say there's a redemption script whose conditions look something like this:</p>

<pre><code>A OR (B AND (C OR D)) OR ((E OR F OR (G AND H)) AND NOT I)
</code></pre>

<p>Right now, this script would be too complicated to fit inside the limit.  By forming it into a syntax tree and Merkelizing it, a redeeming transaction would only have to expose the conditions that were met.  For example, just <code>A</code> would redeem it, and so would just <code>B</code> and <code>C</code>.  This fits inside the size limit, while also never revealing the unused conditions that <em>could</em> have been used to redeem the UTXO.  There's a complexity gain without introducing the risk of DOS attacks, as well as a privacy gain.</p>

<p>I'm unsure how this will directly help with scaling, but since it allows for more complex scripts without a transaction size increase, it certainly won't hurt.  It's just another building block at the disposal of a developer, which they can then hopefully use to solve some future problem.</p>

CC BY-SA 3.0
2016-11-03T19:18:17.987Z
Nit: a NOT condition in a script directly below an AND/OR tree makes no sense. If I is not allowed to sign, he just won't sign :)
Pieter Wuille
CC BY-SA 3.0
2016-11-03T19:20:24.677Z
@PieterWuille, you caught me!  I just thought I needed a NOT in there somewhere ;-b
Jestin
CC BY-SA 3.0
2016-11-03T19:23:30.043Z
@PieterWuille, also, for the record, nobody would ever have to know that particular branch was there...which is sort of the point :)
Jestin
CC BY-SA 3.0
2016-11-03T14:56:55.630Z
2016-11-03T18:25:41.350Z
2016-11-03T18:25:41.350Z
Jestin
<p>So, somebody asked me about MAST yesterday. </p>

<p>Apparently, it's formalized in <a href="https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki" rel="nofollow noreferrer">BIP114 – Merkelized Abstract Syntax Trees</a>.</p>

<p>I couldn't explain what it was and what advantages it'll bring us.</p>

<p>What are MAST, and how will they help with scaling?</p>

<taproot><mast>
I keep hearing about MAST, what is it and what does it do?
Murch
# I keep hearing about MAST, what is it and what does it do?

(Asked by: username_0 on 2016-11-03)

So, somebody asked me about MAST yesterday.

Apparently, it's formalized in [BIP114 – Merkelized Abstract Syntax Trees](https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki).

I couldn't explain what it was and what advantages it'll bring us.

What are MAST, and how will they help with scaling?

**Tags:** taproot, mast


---

## 1 answers

### Answer by username_1 on 2016-11-03. Score: 4 | Accepted answer

From what I've read and heard about MAST, it's an alternate version of pay-to-script-hash that uses a Merkle root instead of a regular hash digest. It combines this idea with that of an [abstract syntax tree](https://en.wikipedia.org/wiki/Abstract_syntax_tree), which is a data structure that compilers use to parse source code. By "Merkelizing" a syntax tree, it allows redeemers to only expose the parts of the script being used for redemption.

This means that you can have more complicated scripts than are currently allowed by the 10,000 byte or 201 OP code limit. Let's say there's a redemption script whose conditions look something like this:

```
A OR (B AND (C OR D)) OR ((E OR F OR (G AND H)) AND NOT I)

```

Right now, this script would be too complicated to fit inside the limit. By forming it into a syntax tree and Merkelizing it, a redeeming transaction would only have to expose the conditions that were met. For example, just `A` would redeem it, and so would just `B` and `C`. This fits inside the size limit, while also never revealing the unused conditions that *could* have been used to redeem the UTXO. There's a complexity gain without introducing the risk of DOS attacks, as well as a privacy gain.

I'm unsure how this will directly help with scaling, but since it allows for more complex scripts without a transaction size increase, it certainly won't hurt. It's just another building block at the disposal of a developer, which they can then hopefully use to solve some future problem.

> **Comments:**
> **username_2**: Nit: a NOT condition in a script directly below an AND/OR tree makes no sense. If I is not allowed to sign, he just won't sign :)  
> **username_1**: @username_2, you caught me!  I just thought I needed a NOT in there somewhere ;-b  
> **username_1**: @username_2, also, for the record, nobody would ever have to know that particular branch was there...which is sort of the point :)  

---

