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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sipa@ulyssis.org>) id 1RSJiJ-0005YL-BK
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Nov 2011 02:34:31 +0000
X-ACL-Warn:
Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129]
helo=cavuit01.kulnet.kuleuven.be)
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RSJiI-0002t6-1p for bitcoin-development@lists.sourceforge.net;
Mon, 21 Nov 2011 02:34:31 +0000
X-KULeuven-Envelope-From: sipa@ulyssis.org
X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5,
autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00,
FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20)
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 44790138025.A67EC
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be
[134.58.240.74])
by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 44790138025
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Nov 2011 03:34:21 +0100 (CET)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps01.kuleuven.be (Postfix) with ESMTP id 2B18331E702
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Nov 2011 03:34:21 +0100 (CET)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id B1C5B10052
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Nov 2011 03:35:29 +0100 (CET)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id 20F5387C1B3; Mon, 21 Nov 2011 03:34:30 +0100 (CET)
Date: Mon, 21 Nov 2011 03:34:30 +0100
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20111121023428.GA23065@ulyssis.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
X-Headers-End: 1RSJiI-0002t6-1p
Subject: [Bitcoin-development] Compressed public keys
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 21 Nov 2011 02:34:31 -0000
Hello all,
I just submitted a pull request (#649) that enables the use of compressed
public keys in Bitcoin. As discovered by roconnor (IRC), this is possible
in such a way that old clients verify and relay them without problems.
They are supported by default by OpenSSL, and all alternative
implementations that use OpenSSL should support these keys just fine as
well.
Compressed public keys are 33 bytes long, and contain the same information
as normal 65-byte keys. They only contain the X coordinate of the point,
while the value of the Y-coordinate is reconstructed upon use. This
requires some CPU, but only a fraction of the cost of verifying a
signature.
In theory, one private key now corresponds to two public keys, and thus
two different addresses. As this would probably cause confusion, this
implementation chooses only one of them (at key generation time). All
keys generated when -compressedpubkeys is active, are compressed, and
their reported address is that corresponding to its compressed pubkey.
Things that need attention:
* Do all client implementations support it?
* How to represent secrets for compressed pubkeys?
* send-to-pubkey transactions are untested, for now
--
Pieter
|
