Namecoin Forum

There is no upper bound on the size of PGP/GPG keys. Keys with many signatures can be upwards of 100KB.

ryanc wrote:There is no upper bound on the size of PGP/GPG keys. Keys with many signatures can be upwards of 100KB.

Thanks for the info ryanc.

Based on virtual_master calcs, we can say that a standard key will fit in 2k field (1k for the key max & 1k for other data for ex), and keys with several signatures won't. Using an external file for big keys makes sense, as it can go up to 100k.
Also, people can still include their key without the signatures I guess, to fit in the small field.

khal wrote:

ryanc wrote:There is no upper bound on the size of PGP/GPG keys. Keys with many signatures can be upwards of 100KB.

Thanks for the info ryanc.

Based on virtual_master calcs, we can say that a standard key will fit in 2k field (1k for the key max & 1k for other data for ex), and keys with several signatures won't. Using an external file for big keys makes sense, as it can go up to 100k.
Also, people can still include their key without the signatures I guess, to fit in the small field.

Additional confirmation signatures are unnecessary. VM is right, we can squeeze even the largest permissible keys into .5KB, which leaves plenty of room for a link to a larger key with signatures. I'm still wary of anything >1KB as the original analysis I did assumed that we could restrict the field sizes and compositions even further. So I don't know, I keep flip flopping between 1K and 2K.

I will redo that analysis this week/after I read ryan's field-restrictions and actually share it with everyone. I don't want to be the bottleneck here...

I changed the poll so that you can recast your vote (you can do that by editing the op). As it turns

Notes: The name length is always limited to 256bytes. The poll is about the value field size in kilo bytes.

For the encryption discussion please start another topic.

khal wrote:

ryanc wrote:There is no upper bound on the size of PGP/GPG keys. Keys with many signatures can be upwards of 100KB.

Thanks for the info ryanc.

Based on virtual_master calcs, we can say that a standard key will fit in 2k field (1k for the key max & 1k for other data for ex), and keys with several signatures won't. Using an external file for big keys makes sense, as it can go up to 100k.
Also, people can still include their key without the signatures I guess, to fit in the small field.

OK, we are making progress. The lower bound should be 1.5k for a plain gpg key.

Any strong opinions between 1.5 / 2 / 2.5 / 3 / ... kbytes? Is there an advantage to stick to whole kilobytes? Please recast your vote.

phelix wrote:I changed the poll so that you can recast your vote (you can do that by editing the op). As it turns

Notes: The name length is always limited to 256bytes. The poll is about the value field size in kilo bytes.

For the encryption discussion please start another topic.

khal wrote:

ryanc wrote:There is no upper bound on the size of PGP/GPG keys. Keys with many signatures can be upwards of 100KB.

Thanks for the info ryanc.

Based on virtual_master calcs, we can say that a standard key will fit in 2k field (1k for the key max & 1k for other data for ex), and keys with several signatures won't. Using an external file for big keys makes sense, as it can go up to 100k.
Also, people can still include their key without the signatures I guess, to fit in the small field.

OK, we are making progress. The lower bound should be 1.5k for a plain gpg key.

Any strong opinions between 1.5 / 2 / 2.5 / 3 / ... kbytes? Is there an advantage to stick to whole kilobytes? Please recast your vote.

Ugh, redid some of my image testing and "threat model" last night, definitely sticking to my 1KB maximum argument. You only need 2KB-4KB to seriously offend everyone. I will give a more formal analysis later.

We can stick the maximum sized 4kb PGP key into a 1KB record plus meta-data even if we encode the key in base-64.

I'm taking a hardline 1K max vote until we are established enough to have credibility with the outside world. Even then, we need per-field restrictions to stymie usenet-style record spanning.

phelix wrote:I changed the poll so that you can recast your vote (you can do that by editing the op).

I didn't want to use my admin rights when not required :p [phelix sayz: haha :p]

/me revoted [2k]

Yanked for security reasons.

We still need a comment from sugarpuf here then it will be the best thread.

There are some other possibilities we can investigate to limit bad content in namecoin (except for the size of the field) :

* find the magic formula for the price of a name (not too cheap, not too expensive)

* 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

So, make your choice and poll :p

ps : should we close the poll at the end of the month to avoid an infinite discussion ? :p

indolering wrote: I question whether I should get a prescription for some anti-anxiety meds

+1
This place is also recommended if you want to survive the zombie apocalypse: