<p>Clients only need to track the currently valid information (there is an expiry date for domains, for example) and not all applications need all of the data stored in the chain.  So, much like Bitcoin itself, application specific versions of the information stored in the blockchain will be used by most applications and they can use SCIP or distributed trust models to check the validity of information instead of storing the entire blockchain locally.</p>

<p>For shits and giggles, I downloaded the top 1 million domains and some IP blacklists, resulting in a 4MB CSV file containing 142,202 IP &lt;-> domain pairs. Simple Zip compression yielded 2:1 - 3:1 compression rates while PAQ8 delivered rates >4:1. A custom data-structure would likely yield even higher compression ratios.</p>

<p>Simple extrapolation of these numbers shows that 5megs can easily handle half a million such pairings. If traffic is distributed in a Zipf-like distribution, the .bit namespace can grow to 2.5 million domains (the size the .bi*<em>z</em>* domain space) and clients could still store the top 20% of sites which receive 80% of all traffic in a 5 meg cache. With even .INFO carrying 6 million domains, we have room to grow :)</p>

<p>And, finally, storage tends to get cheaper over time and the chain could be setup to dynamically set prices.</p>

CC BY-SA 3.0
2013-12-11T00:17:27.247Z
2014-01-02T04:04:58.160Z
2014-01-02T04:04:58.160Z
Indolering
<p>It seems that an idea to store all information inside a blockchain would lead to its bloating.</p>

<p>There are about 250MM of domains in the web, namecoin allows to store 1Kb of data per record, it leads to 250Gb of data to store in the blockchain, but namecoin is far more general key/value storage than DNS, so the real size of blockchain is expected to be larger. </p>

<p>Am I right? What is the strategy to avoid or to deal with this bloating?</p>

CC BY-SA 3.0
2013-12-09T17:21:56.397Z
Namecoin has a serious bug, that the developer has admitted such. Not sure when it will be fixed.
T9b
CC BY-SA 3.0
2013-12-09T17:33:30.690Z
The bug which you're referring to was fixed at height 150000 and version Q.3.72.
Anonymous
CC BY-SA 3.0
2013-12-11T00:18:39.067Z
This bug is of no relevance to the OP.
Indolering
<blockchain><namecoin><scalability>
Scalability of namecoin
rystsov
# Scalability of namecoin

(Asked by: username_0 on 2013-12-09)

It seems that an idea to store all information inside a blockchain would lead to its bloating.

There are about 250MM of domains in the web, namecoin allows to store 1Kb of data per record, it leads to 250Gb of data to store in the blockchain, but namecoin is far more general key/value storage than DNS, so the real size of blockchain is expected to be larger.

Am I right? What is the strategy to avoid or to deal with this bloating?

**Tags:** blockchain, namecoin, scalability

> **Comments:**
> **username_1**: Namecoin has a serious bug, that the developer has admitted such. Not sure when it will be fixed.  
> **username_2**: The bug which you're referring to was fixed at height 150000 and version Q.3.72.  
> **username_3**: This bug is of no relevance to the OP.  

---

## 1 answers

### Answer by username_3 on 2013-12-11. Score: 3

Clients only need to track the currently valid information (there is an expiry date for domains, for example) and not all applications need all of the data stored in the chain. So, much like Bitcoin itself, application specific versions of the information stored in the blockchain will be used by most applications and they can use SCIP or distributed trust models to check the validity of information instead of storing the entire blockchain locally.

For shits and giggles, I downloaded the top 1 million domains and some IP blacklists, resulting in a 4MB CSV file containing 142,202 IP <-> domain pairs. Simple Zip compression yielded 2:1 - 3:1 compression rates while PAQ8 delivered rates >4:1. A custom data-structure would likely yield even higher compression ratios.

Simple extrapolation of these numbers shows that 5megs can easily handle half a million such pairings. If traffic is distributed in a Zipf-like distribution, the .bit namespace can grow to 2.5 million domains (the size the .bi\**z*\* domain space) and clients could still store the top 20% of sites which receive 80% of all traffic in a 5 meg cache. With even .INFO carrying 6 million domains, we have room to grow :)

And, finally, storage tends to get cheaper over time and the chain could be setup to dynamically set prices.


---

