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 CB77486D for ; Sun, 11 Aug 2019 06:09:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mo.garage.hdemail.jp (mo.garage.hdemail.jp [46.51.242.127]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C51506E0 for ; Sun, 11 Aug 2019 06:09:02 +0000 (UTC) Received: from ip-10-217-1-36.ap-northeast-1.compute.internal (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-mf-postfix) with SMTP id 65D2F14C10B for ; Sun, 11 Aug 2019 15:09:01 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from unknown (HELO mo.garage.hdemail.jp) (127.0.0.1) by 0 with SMTP; 11 Aug 2019 15:09:01 +0900 X-Received: from mo.garage.hdemail.jp (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-ma-postfix) with ESMTP id 4D80F4C09B for ; Sun, 11 Aug 2019 15:09:01 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) Received: from gw30.oz.hdemail.jp (ip-10-127-9-254.ap-northeast-1.compute.internal [10.127.9.254]) by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 3BEE314C10B for ; Sun, 11 Aug 2019 15:09:01 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from mail-qt1-f197.google.com (lb05.oz.hdemail.jp [54.238.57.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw30.oz.hdemail.jp (Postfix) with ESMTP id CAD9B148C11C for ; Sun, 11 Aug 2019 15:09:00 +0900 (JST) X-Received: by mail-qt1-f197.google.com with SMTP id f28so93447470qtg.2 for ; Sat, 10 Aug 2019 23:09:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dn7rYlWskQF9CaxDxq+axrS6EXecM1VPq716gu3pWg4=; b=jLC0w8HsLofKhCgOBNbgvXwqYqBqDL6xyZaUHsRX1U8/OiVbRcVEn2geBA2bnUX00r nKywsYE03t8BHJzsuCvVSkU/aIpOieIo541C8daWD4u0jY73YAyf0sWaxjWLOniblO+J k0fdYnnhwoRQKKciAm5o8oZVH0s6Fkuc28xQUWJTFmffeiP8f5/PgNH2fCTtKt4ZxTXS OjpW7NGT/bbpd93Fai64sAyMPVxUG5Eap5lZF2F2kgRMZ/K3d8Z/RV5FyuM4biZPxn/7 KplKoy7dJY/H6wHwXf4nD3eCpjCSt5YqlX2CfeGWD0LH3yxcSG+axHR6bSGUR/Z/9sn/ QC4g== X-Gm-Message-State: APjAAAVAGn+UMjYvw1FTXbKo8NlKMgh8znd7tfLbTnVV6+jWA9gZzlZO aO4IuOj4IgoQuVHkjr/TJTEMTV5603haAvQENDKRzp45gc6+5SRbCh5qd5AA//rdS6KgBYx0mEB fg0x87oxskbwXZNcJGFPSur/+xIPdQb1Q7dZNdOH9o/lvy78SdKBBA99YW+1l3KO7BRj9FYvcB2 wvEy7QGwvwqHTJmrE25WRimc2RNP2YlyJVh3FgathFIE0ZjrjutJyxNt1QB9DXcD6LMBlE+xN1J Kfxx77iMPqxXlPYVFmgKpMoJkG8d+eRnPcbACO/55ZBUCMu8hf35Ozdc5FQhzs+uUT3+KuSxGe4 REGX7ChG/2Fl1s8dRfBays9KlBs= X-Received: by 2002:a37:a492:: with SMTP id n140mr23375621qke.137.1565503739389; Sat, 10 Aug 2019 23:08:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqwczr8eX+3tuMfaVGoi2mAhm6ulWSczG6GypkLOCUVNqc0yEuQykU4GRt7R5uiAvNbMKYe0wzaNp+KvVXgYW78= X-Received: by 2002:a37:a492:: with SMTP id n140mr23375605qke.137.1565503739092; Sat, 10 Aug 2019 23:08:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Karl-Johan Alm Date: Sun, 11 Aug 2019 15:08:48 +0900 Message-ID: To: Pieter Wuille , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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] 32-byte public keys in Schnorr and Taproot 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: Sun, 11 Aug 2019 06:09:03 -0000 Hello, It makes no sense to me to not switch to 32-byte keys. There are literally no (or very mild) disadvantages to this, from what it appears like. I don't think refraining from updating a proposal just because it's been out there for awhile is a valid reason, personally. On Sat, Aug 10, 2019 at 3:17 AM Pieter Wuille via bitcoin-dev wrote: > > Hello all, > > It has been suggested [1] to drop the Y oddness bit in the witness > program for Taproot outputs. This seems like a worthwhile change, as: > * The bit doesn't actually contribute to security. > * It avoids Taproot outputs from being more expensive to create than v0 P2WSH. > * It doesn't preclude future changes that would still need the > additional byte anyway. > > In exploring that option, Jonas Nick found that it seems cleanest [2] > to actually introduce a type of 32-byte public keys (which implicitly > have an even Y coordinate) in bip-schnorr, with associated signing and > verification logic that are distinct from the 33-byte variant. > > This makes me wonder if we need 33-byte public keys at all. > > So I'd like to hear opinions about modifying bip-schnorr to only > define 32-byte public keys. The implications of that would be: > * bip-schnorr public keys wouldn't be exactly the same as ECDSA public > keys, however all derivation logic would still apply (BIP32, > mnemonics, xpubs, ... would still exist and be compatible - just the > first pubkey byte would be dropped at the end). > * The Q point in bip-taproot (the one going in the scriptPubKey) would > just follow the 32-byte pubkey encoding, rather than needing a 33rd > byte. > * The P point in bip-taproot (the internal key revealed during script > path) would become just a 32-byte public key (and we can drop the one > bit in the control block to transmit the oddness of the Y coordinate > of P). > * In order to permit batch verification of the P to Q tweaking for > script-path spending, another control block bit is now needed, namely > one that indicates whether a negation was needed to make P+H(P||m)*G's > Y coordinate even. > * All public keys inside bip-tapscript would also become 32-bytes. If > desired, the "upgradable public key" construction in bip-tapscript can > be kept, by triggering based on the length of public keys (rather than > based on their first byte). > > One question is whether it's worth such a change to bip-schnorr at > this point. We've purposefully never progressed it past draft since > publishing [3], but it has been a while. If necessary, it's possible > to keep verification compatible by still hashing the implied "even" > byte inside the scheme (which commits to the pubkey), but if we're > going to change things, it's perhaps best to do it as cleanly as > possible and also drop that byte. > > Opinions? > > [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016943.html > [2] https://github.com/sipa/bips/pull/52 > [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html > > Cheers, > > -- > Pieter > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev