<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 22, 2013, at 9:44 PM, Robert Christian <<a href="mailto:robertjchristian@gmail.com">robertjchristian@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 22, 2013, at 6:31 PM, Robert Christian <<a href="mailto:robertjchristian@gmail.com">robertjchristian@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Exactly my point. What's the collision resolution strategy and why isn't this a scary proposition?<span></span><br><br></blockquote><div><br></div><div>I did the math on this and it starts to make sense without a collision strategy. For ID's, it's 34 characters that can be 0..9, a..z, and A..Z. That's 64^34. If you could do 5,000 wallet generations per second, it's =(64^34)/(5000*60*60*24*365*1E+51) to get 16 percent all possible addresses within a year with all systems working full time - being a total of 100,000,000,000,000,016,384,608,344,632,472,552,568,168,984,184,560 machines on the task. I think that settles it as a non-efficient means of hacking, at least for the next decade or so until quantum computing comes into play.</div><div><br></div><div>Can someone please check my math? And my premise in general? I feel like I might be missing something fundamental here…. and I think at this point it’s established that there is no collision strategy at all regardless of the fact it’s unlikely?</div></div></div></blockquote><div><br></div>>></div><div><br></div><div>Edit: There are only 58 possible characters. 0OlI are excluded from the set to avoid being misread. and there are a few characters within the address used for version and checksum.</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div><br></div><br><blockquote type="cite">On Sunday, December 22, 2013, Steve Weis wrote:<br><blockquote class="gmail_quote" style="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="javascript:;" onclick="_e(event, 'cvml', 'robertjchristian@gmail.com')">robertjchristian@gmail.com</a>> wrote:<br>
> 2) I am pointing out that addresses are finite, and 34 chars long... They<br>
> can only be upper or lower case, or 0..9. So at the end of the day, after<br>
> all the fancy stuff, the number of all possible bitcoin addresses is<br>
> (26*2+10)^34 possible unique ids.<br>
><br>
> So the number of possible unique addresses is actually relatively smalll.<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>
</blockquote></div><br></div></blockquote></div><br></body></html>