5

I recently read Aaron van Wirdum's layman explanation of both scriptless scripts and taproot. 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?

8

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.

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.

  • 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. Jan 29 at 19:51
  • 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. – Andrew Chow Jan 29 at 20:46
  • 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. Jan 29 at 20:56
  • 4
    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 Jan 30 at 5:35
  • 3
    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 Jan 30 at 5:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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