On Fri, Oct 31, 2003 at 03:52:41PM +0100, Some Guy wrote: > --- Toad <[EMAIL PROTECTED]> wrote: > > On Fri, Oct 31, 2003 at 12:43:51AM +0100, Some Guy wrote: > > > --- Tom Kaitchuck <[EMAIL PROTECTED]> wrote: > > > > On Thursday 30 October 2003 03:20 pm, Tom Kaitchuck wrote: > > > > > On Thursday 30 October 2003 01:46 pm, Toad wrote: > > > > I always thought of Hash Cash working like this. You pick your route, and then > > > you pay the > > toll. > > > > > > What we've discovered today is: > > > If you base the route only on the hashcash and things the hashcash's validity is > > > based on, the > > > adversary is forced to pay first and then get the routing key. > > > That's a big Ah-ha idea for me. > > > > > > I hadn't thought of including the hash cache with the URL at all. I thought > > > we'd make both > > sides > > > pay. They use about the same bandwidth resources. Then again it seems kind of > > > natural to > > make > > > the inserter pay to store stuff. > > > > > > Good spotting with the SSK problem Toad. Here's some ways around the problem: > > > 1) don't include the hash cash with the URL, make both sides do the work > > > 2) route everything in the same subspace to the same place, limit update > > > rate/subspace > > > 3) make everyone use global links > > > 4) make an insertion tool which makes the global links and does the hash cache > > > once > > > 4 is probably best. > > > What's a global link? > > We need SSKs to be SSK@<opaque fixed>/<human readable> - for things like > > for example DBRs. > What I mean is the user puts his HTML files and pics in a directory. All the HTML > just has > relative links. The insertion tool converts href="/foo/bla.html" to > href="SSK@<opaque > fixed>/foo/bla.html". That way you could test the files on the drives but the links > would still > work. > > If you wanted to fred could convert everything back to relative links on if the user > wants to save > the HTML like that. It could store the the long links elsewhere.
Everyone already uses relative links because many users have nodes on different ports. But I don't see how this solves the SSKs problem. DBRs, NIM forms and so on require that we just have SSK@<opaque fixed string>/<human readable string> Having said that, that is not strictly true... on NIM forms, you could precompute the hashcash. DBRs would initially have to be computed by the node at request time, which would really slow down requesting TFE... *but* TUKs would solve that problem. Edition sites could easily precompute the hashcash for the next edition. So I don't see a real problem here. And we wouldn't even need to break the network storage or routing... but we probably want to hold off for TUKs first... > > > > ----Scaling up key sizes and what not > > > > > > Ok, so CPU power will get cheaper. If memory/diskspace gets cheaper in > > > proportion it won't > > > matter. Today 1*CPU second is worth 32KB space. In 4 years 0.2CPU*s might be > > > worth 32KB of > > > space. > > > > > > Ok, what about some node farm creating tons of junk data, won't he eventually > > > have enough to > > do > > > his DNS attack? If you have some religious belief in Moore's Law (I don't) you > > > could argue > > that > > > no matter what CPU time today will be worth a certain amount of memory for all > > > eternity. You > > just > > > have to assume memory prices in the long haul decrease exponentially. > > > > I pragmatically believe in Moore's law because it has worked for the > > last 40 years. > Ok cool. > > > > Here's a fun idea: Could we take the routing key and before using it run it > > > through a special > > > function which changes slowly over time, in a yet to be determined fasion? For > > > example in the > > > future take some of the insignificant bits and mutiply them by constants and add > > > that to the > > > original hash. The idea would be that objects wander around in hashspace just a > > > little over > > > different versions of freenet. In a weeks time an object might only move a node > > > or two, but > > in a > > > few years it could be completely somewhere else. This should make such > > > adversary's stock pile > > of > > > ammo deteriorate, hopefully faster than he can generate it. > > > > I don't see why this would be useful, it would probably weaken > > specialization. The idea is not to use the hashcash in routing, just to > > verify it on each node. > The purpose is to keep someone from generating junk data for a year and then using > it since, by > then the junk won't be routed to the same place. > It won't screw up specailization if it's done gradually. Hmm, maybe. I don't see why you couldn't leave routing out of it - have a slowly changing salt factor fed into Tom's XXX, which is verified but is NOT used to route. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
