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

[Christian Grothoff]

I think this one was again eaten by mailman.

----------  Forwarded Message  ----------

Subject: Re: [GNUnet-developers] Re: amortizable hashcash paper
Date: Fri,  9 May 2003 09:20:15 -0700
From: "January" <address@hidden>
To: address@hidden, address@hidden
Cc: address@hidden, address@hidden

Igor's sketch of a trusted moderator system corresponds to
thoughts I've had myself.

If the "vote" was decoupled from the content, and just referenced
the content, you could then also have the vote reference a
pseudo-id.  This could allow nodes to do the economic thing and
credit pseudo-id's that vote for the same content that the
local user votes for.  Over time, the node "learns" the preferences
of the user.  The more they moderate, the more they get filtering
or sorting that accurately reflects their own interests,
which is a good thing.  There's a positive feedback loop, and
spamming is avoided.

I'm assuming that voting would be done manually and deliberately
by the user, not automatically, and that they could do unfiltered/
unsorted searches.

The problem I see here is that I don't know how to do this without
it being darned heavy on the network usage, so nodes that make
use of this would be heavily penalized, economically.

But Igor makes an excellent point that the unvarnished hashcash
system DEPENDS upon attackers having less CPU than legitimate
voters.  I think Igor is correct that in fact, the converse is
true.

ps:
 I expect this is going to get bounced by the gnunet-developers
 list, so if it does, I'd be grateful if either Igor or Adam
 would be kind enough to forward it.

On Thu, 08 May 2003 06:29:56 -0700 Igor Wronsky
 <address@hidden>

wrote:
>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
>
>_______________________________________________
>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

-------------------------------------------------------