This topic comes up often, taproot and its advantages. But honestly 90% of the advantage is MAST.
Ok, I probably lost most of you here. So lets do a very brief overview.
- P2SH (pay to script).
The idea is that a single script is passed into the ‘input’ or unlocking script to be executed. Important detail is that script can’t call it and thus we avoid recursion.
- Merklized Abstract Syntax Trees (MAST).
The idea here is that the input provides a merkle-proof (several hashes) as well as a script. Those together can be hashed into the merkle-root which makes up the address the user initially paid to.
this is mostly btc specific stuff, it removes limits and adds some opcodes or something. I’m sure others can comment more, but on top of mast there is little of value for BCH here.
P2SH has 2 main advantages, one is the ability to have any type of script and still have a single simple address to pay to. Making QR codes stay short.
The second is one of privacy. The script is not available until the money is being spent which makes attacks massively harder.
The first advantage, having a simple address, is something we can obsolete by moving to better payment protocols. BIP70 already solves this, we will see this continue to be improved I’m sure.
Privacy is still in need to be solved, though.
Notice that p2sh ALSO solves another issue, that the current relay rules are such that only standardized scripts are accepted by the network. This isn’t even a consensus rule and I think it adds no value to the network. We could remove that ‘standardness’ rule if we wanted to.
P2SH adds privacy and discourages brute-forcing attacks on payments already mined by hiding the actual script. Which is nice.
MAST is actually specifically designed for this, though. It even goes a step further by allowing unlocking to happen with only a part of the unlocking script. A multisig fallback section of a script will thus never have the actual public keys exposed for most payments. As a quick example.
As a designer, the p2sh design is not giving me happy thoughts. It is hacky in things like how a full node realizes something IS a p2sh payment, it literally needs a outsider detecting it. Which violates the virtual-machine concepts of script…
A bip114 tried to do mast, it is naturally based on segwit and soft forks, and it was rejected anyway. I think it is pretty easy to do better.
We can have a single opcode; “OP_MAST_VERIFY”.
- push-sha256 (the merkle-root)
- any pushes needed by the subscript.
The opcode takes the 3 items from stack, verifies that the merkle-proof matches the root.
The opcode then executes the script ‘in-place’.
Maybe smart ways stand out to avoid it recusing (it shouldn’t!), but if all else fails that can just become a boolean in the VM. The above way consumes the stack before it is executed so recursing won’t be possible to exploit for looping anyway.
the usage of p2sh is single digit percentage on chain today, as we grow our capabilities and our research into useful stuff the actual usage of smart contracts will likely go up.
I’m hoping we can provide a better way to do that than p2sh, something that most people will prefer and thus that the amount of p2sh scripts goes down. Partly from an estetics point of view, partly because we may at one point have a rule where transaction-version 10 can’t create p2sh anymore and you need v10 to do fun stuff. You know something that makes sense because p2sh definitey is an ugly hack.
Not a “proposal”, more a request for comments. Who wants to add to this wild idea?