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 7E13AC4E for ; Tue, 17 Sep 2019 04:10:01 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 04F6E81A for ; Tue, 17 Sep 2019 04:09:59 +0000 (UTC) Date: Tue, 17 Sep 2019 04:09:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1568693397; bh=aC5Gx8VvBgQIJ8GCHERtZWoo4OMMAWCPkihHdwcMKKo=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=XufQn31D1FIpparwvfXaJorNlCqQMcUo8xhIuq5bzPwhjuy1PwitELoH87rGKvopx c0xB5F7va7gENqpuqY3Lpi5VotYtiq/XPvwbXiqID1O1d4Qld/8k2+pkkSsyNdZlXE hdi/tC7Jiq3dNIiVn55ec0HlhhqU5PYdC8W7Ugx8= To: Greg Sanders , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: John Newbery Subject: Re: [bitcoin-dev] Taproot proposal 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, 17 Sep 2019 04:10:01 -0000 Good morning Greg and John, I am not as sanguine here; SegWit activation was already delayed relative t= o commonly-broadcast expectations, yet many services *still* do not support= sending to SegWit v0 addresses even now. On the other hand, the major benefit of taproot is the better privacy and h= omogeneity afforded by Taproot, and supporting both P2SH-wrapped and non-wr= apped SegWit v1 addresses simply increases the number of places that a user= may be characterized and potentially identified. Thus while I disagree with your reasoning, I do agree with your conclusion:= no P2SH-wrapped SegWit v1. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Tuesday, September 17, 2019 12:18 AM, Greg Sanders via bitcoin-dev wrote: > > I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for = segwit > v0 for compatibility reasons. Most wallets/exchanges/services now support= sending > to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) a= nd that > will be even more true if Schnorr/Taproot=C2=A0activate in 12+ months tim= e. > > Apologies for necroing an ancient thread, but I'm echoing my agreement wi= th John here. > We still have plenty of time to have ecosystem upgrade by the time taproo= t is likely to activate. > > On Wed, May 22, 2019 at 10:30 AM John Newbery via bitcoin-dev wrote: > > > Hi, > > > > > A Taproot output is a SegWit output [...] =C2=A0with > > > version number 1, and a 33-byte witness program whose first byte is 0= or 1. > > > > Given a secret key k and public key P=3D(x,y), a signer with the knowle= dge of k > > can sign for -P=3D(x,p-y) since -k is the secret key for that point. En= coding the > > y value of the public key therefore adds no security. As an alternative= to > > providing the y value of the taproot output key Q when constructing the= taproot > > output, the signer can provide it when signing. We can also restrict th= e y value > > of the internal key P to be even (or high, or a quadratic residue). Tha= t gives > > us 4 options for how to set the y signs for P and Q. > > > > 1. Q sign is explictly set in the witness program, P sign is explicitly= set in the control block > > =C2=A0 =C2=A0 =3D> witness program is 33 bytes, 32 possible leaf versio= ns (one for each pair of 0xc0..0xff) > > 2. Q sign is explictly set in the witness program, P sign is implicitly= even > > =C2=A0 =C2=A0 =3D> witness program is 33 bytes, 64 possible leaf versio= ns (one for each 0xc0..0xff) > > 3. Q sign is explictly set in the control block, P sign is explicitly s= et in the control block > > =C2=A0 =C2=A0 =3D> witness program is 32 bytes, 16 possible leaf versio= ns (one for each 4-tuple of 0xc0..0xff) > > 4. Q sign is explictly set in the control block, P sign is implicitly e= ven > > =C2=A0 =C2=A0 =3D> witness program is 32 bytes, 32 possible leaf versio= ns (one for pair of 0xc0..0xff) > > > > The current proposal uses (1). Using (3) or (4) would reduce the size o= f a > > taproot output by one byte to be the same size as a P2WSH output. That = means > > that it's not more expensive for senders compared to sending to P2WSH. > > =C2=A0 > > (Credit to James Chiang for suggesting omitting the y sign from the pub= lic key and > > to sipa for pointing out the 4 options above) > > > > > (native or P2SH-nested, see BIP141) > > > > I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for = segwit > > v0 for compatibility reasons. Most wallets/exchanges/services now suppo= rt sending > > to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption)= and that > > will be even more true if Schnorr/Taproot activate in 12+ months time. > > > > On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev wrote: > > > > > Hello everyone, > > > > > > Here are two BIP drafts that specify a proposal for a Taproot > > > softfork. A number of ideas are included: > > > > > > * Taproot to make all outputs and cooperative spends indistinguishabl= e > > > from eachother. > > > * Merkle branches to hide the unexecuted branches in scripts. > > > * Schnorr signatures enable wallet software to use key > > > aggregation/thresholds within one input. > > > * Improvements to the signature hashing algorithm (including signing > > > all input amounts). > > > * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support > > > batch validation. > > > * Tagged hashing for domain separation (avoiding issues like > > > CVE-2012-2459 in Merkle trees). > > > * Extensibility through leaf versions, OP_SUCCESS opcodes, and > > > upgradable pubkey types. > > > > > > The BIP drafts can be found here: > > > * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki > > > specifies the transaction input spending rules. > > > * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawi= ki > > > specifies the changes to Script inside such spends. > > > * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki > > > is the Schnorr signature proposal that was discussed earlier on this > > > list (See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201= 8-July/016203.html) > > > > > > An initial reference implementation of the consensus changes, plus > > > preliminary construction/signing tests in the Python framework can be > > > found on https://github.com/sipa/bitcoin/commits/taproot. All > > > together, excluding the Schnorr signature module in libsecp256k1, the > > > consensus changes are around 520 LoC. > > > > > > While many other ideas exist, not everything is incorporated. This > > > includes several ideas that can be implemented separately without los= s > > > of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT= , > > > which we're working on as an independent proposal. > > > > > > The document explains basic wallet operations, such as constructing > > > outputs and signing. However, a wide variety of more complex > > > constructions exist. Standardizing these is useful, but out of scope > > > for now. It is likely also desirable to define extensions to PSBT > > > (BIP174) for interacting with Taproot. That too is not included here. > > > > > > Cheers, > > > > > > -- > > > Pieter > > > _______________________________________________ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev