Poll On New Value Field Size

[domob]

So I'm late to this thread... but I think we're doing things in the wrong order.

1. If we can figure out encryption properly, then illegal content becomes a nonissue.
2. If we don't do encryption and don't restrict value formats, then files spanning multiple names become immediately problematic. (Don't believe me? Ask me on the Bitmessage list.)
3. If we restrict value formats, then we have effectively made ourselves the censors of the Namecoin network, regarding what kind of data can be used. I don't want to ask an authority for permission to make a new format; beta testing stuff would become impossible. Do you want a hardfork after every d/ or id/ spec change? It's completely unworkable.

Seriously, let's try to come up with a workable encryption proposal. There has been good progress on this. If this works, then we can go to 9KiB or above with no issues whatsoever IMHO. If it doesn't, I think it's safe to say we're fucked anyway.

This! I'm all for encryption and against restrictions (apart from that, restrictions can always be circumvented - in the "worst case", at least in theory you can store arbitrary data even in IP addresses some domains resolve to!).

[khal]

Namecoin is a public key/value storage with the ability to list existing names.

Having an index of existing names allows a lot of things that are not yet very used due to the youth of namecoin and its only 2 used namespaces.

Here is what having a public key index permits (https://dot-bit.org/Use_cases) :
- decentralized global information directories
- making search engines, adapted for each namespace (domains, bonds, shares, titles and deeds, etc)
- a public market with buyers/sellers of names (done by analyzing content of value) (can be useful for every namespace too)
- a faster namecoin (on blockchain download & name retrieval)

People now use fiber channels & FHD TV (even 4k screens...). So, seriously, is several kB of data something interesting ?

Also, encryption is not the ultimate solution to be protected from malicious persons.

Because any legal entity can accuse you with something like "you facilitate exchange of CP by making it more difficult to identify it by using encryption".
Is some random binary data split in several names really a more dangerous thing ?
Depending on the place you live, it may even be worse for you to hide things.

If you don't want things in clear on your hard drive, you should encrypt the whole blockchain files (it could be an option proposed by namecoin ?).


Instead, try to make unwanted usages less interesting than in other softwares and people will prefer to go away.

Generic restrictions on name contents (there, I do not mean we implement a check of specs for each namespace, only generic binary data detection or things like that) are not proposed as an ultimate solution, but as a way to limit the available size for binary data. For ex, a 2k field would not allow 2k of binary data, even if you try to encode it in a way to try to get around the restrictions (your [extreme] IP exemple contains 4 bytes of useful data in 15 bytes). Same for adjusted cost depending on value content/size.

Trying to combine several things will make usage of binary data more expensive, more painful to use and more slow (more names needed).

People will need this index, even if we remove it. They'll try to add another layer or use an external thing and, if successful, the index will be back... and you are back were you were before...
Without its index, namecoin lose a big part of its value and simplicity of usage.

[indolering]

I stumbled across some warnings on maximum packet sizes for DNS and latency when looking into DNS some literature on DNSCurve:

1280-1500 MTU (average to maximum for Ethernet v2)

ipv6 header - 40 bytes
tcp header - 20 bytes
PPOE et. al - 8 bytes

1211-1432 bytes per packet before we hit packet fragmentation and the obvious latency issues associate with it. I'm also not factoring in any potential overhead associated with the lite-weight client protocols or web APIs.

Why don't we keep size restrictions on d/ ? If other namespaces want to use a larger size they can do so without threatening d/.

[virtual_master]

Some new coins are not limited at all by fears connected with the value-field size or content type.
Datacoin with unlimited value size and and the coming, a little bit futuristic Ethereum with Turing complete scripting language.
I am not sure if they are not exaggerating but we should also go forward step by step at least that we can implement some realistic applications without being excessively hampered.

[phelix]

I worry that the indexing possibilities might be limited by spam entries or shock entries or good looking entries that lead to shock results.

Because any legal entity can accuse you with something like "you facilitate exchange of CP by making it more difficult to identify it by using encryption".

This is a good argument.

I stumbled across some warnings on maximum packet sizes for DNS and latency when looking into DNS some literature on DNSCurve:

1280-1500 MTU (average to maximum for Ethernet v2)

ipv6 header - 40 bytes
tcp header - 20 bytes
PPOE et. al - 8 bytes

1211-1432 bytes per packet before we hit packet fragmentation and the obvious latency issues associate with it. I'm also not factoring in any potential overhead associated with the lite-weight client protocols or web APIs.

Why don't we keep size restrictions on d/ ? If other namespaces want to use a larger size they can do so without threatening d/.

This is a non-issue IMHO as you don't have to use the full size. d/ entries will still be small.

(1280 - 40) * 2 = 2480

Some new coins are not limited at all by fears connected with the value-field size or content type.
Datacoin with unlimited value size and and the coming, a little bit futuristic Ethereum with Turing complete scripting language.
I am not sure if they are not exaggerating but we should also go forward step by step at least that we can implement some realistic applications without being excessively hampered.

Sometimes I wonder if humanity is ready for this. We will find out...