Date: Tue, 23 Jan 2018 16:44:19 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Gregory Maxwell <greg@xiph.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20180123064419.GA1296@erisian.com.au>
References: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
Precedence: list

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.

If it were "pay-to-taproot-hash", then presuming taproot hashes were 256
bit, then p2wpkh would be a full 12 vbytes cheaper due to the shorter
hash. That might make it hard to maximise the anonymity set. I suppose
a small penalty/discount could be added to align the economic incentives
though.

I wonder how this interacts with segwit versioning. I think you'd want
to have taproot be versioned overall so that you could cope with moving
to a new signing method (different curve, or something non-ECC based)
eventually, and segwit versioning will handle that already; but maybe
it would also be a good idea to also have "S" include a version, that
could be bumped to add new features to script, but left hidden within
the hash so that the fact you're using new (or old) features is only
revealed when it has to be.

Those nits aside, this seems great.

Cheers,
aj