Re: [GNUnet-developers] Another bunch of ideas

[Steven Barker]

On Mon, Jul 14, 2003 at 07:33:23PM +0300, Igor Wronsky wrote:

> Ok, I'm perhaps the most pessimistic and simple-minded of the
> whole bunch, but here goes anyway... don't let these little
> comments depress you. ;)

I won't.  I think I've addressed all of your concerns below, but
even if not, I like debate, even when I'm wrong. :-)

> On Mon, 14 Jul 2003, Steven Barker wrote:

> > * Challenge-Response-Confirmation support in the trust economics code.

> In my limited understanding this method seems to be just as fragile
> as any voting scheme (pardon me if the contrary was shown by your
> credit-assignment scenario, I didn't read it with my brains on)
> against 'tyranny of the masses'. That is, there is likely exist
> such content in the anonymous system that is disliked by majority
> or by a very resourceful (as in $$$) faction. Now the these
> parties could use their resources to thwart the unwanted
> content by inducing an order or ranking on the content matching
> some particular key, in a way that the real content was always
> at the bottom of that ranking (risking filtering etc), and
> spam being at the top.

Well, as applied to AFS, I think a Confirmtion based keyword search
could be done safely.  A Response that the searcher thinks was bogus
would not be cached by the nodes that passed it along, however, it
shouldn't be penalized by the node that already had it.  That node would
simply decide behave as if it had never seen the request.  This means
that unpopular data doesn't spread itself around the network unless some
nodes invest the trust others have in them to request it and confirm it
as good.  This makes spamming keywords much more dificult, as you will
have to repeatedly request and confirm the spam data in order to keep it
in the network.  Doing so abusively will lose you whatever trust you
have from your neighbors, preventing you doing too much damage.

> If, on the other hand, the weight or reliability of the
> confirmation was calculated against the reputation of
> the confirming party, there might be something there. That
> is, if node A knows B and C to be 'baddies', and D a
> goodie (relative, of course), then their confirmation
> weights could be ranked somehow accordingly. Or
> instead of nodes, maybe app level pseudonyms could
> be used.

Well, the priority of a Response message would be clamped at the
trust value of it's reciepient (because you charge them an "insurance"
fee until the confirmation comes in).  There's also the fact that a
responder accused of sending bogus data cannot lose more trust than
the requester spent to make the request in the first place (since the
priority of a Response will always be less than the priority of the
Challenge it's replying to).

> I don't claim it to be this simple. ;) But certainly
> thinking every confirmation as equal leads into trouble.

Hmm, it's not directly in response to your statement here, but your
language made me think of it:  it would be valuable to have a neutral
Confirmation, that says that a Response was not valid, but that it
wasn't fraudulent either. The nodes that got one of those would then
repay the charge levied against the sender of the Response but not
credit them with trust based on the Challenge.

> > Now that A has the data it requested, it has to evalueate it.  This could be
> > an automatic, application specific check (like, for example, determining if
> > data is signed by a trusted identity),
> 
> Once the namespace mechanism is ready, it will handle the
> signature issue without voting or confirmations. In a namespace,
> everything is in a way 'signed' (transitively, at least),
> though 'trust' only exists in the minds eye of the end
> user. Spamming can not happen in namespaces except when
> intended by the author who signed (owner of the space).
> Unfortunately this still leaves the problem of where to
> get good 'entry points'.

Yes, SSK's are good.  But what I was thinking of was how to make a
PGP style web-of-trust thing, where you have identities (keys)
signing each other.  The user would specify one or more identities
that are ultimately trusted, and varying degrees of trust in other
known identities.  The results of a keyword search would then be
checked against that identity trust database to decide if a given
result has short enough trust path to be assumed to be valid or not
(there could be other sophisticated application-level stuff in there
too, like automatic searches for signatures on unknown identities).
SSK's would be enough to hide keyword hits created by untrusted
identities from the user, but they can't prevent them from
propagating in the network.

In fact, since a lot of other applications could benefit from it, I
think an application to manage this distributed trust network would
be extremely valuable.

> > * An Anonymous Distributed Computing framework.

> You're careful leaving out what you'd use anonymous
> distributed computation for. I think we'd be in for
> trouble if, for example, there was a site claiming
> 'join the happy adventure of risk-free credit card
> hacking and get 1/n of the profit!'. I mean, a p2p
> concept can attack the profit margins of individual branches
> of the industry, like the music industry, and maybe
> get away with it on a free-speech excuse or such,
> but if a p2p system enables you to attack economy or
> banking (i.e. perform an "anarcho-communist assault
> on our Capitalist Values, Country and GOD"), the big
> brothers will pull down the whole network in a jiffy.
> Only numbers could save you then, but we'd probably be
> talking about hundreds of thousands of international
> nodes - or more.

Well, my gnunet application would actually only be a framework for
distributed computing.  The distributed jobs themselves would be
submitted anonymously by the users of the network.  :-)

Still, you're right that creating this kind of application would make
us unpopular with a lot of institutions (the IRS, Banks, the military,
etc).  However, I imagine this is only a difference in degree from
the upset applications like AFS are already causing among other
institutions (Holywood, the RIAA, etc).

As an interim measure, the application could require that every
Distributed Computing request be signed, so that node operators
could pick and choose what projects to work on (i.e. "I'll do SETI,
but not credit card cracking", or "I'll do protien folding but not
nuclear weapon test simulation").  We may want this anyway because
making a genuinely tamperproof sandbox to run random code in is
probably not the easiest thing to do.

Of course, some nodes still might do stuff things that others won't
want them to do, but that "comes with the territory" of freedom.  :-p

-- 
Steven Barker                                      address@hidden
  Alaska:
        A prelude to "No."
Get my GnuPG public key at: http://www.blckknght.org/publickey.asc
Fingerprint: 272A 3EC8 52CE F22B F745  775E 5292 F743 EBD5 936B

pgpFok5G7i5fR.pgp
Description: PGP signature