summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKarl-Johan Alm <karljohan-alm@garage.co.jp>2019-08-11 15:08:48 +0900
committerbitcoindev <bitcoindev@gnusha.org>2019-08-11 06:09:03 +0000
commit09b596cbe793a9f1e83574783516bd32c5b07915 (patch)
tree9b4ca4c0b8c8552dca9afe74edb31c785d8fd0da
parent4d0732c54c0174dbb23341eb2493ae52bc2ee996 (diff)
downloadpi-bitcoindev-09b596cbe793a9f1e83574783516bd32c5b07915.tar.gz
pi-bitcoindev-09b596cbe793a9f1e83574783516bd32c5b07915.zip
Re: [bitcoin-dev] 32-byte public keys in Schnorr and Taproot
-rw-r--r--ca/96c62a848940fb901c3895949c5a3accc7cbb9161
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
+