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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sipa@ulyssis.org>) id 1RaCwr-0003Gs-BU
for bitcoin-development@lists.sourceforge.net;
Mon, 12 Dec 2011 20:58:09 +0000
X-ACL-Warn:
Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129]
helo=cavuit01.kulnet.kuleuven.be)
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RaCwq-0006dA-93 for bitcoin-development@lists.sourceforge.net;
Mon, 12 Dec 2011 20:58:09 +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: C0714138025.A7054
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 C0714138025
for <bitcoin-development@lists.sourceforge.net>;
Mon, 12 Dec 2011 21:57:54 +0100 (CET)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps01.kuleuven.be (Postfix) with ESMTP id B32A731E702
for <bitcoin-development@lists.sourceforge.net>;
Mon, 12 Dec 2011 21:57:54 +0100 (CET)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id B3CC510052
for <bitcoin-development@lists.sourceforge.net>;
Mon, 12 Dec 2011 22:58:07 +0100 (CET)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id 9CDD187C1AB; Mon, 12 Dec 2011 21:57:54 +0100 (CET)
Date: Mon, 12 Dec 2011 21:57:54 +0100
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20111212205753.GB16665@ulyssis.org>
References: <201112061610.41083.luke@dashjr.org>
<201112061628.18634.luke@dashjr.org>
<201112101316.31666.luke@dashjr.org>
<20111212205559.GA16665@ulyssis.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20111212205559.GA16665@ulyssis.org>
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: 1RaCwq-0006dA-93
Subject: Re: [Bitcoin-development] Version bytes "2.0"
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, 12 Dec 2011 20:58:09 -0000
It seems base58 is actually quite terrible for producing nice human-recognizable
addresses, even though base58 is specially intended for human usage. We'll just
have to deal with it, or completely overhaul it and move to a saner encoding.
Luke's proposal is somewhat more drastic than my original one, since it removes
the actual "version" notion from the version bytes, and changes testnet addresses.
However, I think it may be worth it. More data classes have been necessary
before, and new versions haven't. Furthermore, they are far more recognizable to
users, which is something that in particular for OP_EVAL addresses (script hashes)
will be a plus.
Therefore, I'm in favor of the proposal; the new versions would become:
0: mainnet pubkey hashes ('1', as before)
192: testnet pubnet hashes ('2', instead of 111, 'm' and 'n')
5: mainnet script hashes ('3'; for OP_EVAL)
196: testnet script hashes ('2', same as normal testnet addresses)
12: mainnet private keys ('Q', 'R' or 'S', instead of 128, '5')
204: testnet private keys ('7', instead of 239, '8' and '9')
Comments?
--
Pieter
|
