9

Generally speaking, the address space of Bitcoin seems to be sufficiently large to make it unlikely that a hash collision will ever occur (see below).
Pacerier stated in a comment on Is it possible to brute force bitcoin address creation in order to steal money? that we'd "want Bitcoin to scale to [...] 10b people, each generating 10k different addresses a day, that's 100 trillion addresses created daily." He followed up with "10k may be a severe underestimation".

100 trillion is 10^14, so if we kept up that pace, we'd have used one address per satoshi after 21 days. I am confused as to what might be the reasons for users to need 10k addresses per day.

Please explain: Why does it seem likely that we will need such a large number of new addresses each day? In what scenario would each user in average need 10k new addresses per day?


Total number of satoshis:
Total number of satoshis

At one address for each satoshi that could be ever in existence (2.1*10^15), with the giant address space of 2^160 possible addresses, the simple approximation of the Birthday paradoxon, which works well for probabilities less than or equal to 0.5...

enter image description here

... tells us that the chance of single hash collision occurring is still pretty small: 1.508*10^(-18).

  • 2
    I see an issue with using satoshis as a limiting factor in future hypotheticals. It's been suggested that if it were ever deemed useful/necessary, the satoshi could easily be split further. (although by that point, hypothetically, we might've moved to longer addresses to avoid just this problem) – Tim S. Mar 31 '14 at 20:30
7

Bitcoin transactions usually carry change, and to increase privacy and security, it is certainly no worse to generate a new address every time for receiving change than to reuse old addresses. Details maybe belong into their own question; however, it is well within the realm of reason to expect a future where most Bitcoin transactions include two new addresses (one for the person paid and one for the change back to the payer).

If we dream up a future where arbitrarily small micropayments can be handled by Bitcoin, then I would actually call the 5k transactions per user that could hence generate 10k new Bitcoin addresses a vast understatement of the potential. I'm thinking that rather than paying my mobile carrier for data roaming, I'd want to use micropayments to pay for routing of IP packets in adhoc wifi networks (ok, maybe not for each individual packet given the overhead---but I could, from a user's perspective, want that to happen for every 10 kb chunk of data or so). And I can envision much the same thing with my regular ISP, or even with most websites I frequent (and, come to think about it, maybe some of them should pay me).

The problem with this is that all these transactions end up in the blockchain, occupying a huge amount of disk space. That is why many suggest that micropayments ultimately belong off-blockchain, meaning some other solution should be found for them that does not place the burden on Bitcoin. In my example, it is easy to see why this is necessary: Even if only 100 nodes kept the entire blockchain, then my 10 kb chunk of transmission data would occupy much more than that in distributed blockchain storage just to finalize my payment for it. Obviously not just inefficient but truly unsustainable at scale.

Hence I would say that as far as Bitcoin's blockchain is concerned, we need not worry about seeing quite that many addresses added to it. But if whatever off-blockchain solutions we will adopt for micropayments in the future uses Bitcoins' address scheme as well, then we may well, outside the blockchain, envision such a massive use of Bitcoin addresses.

  • I like your answer, but would like wait whether somebody will argue the counter-position, so I'll not accept just yet. – Murch Mar 31 '14 at 16:07
4

I would say before we are dealing thousands of microtransactions per day, which I still consider to be far off, is the idea of people and corporations using vanity addresses. Let's just say that I want all my addresses to start with Mark (or as close to mark as possible, e.g. for bitcoin would be 1mark and for litecoin would be Lmark and so on).

Since there is no way to start with an address including, say 1mark, and reverse to find the private key (an assumption on which mining, password hashing, and many other security protocols are based on); I will have to do the inverse: generate a random private key, create a public key, and check if this public key meets my criteria. If the address I generated starts with 1mark then I will add it to my wallet, otherwise I will throw out this private key and try again until I find my address.

Bitcoin and it's derivatives do not allow certain characters in public keys as to avoid confusion. I believe these restricted characters are: number 0 and capital O, number 1 and lowercase l (except for the first character in a coin address). This means that I have 58 usable characters (26 UPPERCASE letters + 26 lowercase letters + 10 numbers - 4 unusable characters in these sets). I do not believe there are more but someone please correct me if I am wrong :)

If there are 58 usable characters for an address, and let's say I am very concerned about the capitalization of my name (i.e. it needs to be 1mark, not 1MaRK or any other permutation with capitalization), the average amount of addresses I will need to generate to find an address begining in 1mark would be 58^4, or 11,316,496. If I didn't care about the capitalizataion of my name it could be as low as 707,281 addresses generated to find an address which begins with my name. That being said, I have a pretty short name, someone name Satoshi will need many more hashes to get his name as a vanity address.

If the water company is using vanity addresses as well, (e.g. 1water) to help their customers differentiate their charges or for any other reason, this increases by the amount of vanity addresses they use per day.

I would use a vanity address generator (see disclaimer) to do this currently, I imagine it will likely built in to standard wallet software at some point, since it is a nice novel feature and allows for more custom firstbits (short identifiers for bitcoin addresses, more information on firstbits can be found here https://en.bitcoin.it/wiki/Firstbits ).

Disclaimer: be careful how you generate a vanity address, currently the best method is to use VanityGen (more info here: https://en.bitcoin.it/wiki/Vanitygen ). Please read up on the possible issues with a vanity address generator and make sure to do so securely if you intend to use a vanity address to save any significant amount of coins (e.g. make sure that the developer can not get access to your private key during or after creation, by running vanitygen on a live usb without connecting to the internet).

  • 1
    There are indeed exactly 58 unique symbols in Base58 econding. +1 for pointing out that many (throw-away, hence off-blockchain) addresses get generated in the search of vanity addresses. The mass use of vanity addresses by merchants/utilities for each customer is an interesting idea. For a company whose name or brand can be shortened as much as their stock listing symbol, that may actually be justifiable. – pyramids Mar 31 '14 at 19:44
  • Thanks, I did not intend to replace your answer, which is very good and to the point, but I wanted to chime in about vanity addresses (with explanation), which did not fit in a comment :) – Mark Mar 31 '14 at 19:58
  • No worries, you did not replace my answer, you only contributed another good answer. ;-) – pyramids Mar 31 '14 at 20:08
  • Very interesting points, however if the private keys for the misses on vanity address generation are discarded, the number of addresses in use is actually no greater than if they just used a random address. The chances of getting a hash collision with a vanity address might be greater though. If all tries were retained, I could see how that would cause a huge number of addresses being used everyday. – Murch Apr 1 '14 at 10:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.