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 :)
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.
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 – 2015-04-29T22:08:50.993
@derrend The latter. – Nick ODell – 2015-04-29T22:12:57.057
I suspected as much. Thank you for the speedy reply :D – derrend – 2015-04-29T22:14:50.443
@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 – 2015-04-30T15:07:19.990