<p>Scriptless scripts are more like the constructs used in HTLCs and Taproot is more like P2SH.</p>

<p>The common example used for scriptless scripts is adaptor signatures. With adaptor signatures, what one person A wants is a valid signature which person B is able to provide but only if they receive payment. This scriptless script allows person A to give person B money, and when person B takes the money, they automatically will reveal to person A the complete signature that person A wanted. This process is done without any scripting, just changing signature values and the transactions all appear as normal transactions.</p>

<p>However, what Taproot does is very different. Taproot hides a script inside of a signature. In Taproot, you have a tree of possible conditions. At the top level, you have a n-of-n multisignature of all parties involved, or some script that allows some parties to spend. If all <code>n</code> parties agree, then the multisig is used and the transaction appears like a normal transaction.</p>

<p>But if not all parties agree, then the script must be executed. Once this happens, the spending transaction will no longer look like a normal transaction. It will be very obviously spending a Taproot output. The script will be revealed and the conditions of that script will need to be checked.</p>

CC BY-SA 4.0
2019-01-29T19:51:35.503Z
I don’t fully understand the taproot collaborative branch. So an off-chain protocol must allow participants to individually execute/verify the spending script of one of the complex branches, then settle via collaborative branch if verified. So script branch verification only amongst signers, not on-chain? Why do non spending signers have incentive to collaborate?
James C.
CC BY-SA 4.0
2019-01-29T20:46:30.290Z
No, the script is only for non-collaborative case. There is no script execution that happens off chain; nothing happens off chain. The theory is that for every case involving multiple people, there is implicitly a case where all of them agree.
Ava Chow
CC BY-SA 4.0
2019-01-29T20:56:02.180Z
So the collaborative spend always implies one script branch has its spending conditions fulfilled, right? The unlocking data is not broadcast though, instead the musig branch is spent. How do they agree that spending conditions of the script branch have been met without executing it? If no execution, why even commit these script ops to the root?
James C.
CC BY-SA 4.0
2019-01-30T05:35:11.967Z
The top level of taproot doesn't need to be N of N, it could be some other admissible set of authorizers, it's just that N of N is almost always sufficient. E.g. if your policy is (A&&B) || (A && timelock) || (B && 2-of-3(C,D,E))  An A+B toplevel  isn't everyone, but it's sufficient. Likewise  2of3 B+C,B+D,B+E could be a taproot top level and would also be acceptable-- you'd prefer to use whichever of these is a more likely outcome.
G. Maxwell
CC BY-SA 4.0
2019-01-30T05:39:10.507Z
James C. if they don't cooperate the transaction will have higher fees and be less private. They don't have to, but they can. If this is a concern for some protocol you can have parties prepay additional fees, then refund them in the cooperatives case, but keep them if they don't cooperate.
G. Maxwell
CC BY-SA 4.0
2019-01-30T07:58:17.837Z
I see, thank you @G.Maxwell. So we could use the taproot top level  branch to settle the contract, and because authorisers were collaborative, return their prepaid fees via script-less scripts? :)
James C.
CC BY-SA 4.0
2019-01-29T19:29:24.370Z
2019-01-29T19:29:24.370Z
Ava Chow
<p>One of the most common use of script in Bitcoin is to construct logically atomic operations, such as "Tx2 happens if and only if Tx1 happens".</p>

<p>Scriptless scripts tells us how to use the additive properties of schnorr-signatures to construct atomic transactions without using script. Doing so this way will make them more efficient and private.</p>

<p>Taproot is an idea which uses the additive property of ECC public keys to allow users to commit to a script which is only revealed if needed. If it isn't needed, it is never even revealed that a script existed at all.</p>

<p>This is useful because almost all sensible contract terms (both smart and otherwise) can be rewritten as a top level OR between "Everyone agrees" and the actual contract, and because (with schnorr) you can make a single signature work for the everyone agrees case.</p>

<p>Taproot itself doesn't depend on the specific properties of schnorr and could be implemented e.g. for ECDSA. Technically taproot works outside of the EC signature itself to allow you to spend either via a single plain signature OR some other conditions, with the existence of other conditions hidden if you spend via the signature. But with ECDSA it isn't easy to use a single public key to represent the "everyone agrees" case, so taproot would be much less useful.</p>

<p>So, for example, if you had an output that could be spent either by Alice or by Bob but only after a time limit then pattern would be more efficient with ECDSA taproot than without taproot: Alice's key would be used to generate the root, and bob's key and timeout would be in the hidden script.</p>

CC BY-SA 4.0
2021-06-20T01:37:02.393Z
the coolest part is that in cooperative case you’ll pay the same transaction fee no matter how large your actual script is. Free “gas” basically.
dk14
CC BY-SA 4.0
2019-01-30T05:57:19.400Z
2019-01-30T05:57:19.400Z
G. Maxwell
<p>I recently read Aaron van Wirdum's layman explanation of both <a href="https://bitcoinmagazine.com/articles/scriptless-scripts-how-bitcoin-can-support-smart-contracts-without-smart-contracts/" rel="noreferrer">scriptless scripts</a> and <a href="https://bitcoinmagazine.com/articles/taproot-coming-what-it-and-how-it-will-benefit-bitcoin/" rel="noreferrer">taproot</a>. I gather that both utilize the aggregation of Schnorr signatures to hide complex scripts (smart contracts) in a normal-looking transaction. What are the finer details that sets the two schemes apart?</p>

