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.