2
1
What’s to stop someone from gaming the system and creating millions of wallets, increasing their odds of accidental deposits? If nothing else you could conceive of a DOS attack of sorts, where the addresses are all burned up. This seems like a major flaw to me... regardless of how many possibilities there are, it's not infinite.
0
Nothing stops anyone from doing that. However, I don't think you'll find many people who agree that it's a "major flaw". If that's a major flaw, then every system in existence has thousands of major flaws. When you say things like "regardless of how many possibilities there are" you're engaging in wild speculative fantasy.
One thing that comes of this is that because the address is Base58encoded, based on my math above, it's 2^40, not 2^106 possibilities as others suggest. A much smaller number. Nobody has validated this thinking... I am looking for correction here... – Robert Christian – 2013-12-28T06:11:36.237
@rob It's 2^160. I don't know how you got 2^40. The encoding has nothing to do with anything. The number one-hundred is the same quantity regardless of how you encoded it (as "100",as "one hundred", as "10x10", or whatever). And what matters is the actual mathematical quantity, not how it's encoded. – David Schwartz – 2013-12-28T06:15:23.767
I am making the case that at the end of the day, everything is distilled to an address, and there can only be so many addresses. To see how I got to 2^40 just read my comments on the original question. If a street has addresses where there can be only two digits, each on 0 to 9, there are 10^2 possibilities before collision. It's a simple argument, but it's true. 2^160 is based on keypair generation, but the hash reduces the possible outputs. I want to be proven wrong. Please do it with clear math, and not a rehash of why we say it's 2^160... the address space is not 2^160. – Robert Christian – 2013-12-31T04:38:52.377
@rob The attacker doesn't have to attack the end, he can attack the weakest point, which is in the middle. Your argument is correct only if you assume an idiotic attacker. The address space is 2^160. There is a trivially reversible, one-to-one correspondence between each of the 2^160 possible hash and each possible valid address. Hence there are 2^160 possible valid addresses. – David Schwartz – 2013-12-31T04:58:24.863
Call me dense, but here is an example address: 1F2Tzu4W8iLEWaMZEHhRMwedD8Di9gvqxK. They are exactly 34 characters. They can only be upper or lower case alphabetical, or numeric, giving 26*2+10=62 possible per character. That's 62^34. Can you break down the flaw with this line of thinking? Hint: You have to step outside of the box for a moment and think about the question with a fresh perspective, and not get hung up on what you are sure of already... because this question has not been adequately addressed at face value yet. (forget the input math and look at the output) – Robert Christian – 2013-12-31T05:09:27.070
Another way to pose the question is: "How does an address that consists of 34 characters in a 0..63 range result in 2^160 possible addresses?" – Robert Christian – 2013-12-31T05:13:31.937
@rob The same way an encoding of any number of characters of the English alphabet and spaces can still only encode ten one-digit numbers -- there only are ten one-digit numbers. There only are 2^160, 160-bit hashes. Therefore any encoding mechanism that can encode all of them can encode precisely 2^160 hashes. – David Schwartz – 2013-12-31T05:18:58.507
Understood. I am looking to fill the gap between the 64^34=2^40 possible values in a 34 character fixed length string of 62 possible characters and the 2^160 possible hash outputs. I am assuming I am missing something in my parameters of the fixed length string but it has yet to be pointed out. – Robert Christian – 2013-12-31T05:29:41.860
Correction, it's smaller than 62 characters. "A set of 58 alphanumeric symbols consisting of easily distinguished uppercase and lowercase letters (0OIl are not used)" – Robert Christian – 2013-12-31T05:53:42.560
I see where I made a simple math mistake reducing 58^34 to a power of two by adding not multiplying the exponents... The bitcoin address is sufficient to contain the 2^160 possible hashes: 58^34 is 904 octodecillion (60 decimal digits), and 2^160 is 1 quindecillion (49 decimal digits)... the larger number accounts for the version byte and checksum. – Robert Christian – 2013-12-31T17:45:57.167
I've heard things like: "Bitcoin already supports OP_HASH256 in script, so it would be trivial to increase the number of addresses if it ever became a problem." here - https://bitcointalk.org/index.php?topic=24268.0
– Robert Christian – 2013-12-22T01:50:22.0801Exercise: estimate the probability that, within 5000 years, such a rig would find a collision with an address already in use, even if every person on the planet has 1 million addresses containing coins. I think you'll find it's much smaller than you expected. 2^160 is a very large number. – Nate Eldredge – 2013-12-22T03:18:24.227
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 per second, it's =(64^34)/(5000606024365*1E+51) to get 16 percent of the addresses in a year working full time with 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. Can someone please check my math? – Robert Christian – 2013-12-23T05:31:42.993
One thing that comes of this is that because the address is Base58encoded, based on my math above, it's 2^40, not 2^106 possibilities as others suggest. A much smaller number. – Robert Christian – 2013-12-27T17:16:01.930
I don't see where you're getting 2^40? Your 64^34 (=2^204) is a bit high to start with. First of all, 0-9,A-Z,a-z is 62 characters, not 64; moreover 0,O,I,l are excluded (to avoid visual confusion), which is where we get 58. So 58^34 would be closer, which is roughly 2^199. But not every string of 34 characters is a legal address; some of the bits are a network byte, and others are a checksum. In fact, an address is formed from a 160-bit hash of a public key, so there really are exactly 2^160 possible addresses. – Nate Eldredge – 2013-12-28T02:14:39.750
(In principle, it could be that some 160-bit strings are not actually the hash of any public key, so the number could be slightly less. This is incredibly unlikely.) – Nate Eldredge – 2013-12-28T02:18:47.683