Poll On New Value Field Size

How large should the value field be?

1k
6
38%
2k
1
6%
2.5k
2
13%
3k
1
6%
4k
0
No votes
5k
6
38%
6k
0
No votes
 
Total votes: 16

midnightmagic
Posts: 18
Joined: Tue Sep 13, 2011 6:50 am

Re: Poll On New Value Field Size

Post by midnightmagic »

indolering wrote:Then I think about paying $50 for 1KB of storage per a year and I question whether I should get a prescription for some anti-anxiety meds [3]. In the end I think we need to work out a way to tailor pricing, size, renewal intervals, and field content to each namespaces needs. For example, we could cap d/ at 1KB and $25-$50 with yearly renewals, metalink/ at 10KB and $0.001 1-10/year and id/ at 100KB and $1/10-50 year intervals. We could also tune bulk (gigabyte) storage using probabilistic techniques so no miner would hold an entire record and clients would have to contact multiple miners to retrieve it, increasing public accountability for looking at that information.
There is absolutely no way to have the price of namecoins rely on the human world of USD-related fiat currency without introducing/handing over complete, arbitrary control of costs to some human individual somewhere who can control the input of that data into the system.

The only thing we can do is price it in internal mechanisms, and make a human guess as to the various costs involved based on, say, ASIC manufacturing costs for Bitcoin-related hardware.

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Poll On New Value Field Size

Post by virtual_master »

khal wrote:There are some other possibilities we can investigate to limit bad content in namecoin (except for the size of the field) :
Let us see the possibilities.
1.
khal wrote: * find the magic formula for the price of a name (not too cheap, not too expensive)
Of course. I will come back to this by the fees thread.
2.
khal wrote: * do a generic analysis of the content of the field :
- I do not want to force some spec/formats in the blockchain, ex: restriting id/ to json, etc => bad idea. It is not the role of the blockchain.
- But we can define some general rules to avoid binary data only
ie: if size < 1k & more than 50% binary data => rejected by the blockchain
ie: if size > 1k & everything is binary => rejected by the blockchain

* Binary data can cost more
How do you want to check if it is binary data and not a Unicode text ?
And how do you want to check the percentage of a value entry ?
This is possible in a file system or in a usual database if the property of the data is set correctly or there is a header which identifies it. Otherwise I don't know how could work.
If it would work then there would be no virus in .txt file which is not detected by the best virus scanners.

3.
Compression/decompression is trivial as an alone standing program but:
- the RSA/DSA key must be in a specific format to work optimal
- to be automatically enforced every specific key must be recognizable (for ex the value fields must have the same name)
- to encode in a special environment could be eventually a little bit more difficult because any attack factor must be avoided in the client

4.
We should avoid another confusion.
We are speaking about the size of the value field or about the size of a name entry(which has more value fiels) ?

5.
Of course a picture can be inserted even in 0.5KB.
But what is the quality ?
Why should somebody look on pictures of 5KB ? (when adult sites are giving free picture samples of 1 MB and 20 MB if payed - and on tor that could be any kind of picture)
And how should somebody look on it ? By writing a special software for the purpose to extract and visualize his own 5KB pictures from the blockchain ? This is absurd as user case(only to compromise the blockchain can have its purpose - and knowing this has lost his attack value).

6.
Even if we would reduce the size of the value field and name entry to less then Bitcoin a much bigger picture can be introduced in directly in the block(if somebody finds a block-a miner).
So the size of the value field could be as big as the block because there is not much difference.
Who wants to look the picture would require a special software. The standard client and block explorer doesn't support picture view from a value field or from the blockchain.
A text in the value field could however have some low quality obscene pictures as text-pictures which is shown in the block-explorer. This could be worse if the size is increasing - but could be solved also with encryption.
But I don't think under 4-5k this would be a problem even without encryption.

7.
But let us be really carefully and we should go for sure and increase in two steps.
- this year we could increase to 2-2.5 KB
- in 1/2 year or 1 year to 4-5 KB if they are no problems
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Poll On New Value Field Size

