Send Devl mailing list submissions to
devl at freenetproject.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.uprizer.com/mailman/listinfo/devl
or, via email, send a message with subject or body 'help' to
devl-request at freenetproject.org
You can reach the person managing the list at
devl-admin at freenetproject.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Devl digest..."
Today's Topics:
1. Re: Announcement Protocol (Scott G. Miller)
2. Re: Aardvark (Scott G. Miller)
3. lists.sourceforge.net mailing list memberships reminder (mailman-owner at
lists.sourceforge.net)
4. Re: Proposal: algorithm for forgetting documents in datastore (Tavin Cole)
--__--__--
Message: 1
Date: Thu, 1 Feb 2001 11:33:35 -0500
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Announcement Protocol
From: "Scott G. Miller" <[email protected]>
Reply-To: devl at freenetproject.org
--hQiwHBbRI9kgIhsi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Feb 01, 2001 at 10:05:34AM +0100, Ruediger Kapitza wrote:
> Hi!
> After reading the proposel there appeared some questions to me:
> First if I'm Alice I have to trust Bob1 fully. This means
> if he is the evil node then there is no chance.
Theres no way around this. If you cant connect to a trusted node, then
you are indeed fucked from the start. No amount of protocol wizardry can
fix that.
> Anyway if I'm Alice my Bob1 must be trusted because its a Ref form some
> friend or other trusted party.
> But even if Bob2 is the evil evil node up to 90% (or so) are special evil
> nodes for Alice later on. Of course for Bob3...N the amount of evil nodes
> gets smaller and smaller and there is no reason anymore.
Alice can detect evilness though. If Mallory acting as Bob2 completely
fabricates the nodes above him on the chain, Alice will find out when she
tries to retrieve the keys those fake nodes sent back. If they try and
forge the x values then that will be detected, again by Alice. In either
case she can re-announce. Because the routes are random, the chances of
encountering the same Bob2 the second time are 1 in the number of
references in Bob1's datastore.
--hQiwHBbRI9kgIhsi
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6eY/er9IW4v3mHtQRAkCJAJoCtMtB3sr/2tTB17XOYSkSpWlnCgCfe8tC
++Uyh9E5batWLvpa7haswB4=
=e+Vs
-----END PGP SIGNATURE-----
--hQiwHBbRI9kgIhsi--
--__--__--
Message: 2
Date: Thu, 1 Feb 2001 11:38:42 -0500
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Aardvark
From: "Scott G. Miller" <[email protected]>
Reply-To: devl at freenetproject.org
--5QAgd0e35j3NYeGe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
> An evil node can easily spoof a KSK. Plus someone else can easily steal
Only if he knows its text key or dictionary attacks it.
> your KSK if it falls off enough of the network. People can also play
> tricks like finding a node that doesn't have the key in its cache
> (by requesting with HTL=1) and then inserting it with HTL=1. There's
> supposed to be a random chance to keep forwarding a request with HTL=1
> but even so, the attacker still has a chance.
Correct.
--5QAgd0e35j3NYeGe
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6eZERr9IW4v3mHtQRAui0AJwLSR6UQeV/B09FX9ZrFXc7D0lJKACbBviC
kw5OpMrhuOeIH86PzPwjwXs=
=ZzUy
-----END PGP SIGNATURE-----
--5QAgd0e35j3NYeGe--
--__--__--
Message: 3
From: [email protected]
To: devl at freenetproject.org
Date: Thu, 01 Feb 2001 08:40:34 -0800
Subject: [freenet-devl] lists.sourceforge.net mailing list memberships reminder
Reply-To: devl at freenetproject.org
This is a reminder, sent out once a month, about your
lists.sourceforge.net mailing list memberships. It includes your
subscription info and how to use it to change it or unsubscribe from a
list.
You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.
In addition to the URL interfaces, you can also use email to make such
changes. For more info, send a message to the '-request' address of
the list (for example, freenet-dev-request at lists.sourceforge.net)
containing just the word 'help' in the message body, and an email
message will be sent to you with instructions.
If you have questions, problems, comments, etc, send them to
mailman-owner at lists.sourceforge.net. Thanks!
Passwords for devl at freenetproject.org:
List Password // URL
---- --------
freenet-dev at lists.sourceforge.net epakpu
http://lists.sourceforge.net/lists/options/freenet-dev/devl%40freenetproject.org
--__--__--
Message: 4
Date: Thu, 1 Feb 2001 12:39:53 -0500
From: Tavin Cole <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Proposal: algorithm for forgetting documents in
datastore
Reply-To: devl at freenetproject.org
On Thu, Feb 01, 2001 at 12:38:24PM +0100, Neil Barsema wrote:
> Tavin Cole wrote
> >There is no way "a file can be instrumental in a routing decision" ..
> >you're talking nonsense here.
> >I can see how the structure of the 0.3
> >datastore could lead to this misconception, but files and references
> >are going to be much more orthogonal in 0.4 anyway.
>
> >The best interpretation of what you just said is that, if a node
> successfully
> >routes a request for a file that was not in its datastore, it should
> >promote the file that was originally associated with the reference used
> >in the routing decision. So you would be promoting a file because it's
> >close to a key that's popular on another node. How would that help
> >matters?
>
> Hm for nonsense you pretty much got the concept well enough to see a way to
> implement it in the current technical solution. I apologise for missing this
> development I have been away ;-)
>
> anyway ok, the file originally associated with the reference gets a tiny
> bump.
> that's basicly my suggestion.
>
> Now to how that will help matters.
> Your not promoting a file that is close to a key that is popular on another
> node(well you are but thats besides the point), you are promoting a file
> that is close to a key that some other node thought your node should be
> serving.
Dude!!! You just don't get it. If your node routes a request, there's
no (necessary) relationship whatsoever with the key being routed and your
node's keyspace focus. Granted, you should receive more requests that
are close to your keyspace focus than not, but you'd still end up
promoting lots of files that are far away from it.
The closest we could come to making this make sense is, anytime your
node successfully serves a file from its datastore, it looks for the file
with the key closest to that one and promotes it. I hope you can see
the flaw in that.
> Basicly files competing against deletion are all pretty unpopular. Either
> because they aren't close enough to the keyspace focus or because they are
> outright unpopular.
>
> What people don't seem te get is I am fighting for unpopular files!
It's impossible! You can only end up reducing the percentage of successful
requests over the whole network.
I'm sorry if my explanations have been less than clear, but if you consider
how Freenet routing works for a while, you will come to the same conclusions.
> If the outright unpopular file gets deleted chances are it is going to fall
> out of Freenet altogether.
> however if we delete the file that just isn't close enough to the focus we
> are probably just reducing (unnescasary) redundancy in the network.
>
> My suggestion in no way guaranties the unpopular file will persists it just
> improves its chances.
>
> But okay, if no one sees the merrit in the suggestion I'll stop pushing it,
> I'll go back to pushing request forking. Has that been implemented yet ;-)
--
// Tavin Cole
--__--__--
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://www.uprizer.com/mailman/listinfo/devl
End of Devl Digest
