On Tue, Jan 23, 2018 at 1:44 AM, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On Tue, Jan 23, 2018 at 12:30:06AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> 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.

> Now we tweak C to produce P which is the key we'll publish: P = C + H(C||S)G.
> (This is the attack hardened pay-to-contract construction described in [2])
> Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P].

Is this really intended as paying directly to a pubkey, instead of a
pubkey hash?

If so, isn't that a step backwards with regard to resistance to quantum
attacks against ECC?

Paying direct to pubkey doesn't seem quite enough to make pay-to-taproot
cheaper than p2wpkh: the extra 12 bytes in the scriptPubKey would need
you to reduce the witness by 48 bytes to maintain the weight, but I think
you'd only be saving 33 bytes by not having to reveal the pubkey, and
another 6-7 bytes by having a tighter signature encoding than DER. Still,
that's pretty close with a difference of only a couple of vbytes per
input by my count.

I've been thinking about your comment, and I think your concern can be addressed. Taproot would almost certainly be deployed in conjunction with cross-input signature aggregation. Because aggregation doesn't work with ECDSA, only those signatures using Taproot and other Schnorr signatures would be available for aggregation. Just having the ability to support cross-input signature aggregation may be motivation enough for ordinary pub-key users to switch to Taproot. However, there is more.

Cross-input signature aggregation probably requires a new field to be added to the P2P transaction structure to hold the aggregated signature, since there isn't really a good place to put it in the existing structure (there are games you can play to make it fit, but I think it is worthwhile). The obvious way add block commitments to a new tx field is via the witness reserved value mechanism present in BIP 141. At this point I think there will be some leeway to adjust the discount on the weight of this new aggregated signature tx field so that even a single input taproot using the aggregated signature system (here an aggregation of 1 signature) ends up no more expensive than a single input segwit P2WPKH.