summaryrefslogtreecommitdiff
path: root/78/2229806813d8ab75e7e2413c8047f5edb88572
blob: afa28aa6a80184ca7cb5cd0078d4317abdfc348a (plain)
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
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gronager@ceptacle.com>) id 1S0F55-00088S-LG
	for bitcoin-development@lists.sourceforge.net;
	Wed, 22 Feb 2012 16:30:15 +0000
X-ACL-Warn: 
Received: from 2508ds5-oebr.0.fullrate.dk ([95.166.54.49]
	helo=mail.ceptacle.com)
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1S0F51-0003a5-0c for bitcoin-development@lists.sourceforge.net;
	Wed, 22 Feb 2012 16:30:15 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail.ceptacle.com (Postfix) with ESMTP id 445A717C2154;
	Wed, 22 Feb 2012 17:30:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at ceptacle.com
Received: from mail.ceptacle.com ([127.0.0.1])
	by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id y+Nwn9XnTgoT; Wed, 22 Feb 2012 17:29:59 +0100 (CET)
Received: from [10.0.1.28] (2508ds5-oebr.0.fullrate.dk [95.166.54.49])
	by mail.ceptacle.com (Postfix) with ESMTPSA id E229417C2143;
	Wed, 22 Feb 2012 17:29:59 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CABsx9T0hCAtJnA9YnmVAMjjSPB5W30e=cp8BX2mO--cWEzuSNQ@mail.gmail.com>
Date: Wed, 22 Feb 2012 17:29:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F78AEBDF-F314-4245-B453-8D23C709D226@ceptacle.com>
References: <3DA9C79B-D91D-48B2-9469-37BAA037FC50@ceptacle.com>
	<CABsx9T0hCAtJnA9YnmVAMjjSPB5W30e=cp8BX2mO--cWEzuSNQ@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
X-Mailer: Apple Mail (2.1257)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1S0F51-0003a5-0c
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP-13
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: Wed, 22 Feb 2012 16:30:15 -0000

Hi Gavin / Luke,

BIP-13 again... I started to implement a bitfield based parsing of the =
version byte using the description I got from Luke, but I then =
discovered that it does not hold:
Network class:
00xxxxxx - main network
01xxxxxx - reserved
10xxxxxx - reserved
11xxxxxx - test network

Network:
xx00xxxx - bitcoin
xx01xxxx - reserved
xx10xxxx - OTHER (next octet)
xx11xxxx - Namecoin

Network specific:
xxxx000y - PubKeyHash
xxxx001y - reserved
xxxx010y - p2sh
xxxx011y - public key (raw)
xxxx100y - signature
xxxx101y - reserved
xxxx110y - private key (raw)
xxxx111y - OTHER (next octet)

However, the definitions en base58.h are:

        PUBKEY_ADDRESS =3D 0, (00000000)
        SCRIPT_ADDRESS =3D 5, (00000101)
        PUBKEY_ADDRESS_TEST =3D 111, (01101111) !!!
        SCRIPT_ADDRESS_TEST =3D 196, (11000100) !!!

[as a side note litecoin is 48 (00110000) and namecoin is 52 (00110100)]

So there is no logic ?? I have searched the mailing list and the forum =
for discussions on this but found it hard to find any. If I overlooked =
something please direct me.

Cheers,

M

PS: I have said so before, but it would *really* be nice if discussions =
/ conclusions / irc-summaries were taking place at one place - e.g. at =
the bitcoin-dev mailing list, not at 5-10 different threads in =
bitcointalk or in bip notes or solely on IRC...


On 20/02/2012, at 18:17, Gavin Andresen wrote:

> RE:
> > base58-encode: [one-byte network ID][20-byte hash][one-byte address =
class][3-byte checksum]
>=20
> How will the code distinguish between the old scheme:
> [one-byte-version][20-byte-hash][4-byte-checksum]
> and the new?
>=20
> 1 in 256 old addresses will have a first-byte-of-checksum that matches =
the new address class; I guess the code would do something like:
>=20
> a) If the 4-byte checksum matches, then assume it is a singlesig =
address (1 in 2^32 multisig addresses will incorrectly match)
> b) If the one-byte-address-class and 3-byte checksum match, then it is =
a valid p2sh
> c) Otherwise, invalid address
>=20
> The 1 in 2^32 multisig addresses also being valid singlesig addresses =
makes me think this scheme won't work-- an attacker willing to generate =
8 billion or so ECDSA keys could generate a single/multisig collision.  =
I'm not sure how that could be leveraged to their advantage, but I bet =
they'd find a way.
>=20
> RE: should it be a BIP:  The BIP process is described in BIP 0001, and =
you're following it perfectly so far:
>=20
> 1) Post a rough draft of the idea here to see if there's any chance =
it'll be adopted
> 2) Assuming a positive response and no major flaws: write up a draft =
BIP
> 3) Post the draft BIP here, where it can be picked apart.
> 4) Assuming no major flaws, ask the BIP editor (Amir) for a BIP number
>=20
> I'd also encourage you to actually implement your idea between steps 3 =
and 4. But in this particular case, I think an attacker being able to =
create singlesig/p2sh address collisions counts as a major flaw.
>=20
> --=20
> --
> Gavin Andresen

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager@ceptacle.com
Web: http://www.ceptacle.com/