1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
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
|
