MIME-Version: 1.0
In-Reply-To: <20180123064419.GA1296@erisian.com.au>
References: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
	<20180123064419.GA1296@erisian.com.au>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sat, 27 Jan 2018 12:07:25 -0500
Message-ID: <CAMZUoKmfcmfgErhvAZUQgi8R7bzYCMotT7MMpqQrePej09NBmw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1144d5ea44a05c0563c50d82"
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
Precedence: list

--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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Jan 23, 2018 at 1:44 AM, Anthony Towns via bitcoin-dev <span di=
r=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">=
On Tue, Jan 23, 2018 at 12:30:06AM +0000, Gregory Maxwell via bitcoin-dev w=
rote:<br>
&gt; One point that comes up while talking about merkelized scripts is can<=
br>
&gt; we go about making fancier contract use cases as indistinguishable as<=
br>
&gt; possible from the most common and boring payments.<br>
<br>
</span><span class=3D"gmail-">&gt; Now we tweak C to produce P which is the=
 key we&#39;ll publish: P =3D C + H(C||S)G.<br>
&gt; (This is the attack hardened pay-to-contract construction described in=
 [2])<br>
&gt; Then we pay to a scriptPubKey of [Taproot supporting version] [EC poin=
t P].<br>
<br>
</span>Is this really intended as paying directly to a pubkey, instead of a=
<br>
pubkey hash?<br>
<br>
If so, isn&#39;t that a step backwards with regard to resistance to quantum=
<br>
attacks against ECC?<br>
<br>
Paying direct to pubkey doesn&#39;t seem quite enough to make pay-to-taproo=
t<br>
cheaper than p2wpkh: the extra 12 bytes in the scriptPubKey would need<br>
you to reduce the witness by 48 bytes to maintain the weight, but I think<b=
r>
you&#39;d only be saving 33 bytes by not having to reveal the pubkey, and<b=
r>
another 6-7 bytes by having a tighter signature encoding than DER. Still,<b=
r>
that&#39;s pretty close with a difference of only a couple of vbytes per<br=
>
input by my count.<br></blockquote><div><br></div><div>I&#39;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&#39;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.</div><div><br></div>=
<div>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&#39;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.<br></div></div><=
/div></div>

--001a1144d5ea44a05c0563c50d82--