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 5FFCAE92 for ; Tue, 23 Jan 2018 22:22:42 +0000 (UTC) X-Greylist: from auto-whitelisted 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 724BFCA for ; Tue, 23 Jan 2018 22:22:41 +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 1ee6xg-000689-7J; Wed, 24 Jan 2018 08:22:39 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Wed, 24 Jan 2018 08:22:29 +1000 Date: Wed, 24 Jan 2018 08:22:29 +1000 From: Anthony Towns To: Gregory Maxwell Message-ID: <20180123222229.GA3801@erisian.com.au> References: <20180123064419.GA1296@erisian.com.au> 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 Cc: Bitcoin Protocol Discussion 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 22:22:42 -0000 On Tue, Jan 23, 2018 at 01:15:38PM +0000, Gregory Maxwell wrote: > On Tue, Jan 23, 2018 at 6:44 AM, Anthony Towns wrote: > > 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? > Considering the considerable level of address reuse -- I recall prior > stats that a majority of circulating funds are on addresses that had > previously been used, on top of the general race limitations-- I am > now dubious to the idea that hashing provides any kind of meaningful > quantum resistance and somewhat regret introducing that meme to the > space in the first place. If we considered quantum resistance a > meaningful concern we should address that specifically. --- so I > don't think that should be a factor that drives a decision here. Hmm, at least people can choose not to reuse addresses currently -- if everyone were using taproot and that didn't involve hashing the key, there would be no way for individuals to hedge against quantum attacks in case they're ever feasible, at least that I can see (well, without moving their funds out of bitcoin anyway)? Even "X + H(X|script)g" with X being a random point would end up attackable, since that would almost always end up corresponding with a valid public key that a successful attack could then find a private key for. (It seems like using the point at infinity wouldn't work because P = 0+H(0||S)g = H(0||S)g, so as soon as you tried to spend it via S, someone watching the mempool would know H(0||S), which is the secret key for P, and be able to spend it via the pubkey path -- no quantum crypto needed. Or am I missing something?) Also, if the people currently reusing addresses tend to cycle the funds through fairly quickly anyway, they might be able to simply stop doing that when quantum attacks start approaching feasibility. If funds are being held in reused addresses over the long term, that would be more of a problem though... > When collision resistance is needed (as I think it clearly is for > taproot) you don't get a space savings in the txout from hashing, so > there is an argument to use the public key directly at least... but > it's worth considering. Direct SPK use is also adventitious for being > able to efficiently ZKP over the UTXO set, e.g. for private solvency > proofs, but it isn't absolutely mandatory for that (one can hash > inside the proof, but it's slower). Yeah, that was one of the assumptions for http://www.jbonneau.com/doc/DBBCB15-CCS-provisions.pdf iirc. (Also, pretty sure you mean "advantageous", but at least I learnt a new word today) Cheers, aj