<p>It's not really clear what your use case is.</p>

<p>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.</p>

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

<p>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 10<sup>20</sup> and 1000000 elements <a href="http://hur.st/bloomfilter?n=1000000&amp;p=1.0E-20" rel="noreferrer">would only take 11 MB</a>.</p>

CC BY-SA 3.0
2015-04-29T22:08:50.993Z
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
CC BY-SA 3.0
2015-04-29T22:12:57.057Z
@derrend The latter.
Nick ODell
CC BY-SA 3.0
2015-04-29T22:14:50.443Z
I suspected as much. Thank you for the speedy reply :D
derrend
CC BY-SA 3.0
2015-04-30T15:07:19.990Z
@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
CC BY-SA 3.0
2015-04-29T00:58:08.707Z
2015-04-29T00:58:08.707Z
Nick ODell
<p>Let's pretend I wanted to store 1MILLION btc addresses in mysql,</p>

<p>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?</p>

<p>Thank you in advance :)</p>

<bitcoind><database><storage>
What is the most efficient way to store bitcoin addresses in a database?
derrend
# What is the most efficient way to store bitcoin addresses in a database?

(Asked by: username_0 on 2015-04-29)

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 :)

**Tags:** bitcoind, database, storage


---

## 1 answers

### Answer by username_1 on 2015-04-29. Score: 5 | Accepted answer

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](http://hur.st/bloomfilter?n=1000000&p=1.0E-20).

> **Comments:**
> **username_0**: Just a quick follow up from yesterday @username_1, 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 :)  
> **username_1**: @username_0 The latter.  
> **username_0**: I suspected as much. Thank you for the speedy reply :D  
> **username_2**: @username_0 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.  

---

