gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] Re: amortizable hashcash paper


From: Adam Back
Subject: Re: [GNUnet-developers] Re: amortizable hashcash paper
Date: Thu, 8 May 2003 01:23:01 +0100
User-agent: Mutt/1.2.2i

Could you separate the votes from the content?  ie Just pass around
yes and no votes for content based on the gnuNet unique document id.
The mechanism for passing the votes around then may be a field in
search terms, RBlocks or whatever unit is typically communicated, but
would bear no particular relationship to the payload it piggybacked
on.

Then perhaps you can achieve enough propogation to get an estimate for
document popularity (yes votes) and unpolularity (no votes).  To vote
on something normally you'd have to obtain the content to form an
opinion on whether it should be voted against, so I think there would
be a systemic bias against no votes compared to yes votes, because no
voted content would be less available.

The remaining concern would be whether DoS-attackers would try to vote
no for good content and yes for junk content.  Both are DoS attacks,
but I think the amortizable hashcash model has to be that it works as
long as the good behaving users have more CPU than the attackers.

You might also choose to force an attacker to at least have examined
the node he is voting against by using hash of hash or similar
technique to force download to discover the authenticator for the
data.

(Forgive abuse of gnuNET terms -- I am not as up to speed on the
terminology and low level details yet).

Adam

On Tue, May 06, 2003 at 04:50:45PM -0500, Christian Grothoff wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I don't think "no" can be used for spam-control since the message would be 
> delivered to too many people before the 'no' could possibly come into effect.
> 
> On peers suppressing "no" votes, I think I should reformulate a bit. Bad 
> peers 
> can not suppress "yes" votes since the other peers would accumulate the best
> votes, the malicious peers would just slow down the "counting" process.  In 
> the case of "no" votes, this would also apply, but the real problem is that 
> even the good peers would probably tend to *discard* content that has been 
> voted against a lot. Since the bad guys would discard "no" votes and the good 
> guys would discard the whole RBlock, "no"s would never really spread (unless 
> we decide to keep the RBlocks for the useless content anyway, but I'd rather
> just discard content that has had few votes and only keep the good content).
> 
> Does this help? Other opinions?
> 
> Christian
> 
> On Tuesday 06 May 2003 04:29 pm, January wrote:
> > Isn't a "no" vote capability important for building a
> > spam control (malicious content) system?  And can't a
> > malicious host discard  "yes" votes as easily as
> > dicarding "no" votes if they are interested in suppressing
> > content?
> >
> >
> > On Tue, 06 May 2003 11:13:31 -0700 Christian Grothoff
> > <address@hidden>
> >
> > wrote:
> > >-----BEGIN PGP SIGNED MESSAGE-----
> > >Hash: SHA1
> > >
> > >On Tuesday 06 May 2003 12:30 pm, you wrote:
> > >> This may seem like a silly question, but for the gnunet
> > >> "popularity rating" implimented with the hash thing, will
> > >> users be able to rate entries negatively as well as positively?
> > >> I do hope the answer is "yes".
> > >
> > >Well, as far as I can tell, the answer would be "no", because that way,
> > >
> > >malicious peers can not just 'discard' "no" votes (and they are
> > >computationally bounded in the amount of "yes" votes they can 'forge').
> > >But you have an implicit "no": the content that did not get many 'yes'
> > >votes. I believe that this will be sufficient if we make voting *easy*
> >
> > such
> >
> > >that people actually do it ...
> > >
> > >Christian
> > >-----BEGIN PGP SIGNATURE-----
> > >Version: GnuPG v1.0.6 (GNU/Linux)
> > >Comment: For info see http://www.gnupg.org
> > >
> > >iD8DBQE+t/tL9tNtMeXQLkIRAiCSAJ45qlLpxB+Udd3iTDtPtIhLVMbDYACfTBgM
> > >ENssuJ1SKhU90BYSy1swjbg=
> > >=JDir
> > >-----END PGP SIGNATURE-----
> > >
> > >
> > >
> > >_______________________________________________
> > >GNUnet-developers mailing list
> > >address@hidden
> > >http://mail.gnu.org/mailman/listinfo/gnunet-developers
> >
> > Concerned about your privacy? Follow this link to get
> > FREE encrypted email: https://www.hushmail.com/?l=2
> >
> > Free, ultra-private instant messaging with Hush Messenger
> > https://www.hushmail.com/services.php?subloc=messenger&l=434
> >
> > Big $$$ to be made with the HushMail Affiliate Program:
> > https://www.hushmail.com/about.php?subloc=affiliate&l=427
> - -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE+uCqT9tNtMeXQLkIRAiGfAJ9DYfiUgws+jJkyilQImLdxT6ZaNgCdEnJf
> 90jEVdGkTbMTESC6leEJypU=
> =Zh6k
> - -----END PGP SIGNATURE-----
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE+uC429tNtMeXQLkIRAuooAJ9FRDIDYBgLBQc7iaTIIgauKH2Q1QCfamYu
> Z0QMMO69hyfJUdpKXd9dzko=
> =JbI9
> -----END PGP SIGNATURE-----
> 
> 
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnunet-developers




reply via email to

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