diff options
author | Karl-Johan Alm <karljohan-alm@garage.co.jp> | 2019-08-11 15:08:48 +0900 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2019-08-11 06:09:03 +0000 |
commit | 09b596cbe793a9f1e83574783516bd32c5b07915 (patch) | |
tree | 9b4ca4c0b8c8552dca9afe74edb31c785d8fd0da | |
parent | 4d0732c54c0174dbb23341eb2493ae52bc2ee996 (diff) | |
download | pi-bitcoindev-09b596cbe793a9f1e83574783516bd32c5b07915.tar.gz pi-bitcoindev-09b596cbe793a9f1e83574783516bd32c5b07915.zip |
Re: [bitcoin-dev] 32-byte public keys in Schnorr and Taproot
-rw-r--r-- | ca/96c62a848940fb901c3895949c5a3accc7cbb9 | 161 |
1 files changed, 161 insertions, 0 deletions
diff --git a/ca/96c62a848940fb901c3895949c5a3accc7cbb9 b/ca/96c62a848940fb901c3895949c5a3accc7cbb9 new file mode 100644 index 000000000..2993d2797 --- /dev/null +++ b/ca/96c62a848940fb901c3895949c5a3accc7cbb9 @@ -0,0 +1,161 @@ +Return-Path: <karljohan-alm@garage.co.jp> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id CB77486D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 11 Aug 2019 15:09:00 +0900 (JST) +X-Received: by mail-qt1-f197.google.com with SMTP id f28so93447470qtg.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CAPg+sBhDQ5yS-BemRWqSxV7TJaWNFs7d-zD6p5HtquFwUjDdsg@mail.gmail.com> +In-Reply-To: <CAPg+sBhDQ5yS-BemRWqSxV7TJaWNFs7d-zD6p5HtquFwUjDdsg@mail.gmail.com> +From: Karl-Johan Alm <karljohan-alm@garage.co.jp> +Date: Sun, 11 Aug 2019 15:08:48 +0900 +Message-ID: <CALJw2w5=5vmO1jGyWU5XGorKX_UvyD2G+94SuBha1ZrX_ByK1A@mail.gmail.com> +To: Pieter Wuille <pieter.wuille@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 +<bitcoin-dev@lists.linuxfoundation.org> 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 + |