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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1RzWrV-0005Eo-IT
for bitcoin-development@lists.sourceforge.net;
Mon, 20 Feb 2012 17:17:17 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=gavinandresen@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RzWrR-0003aW-DG
for bitcoin-development@lists.sourceforge.net;
Mon, 20 Feb 2012 17:17:17 +0000
Received: by werc1 with SMTP id c1so4690442wer.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 20 Feb 2012 09:17:07 -0800 (PST)
Received-SPF: pass (google.com: domain of gavinandresen@gmail.com designates
10.180.102.35 as permitted sender) client-ip=10.180.102.35;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
gavinandresen@gmail.com designates 10.180.102.35 as permitted
sender) smtp.mail=gavinandresen@gmail.com;
dkim=pass header.i=gavinandresen@gmail.com
Received: from mr.google.com ([10.180.102.35])
by 10.180.102.35 with SMTP id fl3mr18655743wib.22.1329758227356
(num_hops = 1); Mon, 20 Feb 2012 09:17:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.102.35 with SMTP id fl3mr15525524wib.22.1329758227200;
Mon, 20 Feb 2012 09:17:07 -0800 (PST)
Received: by 10.223.116.15 with HTTP; Mon, 20 Feb 2012 09:17:07 -0800 (PST)
In-Reply-To: <3DA9C79B-D91D-48B2-9469-37BAA037FC50@ceptacle.com>
References: <3DA9C79B-D91D-48B2-9469-37BAA037FC50@ceptacle.com>
Date: Mon, 20 Feb 2012 12:17:07 -0500
Message-ID: <CABsx9T0hCAtJnA9YnmVAMjjSPB5W30e=cp8BX2mO--cWEzuSNQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: =?ISO-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
Content-Type: multipart/alternative; boundary=f46d044517f3c4fb5504b96876d2
X-Spam-Score: -1.1 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RzWrR-0003aW-DG
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: Mon, 20 Feb 2012 17:17:17 -0000
--f46d044517f3c4fb5504b96876d2
Content-Type: text/plain; charset=ISO-8859-1
RE:
> base58-encode: [one-byte network ID][20-byte hash][one-byte address
class][3-byte checksum]
How will the code distinguish between the old scheme:
[one-byte-version][20-byte-hash][4-byte-checksum]
and the new?
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:
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
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.
RE: should it be a BIP: The BIP process is described in BIP
0001<https://en.bitcoin.it/wiki/BIP_0001#BIP_Work_Flow>,
and you're following it perfectly so far:
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
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.
--
--
Gavin Andresen
--f46d044517f3c4fb5504b96876d2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
RE:<br>> base58-encode: [one-byte network ID][20-byte hash][one-byte add=
ress class][3-byte checksum]<br><br>How will the code distinguish between t=
he old scheme:<br> [one-byte-version][20-byte-hash][4-byte-checksum]<br>
and the new?<br><br>1 in 256 old addresses will have a first-byte-of-checks=
um that matches the new address class; I guess the code would do something =
like:<br><br>a) If the 4-byte checksum matches, then assume it is a singles=
ig address (1 in 2^32 multisig addresses will incorrectly match)<br>
b) If the one-byte-address-class and 3-byte checksum match, then it is a va=
lid p2sh<br>c) Otherwise, invalid address<br><br>The 1 in 2^32 multisig add=
resses also being valid singlesig addresses makes me think this scheme won&=
#39;t work-- an attacker willing to generate 8 billion or so ECDSA keys cou=
ld generate a single/multisig collision. =A0I'm not sure how that could=
be leveraged to their advantage, but I bet they'd find a way.<br>
<br>RE: should it be a BIP: =A0The BIP process <a href=3D"https://en.bitcoi=
n.it/wiki/BIP_0001#BIP_Work_Flow">is described in BIP 0001</a>, and you'=
;re following it perfectly so far:<div><br></div><div>1) Post a rough draft=
of the idea here to see if there's any chance it'll be adopted</di=
v>
<div>2) Assuming a positive response and no major flaws: write up a draft B=
IP</div><div>3) Post the draft BIP here, where it can be picked apart.</div=
><div>4) Assuming no major flaws, ask the BIP editor (Amir) for a BIP numbe=
r</div>
<div><br></div><div>I'd also encourage you to actually implement your i=
dea 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 f=
law.<br>
<br>-- <br>--<br>Gavin Andresen<br></div>
--f46d044517f3c4fb5504b96876d2--
|
