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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <nadav@shesek.info>) id 1Uq81j-0005Bv-N6
for bitcoin-development@lists.sourceforge.net;
Fri, 21 Jun 2013 20:33:47 +0000
X-ACL-Warn:
Received: from mail-ve0-f180.google.com ([209.85.128.180])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Uq81h-0004rg-Fx
for bitcoin-development@lists.sourceforge.net;
Fri, 21 Jun 2013 20:33:47 +0000
Received: by mail-ve0-f180.google.com with SMTP id pa12so6900753veb.11
for <bitcoin-development@lists.sourceforge.net>;
Fri, 21 Jun 2013 13:33:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-originating-ip:from:date:message-id:subject:to
:content-type:x-gm-message-state;
bh=IeRAVL+/faT1LLloKw9rmuPkRgo7ZJxarGqfSFdGKe0=;
b=ScuH0WHBYL5Y7dc6elJSiPdjGgluPH8cMpVsrGzgP3/5Hdrx2Mh5o1Y/WyEJBHQrZY
WcSVtrUGGHZWDbMuUcOpuLGE00SJm2d+wQh2Pg4uChG76NTZsUIcspvfF5/XDhcEP8S1
7kHKkzYRnRmA6rPYHs5L74ecVfQk5iGGwUmEn/ODeU/mVaTrCJJ3+JocSMLwDmm/uA93
VdhprWmoegiI2tCMYlEMCt8fmmLuHzlFoEQGT1cOfX3NhfSJYDXPPnhXCSMvzfiAitp6
+rvqKWZPcomBhm9YeWPF3GY9scyV6v89zT6TFaIQDvYJJBtY3E5mhDMY+q84D7MHDzeB
0tSA==
X-Received: by 10.220.66.136 with SMTP id n8mr6324201vci.49.1371846379620;
Fri, 21 Jun 2013 13:26:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.36.177 with HTTP; Fri, 21 Jun 2013 13:25:59 -0700 (PDT)
X-Originating-IP: [217.132.7.235]
From: Nadav Ivgi <nadav@shesek.info>
Date: Fri, 21 Jun 2013 23:25:59 +0300
Message-ID: <CAGXD5f1RRuwDJsLUiQVOXzeHFPA5HrBvatjvhDw9oFO7yNe-og@mail.gmail.com>
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b3a7f9624dffe04dfafe060
X-Gm-Message-State: ALoCoQlXypc3Uwf5H4Uv4/Oh7nGhhw5ShZtVTiMd/o/Py9Mp8/7dglLBpbCCWTwaRFejISrxp4m4
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Headers-End: 1Uq81h-0004rg-Fx
Subject: [Bitcoin-development] Standard public key base58-check address
prefix?
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: Fri, 21 Jun 2013 20:33:47 -0000
--047d7b3a7f9624dffe04dfafe060
Content-Type: text/plain; charset=ISO-8859-1
I'm working on a project that requires users to exchange public keys (for
multisig transactions).
It seems that hex encoding is usually used to display public keys (i.e. in
bitaddress and brainwallet), which results in longer strings and lacks the
4-bytes verification.
A standard way to encode public keys as base58-check addresses would make
it easier and safer to display and exchange public keys. All that is really
needed is deciding on a prefix byte.
Perhaps we can use 0x37/0x38, which results in the letter P (for "Public")?
It seems like those bytes aren't used for anything yet.
Thanks,
Nadav
--047d7b3a7f9624dffe04dfafe060
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"font-family:arial,sans-serif;font-size:12.80=
0000190734863px">I'm working on a project that requires users to exchan=
ge public keys (for multisig transactions).</div><div style=3D"font-family:=
arial,sans-serif;font-size:12.800000190734863px">
<br></div><div style=3D"font-family:arial,sans-serif;font-size:12.800000190=
734863px">It seems that hex encoding is usually used to display public keys=
(i.e. in bitaddress and brainwallet), which results in longer strings and =
lacks the 4-bytes verification.</div>
<div style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">=
<br></div><div style=3D"font-family:arial,sans-serif;font-size:12.800000190=
734863px">A standard way to encode public keys as base58-check addresses wo=
uld make it easier and safer to display and exchange public keys. All that =
is really needed is deciding on a prefix byte.</div>
<div style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">=
<br></div><div style=3D"font-family:arial,sans-serif;font-size:12.800000190=
734863px">Perhaps we can use 0x37/0x38, which results in the letter P (for =
"Public")? It seems like those bytes aren't used for anything=
yet.</div>
<div style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">=
<br></div><div style=3D"font-family:arial,sans-serif;font-size:12.800000190=
734863px">Thanks,</div><div style=3D"font-family:arial,sans-serif;font-size=
:12.800000190734863px">
Nadav</div>
</div>
--047d7b3a7f9624dffe04dfafe060--
|
