Re: [GNUnet-developers] Other way to updateable content

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Let me think aloud here. The 'if the secret key of the author is leaked, bad 
people can censor the content by putting in bad information instead' is true 
but not really a concern, we should really be able to assert that the secret 
key is never exposed. So as long as the serial number is part of the 
cryptographically signed part of the block, it can not be tampered with.

A more major problem with these 'arbitrary' updates is that how would a peer 
know that he actually got "the latest" version from the network? If I get 
version 4, how can I be sure that there is no version 235252 out there? How 
do you ensure that malicious peers actually do the update and do not keep old 
versions around and forward those? The existing proposal gives you the 
guarantee that you get any one version of the content and can from there 
compute (!) the version that will be the latest at any given time in the 
future, and nobody can cheat. 

Thus the existing proposal is much better for periodically updated content. It 
may be worse of irregularly updated content with "weak" security requirements 
because it forces the author to re-publish an update in every period to keep 
the content available at all times and it is impossible to publish updates at 
points in time where no update is scheduled.

But why could we not have both? One mechanism where the updates are 
periodically and deterministic and where it is clear which version is the 
current one (and where, btw, previous revisions are also always accessible) 
and another where there is an 'overwrite old' mechanism that allows the 
author to replace old blocks with new blocks but which has weaker consistency 
guarantees (the update may not propagate everywhere, users may get an 
out-of-date version even if a more recent version is available on the 
network).

Sounds reasonable?

Christian

On Sunday 26 January 2003 11:31 am, Igor Wronsky wrote:
> Ok, while taking a shower I came up with a simpler scheme for
> allowing updateable content. Some of you will probably scream
> "noo!!!!", but please read my whole argument.
>
> The main idea is very simple: let us allow rewriting of the
> entry point - and nothing else. Have a special block like
> (namespace,pointer_to_actual_data,serial#,signature).
> When wanting to modify something, increment serial# and change
> pointer_to_actual_data. Insert actual data and the new
> entry point. When searching, do query like query(namespace,
> serial#>=wanted). When node gets this query, it'll look
> if local data store has anything matching the requirements.
> If yes, it will return the data AND forward the query,
> this time requiring serial#>localserial#. If not, just
> forward as-is. When receiving data from some other node,
> the signature is checked, if it matches, write to disk,
> overwriting everything with serial# less than this, and
> send reply to whoever originally requested.
>
> There might be technical problems, but the main problem
> people will see, is political, mainly censorship: what if a nasty
> person gets hold of the secret key and tampers with the entry
> point? I have two answers. First: no actual content can be
> censored even if this is allowed. Anyone can have linked to the
> content, or made a list of their hashes someplace. Second: the
> tampering is already possible in edition-based mechanism,
> in a way that we can't trust anything except the "first edition"
> to come from the original author. And in addition, note
> that we are not *forcing* anyone to use a rewritable entry-
> point. Someone w/ ultraparanoia on can always insert
> a "perpetual" entry point pointing to some fixed data.
>
> The gain of this method is very simple: the author can
> publish the modifications whenever he likes, the modded
> entry point replaces the old ones automatically, and
> this can be done quite transparent to the end user
> (except maybe with some "hey I found a even more recent
> version" -interruptions).
>
> Also this can probably be integrated easily to the current
> namespace proposal without requirement for a new block type,
> a flag (bool rewritable) probably suffices.
>
> Comments?
>
>
> ps. Christian, you sounded mildly sceptical of the fproxy
> issue. However, such a scheme is quite popular in freenet,
> and gives it atleast some community feeling. If gnunet
> can be competitive with freenet in transferring raw
> data, there is no reason why the fproxy wouldn't work
> as good or better in gnunet env.
>
>
> Igor
>
>
>
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnunet-developers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+NGhr9tNtMeXQLkIRAtvJAJ90ZpQdD/JGaKwmdsfdC3AdjdqkfwCdFsGJ
BmuNnQ1WyWo2m43aPCn2PJg=
=z4+M
-----END PGP SIGNATURE-----