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
|
Return-Path: <crypto@timruffing.de>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C6FD8720
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Aug 2018 21:12:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0688F1A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Aug 2018 21:12:53 +0000 (UTC)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx1.mailbox.org (Postfix) with ESMTPS id AC7764889D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Aug 2018 23:12:51 +0200 (CEST)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241])
by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172])
(amavisd-new, port 10030) with ESMTP id BBAN5vRctlKF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Aug 2018 23:12:50 +0200 (CEST)
Message-ID: <2e620d305c86f65cbff44b5fba548dc85c118f84.camel@timruffing.de>
From: Tim Ruffing <crypto@timruffing.de>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Mon, 06 Aug 2018 23:12:48 +0200
In-Reply-To: <CAPg+sBj7f+=OYXuOMdNeJk3NBG67FSQSF8Xv3seFCvwxCWq69A@mail.gmail.com>
References: <CAPg+sBj7f+=OYXuOMdNeJk3NBG67FSQSF8Xv3seFCvwxCWq69A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 06 Aug 2018 21:16:25 +0000
Subject: Re: [bitcoin-dev] Schnorr signatures BIP
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: Mon, 06 Aug 2018 21:12:54 -0000
Is it intentional that the encoding of public (and private) keys is
unspecified? I'd consider at least the encoding of the public key to be
part of the signature scheme, so ideally it should be specified already
in this BIP. On the other hand, there may be good arguments against it,
but I'm not aware of any.
This issue leads to a discrepancy between the specification and the
test vectors because the data fields of test vectors "are given as byte
arrays", including public and secret key. As a consequence, even the
Python reference implementation in the BIP draft doesn't work on test
vectors (in a strict sense).
Best,
Tim
On Fri, 2018-07-06 at 11:08 -0700, Pieter Wuille via bitcoin-dev wrote:
> Hello everyone,
>
> Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,
> over the same curve as is currently used in ECDSA:
> https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
>
> It is simply a draft specification of the signature scheme itself. It
> does not concern consensus rules, aggregation, or any other
> integration into Bitcoin - those things are left for other proposals,
> which can refer to this scheme if desirable. Standardizing the
> signature scheme is a first step towards that, and as it may be
> useful
> in other contexts to have a common Schnorr scheme available, it is
> its
> own informational BIP.
>
> If accepted, we'll work on more production-ready reference
> implementations and tests.
>
> This is joint work with several people listed in the document.
>
> Cheers,
>
|
