3

Let's pretend I wanted to store 1MILLION btc addresses in mysql,

I thought about saving the last 10 digits of each submitted address and testing against that but would 10 characters be enough to avoid duplicates? Is 10 digits too much? Or is there an even better way, does an industry standard exist?

Thank you in advance :)

| improve this question | |
5

It's not really clear what your use case is.

If you need to retrieve the addresses later, you can store each address as a string. That's only ~34MB, which easily fits in memory.

To save space, you can convert each address to hash160 format, which is only 20 bytes. In total, that's 20 MB.

If you're merely trying to test whether a Bitcoin address is contained within the database then you could use a bloom filter. A bloom filter with a false positive rate of 1 in 1020 and 1000000 elements would only take 11 MB.

| improve this answer | |
  • Just a quick follow up from yesterday @Nick ODell, does a method of testing exist which I could use to check which parent a sub public key came from or is my only option to generate sub keys from the suspected parent(s) until a match is found? I'm just wondering if I can reduce the number of keys I need in my database to just the parent keys if you catch my drift :) – derrend Apr 29 '15 at 22:08
  • @derrend The latter. – Nick ODell Apr 29 '15 at 22:12
  • I suspected as much. Thank you for the speedy reply :D – derrend Apr 29 '15 at 22:14
  • @derrend sounds like you're talking about storing a million of your own addresses? In that case you can simply store the xpub key and a million derivation paths. Unclear what addressees yippee taking about and what the purpose of the database will be. – Jannes Apr 30 '15 at 15:07

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.