Namecoin Forum

Why ?

I think, everybody should be able to store the entire namecoin data, even in the future

My point is, smaller is the limit, more easy it will be to store the entire blockchain by anybody
And if 520 is enouth today acording to that bug, maybe 1k will be ok for a long time ?
(but maybe I missed something big ? )

And what's the problem about storing the keys in some key servers ?
I don't undestand why it's slower and so much complicated ?

Not having to depend on "import" for space so much would also simplify the implementation of Namecoin services.

What do you mean by service ? Like mail ? wiki page ? file sharing ?
none of these data can fit in the blockchain in my view. But these data can be replicated on many peers, by peoples supporting that service ?

GPG key is maybe a special case, as it's not really a data but a key ...

phelix wrote:cross post:

GiToo wrote:As namecoin seems more a "public index" than a "distributed storage"
What about, instead of storing the GPG key in the blockchain, storing a GPG_key_server_name.bit instead, hosting the keys with the same id/ ?
9k is too much I think, 1k is maybe enouth to store any "reference" to a data but not the data itself ?

why? So far I have not yet heard one single good argument against the 9k.

Well, there are also signatures. Also referencing everything makes things more complicated and slow.

I agree that referencing on a hosted storage makes it more complicated and would become decentralized and would loose with it the Namecoin specific advantage.

I also didn't heard any argument what would bring 9k over 5k. The only recommendation for 8k gpg key in the future I found by Bruce Schneier, but this is actually not supported by the gpg standard.
I think the value field should be big enough for all purposes but should be not bigger. 5k would be 10X more then the previous 0.5k and who knows what problems will bring even this. ( like introducing illegal content, overbloating the blockchain, ...)
But this is just my opinion. I am also not fixed on it. If Khal makes the rebase then he should have some decisions freedom and I thrust in his knowledge of the Namecoin network. But if it will make another programmer and he prefer 2.5k field this is also acceptable for me.
I just consider now 5k optimal but between(2.5k - 9k) acceptable.

ok

to make a service "censorship resistant", the important information is maybe the number of peers of this service (on various networks type)
taking an ipv6 as peer of a service, max 39byte as string format + json =~ 50byte per peer in average
with 1kb, ~20 peers can be define for one domain or "service" (can you confirm this ? )
with 5kb, ~100
with 9kb, ~180

I'm not sure about this, what do you think ?
maybe 20peers isn't enouth for one service ?

PS: if someone think I'm talking too much, please just tell me, don't want to bother you

GiToo wrote:ok

to make a service "censorship resistant", the important information is maybe the number of peers of this service (on various networks type)
taking an ipv6 as peer of a service, max 39byte as string format + json =~ 50byte per peer in average
with 1kb, ~20 peers can be define for one domain or "service" (can you confirm this ? )
with 5kb, ~100
with 9kb, ~180

I'm not sure about this, what do you think ?
maybe 20peers isn't enouth for one service ?

PS: if someone think I'm talking too much, please just tell me, don't want to bother you

I don't know what do you mean.
To extend the Namecoin Identity system for different applications we need to store the gpg public key in a value field(which is limited actually to 0,5k due to a bug, otherwise would be 1k).
The actually most used key is the 1024 bit RSA which should be deprecated in the near future, since they may become breakable in the near future.
https://en.wikipedia.org/wiki/Key_size
Retroshare (where could be a good ID implementation) and some other applications are using 2048 bit RSA keysize.
Some specialists consider the 2048 bit key secure until 2030 others even the 4096 keys just until 2020.
So I would say the value field size should be at least 2.5k but optimal 5k.
More is not necessary(for the gpg public key storage) because the actual gpg standard supports only max 4096 keysize.

I was trying to "evaluate" the number of IP address you can assign to one d/domain in 1k
(and trying to find another case where 1k limit is maybe too short, not only for gpg keys)

for ex: a controversial website like d/wikileaks
as the content cannot fit in namecoins
for being censorship resistant, it will need to assign many addresses like tor/oignon, cjdns, freenet, and many public IP address ?
so 20 address for one domain is maybe too short ?

5k seems fine to me now

I'm researching a solution to this problem of the blockchain size. currently I am researching the various torrent sevices, magnet links, hash tracking systems etc.

My idea is to turn the blockchain into a torrented file for the namecoin service so information is downloaded dynamically as it is needed. To maintain security I am researching how to combine nmcontrol with namecoin + plug-ins to make anyone who connects to a website a server for the website, optionally of course and allow the website to pay those users for helping distribute the .bit sites.

ETA 3-6 months, I'll be working on my git hub repository as i have time, it'll take so long because i'm researching how to rebase namecoin off of the current Bitcoin client .8.5. there is a lot of code to look at and am reviewing all of it for security reasons... can never be to careful.

the value field should be as large as necessary to maintain maximum flexibility.

GiToo wrote:I was trying to "evaluate" the number of IP address you can assign to one d/domain in 1k
(and trying to find another case where 1k limit is maybe too short, not only for gpg keys)

for ex: a controversial website like d/wikileaks
as the content cannot fit in namecoins
for being censorship resistant, it will need to assign many addresses like tor/oignon, cjdns, freenet, and many public IP address ?
so 20 address for one domain is maybe too short ?

5k seems fine to me now

The "import" field is sufficient for assigning multiple resolvers to a domain. Not necessarily better than a longer value size limit, but sufficient. The bigger problem is single field values which don't fit in a single name (e.g. a 4k GPG key).

Assuming that a single large-value name is more expensive than multiple small-value names, then users will only use long-valued names for use cases such as the 4k GPG key.

5k is reasonable in my opinion. But I don't feel particularly strongly.

(Speaking of WikiLeaks, does WikiLeaks still have control of d/wikileaks? Looks like it expired in 2011 and was reregistered with a different IP, and that IP doesn't seem to load for me.)

Some relevant informations in this context what I found now:
The actual gnupg 2.0.22 supports max 4096 bit size DSA key but there is a gnupg 2.1 beta with ECDSA support.
To compare 1024 bit DSA key has the same level of security as 320 bit ECDSA key.
https://code.google.com/p/gnupg-ecc/
So it seems that the next Gnupg version will have ECDSA support also which has a higher key efficiency.

GiToo wrote:

Why ?

I think, everybody should be able to store the entire namecoin data, even in the future

This really is in no way related. Spamming will be cheaper with several small tx than with one large tx due to the more than linear increasing per byte fee.

I take it there is something like a consensus for 5k. With ECC there really should not be need for 8k keys. And anything else can be linked.

I see no objection for a 5k size field.
It should be sufficient for most usages, and special usages will use external storages (as the potential future messaging, where only a hash will be stored in the blockchain, and the message will be temporary) and tricks like the import field and split values.