From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7122FEEA for ; Tue, 23 Jan 2018 07:26:35 +0000 (UTC) X-Greylist: delayed 00:42:05 by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E3A1CEC for ; Tue, 23 Jan 2018 07:26:34 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1edsJm-0004Cg-1Y; Tue, 23 Jan 2018 16:44:27 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Tue, 23 Jan 2018 16:44:19 +1000 Date: Tue, 23 Jan 2018 16:44:19 +1000 From: Anthony Towns To: Gregory Maxwell , Bitcoin Protocol Discussion Message-ID: <20180123064419.GA1296@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 07:26:35 -0000 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