<taproot><schnorr-signatures>
How are scriptless scripts and taproot different?
blee
# How are scriptless scripts and taproot different?

(Asked by: username_0 on 2019-01-29)

I recently read Aaron van Wirdum's layman explanation of both [scriptless scripts](https://bitcoinmagazine.com/articles/scriptless-scripts-how-bitcoin-can-support-smart-contracts-without-smart-contracts/) and [taproot](https://bitcoinmagazine.com/articles/taproot-coming-what-it-and-how-it-will-benefit-bitcoin/). I gather that both utilize the aggregation of Schnorr signatures to hide complex scripts (smart contracts) in a normal-looking transaction. What are the finer details that sets the two schemes apart?

**Tags:** taproot, schnorr-signatures


---

## 2 answers

### Answer by username_3 on 2019-01-30. Score: 9 | Accepted answer

One of the most common use of script in Bitcoin is to construct logically atomic operations, such as "Tx2 happens if and only if Tx1 happens".

Scriptless scripts tells us how to use the additive properties of schnorr-signatures to construct atomic transactions without using script. Doing so this way will make them more efficient and private.

Taproot is an idea which uses the additive property of ECC public keys to allow users to commit to a script which is only revealed if needed. If it isn't needed, it is never even revealed that a script existed at all.

This is useful because almost all sensible contract terms (both smart and otherwise) can be rewritten as a top level OR between "Everyone agrees" and the actual contract, and because (with schnorr) you can make a single signature work for the everyone agrees case.

Taproot itself doesn't depend on the specific properties of schnorr and could be implemented e.g. for ECDSA. Technically taproot works outside of the EC signature itself to allow you to spend either via a single plain signature OR some other conditions, with the existence of other conditions hidden if you spend via the signature. But with ECDSA it isn't easy to use a single public key to represent the "everyone agrees" case, so taproot would be much less useful.

So, for example, if you had an output that could be spent either by Alice or by Bob but only after a time limit then pattern would be more efficient with ECDSA taproot than without taproot: Alice's key would be used to generate the root, and bob's key and timeout would be in the hidden script.

> **Comments:**
> **username_4**: the coolest part is that in cooperative case you’ll pay the same transaction fee no matter how large your actual script is. Free “gas” basically.  

---

### Answer by username_1 on 2019-01-29. Score: 6

Scriptless scripts are more like the constructs used in HTLCs and Taproot is more like P2SH.

The common example used for scriptless scripts is adaptor signatures. With adaptor signatures, what one person A wants is a valid signature which person B is able to provide but only if they receive payment. This scriptless script allows person A to give person B money, and when person B takes the money, they automatically will reveal to person A the complete signature that person A wanted. This process is done without any scripting, just changing signature values and the transactions all appear as normal transactions.

However, what Taproot does is very different. Taproot hides a script inside of a signature. In Taproot, you have a tree of possible conditions. At the top level, you have a n-of-n multisignature of all parties involved, or some script that allows some parties to spend. If all `n` parties agree, then the multisig is used and the transaction appears like a normal transaction.

But if not all parties agree, then the script must be executed. Once this happens, the spending transaction will no longer look like a normal transaction. It will be very obviously spending a Taproot output. The script will be revealed and the conditions of that script will need to be checked.

> **Comments:**
> **username_2**: I don’t fully understand the taproot collaborative branch. So an off-chain protocol must allow participants to individually execute/verify the spending script of one of the complex branches, then settle via collaborative branch if verified. So script branch verification only amongst signers, not on-chain? Why do non spending signers have incentive to collaborate?  
> **username_1**: No, the script is only for non-collaborative case. There is no script execution that happens off chain; nothing happens off chain. The theory is that for every case involving multiple people, there is implicitly a case where all of them agree.  
> **username_2**: So the collaborative spend always implies one script branch has its spending conditions fulfilled, right? The unlocking data is not broadcast though, instead the musig branch is spent. How do they agree that spending conditions of the script branch have been met without executing it? If no execution, why even commit these script ops to the root?  
> **username_3**: The top level of taproot doesn't need to be N of N, it could be some other admissible set of authorizers, it's just that N of N is almost always sufficient. E.g. if your policy is (A&&B) || (A && timelock) || (B && 2-of-3(C,D,E))  An A+B toplevel  isn't everyone, but it's sufficient. Likewise  2of3 B+C,B+D,B+E could be a taproot top level and would also be acceptable-- you'd prefer to use whichever of these is a more likely outcome.  
> **username_3**: username_2 C. if they don't cooperate the transaction will have higher fees and be less private. They don't have to, but they can. If this is a concern for some protocol you can have parties prepay additional fees, then refund them in the cooperatives case, but keep them if they don't cooperate.  
> **username_2**: I see, thank you @G.username_3. So we could use the taproot top level  branch to settle the contract, and because authorisers were collaborative, return their prepaid fees via script-less scripts? :)  

---

