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.
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
