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 6F7E9F31 for ; Sat, 27 Jan 2018 17:07:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 942A7319 for ; Sat, 27 Jan 2018 17:07:46 +0000 (UTC) Received: by mail-it0-f47.google.com with SMTP id k131so3831512ith.4 for ; Sat, 27 Jan 2018 09:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream.io; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+bbNBuBCkzeLAnadFLZMoCVbD7CU+DxxSgA5IlCUKGM=; b=SqULcC4B4Da6tEHLJNHDRM9RLBYAnY5EXsFRNJC1ZEDHh8KR5t5FSlH/ndtEsADlI0 JOYXDRLTNs9UeyWqgx7tmzbhVD850DjkTiO7HovBD8xXma6krjpqiUQt4BCAUTHoFIxZ m02MWuCvdml/nEY4g5BIY77SCeGSPqO/tT6js= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+bbNBuBCkzeLAnadFLZMoCVbD7CU+DxxSgA5IlCUKGM=; b=Uw8f/CbxCqplxZiN8WPzS5ybHrdS0wsSJn3Qa/65HkcAckgk+yQtUhvdx3Fs9FJToI k0pYF78E2xMjo+1QcJh1lX7eGK9vqZYCBspmc2H0rDww1t2VQEOsAr2QI7S39i4oLanL rLvUCJMXAP4YGPCehgi56FDRQ8WyTV2ggoK1ErN7dyD5hznWqA/LDztoDGPTR6N3WkVY 5oNuqhJXh08vJMpQt+70DyUKSVfL1mP+JH6f8jQqW8KwP+8TJqUMqi3u+SixPiyctjLU 3Qz7LdSJkhRzEK5/tQMFrzppbm1VFKdfdtciaRVWRkm+D6CCrracM0EHhfBiS1y78zF6 o/sg== X-Gm-Message-State: AKwxytdltitRam3b9IJrvB+t7iRTq680Lo7Z1AW2a+UlCKMNGJuwScQj tKUCpa6uhVuaK8qwrNWGjytx5FEqdWIgiwRXLMUOpuyYc4g= X-Google-Smtp-Source: AH8x225Zs6GgWn6OJ++AHNnR/Fgmaepcfk79Vo/ewcdD4bGXHr9Ld+ypfgFbeYxCmWmjuRP3bUM/oGvl5Ixh7tKgxNQ= X-Received: by 10.36.86.20 with SMTP id o20mr21420978itb.53.1517072865854; Sat, 27 Jan 2018 09:07:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.120.10 with HTTP; Sat, 27 Jan 2018 09:07:25 -0800 (PST) In-Reply-To: <20180123064419.GA1296@erisian.com.au> References: <20180123064419.GA1296@erisian.com.au> From: "Russell O'Connor" Date: Sat, 27 Jan 2018 12:07:25 -0500 Message-ID: To: Anthony Towns , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a1144d5ea44a05c0563c50d82" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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: Sat, 27 Jan 2018 17:07:47 -0000 --001a1144d5ea44a05c0563c50d82 Content-Type: text/plain; charset="UTF-8" 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. --001a1144d5ea44a05c0563c50d82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 w= rote:
> One point that comes up while talking about merkelized scripts is can<= br> > we go about making fancier contract use cases as indistinguishable as<= br> > possible from the most common and boring payments.

> Now we tweak C to produce P which is the= key we'll publish: P =3D 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 poin= t 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-taproo= t
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 thinki= ng about your comment, and I think your concern can be addressed.=C2=A0 Tap= root would almost certainly be deployed in conjunction with cross-input sig= nature aggregation.=C2=A0 Because aggregation doesn't work with ECDSA, = only those signatures using Taproot and other Schnorr signatures would be a= vailable for aggregation.=C2=A0 Just having the ability to support cross-in= put signature aggregation may be motivation enough for ordinary pub-key use= rs to switch to Taproot.=C2=A0 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, si= nce 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= ).=C2=A0 The obvious way add block commitments to a new tx field is via the= witness reserved value mechanism present in BIP 141.=C2=A0 At this point I= think there will be some leeway to adjust the discount on the weight of th= is new aggregated signature tx field so that even a single input taproot us= ing the aggregated signature system (here an aggregation of 1 signature) en= ds up no more expensive than a single input segwit P2WPKH.
<= /div>
--001a1144d5ea44a05c0563c50d82--