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

[Igor Wronsky]

On Sun, 26 Jan 2003, Christian Grothoff wrote:

> 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.

What makes you think a malicious node, in the old proposal, couldn't just
flatly refuse to transfer arbitrary blocks w.r.t the defined geometric
function and increment, which can be assumed to be known to anybody who
wants to attack the particular entry point? Then the user, though he could
know that what he's got is not the latest (possibly having to revert to an
old version), but he still couldn't know if a later edition has been
published - the author could've been shot, the network can have been
split, or the nodes can refuse to transfer the data for reason or
another. Primarily, there's no guarantee anyway of availability, only of
validity, when we get the data. If, on the other hand, the new style
was used, the blocks could always be allowed to be timestamped (perhaps
only roughly, and/or allowing the author to fake the dates), so the user
could measure if the edition he gets is recent or not. The author
could cheat, yes, but so he can insert future editions beforehand.
Also, the timestamping wouldn't be much of a problem, it could
be something on the lines of 'posted on week 42' or 'next
edition expected in january', and the reliability of the timestamp
would be measured by users personal trust on that pseudonym
who has done the signing.

So the answer to your question is that no, the user can't
exactly know, but how tragic is that? Timestamping could give
some measure, and the malicious nodes couldn't gain more
than 'unit of credit' by this mechanism per a node requesting
the entry point: once user gets edition i, he starts requesting
with #serial>=i+1, where only valid matches are those newer than
the edition he's already got. Incorrect answers can naturally
be discarded and not awarded any trust. And we assume that
the nodes can not forge the serials. Thus a malicious node
can cheat only once. I assume here that the client software
can keep on looking for a newer version and perhaps replacing
the shown content on the fly, until user tells it to stop looking.

Ok, that was mostly thinking aloud too, but the purpose here imo
is to get the thoughts and arguments honed to a good
proposition that is worth implementation and doesn't have
to be radically tweaked after its there.

> 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?

I didn't say we'd have to remove the other options. I'm just
noticing that many publishers might not feel comfortable being
forced to regular updating and that we could/should have a
simple, transparent, perhaps a bit less secure alternative. Also,
different types pointers could be published to the same content,
say the publisher first thinks he'll do periodicals (a
geometric query works well), then he gets bored (a rewriting
mechanism gives the most recent, because periodic insert
hasn't been done, and the resp. query can't work), gets
active again, etc...


Igor