[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] update mechanism

From: Christian Grothoff
Subject: Re: [GNUnet-developers] update mechanism
Date: Sat, 17 Aug 2002 15:21:55 -0500
User-agent: KMail/1.4.1

Hash: SHA1

On Saturday 17 August 2002 07:25 am, Martin Uecker wrote:
> > | I can see some use for this. An update could be implemented by simply
> > | defining another root-node R type that carries an signature from
> > | the originator (say S_A(R)). The originator can then send an update
> > | request using the key for the root-node (single-hash, not double or
> > | triple-hash), T, the public key A and a signed new replacement block
> > | R' which points to the updated file. We'll also want to add a timestamp
> > | to ensure that we update in the right direction.
> > | Still, how do you force a node to perform the potentially expensive
> > | update operation (find block, verify sig, replace), how do you ensure
> > | that the updates are propagated sufficiently long in GNUnet to reach
> > | everybody but not too long? What is the (economic) incentive in doing
> > | the update? The receiver could just add (keeping R and R') to its
> > | set of keys and now have 2 replies to send as replies to a request.
> The client can discard the old version if it recieves both as search
> results. The reciever has an economic interest to not recieve stale
> data.  He might adjust the reputation of the sender accordingly.

So what this would rather boil down to is that the client can identify RNodes 
that originate from the same author (pseudonym) and can distinguish versions 
and decide to take the most recent version. That's fine - and it wouldn't 
even require an extention to the protocol to tell everybody to remove the old
content, it would be a decision of the client not to download the (outdated) 


Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


reply via email to

[Prev in Thread] Current Thread [Next in Thread]