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

[Igor Wronsky]

On Thu, 8 May 2003, Adam Back wrote:

Perhaps I'm missing something, but the whole discussion below
reminds me of giving in to the tyranny of democracy, i.e.
allowing the majority to decide what is ok. The philosophy
behind gnunet - if I got it right - seemed to strive for something
like that the nodes appreciating The Kitten Collection would naturally
form an economic clique helping out each other but also occasionally
transferring something for 'other' nodes, if capacity permits. Global
ranking of content (or anonymous free-for-all voting) seems to go
against this. Hashcash doesn't seem to help either, if zealots
are willing to use cpu cycles in going against something particular.

Of course, if you are trying to do app-level spam prevention by
global voting, that might be fine, but it sounds suspicious if its
used at the block level where nodes decide about storing and forwarding
content. But even on the app-level some kind of locality or nonanonymous
voting and pseudonym ranking might be required, to thwart hostile,
possibly bigger user groups from taking over. And for just content
sharing, if the namespace scheme is implemented, the need for
spam prevention lessens, as people naturally learn to trust
pseudonyms they like, and the pseudonyms control their own "turf",
disabling spamming altogether. And finally, I didn't sleep
much last night. ;)


Igor


> 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
>
>
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnunet-developers
>