[148601] in cryptography@c2.net mail archive
Re: [Cryptography] BitCoin Question - This may not be the best
daemon@ATHENA.MIT.EDU (Robert Christian)
Sun Dec 22 21:35:31 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CACJAJ58ywpF9jQS-c-E+j_8Hzi4MpRo_NPNnznj-Br4hx0mVTA@mail.gmail.com>
Date: Sun, 22 Dec 2013 18:31:19 -0800
From: Robert Christian <robertjchristian@gmail.com>
To: Steve Weis <steveweis@gmail.com>
Cc: cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2521962548293958247==
Content-Type: multipart/alternative; boundary=001a1130c44643e11b04ee2a6c68
--001a1130c44643e11b04ee2a6c68
Content-Type: text/plain; charset=UTF-8
Exactly my point. What's the collision resolution strategy and why isn't
this a scary proposition?
On Sunday, December 22, 2013, Steve Weis wrote:
> On Sun, Dec 22, 2013 at 4:30 PM, Robert Christian
> <robertjchristian@gmail.com <javascript:;>> wrote:
> > 2) I am pointing out that addresses are finite, and 34 chars long... They
> > can only be upper or lower case, or 0..9. So at the end of the day,
> after
> > all the fancy stuff, the number of all possible bitcoin addresses is
> > (26*2+10)^34 possible unique ids.
> >
> > So the number of possible unique addresses is actually relatively smalll.
> > Right?
>
> The address has 20-bytes of hash, a network ID byte prefix, and a
> 4-byte checksum. So, there are 2^160 possible unique addresses. This
> is converted into a 34 character base-58 string.
>
> You do bring up one point that many key pairs will collide for a
> particular address. That's why the hash function must be assumed to be
> collision resistant.
>
> As for when we might see collisions, with a birthday attack you'd
> expect there to be a 50% chance of some collision existing when there
> are roughly 2^80 addresses.
>
--001a1130c44643e11b04ee2a6c68
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Exactly my point. =C2=A0What's the collision resolution strategy and wh=
y isn't this a scary proposition?<span></span><br><br>On Sunday, Decemb=
er 22, 2013, Steve Weis wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, Dec 22, 2013 at 4:30 PM, Robert Christian<br>
<<a href=3D"javascript:;" onclick=3D"_e(event, 'cvml', 'robe=
rtjchristian@gmail.com')">robertjchristian@gmail.com</a>> wrote:<br>
> 2) I am pointing out that addresses are finite, and 34 chars long... T=
hey<br>
> can only be upper or lower case, or 0..9. =C2=A0So at the end of the d=
ay, after<br>
> all the fancy stuff, the number of all possible bitcoin addresses is<b=
r>
> (26*2+10)^34 possible unique ids.<br>
><br>
> So the number of possible unique addresses is actually relatively smal=
ll.<br>
> Right?<br>
<br>
The address has 20-bytes of hash, a network ID byte prefix, and a<br>
4-byte checksum. So, there are 2^160 possible unique addresses. This<br>
is converted into a 34 character base-58 string.<br>
<br>
You do bring up one point that many key pairs will collide for a<br>
particular address. That's why the hash function must be assumed to be<=
br>
collision resistant.<br>
<br>
As for when we might see collisions, with a birthday attack you'd<br>
expect there to be a 50% chance of some collision existing when there<br>
are roughly 2^80 addresses.<br>
</blockquote>
--001a1130c44643e11b04ee2a6c68--
--===============2521962548293958247==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============2521962548293958247==--
