The issue with that approach without support for the privacy-encouraging wrapper proposed by Greg here is that it encourages adoption halfway and destroys a lot of the value of the apparent-script monoculture for privacy preservation. Greg's proposal here doesn't change the format of any specific MAST implementation, but instead adds the privacy wrapper that I always felt was missing in existing proposals, without any real additional overhead in many use-cases!
Indeed, permissionless innovation is important, but the huge advantage of providing the privacy wrapper by default here is absolutely massive to the ecosystem and should not be handwaved away for vague possibly-advantages.
Post by Mark Friedenbach via bitcoin-dev
I had the opposite response in private, which I will share here. As
recently as Jan 9th feedback on BIP 117 was shared on this list by
Pieter Wuille and others suggesting we adopt native MAST template
instead of the user programmable combination of BIPs 116 and 117. Part
I havent the hubris to suggest that we know exactly what a templated
MAST *should* look like. It's not used in production anywhere. Even if
we did have the foresight, the tail-call semantics allow for other
constructions besides MAST and for the sake of the future we should
allow such permission-less innovation. The proper sequence of events
should be to enable features in a generic way, and then to create
specialized templates to save space for common constructions. Not the
other way around. 
I take this advance as further evidence in favor of this view. As
recently as 24 hours ago if you had asked what a native-MAST template
would have looked like, the answer would have been something like
Johnson Lauâs BIP 114, with some quibbling over details. Taproot is a
clearly superior approach. But is it optimal? I donât think we can
claim that now. Optimality of these constructs isnât something easily
proven, with the nearest substitute being unchanging consensus over
extended periods of time.
Every time we add an output type specialization, we introduce a new
codepath in the core of the script consensus that must be maintained
forever. Take P2SH: from this point forward there is no reason to use
it in new applications, ever. But it must be forever supported. In an
alternate universe we could have deployed a native MAST proposal, like
BIP 114, only to have Taproot-like schemes discovered after activation.
That would have been a sucky outcome. It is still the case that we
could go for Taproot right now, and then in six months or a yearâs time
we find an important tweak or a different approach entirely that is
even better, but the activation process had already started. That would
be a sucky outcome we havenât avoided yet.
This is not an argument against template specialization for common code
paths, especially those which increase fungibility of coins. I do think
we should have a native MAST template eventually, using Taproot or
something better. However if I may be allowed I will make an educated
guess about the origin of Taproot: I think itâs no coincidence that
Greg had this insight and/or wrote it up simultaneous with a push by
myself and others for getting MAST features into bitcoin via BIPs 98,
116, and 117, or 114. Cryptographers tend to only think up solutions to
problems that are on their minds. And the problems on most peopleâs
minds are primarily those that are deployable today, or otherwise
BIPS 116 and 117 each provide a reusable component that together
happens to enable a generic form of MAST. Even without the workarounds
required to avoid CLEANSTACK violations, the resulting MAST template is
larger than what is possible with specialization. However letâs not
forget that (1) they also enable other applications like honeypots, key
trees, and script delegation; and relevant to this conversation (2)
they get the MAST feature available for use in production by the wider
community. I donât think Iâd personally be willing to bet that we found
the optimal MAST structure in Gregâs Taproot until we have people doing
interesting production work like multisig wallets, lightning protocol,
and the next set of consensus features start putting it into production
and exploring edge cases. We may find ways Taproot can be tweaked to
enable other applications (like encoding a hash preimage as well) or
simplify obscure corner cases.
I feel quite strongly that the correct approach is to add support for
generic features to accomplish the underlying goal in a user
programmable way, and THEN after activation and some usage consider
ways in which common use cases can be made more efficient through
output specialization. To take a more obvious example, lightning
protocol is still an active area or research and I think it is
abundantly clear that we donât know yet what the globally optimal
layer-2 caching protocol will be, even if we have educated guesses as
to its broad structure. A proposal right now to standardize a more
compact lightning script type would be rightly rejected. It is less
obvious but just as true that the same should hold for MAST.
I have argued these points before in favor of permission less
innovation first, then application specialization later, in  and at
the end of the rather long email . I hope you can take the time to
read those if you still feel we should take a specialized template
approach instead of the user programmable BIPSs 116 and 117.
On Jan 22, 2018, at 6:51 PM, Matt Corallo via bitcoin-dev
I'd be hesitant to deploy a MAST proposal without this clever
application of pay-to-contract-hash now! Looks like the overhead over a
more-naive MAST construction is rather trivial, too!
On January 23, 2018 12:30:06 AM UTC, Gregory Maxwell via bitcoin-dev
Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two
areas: efficiency and privacy. Efficiency because unexecuted forks of
a script can avoid ever hitting the chain, and privacy because hiding
unexecuted code leaves scripts indistinguishable to the extent that
their only differences are in the unexecuted parts.
As Mark Friedenbach and others have pointed out before it is almost
always the case that interesting scripts have a logical top level
branch which allows satisfaction of the contract with nothing other
than a signature by all parties. Other branches would only be used
where some participant is failing to cooperate. More strongly stated,
I believe that _any_ contract with a fixed finite participant set
upfront can be and should be represented as an OR between an N-of-N
and whatever more complex contract you might want to represent.
One point that comes up while talking about merkelized scripts is can
we go about making fancier contract use cases as indistinguishable as
possible from the most common and boring payments. Otherwise, if the
anonymity set of fancy usage is only other fancy usage it may not be
very large in practice. One suggestion has been that ordinary
checksig-only scripts should include a dummy branch for the rest of
the tree (e.g. a random value hash), making it look like there are
potentially alternative rules when there aren't really. The negative
side of this is an additional 32-byte overhead for the overwhelmingly
common case which doesn't need it. I think the privacy gains are
worth doing such a thing, but different people reason differently
about these trade-offs.
It turns out, however, that there is no need to make a trade-off.
special case of a top level "threshold-signature OR
arbitrary-conditions" can be made indistinguishable from a normal
one-party signature, with no overhead at all, with a special
delegating CHECKSIG which I call Taproot.
Let's say we want to create a coin that can be redeemed by either
Alice && Bob or by CSV-timelock && Bob.
Alice has public A, Bob has pubkey B.
We compute the 2-of-2 aggregate key C = A + B. (Simplified; to
protect against rogue key attacks you may want to use the MuSig key
aggregation function )
We form our timelock script S = "<timeout> OP_CSV OP_DROP B
Now we tweak C to produce P which is the key we'll publish: P = C +
(This is the attack hardened pay-to-contract construction described
Then we pay to a scriptPubKey of [Taproot supporting version] [EC
Now Alice and Bob-- assuming they are both online and agree about the
resolution of their contract-- can jointly form a 2 of 2 signature
P, and spend as if it were a payment to a single party (one of them
just needs to add H(C||S) to their private key).
Alternatively, the Taproot consensus rules would allow this script to
be satisfied by someone who provides the network with C (the original
combined pubkey), S, and does whatever S requires-- e.g. passes the
CSV check and provides Bob's signature. With this information the
network can verify that C + H(C||S) == P.
So in the all-sign case there is zero overhead; and no one can tell
that the contract alternative exists. In the alternative redemption
branch the only overhead is revealing the original combined pubkey
and, of course, the existence of the contract is made public.
This composes just fine with whatever other merkelized script system
we might care to use, as the S can be whatever kind of data we want,
including the root of some tree.
My example shows 2-of-2 but it works the same for any number of
participants (and with setup interaction any threshold of
participants, so long as you don't mind an inability to tell which
members signed off).
The verification computational complexity of signature path is
obviously the same as any other plain signature (since its
indistinguishable). Verification of the branch redemption requires a
hash and a multiplication with a constant point which is strictly
efficient than a signature verification and could be efficiently
into batch signature validation.
The nearest competitor to this idea that I can come up with would
supporting a simple delegation where the output can be spent by the
named key, or a spending transaction could provide a script along
a signature of that script by the named key, delegating control to
signed script. Before paying into that escrow Alice/Bob would
construct this signature. This idea is equally efficient in the
case, but larger and slower to verify in the alternative spend case.
Setting up the signature requires additional interaction between
participants and the resulting signature must be durably stored and
couldn't just be recomputed using single-party information.
I believe this construction will allow the largest possible anonymity
set for fixed party smart contracts by making them look like the
simplest possible payments. It accomplishes this without any overhead
in the common case, invoking any sketchy or impractical techniques,
requiring extra rounds of interaction between contract participants,
and without requiring the durable storage of other data.
<https://blockstream.com/sidechains.pdf> Appendix A
bitcoin-dev mailing list
bitcoin-dev mailing list