New size of the value field

[phelix]

http://dot-bit.org/forum/viewtopic.php?f=2&t=503 Increasing the size of the value field

Currently the size of the value field is limited to 520 characters for name_upate, ~1020 for name_firstupdate. There is an unintentional restriction (bug) in name_update.

When we fix this bug we might as well further increase the size of the value field.

Please note this does not increase the danger of spamming/flooding the networks or blocks because the fees will be structured in a way such that one large TX will be more expensive than two small TXs.

Khal's suggestion was 9k to let gpg keys fit. Maybe there are other ways by linking to gpg keys or people only use Bitmessage and the like by now. Still, a larger value size might even save the network room as there will have to be fewer "import" statements (which cause an overhead of ~500 bytes for a second TX I guess - from this guess it would today take about 17k to store 9k of value data).

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

We need to find consensus about the new size. I think Khal's suggestion still makes sense. If you think otherwise please explain why.


Previous opinions and concerns:

The issue 3 will need an update of all namecoin clients to be fixed.

Due to this bug, a name_update will fail if previous name_update or name_firstupdate used a value with more than 520 characters. Yes, you read it right...

So, I think we should "benefit" from this forced upgrade to increase the maximum number of characters for the value field, because we already need a general upgrade.

Why ?
Some possible namecoin usages are already limited by this, like GPG. See https://dot-bit.org/Personal_Namespace#Notes.
Other

Is it dangerous for the network ?
Each transaction above 1K will always have fee, for each 1K of data. If fees are set to the right value, they will do their job.
Each transaction above 10K will be rejected (another network rules).

How many characters ?
I propose to set it to 9000 characters max to allow 8k gpg keys with some other data.

What do you think ?

For the record, I think enlarging the data field limit by 20 times is a bad idea.

I'm also not sure about 9k - what about fixing the bug so that we end up with the originally planned 1k? (And of course introduce graceful failing for larger values instead of the current behaviour of silently being stuck.) What are the applications you have in mind for 9k were 1k is too little?

I agree with you. It would be the best solution.
1k would be enough at the moment.
As far as I know nobody complained even the 500 byte limit.

[virtual_master]

Back to Khals proposal of 9k size.
This is probably based on the considerations over the 1k gpg key which may become less secure beyond 2015.
http://www.debian-administration.org/us ... /weblog/48
'The Digital Signature Algorithm, in its original form, only allowed maximum 1024-bit asymmetric keys, and the signature process itself signs a 160-bit hash, initially officially specified as SHA-1. This means that 1024-bit DSA keys should be phased out as well. '

My comments to this:
- we are still not in 2015
- the DSA only allowed maximum 1024-bit asymmetric keys as in the document
- there is a proposition for a migration process which could be for a 2k key size also
- standard GPG actually doesn't even support key size>4k
- increasing the size for a presumable future GPG key standard we would open now only to spam in the blockchain for an uncontrolled content

Let us make a reasonable compromise and make place for 2k field size (1k standard gpg key) but for increasing fee with higher amount of data.
Then the actual established gpg standard of 1024 bit key can be full supported in the value field. When it will be more clear which new gpg standard will establish then we can discuss it again.
----------
Or what about a 2.5k field size ? Then there will be even place for the actually proposed 2048 bit DSA/RSA key size and that will be secure enough for the next 10 years if the quantum computers will be not developed.

[phelix]

- increasing the size for a presumable future GPG key standard we would open now only to spam in the blockchain for an uncontrolled content

Spam is not an issue here. Spamming would be cheaper with small TXs.

[jdbtracker]

I agree... time for some change. so how do we vote for this?

[moa]

We have bigger problems than going off on a tangent with value field size changes .... e.g. rebasing on bitcoin is one big reason.

[jdbtracker]

We have bigger problems than going off on a tangent with value field size changes .... e.g. rebasing on bitcoin is one big reason.

what are the problems, what needs to be fixed in your opinion?

[moa]

We have bigger problems than going off on a tangent with value field size changes .... e.g. rebasing on bitcoin is one big reason.

what are the problems, what needs to be fixed in your opinion?

e.g. rebasing on bitcoin is one big reason.

[virtual_master]

We have bigger problems than going off on a tangent with value field size changes .... e.g. rebasing on bitcoin is one big reason.

what are the problems, what needs to be fixed in your opinion?

e.g. rebasing on bitcoin is one big reason.

I don't think it is helpful to block discussions now in any Namecoin related topic with the hint that rebase is more important.
Some topics can be more important some are less important, but generally importance is a subjective characteristic.
If Phelix dedicated this thread to the less important topic of 'New size of the value field' then we should respect his wish and we shouldn't hijack it from the topic.
Here is the rebase thread:
http://dot-bit.org/forum/viewtopic.php?f=5&t=1009
-----------
So what speaks for a specific value field size and what against it ?

[GiToo]

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 ?

[phelix]

cross post:

Hi.
I reconsidered my point of view based mainly on retroshare id integration possibility and I consider now 5k value field size instead of the actual 0.5k to be OK (this would allow to integrate maximum sized 4096 bit gpg keys based on the actual gpg standard which is after all security experts at least until 2020 secure).

ok. I'm not at all fixated on 9k it's just that Khal said gpg keys could be up to 8k and I don't see any issues with 9k.

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.