Post by phelix »

virtual_master wrote: But let us be really carefully and we should go for sure and increase in two steps.
- this year we could increase to 2-2.5 KB
- in 1/2 year or 1 year to 4-5 KB if they are no problems
sounds like a good plan to me

current poll average is 2.85kb :mrgreen:
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

indolering
Posts: 800
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: Poll On New Value Field Size

Post by indolering »

phelix wrote:
virtual_master wrote: But let us be really carefully and we should go for sure and increase in two steps.
- this year we could increase to 2-2.5 KB
- in 1/2 year or 1 year to 4-5 KB if they are no problems
sounds like a good plan to me

current poll average is 2.85kb :mrgreen:
I misunderstood Ryan-c in a prior conversation, I though the additional bloat was due to confirmation signatures. That was incorrect,
ryan-c wrote:It's actually 2.5KB MINIMUM plus metadata. Each key has an identity key (512 bytes + a 512 byte self signature) and at least one sub key (512 bytes + 512 byte self signature + 512 byte signature by identity key). Then there's other people's signtures, name/email address, expiration times, encryption algo prefs, photo (yes, a gpg key can include a photo) etc."
Ryan also walked me through field restrictions of which there are none for large keys: a malicious user can craft any public key they like. With key sizes that large there is no way to control what is placed in the blockchain. Anything above 300 bytes of unrestricted data and anyone can string together multiple domains and put in a high resolution video of anything they want.

So my vote is either keep the field content restricted to given parameters (hashes for keys, 4 octets for IPv4, valid URIs, etc) or bust : (
DNS is much more than a key->value datastore.

ryanc
Posts: 147
Joined: Wed Dec 18, 2013 8:10 pm
os: linux

Re: Poll On New Value Field Size

Post by ryanc »

Being able to put a full public key in the blockchain is an asinine use case.

1) PGP/GPG keyservers have been around forever - pgp.mit.edu and pool.sks-keyservers.net - and they work fine over Tor. Fingerprint is enough to get/verify the full key.

2) PGP/GPG keypairs are large and arbitrary data can trivially be embedded within them.

3) Even if you filter the fields (which then requires them to be validated as part of block checking and makes adding new protocols to PGP/GPG keys a hard fork event), I can still put up to ~500 bytes in each RSA modulus by maliciously choosing my primes.

domob
Posts: 1127
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Poll On New Value Field Size

Post by domob »

ryanc wrote:Being able to put a full public key in the blockchain is an asinine use case.

1) PGP/GPG keyservers have been around forever - pgp.mit.edu and pool.sks-keyservers.net - and they work fine over Tor. Fingerprint is enough to get/verify the full key.

2) PGP/GPG keypairs are large and arbitrary data can trivially be embedded within them.

3) Even if you filter the fields (which then requires them to be validated as part of block checking and makes adding new protocols to PGP/GPG keys a hard fork event), I can still put up to ~500 bytes in each RSA modulus by maliciously choosing my primes.
I agree, I don't really see the need for full keys. Speaking of 2: You can even embed images in GPG keys (and have them viewed by standard GPG tools) - more fuel for the discussion about possibly illegal pictures in the blockchain.... ;)
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Poll On New Value Field Size

Post by phelix »

a retroshare key is about 900bytes... I don't know of any servers for these
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

ryanc
Posts: 147
Joined: Wed Dec 18, 2013 8:10 pm
os: linux

Re: Poll On New Value Field Size

Post by ryanc »

phelix wrote:a retroshare key is about 900bytes... I don't know of any servers for these
Are these RSA keys?

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Poll On New Value Field Size

Post by phelix »

ryanc wrote:
phelix wrote:a retroshare key is about 900bytes... I don't know of any servers for these
Are these RSA keys?
tbh I have no idea :D
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Poll On New Value Field Size

Post by biolizard89 »

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.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply