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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 528129D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Aug 2019 18:16:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com
[209.85.210.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D7832829
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Aug 2019 18:16:41 +0000 (UTC)
Received: by mail-ot1-f43.google.com with SMTP id f17so647169otq.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 09 Aug 2019 11:16:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=Qh99pT6+mqkKrAInGdHtU9PZ/v33DLuekNch+zg/hqE=;
b=IUaWbrKwfcLhrjqzzk4n8SuZ0vIQkUDEeQM68UzWQ31yphb2Z1tMoIrEw3opQ2LoUn
D0E9i82PfF5eMBoxKAlFFYlWAZ0I5wb33/fBGVCa44Vc1VVpKXs9+EcnKWX4M94c8h3l
z6yFjYqG01KswE02bHLfX96nLhKzCS1rYy91Br3oiEdgkjfYAX9oDpwN9QuOcOssKWTy
S2X7blycVdJw5BS3/0tKx4fRUAX5U6BIYASUFnfrPcXJW3qFlmzGE7fZIqfk+0N2EJTH
W9jhu8BrC9HbTwtTCWw4XLsYd2dPoSMw4f43fW5cKal5buDaEE6f1EYhoWcJPtxwv9d2
h2ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=Qh99pT6+mqkKrAInGdHtU9PZ/v33DLuekNch+zg/hqE=;
b=gZstqjqQ2X0C9R3J3tl01UkFfrDXlHWhKSfIvndAJB4+92giFN6prEBjsTDYTe+s9+
e2sEsjFr8wQh2wrCOOf+ZmgXBWYPVQzx43qkHp9LCSYE2F8MkRGc8GK3pZ/+1P3YWRfO
VqKVXvADbv4nnAs0Zu09/72JjIwmMICnYonyb8GrqeXLW+XiGJHxv0dSP75OpQh+6/E2
4mYu+DVmD3A4oYStKUzpI0tUglU6A3vKYAJhjmIjQtZfctxWP/qMf/OzTXUTcV5UWuKJ
oJLwR7ZN4CNRr5yASyKCOLlxA1nMMSOsEXr9aYopth+fo/0tSFN/ZIhU3A/s8tLfW3/v
kWbQ==
X-Gm-Message-State: APjAAAUvUzdXgjDNSsev/fndn4Mv9qVRWLosWcjfXhy52pRjFAOVvG2O
io1Qd5mfdECf6uzkoLh5Wj73JkiT3/IPIgfYjvo/+rd1
X-Google-Smtp-Source: APXvYqzRYtfdHHQQ1ilLCAOSFW/N1md1exZaPRn37dm1NpBvgCmxfkgQcRFIzROG0lOF2JE8YUTTUdM6OMxvOMySuuM=
X-Received: by 2002:a9d:6c54:: with SMTP id g20mr19676717otq.66.1565374600883;
Fri, 09 Aug 2019 11:16:40 -0700 (PDT)
MIME-Version: 1.0
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Fri, 9 Aug 2019 11:16:29 -0700
Message-ID: <CAPg+sBhDQ5yS-BemRWqSxV7TJaWNFs7d-zD6p5HtquFwUjDdsg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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: [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: Fri, 09 Aug 2019 18:16:42 -0000
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
|
